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

If you have updated the firmware, kernel, or bootloader, and cmdline then auto volume decryption on your next reboot will fail.

Does this mean that for every kernel update through dnf the boot and decryption will break? And that I manually have to add new keys to tpm?

It completely depends on your encryption's PCR configuration. See more at man systemd-cryptenroll.

Does this mean that for every kernel update through dnf the boot and decryption will break? And that I manually have to add new keys to tpm?

If you have PCR 8 and/or 9 configured: yes. I strongly recommend this because of comment #4717836.

Fedora/RedHat is currently working on a Unified Kernel Image which can also boot without grub. This makes the contents of the PCRs predictable after a update before the reboot has happened and enables the possibility to add the new decryption key without breaking auto-unlock after updates. This prediction is not possible to do with the current implementation of grub and I assume never will.

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.

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.