Software-based full-disk encryption (FDE) has been around for a long time. But newer solid-state disks (SSDs) use hardware-based FDE, where the cryptographic operations are performed on an AES coprocessor baked into the disk rather than on the host computer’s CPU. These types of disk are sometimes referred to self-encrypting drives (SEDs). But researchers from Radboud University in the Netherlands, Carlo Meijer and Bernard van Gastel, have published a paper claiming that encryption on SEDs can be bypassed using different attack vectors.
SEDs are popular because they don’t impact performance like software-based FDE and were not supposed to be prone to cold boot and DMA attacks, where attackers can steal the encryption key from the computer’s RAM. But the new research suggests that SEDs are also susceptible to these types of attack. To support Suspend-to-RAM (S3), a secret key is usually stored in RAM so that users don’t need to enter a password to decrypt the disk when the computer wakes from sleep. BitLocker uses this method. And if the secret key is moved to the SSD, its controller is just as susceptible as the computer’s RAM.
Master Password Capability
In addition to the Media Encryption Key (MEK) that is required to decrypt an SED, manufacturers set a master password. If an attacker finds out the master password, which is written in the drive’s manual, then they can decrypt data without the MEK. The paper suggests that users must either change the master password or set the disk’s Master Password Capability setting to Maximum to disable the ability to decrypt the disk using the factory-default master password.
ATA Security and TCG Opal Specifications
Incorrect implementations of the ATA Security and TCG Opal specifications used in SEDs mean that the user’s chosen encryption password and the disk encryption key (DEK) are not cryptographically linked, potentially allowing an attacker to harvest the DEK and use it to unlock the disk without knowing the user’s password.
Lack of Entropy
Users can’t specify the DEK manually, so it must be generated randomly. The research states that a lack of random entropy could make it easy for an attacker to determine the DEK.
Microsoft Issues Security Advisory
The research shines a light on how poorly hardware-based FDE is usually implemented and that it could lead to data leakage. And in all the SEDs tested, the flaws identified in the paper were present. In Windows 7, BitLocker doesn’t support hardware-based FDE on SEDs. But in Windows 10, BitLocker by default offloads encryption to the drive if a supported SED is detected. This puts Windows 10 users in a situation that might leave them exposed.
In response, Microsoft has issued a security advisory (ADV180028) for Windows 8, 8.1 and 10, and Windows Server 2012 to 2019, suggesting that where BitLocker is used in conjunction with supported SEDs, Group Policy should be configured to force BitLocker to use software-based encryption. Setting the Configure use of hardware-based encryption for ……. drives to Disabled forces BitLocker to use software-based encryption. This setting is available for fixed, removable, and operating system drives.
If you are concerned about software-based FDE and cold boot attacks, Microsoft says that Windows 10 on modern hardware can support single sign-on, i.e. where users don’t need to enter a PIN to unlock the drive on start-up, protect the BitLocker encryption key while at rest – using a Trusted Platform Module (TPM) – and while in use and in memory, using a combination of Windows and hardware security features.