Using PKI-Based Security with CBFS Storage

When talking about PKI-based security in the file system, people usually mean something similar to EFS in Windows. However, the question is broader.

PKI stands for public key infrastructure, the set of standards and protocols that let you use asymmetric cryptography (also called public key cryptography) to sign and encrypt the data in order to prove data authenticity and to secure the data from unauthorized access.

There are several scenarios when PKI can be used:

  • Providing control over user access to the files or the whole disk by encrypting the files or the disk.
  • Providing authenticity by signing the data that is written and validating the signature when reading the data.

File and Storage Encryption

EFS provides only the encryption of the files and this encryption is done in a very complicated way. File encryption using certificates in CBFS Storage is quite simple but requires a certain amount of coding, as CBFS Storage itself doesn't have PKI functions.

PKI is based on asymmetric cryptography. Asymmetric (public-key-based) cryptography uses two keys — public and private (in PGP, the private key is erroneously called secret). However, this type of cryptography is not suitable for encrypting large amounts of data.

To encrypt the data, convenient symmetric algorithms are used such as 3DES, AES, Blowfish, etc. So in PKI, the following approach is utilized: the random key for a symmetric algorithm is created and this key is used to encrypt the data. This key is called the session key.

The key for symmetric algorithm is quite short and can be easily encrypted and decrypted using asymmetric keys. The encryption of the session key is done by the public key, and the decryption is done by using the corresponding private key. The session key can be encrypted using several public keys, so that you can provide access to the session key by multiple owners of multiple private keys.

The encrypted session key can be kept together with the data. However, keeping it separately reduces the chances for a successful cryptographic attack. On the other hand, keeping the key separately complicates the key management significantly.

By default, CBFS Storage uses AES256-based encryption with SHA256 hashing. The symmetric key is 32 bytes in length and it's derived from the password you set for the file (or the storage) and certain internal data.

With CBFS Storage you can use two different approaches to PKI encryption.

The first approach is to use CBFS Storage's built-in symmetric encryption and create, use, and secure the session key in your application. You use the session key as the password for the files or the storage.
The second approach is more complex: you can implement your own encryption and hashing procedures and tell CBFS Storage to use them. In this case, you decide how strong the key should be and what algorithms must be used for all the steps of encryption. This approach is discussed in more detail in the "Implementing DRM with CBFS Storage" article.

Whatever approach you use, you will need a place to store the encrypted session key. CBFS Storage offers you such a place. If you encrypt the whole storage, you can keep your encrypted session key and the information related to public and private keys (certificates, OpenPGP keys, or their Ids) in the RootData of the storage. If you use per-file encryption, you can use the alternate data stream of the file to keep this information.


Signing the Files

Another application for PKI is to ensure the integrity and authenticity of the data using signing algorithms that are public key based. This means that the data came from the source that was supposed to originate this data, and the information has not been altered on the way.

The data is signed using the private key (in fact, the hash of the data is signed, not the data itself). When the data is read, verification takes place. First, the hash is calculated and compared with the signed hash, then the signature is verified using the public key. The public key itself is checked for validity before or after hash verification.

The signature can be wrapping or detached. Wrapping signatures includes the original data, while detached signatures are separated from the data.

In CBFS Storage it makes sense to use detached signatures to avoid the signature verification step when it's not required.

Signing and verification of the data are usually atomic operations and the details are hidden in low-level procedures that you rarely call directly.

CBFS Storage provides storage for detached signature: you can store this signature in the alternate data stream of the file. And it's the job of your application to sign the data when or after it has been written and to validate the signature when the data is read (if validation is needed).


Ready to get started?

Learn more about Callback Technologies or download a free trial.

Download Now