Flaws in Self-Encrypting SSDs Compromise Data Encryption

Researchers have found serious weaknesses in self-encrypting solid-state drives (SSDs) that could allow attackers to compromise data stored on them without knowing the encryption password.

Researchers Carlo Meijer and Bernard van Gastel from Radboud University in the Netherlands looked at several popular models of self-encrypting SSD from Crucial and Samsung and found security issues with their data encryption implementations.

Self-encrypting drives (SEDs) are either SSDs or HDDs with a built-in chip and firmware capable of encrypting data directly at the hardware level. This allows users to avoid using software-based full disk encryption solutions such as those available in operating systems.

When implementing encryption, SED manufacturers use the password capability of the ATA Security feature set, the newer Trusted Computing Group (TCG) Storage Security Subsystem Class standard also known as Opal or a proprietary solution.

Self-encrypting drives, either internal or portable, are popular with businesses because they offer an easy way to meet data encryption requirements. In fact, BitLocker, the disk encryption technology built into Windows, automatically uses hardware-based encryption if the SSD supports the TCG Opal standard.

Unfortunately, a lot can go wrong when implementing cryptographic systems in general, and hardware-based implementations such as those found in SEDs are much more difficult to audit than software-based solutions.

In their research paper, Meijer and van Gastel described several security issues that could affect hardware-based encryption implementations, ranging from not binding the encryption key to the user-defined password to using poor sources of randomness when generating encryption keys and issues with wear leveling and power-saving mode. They found a combination of these problems in all the devices they tested.

For example, the Crucial MX100 and Crucial MX200 do not cryptographically bind the user password to the drive encryption key. The password is hashed and checked against a buffer and if it matches, the drive is unlocked.

If attackers obtain such an encrypted drive, they can connect a JTAG debugging device to it and modify the password checking routine in RAM so that it validates regardless of the inputted password. This leads to a complete compromise of the data.

“Furthermore, we found that a vendor-specific command allows for arbitrary modifications within the address space,” the researchers said in their paper. “This enables malware with remote access to the host PC to infect the drive’s firmware, allowing it to hide itself and/or to survive re-installation of the host PC’s OS.”

Another Crucial SSD, the MX300, did bind the password to the encryption key, but had other issues that allowed for data to be recovered. Researchers found a way to write a modified firmware to the drive, which they then used to change the VerifyPasswd function to unlock a master key that protected all other keys—the drive supports multiple users with separate keys for different data ranges.

The Samsung 840 EVO SSD binds the password to the decryption key only if the MASTER PASSWORD CAPABILITY bit is set to Maximum in the ATA Security feature set or if the drive is configured in TCG Opal mode. If the bit is set only to High, then the password and key are not bound and decryption can be achieved in a similar way to the Crucial SSDs.

And even if the more secure modes are used, decryption might still be achieved due to a wear-leveling issue that could allow an attacker to recover a previous version of the crypto blob that was in use when the drive was in an unprotected state.

The Samsung 850 EVO SSD is similar to the 840 and suffers from the same problem with ATA security, with the exception of the wear-leveling issue.

The Samsung T3 portable SSD is vulnerable to password validation routine modification in RAM through JTAG, like in the case of Crucial MX100 and Crucial MX200. The Samsung T5 SSD also can be compromised, but requires obtaining a previous version of the crypto blob. This can be achieved by acquiring unsigned code execution on the device, which the T3 is also vulnerable to.

“The results presented in this paper show that one should not rely solely on hardware encryption as offered by SSDs for confidentiality,” the researchers said. “We recommend users that depend on hardware encryption implemented in SSDs to employ also a software full-disk encryption solution, preferably an open-source and audited one.”

In response to the researchers’ findings, Microsoft issued a security advisory that explains how to override BitLocker’s default behavior and force the use of software-based over hardware-based encryption, even if the disk supports the latter.

“After a drive has been encrypted using hardware encryption, switching to software encryption on that drive will require that the drive be unencrypted first and then re-encrypted using software encryption,” Microsoft warns. “If you are using BitLocker Drive Encryption, changing the Group Policy value to enforce software encryption alone is not sufficient to re-encrypt existing data.”

Featured eBook
Mobile-to-Mainframe: The Definitive Guide to Achieving Compliance

Mobile-to-Mainframe: The Definitive Guide to Achieving Compliance

Mainframes are a lot like banks. They hold some of the most valuable information in the world — which make them a lucrative target for everything from insider attacks to data theft. Mainframes today process over $8 trillion in credit card transactions annually, and as much as 70 percent of all corporate data still runs on the platform ... Read More
CA Technologies

Lucian Constantin

Lucian has been covering computer security and the hacker culture for almost a decade, his work appearing in many technology publications including PCWorld, Computerworld, Network World, CIO, CSO, Forbes and The Inquirer. He has a bachelor's degree in political science, but has been passionate about computers and cybersecurity from an early age. Before he chose a career in journalism, Lucian worked as a system and network administrator. He enjoys attending security conferences and delving into interesting research papers. You can reach him at lucian@constantinsecurity.com or @lconstantin on Twitter. For encrypted email, his PGP key's fingerprint is: 7A66 4901 5CDA 844E 8C6D 04D5 2BB4 6332 FC52 6D42

lucian-constantin has 254 posts and counting.See all posts by lucian-constantin