[GUIDE] Setup TPM2 Autodecrypt

I want to share some of my experience setting up TPM2 auto-decrypt LUKS full-disk encryption. Although I have been using Linux for a while, I have always been avoiding doing any configuration that is not in the GUI, so I think this will be a good place for me to collect some suggestions about my setup.

TLDR: Just Show Me The Command

Use lsblk or gnome disk application to find the LUKS full disk encryption partition. The partition is most likely /dev/nvme0n1p3. Run

sudo systemd-cryptenroll --wipe-slot tpm2 --tpm2-device auto --tpm2-pcrs "1+3+5+7+11+12+14+15" /dev/nvme0n1p3
sudo dracut -f

where /dev/nvme0n1p3 is your LUKS partition. Enter your LUKS password when prompt, and restart, you should not see a password prompt.

If this stopped working after a firmware or bootloader update, run

sudo dracut -f

to re-build initramfs.

NOTE: These commands only works with TPM2 and LUKS2, which should not be a problem on framework laptops as of the time of writing; you will also need to have LUKS full disk encryption. If you selected full disk encryption when installing your distro, you will likely be fine.

Configuration Explaination

systemd-cryptenroll v.s. clevis

This configuration is copied from this fedora magazine article, which is an update from an older article.

The systemd-cryptenroll method is easier to set up and more user-friendly than clevis in the previous older articles.

System Integrity Configuration

An important configuration is to specify under what condition the TPM will release the key. This is specified by "1+3+5+7+11+12+14+15" in the command, the original article recommend "0+1+2+3+4+5+7+9".

Several Common configs:

  • my config: "1+3+5+7+11+12+14+15", probably an overkill, reasons specified below.
  • config recommended by fedora magazine article: "0+1+2+3+4+5+7+9",
  • default config: "7", you will only need to enter password when secure boot is disabled
  • my recommended minimal config: "1+7", according to the doc, you will only need to enter password on hardware change and when secure boot is disabled.

Here are the reasons for my config:

  • I omitted 9 (Linux Kernel and grub), which requires rebuild every time there is a kernel update. As Fedora updates the Kernel quite often, I omitted this integrety check.
  • I omitted 4 because I observed a change in its signature after a kernel update. I am assuming it will sometimes be changed by an regular update.
  • I omitted 0 (firmware) and 2 (pluggable hardware), because it is explicitly recommended against by systemd-cryptenroll man page
  • I added 11 (ELF kernel image, embedded initrd and other payload of the PE image ) and 14 (shim) because 7, 11, 14 is recommended by systemd-cryptenroll man page
  • I added 12 (kernel-config) because I don’t typically change kernel parameters
  • I added 15 (volume key of activated LUKS volumes), because I don’t imagine I would change the LUKS volumes.

Please pick and choose a setup that works for you. For more info, please refer to systemd-cryptenroll man page and Linux TPM PCR Registry Spec

Some Common Misconceptions:

Full-disk Encryption (FDE): I always thought that the disk is decrypted the moment password is provided. However, that is not the case: all the data on the disk is constantly encrypted, and data is only decrypted when reading into the ram. Hence in order to break full-disk encryption, the attacker will need:

  • the powered-on laptop with LUKS password already provided;
  • read the key from RAM.

So it is unlikely for any ordinary attacker to break FDE, except de-LUKS which is carried out by swapping initrd. I am not sure if this is addressed by secure boot. Read more about the future of fedora encryption, TPM, and secure boot here.

Secure Boot: An old myth states that secure boot is invented to help Microsoft lock down the BIOS and prevent installation of alternative OS. However, I don’t think it is the case, since most Linux distro works with secure boot, and Mok can be used to sign custom kernels.

TPM and security implications: TPM is a way to store keys that is not readable by the rest of the system. You can save the password in TPM, and it will be released to RAM when it is requested by a specific program under specific conditions (when system integrity is checked).

However, TPM is called “Trusted” Platform Module, not “Trustworthy” Platform Module. There is no guarantee that it will do what it claims to do, see here and here; both example are taken from the “Security Implication” section of this fedora magazine article.

Being a security-critical module. I would trust framework to do basic verification of the trust-worthiness of their suppliers. However, just keep in mind, using TPM is less secure than entering the password manually; but you can use a much more complicated password when using TPM (backup your LUKS key in a safe or a password manager like bitwarden), enhancing the security of the TPM method.

Will I be locked out of my OS?: as long as you have your LUKS key (backup your key!)and the working ssd, you should boot just fine, even after hardware changes.

Other useful resources:

  • Command to read TPM event log: sudo tpm2 eventlog /sys/kernel/security/tpm0/binary_bios_measurements or sudo fwupdtpmevlog
  • Command to get current pcr value: sudo tpm2 pcrread, you can log the pcr value before an update sudo tpm2 pcrread > ~/Download/pcr.txt and compare the value after the update, to see which measurement is changed. You can choose to remove the check that is changed by a system update. For example, we can remove check 15 simply by rerun cryptenroll:
sudo systemd-cryptenroll --wipe-slot tpm2 --tpm2-device auto --tpm2-pcrs "1+3+5+7+11+12+14" /dev/nvme0n1p3
sudo dracut -f

Notice the differece between these commands and the original command, 15 is no longer in "1+3+5+7+11+12+14"

  • Change LUKS key, just use gnome disk application, select the LUKS partition, click the gear icon, and select “change passpharse”. You can set a much stronger password after setting up TPM autodecrypt (Again, backup your key).

Further Reading


This is neat write up.
I have been doing casual readings to understand this whole process of tmp unlocking. I have yet to be annoyed enough with typing in an extra password to implement this.

1 Like

Pinning as a guide, nicely done.

1 Like

On my systems, the /boot block device, containing the initramfs images, is encrypted, too. Only the /boot/efi is not, so one would have to replace the GRUB’s efi binary. However, I take it that this one can be signed and then verified before startup.

I would be happy to see how to do it :slight_smile:

1 Like