What kind of "actions" can a TPM2 policy authorize?

Question

I've been instructed to use the state of our system's TPM's PCR registers to prevent the system we're working on from booting if one of the PCR registers is different from what we expect. In service of that goal, I'm reading over this article: https://threat.tevora.com/secure-boot-tpm-2/

there is a paragraph near the middle that reads:

TPM2 has the ability to create policies based off of PCRs: If the PCR contents do not match expectations, the policy will not authorize the action.

What kind of actions are they talking about here? And what would be the immediate ramifications if the action was not authorized?

---

Some background: Before today, I was under the impression that the principle trick of the TPM was to encrypt or decrypt data using a key that the TPM holds securely. Now this article suggests that the TPM can also (two different functions) encrypt or decrypt data based on the current state of its' PCR registers... this seems similar enough to my previous understanding that I can believe it.

If my understanding is correct, I can see how this would be useful to our project's goals; encrypt a blob of data that is critical to the success of the boot (say... the kernel*) with the state of the PCR registers while the PCR registers are in a known-trustworthy state (i.e. while known-trustworthy software is loaded). If software that writes different PCR registers replaces the known-trustworthy software, then the kernel blob won't decrypt properly, and execution "halts". Presumably there are ways to handle this halting gracefully, like Bitlocker or LUKS; I imagine if I just encrypted executable code and then decrypted it with the wrong key, it would produce gibberish, and the machine would do unexpected things rather than halt gracefully when running that gibberish.

A co-worker has taken the position that there's a simpler way; that a TPM can permit or refuse an action directly... so, like, it halts the processor or something, I guess? He doesn't express himself very well, and when I tried to summarize his position he told me I got it wrong, so... I'm deliberately keeping the details of his position scant. Suffice it to say, my understanding of what a TPM does wouldn't allow for what he describes...

You could interpret the two sentences from the article as supporting his position, or mine, depending on what actions it is possible to ask the TPM to authorize, and what the immediate consequences ramifications of the TPM denying you the authorization to do something. Does anyone here have an opinion?

*...how would I "encrypt the kernel", exactly? :-p

Answer 1

TL;DR: you can prevent booting directly. However, not the TPM stops the boot process, but the last trusted component in your chain of trust (e.g. your bootloader).

A TPM is passive, i.e. it receives commands and executes them. The TPM cannot intervene with the boot process on its own.

Some TPM basics: typically, there are two features associated with PCRs: Sealing and Quoting. Sealing is tying a key to a known good PCR value, as you mentioned already. Quoting is reporting a PCR value (including a signature by the TPM to ensure integrity).

Of course you could encrypt the kernel (or your entire disk using LUKS). That's not really neccessary, though. Your bootloader could just measure the (unencrypted) kernel and refuse to boot any bad kernel. You do not need a TPM (nor a TPM Policy) for this. The bootloader, or to be more specific the initial piece of code which performs the first measurement, needs to be trusted at all times in a chain of trust. It is called the Core Root of Trust for Measurement (CRTM). If the bootloader was corrupted, it could just produce fake measurements leading to a successful boot (without any way for the TPM or any subsequent software to detect that).

You want to use a TPM for other reasons. Beside secure key storage, it's the job of the TPM to securely store measurements so they cannot be tampered with (especially after booting). Using remote attestation you can prove to a remote host that your PCRs hold good values. In fact, remote attestation is basically quoting with extra steps. There are many more things you can do with a TPM which I'm not going into for the sake of simplicity.

As for the actions authorized by policies: to perform actions on TPM entities (keys, data blobs, hierarchies, NV indices etc.), you may need policy authorization (depending on the entity's attributes userWithAuth and adminWithPolicy). There are many different entities with different actions, you cannot simply list them here. However, policy sessions only authorize actions on TPM-internal entities.