Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bypassing disk encryption on systems with automatic TPM2 unlock

oddlama.org

Post reply on HN
Print view View original

21–30 of 136 posts

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#21

Post by coppsilgold »

_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

Passwordless TPM FDE effectively "pairs" your HDD(s) with the TPM module such that the data on the drive(s) is inaccessible without it or a strong LUKS password if added.

Using even a weak pin/password will allow you to both "pair" and "secure" assuming the TPM is configured to destroy the key on multiple failed attempts.

You should also add a strong (high entropy) LUKS password to allow data recovery in case the TPM chip is lost or the keys are destroyed.

Note that the bits of the encryption keys are present somewhere in the TPM and could in theory be extracted with an exploit or with scanning probe microscopy perhaps.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#22

Post by johnisgood »

_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

You do not even need to enter a password.

Use a randomly generated key. Retrieve it from an USB drive at boot (it does it automagically), which contains everything, giving you full plausible deniability without it. It means literally everything you need to boot up is on the USB drive, and if you so want it, you can use 2 separate USB drives.

This is for computers you have physical access to, of course. You will need to carry the USB disk if it is a laptop, but you choose: you want to enter a password (which by itself gives you no plausible deniability BTW), or you want plausible deniability and/or you don't want to enter a password. And while we are at it, laptops (and even desktops) today have SSD, and encryption and plausible deniability is different for an SSD, but again, you choose. Right tool for the job.

https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_enti...

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#23

Post by johnisgood »

udev4096 wrote: post #19
_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

It's just not practical. How are you going to manually enter the password for let's say 10 servers?

USB pendrive with random key, no need to enter anything and is more secure and gives you plausible deniability through many different means.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#24

Post by johnisgood »

mcny wrote: post #4
_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

> Entering a password on boot isn't even that much work It is on fedora. I wabt the latest packages and I want to install them with dnf offline upgrade but now I need to put in password twice once for the updates d again for next boot. If it is a server, I don't want to keep a monitor attached to it just to enter the password. I want the computer to just boot. There has to be a better way.

There is: https://news.ycombinator.com/item?id=42734841.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#25

Post by _blk »

sedatk wrote: post #8
_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

Because I don't expect a random thief to go to the lengths of identifying OS level vulnerabilities to bypass the login prompt in order to decrypt the disk contents. The potential gains for them are marginal compared to the time and effort spent there, not to mention technical expertise needed. I expect them to steal it, and if it's encrypted, just sell it for parts, or wipe it and sell it anew. Entering a password ca…

A weak password is always better than no password. It's like using a cheap lock on your door or not locking it. Practically, if a thief wants to get through he'll get through but your insurance and sentencing will look different.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#26

Post by webstrand »

mcny wrote: post #4
_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

> Entering a password on boot isn't even that much work It is on fedora. I wabt the latest packages and I want to install them with dnf offline upgrade but now I need to put in password twice once for the updates d again for next boot. If it is a server, I don't want to keep a monitor attached to it just to enter the password. I want the computer to just boot. There has to be a better way.

There is, I use kexec to boot a modified cpio containing the fde password, since cpio can be extended by concatenation. https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981...

It's the same technique grub uses to forward the FDE password to the initramfs after its own initial decryption (to read the kernel and initramfs). This works to reboot remote servers with FDE, without needing a vnc or earlyboot-sshd.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#27

Post by fulafel »

_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

Try having a chat with a HCI person. Or in a pinch ask a LLM to emulate one for you. It's a useful perspective to have for a lot of stuff.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#28

Post by XorNot »

keeperofdakeys wrote: post #10

You can mitigate this by including PCRs that sign the kernel and initrd, however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros. Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decry…

It's ridiculous that there's no software implementation to do this, it's a huge problem.

Auto update should be able to include the kernel, initrd and grub cmdline from the running system I have no idea what's holding this back since evidently code already exists somewhere to do exactly that.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#29

Post by logifail »

_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

> I don't understand why anyone would use passwordless disk encryption

You want to install and operate a device at a remote site with restricted (or no) VPN access and where you don't trust the local staff?

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#30

Post by tommiegannert »

Hakkin wrote: post #5
_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

If a disk is encrypted, you don't have to worry about the contents if you eventually have to RMA or dispose of the disk. For this use case, it makes no difference how the encryption key is input.

I'd guess the most common scenario is for someone giving away the entire computer, not fiddle with components. Or theft of the full machine.

This feels like one of those half-security measures that makes it feel like you're safe, but it's mostly marketing, making you believe *this* device can be both safe and easy to use.

Post reply on HN