Decrypt LUKS volumes with a TPM on Fedora Linux

LUKS_and_TPM2_with_Fedora.md

Decrypt LUKS volumes with a TPM on Fedora Linux

This guide allows you to use the TPM on your computer to decrypt your LUKS encrypted volumes. If you are worried about a cold boot attack on your hardware please DO NOT use this guide with your root volume!

Preflight Checks

Verify that you have a TPM in your computer:

# systemd-cryptenroll --tpm2-device=list
PATH        DEVICE      DRIVER
/dev/tpmrm0 MSFT0101:00 tpm_crb

Note: If you have more than one TPM in your computer you will need to change --tpm2-device=auto to the exact TPM you want to use: --tpm2-device=/dev/tpmrm0 and rd.luks.options=tpm2-device=/dev/tpmrm0 in GRUB_CMDLINE_LINUX.

Verify that you are booted into SecureBoot.

# mokutil --sb-state
SecureBoot disabled

If you see that it is disabled you will need to enable it in the BIOS. You should enable SecureBoot before you start.

Note: Enabling SecureBoot will cause third party kernel modules (such as NVIDIA drivers) to fail to load. You can work around this by using something like this to automatically sign the drivers built by akmod.

If you use the RPM Fusion repo for NVIDIA drivers you can use their support for automatically signing locally built kmod with a self generated key.

Find your LUKS encrypted volumes

# blkid -t TYPE=crypto_LUKS
/dev/nvme0n1p3: UUID="0818cd36-a007-11ec-aaab-7c10c93c41b1" TYPE="crypto_LUKS" PARTUUID="c362bcd2-87"
/dev/nvme1n1p1: UUID="15bc3342-a007-11ec-a502-7c10c93c41b1" TYPE="crypto_LUKS" PARTUUID="e8ead241-02"

Enroll your encrypted volumes

# systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+2+4+7+8+9 /dev/nvme0n1p3
# systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+2+4+7+8+9 /dev/nvme1n1p1

This will ask for your volume's passphrase. If you'd like to automate this in a script you may set the PASSWORD environment variable to your LUKS passphrase.

When setting --tpm2-pcrs=0+2+4+7+8+9 the following items are these are validated at boot time:

0: System firmware executable
2: Kernel
4: Bootloader
7: Secure boot state
8: Cmdline
9: Initrd

PCR 0,2,4,7,8,9 verifies the firmware, kernel, bootloader, secure boot state, cmdline and initrd before releasing the decryption key. If you are using PCR 2 and multiple kernels you will need to enroll a key for each kernel. If you have updated the firmware, kernel, or bootloader, and cmdline then auto volume decryption on your next reboot will fail. As long as you have a password set on your LUKS volumes you will be prompted to have to enter it to decrypt them and you will need to wipe the old key and enroll a new key if anything changes.

Remove all TPM2 keys and enroll a new key

systemd-cryptenroll /dev/nvme0n1p3 --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=0,2,4,7,8,9
systemd-cryptenroll /dev/nvme1n1p1 --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=0,2,4,7,8,9

Edit /etc/crypttab

Add tpm2-device=auto,discard to the end of each LUKS device line in /etc/crypttab

# cat /etc/crypttab
luks-014aa5a6-a007-11ec-a054-7c10c93c41b1 UUID=0818cd36-a007-11ec-aaab-7c10c93c41b1 - tpm2-device=auto,discard
luks-0e9e99f6-a007-11ec-8130-7c10c93c41b1 UUID=15bc3342-a007-11ec-a502-7c10c93c41b1 - tpm2-device=auto,discard

Edit /etc/default/grub

Edit /etc/default/grub and add rd.luks.options=tpm2-device=auto to GRUB_CMDLINE_LINUX.

GRUB_CMDLINE_LINUX="rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 rd.luks.uuid=luks-014aa5a6-a007-11ec-a054-7c10c93c41b1 rd.luks.uuid=luks-0e9e99f6-a007-11ec-8130-7c10c93c41b1 rd.luks.options=tpm2-device=auto rhgb quiet rd.driver.blacklist=nouveau"

Recovery Key Enrollment (optional)

If you have a safe place to store a recovery key you can generate and add one for each LUKS volume. It will show the recovery key phrase on screen and generate a QR code you may scan off screen.

systemd-cryptenroll --recovery-key /dev/nvme0n1p3
systemd-cryptenroll --recovery-key /dev/nvme1n1p1

