In the first two posts of this series, I reviewed fundamental terms and concepts of encryption key classifications and discussed roles of passwords versus keys and hash algorithms.  In this post, I will provide detail on each key management mode available on a Mercury secure SSD, not all of which may be supported by other SSD manufacturers.

Encryption Key Modes

While the complexity of implementation increases from one mode to the next in the following discussion, end user responsibility also increases. It is imperative to ensure that end users have the proper knowledge, training and infrastructure to successfully create, store, protect and distribute encryption keys and passwords. With these capabilities, the flexibility and security benefits of the more complex modes can be fully realized.

Mode	Key Type	Key Generation Mode	ATA Password	Data Recovery After Key Purge	FIPS-140-2 Support	CC Profiles Supported	CSfC- Eligible	Requires Guns and Guards
0	Permanent	Self	No	No	No	EE	No	Yes
1	Permanent	Self	Yes	No	Yes	EE AA	Yes	No
2	Permanent	User	Yes	Yes	Yes	EE	No	No
3	Session	User	No	Yes	Yes	EE	No	No
4	Session	User	Yes	Yes	Yes	EE	No	No
5	Black Key	User	No	Yes	Yes	EE	No	No
6	Black Key	User	Yes	Yes	Yes	EE AA	Yes	No

 

Mode 0: Self-Generated Permanent Key, without ATA Password

Mode 0 uses a self-generated permanent key and operates normally whether installed into its intended host system or any other system. This is the factory set mode. A purge of the encryption key in this mode leaves all data permanently encrypted, inaccessible to both adversarial and friendly forces. The data cannot be recovered after the key has been purged.

Mode 0 is not a FIPS 140-2 certified mode because there is no authentication. This mode is not recommended for any military data storage applications. Mercury includes this mode in its secure SSD portfolio to allow basic read/write operations of the drive to be tested for users unfamiliar with the security features of the more advanced modes.  

Mode 1: Self-Generated Permanent Key with ATA Password

Mode 1 uses a self-generated permanent key with the added authentication layer of an ATA password. Created by the CO during initial configuration, the ATA password must have high entropy (degree of randomness) for maximum security. The hash of the ATA password, as discussed in my previous post, is stored on the drive and used for authentication every time power is applied to the device. The ATA password is conditioned and then used to encrypt and decrypt the permanent key which remains on the device through power cycles, unless purged by command.

This mode is simple to implement and therefore well suited to individuals seeking to protect military data without substantial training in the more advanced key management modes. Because the identity of the self-generated key is unknown to both users and adversaries, it requires no additional infrastructure for protection and distribution of the key.

It is important to consider the scenario where the encryption key has been purged, as the key purge option has consequences that cannot be mitigated. In this scenario, the encryption key purge leaves stored data permanently encrypted; the key cannot be refilled by friendly or adversarial forces to access data again.

Because of these important security features, Mode 1 can be used to protect data up to the top-secret level in approved CSfC end user device implementations.

Mode 1 meets all requirements for FIPS 140-2, CC AA, EE and CSfC-eligible solutions.  

Mode 2: User-Generated Permanent Key and ATA Password

Mode 2 employs a user-generated permanent key created by the CO during initial configuration along with the ATA password. The CO must own and manage both values, requiring significantly more resource investment than Mode 1. As such, the CO maintains full authority to change and refill these values into the device at any time.

This mode is more complex than Mode 1, as the responsibility for creating key values with high entropy is placed on the CO. However, the end user gains the benefit of data recovery after a key purge event.

Like Mode 1, the SSD conditions the ATA password and uses the conditioned value to encrypt the permanent key. No plain text is stored on the drive. During normal operation, the ATA password is needed to decrypt the drive’s stored key to decrypt data.

Let me provide a common scenario for Mode 2. A secure SSD device storing high-value data must be transported to a new location. Prior to departure from the original location, the key is purged from the drive leaving the data in an encrypted state (with no installed key) ready for transportation. Once the device securely arrives and is installed in a new location, the ATA password and the key are input into the device. Normal read and write operations commence. Under normal circumstances, the permanent key will remain on the drive, encrypted, so the drive will operate normally when accessed with the correct ATA password.

If the drive were captured by an enemy in transit, the enemy would require both the key and the password to decrypt the data.

