> TPM-backed full-disk encryption

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

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.

	▲	aaravchen 2 days ago \| parent [-]
		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.

▲

djkoolaide 2 days ago | parent | prev | next [-]

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

▲

nechuchelo 2 days ago | parent [-]

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

▲

bboozzoo 2 days ago | parent [-]

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.

	▲	hyperman1 2 days ago \| parent [-]
		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.

▲

Gigachad 2 days ago | parent | prev | next [-]

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

▲

zenoprax 2 days ago | parent [-]

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.

▲

hfjtnrkdkf 2 days ago | parent [-]

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

▲

Gigachad 2 days ago | parent | next [-]

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.

▲

zenoprax 2 days ago | parent [-]

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

	▲	Gigachad 2 days ago \| parent [-]
		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.

▲

zenoprax 2 days ago | parent | prev [-]

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.

▲

senectus1 2 days ago | parent | prev [-]

oh man i hope this works on dell laptops