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

61–70 of 136 posts

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#61

Post by deno »

prmoustache wrote: post #45
dangero wrote: post #7

Earlier quoted context omitted.

Depends on the use case. If boot requires a password, the computer can never lose power or be rebooted without human presence. That’s not always practical.

That is what remote kvm are for and if you do that on commodity hardware you can start a tiny ssh server starting up from an initrd. Having said that an attacker with local access could change the initrd without your knowledge so that it logs the password you enter so it is not necessarily the most secure solution.

You’ve answered it yourself. Without TPM you have no idea if you can provide the secret to the system or if it’s compromised. Whether that secret comes from TPM or network is secondary.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#62

Post by nh2 »

artiscode wrote: post #33
logifail wrote: post #29

Earlier quoted context omitted.

> 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?

A remote KVM, i.e TinyPilot will help avoid dealing with lack of trust in local staff. Additionally connection to the KVM can be done over LTE/Cellular if you don't trust the local connection too.

How does this make sense?

Any change the untrusted local staff could make to the server, they could also make to the KVM machine (e.g. turn it into a keylogger).

Now you have the same problem but with a smaller computer.

You cannot turn untrusted systems into trusted systems by adding more untrusted systems.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#63

Post by oddlama »

staff3203 wrote: post #12

On my system, I used `tpm2-measure-pcr=yes` in `/etc/crypttab.initramfs`, then used `--tpm2-pcrs=0+2+7+15:sha256=0000000000000000000000000000000000000000000000000000000000000000` with `systemd-cryptenroll`. As soon as a volume is decrypted, initrd will write `volume-key` to PCR 15, so any further executables can no longer access the data stored in the TPM.

This is great if you only have a single disk, but if you have multiple encrypted disks that are unlocked in the initrd this way, then if you can gain control flow by faking data on the last decrypted disk you can still gain access to all the previously unlocked partitions.

Of course you cannot unseal the secret from the TPM anymore.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#64

Post by nick__m »

prmoustache wrote: post #44
sedatk wrote: post #8

Earlier quoted context omitted.

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…

> Entering a password can be a lot of work if you use a strong password (and if you don't, why bother with a password?). So does-it means you do not setup a password/passphrase for your user account?

I use auto login (control userpassword2 still work to set that up on Windows11) on my gaming computer in the living room! If I could that user account wouldn't have a password.

But my work computers requires a pin to boot and a password that only my yubikeys (bind the static password to the long press) knows to login. different policy for different context...

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#65

Post by teddyh »

dangero wrote: post #7
_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

Depends on the use case. If boot requires a password, the computer can never lose power or be rebooted without human presence. That’s not always practical.

You can reboot your full-disk-encryption server while you sleep. Obligatory plug: https://www.recompile.se/mandos>

Disclosure: I am a co-author of Mandos.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#66

Post by ChocolateGod »

ARob109 wrote: post #13

Seems like this could be easily mitigated with a read only root filesystem using dm verity Store the root hash of the dm verity formatted rootfs in the PCR. If a malicious partition is presented to initrd, its root hash will not match the trusted one stored in the TPM. Or if you need a writeable rootfs, use fs verity and store the signature of init into the PCR. The trusted init signature won’t match signature of mal…

> If a malicious partition is presented to initrd

The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.

I know Fedora has been musing with shipping prebuilt initrds, but it raises problems with things like Nvidia where you need the driver to be in the initramfs to have a proper boot screen. There's also UKIs that have the kernel + initramfs in the same EFI binary (and thus signed) for booting by secure boot, but they can become too big for the small EFI partition computers ship with.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#67

Post by [deleted] »

megous wrote: post #41
Hakkin wrote: post #5

Earlier quoted context omitted.

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.

Encrypted data are noise now, maybe, but may be decryptable in the future with advances in computing. So all this depends on what you worry about.

[deleted]

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#68

Post by HPsquared »

megous wrote: post #41
Hakkin wrote: post #5

Earlier quoted context omitted.

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.

Encrypted data are noise now, maybe, but may be decryptable in the future with advances in computing. So all this depends on what you worry about.

Most of this concern is around certain public key cryptography algorithms which depend on math problems being extremely hard to solve but could in theory be mathematically solved (decrypted without the key) with a good enough quantum computer.

Disk encryption (AES etc) is symmetric and still only brute-force would work which can be made infeasible with a long enough key.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#69

Post by prennert »

teddyh wrote: post #65
dangero wrote: post #7

Earlier quoted context omitted.

Depends on the use case. If boot requires a password, the computer can never lose power or be rebooted without human presence. That’s not always practical.

You can reboot your full-disk-encryption server while you sleep. Obligatory plug: https://www.recompile.se/mandos > Disclosure: I am a co-author of Mandos.

Has this solution been audited? In particular, is it safe to replay attacks by actors listening in to the network traffic?

Also from the diagram it looks like the secret key is stored unencrypted on the server, or do I read it wrong?

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#70

Post by bean-weevil »

oddlama wrote: post #63
staff3203 wrote: post #12

On my system, I used `tpm2-measure-pcr=yes` in `/etc/crypttab.initramfs`, then used `--tpm2-pcrs=0+2+7+15:sha256=0000000000000000000000000000000000000000000000000000000000000000` with `systemd-cryptenroll`. As soon as a volume is decrypted, initrd will write `volume-key` to PCR 15, so any further executables can no longer access the data stored in the TPM.

This is great if you only have a single disk, but if you have multiple encrypted disks that are unlocked in the initrd this way, then if you can gain control flow by faking data on the last decrypted disk you can still gain access to all the previously unlocked partitions. Of course you cannot unseal the secret from the TPM anymore.

If you have tpm encryption on your boot disk, then you can simply store decryption keys for your otyer disks on it.
Post reply on HN