Software-based or Hardware-based AES 256 Encryption for securing DoD data on SSDs (Solid State Drives)

Software-based or Hardware-based AES 256 Encryption for securing DoD data on SSDs (Solid State Drives) 

Over the next several years, the US DoD, including all branches of the military, will face regular and complex decisions regarding the complete protection of all digital data.  Data must be protected regardless of how and where it is created, used, stored or transferred – physically and across networks.  Data at rest and data in-flight may be intercepted and possibly compromised.  All sensitive and top-secret data must be encrypted.

AES, the Proven Standard for Data Encryption

The Advanced Encryption Standard is a standard ratified by National Institute of Standards and Technology (NIST).  AES is approved as the FIPS standard and is included in ISO/IEC 18033-3.  AES is the only publicly available cipher approved by the NSA for storage and communication of top secret data.

AES encryption is available in different levels.  AES 256 is the highest level used to protect top secret data.  AES utilizes multiple blocks of highly complex algorithms to scramble data.  An “encryption key” is needed to unscramble or decrypt the data so it can be used. Currently, no weakness has been found in AES. This means brute force is the only existing form of attack that can decrypt AES encrypted data. Brute force can also be described as the method of trial and error.  Every possible “key” is tried until the correct one is found.  As an example, this could take a trillion machines, testing a billion keys per second, two billion years to discover the correct key.  It would take the world’s fastest supercomputer, TaihuLight[1] in China with ~ 100 petaFLOPs, millions of years to characterize a single AES 256-bit deployment.

Software-Based Encryption

Deploying a software or hardware based encryption solution has different benefits and drawbacks.  Software encryption uses external software to secure the data before it is written to the SSD. Software encryption can sometimes be a lower cost alternative to hardware encryption.  But there are significant drawbacks to using this approach.

A software-based solution often requires numerous updates to keep up with attack threats.  It’s not that the encrypted data is threatened, but the system doing the actual encrypting may be compromised. The protection provided by software solutions is only as strong as the level of security of the operating system. A security weakness in the OS can easily compromise the security provided by the AES encryption. If any change or update is made to the system or OS, the encryption process may become vulnerable or inoperable and the keys used for data encryption may be compromised.  Attacks such as “Evil Maid” or “Cold Boot” can be used to discover the encryption keys.  Moreover, updating encryption software can be tedious, requiring complex driver and software installations.  In many DoD data capture environments, maintaining the latest software to perform encryption may be impossible.  This is especially true when the data being encrypted is created and stored on SSDs within satellites, drones, or submerged or buried sensor arrays.

Though software encryption is better than having no encryption at all, it may still be vulnerable to user error. Managing software encryption requires users and administrators to follow certain procedures in order to secure the data.  Not only do these procedures need to be documented and maintained, they also need to be followed.  The reliance on encryption for securing data can be compromised if procedures are maliciously or negligently forgotten and purposely avoided.

Another challenge of using a software-based solution is performance.  Performance degradation is a notable problem with software-based encryption.  A recent paper presented at the Data Storage Innovation Conference entitled “Encrypted Storage: Self-Encryption versus Software Solutions” concludes that performing AES 256-bit encryption with software vs. hardware has a significant impact of overall read and write performance.  When working with modest sized files, the impact of a hardware-based solution was barely noticeable, while the software-based solution degraded performance by a staggering 45%.  The performance degraded even further with large files.  The hardware-based solution degraded performance by roughly 5%, while the software-based solution degraded performance by nearly 60%.

Although software-based encryption seems simple on the outside, it is riddled with possible security risks and opportunities for data theft.   It also places a large burden on the host system, causing significant performance degradation.  Moreover, a large amount of IT management resources are required to properly maintain, update and ensure the software-based encryption solution is working as expected.

Hardware-Based Encryption

Hardware-based encryption on SSDs is very different.  SSDs, with hardware-based encryption are SEDs (self-encrypting devices). Hardware encryption uses the SSD’s “on-board” AES encryption engine to perform encryption and decryption. It is self-contained and does not require the use of any additional software. Therefore, it is essentially free from the possibility of contamination, malicious code infection, or OS vulnerability.  The encryption process is intrinsic and automatic.  It cannot be forgotten or purposely avoided by the user.

With SSDs, the DEK (disk encryption key) is used to encrypt and decrypt the data. Unlike software-based encryption, the process of applying the actual encryption and decryption of data is done inside the SSD using the SSD’s controller chip and the internal DEK.  The DEK is never on the host system, but encrypted and hidden within the SSD.   All data stored on the SSD is automatically encrypted when written and automatically decrypted when read.

In addition to the DEK, is the KEK (Key Encryption Key) which encrypts and locks the DEK within the SSD so data cannot be freely written and cannot be freely read. When an SSD is first installed, the host authentication service creates a random KEK.  After the KEK is created, it is encrypted and stored on the SSD before any data is written to the SSD.  The SSD remains locked and any data on the SSD cannot be used until the SSD and DEK are unlocked by the KEK.

To unlock the SSD the user must first be properly authenticated. When the user is properly authenticated, the OS sends a KEK to the SSD.  The SSD receives the KEK (Key Encryption Key) from the OS.  The SSD matches the KEK against the original, internally stored, KEK.  The function of comparing the KEKs for authentication is performed inside the SSD. If the two match, the SSD is unlocked and the DEK can decrypt the data as it is read and allow new data to be encrypted and written.   The user credentials (original KEK) and the DEK are never in the “clear” inside the SDD.  They are encrypted and hidden.  The original KEK and DEK are never exposed in the memory, processor, or OS of the host computer.  The authentication service of the host provides a KEK only when the user is properly authenticated.

The actual authentication sequence is as follows:

  1. The host is booted.
  2. BIOS attempts MBR (Master Boot Record) read from the SSD.
  3. SSD redirects BIOS to hidden pre-boot area on the SSD
  4. SSD loads pre-boot system code to the host so a KEK can be provided
  5. User enters authentication credentials for the SSD to verify
  6. The host authentication service provides the KEK to the SSD
  7. The host provided KEK is compared to the hidden internally stored and encrypted KEK within the SSD
  8. If they match the drive is unlocked, the hidden and internal DEK is decrypted and encrypted data can be read and new data can be encrypted and written.
  9. If they do not match the SSD remains locked and the DEK remains locked. The SSD does not respond to read or write requests.

As you can see, because the original DEK and KEK are encrypted and remain hidden and secured inside the SSD, the OS, host system and SSD are significantly less vulnerable to attacks aimed at obtaining these keys.

Conclusion

Hardware-based encryption is the clear choice when using AES 256 encryption to secure DoD sensitive and top secret data.

  • Encryption keys remain encrypted and hidden within the SSD and are never exposed to the host memory, processor, or OS.
  • Encryption keys keep the SSD locked even if the SSD is stolen or intercepted and installed on another host.
  • Encryption is automatic and users cannot forget or purposely avoid the encryption process.
  • Encryption is maintenance and error free. Host system upgrades, repairs, security patches, and breaches have no impact on the encryption performed and data stored inside the SSD.
  • Encryption is OS independent, does not require software or even an OS to encrypt data.
  • Encryption is performed by dedicated hardware encryption engines with very limited impact on performance.

 

For DoD data created and stored:

  • – in the datacenter or in the field,
  • – in any environment or in any system,
  • – and in flight or at rest,

Using hardware-based AES 256 encryption is the clear choice to secure top secret data.

 

Writer: Zophar Sante, Business Development

Date: 4/30/2018

[1] Source: High Performance Computing top 10 list Nov, 2017 https://www.top500.org/lists/2017/11/