Enhance system security with better data-at-rest encryption

Dave Kleidermacher

March 24, 2012

Dave Kleidermacher

Managing the key
The primary purpose of data-at-rest protection is to ensure that information residing on lost or stolen media cannot be accessed by unauthorized parties who must be assumed to have complete physical access to the disk. Thus, the symmetric storage encryption key must never be stored in the clear on the disk. However, it's often necessary to store an encrypted copy of the symmetric key on the disk (or perhaps an attached Trusted Platform Module, if available). The key is unwrapped for active use while the system is executing in an authorized manner. For personal computers such as laptops and smartphones, unwrapping is triggered by successful authentication of the user (such as using a password, smartcard, biometric, or multiple factors).

Generating the key
A typical method of storage encryption key establishment is to convert user credentials into a key using a key derivation function (KDF). A popular KDF used to convert passwords is the password-based key derivation function, version 2 (PBKDF2). PBKDF2 is defined in the RSA Laboratories' specification PKCS #5 and duplicated in RFC 2898.^8,9 PBKDF2 applies a hash function to the password concatenated with a salt (random bitstring). To make password cracking more difficult, the standard recommends that the hash output be rehashed multiple times. The recommended minimum hash iteration count is 1,000, although the number is expected to increase over time. Apple's iOS 4.0 uses 10,000 iterations. In 2010, RIM BlackBerry's encrypted backup service was determined to be vulnerable due to faulty application of PBKDF2. Instead of following the standard, the BlackBerry software used an iteration count of one.¹⁰

When the password is used to directly generate the storage encryption key, a change in password changes the encryption key, thereby forcing re-encryption of the entire protected media. To avoid this problem, a permanent, unique encryption key is created when the media is initially provisioned, and the key is wrapped (encrypted) with the password-derived key. With this two-level keying scheme, a periodic password change only requires rewrapping of the encryption key.

The user-authentication approach may be sufficient for limited types of attended embedded systems that can tolerate user intervention whenever the protected volumes must be unlocked. Nevertheless, this approach is not sufficient for large classes of unattended embedded systems. If the embedded system encounters a fault and automatically reboots, the encrypted volumes must be able to get back online without manual credential input.

Remote key provisioning
We can consider two classes of unattended embedded systems: those that have a remote management network interface and those that do not. For the latter, the embedded system lacks any mechanism for dynamic interaction that can unlock an encryption key. In this case, if information value demands data-at-rest protection, the designer is advised to incorporate a cryptographic coprocessor that provides physical tamper-resistant key storage and internal execution of the data encryption algorithm. The device driver sends plaintext to this encryptor and receives ciphertext for storage on disk and similarly requests decryption of disk blocks as needed.

For network-enabled embedded systems, a remote management server holds a database of the provisioned data-encryption keys. A server connection is initiated by the embedded system whenever a data-encryption key must be unlocked (such as at boot time). The embedded system and server mutually authenticate, and the server provides a copy of the embedded system's provisioned data-encryption key over the secured channel.

Key escrow
When implementing a data-at-rest protection system, developers must consider key escrow to guard against the possibility that the authentication information used to unlock the storage encryption key will be lost.

There are situations where the system owner may need to extract the data from storage, such as after a system failure. In most system designs, holding a copy of the data encryption key in an off-site secure location is advisable in order to prevent loss of data when the data encryption key is no longer accessible. If the embedded system lacks a network management interface, the internally-stored key must be exportable onto media for off-site escrow storage (such as in a secure vault). If the system supports network management and remote key provisioning, developers need to ensure that remotely provisioned keys are retained on a secure server or copied to protected offline media.