Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

zdnet.com

Post reply on HN
Print view View original

11–20 of 113 posts

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#11

Post by Lucent »

trulyrandom wrote: post #5

I did not know that BitLocker relies on hardware encryption if the SSD has support for it. That seems like an extremely dangerous default to have, especially as the implementation is closed source in most (all?) cases.

It's a very difficult process to turn on and isn't something that happens automatically. You must flip the bit using the SSD manufacturer's tool, reinstall Windows, and then enable BitLocker. Even then, it only works with a handful of SATA SSDs and maybe 2 NVMe SSDs with 1 or 2 motherboards.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#12

Post by mtgx »

trulyrandom wrote: post #5

I did not know that BitLocker relies on hardware encryption if the SSD has support for it. That seems like an extremely dangerous default to have, especially as the implementation is closed source in most (all?) cases.

In case it hasn't been obvious by now, BitLocker has been designed to be compatible with law enforcement requests. That means for one that the vast majority of Windows users will never see it work by default on their machines, as you can see encryption on Android and iOS devices. And second, most of those that do enable it, will be relegated to the broken and/or backdoored encryption of the OEMs.

Thirdly, BitLocker itself may have a backdoor, or at the very least Microsoft continues to design it in such a way that they (and law enforcement have or can get your private key for it, when needed). I remember a while ago people were complaining that BitLocker keys are automatically saved to their OneDrive account, where Microsoft of course can see it.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#13

Post by raesene9 »

In case you're wondering if this affects you (I know I was wondering) the relevant command to run is (in an elevated command prompt)

`manage-bde -status `

Then look at the output for "Encryption Method". If it says something like "XTS-AES 128" I think that means you're using software encryption. If it mentions hardware encryption, then it's using it :) (more info. https://helgeklein.com/blog/2015/01/how-to-enable-bitlocker-...)

FWIW on my Win 10 install with a Samsung PM871 it was set to software encryption.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#14

Post by Operyl »

mtgx wrote: post #12
trulyrandom wrote: post #5

I did not know that BitLocker relies on hardware encryption if the SSD has support for it. That seems like an extremely dangerous default to have, especially as the implementation is closed source in most (all?) cases.

In case it hasn't been obvious by now, BitLocker has been designed to be compatible with law enforcement requests. That means for one that the vast majority of Windows users will never see it work by default on their machines, as you can see encryption on Android and iOS devices. And second, most of those that do enable it, will be relegated to the broken and/or backdoored encryption of the OEMs. Thirdly, BitLocker i…

Can I see some citations for your first set of claims? Because I know some law enforcement officers would be very happy to learn this.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#16

Post by xoa »

exceptione wrote: post #3
DyslexicAtheist wrote: post #2

"We have analyzed the hardware full-disk encryption of several SSDs by reverse engineering their firmware. In theory, the security guarantees offered by hardware encryption are similar to or better than software implementations. In reality, we found that many hardware implementations have critical security weaknesses, for many models allowing for complete recovery of the data without knowledge of any secret. BitLocke…

I still think it's shocking, and I imagine a lot of companies and professionals rely on hardware encryption based on the presumption that it would be safer than software based encryption. I myself trusted the Opal-certification too. There was really no option for the vendors to stunt this feature. For me, this paper is rather alarming and should be on the front page.

It's genuinely interesting to hear this is the case. I mean, I don't disagree with you that it's important to have out in the open regardless. But I honestly just assumed from the start that Opal would just generally be a badly implemented feature checkbox not something dependable. For this case of crypto code it didn't seem trustworthy if it wasn't open, standard and trivially auditable. Unlike Apple for example these products don't have the kind of marketshare, clear public profile and constant open as well as covert attacks that would be necessary to grant a higher degree of confidence despite being closed, the barrier needs to be lower given the lower profile. So I've never used the hardware crypto in any SSD, it's always been through software on top, although in fairness that has become easier to do as AES-NI has become more universal in CPUs. That has given a lot of the assurance and speed of a dedicated hardware crypto chip while still using higher level software.

I guess in retrospect it's quite reasonable most people would trust it, or for that matter not think about it at all but rather trust Microsoft or whomever to be getting that right for them and that checking the FDE Box in the GUI would mean what it said. A good example of having personal blinders on for me, I'm too used to just ignoring Opal entirely since the day it was introduced.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#17

Post by wmf »

amarshall wrote: post #7

As far as I know, no other popular full-disk encryption (LUKS, geli, FileVault) delegates to the SSD’s hardware encryption (by default, anyway) as BitLocker apparently does [0]. Anyone know otherwise? [0]: https://docs.microsoft.com/en-us/previous-versions/windows/i...

Lots of enterprise SAN/NAS equipment uses SEDs, although one would hope those are actually secure considering how much they charge for it.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#18

Post by dogma1138 »

raesene9 wrote: post #13

In case you're wondering if this affects you (I know I was wondering) the relevant command to run is (in an elevated command prompt) `manage-bde -status ` Then look at the output for "Encryption Method". If it says something like "XTS-AES 128" I think that means you're using software encryption. If it mentions hardware encryption, then it's using it :) (more info. https://helgeklein.com/blog/2015/01/how-to-enable-bit…

I never used HW disk encryption (other than TPM) because I always seen it as unnecessary as in it doesn’t really improve on SW+TPM in terms of performance or compatibility and could only cause potential data recovery and security issues.

There is no performance benefit in fact with modern CPUs that have crypto extensions it’s often slower and I never trust commercial solutions ever since you could dump the key from the SanDisk/McAfee “secure” flash drives, and all previous HDD password protection schemes like the ATA passcode were so shit I didn’t even understood why people bothered with them in the first place.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#19

Post by dogma1138 »

Skunkleton wrote: post #8
trulyrandom wrote: post #5

I did not know that BitLocker relies on hardware encryption if the SSD has support for it. That seems like an extremely dangerous default to have, especially as the implementation is closed source in most (all?) cases.

But bitlocker itself is closed source. Why do you trust microsoft more than the disk vendor? Further, if I were going to choose an opaque blob to trust I would choose the one that has the smaller attack surface.

Because Windows due to its attack surface is much better researched and understood, Microsoft actually has a decent track record of investing in security and it can be patched.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#20

Post by nly »

Why would anyone be surprised about this?

If you can't read a whitepaper, and inspect the algorithm to a degree where you can create your own provably-compatible implementation, or easily inspect the vendors source code, then you should just assume it's implemented incompetently and is completely and utterly compromised.

The same goes for all cellular/mobile phone encryption standards, proprietary VPN solutions, proprietary DRM, crypto used in banking (Chip n Pin etc etc). All compromised. Period. Don't trust it. All crypto implementations should be guilty until proven innocent under serious peer review.

The same attitude should be taken with anything not encrypted. Yes your ISP is spying on your browsing habits, logging everything, and probably will one day sell that data. Yes your bank is analyzing your spending habits. Just assume it's happening. There's enough evidence out there now that this is the new reality.

Post reply on HN