Two days ago, Dutch researchers from Radboud University in the Netherlands found out about a serious flaw in self-encrypting SSD drives which basically allows unwanted access to data without having to know any kind of secret that is used for encryption. The full paper can be found here: https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf
How does this affect BitLocker?
In some circumstances BitLocker will rely on a drive’s hardware encryption capability if it is advertised to the Operating System. The good news is, you can check your BitLocker implementation by running short CMD or PowerShell commands:
manage-bde.exe -status
or
Get-BitLockerVolume | fl
In either case, check the Encryption Method or EncryptionMethod parameter, respectively.
If no field reads “Hardware Encryption” you are safe.
How likely is this a problem for corporate use?
I am certain there are still some undisclosed things about this security flaw. However, I investigated how common corporate scenarios could be vulnerable. Here’s what I found out: I got in touch with several of our customers to check if they are safe and use software encrpytion for BitLocker. All of them reported the use of either AES or XTS-AES instead of any kind of hardware encryption. That’s also what I recall from several BitLocker projects where we always check parameters after encryption (like the encrpytion method). Granted, this was mostly done to ensure the correct version of AES instead of excepting hardware encryption which was considered safe until two days ago. What all of them have in common is the use of a built-in TPM chip for preboot authentication, including all scenarios like using PINs, Startup keys, or a combination of both. Although it is not documented and I have not yet received an answer from Microsoft, I am almost certain that the use of a TPM for BitLocker also forces the use of software encryption. And finally: it is extremely difficult to enable BitLocker hardware encryption in an automated fashion as there a several prerequisites including the use of the SSD vendors’ tools like Samsung Magician and other requirements (https://docs.microsoft.com/en-us/windows/security/information-protection/encrypted-hard-drive#system-requirements). Note that Self-Encrypting Drives (SEDs) and Encrypted Hard Drives (eDrives) are actually two different standards but they are similarly configured.
tl;dr: It is highly unlikely that you configured BitLocker using hardware encryption in your company by accident. However, please check your devices by using the commands above to be sure.
Migrating to software encryption
The steps you have to take to migrate to software encryption are straightforward:
- Configure and deploy a Group Policy to enable forced software encryption.
- Fully turn off BitLocker to decrypt all affected drives.
- Enable BitLocker again.
(taken from: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV180028) Sounds simple but will require much more effort in the field as you have to find a way to work on every devices.