Silverblue: TPM-LUKS and higher PCRs

I will install Fedora Silverblue on a device for another person soon.

One idea for the installation process is to use Full-Disk-Encryption, but to use systemd-cryptenroll to enroll the key to the TPM to allow automatic unlock in normal operation.

Now, I have tested this procedure in a virtual machine, among other things. When using the PCR-values 0+1+2+3+4+5+7, it works as expected. AFAIK these values cover anything related to the device and firmware, but not the operating system itself.

Following the articles in the magazine[1][2], using at least PCR level 9 additional would also be advisable to measure the bootloader and initramfs.

However, when using the PCR-values 0+1+2+3+4+5+7+9 with systemd-cryptenroll, the automatic unlock fails as soon as an update was made, which would make this system less practical.
Some recommendations in one of the articles ([1:1]), like using rpm-ostree initramfs –enable –arg=-a –arg=systemd-pcrphase or adding tpm information to /etc/crypttab, don’t seem to make a difference.

So, how would go about in order to use PCR 9 with systemd-cryptenroll in Fedora Silverblue, while preventing it breaking on updates?


  1. Automatically decrypt your disk using TPM2 - Fedora Magazine ↩︎ ↩︎

  2. Use systemd-cryptenroll with FIDO U2F or TPM2 to decrypt your disk - Fedora Magazine ↩︎

1 Like

If you look at what is measured in the PCR, you will find that GRUB measures a ton of things there that makes them mostly unusable for FDE use right now. We are working on cleaning this up with UKI & systemd-boot but it’s not ready yet.

In the meantime, you can lock against PCR 7 only (Secure Boot policy) and that should work but it’s obviously not secure.

Beginner’s question: is it secure enough to prevent a thief from opening the disc if a passphrase is configured as an alternative method?

@oneofthefedorausers I’m trying the same on Kinoite. Is enrolling the TPM chip as easy as sudo systemd-cryptenroll /dev/xxx --tpm2-device=auto --tpm2-pcrs=1,2,3,4,5,7 ? It works in my VM but I want to be sure that the passphrase is still usable. I haven’t installed clevis or anything listed in Fedora Magazine.

No, anyone can take the disk and boot it from a Fedora LiveISO and get the key.

PCR 4 at least will change on every update.

1 Like

Good to know, it’s that easy to unlock LUKS under the present implementation of TPM unlocking in Fedora?

If you lock only against PCR7

So just to be clear, because I’m not sure that I clearly understand your last answer, is sudo systemd-cryptenroll /dev/xxx --tpm2-device=auto --tpm2-pcrs=0,1,2,3,5,7 secure enough? Or do you need supplmentary PCRs but run the risk of re-enrolling the TPM chip on the next upgrade?

Sorry to bother you again @siosm , are PCRs 0,1,2,3,5,7 secure enough?

The only way to make this “relatively secure” with GRUB is to lock PCR 4, 7, 8 & 9. However, 8 & 9 will change on almost every boot & every update and are really hard to predict. Thus why it’s mostly not usable.

We are working on improvements on this fronts but it’s not ready yet. See: UKI, composefs and remote attestation for Bootable Containers - media.ccc.de

1 Like

Final question I promise, are PCRs 0,1,2,3,5,7 enough to protect personal data in case the computer is stolen? I use a passphrase and TPM as an alternative unlocking method. BIOS and temporary boot devices are password protected.

It depends on what your thread model is. If you are just trying to protect from a dumb thief, this will be enough. If someone really wants to get your data, they can edit the kernel command line and get a root shell on your system.

(Not the final question I guess) How can the root shell open the luks volume without the passphrase?

With the TPM as the PCR values will be the same. You can try it yourself. Add systemd.debug_shell=1 to your kernel command line and your system will auto-unlock using the TPM and you will get a root shell: Diagnosing Boot Problems