Bitlocker vulnerability on several SSDs

Topic

New Reply

Not sure, whether this is the right forum branch for this, but I like to drop the information.

Using a SSD drive and Windows in combination with Bitlocker to encrypt sensitive information isn’t a good idea at all. Admins need to take care, to set the right GPOs (not allow Bitlocker to use the drive’s hardware support for encryption). The reason: With hardware supported Bitlocker encryption there are possibilities to bypass the encryption key on SSDs. Some security researchers found a way, to read encrypted data without using the encryption key from popular SSDs (Samsung, Crucial).

Forcing Bitlocker to use software encryption avoid this szenario. Details may be found within my blog post: SSD vulnerability breaks (Bitlocker) encryption

Ex Microsoft Windows (Insider) MVP, Microsoft Answers Community Moderator, Blogger, Book author

https://www.borncity.com/win/

2 users thanked author for this post.

Elly, Microfix

Reply | Quote

Replies

The chart published in this article shows that one of the SSDs I use for its self-encryption capabilities, the 850 Evo, is only vulnerable in the ATA mode in “high” security.  I read much about this possibility when I first set up my 850 Evo (bought in a Black Friday sale just over 2 years ago)… you set the user password, but the master password isn’t necessarily set (there may not be an option to set it in the BIOS/UEFI, but it’s there in the drive anyway, as it is part of the ATA spec).

If the master password is not set, it remains at the default setting, whatever that may be, and it can be used to unlock the drive or to remove the user password without actually knowing the user password.  If the master password is not set, there’s essentially no security.

Note that this isn’t really a vulnerability– this is the expected behavior as defined in the ATA spec.  It’s up to the BIOS maker to offer the possibility of setting both passwords, and for the user to understand that they both must be set (and further, that they’re not the same as the BIOS/UEFI password, which can really be confusing to some people).

If the BIOS/UEFI allows you to set maximum security mode, that means the master password cannot be used to unlock the drive or to remove the user password.

In the “maximum” security ATA mode, the 850 Evo is listed as not vulnerable.  That’s not actually the mode in which I use my 850; it’s in “high” security mode, as that is the only option in the BIOS, but the master password is set (to be the same as the user password).  As far as I understand, this has the same effect as using maximum security mode.  I hope this mitigates the lack of cryptographically linked keys!

My other laptop with a Samsung SSD is my Swift, which has a 1TB M.2 (SATA) 860 Evo, which wasn’t listed in the chart, but I doubt it’s worse than the 850 Evo.  Like the Core 2 laptop, it doesn’t have an option for “Maximum” security, but it does allow me to set the master password, which hopefully achieves the same as setting the “Max” mode.

If this is not the case, then Samsung has a problem.  I bought my Samsung SSDs specifically to use the self encrypting mode, and if it is not as good as they claimed in their sales literature, it’s not going to cut it to just say “use software encryption.”  Their own sales literature said their hardware encryption is better because it’s transparent and has no performance loss!  That’s a promise they need to keep.

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

Reply | Quote

The Samsung site has a recommendation to use encryption software and a BIOS update so I suspect the problem exists in any mode.
https://www.samsung.com/semiconductor/minisite/ssd/support/consumer-notice/

cheers, Paul

Reply | Quote

The researchers who informed us of this issue in the first place said that the 850 Evo is only vulnerable in one of the ten or so tested modes.  I can only take them at their word for the time being.  Sometimes security vulns do end up being worse than they first appear, but it could also go the other way.

The response from Samsung seems to be a “pass the buck” thing.  “Oh, is one of our advertised features not working?  Just use the slower alternative that we told you was bad when we sold you the unit and took your money.”  I bought Samsung specifically to get the full drive encryption, and it cost me more than if I had bought another model with the same performance but without the full disk encryption.

I think Samsung may fix this in firmware for the internal models too, hopefully.

As soon as I typed that previous message, I went to the Samsung site to see if there was a firmware update listed for my 860 Evo (I will worry about the 850 in the other laptop later).  They don’t provide that info, or at least I could not find it– you’re just supposed to use their Magician software, which only runs on Windows, and let it figure it all out for you.

I still have a vestigial installation of Windows 10 on the otherwise unused eMMC drive on the Swift, so I booted that and downloaded/ installed Magician.  It did say there was a firmware upgrade available, but no date was given for the new version, and given that the message on the Samsung site only mentioned updates for the externals, I’m guessing that the version for my device predated this vulnerability.

