Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's really annoying how none of these tools provide an easy way to activate the properly fast, zero CPU overhead hardware-based encryption that almost all modern SSDs can do, which also makes it work properly with DirectStorage, etc.

The only one I'm aware of that can do it is Bitlocker, but the setup is stupidly clunky for no reason (you even have to reinstall windows to activate it - wtf).

A while back I used a tool to do it manually called sedutil but it seems to be abandoned now and no longer works with modern processors.



> It's really annoying how none of these tools provide an easy way to activate the properly fast, zero CPU overhead hardware-based encryption that almost all modern SSDs can do, which also makes it work properly with DirectStorage, etc.

Because the situation is similar to Dr. House: All disks lie. An OS can't trust the quality of the encryption in modern SSDs, there is no way short of dedicated hardware and firmware reverse engineering to make sure it actually encrypts the data. And on top of that comes the issue with using the supposedly "secure" TPM for disk encryption, that in many cases can simply be sniffed on the communication bus [1].

The only way a disk encryption solution can reasonably guarantee security is if it either controls the whole stack (such as Apple's FileVault using the T2 coprocessor on Intel/built-in capabilities on M SoCs) or it does everything in ring 0 inside the OS.

[1] https://pulsesecurity.co.nz/articles/TPM-sniffing


> Because the situation is similar to Dr. House: All disks lie. An OS can't trust the quality of the encryption in modern SSDs

Why is this the job of the OS? If we trust the SSD ourselves, it should simply accept that and proceed using the API as intended. For example, there's no reason to suspect anything wrong with the latest Samsung SSDs, is there?

I've so far not understood the purpose of the TPM here. Why can't the key be derived off a password entered during boot? It's not necessary to involve a TPM at all.

It seems wild to even consider software encryption for the whole disk at the bandwidth and iops modern SSDs are expected to deliver.


> Why is this the job of the OS? If we trust the SSD ourselves, it should simply accept that and proceed using the API as intended.

Because in the event of the crypto being only for show, people might blame the software for not warning them.

> I've so far not understood the purpose of the TPM here. Why can't the key be derived off a password entered during boot?

The general idea behind using the TPM as a crypto HSM was to provide at least a basic protection against simple disk cloning, i.e. evil-maid attacks.

> It seems wild to even consider software encryption for the whole disk at the bandwidth and iops modern SSDs are expected to deliver.

CPUs are pretty fast these days at anything crypto, as virtually all popular architectures have native AES instructions.


The fact that no one else trusts it is good enough reason not to use it. Crypto always starts out untrusted as there is no way to prove it's secure. Only by standing the test of time with widespread use does it gain at least a relative advantage.


SSD based encryption implementations are often highly insecure and should never be used. Many drives don't even use the given password to encrypt the data on the disk, meaning that flashing the controller with a modified firmware with the password validation patched out will let anyone decrypt the data without needing to know the password. https://www.ieee-security.org/TC/SP2019/papers/310.pdf


Well that's disappointing.


Microsoft actually used the disk encryption scheme by default in early versions of bitlocker. They had to backtrack because the disk encryption implementations were found to often not work at all!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: