Automatically decrypt your disk using TPM2

Photo by bassem Kira on Unsplash (cropped)

This article demonstrates how to configure clevis and systemd-cryptenroll using a Trusted Platform Module 2 chip to automatically decrypt your LUKS-encrypted partitions at boot.

If you just want to get automatic decryption going you may skip directly to the Prerequisites section.


Disk encryption protects your data (private keys and critical documents) through direct access of your hardware. Think of selling your notebook / smartphone or it being stolen by an opportunistic evil actor. Any data, even if “deleted”, is recoverable and hence may fall into the hands of an unknown third party.

Disk encryption does not protect your data from access on the running system. For example, disk encryption does not protect your data from access by malware running as your user or in kernel space. It’s already decrypted at that point.

Entering the passphrase to decrypt the disk at boot can become quite tedious. On modern systems a secure hardware chip called “TPM” (Trusted Platform Module) can store a secret and automatically decrypt your disk. This is an alternative factor, not a second factor. Keep that in mind. Done right, this is an alternative with a level of security similar to a passphrase.


A TPM2 chip is a little hardware module inside your device which basically provides APIs for either WRITE-only or READ-only information. This way you might write a secret onto it, but you can never read it out later (but the TPM may use it later internally). Or you write info at one point that you only read out later. The TPM2 provides something called PCRs (Platform Configuration Registers). These registers take SHA1 or SHA256 hashes and contain measurements used to assert integrity of, for example, the UEFI configuration.

Enable or disable Secure Boot in the system’s UEFI. Among other things, Secure Boot computes hashes of every component in the boot chain (UEFI and its configuration, bootloader, etc.) and chains them together such that a change in one of those components changes the computed and stored hashes in all following PCRs. This way you can build up trust about the environment you are in. Having a measure of the trustworthiness of your environment is useful, for example, when decrypting your disk. The UEFI Secure Boot specification defines PCRs 0 – 7. Everything beyond that is free for the OS and applications to use.

A summary of what is measured into which PCRs according to the spec

  • PCR 0: the EFI Firmware info like its version
  • PCR 1: additional config and info related to the EFI Firmware
  • PCR 2: EFI drives from hardware components (like RAID controller)
  • PCR 3: additional config and info to drivers stored in 2
  • PCR 4: pre-OS diagnostics and the EFI OS Loader
  • PCR 5: config of the EFI OS Loader and GPT table
  • PCR 6: is reserved for host platform manufacturer variables and is not used by EFI
  • PCR 7: stores secure boot policy configuration

Some examples on what is measured into which PCR

  • Changes to the initramfs measure into PCRs 9 and 10. So if you regenerate the initramfs using dracut -f you have to rebind. This will happen on every update to the kernel.
  • Changes to the Grub configuration, like adding kernel arguments, kernels, etc. measure into PCRs 8, 9 and 10.
  • Storage devices measure into PCRs 8 and 10. However, Hubs and YubiKeys do not seem to measure in any PCR.
  • Additional operating systems measure into PCR 1. This occurs, for example, when attaching a USB stick before boot with a Fedora Linux live image.
  • Booting into a live image changes PCRs 1, 4, 5, 8, 9 and 10.

A tool called clevis generates a new decryption secret for the LUKS encrypted disk, stores it in the TPM2 chip and configures the TPM2 to only return the secret if the PCR state matches the one at configuration time. Clevis will attempt to retrieve the secret and automatically decrypt the disk at boot time only if the state is as expected.

Security implications

As you establish an alternative unlock method using only the on-board hardware of your platform, you have to trust your platform manufacturer to do their job right. This is a delicate topic. There is trust in a secure hardware and firmware design. Then there is trust that the UEFI, bootloader, kernel, initramfs, etc. are all unmodified. Combined you expect a trustworthy environment where it is OK to automatically decrypt the disk.

That being said you have to trust (or better, verify) that the manufacturer did not mess anything up in the overall platform design for this to be considered a fairly safe decryption alternative. There are a range of cases where things did not work out as planned. For example, when security researches showed that BitLocker on a Lenovo notebook would use unencrypted SPI communication with the TPM2 leaking the LUKS passphrase in plain text without even altering the system, or that BitLocker used the native encryption features of SSD drives that you can by-pass through factory reset.

