First of all, I must say that I'm using a VM with an emulated TPM 2.0.
I've created an LUKS2 encrypted partition and configured the TPM 2.0 to unseal the key only if the PCR 7 has a certain value.
For what I've understood so far in the PCR 7 are stored the secure boot policy, so while secure boot is active the sha1=F7... but when is turned if is like sha1=DF...
The problem is that from my first measurement I've switched secure boot on and off a couple of times but the hash is always the same when it is on, sha1=F7....
This is in contrast with what written in "A Practical Guide to TPM 2.0":

PCR new value = Digest of (PCR old value || data to extend)

Is the PCR 7 an outlier about this formula? Or is the fact that I'm using a VM with an emulated TPM 2.0?

1 Answer 1


PCRs are set to their initial values every time the TPM resets. Then items are extended to them as BIOS/UEFI code runs. This is described in the PCR value section of Chapter 12 of the book you reference.

The TPM initializes all PCRs at power on, typically to either all zeroes or all ones, as specified by the TPM platform specification.

You want PCR values to operate this way. When Secure Boot is On, it's consistently one value, when it's Off, it's another value. That lets LUKS auto-unlock when Secure Boot is On, but prompt you if someone turns Secure Boot Off. Similarly, if you bind LUKS to PCR[0], it would only unlock if you have the same BIOS. This also allows you to pre-calculate PCR values if, for example, you wanted to update your BIOS to a new version, you can create a policy where LUKS would unlock if PCR[0] has the measurement of your current BIOS or the new one. Then once you've booted successfully to the new BIOS version, you can update the policy to only use the new PCR[0] value.

  • Thanks for your reply but maybe I've explained poorly my problem. In my case when The Secure Boot is enabled I have the TPM[7] in a state called S1, then the TPM[7] changes into a state S2 because the Secure Boot is disabled. The problem arises when I turn on the Secure Boot again and TPM[7] returns to S1 instead of going to a new state S3.
    – Blasco
    Commented Feb 29 at 7:28
  • That's how it's supposed to work. If you change nothing else that's measured into PCR[7] except whether Secure Boot is enabled or disabled, then you'll have two PCR[7] values, one corresponding to enabled (S1), one to disabled (S2). You'll only get a new state if you change something else. What security property or behavior are you trying to obtain by knowing whether UEFI Secure Boot was on, turned off, and then turned back on? If you configured UEFI Secure Boot properly, then you ideally wouldn't care whether someone had turned it off. The disk only auto-unlocks if it's on.
    – gilb3rt
    Commented Feb 29 at 19:03
  • Yeah, the disk auto-unlocks if and only if it's on. But I'm still confused by the "new digest formula". I'll deep dive a bit more into the PCR new digest composition, thanks anyway.
    – Blasco
    Commented Mar 1 at 7:55
  • The main thing to remember is that every boot, TPM PCRs get reset to default and then built up again by BIOS and other software extending events into them using the formula you mention. So, all else being equal, one boot doesn't influence another (thought PCR[4] does measure boot attempts).
    – gilb3rt
    Commented Mar 5 at 22:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .