TPM on Giovanni Bassi

NixOS: Installation Guide with RAID 1, encryption, and TPM unlock (part 7 - Mitigating the OS swap attack)

giggio@giggio.net (Giovanni Bassi) — Mon, 01 Jun 2026 11:00:00 -0300

There is still a loophole where one could obtain the LUKS volume encryption key using another operating system. Let’s fix that.

This is the seventh post in the series:

Preparing the virtual machine and partitioning the disks
Disko, LUKS, and btrfs
Installing the OS
Enabling Secure Boot
Unlocking the disk with TPM
Mitigating the volume swap attack
Mitigating the OS-switch attack (this post)

If you are only using your own keys in Secure Boot, this post doesn’t apply to your scenario. If you are also using Microsoft’s keys, you need to implement this mitigation.

The Problem

So far, we have been linking disk decryption to PCR 7 (and PCR 15 for system loading, as described in the last post). As seen in previous posts, PCR 7 depends exclusively on the Secure Boot state. This means that, regardless of which operating system is loaded, PCR 7 will have the same values.

If you also trust third-party keys (such as Microsoft’s or another manufacturer’s, like Canonical’s) in Secure Boot, there is still an attack surface that allows booting another system signed by those authorities. Therefore, it’s necessary to bind the protection to something beyond just PCR 7.

With the operating system loaded and PCR 7 in the correct configuration, it’s possible to obtain the LUKS volume header data and decrypt it using the TPM to get the LUKS master key, and then decrypt the volume. This could even be done using a Live CD with a correctly signed boot loader.

Naively sealing the LUKS key with the NixOS boot loader

Sealing the volume key only with PCR 7 is risky, so let’s also use another PCR that is closely tied to our operating system. PCR 4 measures the boot loader and additional drivers — the boot loader/PE binary code executed in the boot path. This means only an operating system that loads using the NixOS .efi files we are using would be able to retrieve the LUKS key via the TPM.

Since these .efi files are generated on-demand for our specific NixOS configuration and signed with Lanzaboote using our private keys, this prevents another OS from decrypting the LUKS key. For instance, if you load Ubuntu, the boot loader will be Ubuntu’s, with different .efi files, and therefore the content extended into PCR 4 will also be different. Because PCR 4 measures the EFI/PE binary actually executed at boot, a different boot path produces a different measurement and cannot reuse the same TPM token.

This would be simple if the boot loader didn’t change every time the Kernel, initrd, or any boot configuration is updated, which ends up changing PCR 4. If that weren’t the case, we could simply run:

# remove previous token from disk 1
sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/disk/by-label/NIXLUKS1
# enroll new token using PCR 4 and PCR 7 on disk 1
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=4+7 /dev/disk/by-label/NIXLUKS1
# do the same for disk 2...

Note: The commands above can be combined into one, which will wipe and enroll in a single operation.

This will only work until the next time the boot loader files (the .efi files) are changed. On the first boot after such a change, the volume will no longer decrypt automatically, it will ask for the password, and you would need to run the commands above again. If that’s acceptable to you, you don’t even need to read the rest of the post, but I can tell you there is a better and equally secure way to solve this.

Sealing the LUKS key with the NixOS boot loader using a PCR policy

Important: Before starting, verify that your virtual machine is configured to use only one of the disks as a boot disk. I noticed that if both disks are marked as boot disks, PCR 4 is not correctly evaluated and the policy is not created. In the virtual machine settings, you can see this in the “Boot Options” menu. This might be a quirk of Virtual Machine Manager (and virsh), the Firmware used, or something related to Secure Boot and TPM protocols. The problem doesn’t occur on my physical machine, only on the virtual one.

The secret to solving this problem is a system that can predict the values that will be in the PCR and create an appropriate policy, and that is exactly what systemd-pcrlock does. While the process can be done manually, Lanzaboote recently implemented TPM measurement alongside Secure Boot integration, using systemd-pcrlock. At the time of writing, this hasn’t made it into a release yet, meaning it might contain bugs. By the time you read this, the functionality may have stabilized.

To enable it, simply add this to your configuration:

boot.lanzaboote = {
 enable = true;
 pkiBundle = "/var/lib/sbctl";
 configurationLimit = 8;
 measuredBoot = {
 enable = true;
 pcrs = [ 4 7 ];
 };
};

