Arch Linux

avi9526

Member

Registered: 2015-05-15

Posts: 125

[SOLVED] LUKS drive auto unlocked by TPM when expected not to

I had my auto unlocking being broken for a long time. Tried to fix it without success. TPM2 unlock just didn't work. After playing with BIOS settings (clearing secure boot keys and etc) it suddenly started working. Problem is - i'd expect it to fail.

cryptsetup luksDump header.img
…
Tokens:
  0: systemd-tpm2
        tpm2-hash-pcrs:   0+7
…

and while playing with BIOS secure boot settings I was monitoring PCR 7 with

systemd-analyze pcrs

each boot this value changed (because I've changed secure boot setting in BIOS), yet each time disk was auto unlocked. I've read wiki and articles and know that TPM and LUKS is problematic, but this look utterly unsafe. What is going on?

Last edited by avi9526 (2026-06-05 16:48:33)

cryptearth

Member

Registered: 2024-02-03

Posts: 2,257

Re: [SOLVED] LUKS drive auto unlocked by TPM when expected not to

TPM != secure boot

secureboot: regular x509 chain just to verify signature of the chain up to the kernel to the systems root key
TPM: a device to meassure and compare a systems state
they both usually work independent of eachother

enable secureboot without proper chain just causes the boot to fail - while the tpm isn't affected by this as it more or less just checks: "hey, is this still the hardware as last time - and is it unmodified?"
I don't know if "is secureboot enabled?" can even be meassured for tpm auto-unlock - but it likely isn't in any default

avi9526

Member

Registered: 2015-05-15

Posts: 125

Re: [SOLVED] LUKS drive auto unlocked by TPM when expected not to

I have identified the problem. It appears that I have created it myself. You can notice that I use a detached luks header, but since /boot is not properly available at the time of unlocking the copy of the header must be built into initramfs image. So any change to actual header require "mkinitcpio" afterwards.

sbctl status
…
    Setup Mode:     ✓ Disabled
    Secure Boot:    ✓ Enabled
…

systemd-cryptenroll --wipe-slot=tpm2 Header.img
systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 Header.img
mkinitcpio -p linux…
reboot
…
PROFIT

Now LUKS auto unlock works when secure boot enabled and not does not work when secure boot altered (disabled, keys changed, etc)

Header being built into initramfs means I cannot use PCR9 that hashes initrd image, because I need to store hash of initrd inside initrd, which is practically impossible. Shame.

Last edited by avi9526 (2026-06-05 16:48:24)

Strike0

Member

From: Germany

Registered: 2011-09-05

Posts: 1,491

Re: [SOLVED] LUKS drive auto unlocked by TPM when expected not to

You don't explain why you use a separate header, but have a look if the new pinning feature let's you use defaults.

avi9526

Member

Registered: 2015-05-15

Posts: 125

Re: [SOLVED] LUKS drive auto unlocked by TPM when expected not to

You don't explain why you use a separate header, but have a look if the new pinning feature let's you use defaults.

I will take a look, thnx

Separate header is somehow pleasant to me:
1) it is easy to backup and fallback, there is 3 backups of header lying in my /boot
2) it is unix-way - as it is file
3) it corresponds to idea that data must be separated from non-data
4) such encryption could be removed/enrolled in the raw way due to the fact that encrypted data is aligned to un-encrypted data [https://unix.stackexchange.com/a/130998/67899]
5) it could be argued that encrypted partition without header is no more than just random data, actual situation depends on how close the government soldering iron to your backdoor

Last edited by avi9526 (2026-06-13 20:03:37)

Strike0

Member

From: Germany

Registered: 2011-09-05

Posts: 1,491

Re: [SOLVED] LUKS drive auto unlocked by TPM when expected not to

Regarding your points:
1) Backup, yes, but backups kept on the same device are not always helpful; just saying.
4) Don't follow that old post; follow the manual of cryptsetup-reencrypt to decrypt or reencrypt, or the wiki page on it.
5) One could argue that in case the /boot is not on the same machine. This in turn implies the machine boots usb - which must be physically secured, and the machine's primary protection is a bios password, instead of secure boot.