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

21–30 of 113 posts

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

#21

Post by gbear605 »

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…

I’m sure that the Department of Defense would like to know if you have proof that some of their security measures are backdoored!

https://www.pof.usace.army.mil/Portals/35/docs/About/Our%20O...

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

#22

Post by tjoff »

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…

What surprised me was that bitlocker could make use of it. I always assumed that software encryption would be much safer but I had no idea that the in-device hardware encryption could be leveraged by software.

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

#23

Post by zAy0LfpBZLC8mAC »

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…

> This challenges the view that hardware encryption is prefer-able over software encryption.

WAT? Who ever thought that? For exactly the reason you state, I certainly would not have recommended anyone to ever trust "hardware encryption". And it's not just that firmware tends to be terrible: We had plenty of "secure storage" thingies that weren't.

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

#24

Post by Skunkleton »

dogma1138 wrote: post #19
Skunkleton wrote: post #8

Earlier quoted context omitted.

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.

The attack surface of windows is many orders of magnitude larger and also includes the attack surface of the CPU itself. It is _much_ easier to do a good job securing simple firmware.

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

#25

Post by yellowapple »

nly wrote: post #20

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, prop…

Yep, yep, and yep. I've said it enough to sound like a broken record:

Transparency is a dependency of trust.

If you can't see how it works, then it's objectively impossible to trust it to do the right thing. This applies to everything on a computer, really. Is your browser transparent? Is your operating system transparent? What about the drivers? Device firmware? That "security" solution that unexpectedly ushered in the Year of the MINIX Desktop™?

Of course, we sacrifice some of those points in favor of pragmatism, but if you ain't paranoid about your computer's lack of transparency, you should be.

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

#26

Post by yellowapple »

wmf wrote: post #17
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.

"although one would hope those are actually secure considering how much they charge for it"

Considering BitLocker requires a Windows purchase (unless you pirate it) and LVM costs exactly $0, I think it's safe to say that the amount of money thrown is not a good indicator of actual security.

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

#27

Post by yellowapple »

Skunkleton wrote: post #24
dogma1138 wrote: post #19

Earlier quoted context omitted.

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.

The attack surface of windows is many orders of magnitude larger and also includes the attack surface of the CPU itself. It is _much_ easier to do a good job securing simple firmware.

And yet that still seems to be quite difficult, as evidenced by this very paper.

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

#28

Post by nly »

yellowapple wrote: post #25
nly wrote: post #20

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, prop…

Yep, yep, and yep. I've said it enough to sound like a broken record: Transparency is a dependency of trust. If you can't see how it works, then it's objectively impossible to trust it to do the right thing. This applies to everything on a computer, really. Is your browser transparent? Is your operating system transparent? What about the drivers? Device firmware? That "security" solution that unexpectedly ushered in…

It's not really about vendors being malicious. It's just that both the carrots and the sticks involved in providing secure products are weak. You can slap a "Uses 256-bit military grade encryption" sticker on your product, pull some half-arsed home-baked crap and make more money. When someone exposes you you just go "Darn, those hackers... ruining things for good everyday folk"

It's an attitude problem. Most people wouldn't buy a glass house where people on the street could watch you shower and poop, but that's what we have in tech.

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

#30

Post by Skunkleton »

yellowapple wrote: post #27
Skunkleton wrote: post #24

Earlier quoted context omitted.

The attack surface of windows is many orders of magnitude larger and also includes the attack surface of the CPU itself. It is _much_ easier to do a good job securing simple firmware.

And yet that still seems to be quite difficult, as evidenced by this very paper.

Sure. Security is hard.
Post reply on HN