Crypto SSD Encryption Key Exchange Methods

In order to perform encryption/decryption, an encryption key is required. In the following discussion, we will refer to this as the DEK (Device Encryption Key).

There are various ways in which the DEK can be provided to the device, we will discuss a few of these methods below.

Self Generated Permanent Key:

In this method, the drive internally generates an encryption key and stores it in a reserved area on the drive. Data is automatically encrypted and decrypted, the user has no control of the DEK. This method was used in some SSDs that are advertised as having AES encryption.

However, this key handling method offers no protection to the data at all as the DEK is stored in the drive itself; anyone that has access to the drive will have access to the data. The encryption engine in this case is merely functioning as a data scrambler, which is a requirement for MLC/TLC NAND flash.

User Generated Session Key:

In this method of key exchange, the user generates a DEK and sends it to the device, usually via an ATA Vendor Specific command.

The DEK is not stored in the device, thus every time the drive is power cycled, the user needs to resend the DEK to the device.

This method of key exchange is better than the Self Generated Permanent Key method just described because a 3rd party who has access to the drive cannot decrypt the data without providing the proper DEK.

This is one of the key exchange methods supported by Cactus Technologies CryptoSSD products, we refer to this as the SetDEK method.

The weakness of this key exchange method is that the DEK is sent over to the device in plain text, thus it is possible for a 3rd party to capture this DEK through some sort of bus monitoring method.

Furthermore, the DEK does not change and the same DEK is send over to the device every time; thus, one a 3rd party has captured the DEK once, it can decrypt the data if it manages to get access to the drive.

Cactus Technologies Single Factor Authentication w/ HMAC:

To address the issue of key exchange security, Cactus Technologies worked with eNOVA Technology Corp. to develop a secure key exchange method using HMAC protocol.

HMAC stands for Key Hashed Message Authentication Code, this is a well known authentication protocol, commonly used in the industry.

This key exchange method uses FIPS 140 level 2 certified hardware crypto modules in eNOVA MX+ device to generate a DEK.

A customer defined 256-bit shared key is used to generate a random Key Encryption Key (KEK), which is used to wrap the DEK in a MAC (Message Authentication Code). This MAC is then sent to the device.

In the device, this MAC is authenticated in the MX+ device and the DEK is then unwrapped from the MAC. The MAC is random and different every time and the DEK is not send over in plain text as in the SetDEK method; hence, this method of key changes is secure from 3rd party snooping.

In order for a 3rd party to be able to decrypt the data on the drive, it has to have knowledge of the Unlock PIN, the shared key and the series of ATA commands for HMAC exchange; it is highly unlikely that a 3rd party will have access to all three items.

Hence, this method of key exchange is highly secure. As is the case with the SetDEK method, the DEK is stored internally in the MX+ device in volatile register only.

This register is write only and cannot be read; the stored data is lost when power is removed, thus, key exchange must take place every time the device is power cycled.

This method of key exchange is very secure but is more difficult to integrate into a user's host system.

There are numerous ATA Vendor Specific commands involved, the details of which are disclosed to the customer only after an NDA has been executed with eNOVA Technology Corp.

Cactus Technologies will provide Windows and Linux HMAC utilities to manage the key exchange but for customers using other Operating Systems or operating environments who need to write their own utilities, please contact Cactus Technologies for further information and support.

Final Thoughts:

Cactus Technologies designs and manufacturers highly secure FIPS 140-2 Validated, AES256 Encrypted SSD in our CryptoSSD line of products. These products use a Crypto Module which is both FIPS 140-2 and FIPS-197 Certified.

Our 2.5” SATA Encrypted SSD have Extended (-40C to 85C) Operating Temperature versions, while the Encrypted External USB SSD is rated for 0C to 70C.

If you need assistance with an OEM design or needing special features, please contact us.