Mode 2 meets all requirements for FIPS 140-2 and CC EE.  

Mode 3: User-Generated Session Key, without ATA Password

In Mode 3, the CO generates the session key during the initial device configuration. The CO must take ownership of the key, ensuring that it is stored in a secure location away from the SSD device. When power is removed from the device, it automatically purges the key. When power is applied to the device, the session key must be loaded into the SSD to decrypt the contents of the drive.

Session keys are useful when the mission cannot rely on a user or system command for a key purge initiation. In military environments, events can happen quickly and unpredictably. Consider an unmanned vehicle containing sensitive intelligence data crashing in enemy territory after a missile attack. Using a session key mode in this scenario guarantees the key is automatically purged at power off, securing high value data without human intervention.

A session key adds yet more complexity to the end user’s key management process. The CO is responsible for creating the high entropic key value, securely storing the key and having it available at every power up for device operation.

Mode 3 meets all requirements for FIPS 140-2 and CC EE.  

Mode 4: User-Generated Session Key, with ATA Password

In Mode 4, the CO creates both the ATA password and the session key during initial configuration. Every time the device is powered, it needs both the ATA password and session key to operate normally.

While session keys can be automatically transmitted over network lines at power on, it is always preferable to require additional user authentication prior to giving access to high-value military data. When it is practical to have an individual directly engaged with the data storage system, the addition of an ATA password validates the user prior to key transmission. Thus, the combination of session key with ATA password makes Mode 4 more secure than Mode 3.

The addition of the ATA password adds further complexity to the key management mode process. There may be circumstances where it is desirable to have the encryption key and the ATA password managed by different individuals. While the complexity of this key management mode is high, the security benefits realized from this approach outweigh this complexity.

Mode 4 meets all requirements for FIPS 140-2 and CC EE.  

Mode 5: Key Encryption Key with a Black key, without ATA Password

In modes 0 through 4, keys are input into a device as a red, or plain text, key. In Mode 5, KEK with a black key, the key is input as a black, or encrypted, key.

First, the CO generates two random 256-bit numbers: a red key and a KEK. The KEK, described in the encryption keys section of the first post of this series, encrypts the red key, thus creating the black key.

Both the KEK and the black key must be entered into this device for normal operation. However, the order of entry matters. The KEK must first be entered into the SSD before the correct black key is accepted.

Readers may question when the use of a KEK with black key is warranted. Some military applications do not allow the transport of plain text key values. When this requirement is in place for a specific military program, a KEK with black key is required. These applications typically require the use of a simple key loader (SKL) for secure storage and transfer of keys between cryptographic devices.

Mode 5 meets all requirements for FIPS 140-2 and CC EE.  

Mode 6: Key Encryption Key a with Black key and ATA Password

In Mode 6, the CO generates three pieces of critical information which must be managed properly throughout the lifecycle of the mission:

1. Random 256-bit red key
2. Random 256-bit KEK
3. ATA password

As in Mode 5, the red key and the KEK are used to generate a black key. Both the KEK and the black key must be input into the device, but in this mode, after the ATA password, for normal read/write operations to commence. Mode 6 provides the highest level of security, yet demands the most stringent implementation and management requirements.

You may recall earlier in my first post that self-generated keys are considered more secure in the sense that the key is unknown, and therefore self-generated keys cannot be refilled after the key is purged. Yet the paragraph above states that the highest level of security is attained through the use of Mode 6.

This discrepancy is easily explained. Although beyond the scope of this blog, there are stringent stipulations surrounding the creation, storage, protection, distribution and destruction of black keys. These protocols used by our government and military forces deem the KEK with black key mode the most secure choice for encryption key management. As a result, this mode is certified for use in CSfC-eligible solutions to protect data up to the top-secret level in accordance with CSfC program guidelines.

Mode 6 meets all requirements for FIPS 140-2, CC AA, EE and CSfC-eligible solutions.

Up next in the final post of this series, I’ll provide an easy to use framework to determine which key management mode is best for your application and discuss a new mode for secure boot. To learn more, you can download the entire white paper “Unlocking the True Value of Encryption and Key Management Modes for Military Data Storage Applications” or contact me at secure.ssd@mrcy.com.