11. Mar 2026 | Alberto Planas | CC-BY-SA-3.0
Introduction
In user space, Full Disk Encryption (FDE), as opposed to the bootloader-based FDE, developers for openSUSE supports signed policy and NVIndex policy from scratch when using Trusted Platform Module 2 (TPM2).
With this signed policy, we deliver a JSON file in the EFI System Partition (ESP) that is read during the initrd stage through systemd-cryptsetup. This file contains the hash policy, which is basically the expected values of the PCR registers of the TPM2 (measured boot). Along with the policy we will find a signature that will be validated by the TPM2and if the PCR values and the signatures are valid, then the TPM2 will unlock the password for the encrypted hard drive, and the boot process can continue.
This method is simple and very flexible. We can update the policy to generate new predictions (for example, if a new kernel is installed). Using a private key, which can be stored in the encrypted side of the system, we can sign it and install it in the ESP. Another advantage is that we can generate multiple files that support multiple valid configurations, representing different snapshots, kernels or initrd installed in the system.
But one limitation of this method is that we are not protected against a rollback attack. Someone can copy the JSON file (the ESP is not encrypted), along with the kernel and the initrd and wait until some CVE is published for this setup. After that the assets can be copied back to the ESP and the signature of the policy will still be valid as far as the TPM2 is worried Technically, this can be solved by generating a new private key and rolling the devices back up, but it’s not ideal.
systemd-pcrlock offers a new alternative, known as NVIndex policy, which stores the policy TPM2 non-volatile RAM under a password (recovery PIN). This approach is a bit better for our case as it solves the rollback attack. This method is used by default if the TPM2 support it, but because policyAuthorizeNV was introduced in TPM2 Revision 1.38 ten years ago (2016), not all devices can do this. sdbootutil fall back to pcr-oracle (signed policy) submit NVIndex policy cannot be used.
The following version of sdbootutil will fall pcr-oracle.
Motivation
It’s basically time to do it. The rollback attack is a good argument to avoid signed policies, but we must consider the maintenance of pcr-oracle for multiple bootloaders (GRUB2 and systemd-boot).
The way in which pcr-oracle work means that any change in the event log sequence or structure must be addressed in the source code, but with systemd-pcrlock it’s a matter of generating some JSON files stored in /var/lib/pcrlock.d and updating the TPM2 policy at the right moment.
This makes a difference pcr-oracle lags behind current support, effectively making it broken by any metric.
Migration
The good news is that if you have a TPM2 manufactured after 2016, you can migrate to systemd-pcrlock very easy. sdbootutil still recognize systems registered with pcr-oracle and can roll them off. The migration process is as easy as:
# sdbootutil unenroll --method=tpm2
# sdbootutil enroll --ask-pin --method=tpm2
If unfortunately you TPM2 revision is older, the password entry is always available:
# sdbootutil unenroll --method=tpm2
# sdbootutil enroll --method=password
