# \[GUIDE\] Setup TPM2 Autodecrypt

**URL:** <https://community.frame.work/t/guide-setup-tpm2-autodecrypt/39005>\
**Category:** Linux\
**Created:** [October 29, 2023, 5:41pm UTC](https://community.frame.work/t/guide-setup-tpm2-autodecrypt/39005 "2023-10-29T17:41:13Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![Silntknight](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/silntknight/32/24995_2.png) [@Silntknight](https://community.frame.work/u/Silntknight)\
**Post date:** [March 6, 2025, 11:23pm UTC](https://community.frame.work/t/guide-setup-tpm2-autodecrypt/39005/23 "2025-03-06T23:23:42Z")

</div>

I’m having a bit of trouble with parts of this. PCRs 0 through 7 all work fine for me, but I can’t seem to get 15 working with either the machine-id or the LUKS volume key measurements. From a couple of different sites, it looks like not having a userspace verification can lead to compromising the TPM key, so I would like to get this resolved.

I enrolled my TPM with PCRs 0+1+2+3+5+6+7. I am using a UKI, self-signed, so I excluded 4, 9, and 11 intentionally since they are covered by 7, from what I understand, and including 4 would cause my password to be required every time I updated the `initramfs`.

When I try to add 15 to the mix, my password ends up always being required, even though it matches on each boot. I checked with both `systemd-analyze pcrs` to compare the hash values in PCR 15 before and after making the change, as well as with `systemd-pcrlock log`, which indicates that the machine-id key matches.

If I try to add the LUKS volume key hash to the mix, things get even stranger. It still doesn’t work, despite the hash values being correct once the system is booted, but if I use `systemd-pcrlock log`, it provides a different hash for the LUKS volume key than the one in the PCR. Basically, the scenarios below are the ones I tested, none of which work. After enrolling the TPM, I regenerate the `initramfs` with `mkinitcpio`, which generates a UKI at `/boot/EFI/BOOT/BOOTX64.efi`

# Scenario 1 - PCR 15 with just machine-id

`systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm-pcrs=0+1+2+3+5+6+7+15 <partition>`

# Scenario 2 - PCR 15 with machine-id and LUKS volume key

`systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm-pcrs=0+1+2+3+5+6+7+15 <partition>`

Kernel command line also has `rd.luks.options=tpm2-measure-pcr=yes`

# Scenario 3 - PCR 8 with just LUKS volume key

`systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm-pcrs=0+1+2+3+5+6+7+8 <partition>`

Kernel command line also has `rd.luks.options=tpm2-measure-pcr=8`

This particular scenario also causes `systemd-pcrlock log` to indicate that the calculated hash value for my volume key _does not_ match with the value stored in the PCR. I also attempted this with PCR 23 instead of 8 to the same effect.

# Scenario 4 - Adding LUKS volume key at all

`systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm-pcrs=0+1+2+3+5+6+7 <partition>`

Kernel command line also has `rd.luks.options=tpm2-measure-pcr=8`

Despite not binding the TPM to PCR 8, if I have `systemd-cryptenroll` store the hash value to a PCR (8, 15, and 23 tested), I am asked for the password.

System information:

```auto
Framework 16 | BIOS 3.05
Arch Linux | Linux Kernel 6.13.5-arch1-1

```

---

_[View the full topic](https://community.frame.work/t/guide-setup-tpm2-autodecrypt/39005)._