Imagine a US operative on a covert mission is comprised in enemy territory. His laptop, now in the hands of the enemy, contains highly sensitive data stored on the factory-installed SSD and protected only by his 12-character Windows password. A skilled adversary using a brute force attack will quickly gain access to this data. Would you feel safe having our national interests stored on the same type of drive as your laptop? Without the use of a secure storage device with properly implemented encryption and encryption keys, data could easily fall into the enemy’s hands.

In two of my previous blog posts, Encryption Decoded and Diamonds are Forever, Encryption Keys Last Longer, readers learned about the importance of Advanced Encryption Standard (AES-256) XTS technology to encrypt and protect data at rest (DAR) in a secure solid-state drive (SSD). In this blog series, I will continue this discussion by providing a more in-depth look at the fundamentals of encryption keys and key management mode classifications, including relevant use cases. My goal is to help you understand encryption key basics and how to determine which key mode is best for your application when using Mercury’s TRRUST-Stor and ASURRE-Stor secure SSD's.

Before we dive into the encryption key terms and concepts, let's circle back to the encryption standards that are critical when implementing data security solutions in military applications.

Assurance

When protecting high-value data with encryption, it's critical to have assurance that the encrypting hardware or software is effectively securing the stored data. Standards and certifications for encryption algorithms and key management are in place to ensure just that.

The National Institute of Standards and Technology (NIST) oversees the Federal Information Processing Standards (FIPS) that provide criteria for the proper implementation of cryptographic algorithms. FIPS 197 validates the correctness of the AES-256 algorithms, while FIPS 140-2 provides the standards for key management and authentication algorithms. The National Information Assurance Partnership (NIAP) oversees evaluations of commercial Information Technology (IT) products for use in national security systems. Hardware and software products must meet the criteria established in the relevant Protection Profiles (PP) and pass evaluation by the Common Criteria (CC). Encrypted SSD devices must meet the Authorization Acquisition (AA) and Encryption Engine (EE) protection profiles prior to evaluation for the Commercial Solutions for Classified (CSfC) program.

The CSfC program was launched by the National Security Administration (NSA) and the Central Security Service (CSS) to protect classified, secret and top secret data by simultaneously implementing two compliant commercial security components in layers. For more information, you may refer to our white paper on hardware full disk encryption technology for the CSfC program or check out our CSfC webpage.

The single goal of a CSfC security solution is to emphatically ensure that no unauthorized user obtains access to highly sensitive data. The CSfC program is particularly relevant for this blog series, as only two key management modes are approved for use in devices integrated into fully compliant CSfC solutions. These two modes, introduced in a later blog, include compliance to the above standards while also incorporating the most stringent key generation, storage, distribution and destruction methods. Now to begin our journey, let's explore a few key terms and concepts.

Types of Text

Data encryption is comprised of two forms of text:

• Plain text data refers to information in its normal, legible form either before encryption or after decryption. Plain text is the input to an encryption algorithm.
• Cipher text data is the encoded or encrypted information that is illegible until decrypted into plain text data. Cipher text is the output from an encryption algorithm.

Encryption Keys

An encryption key, or data encryption key (DEK), is a random string of bits generated by an algorithm that is used to encrypt and decrypt data, converting either plain text into cipher text or cipher text into plain text. To further this concept, encryption keys are classified as either:

• A red key: plain text key
• A black key: encrypted key

A key encryption key (KEK) is designed to encrypt a red key into a black key or decrypt a black key into a red key. The specific use case of a KEK will be explored in my next blog. The critical point to remember for the purposes of this discussion is that a black key is used for missions and programs requiring the highest levels of security.

Encryption Key Creation

There are two methods to generate an encryption key.

• A self-generated key is created by the random key generator logic located in the SSD device. Self-generated keys are never known to users and therefore cannot be refilled after the key is purged.

Performing the important step of key generation on a certified SSD device removes complexity and encryption infrastructure on the end user. The drawback of a self-generating key is the inability to refill a key after it's purged, leaving data permanently encrypted to friends and foes alike.

When an encryption algorithm achieves FIPS certification, the random key generator within the encryption engine produces a key that is just that -- random. This eliminates the risk that a pattern in the key could be determined, resulting in adversarial discovery of the key’s complete identity.

• A user-generated key is created through a user-defined random key generator independent of the SSD device. This key is known to the user, usually the Crypto Officer (CO), and can be stored and refilled into the device after a key purge has occurred.

User-generated keys are inherently more complex to implement since the end user assumes 100% ownership for random key generation and secure key storage. These trade-offs are necessary when data needs to be accessible after a key purge. A user-generated key is the preferred method when the end user has FIPS-certified algorithms. It's important to note that this choice also demands the proper key management infrastructure and system security for key maintenance.

Permanence of Encryption Keys

Depending on your security requirements for a specific mission, an encryption key can be entered into the device as either a permanent or a session key.

• A permanent key remains on the device through power cycles. It can be purged through user-defined commands.
• A session key is automatically purged when power is removed from the device. To enable a normal read and write operation, the session key must be input every time the device is powered on.

Stay tuned for my next post where I will review ATA passwords, how they relate to encryption keys and how these critical values are stored on secure SSD devices. In Parts 3 and 4, I will take a deeper look at self-generated, user-generated, permanent and session keys with use cases.

To learn more on the fundamentals of encryption keys and key management modes, you can download my 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.