
Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf] - luu
https://www.ieee-security.org/TC/SP2019/papers/310.pdf
======
zaroth
> _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...](https://www.zdnet.com/google-amp/article/flaws-in-self-encrypting-
ssds-let-attackers-bypass-disk-encryption/)

[2] - [https://www.pcworld.com/article/3441864/bitlocker-windows-
bu...](https://www.pcworld.com/article/3441864/bitlocker-windows-built-in-
encryption-tool-no-longer-trusts-your-ssds-hardware-protection.html)

~~~
spzb
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

------
tenebrisalietum
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
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...](https://www.malwaretech.com/2015/04/hard-disk-firmware-hacking-
part-1.html)

------
inetknght
Does this affect Linux, LVM, or LUKS?

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

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

~~~
cmurf
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...](https://paste.fedoraproject.org/paste/IvXs0f-N2~qN-k32Z2Y~yA/raw)

------
annoyingnoob
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
Is there strong reason to believe a company would design and implement SSD
hardware encryption twice?

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