These examples are all about BitLocker but it should make it clear that if the overall design is broken, then the secret is accessible and this alternative method less secure than a passphrase only present in your head (and somewhere safe like a password manager). On the other hand, keep in mind that in most cases elaborate research and attacks to access a drive’s data are not worth the effort for an opportunistic bad actor. Additionally, not having to enter a passphrase on every boot should help adoption of this technology as it is transparent but adds additional hurdles to unwanted access.


First check that:

  • Secure Boot is enabled and working
  • A TPM2 chip is available
  • The clevis package is installed

Clevis is where the magic happens. It’s a tool you use in the running OS to bind the TPM2 as an alternative decryption method and use it inside the initramfs to read the decryption secret from the TPM2.

Check that secure boot is enabled. The output of dmesg should look like this:

$ dmesg | grep Secure
[    0.000000] secureboot: Secure boot enabled
[    0.000000] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
[    0.005537] secureboot: Secure boot enabled
[    1.582598] integrity: Loaded X.509 cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42'
[   35.382910] Bluetooth: hci0: Secure boot is enabled

Check dmesg for the presence of a TPM2 chip:

$ dmesg | grep TPM
[    0.005598] ACPI: TPM2 0x000000005D757000 00004C (v04 DELL   Dell Inc 00000002      01000013)

Install the clevis dependencies and regenerate your initramfs using dracut.

sudo dnf install clevis clevis-luks clevis-dracut clevis-udisks2 clevis-systemd
sudo dracut -fv --regenerate-all
sudo systemctl reboot

The reboot is important to get the correct PCR measurements based on the new initramfs image used for the next step.

Configure clevis

To bind the LUKS-encrypted partition with the TPM2 chip. Point clevis to your (root) LUKS partition and specify the PCRs it should use.

Enter your current LUKS passphrase when asked. The process uses this to generate a new independent secret that will tie your LUKS partition to the TPM2 for use as an alternative decryption method. So if it does not work you will still have the option to enter your decryption passphrase directly.

sudo clevis luks bind -d /dev/nvme... tpm2 '{"pcr_ids":"1,4,5,7,9"}'

As mentioned previously, PCRs 1, 4 and 5 change when booting into another system such as a live disk. PCR 7 tracks the current UEFI Secure Boot policy and PCR 9 changes if the initramfs loaded via EFI changes.

Note: If you just want to protect the LUKS passphrase from live images but don’t care about more “elaborate” attacks such as altering the unsigned initramfs on the unencrypted boot partition, then you might omit PCR 9 and save yourself the trouble of rebinding on updates.

Automatically decrypt additional partitions

In case of secondary encrypted partitions use /etc/crypttab.

Use systemd-cryptenroll to register the disk for systemd to unlock:

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

Then reflect that config in your /etc/crypttab by appending the options tpm2-device=auto,tpm2-pcrs=1,4,5,7,9.

Unbind, rebind and edit

List all current bindings of a device:

$ sudo clevis luks list -d /dev/nvme0n1... tpm2
1: tpm2 '{"hash":"sha256","key":"ecc","pcr_bank":"sha256","pcr_ids":"0,1,2,3,4,5,7,9"}'

Unbind a device:

sudo clevis luks unbind -d /dev/nvme0n1... -s 1 tpm2

The -s parameter specifies the slot of the alternative secret for this disk stored in the TPM. It should be 1 if you always unbind before binding again.

Regenerate binding, in case the PCRs have changed:

sudo clevis luks regen -d /dev/nvme0n1... -s 1 tpm2

Edit the configuration of a device:

sudo clevis luks edit -d /dev/nvme0n1... -s 1 -c '{"pcr_ids":"0,1,2,3,4,5,7,9"}'


Disk decryption passphrase prompt shows at boot, but goes away after a while:

Add a sleep command to the systemd-ask-password-plymouth.service file using systemctl edit to avoid requests to the TPM before its kernel module is loaded:

ExecStartPre=/bin/sleep 10

Add the following to the config file /etc/dracut.conf.d/systemd-ask-password-plymouth.conf:

install_items+=" /etc/systemd/system/systemd-ask-password-plymouth.service.d/override.conf "

Then regenerate dracut via sudo dracut -fv ‐‐regenerate-all.