Finally, you need to perform a nixos-rebuild, but use boot instead of switch:

sudo nixos-rebuild boot

This will prepare the configuration, but it will only be used on the next boot. This is important to ensure that the boot loader files are correctly signed, in addition to preparing the PCR 7 files.

Note: systemd-pcrlock has several subcommands that allow you to “lock” a specific PCR. “Locking,” as used here, means inspecting the events of each PCR and generating .pcrlock files in the /var/lib/pcrlock.d directory. For example, systemd-pcrlock lock-firmware-code generates the file /var/lib/pcrlock.d/250-firmware-code-early.pcrlock.d/generated.pcrlock with PCR 0 and 2 measurements. Lanzaboote uses this system when you enable PCR 7 by running systemd-pcrlock lock-secureboot-authority and systemd-pcrlock lock-secureboot-policy. This is done by creating two oneshot systemd services: systemd-pcrlock-secureboot-authority and systemd-pcrlock-secureboot-policy.

Reboot the system. The LUKS key is still tied only to PCR 7, and the disks will be decrypted automatically. After the reboot, the policy file will have been created. You can verify if both PCRs are present in the file by running:

$ jq '.pcrValues.[].pcr' /var/lib/systemd/pcrlock.json
4
7

If this is correct, you can now remove the token from the disk headers that was tied only to PCR 7 and create a new one using the policy via the generated file:

# remove previous token and enroll new token using the policy on disk 1
sudo systemd-cryptenroll --tpm2-device=auto --wipe-slot=tpm2 --tpm2-pcrlock=/var/lib/systemd/pcrlock.json /dev/disk/by-label/NIXLUKS1
# remove previous token and enroll new token using the policy on disk 2
sudo systemd-cryptenroll --tpm2-device=auto --wipe-slot=tpm2 --tpm2-pcrlock=/var/lib/systemd/pcrlock.json /dev/disk/by-label/NIXLUKS2

With this, you can reboot again. The disk should continue to unlock automatically, but this time it is using the policy file, and therefore PCRs 4 and 7.

The functionality is now complete. Whenever the boot loader files are updated, the policy will also be updated, and the disk will be decrypted automatically without requiring any manual interaction. In the following sections, I will dive deeper into what is happening.

Inspecting TPM events

You can check TPM events by running sudo systemd-pcrlock log, or just sudo systemd-pcrlock. Unfortunately, the command doesn’t allow showing events for a specific PCR, so you can do it using JSON and jq. To see only PCR 4 events, run:

sudo systemd-pcrlock log --json=short 2>/dev/null | jq '[.log[] | select(.pcr == 4)]'

To see the components registered in systemd-pcrlock, use the list-components command:

$ sudo systemd-pcrlock list-components
ID VARIANTS
240-secureboot-policy /var/lib/pcrlock.d/240-secureboot-policy.pcrlock.d/generated.pcrlock
350-action-efi-application /nix/store/f4s218swc4kw35apcqg9al8d7s287x7y-pcrlock.d/350-action-efi-application.pcrlock
400-secureboot-separator /nix/store/f4s218swc4kw35apcqg9al8d7s287x7y-pcrlock.d/400-secureboot-separator.pcrlock.d/300-0x00000000.pcrlock
500-separator /nix/store/f4s218swc4kw35apcqg9al8d7s287x7y-pcrlock.d/500-separator.pcrlock.d/300-0x00000000.pcrlock
620-secureboot-authority /var/lib/pcrlock.d/620-secureboot-authority.pcrlock.d/generated.pcrlock
630-bootloader /var/lib/pcrlock.d/630-bootloader.pcrlock.d/current.pcrlock
635-lanzaboote /var/lib/pcrlock.d/635-lanzaboote.pcrlock.d/7.pcrlock

These components are used to predict the values of each PCR. They are what “lock” the TPM. The idea is that systemd-pcrlock lock-* commands check TPM events and generate these components, along with Lanzaboote generating the PCR 4 (boot loader) ones at every nixos-rebuild.

Finally, you can check the measurements being used by running systemd-pcrlock predict:

