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

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.

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 :)