Using PKI-Based Security with CBFS Vault

PKI, which stands for "public key infrastructure", is a set of standards and protocols that lets you use asymmetric cryptography (also called public key cryptography) to sign and encrypt data in order to:

• Preventing unauthorized access to data by encrypting individual files, entire Vaults, or both.
• Providing data authenticity by signing data when it is written, and then validating that signature whenever it is read.

File and Vault Encryption

PKI is commonly used to strengthen standard symmetric data encryption. Using PKI (i.e., certificate-based) encryption in CBFS Vault is quite simple, but does require a bit of coding since CBFS Vault doesn't include built-in PKI functionality.

PKI is based on asymmetric cryptography. Asymmetric (public-key-based) cryptography uses two keys: public and private. However, this type of cryptography is not suitable for encrypting large amounts of data. To encrypt the actual data, convenient symmetric algorithms such as 3DES, AES, Blowfish, etc. are used instead. So in PKI, the following approach is utilized: a 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 a 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, while the decryption is done by using the corresponding private key. Separate copies of the session key can be encrypted using different public keys, allowing you to grant access to multiple users/devices by providing them with the respective private keys.

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

By default, CBFS Vault uses AES256-based encryption with SHA256 hashing. The symmetric key is 32 bytes in length, and it's derived from a password you specify for the file (or the Vault) and certain internal data. There are two approaches to implementing PKI encryption with CBFS Vault:

1. Use CBFS Vault's built-in symmetric encryption and create, use, and secure the session key in your application. You can then use the session key as the password for files or the Vault.
2. Implement your own encryption and hashing procedures and tell CBFS Vault 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 DRM With CBFS Vault article.)

Regardless of which approach you use, you will need a place to store the encrypted session key; CBFS Vault has a couple of options, depending on what you're encrypting. If you're using whole-vault encryption, you can store the encrypted session key and the information related to public and private keys (certificates, OpenPGP keys, or their IDs) in the special area of the vault referred to as its "RootData"; refer to the documentation for information. If you're using per-file encryption, you can store this information within the vault itself in file form, or even in an alternate data stream in a file itself.

Signing Files

Another use for PKI is to ensure the integrity and authenticity of the data using signing algorithms that are public key based. This allows readers to validate that the data originated from an expected source, and that it was not altered at some point between the source and the reader.

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 either before or after hash verification.

The signature can be wrapping or detached. Wrapping signatures include the original data, while detached signatures are separated from the data. In CBFS Vault, it makes sense to use detached signatures to avoid the signature verification step when it's not required.

CBFS Vault provides a place for detached signatures: you can store them in alternate data streams of a file. 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).