If you use Win10 BitLocker on a solid state drive, you need to follow MS’s advice and re-activate it

Topic

New Reply

There’s a bug in most self-encrypting SSDs that leaves the data on the drives wide open. It’s complicated, but in theory anyone who can get at the har
[See the full post at: If you use Win10 BitLocker on a solid state drive, you need to follow MS’s advice and re-activate it]

4 users thanked author for this post.

JohnW, Elly, AlexEiffel, Mr. Natural

Reply | Quote

Replies

My personal opinion of Bitlocker is you’re inviting big trouble.

Red Ruffnsore

Reply | Quote

Bitlocker works frustratingly well, and it’s only a problem when the recovery details were not recorded.  I’ve seen people turn it on for USB devices and not write down the password or recovery key and expect me to somehow fix it.  It makes diagnostic work harder as well, but that’s a good thing in terms of keeping data protected.

Reply | Quote

In reading Microsoft’s security advisory, I believe the “solution” you mention in the last sentence should be:

[Turn off] BitLocker to unencrypt the hardware protection, then [enable BitLocker to] install software protection

1 user thanked author for this post.

woody

Reply | Quote

It is also necessary to use Group Policy to disable hardware encryption before re-encrypting the drive again with BitLocker.   If hardware encryption is available on the drive, Windows will enable it by default.

See “Configure use of hardware based encryption for operating system drives” in Group Policy editor.

If you disable that policy, Windows will use software based encryption instead of hardware based encryption the next time you enable BitLocker for that drive.

Windows 10 Pro 22H2

Reply | Quote

Is there a link to Microsoft Security Advisory?

Reply | Quote

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV180028

There’s a crucial step in there – you need to change settings to enforce software encryption before turning BitLocker back on.

 

Mind you, the truly paranoid haven’t been trusting the self-encryption on those drives anyway. Just like they don’t trust TPM. Well, I can sort of understand that in some situations, but…

Reply | Quote

We have recently implemented MBAM in my company, so I looked at this today, to make the suggested change in the policy. However the policy for setting hardware/software encryption only resides in the BitLocker section of Group Policy (Configure use of hardware-based encryption), not in the similar MDOP MBAM section. MS advice is to not touch any of the settings in the BitLocker section if you use MBAM, so how is this prevented? Does MBAM always force software encryption?

Reply | Quote

I wrote a message about this subject that I thought was a response to this post by Woody, but it’s actually in the other SED thread.  In short: Not all implementations of TCG Opal (as used by Win 8.x and 10 Bitlocker) are faulty, according to the researchers who initially reported this vulnerability.  They tested five models for Opal vulnerability, and found it present in the Crucial MX100 and MX200.  The Crucial MX300, the Samsung 840 Evo, and the Samsung 850 Evo were not affected.  If yours is a model that is not among the five shown, it may or may not be vulnerable.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

Reply | Quote

… but the MX300 had the problem that the permanent (well, until SSD firmware update at the very least) master password was found to be an empty string.

Oh well. I did have a bit of a problem with the BitLocker settings on this particular system, what with a too-old TPM version and all. Was already doing it in software as a result.

So, if you check and find that you’re already doing software encryption, you aren’t in an immediate hurry… until you get new hardware.

“manage-bde -status |findstr Method”

Reply | Quote

mn– wrote:

… but the MX300 had the problem that the permanent (well, until SSD firmware update at the very least) master password was found to be an empty string.

I didn’t read the specifics in the MX300, as I don’t have one (as an aside, I did buy one two years ago for my laptop that now has a Samsung 850 Evo, but I could not get the MX300 to work with the ATA password in the laptop.  The Samsung works fine).

Still, if the drive adheres to the ATA spec, the master password is not permanently set.  If only the user password is set, that will lock the drive, but the default master password can be used to unlock the drive too.  If the BIOS/UEFI includes no way to set the master password, you can still set it manually to close the loophole.  That’s how it is on my Acer Swift, with its awful Insyde firmware.  The UEFI setting only allows me to set the user password.  While it is impossible to send the default master password in the UEFI unlock popup, it would be simple to pop the drive into another PC and enter the default password (or null password) with something like HDPARM.

What I did to plug that hole was use the HDPARM command in Linux to set the master password:

sudo hdparm –user-master m –security-set-pass “XXXXX”

That sets the master password to XXXXX, but leaves the user password set to whatever you set it to in the UEFI firmware.  Note that what you enter into the password in the UEFI is not the actual password sent to the drive.  The UEFI does something to the password that makes it impossible to set the password with HDPARM and unlock it with the UEFI challenge on bootup, unless you know what it is that it does with the password.

I also learned that my thought that setting the master password might be the same as setting to “max” security mode (on my Samsung drive) was not correct.  I read the actual report from the original researchers, and it was quite clear.  To have the drive encrypt the key, it is necessary to use max security mode (a big oversight on Samsung’s part).

I was looking into a way to get it set up in “max” mode with the uncooperative UEFI, but then I learned how bad the Insyde firmware really is.  Enter the wrong password three times and it gives you an unlock code.  I do not know how to use that to unlock it; my code is 10 digits, while all of the online references and unlocking tools for Insyde use an 8 digit code.  I can confirm that using them and entering the 10 digit password did not work.

Still, for the UEFI to give the attacker a hint that can be used to detect the password is absurd, absolutely, stupidly absurd.  Even if I get the max security mode set, my stupid firmware is willing to give away the store. I thought it was bad when Windows told me I have to set a password hint, which I sent to an epithet directed at Microsoft… but giving away an unlock code is beyond the pale.

As such, I am working on other alternatives.  Right now, I have the /home partition encrypted via software (but hardware accelerated in the CPU, which has the AES-NI instructions) with LUKS and AES256.  It does result in a 30% slowdown compared to no software encryption, which I don’t like, but I’m still experimenting around.  I stopped using the encrypted KDE vaults because they were far slower still (about a 90% loss of speed).

The Crucial devices had more security problems, but I understand they’ve received patches.  Samsung says “use software encryption.”  I could have bought a cheaper drive than the Samsung if I wanted to do that, Samsung.  Not cool.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

Reply | Quote

I’m using a Samsung 850 EVO, but I’m not taking any chances.  If down the road the details are confirmed, I will flip it back to hardware SED.  Software only for now…

Windows 10 Pro 22H2

Reply | Quote