Bypassing disk encryption on systems with automatic TPM2 unlock
48 comments
·January 17, 2025kopirgan
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.
ARob109
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.
yx827ha
That's how ChromeOS does it. https://m.youtube.com/watch?v=iO6cb90WiQ4
ARob109
Android too in a way via Android Verified Boot. I think ChromeOS uses AVB as well.
Android Verified Boot extends the System on chip Hardware based secure boot to the kernel and rootfs. Root of trust is fused into the SoC, and second stage bootloaders are signed. Second stage boot loader eg uboot,UEFI/edk2 contains a public key that is used to verify a signed AVB partition. This signed partition contains signed rootfs dm verity metadata and signed hash of the kernel(+initrd). AVB validates kernel hash with expected hash and loads kernel if good. It provides the trusted rootfs verity hash to kernel via cmdline. Then when kernel reads rootfs, the dmverity system will calculate hash and check if matches the expected one. If not, the system reboots and the AVB metadata is flagged to indicate tampering/failure of the rootfs.
edit to add: If the SoC supports hardware based full disk encryption, the filesystem can be encrypted as well, with the key being stored in Androids secure key store. Android though has moved away from FDE in favor of file based encryption.
bigfatkitten
The ingredients are there as Chrome OS and Android have shown, but robust hardware-bound disk encryption has just never been a priority for the general purpose distros.
staff3203
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.
usr1106
Yes, that seems a good extra level of defense. Allow unsealing only once. We extend a PCR with random data.
acheong08
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
Hakkin
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.
tommiegannert
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.
megous
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.
sedatk
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 can be a lot of work if you use a strong password (and if you don't, why bother with a password?). Typos can take a toll too because of all the delays included.
prmoustache
> 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?
_blk
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.
dangero
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.
prmoustache
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.
tucnak
Google: IPMI, BMC
pclmulqdq
On servers, it protects against someone stealing your disks (or stealing the raw bytes from your disks) and then booting them in a copy of your machine.
mcny
> 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.
prmoustache
I also use a fedora.
Typically I use offline upgrade if I mean to poweroff but otherwise I just run `sudo dnf update -y && sudo systemctl reboot` in a terminal if I want a quick update&reboot.
On another laptop I am using silverblue (well bluefin) and the atomic upgrades solve the issue completely.
keeperofdakeys
> There has to be a better way.
Probably Clevis and Tang, network disk decryption that can only decrypt if most of your servers are online. https://github.com/latchset/clevis https://github.com/latchset/tang
Or network decryption (SSH into initrd). https://github.com/gsauthof/dracut-sshd
webstrand
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.
bpye
Is the boot time password unlock occurring in GRUB or after the Linux kernel has started? If the latter you should be able to setup an SSH server to run in that early boot environment, that’s how I can remote unlock drives on NixOS.
logifail
> 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?
artiscode
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.
logifail
I set up a server last year which is at a remote site which is completely air-gapped from the Internet, it's allowed to see one local LAN and that's all. For any kind of admin task someone has to drive to site.
There is precisely zero chance that the relevant IT security goons would allow any kind of remote KVM/LTE connection.
coppsilgold
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.
johnisgood
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...
keeperofdakeys
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.
Vogtinator
> You can mitigate this by including PCRs that sign the kernel and initrd.
No, that's not an effective mitigation. The signed kernel+initrd would still boot into the impersonated root.
> 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.
With some logic to update the values on kernel updates and re-seal the secret this can be handled transparently. That's the design with sdbootutil in openSUSE (https://en.opensuse.org/Systemd-fde, https://github.com/openSUSE/sdbootutil).
jansommer
You can use tpm2_policyauthorize and allow the PCR to change without having to manually unlock. This was not supported in TPM 1.2.
You can use it with Systemd.
https://github.com/tpm2-software/tpm2-tools/blob/master/man/...
saljam
> You can mitigate this by including PCRs that sign the kernel and initrd
nope! the trick the article is describing works even if the kernel and initrd is measured. it uses the same kernel, initrd, and command line.
the reason this trick works is that initrds usually fall back to password unlock if the key from the tpm doesn't work. so the hack replaces the encrypted volume, not the kernel, with a compromised one. that is:
1. (temporarily) replace encrypted volume with our own, encrypted with a known password.
2. boot the device.
3. the automated tpm unlock fails, prompting for a password.
4. type in our password. now we're in, using the original kernel and initrd, but it's our special filesystem, not the one we're trying to decrypt.
5. ask the tpm again for the key. since we're still using the original kernel, initrd, and command line, we should now get the key to unlock the original encrypted volume.
the way to fix this is to somehow also measure encrypted volume itself. the article points to suggestions of deriving a value from the encryption key.
XorNot
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.
Vogtinator
That's the design with sdbootutil in openSUSE (https://en.opensuse.org/Systemd-fde, https://github.com/openSUSE/sdbootutil).
tommiegannert
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.)
michaelt
> It could also let the TPM verify the disk decryption password (when it's needed.)
The design intent is basically:
1. The TPM is very sensitive, and errs on the side of not unlocking your disk.
Booting into recovery mode to fix a driver? Reinstalled your distro? Added a MOK so you can install the nvidia drivers? Toggled certain options in your BIOS? The expected-computer-state checksums are wrong, better not unlock the disk as it could be an attack.
2. When this happens, you key in the password instead.
You can't rely on the TPM to verify the manually entered password, as the intent of the manually entered password is to recover when the TPM is in a broken state.
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 ?