$ sudo systemd-pcrlock predict --pcr=4,7
Event log record 0 (PCR 0, "Raw: 2\0008\000\000\000") not matching any component.
Event log record 9 (PCR 1, "Raw: ACPI DATA") not matching any component.
Event log record 13 (PCR 2, "Raw: \030\377\004\000") not matching any component.
Event log record 27 (PCR 5, "GPT: disk 8118a150-5781-4514-94f0-517c327f4ca7") not matching any component.
Event log record 40 (PCR 9, "Linux: kernel command line") not matching any component.
Event log record 31 (PCR 11, "String: .linux") not matching any component.
Event log record 39 (PCR 12, "String: Global credentials initrd") not matching any component.
Event log record 44 (PCR 15, "cryptsetup:crypt_disk1:5a2876f5-9220-4040-8b56-7bc226c9d649") not matching any component.
3 combinations of components.
PCR 4 (boot-loader-code) matches event log and fully consists of recognized measurements. Including in set of PCRs.
PCR 7 (secure-boot-policy) matches event log and fully consists of recognized measurements. Including in set of PCRs.
PCRs in protection mask: 4 (boot-loader-code), 7 (secure-boot-policy)
Results for PCR 4 (boot-loader-code):
 sha256: 19d6c3ffa28c30062e84d8e90a357a6319ce921dfa15ee6618a5f9c38a5e9890
 sha256: 58d68b2aa60262d9831fdd1b8b0f50fd30610162bf3ae7f19d4722e21ba24277
 sha256: 480319eadf7ad52de18d44758204505cf34a4def787c762e1da3024a69b2ec8e
Results for PCR 7 (secure-boot-policy):
 sha256: cc1dc9cbd11e3ad0a695744ab152362d388e2e97f165117e3e45b8248f4a5078

The initial lines show event records that were not recognized. Since predict only generates predictions for PCRs whose component coverage is complete, those PCRs are excluded from this specific policy. If we wanted to use them, some could have components created by running systemd-pcrlock lock-* commands, while others would need manual component creation.

Lastly, let’s compare the PCR 7 logs used in the fifth post. The only difference is the inclusion of the component field (which “locks” the PCR), highlighted below:

sudo systemd-pcrlock log --json=short 2>/dev/null | jq '[.log[] | select(.pcr == 7)]'

[
 {
 "pcr": 7,
 "pcrname": "secure-boot-policy",
 "event": "efi-variable-driver-config",
 "match": true,
 "sha256": "9f75b6823bff6af1024a4e2036719cdd548d3cbc2bf1de8e7ef4d0ed01f94bf9",
 "phase": "F",
 "component": "240-secureboot-policy",
 "description": "Variable: dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f"
 },
 {
 "pcr": 7,
 "pcrname": "secure-boot-policy",
 "event": "efi-variable-authority",
 "match": true,
 "sha256": "f35567246a92b2fcdd2901e4ad2febdfd80173f25527c5a73033bf100a8eb980",
 "phase": "F",
 "component": "620-secureboot-authority",
 "description": "Authority: db-d719b2cb-3d3a-4596-a3bc-dad00e67656f"
 }
]

Evaluating the LUKS header token

We can also compare the LUKS header, which was updated when we ran systemd-cryptenroll with the --wipe-slot argument and then --tpm2-pcrlock. In the fifth post, the policy wasn’t used, so the tpm-pcrs field (a list) had the value 7, and now it’s empty. The tpm2-pcr-bank field is no longer used, and the tpm2_pcrlock_nv field now has a hash:

sudo cryptsetup luksDump --dump-json-metadata /dev/disk/by-label/NIXLUKS1 | jq -r '.tokens."0"'

{
 "type": "systemd-tpm2",
 "keyslots": ["1"],
 "tpm2-blob": "<a base64 value>",
 "tpm2-pcrs": [],
 "tpm2-policy-hash": "<a hash>",
 "tpm2_pcrlock": true,
 "tpm2_srk": "<another base64 value>",
 "tpm2_pcrlock_nv": "<yet another base64 value>"
}

This last field, ending in _nv, is especially important. It points to a non-volatile area of the TPM, which is not erased when the computer turns off. The pcrlock policy data is stored there, and if the TPM is cleared, it forces the recreation of the policy (more on this below).

