Difficult-to-implement encryption schemes in self-encrypting drives are likely handled incorrectly, leading to a false sense of security.
Hardware encryption capabilities are often highly-touted selling points of solid state drives (SSD) marketed toward enterprise users, and increasingly toward average consumers, as concerns about data privacy and identity theft increase. These self-encrypting drives (SEDs) contain a dedicated AES coprocessor used exclusively for handling drive encryption. This has the dual purpose of isolating encryption tasks from other drive operations for increased security, as well as eliminating overhead from either the main drive controller or system CPU, as neither are tasked with encrypting or decrypting data as needed — effectively making encryption a resource-neutral operation.
Despite the premium which SEDs command, their implementation is seriously lacking, as researchers at Radboud University in the Netherlands revealed in a paper released this week titled "Self-encrypting deception: weaknesses in the encryption of solid state drives." The researchers have found that both the "ATA security" and "Opal Storage Specification" for self-encrypting drives have material implementation flaws in SSD firmware which are trivial to exploit, in order to gain access to drive contents.
SEE: Quick glossary: Encryption (Tech Pro Research)
To make matters worse, Microsoft's popular BitLocker drive encryption software assumes that the encryption implementation of SEDs is trustworthy. For these cases, BitLocker acts as a frontend for the hardware encryption scheme found in these drives in order to increase drive performance, as the CPU usage which accompanies software encryption is not insignificant. Logically, this design choice makes sense, as it would be reasonable to assume that the hardware solution works, rather than attempt to encrypt data twice out of an overabundance of caution.
This behavior can be overridden using a group policy setting. According to Microsoft's guidance for configuring BitLocker to enforce software encryption, for self-encrypting drives which were originally 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." BitLocker is available to Pro and Enterprise editions of Windows 8.1 and 10, as well as to Enterprise and Ultimate editions of Windows 7, though the implementation in Windows 7 does not defer to hardware encryption.
While the researchers note that "properly implementing a hardware FDE scheme is not trivial," the number of implementation issues discovered in the tested drives underlies either a naïve or halfhearted attempt at implemententing full-disk encryption. For the Crucial MX100 and MX200 drives, it is possible to use a JTAG debugger to rewrite the drive firmware, allowing data access. This is a method which is known to be used by government agencies to infect drives. Likewise, both drives fail to bind the drive password to the decryption key, making it possible to unlock without knowledge of the drive password. While the MX300 has significant implementation improvements, the whole drive can be unlocked with a master password, which by default is blank. Samsung's 840 EVO and 850 EVO internal SSDs, as well as the T3 and T5 external SSDs were also found to be deficient.
The researchers conclude that "Hardware encryption currently comes with the drawback of having to rely on proprietary, non-public, hard-to-audit crypto schemes designed by their manufacturers. Correctly implementing disk encryption is hard and the consequences of making mistakes are often catastrophic," adding that "A pattern of critical issues across vendors indicates that the issues are not incidental but structural, and that we should critically assess whether this process of standards engineering actually benefits security, and if not, how it can be improved."
Edit: A previous version of this story indicated that users of BitLocker would be required to format an encrypted drive when switching from BitLocker-managed hardware encryption to software-based encryption when this option is forced via Group Policy settings. This has been corrected with information from a Microsoft advisory published after this article.
The big takeaways for tech leaders:
- Difficult-to-implement encryption schemes in self-encrypting drives are likely done incorrectly, leading to a false sense of security.
- BitLocker users are not safe, as the software encryption solution defers to hardware encryption by default when detected. This can be changed in a group policy setting, but requires formatting affected drives.
- Encryption: A cheat sheet (TechRepublic)
- A winning strategy for cybersecurity (ZDNet special report) | Download the report as a PDF (TechRepublic)
- Windows 10 tip: Save a copy (or two) of your BitLocker recovery key (ZDNet)
- Microsoft's BitLocker encryption program: A cheat sheet (TechRepublic)
- Flaws in self-encrypting SSDs let attackers bypass disk encryption (ZDNet)
- Microsoft BitLocker: Built-in encryption for your Windows PC (TechRepublic)