linux_tpm_pcr_registry.md

[kgoldman]

Regarding this registry: It correctly observes that PCRs are a scarce resource. However, it then appears to claim PCR 11-15.

What is the rationale for using so many PCRs? Typically, one would use multiple PCR if one was sealing to a subset of all the measured events. The seal would use early measurements. For attestation, there is little advantage to using multiple PCRs.

[bluca]

Attestation is not the only use case, there's also sealing secrets, for example to encrypt volumes or credentials

[bluca]

In fact we should go in the opposite direction, and use more separate measurements by "owner", so that we can reliably predict them and pre-seal off-box.
We should move towards using signed policies in protected variables as we talked about a few times, to create "pseudo"-PCRs, so that we are not limited by the ~20 that are available.

[poettering]

@kgoldman PCR 15 for example is supposed to contain measurements of various ids identifying the system (/etc/machine-id, fs uuids, luks volume keys of system volumes, and similar). the idea is that these are measured during boot, and then allow enrolling resources to "this specific system" by binding it to PCR 15, and knowing that if you bind stuff to that the resource won't be able to be unlocked on any other system.

PCR 11 otoh is about the local software, so if you lock against that, then you bind against a specific set of software, because this is what relevant OS software is measured into (kernel, …).

with that combination you can then express stuff like "hey, bind this resource to the local system and this software", and resources can be unlocked any time during runtime, if desired.

by separating pcr11 and pcr15 you can pre-calculate the values easily. pcr 11 can be pre-calculated by the os vendor (so that it can provide a PCR signature even), while PCR 15 can be pre-calulated locally only, and is going to remain stable even across sw updates.

In your model where you use a single pcr for everything you cannot possibly pre-calculated stuff reliably so that it remains stable across updates (as for our PCR 15) or can be pre-calculated by the vendor already (as for our PCR 11). Your model might be ok, if you neither intend to use signed PCR policies, or if the distinction between "vendor resources" and "local resources" doesnt matter, and if you are happy to re-enroll all the time.

[kgoldman]

If the chain of trust goes from 15 to 11, 15 doesn't provide security by itself, right?
I just have an overriding concern that there may be no PCRs left for anything else.

[bluca]

Yes, the extremely limited PCR space is an issue, hence why we should really move past PCRs for this - but it can only be a very long term goal ofc

[poettering]

PCRs are in a way a legacy concept, you can build pcr-like objects in TPMs too. So yes, true PCRs are a scarce concept, but for other stuff we have a way out.