Data Security and Integrety

What follows, is the technical specifications for the Management Console as well as the Encryption Technology contained inside CryptoFS.

Management Console

In the preferred model, the customer is provided with a management console. The management console generates a 2048-bit RSA public/private key pair. They then produce a signed license request which is submitted. When the license request is accepted, our licensing server generates the appropriate number of master licenses, one for each copy of CFS purchased. Each master license contains a unique identifier and the public key for the management console that will administer these copies.

To issue a license, the management console creates a 2048-bit RSA public/private key pair for this copy. It then creates a secondary license including the unique identifier in the master license, the security policy, and the licensee. The public key is also embedded in the license and the license is signed with the licensee's master key.

The master console can also create the key rings at this time, if desired. It then encrypts the key rings with the license's 2048-bit RSA key and signs it with the master key. Then it combines the two licenses with the encrypted key ring to form the final installation set. The key rings are the symmetric keys actually used to encrypt the data.

CFS, when started up, will read the master license (which contains no security-sensitive information) and see that the master license contains a sub-licensing key. It will then refuse to proceed unless it finds that secondary license. The secondary license can contain security policy information. This policy can include requiring all data be accessible through a recovery key or that all key rings be archived by the master console.

CFS cannot proceed further without decrypting the key ring. The private key required to decrypt the key ring can either be protected by a password or, ideally, stored in a FIPS-compliant security token, a physical device that connects to a computer's USB port.

If directed by the security policy in the secondary license, CFS Light will only use key rings that have been signed by the recovery key. This ensures that only keys archived by the master server are used. The key that signs the key rings does not have to be the same master key that signs the licenses. This permits the recovery private key to be kept where even those who administer the licensing of the software cannot access it. The recovery public key can also be placed in the master license, so even those who license the software cannot bypass or avoid the recovery requirements or access the archived keys.

Encryption Operations

On startup, CFS finds its master license (issued by the software distributor). If the master license directs it to do so, it locates a secondary license (issued by the licensee's distribution authority). If either the master or secondary license directs it to do so, it locates a signed key ring. If it cannot locate these things, CFS refuses to operate.

The key ring is always stored encrypted. The master and secondary licenses can be stored encrypted if desired. The preferred mechanism is for the key that decodes the key ring to be stored on a FIPS-approved security token.

The key ring contains 64 128-bit AES keys (assuming 128-bit AES has been selected). When an object needs to be encrypted, one of the 64 keys is arbitrarily selected and a 128-bit initialization vector and 128-bit salt are selected by a FIPS-approved random number generator. The object then has a salt appended to it and the HMAC/SHA1 of the object plus the salt is computed. The object and salt are then encrypted using RSA in OFB128 mode. The object identifier, initialization vector, encrypted object and salt, and HMAC are then stored and form the encrypted object.

File metadata is always stored as encrypted objects. File data is cut into pieces and stored as encrypted objects. This provides a significant benefit in that it ensures that all metadata and file data is tamperproof and that any data errors (whether intentionally caused or due to hardware or software problems) are detected immediately. Surprisingly, many other supposedly secure encryption products do not make any effort to validate the decrypted data.

CFS internal storage also protects against metadata loss or corruption. Each data object contains enough redundant information to place itself back where it goes. So even if a significant amount of metadata is lost, any data objects that are recovered can be identified and placed where they belong. This increases storage requirements slightly, but the benefit of recovery even against massive data corruption is significant.