Encryption Keys: The Cliff Notes Version, Part 4

Key Management Mode Selection, Simplified

In my prior three posts, I provided an overview of encryption key fundamentals and the various encryption key mode strategies that can be implemented in a Mercury secure SSD. If you did not read those, stop everything and go back to them now! Or, stay here, keep reading and you'll find a simple, easy-to-use process flow diagram to guide you to the best key management mode for your application.

It is important to note, these are only general guidelines. If you have questions or doubts, consult with a security implementation expert. In this entry, I will also share our new key management mode for secure boot which is under development and releasing soon.

The first question to ask when getting started: will the data be stored on an end user device for a CSfC -approved implementation? If so, the key management mode options are limited to either Mode 1 or Mode 6. If the program is a black key program, Mode 6 is required.

If your data storage implementation is not intended for the CSfC program, answering these questions below will help in your decision:

1. Is data recovery after key purge required? The answer to this question determines whether you need a self-generated key (Mode 1) or a user-generated key (Modes 2 through 6).
2. Is the program a black key program? If so, Modes 5 and 6 are appropriate. Mode 6 includes an ATA password authentication, which is recommended unless there is a specific justification to avoid doing so.
3. If not a black key program, is automatic key purge beneficial or required for the mission? Session keys provide automatic key purge when power is removed from the device.
4. Is the added security layer of an ATA password required for the specific security implementation? If unsure of the answer to this question, it is best to err on the side of caution and implement an ATA password.

Future Directions in Key Management Modes

In Modes 0 through 6, the secure SSD operates as a data drive, independent of the host operating system. The host BIOS sends the ATA password and key to the SSD device to authenticate and access the drive after the system has booted. We now introduce the concept of secure boot for a secure SSD.

In secure boot mode, the host system will be configured to boot from an external device such as a USB flash drive containing a secure boot operating system and necessary encryption key. After the initial firmware is loaded with key and soft boot initiated, the drive operates normally.

As an example of practical secure boot implementation, consider a CO designing a new security implementation. A secure SSD with secure boot functionality is installed into a laptop as a boot drive. Because the laptop is easily portable, it would be a security risk to enable the laptop BIOS to initiate secure boot functionality. Instead, the CO loads a special secure boot operating system onto a USB flash drive. This secure boot operating system is designed to work only with the particular secure SSD installed in this laptop.

The end user is required to insert the USB flash drive and boot a small authentication-collecting program from the flash drive. The flash drive, containing the authentication firmware, challenges the user for authentication parameters such as a strong passphrase or even an encryption key value. The authentication information collected by the firmware is then conditioned and filled into the SSD. After this, a soft boot is applied and the SSD is then able to perform normal read and write operations. It is important to note that the encryption key is filled into the device through the secure boot operating system.

If you are interested in the implementation of secure boot mode or have questions regarding the right key management mode for your specific application, please contact us at [e-mail].