Boo to Samsung for making firmware upgrades depend on a Windows-only program (EDIT: This applies to the 860 series.  Some other models, like the 850 series, do have .iso-based updaters that can be used independently of OS), and boo again for not making the release date/patch notes for the new firmware revision easily accessible.  Even the firmware updater for my Swift laptop (which has no built-in flash utility) will run in DOS from a boot “disk.”

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

1 user thanked author for this post.

BobbyB

Reply | Quote

gborn wrote:

Using a SSD drive and Windows in combination with Bitlocker to encrypt sensitive information isn’t a good idea at all.

On self-encrypting drives (SEDs) only?

Windows 11 Pro version 22H2 build 22621.2361 + Microsoft 365 + Edge

Reply | Quote

I don’t think the Bitlocker offered in Pro and Ultimate versions of 7 is able to use the self-encryption features on hard drives/SSDs.  If you’re using Bitlocker in 7, you should be good to go without doing anything.

In addition, not all drives tested by the people who reported this vulnerability were shown to be susceptible.

The self-encrypting protocol used by Bitlocker is Opal, and that was only shown to be vulnerable in the Crucial MX100 and MX200, not the MX300 or Samsung’s 840 Evo or 850 Evo.  Those were the only drives tested for Opal vulnerability, and 60% of the drives they did test didn’t have the vulnerability.

IMO, it’s a bit early to press the panic button if you aren’t using one of the drives shown to be vulnerable.  Self-encryption is far faster than software encryption, and switching to software encryption would be a real shame if you end up having a drive that isn’t vulnerable to the flaw in the first place. Re-encrypting an entire drive full of data could take a very long time, and so would putting it back after you find out that your drive was never/is no longer vulnerable.

In the meantime (that is, until we get more info about which drives are vulnerable), you can take measures to protect the most sensitive data on your SED.  If you use Windows Pro or Ultimate (any of the currently supported versions), which you do if you’re using Bitlocker in the first place, you can use the encrypting file system (EFS) to protect any file you wish (be careful with it, as with any encryption.  If you lose the login credentials, your files are as good as gone).

If you use a Home version of Windows, there are other solutions that others (and the articles about this vulnerability) have mentioned, like Veracrypt.

On my possibly-not vulnerable Samsung 860 Evo in my Swift (in ATA password mode, but with the master password set), I’m using my Linux desktop environment KDE’s vault feature, which is very easy to use, and has a lot in common with programs that are available on Windows.  A lot of this applies just as much to Windows, with just some details differing.

My sensitive documents, email archive and my password databases, bookmarks, and browsing history files for Waterfox and Thunderbird are in a vault, with symbolic links (symlinks for short) in the respective profile directories pointing into the vault. That means I can just use the files the same as before as long as the vault is unlocked.  They appear to the system to be in their old locations because of the symlinks, but they’re really in the vault, and are completely inaccessible with it locked.

Symlinks are very common in the Unix-like world, but Windows does have them too, so you could do this same thing in Windows if you had a program to create the vault.

Those files I put into the vault are the files I’d least want to have out of my control. I could have instead put the entire profile for Waterfox and Thunderbird into the vault, but the rest of the stuff in the profiles is not sensitive, and there’s no need to take the speed hit in protecting it.

The rest of the system (outside the vault) is still protected by the self-encrypting feature, even if it is flawed.  Most threats are not determined attackers who are after you specifically… they’re opportunists who see a laptop and steal it.  More likely, they’re after the laptop itself, but they might also do a little identity theft if they can find something juicy.  A simple ATA password without encryption will foil most of them!

If and when I find out for sure that my 860 Evo drive is not vulnerable (or it is made that way with a firmware update), I can easily copy the files back into their original homes, overwriting the symlinks.

 

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

Reply | Quote

According to the Microsoft Security Guidance Advisory Bulletin, it is easy to determine if your BitLocker implementation is affected by this vulnerability.

Just run:
manage-bde.exe -status

Look at what value is listed as the Encryption Method field?

If it is “Hardware Encryption,” then your drive may be subject to this vulnerability.

If it is anything else, then you are already using software based encryption and so you are not vulnerable.

Reply | Quote