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

https://www.ieee-security.org/TC/SP2019/papers/310.pdf

by luu • 7 years ago

65 18 7 years ago

I may have missed it, did they test any Intel drives?

Edit: Looks like the models they chose to test are consumer oriented products. I'm more interested in enterprise oriented products. They didn't cover any drives that I actually use in the encrypted laptops that I deploy.

willis936• 7 years ago

Is there strong reason to believe a company would design and implement SSD hardware encryption twice?

yjftsjthsd-h• 7 years ago

They frequently do the rest of the hardware and software separately for consumer and enterprise, so it seems like a reasonable extrapolation.

annoyingnoob3• 7 years ago

They didn't cover any products from manufacturers I actually use. In my experience, consumer products can be quite different from enterprise products.

ComputerGuru• 7 years ago

Depending on the company, enterprise and consumer divisions might be totally separate from A to Z. (But I agree with you.)

bayindirh• 7 years ago

Yes. Compliance with some MIL-xxx and FIPS-xxx specs come into my mind.

zaroth• 7 years ago

BitLocker, the encryption software built into Microsoft Win- dows will rely exclusively on hardware full-disk encryption if the SSD advertises support for it. Thus, for these drives, data protected by BitLocker is also compromised.

I thought BitLocker stopped trusting SEDs after the last time around when drives were discovered to be trivially broken? [1]

But apparently this change only just happened a couple months ago. [2]

[1] https://www.zdnet.com/google-amp/article/flaws-in-self-encry...

[2] https://www.pcworld.com/article/3441864/bitlocker-windows-bu...

spzb• 7 years ago

This appears to be the same paper as in your first link. It was a draft at the time and now appears to have made it to a conference presentation.

Edit: In fact the conference was in May so about six months after the first story based on the draft version. Not quite sure why it's hitting HN front page now

isido• 7 years ago

I think this is the published paper which contains the same vulnerabilites mentioned in the first link.

inetknght• 7 years ago

Does this affect Linux, LVM, or LUKS?

annoyingnoob3• 7 years ago

It affects the hardware encryption of the drives themselves, the issue is independent of the OS.

yborg• 7 years ago

The question is whether or not other full-disk encryption implementations defer to on=device encryption hardware if present. As the paper notes, with the advent of embedded AES instructions in Intel processors, there is little or no performance advantage to doing so, and given the near-certainty that a crypto implementation done by a company or group that isn't a crypto-specialist is going to be flawed, it will likely compromise security to do so.

LinuxBender• 7 years ago

No. LUKS or dm-crypt are independent of hardware encryption. LVM is just volume management and is orthogonal to encryption.

KingMachiavelli• 7 years ago

From the attack model this is looking at no; cold storage LUKS encryption is safe.

The downside of having encryption done on the CPU is that it has a max throughput and latency burden (even with AES acceleration) which isn't a problem for SATA devices (both HDD & SSD) but it is with new high-end NVMe drives that can see througput in excess of 1GB/s.

On the other hand, LUKS still has it's own attack methods when a volume is opened (cold->hot). If the keyfile/password is stored on a seperate drive or entered manually, the interface (USB keyboard, SATA connection, motherboard chipset, etc) could be exploited to retrieve the key in cleartext. If the key is stored or tied to the machines TPM, then it's up in the air as to wheter Intel/AMD + the motherboard's manufacture didn't leave a flaw somewhere. i.e How much more secure is the mobo/CPU TPM than the OPAL/ATA based encryption found on these drives?

tenebrisalietum• 7 years ago

Self-encrypting drives are great for liability-offload situations like fulfilling enterprise or statutory requirements as cheap as possible, but not great if you actually truly want to protect the data.

If you can't see the final data after encryption, you have no way of verifying if it was actually done or how well it was done.

Nothing short of a standard SSD platform with independently removable, externally readable/writeable, and installable firmware and flash modules would completely satisfy that requirement though. It'd be interesting to have but certainly cost prohibitive.

kjs3• 7 years ago

Yup, and I've been telling my clients for years that it's just a checkbox exercise. No one really does key management well in the first place for self-encrypted drives, and when people started publishing things like [1], it was clear the game was up.

For circumstances where the data is genuinely sensitive, we've pushed for physical destruction of the drive. Bonus: throwing pallets of old drives into the incredibly loud shredder our destruction partners use is a lot of fun.

[1] https://www.malwaretech.com/2015/04/hard-disk-firmware-hacki...

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

Related Stories