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


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.

| improve this answer | |
  • I'm not sure we CAN have a Core Root of Trust for Measurement. My understanding was CRTMs depended on access to a read-only chip that contained code that made the first PCR measurements... but our hardware does not have any such read-only chip (Intel Atom processor). If I was wearing my engineer hat instead of my infosec hat, I'd say that BIOS firmware can be the CRTM, but as it is I'm afraid to say that... am I being overly paranoid? If we don't have a CRTM, I can't see a way forward except encryption; no CTRM, and "refuse to boot unless PCRs" code could be maliciously ignored – user1733212 May 30 at 1:43
  • Encrypting the kernel does not add any security (in terms of boot integrity). There are two threats: A) Your kernel is tampered with. In this case, your BIOS can refuse to boot the kernel. It does not matter if your kernel is encrypted. B) Your BIOS (CRTM) is tampered with. In this case you can neither detect the corruption nor react to it. Your BIOS can decrypt your kernel or boot into any malicious software. It does not matter if your kernel is encrypted since the BIOS knows the key. Finally: if your CRTM really has to be read-only depends on your protection needs (and budget). – MemAllox May 31 at 20:09
  • So lets leave aside encryption for the moment; its only relevant (and only in my neophyte brain) if there is no way to protect against case B. So how do we protect against case B? Cyber-security directive is that our solution be tamper-proof (and rootkits were specifically named). And the Intel Atom doesn't support BIOS Guard; my understanding was this was the read only memory I described. see the table on page 4 – user1733212 Jun 1 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.