TPM and PCRs

[Michael Richardson]

Grzegorz Kulewski <gk at leniwiec.biz> wrote:
    >> 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

I'm not intimately familiar with sealing based upon PCR state.
I would hesistate to go this direction because PCR state is rather fragile.
(Annoyingly so, and I suspect unnecessarily so)
It depends upon the amount of ram installed, BIOS/UEFI options!
I think that in some cases, having a bootable USB key inserted, even when
it's not used for boot, can change things!

    > /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.

I think that one would have to use some tpm2_ or tss-* tools to configure this.
I think that after that, it's just a question of having the interface,
probably the PKCS11 interface can be used...

The abrmd process can mitigate access to /dev/tpm*, and that's mostly how
you'd want it.
Otherwise, one would be relying on just group permissions on /dev/tpm*.
Going via the abrmd allows for the possibility of a richer ACLs in the future too.

    > 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.

To be clear: secure boot is when each stage verifies a signature on the next
step of boot.   The *public* root of trust key can be stored in a TPM for
integrity protection.  Or burnt into a ROM.  Many microcontrollers have
eFuses for this purpose.   PCRs are generally used for *measured* boot,
where each stage measures (SHA256 hash, etc.) the next stage, but does not
know how to verify if it's correct or not.  This is significantly more
democratic.

    > 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

You can do either.
TPMs have historically had very limited space for keys, so, yes, one seals
the private key with the TPM, and then stores the encrypted blob on disk.
But, that space is growing, and fTPMs (a software TPM running in a SGX or
TrustZone or other TEE) often have significant space, but obviously how much
flash they have access is not infinite.  And that flash has to sealed.

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

It's true, I made assumptions.
I mean, do you even like cats?
And did those cats even consent to have their image used in that way? :-)

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

Yes, I completely agree that this is a desired thing.

    > 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

And just to be clear: in this case, there is often an interaction with the
company's Verifier before the VPN key is unlocked.
This interaction is often not easily visible.
ActiveDirectory is involved.   My understanding is that the user login to
laptop also unlocks a kerberos ticket that contains the unseal key.
(But I'm priviledged to have never really run windows)

    > 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.

All good reasons to have many different kinds of keys.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- 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/e3629904/attachment-0001.sig>