Removing the TPM policy

If you ever remove the NixOS TPM measurement settings (boot.lanzaboote.measuredBoot), you will need to remove the policy manually. It is registered in the aforementioned policy file, but also in the TPM’s non-volatile memory. This should be automated by Lanzaboote (I opened an issue), but from what I’ve seen, it isn’t yet. After running nixos-rebuild switch, run:

# remove the policy from the TPM's non-volatile memory and also the files:
# /var/lib/systemd/pcrlock.json and
# /boot/loader/credentials/pcrlock.nixos.cred
sudo systemd-pcrlock remove-policy

Don’t forget to remove the TPM keyslot from the LUKS volume headers:

sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/disk/by-label/NIXLUKS1
sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/disk/by-label/NIXLUKS2

Dealing with a cleared/wiped TPM

If the TPM’s non-volatile memory is wiped, the reference to the TPM policy registered in the LUKS volume header will become outdated, pointing to a record that no longer exists. This will force us to re-enroll the policy into the LUKS header. You can test this safely by clearing the TPM directly from Linux. Run the following commands and reboot:

nix-shell -p tpm2-tools
sudo tpm2 clear
exit

As a result, the operation to decrypt the disk using the TPM during boot will fail, and you will need to decrypt using your password. To re-enable automatic TPM decryption, you first need to remove the policy from the disk (the /var/lib/systemd/pcrlock.json and /boot/loader/credentials/pcrlock.nixos.cred files—explained in the previous section), run nixos-rebuild boot, and reboot to recreate the wiped policy. Then, redo the LUKS header with the systemd-cryptenroll --wipe-slot and systemd-cryptenroll --tpm2-pcrlock commands:

sudo systemd-pcrlock remove-policy
sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/disk/by-label/NIXLUKS1
sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/disk/by-label/NIXLUKS2
sudo nixos-rebuild boot
# reboot, enter LUKS password
jq '.pcrValues.[].pcr' /var/lib/systemd/pcrlock.json # validate that the result is: 4 7
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrlock=/var/lib/systemd/pcrlock.json /dev/disk/by-label/NIXLUKS1
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrlock=/var/lib/systemd/pcrlock.json /dev/disk/by-label/NIXLUKS2

Reboot once more, and you should no longer be prompted for a password.

You’ve already seen these commands in this article, so I won’t detail them further.

Conclusion

With this, your operating system is now protected, and you have the convenience of a system that starts without constantly asking for a decryption password. Better yet, since everything was done using NixOS, the configuration is ready to be reused: if it worked once, it will work forever.

The series was supposed to end here, but since I wrote this post, a few days have passed and I’ve used everything I wrote here to migrate my own machine from Ubuntu to NixOS. I learned a lot and have a few more things to share, so the series will have at least one more post.

If you’ve followed along this far, ran a proof of concept with the examples, or have ideas or criticisms, leave a comment so I know!

NixOS: Installation Guide with RAID 1, encryption, and TPM Unlock (part 6 - Mitigating the volume swap attack)

giggio@giggio.net (Giovanni Bassi) — Tue, 26 May 2026 10:00:00 -0300

The NixOS disk is encrypted, but a careful LUKS volume swap attack can still be used to obtain the encryption master key.

In this post, I show how to mitigate it!

This is the sixth post in the series:

Preparing the virtual machine and partitioning the disks
Disko, LUKS, and btrfs
Installing the OS
Enabling Secure Boot
Unlocking the disk with TPM
Mitigating the volume swap attack (this post)

As I said in the previous post, this kind of attack would not be carried out by an average person. The computer shop technician who is repairing your laptop probably will not be able to read your LUKS encrypted disk and with the key sealed with the help of PCR 7. But someone who knows what they are doing will find the weakness. This post and the next one are for those who want to be fully protected, both from the technician at the shop around the corner and from a hostile government or corporate agent. By the end of these two posts, the attacks described here will be mitigated, significantly increasing security (keeping in mind that it is always prudent to consider other attack surfaces outside these scenarios).

The problem

The attack was described by Oddlama, and it basically consists of removing the disk from the original computer, creating a fake encrypted partition with the same identification data as the original partition, and then using that to obtain the key. He even describes how to do this against NixOS.

