> 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...

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

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

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.

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...

Does this affect Linux, LVM, or LUKS?

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

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?

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

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.

There may not be an IO performance disadvantage to using Intel AES-NI for dmcrypt, versus in-hardware (in the drive). But there is a CPU performance impact when using it. I see ~22% x4 thread (~88% CPU out of 400%) for kcryptd processes when fully utilizing reads or writes for a single laptop hard drives at ~140MB/s with an Intel Pentium N3700 in an Intel NUC. That's obviously not a very substantial CPU. But it is nevertheless a fairly substantial CPU hit. The spare CPU cycles are available so it doesn't have an actual impact on this system.

Anyway, neither kernel fscrypt, nor dmcrypt have any dependency on drive embedded crypto. They do use AES-NI or equivalent, if available and if that support is compiled into the kernel.

Detail output from top while doing a scrub on a LUKS encrypted system. (Expires in 7 days.) https://paste.fedoraproject.org/paste/IvXs0f-N2~qN-k32Z2Y~yA...

> The question is whether or not other full-disk encryption implementations defer to on=device encryption hardware if present.

dm-crypt (of which LUKS is a part) certainly does not do that.

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.

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

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

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

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

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