Microsoft Security Advisory for self-encrypting drives
Microsoft published the security advisory ADV180028, Guidance for configuring BitLocker to enforce software encryption, yesterday. The advisory is a response to the research paper Self-encrypting deception: weaknesses in the encryption of solid state drives (SSDs) by the Dutch security researchers Carlo Meijer and Bernard von Gastel from Radboud University (PDF here).
The researchers discovered a vulnerability in Solid State Drives that support hardware encryption that enabled them to retrieve data from the encrypted drive without knowledge of the password used to encrypt the data on it.
The vulnerability requires local access to the drive as it is necessary to manipulate the firmware of it to access the data.
The security researchers tested several retail solid state drives that support hardware encryption and found the vulnerability in each of them including Crucial MX100, MX200 and MX3000, Samsung T3 and T5, and Samsung 840 Evo and 850 Evo drives.
How BitLocker is affected
BitLocker supports software and hardware encryption but uses hardware encryption by default if supported by the drive. Means: any drive that supports hardware encryption is potentially affected by the issue on Windows.
Microsoft suggests that administrators switch the encryption mode from hardware to software to address the issue and resolve it at the same time.
Verify the encryption method
System administrators can check the used encryption method on Windows devices in the following way:
- Open an elevated command prompt, e.g. by opening the Start menu, typing cmd.exe, right-clicking on the result, and selecting the "run as administrator" option.
- Confirm the UAC prompt that is displayed.
- Type manage-bde.exe -status.
- Check for "Hardware Encryption" under Encryption Method.
The solid state drives uses software encryption if you don't find hardware encryption referenced in the output.
How to switch to BitLocker software encryption
Administrators may switch the encryption method to software if BitLocker uses a drive's hardware encryption capabilities on a Windows machine.
BitLocker can't switch to software encryption automatically if a drive uses hardware encryption. The required process involves enabling software encryption as the default, decryption of the drive, and encrypting it using BitLocker.
Microsoft notes that it is not required to format the drive or install software again when switching the encryption method.
First thing that needs to be done is enforce the use of software encryption using the Group Policy.
- Open the Start menu.
- Type gpedit.msc
- Go to Computer Configuration> Administrative Templates > Windows Components > Bitlocker Drive Encryption.
- For the system drive, open Operating System Drives and double-click on Configure use of hardware-based encryption for operating system drives.
- For fixed date drives, open Fixed Data Drives and double-click on Configure use of hardware-based encryption for Fixed Data Drives.
- For removable drives, open Removable Data Drives and double-click on Configure use of hardware-based encryption for Removable Data Drives,
- Set the required policies to Disabled. A value of disabled forces BitLocker to use software-encryption for all drives even those that support hardware encryption.
The setting applies to new drives that you connect to the computer. BitLocker won't apply the new encryption method to drives that are already encrypted.
It is necessary to turn off BitLocker on affected drives fully to decrypt the data and turn it on again after the process so that BitLocker uses software encryption as defined in the Group Policy to encrypt the drive's data.
Here is how that is done
- Open Explorer on the computer.
- Right-click on the drive and select "Manage BitLocker" from the context menu.
- Select "Turn off BitLocker" to decrypt the drive. The time it takes to decrypt the drive depends on a number of factors
- Once BitLocker is turned off on the drive, enable BitLocker encryption again on the drive.
Closing Words
The issue affects Solid State Drives that support hardware encryption. The security researchers tested only some Solid State Drives that support the security feature; it seems likely that additional drives are vulnerable as well.
Attackers need local access to the drive to exploit the vulnerability. While that is very limiting, it is still suggested to switch to software encryption especially if critical data is stored on the drive or if the computer or drive may be sold or given away at a later point in time. (via Born)
It says “Encryption Method: XTS-AES 128” on my Samsung 950 Pro M.2 NVMe SSD.
Hopefully we could know what SSDs are good and not effected with such a vulnerability.
Seems kind of nuts to pay extra for an edition of Windows that simply uses the features that are already part of your SSD, when you can use a demonstrably more secure product for free. Of course I’m talking about Veracrypt. Not only does Veracrypt not contain any known serious flaws like this, but in the event that you run into some kind of trouble with it, you are using a standard, open source product instead of some drive manufacturer’s proprietary implementation of encryption, meaning that getting help is likely to be easier or at least much less painful on your wallet than it would be if e.g. the encryption integrated in your SSD freaks out after the warranty has ended. You can for example back up the volume header of the Veracrypt container to a different device so that if it gets damaged or something, fixing it is easy. And of course you can audit the code or pay someone else to do it to ensure that it is properly implemented and there are no gaping holes. This is what was done with Truecrypt, which Veracrypt is a continuation of. As long as the CPU has AES_NI, there will be no speed penalty.
@Kevin: “Not only does Veracrypt not contain any known serious flaws like this”
Since computer security is my professional bent, I’m going to be a little pedantic about this. The problem with the encrypted SSDs is not that they contain flaws in the cryptography (nobody has found any such flaws, anyway). The very nature of the vast majority software-based crypto means that very few, if any, would have this problem.
To be clear, here’s what the issue is:
These drives use a crypto key that is not derived from the password the user sets on them. That is flaw #1, as it means that if you can find a way to reset the password, then the drive can be properly decrypted.
Flaw #2 is that by connecting to the physical debug port on these drives, it is trivial to reset the password without having to know what the old password was.
Thus, anyone who has physical access to these drives also has access to their contents regardless of the encryption. The encryption itself is not compromised, though.
Yeah what Veracrypt and Luks do is generate a random master key that actually has nothing to do with your password, but then they encrypt that key with your password. This way, your password isn’t actually the key to the encrypted data, and so you can change your password without needing to reencrypt everything. When you want to change passwords, they just decrypt the master key that was encrypted with your former password, and then reencrypt the same master key with your new password. This also means there can be more than one password in the case of Luks, just store multiple encrypted copies of the same master key in different slots.
What these drive manufacturers are doing is failing to secure and protect the master key.
@Kevin: “Yeah what Veracrypt and Luks do is generate a random master key that actually has nothing to do with your password, but then they encrypt that key with your password. ”
Yes, this is the compromise process that most such software engages in, and is what the drives should have been doing.
I do feel it’s important to note, though, that even the drives they tested that did not have this particular flaw were still able to be cracked using a code injection flaw in the same debug port.
Again, I feel it’s important to point out that all of these methods require physical access to the drive (meaning that you have to be able to open the case and connect probes to the drive itself). As such, while none of this is good, it’s not something that is likely to bite most people.
What I’ve been recommending is that people should encrypt their sensitive data regardless of whether or not they’re using an encrypting drive (they should do this regardless of the existence of these flaws), and don’t panic over this issue.
I meant van Gastel :-) Double mistake. :-( Sorry for the typo! :-(
I am quite sure that the TU Delft researchers really would like to have discovered this! :-)
Martin, Just a ferry small point in this otherwise really great article which only the family of the Dutch security researcher Bernard von Gastel from the Radboud University will interest. It’s not von Gastel but van Gatsel. :-)
Just to be Sure. On my SSD its says “XTS-AES 256” as the “Encryption Method:”. This means im safe and use Software Encryption right?
No. That is referring to the crypto scheme your drive is using, but the security problem found with major encrypted SSDs is not related to the crypto scheme. That label on your drive doesn’t indicate whether or not your drive is affected. Given that most drives appear to be affected, the only safe assumption to make is that yours is in that group.
I recommend that you use crypto software.
Or, ignore the issue, depending. Physical access to these drives is required in order to crack them, so you aren’t vulnerable to online attackers because of this.
@John Fenderson,
Microsoft would disagree with what you had said about “XTS-AES 256†as the “Encryption Method.†The label would actually state “Hardware Encryption” if hardware encryption is being used.
Reference:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180028
Reading this again – I may have misunderstood the original question.
I am referring to the output of manage-bde.exe -status
What value is listed as the Encryption Method field?
yes i am referring to the “manage-bde.exe -status” output. The output says: “Encryption Method: XTS-AES 256“.
@AngryJohnny75
Thank you, I had misunderstood what DropZz was saying. I thought he was referring to a physical label on his hard drive. You made me realize that he was talking about what Windows was reporting. You’re right, that’s entirely different.