This is possible because the UKI (Unified Kernel Image — the binary loaded by UEFI that contains the kernel and the initrd) is not encrypted — if it were, UEFI would not be able to load it. The LUKS volume header is also not encrypted, since it must be read by the system in initrd so that the LUKS volume can be decrypted. It is possible to inspect what will be loaded during boot and replace the LUKS volume with another one carefully prepared to steal the master key from the original LUKS volume.

I will not go into more detail because the explanation is long. You can read Oddlama’s post; it is quite interesting. The important point is that this attack is only possible because the UKI does not validate the identity of the LUKS volume, which allows it to be replaced.

Closing the breach

To solve the problem, we just need to start validating the decrypted volume before proceeding, something that is not being done yet and will be addressed using PCR 15 (system-identity). In the previous post, I showed how to list the hashes of all PCRs with systemd-analyze pcrs. Notice that PCR 15 was zeroed out, meaning it had not been extended. systemd can start writing to it by simply enabling tpm2-measure-pcr=yes for systemd-cryptsetup during the boot process.

To start writing to PCR 15 in the NixOS way, we need a Nix configuration. Fortunately, Oddlama himself provided the solution, pointing to a Forgejo repository by PatrickDaG, with the file ensure-pcr.nix, which has already been adapted in the repository cloned into /etc/nixos, and which makes it possible to read this PCR through a NixOS module.

I incorporated this module into my solution, which made it very easy to apply. The example commit is f690b88, described as “Enable PCR15”, but we do not need to check it out; it is enough to update the configuration in /etc/nixos/configuration.nix (it is already in the code, just remove the comment):

systemIdentity = {
 enable = true;
};

Then apply it:

nixos-rebuild switch

Restart the virtual machine, and after the reboot, confirm that the value of PCR 15 is present (the value below is just an example — replaced by a sequence from 0 to 9):

$ systemd-analyze pcrs 15
NR NAME SHA256
15 system-identity 0123456789012345678901234567890123456789012345678901234567890123

That is the hash of the system identity (derived from the activated LUKS volume key); it is what will ensure that the unlocked volume is the expected one, reducing the volume swap attack.

The value found must be copied into the pcr15 field in the configuration. For example, using the fictitious sequence above from 0 to 9:

systemIdentity = {
 enable = true;
 pcr15 = "0123456789012345678901234567890123456789012345678901234567890123";
};

Change this value, reboot once more, and everything should continue working.

How this solution prevents volume swapping

The explanation is in the Nix module defined in the file ensure-pcr.nix.

It creates a systemd service that starts extending PCR 15 when systemIdentity.enable is enabled, running:

systemd-cryptsetup attach crypt_disk1 /dev/disk/by-partlabel/NIXLUKS1 - 'tpm2-device=auto,tpm2-measure-pcr=yes,discard';

And when the hash of PCR 15 has been defined in systemIdentity.pcr15, it creates a check-pcrs service that runs in initrd and, if it fails, prevents boot from continuing. This service is very simple: it just compares the hash stored in the configuration with the value found in PCR 15:

if [[ $(systemd-analyze pcrs 15 --json=short | jq -r ".[0].sha256") != "${config.systemIdentity.pcr15}" ]] ; then
 echo "PCR 15 check failed"
 exit 1
else
 echo "PCR 15 check succeed"
fi

As this service is required by sysroot.mount, if check-pcrs fails the root disk cannot be mounted and the entire boot fails, entering emergency mode.

What if the boot fails?

If the value of PCR 15 changes for any reason, the boot will fail and enter emergency mode. In that case, you will need to log in with the emergency password configured in initrd and run:

systemctl disable check-pcrs
systemctl default

Note: see the boot.initrd.systemd.emergencyAccess attribute in configuration.nix, that is what defines the emergency initrd password (using a hash of the password). To create the password as test, run (replace the salt, xyz, and the password):

openssl passwd -6 -salt xyz test

Tip: I recommend that you test this by changing the configuration value to the wrong hash, running switch, and confirming that the boot failed. Then test the commands above: you will need to provide the initrd emergency password, disable the check-pcrs service, and continue the boot. In the worst-case scenario, if you cannot do that, you can choose the previous configuration from the boot menu. After logging in again, set the PCR 15 value in the configuration back to the correct one, run a new switch and reboot, making sure that boot works again without issues.

