TPM and PCRs

[Michael Richardson]

Grzegorz Kulewski <gk at leniwiec.biz> wrote:
    > I know that gnupg supports TPMs (from 2.3 IIRC) via keytotpm command.

I have never used keytotpm myself, as yet.
(I am deep in the openssl provider interface, trying to use it with openssl-tpm2,
via ruby-openssl, to sign PKIX certificates, COSE/JOSE and CMS artifacts, and
eventually, yes git commits using some tbd openpgp tool)
(Also editor of RFC9334 Remote ATtestation procedureS (RATS) Architecture)

    > But AFAIK the main "selling point" of TPMs is binding encryption of
    > secrets to specific software versions and system state via hashes
    > (PCRs), so that the enrolled key is only accessible (may be "unsealed")
    > if specific trusted software and/or configuration is used.

It's the major selling point, but it's not really the only thing they are
good for.

    > 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 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 :-)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 511 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250905/6072706b/attachment.sig>