from Hacker News

Bypassing disk encryption on systems with automatic TPM2 unlock

by arjvik on 1/17/25, 3:00 AM with 129 comments

  • by staff3203 on 1/17/25, 5:22 AM

    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.

  • by rollcat on 1/17/25, 4:03 PM

    When I first read about TPM-based FDE on Linux[0], I was excited that the systemd guys were finally taking a step in the right direction - BitLocker/FileVault were standard on Windows/macOS for a long time by that point. FDE should be secure by default, dead-simple to set up (e.g. a checkbox in the installer that defaults to "enabled"), and painless for everyday use.

    [0]: https://0pointer.de/blog/brave-new-trusted-boot-world.html

    Then I read about the implementation details[0], and it's a complex bloody mess with an unending chain of brittle steps and edge cases, that are begging for a mistake and get exploited. So here we are.

    I'm convinced that "measure the kernel" into "measure the initrd" into "show login screen" is all it should take.

  • by acheong08 on 1/17/25, 4:12 AM

    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

  • by ARob109 on 1/17/25, 5:24 AM

    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 malicious init.

    LUKS for encryption and verity for integrity/verification.

  • by keeperofdakeys on 1/17/25, 5:15 AM

    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 decryption like dracut-sshd.

  • by blastrock on 1/17/25, 6:47 PM

    Very clever!

    I am the author of one of the older guides https://blastrock.github.io/fde-tpm-sb.html .

    I was wondering about the solution you propose which seems a bit complicated to me. Here's my idea, please tell me if I'm completely wrong here.

    What if I put a file on the root filesystem with some random content (say 32 bytes), let's name it /prehash. I hash this file (sha256, blake2, whatever). Then, in the signed initrd, just after mounting the filesystem, I assert that hash(/prehash) == expected_hash or crash the system otherwise. Do you think it would be enough to fix the issue?

  • by fguerraz on 1/17/25, 9:30 AM

    The "mitigation" itself is still not very safe if you're paranoid about governments or very motivated organisations. The extra step of checking PCR12 is performed by the initrd that you trust because it's signed by a private key that has probably leaked to every serious hacking corp / government. They can just boot their own signed initrd and kindly ask the TPM that will oblige.

    I personally replace the firmware certificates (PK, KEK, db, dbx, …) with my own and sign every kernel/initrd update, I also unlock my disks with a passphrase anyways, but I'm on the fence WRT if it's more secure than TPM.

    Yes in theory TPM key extraction is feasible (and even easy if it's performed by a chip other than your CPU https://pulsesecurity.co.nz/articles/TPM-sniffing ) but it is harder than filming/watching you type the passphrase or installing a discrete key-logger ?

  • by tommiegannert on 1/17/25, 7:28 AM

    Very nice exploit.

    So if you use this PCR state machine, the problem is that the step before initrd doesn't require the correct password to move the PCR forward? It accepts any password that decrypts the next stage, which didn't have its integrity verified here.

    Seems there are multiple ways of solving this, and adding integrity checks is only one. It could also let the TPM verify the disk decryption password (when it's needed.)

  • by kukrimate on 1/25/25, 1:10 PM

    Why does the initrd have to keep the PCRs the same after handing off to the root filesystem anyhow?

    Capping off the PCRs with any arbitrary value before execing into root would stop this.

  • by lxgr on 1/17/25, 8:26 PM

    > You are safe if you additionally use a pin to unlock your TPM

    Does the default configuration not somehow tangle a user-entered password to authentication against the TPM?

    That's still not perfect (i.e. how do you make PIN/password entry non-keyloggable), but anything else, in particular extending the trusted computing base to the entire kernel and the hardware it runs on and hoping that they will both be bug-free and impossible to impersonate, seems like a bad idea.

    The TPM is also in a much better position to properly velocity check PIN/password entries than the OS.

  • by huslage on 1/17/25, 5:19 AM

    The other option is to have an intrusion prevention switch or two in the case so the TPM locks itself in some way and the machine refuses to boot at all without some PKI attestation.

  • by honestSysAdmin on 1/18/25, 8:22 AM

    Long before UKI was a thing, this kind of attack was prevented by hardcoding into an EFI stub kernel the sha512 hash of a trusted initrd that would verify the cryptographic authenticity of the initrd that did the "heavy lifting" (mounting disks etc).

    We have had not just secure boot but had it better on Linux (and other Unix-like) systems for a very long time.

  • by varispeed on 1/17/25, 9:01 PM

    How do you deal with something like this in a NAS? There is no way to enter password during boot.

    If someone steals the NAS how easily can they get to the data? Assuming volumes are encrypted, but the are automatically mounted on boot?

    How to ensure the data is safe in case of theft.

  • by mateusz834 on 1/17/25, 11:06 AM

    Personally i would like a way to use TMP2 (with PIN) + password. (i.e. mode where PIN is derived from the password, but is also used to encrypt), so that i do not have to trust the TPM manufacturer.

  • by tiberious726 on 1/17/25, 4:16 PM

    TPM+PIN is pretty great, is a shame it's nearly never used.

  • by shitter on 1/17/25, 2:25 PM

    This is mitigated if your initramfs + kernel are measured into the TPM, right?

    Edit: never mind, I think it's still vulnerable.

  • by kopirgan on 1/17/25, 9:45 AM

    Any idea how this works in the Windows world with bitlocker? I hope it's not same vulnerability

    I recently changed motherboard on my laptop, had the bitlocker key if not I was told I'll have to reinstall Windows all over again.

    Even with the key, one must decrypt and re-encrypt.

  • by jdoss on 1/17/25, 5:26 PM

    Hah, my gist from 2022 is on this post as a "broken guide". I'd disagree in saying it is broken. It works just fine and I flat out say at the top to not use it if you are worried about a cold boot attack on your hardware.