Is it secure?

Again: not yet.

The attack described by Oddlama no longer works, but there is still another one: since we only bind the disk encryption to PCRs 7 and 15, it is still possible to replace the operating system with another one and use the TPM to decrypt the disk. We will solve that in the next post.

NixOS: Installation Guide with RAID 1, encryption, and TPM Unlock (part 5 - unlocking the disk with TPM)

giggio@giggio.net (Giovanni Bassi) — Mon, 18 May 2026 11:00:00 -0300

At last, we are going to automatically decrypt the NixOS disk using the TPM!

This is the fifth post in the series:

Preparing the virtual machine and partitioning the disks
Disko, LUKS, and btrfs
Installing the OS
Enabling Secure Boot
Unlocking the disk with TPM (this post)

Up to now, every boot has required the LUKS password to decrypt the disk. But if the machine’s integrity has not been compromised, there is no problem in doing this automatically. But how?

Now it is time to orchestrate everything we have put together so far, connecting LUKS, Secure Boot, and the TPM.

Why this is safe

Assuming the machine has not been compromised, when the operating system comes up, the only safe way to access it is with valid credentials — assuming the system has no exploitable vulnerability. That means logging in through the console, SSH, the graphical interface, or a serial connection. In practice, that means that without a login password there is no access to the computer, and no privilege is gained.

Everything works based on this principle: an uncompromised and intact system protects itself, and if it is compromised (firmware modification, disk removal, etc), encryption protects the data.

Understanding the TPM

The TPM (Trusted Platform Module) is a dedicated processor that stores, in an inviolable way, measurements taken of the hardware and software running on the computer. These measurements are stored in PCRs (Platform Configuration Registers), whose values can be extended, but never set directly. Every value sent to the TPM extends the previous value and produces a new one. If we were to model this as a formula, it would be something like this:

PCR = HASH(PCR || new_measurement)

In other words, the PCR hash is used together with the new measured value to create the new hash.

You can see the hashes of each PCR on your running TPM (fictitious values):

$ systemd-analyze pcrs
NR NAME SHA256
 0 platform-code 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
 1 platform-config 123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0
 2 external-code 23456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01
 3 external-config 3456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012
 4 boot-loader-code 456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123
 5 boot-loader-config 56789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234
 6 host-platform 6789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345
 7 secure-boot-policy 789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456
 8 - 89abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234567
 9 kernel-initrd 9abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345678
10 ima abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789
11 kernel-boot 0000000000000000000000000000000000000000000000000000000000000000
12 kernel-config 0000000000000000000000000000000000000000000000000000000000000000
13 sysexts 0000000000000000000000000000000000000000000000000000000000000000
14 shim-policy bcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789a
15 system-identity 0000000000000000000000000000000000000000000000000000000000000000
16 debug 0000000000000000000000000000000000000000000000000000000000000000
17 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23 application-support 0000000000000000000000000000000000000000000000000000000000000000

Each PCR is independent and is extended freely, without depending on the others. On compatible TPMs there are 24 PCRs; the UAPI (Linux Userspace API Group) in its specifications considers 0–7 to be firmware and 8–15 to be the range available to the operating system, although the systemd ecosystem also uses specific PCRs for additional measurements, and PCRs 16–23 are also usable.

When the computer powers on, all PCRs start out with no value. The firmware then begins extending the PCRs. For example, PCR 0 depends on the software running in the firmware — what we normally call the BIOS. When you “update the BIOS”, PCR 0 changes. PCR 1 may change if you replace a hardware component. PCR 4 is tied to the operating system; it measures the boot loader and additional drivers. And so on.

PCR 7 depends on the Secure Boot state. Its values are commonly extended using the keys enrolled in Secure Boot, as well as the Secure Boot Authority. It is this PCR that we will use to unlock the disk, at this moment.

I will come back to PCRs in the next posts, but it is important to understand what they are for. If you decide to use what I am proposing in these posts, this knowledge may be useful if you run into trouble.

You can see all the events that led to PCR extensions by running sudo systemd-pcrlock log. Using jq, you can show only the events that led to PCR 7:

