Submitted via IRC for Bytram
BitLocker on self-encrypted SSDs blown; Microsoft advises you switch to software protection
Yesterday, Microsoft released ADV180028, Guidance for configuring BitLocker to enforce software encryption, in response to a clever crack published on Monday by Carlo Meijer and Bernard van Gastel at Radboud University in the Netherlands (PDF).
[...] The security researchers explain that they were able to modify the firmware of the drives in a required way, because they could use a debugging interface to bypass the password validation routine in SSD drives. It does require physical access to a (internal or external) SSD. But the researchers were able to decrypt hardware-encrypted data without a password. The researchers write that they will not release any details in the form of a proof of concept (PoC) for exploit.
Microsoft's BitLocker feature encrypts all the data on a drive. When you run BitLocker on a Win10 system with a solid state drive that has built-in hardware encryption, BitLocker relies on the self-encrypting drive's own capabilities. If the drive doesn't have hardware self-encryption (or you're using Win7 or 8.1), BitLocker implements software encryption, which is less efficient, but still enforces password protection.
[...] The hardware-based self-encryption flaw seems to be present on most, if not all, self-encrypting drives.
(Score: 2) by ElizabethGreene on Thursday November 08 2018, @06:49PM
I have never successfully gotten the boot volume of a machine to use hardware encryption. There isn't (or wasn't when I looked earlier this year) a way to turn it on it a running OS built from a task sequence.
(Second hard drives, yes. Boot drives, no.)
Does anyone have this working? You can see it under the "Encryption Type" when you run manage-bde.exe -status
I'd also like to know if the vulnerability effects msed. It nominally has support for self-encrypting drives under Linux.