Background

Ciphers

Block Device Considerations

Requirements for encryption of data on a block file system device are quite different than requirements for encrypting a single file or a long stream of data. In particular:

  • Data are stored in fixed-size units (blocks, cylinders, sectors)
  • Each data block is processed independently of the other blocks
  • Encrypted data length must equal decrypted length
  • Layout of data blocks is not altered

Cipher Mode

A block cipher operates on fairly small blocks of data, generally 8 to 16 bytes. The mode defines how data larger than the block size is encrypted. The simplest mode is ECB (electronic code book) where each block is encrypted using only the key. The same data produce the same results no matter where the block is in the data stream. The other modes use some data other than the key (an random IV (initialization vector), the results of a previous operation, a numeric sequence, etc.) to modify the encryption process for each block. A cipher mode used for block device encryption has different requirements than a mode for encrypting a file that is read or written from the beginning to the end since any arbitrary block of data in the device may need to be read or written.

Of the traditional modes, the general consensus is that ECB is not suitable for this job. AES-CBC-plain is better but still offers a few potential exposures. CBC-ESSIV is a popular mode for disk encryption software and seems to be a reasonable choice.

In recent years, modes designed for block device encryption have been developed. LRW, XEX, and XTS are tweakable narrow-block encryption modes. (XTS: XEX TCB with ciphertext stealing and is a narrow-block cryptographic mode. (XEX stands for 'XOR-Encrypt-XOR', and TCB is Tweakable CodeBook mode encryption)). CMC and EME are wide-block encryption modes.

Standardization in cypher modes is being addressed by the IEEE 1619 Security In Storage Working Group (SISWG).

Questions to Ask

  • What cipher, mode, and key length does the product use?
  • What cryptographic module(s) are used? (e.g. openssl, linux kernel/cryptoAPI, loop-AES, etc.) Are they FIPS-140 certified?
  • Do you plan to provide support for IEEE SISWG cipher modes (LRW, XTC)?

Randomness

  • What PRNG is used?

Key Storage and Encryption

How and where the keys are stored are probably the most critical security aspect of these products. The simplest ones (cryptoloop,loop-AES,dm-crypt) use a single master key that the system manager must manage himself. Loss of this key means the data are not recoverable. Changing this key requires re-encrypting the data. Better applications (dm-crypt/LUKS,TrueCrypt, most commercial) create a master encryption key and encrypt it for multiple user keys. Any one of these keys can be used to decrypt the data, and any of them can be removed or changed without changing the master encryption key.

One area to worry about here is exactly how "remote help" is provided. One secure way to do this is to encrypt the master key for a user key known to the help provider and see that he has a current copy. It is critical to understand how this remote help service is provided to assure that there isn't some unknown key used to encrypt the master key. A good sign of this would be if remote help can be given without access to any data from the encrypted host.

  • Encrypted master key may be stored on disk. This may one version for each user key.
  • The user knows his key and enough about the master key to recover the master key.
    • Operating system protections may protect the user from directly reading the encrypted master keys.

Questions

  • How is the master key derrived?
  • Where is it stored and how is it encrypted?
  • Can the master encryption key be exported?
  • Any special protections of master key and cipher key schedule while in memory?
  • How are user passwords turned into user keys, e.g. PKCS#5 key strengthening?

Scope of Encryption

  • In general, you can't encrypt the MBR or partition boot record.
  • Before encrypted data can be processed, sufficient components of the OS must be loaded.
    • On linux, this is the data in the /boot partition (kernel, initrd (with encryption modules), boot loader). The root partition can be encrypted so long as there is an unencrypted /boot.
  • The encryption software must insert itself somewhere between the OS and the storage device.
    • On linux, the encryption is used on the block device that contains the file system either with a loopback device or device manager driver.
  • On systems with fairly strong file permissions, it may not be necessary to encrypt the system partitions.
    • This does open a vulnerability to alter the OS to intercept the encryption keys.
    • On Linux, it is probably reasonable to encrypt /home, swap, and various parts of /var and tmp directories.

OS/Hardware Integration

  • Boot sequence
  • TPM
  • Security tokens
    • Are keys stored on and retrieved from the token, or is the token used to decrypt the master key?
  • Key storage on USB mass storage

General

  • Encrypt in place?
  • Encrypt in place while in use with recovery?

Compatibility

These issues relate to the migration from one product to another or sharing encrypted containers between platforms.

  • Container format
    • Is there a header on the encrypted file system?
    • Where is metadata such as master key, etc stored? Is it exportable?
    • What container formats can be used, e.g. Truecrypt, LUKS, no container, etc.?
  • Can the master key be exported?
  • No labels