sudo /run/current-system/systemd/lib/systemd/systemd-pcrlock log --json=short 2>/dev/null | jq '[.log[] | select(.pcr == 7)]'

The result, simplified so it does not get too long, is this:

[
 {
 "pcr": 7,
 "pcrname": "secure-boot-policy",
 "event": "efi-variable-driver-config",
 "match": true,
 "sha256": "9f75b6823bff6af1024a4e2036719cdd548d3cbc2bf1de8e7ef4d0ed01f94bf9",
 "phase": "F",
 "component": null,
 "description": "Variable: dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f"
 },
 {
 "pcr": 7,
 "pcrname": "secure-boot-policy",
 "event": "efi-variable-authority",
 "match": true,
 "sha256": "f35567246a92b2fcdd2901e4ad2febdfd80173f25527c5a73033bf100a8eb980",
 "phase": "F",
 "component": null,
 "description": "Authority: db-d719b2cb-3d3a-4596-a3bc-dad00e67656f"
 }
]

Note that the hash value, stored in the sha256 field, changes with each event. When the TPM receives a request to decrypt a value, its state must match exactly what was used when the value was encrypted (this is done through TPM policies). That means a value encrypted early in the boot process may no longer be decryptable at the end of the boot process, if the PCR has been extended again. This is especially useful for this very reason: allowing a value to be accessible only at a specific point in the boot sequence, such as during initrd startup (PCR 11 has measurements that make this possible).

Systemd documents how it uses PCRs, and since nowadays there is practically no Linux without systemd, it is worth understanding. This document will be useful later, when we look more closely at PCR 15 (system identity).

Unlocking the disk during boot

Only one command is needed to make everything happen. In our case, since we have two disks and two partitions, we run the command once for each of them (you will need to enter your LUKS password for the process to complete):

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/disk/by-label/NIXLUKS1
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/disk/by-label/NIXLUKS2

When this command runs, the volume master key is obtained using your password. It is then encrypted (sealed) using the TPM, and this sealed value is stored in the LUKS volume header. In this case, only PCR 7 is being used to seal the value, meaning only the Secure Boot state. That means if the Secure Boot state changes (if it is reset, or if a new key is removed or added), the TPM’s PCR 7 state will also change, and the disk will no longer be decrypted during boot. In this post, the goal is to tie automatic disk decryption to the Secure Boot state, and that is what we have done.

You can see the details stored in the LUKS volume header by running the following command after systemd-cryptenroll has been executed:

sudo cryptsetup luksDump /dev/disk/by-label/NIXLUKS1

Notice the Tokens field, with the first one being systemd-tpm2, with a Keyslot:

Tokens:
 0: systemd-tpm2
 Keyslot: 1

To see more details about the sealed value, run:

sudo cryptsetup luksDump --dump-json-metadata /dev/disk/by-label/NIXLUKS1 | jq -r '.tokens."0"'

The result will look something like this:

{
 "type": "systemd-tpm2",
 "keyslots": ["1"],
 "tpm2-blob": "<a base64 value>",
 "tpm2-pcrs": [7],
 "tpm2-pcr-bank": "sha256",
 "tpm2-policy-hash": "<a hash>",
 "tpm2_srk": "<another base64 value>",
}

The tpm2-blob contains the value encrypted by the TPM (plus metadata). Using the tools from the tpm2-tools package and root access, you could recover the master password from this value. That is not a security problem: the system is already running and the disk is already decrypted. The purpose of TPM protection is not to protect a healthy running system from its administrator, but to protect against integrity violations that happen before, during, and after boot.

With just these two commands, the TPM will start unlocking both LUKS volumes. Reboot to confirm that it no longer asks for the password. If it does, inspect the boot logs with sudo journalctl --boot.

Is it secure?

Not yet.

There are two vulnerabilities, and I will address them in the next posts. Neither is trivial, but someone who understands how all of this works could gain access to the data in a short amount of time. None of the work done so far will be lost; we will build on the current solution. The good news is that both issues are easy to fix.

That said, it is fair assume that most people, including technicians who are not systems penetration experts, would no longer be able to read the disk of a computer encrypted this way. In other words, sending a laptop for repair with this configuration would probably not present a risk. But that is still not good enough.

In the next post we will start closing the gaps.