TPM and PCRs

[Grzegorz Kulewski]

W dniu 05.09.2025 o 21:36, Michael Richardson pisze:
> Grzegorz Kulewski <gk at leniwiec.biz> wrote:
>     > Does gpg supports binding keys to PCRs' state? Are there any plans to
>     > add such feature? Is it possible to somehow work it around before it is
>     > implemented?
> 
> You are kinda asking the question wrong.
> GNUPG is just an application; it has no special priviledge with the TPM.
> 
> The question you should ask: are there TPMs and/or priviledged TPM interactions
> where a GNUPG private key could be unsealed by TPM only once the system is in
> a known trustoworthy state?
> I think that the answer is sorta.
> 
> The evaluation ("Verification") of whether a final state PCR
> (Evidence) is valid or not generally something that occurs locally: You can't
> trust a trojan'ed system to claim to not be trojaned.  While measured boot
> depends upon a root of trust, and that part usually involves a secured boot,
> if one wants to do secure boot all the way, then it leads to profound vendor
> lock-in, and "treasurous computing", that's really the only way to build a
> system that independantly can be judged as to whether or not it's in the right state.
> 
> So in *this* model, you could imagine some thing returned from the Verifier
> that would allow a priviledged process to ask the TPM to unseal something.
> I'm unaware of any existing system that does exactly this, but that's probably just
> my limited knowledge.
> 
> My understanding of how TPM-enabled LUKS and MS Bitlocker work is that the
> main (disk) decryption key is stored in the TPM.  It's only protected because
> the TPM is not the main CPU (or is a TEE of the main CPU, if fTPM), and
> ability to talk to the TPM is restricted.   Attacks on this have involved
> hardware access to i2c bus; there are ways to defend against this by
> encrypting that bus using the EK, but in that case, the main CPU has to have
> a copy of the EK public key somewhere safe.

I am not an expert but AFAIK when sealing a secret in TPM you can bind it to some PCR state (or not). I believe any code that can open TPM /dev can do this, not something "privileged". But if gpg doesn't do it then the secret is not protected by any "verified state" bindings and nothing (except improving gpg and sealing that key again) can be done about it. But maybe I am wrong. I see no option to tell gpg to bind the key to some PCRs - that's why I am asking about plans to implement such feature.

Yes, AFAIK using PCRs is only possible (and makes sense) when secure boot is enabled. Of course security of such "verified state" depends on perfect (or good enough) implementation all the way from TPM and CPU via UEFI, bootloader, kernel, initramfs to root fs verification. So it's probably not 100% perfect and can have a lot of holes. But it's the only thing (except maybe PIN, if it's used and if it's still secret) that can potentially stop attacker from just booting some LiveCD and unsealing and using the key there.

AFAIK in most (all?) cases keys are not stored in TPM but only sealed (encrypted) by it and stored on disk and then unsealed (bound state is verified, if any, key is decrypted and loaded into TPM so it can be used to do further crypto).

Not sure about rest of your message and it's relevance to my original question.


> I suspect that your ultimate goal might be better satisfied with a USB
> connected secure element, with the ability to physically remove it from the
> system.   An ummarked USB secure element key in a locked drawer full of USB
> keys containing endless pictures of cats is what I'd do :-)

Not sure how do you know my goals from my original post. :-)

Basically we _are_ using USB SEs too. They are "user bound" (user is supposed to carry them all the time) and they often require physical interaction to unseal the key. But for some keys it's more convenient for them to be "machine bound" (forever bound to some computer and only usable if the computer is in a "valid secure state", not necessarily when user is physically present). That's why using TPM is convenient in those cases. For example you may want to store your company VPN key in the TPM (and only allow it to be unsealed if company approved OS is booted and wasn't tampered with) while storing your normal SSH/e-mail/whatever keys in USB SE. If some service (SSH for example) requires both VPN and such USB key you are basically getting double protection. Also note that in such cases some operations (for example backups via VPN) can happen when computer is booted and the TPM key is unsealed but the user and their USB SE can be away while some (for example SSH login via VPN) require both "secure computer" and "physical presence of the user" - it's a matter of policy planning and configuration.

-- 
Grzegorz Kulewski