Reboot and then regenerate the binding:

sudo systemctl reboot
sudo clevis luks regen -d /dev/nvme0n1... -s 1


FAQs and Guides


  1. Presumably, if somebody steals your lap-top and uses it to boot on the basis of now having the hardware, that is quite a security problem?

    • cjpembo

      I came to the same conclusion after reading this article. With this TPM method, if the system board crashes, is the data locked forever? Ultimately, I guess the drive is encrypted, and even though it is automatically decrypted, that could prove to be marginally better than no encryption in some scenarios. I’d be more worried about something happening to the linux boot process in a future ‘sudo dnf update’ that somehow borks this TPM setup you’ve been blindly relying on and then you’re locked out forever. So I’d keep all of this away from your /boot partition in case you need to rescue the system. Assuming you have a boot partition.

      • I think it is using symmetric encryption. So, in theory, as long as you remember the passphrase, you should be able to decrypt it later on even if an update breaks the TPM automatic decryption. However, will you remember (or be able to find) that passphrase you set three years ago when the day comes that this automated system fails? That is perhaps the better question.

        Also, being able to get to the boot partition won’t help you. If you have neither the passphrase nor the automated TPM unlocking, then your data is effectively gone.

        • hammerhead corvette

          However, will you remember (or be able to find) that passphrase you set three years ago when the day comes that this automated system fails?

          Which is why you have a BItWarden, KeepassXC vault with all your keys on multiple devices, so in the case you need a password froma machine you had 3yrs ago, you still have your keys. Laptop/Desktop/Phone should all have a password vault.

    • I think so. It will decrypt the disk automatically and boot.

      • I think the assumption is that you have passwords set on all the post-boot interactive interfaces (GNOME, tty2, etc.). So unless there is an exploit in one of those (which is possible), an unauthorized party shouldn’t be able to access your data, even if the system boots.

    • Matt

      Somewhat, but not nearly as much as you might think.

      The point of the TPM is to ensure the state of the system hasn’t changed. So if someone boots up, and you have a reasonably strong password, they should have the ability to . . . guess your password at the console, and that’s it. If they boot to a live CD, the TPM will refuse to decrypt the drives. If they remove the drives, the TPM will refuse to decrypt them. Tampering with the TPM is meant to be very difficult, it will simply forget its keys.

      For a tech savvy individual’s computer, sure, entering a long passphrase might make sense. It might seem and sometimes actually be much more secure. But think about an organization’s IT. TPM vs giving the user a passphrase they’re likely going to write down on a piece of paper they keep by the laptop? So, so, so much better.

      The TPM is doing other things for you in this scenario too, since secure boot is enabled, you have pretty good assurance your kernel wasn’t modified between boots.

  2. Thanks for this guide, incredibly helpful! I managed to set everything up very quickly. Although I decided not to use PCR 9 and use PCR 0. Speaking of which, is there a reason why PCR 0 is not used in this guide?

    • I decided to include only the most basic configuration for the given requirements as it reduced my test set and seems to be sufficient for what this guide tries to achieve 🙂

  3. vamos ajudar nós comentarios deste grande Fedora ,pós pricisamos muito de tecnologias de ponta e livre sem preconceitos e sem interferencias ,muito obrigado ,

  4. Michael

    Why encrypt the disk if it is decrypted automatically on boot. disk encryption is part of 2 factor authentication to protect the disk contents. This effectively defeats one of the 2 factors.

    If you wish to automatically decrypt the disk on boot then use a method which relies on another device – yubikey for example – or at least a fingerprint.

    • I think it might even be a good idea to require such an external device if Fedora Linux were to ever ship with pre-configured support for such filesystem-level or block-level encryption if for no other reason than that such a requirement might help to prevent ransomware attackers from turning encryption on for people remotely.

    • Disk encryption prevents attackers from accessing your device when it’s turned off. Without it, they can just boot from a live USB and get access to your data.

      With automatic decryption, they can easily turn on your device, but they still won’t be able to get your data, because it’s protected by your user password.

    • If you only use a passphrase, then the passphrase is the one and only factor.

  5. Nicholas

    Thanks for this guide! Been wondering how to do this. Also, quick heads up that the part about delaying the login prompt on boot says


    instead of



  6. Dave

    why clevis?

    i just use systemd-cryptentoll on fedora workstation, installed tpm2-tools package, edit crypttab accordingly and reran dracut.

    so, there is no need to play with plymouth…

    • Kevin

      Do you have a link to set that up?

      • Damjan

        Do you have a link to set that up?

        funnily enough, it’s in the article above too – just “for other” filesystems, which I don’t understand, it’ll work for root too.

      • Dave

        It’s fairly easy and well documented in the man pages for crypttab (example 5: TPM2 Volume Unlocking) . Just make sure, that the tpm2-tools are installed, you may have to reboot. Im not good in writing manuals, so i will make a short video for you. come back in one or two days 🙂

      • Dave

        so here’s a link to my shortcast. i think, that’s suitable for most common attackers and it’s very comfortable to use.

        • J

          Hmm it’s not secure at all. Steps to break your system:
          1. boot grml
          2. mount /boot
          3. edit “loader/entries/.conf in the mounted boot partition and add “init=/bin/sh” to the options line
          4. reboot and you are in
          5. “meh” instead of “tadaaa” 😉

          Problem is that systemd-cryptenroll only measures the PCR 7 by default. That’s easy, but far from good in my opinion.

          And another thing. In my tests with –tpm-pcrs=7+9 I figured out that you need to update the initramfs first, reboot and then enroll the tpm slot with systemd-cryptenroll. The order matters.

  7. Hugo Leonardo R. D. Lopes

    Hello Alexander Wellbrock!

    I really liked the article, I didn’t know that this was possible.
    I have some questions and passive tests if anyone wants to do it.
    1: To insert code into TMP2, I believe you have a reserved space in KB or MB… If so!… How much is that space? I think it’s too small… I don’t know!
    2: Depending on the size, is it possible to introduce the shadow in a way that if someone tries to remove it, a low-level programming language code destroys the TPM2 and makes it unreadable and inaccessible, if this configuration wasn’t similar to the ROM, from the factory? I believe it is not, because a permanent code was inserted in the TPM2 according to your tests.
    3: If you have space to introduce shadow, do you believe it is possible to implement, in an incremental way, not at the end or in continuity, more of addition and overlapping, as if we were putting one hand over the other, or several sheets of paper, one over the other, just in this free space of TPM2, where you introduced the “clevis”, and encrypt with more than 4 different cryptos, generating a unique code, as it would be addition, one over the other, without erasing the data, removing each layer of bits and then putting it back in the correct place, with different passwords for each crypto, where after passing each crypto, it would be unreadable for the machine language to decipher each overlapping password code in addition, already with the shadow implemented in place of “clevis “? In this way, there would be no problem with TPM2, as that part would be unreadable, but interpreted for use on the Computer, and afterwards, it could encrypt the disk without problems.
    I would like to take this test… Unfortunately, I cannot do it because of my limitations, due to the seriousness of what they did to me in Portugal (level of medication and false medical reports), and also to people from NATO, outside NATO and Portuguese from different social classes.
    I hope I have contributed in some way to my Linux daydreams. Thanks!

  8. eu sou Brasileiro aquilo que vejo .que nosso computador não vive bons momentos ,devido preço sistemas que domina o mercado ,mas oferece muito pouco para o navegador ou a pessoa que compra o mesmo ,nossa salvação seria o sistema Linux ,e nosso Fedora tem evoluito tanto e mais ainda em segurança ,como este sistema novo ,obrigado

  9. César

    Hello, there’s a small typo in the troubleshooting section when you told the reader to regenerate dracut using sudo dracut -fv -regenerate-all, it should be –regenerate-all with double hyphen, otherwise great guide, will keep an eye for more interesting tips 🙂

    • Thanks César. I’ve corrected it. It was caused by WordPress auto-correct. (Isn’t automation wonderful‽ 🙂)

      BTW, just my 2¢, but I wouldn’t recommend using ‐‐regenerate-all (ever). If something goes wrong, it can wreck all of your kernels at the same time. It is better to omit that option so that only the latest kernel is updated or to use the ‐‐kver <kernel-version> option to update only the specified kernel. That way, you leave your other kernels untouched and you can still use them to boot your system if you need to.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions