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

I am on Fedora 40.

It worked with me after doing the following changes I saw in Fedora Magazine.

https://fedoramagazine.org/automatically-decrypt-your-disk-using-tpm2/

sudo systemd-cryptenroll /dev/nvme0n1xxx --tpm2-device=auto --tpm2-pcrs=1,4,5,7,9

Then on /etc/crypttab:

luks-xxx UUID=yyy - tpm2-device=auto,tpm2-pcrs=1,4,5,7,9

Finally:

dracut -fv --regenerate-all

Note for systemd-boot users: dont include PCR 8 (thats a grub thing, see https://www.freedesktop.org/software/systemd/man/latest/systemd-cryptenroll.html) use PCR 12

@Blaimi

I want to protect my data against "ooops, I forgot my laptop in the train".
I completely get that. Still, it is more common for a normal user to get compromised remotely rather than an IRL evil maid attack. And protecting against remote attacks protects the system against physical attacks as well.
Also, I would point out that TPM-based encryption has two flaws:

• SHA-1 banks: Easily guessable by modern day computer, unless DA lockout is configured. But DA lockout can happen in unexpected situations, that is why in my tests I found Ubuntu with TPM based FDE impossible when dual booting Windows.
• No firmware TPM: If TPM lines are exposed you can get easily compromised anyway, see this great vid by stacksmashing. I would personally set a TPM pin (however, I would note that stable versions of Systemd seem to confuse FIDO2 and TPM2 PIN prompt texts if both is set up) or if you really need TPM2 fully unattended unlocking, go for a chip which has a firmware TPM, so lines are not exposed.

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.

This is ok, but not portable, see above me:

Note for systemd-boot users: dont include PCR 8 (thats a grub thing, see https://www.freedesktop.org/software/systemd/man/latest/systemd-cryptenroll.html) use PCR 12

Also, this relies on the TPM measurement, instead of the fixed functionality of the kernel to actually ignore kernel parameters and if you are looking for a standard way to store that go for PCR 12. But I would only do this for non-tinkering users, where the kernel CMD never changes and this is more relevant for OEMs or embedded systems.

@IPlayZed It seems that PCR8 also works with rEFInd. I used PCR8 on my setup and it was working fine, when I modified kernel command line parameters in refind.conf it asked me for the password after reboot. It started working again when I restored command line to the previous one. I couldn't find anything in rEFInd documentation about that though.

@DragonSWDev Hey, that is good to know. This means that the 3 main bootloaders follow the standards :)