Hacker News Reader

Hacker News

Comment by rasengan | Hacker News Reader

Parent Full thread

rasengan

> TPM-backed full-disk encryption

This is going to be very useful for servers hosted in third party DCs.

View on HN

Keeping the key in the same room as the padlock only protects against casual drive theft and secure disposal.

Personally I'm more worried about someone stealing the entire server or a local threat actor.

Sure, keep TPM to help with boot integrity, maybe even a factor for unlock, but things like Clevis+Tang (or Bitlock Network Unlock for our windows brethren) is essential in my opinion.

TPM locking is for ensuring the disk isn't removed from your machine. It's technically possible that someone could tap the hardware while the disk is still in your machine, but otherwise they're stuck contending with whatever other security setup you have on your machine.

The TPM locked disk encryption is more like embedding your safe in concrete with deep foundations. It doesn't affect the thickness or quality of your safe.

The beta installer was completely unsuccessful in setting the TPM-backed disk encryption on both a ThinkPad X1 Carbon (Intel 258V) and a ThinkPad P14s (AMD 300-something). Hopefully they ironed that part out in the release, but it seems still early for this feature (at least for my comfort level).

Same on my Framework Desktop. Looks like it works only with a limited number of TPM chips for now.

The constructed policy is quite strict and expects certain UEFI things to be set up correctly. For example both this https://github.com/canonical/secboot/blob/7434bac27844362ff8... and https://github.com/canonical/secboot/blob/7434bac27844362ff8... are enabled in the policy. The policy choices and various early checks, even as trivial as confirming that the TCG log content is correct after booting into installation system, are enough to rule out a lot of potentially problematic EFI deployments. Effectively making it more strict helps avoid a lot of funny issues where the firmware is clearly buggy and things would fall apart sooner or later.

Strict is probably good. My company started to enable bitlocker this year on win11, and a non trivial amount of initial encryptions seem to be failing, destroying the user data and requiring a full reformat.

I want this on my own homeserver. Protection against someone stealing the server without requiring me to type a password every boot.

In what way is TPM protecting your data if someone steals the entire server? TPM only ensures that the boot environment has not been modified. Whatever key is being used to automatically decrypt the disk would be in the clear.

Unless I'm misunderstanding your situation, I think you should look up the "Evil Maid Attack" to better understand how to mitigate risk for your threat model.

assuming there are no bugs in linux and you enable full memory encryption in BIOS, it protects you in the same way the FBI cant get into a locked iphone they physically posess

but linux is not as secure as an iphone, and linux users typically dont know how to set this up, so in practice you are right, it doesnt protect you

My threat model is a junkie breaks in to my house and flips my server on facebook marketplace. Then the buyer curiously pokes through my hard drives. Of course if protecting against government agencies is the threat model then TPM alone isn't enough.

For me, a zero friction way to have decent security is worlds better than the normal state where homeservers are not encrypted at all.

I just don't understand where the protection comes from if you have automatic password entry. If the thief boots up the server it is just as convenient for them as it is for you.

Your threat model is the same as my use of a laptop: regular LUKS with a password is enough on its own. Add TPM if you want to know that you're entering your password in a secure boot environment (ie. protect against a fake LUKS screen that steals your password).

Because you'll boot up in to a password prompt. So you'd need a password bypass exploit to get in. If you attempt to change the boot device or kernel the TPM won't release the key.

Yes, but not by automating the password process. You could probably do some sort of remote authentication with a custom iniramfs that will "phone home" for a key but that initramfs, even if signed and protected from tampering, is still exposing the authentication end point.

The attacker would just need to spoof the request to gain the key.

oh man i hope this works on dell laptops

Reply on news.ycombinator.com