Verify and reboot!

Verify that you have the TPM added to the encrypted volumes:

# systemd-cryptenroll /dev/nvme0n1p3
SLOT TYPE
   0 password
   1 tpm2
   2 recovery
# systemd-cryptenroll /dev/nvme1n1p1
SLOT TYPE
   0 password
   1 tpm2
   2 recovery

and now you can reboot and your TPM should unlock your encrypted drives!

Sources:

• https://gist.github.com/chrisx8/cda23e2d1fa3dcda0d739bc74f600175
• https://bugzilla.redhat.com/show_bug.cgi?id=1976462
• https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html
• https://wiki.archlinux.org/title/Trusted_Platform_Module#systemd-cryptenroll
• https://man7.org/linux/man-pages/man5/dracut.conf.5.html
• https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html
• https://github.com/larsks/akmod-sign-modules
• https://rpmfusion.org/Howto/Secure%20Boot

I can't get it to work on my thinkpad T14 gen 1. It just shows my normal encryption passphrase prompt (not the recovery key but the original passphrase). Everything from the steps above goes correctly and systemd-cryptenroll /dev/nvme0n1p3 shows tpm2. Anyone experienced something like this?

EDIT: For anyone wondering: I had to re-run systemd-cryptenroll /dev/nvme0n1p3 --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=0,2,4,7,8 after the dracut -f. Now it automatically works.

This because you either did not run on or it failed for some reason during the UKI generation and the information to unlock the volume via this method was not included.
An other option is that one of the PCRS failed the TPM policy, resulting in the fallback passphrase encryption.

@Jarartur Also, FYI, I am not sure which systemd version you are using, but PCR 8 is not defined in systemd-cryptenroll's manpage, so you should not use it. Maybe PCR 9 would make sense, but you would have to re-enroll the TPM keys on each initrd update. Also, upon a bootloader update beacuse of PCR 4.

@Jarartur Also, FYI, I am not sure which systemd version you are using, but PCR 8 is not defined in systemd-cryptenroll's manpage, so you should not use it. Maybe PCR 9 would make sense, but you would have to re-enroll the TPM keys on each initrd update. Also, upon a bootloader update beacuse of PCR 4.

Please see comments 4717836 and 4761939 for an explanation why you should never skip PCR8 and 9 when you use grub or any bootloader where you can change the kernel cmdline or with an unencrypted /boot where the initrd can be replaced with a malicious one. Yes, this entails that the key needs to be enrolled after nearly every upgrade.

There have been a lot of comments on this gist with some good feedback and advice. I updated the guide to included PCR9 as a result.

@Blaimi As long as you are using secure boot and the bootloader loads a UKI as long as it is not specifically disabled in the kernel, you can not change the kernel command line, the kernel will ignore and cmdline values passed to it, this is by design. This applies across all bootloaders, including GRUB(2), as this is handled by the kernel. Using this PCR would only be relevant if you are not booting a UKI, but then the loaded initramfs can be taken over anyway. I guess if you are booting a pure modified kernel without an initramfs which handles everything on an embedded system, this would make sense, but you would not use GRUB or anything else there anyway and UEFI is nonexistent basically there :) Thus, making this irrelevant in any sensible situation.

Yes, if you are using a UKI … but even fedora 40, which brought us the ability for UKI, is not using them by default.

Well, it is described in the beggining that this will not protect against cold boot attacks. But I would also point out (albeit there are many easier ways), as long as the initramfs is not verified against verity, replacing it can be done remotely by a malicious program to gain persistance and it will probably be unnoticed by the user.

I would personally point out that not even the LUKS encrypted non-root volumes are safe in this scenario.

I want to protect my data against "ooops, I forgot my laptop in the train". And to have some comfort when booting (by not having to type the password), I accept that a computer forensic may get access with a significant effort. Adding init=/bin/bash to the kernelcmd and replacing the user password is the first thing I would try, even on unencrypted systems. This is even the recommended method to recover a forgotten root password in Linux Foundation's LFCS certification. Manipulating the initrd needs a lot more time but is also very trivial. A good example for adding custom scripts, even with networking, is dracut-sshd which can be used to unlock LUKS volumes via network when starting the machine via wake on lan.

Adding PCR8 prevents the attac with init=/bin/bash, and PCR9 prevents initrd manipulation on current default installations of fedora which use grub with initrds and not an UKI.