Hacker News Reader

Comment by michaelt | Hacker News Reader

> I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least.

I think the target market is "I have a server in a data centre, I need unattended boot, I don't really need a high grade of security I just need to tick a checkbox saying the hard disk is encrypted"

If your organisation is large enough to start losing track of entire servers, and yet small enough you can't adopt effective organisational controls to prevent such losses, even mediocre encryption might give you some peace of mind - and it lets you avoid reporting data breaches, as the lost data was 'encrypted'.

View on HN

Looks like so. From https://rogueai.github.io/posts/arch-luks-tpm/#unlock-the-lu... 'From a security point of view, passwordless LUKS unclocking might look like we’re giving up some security, as booting will go straight to login without asking any password whatsoever. We’re indeed trading a bit of security in favour of convenience, it’s important to note though that binding the LUKS to the TPM ensures the volume will only unlock in our machine, with Secure Boot enabled and our signed boot image.'

So there we are somewhat breaking 'Secure Boot' process in general.

Another potential use is encrypted root with home directories subsequently requiring login password to decrypt (using pam_ecryptfs, pam_mount, etc). Less secure than root fe needing a PIN/password but can still defend against some threat models.

It's not a totally meaningless check box. If the key for decrypting the disk is in the TPM, this fixes the case where the drive gets pulled and thrown in a recycle bin, then someone recovers data from it later.

> this fixes the case where the drive gets pulled and thrown in a recycle bin

Also allows you to do that when you retire a server or cluster. I've been in situations where we had to wipe hundreds of multi-TB hard drives. If you've never done it, that takes a good deal of time. You can get appliances that do it, or try to build your own DBAN rig, but it still takes days. Or you can just shred them, but hard drive shredders are not cheap either, and that's rather wasteful and may not be environmentally conscious.

Yes, when I say "small enough you can't adopt effective organisational controls" I mean organisations that are large enough that they're discarding so many disks they might accidentally forget to wipe some, and yet small enough they don't have procedures and record-keeping that prevent such accidents.

A large organisation will usually have tedious checks and record-keeping for wiping and discarding hardware, probably instituted after they wiped and discarded the wrong hardware.

It is not about forgetting to wipe a disk. A realistic scenario is that an SSD fails in a way that it ceases to be recognized by the system. At this point, you have no way to wipe it. Still, you may be required to return it to the vendor (by the contract that gave you the discounted price in the first place) - and they can read it using their tools not available to mere mortals.

In addition to sibling replies, I'll add that a common important use for encryption (and reason to have it be completely standard 100% of the time, even in fully transparent mode) is storage EOL procedures. It's much easier/cheaper/safer to get rid of an HDD or SSD and feel confident everything is gone if it was all fully encrypted from the beginning and you just need to trash the key.

The threat vector mitigated by Clevis[1] is someone with physical access (e.g. an insider) removing the server from the data center and being able to access its data.

[1] https://github.com/latchset/clevis

I don't see any discussion of threat vectors on that page, but Clevis clearly fails to mitigate the threat vector you describe.

You can't read encrypted data without the key

Reply on news.ycombinator.com