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