RE: Policies for nvindex based "fake" PCRs

[<Andreas.Fuchs@infineon.com>]

Hi Lennart,

there is one further approach to do things:

- Upon boot, extend the NV-PCR by a secret initial extend value. Then document the resulting NV-content as the only valid initial state value.
- Thus, if someone attempts to delete and recreate the NV-index, they cannot recreate the initial state.

If your usecase is (only) remote attestation, then you can use a random initial extend value and use a "regular" pcr to document the aforementioned initial state (simple version).
If your usecase includes local attestation (PolicyPCR/PolicyNV), then you would have to store and reuse the initial extend value (could be sealed to the PCR state of a "regular" pcr value.

For remote attestation, you can of course not use TPM2_Quote anymore. The way to go here is the use of a Session with AuditDigest that performs a set of PCR_Read & NV_Read commands.

I hope, this helps your use case.

P.S. If your TPM_NT is _EXTEND, then you do not need a policy, since NV_Write is forbidden anyways.
P.P.S. I assume you are already aware of the TPMA_NV_CLEAR_STCLEAR flag.

Cheers,
Andreas

-----Original Message-----
From: Lennart Poettering <mzgcz2gff@0pointer.net> 
Sent: Mittwoch, 29. Mai 2024 11:15
To: tpm2@lists.linux.dev
Subject: Policies for nvindex based "fake" PCRs

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx>.



Hi!

As you all know there aren't that many PCRs available in TPM2. But supposedly we can define equivalent objects via nvindexes, and then do extensions via TPM2_NV_Extend.

I'd like to add support for this to systemd's measurement logic (since we'd like to measure more categories of stuff, but simply have no PCRs left right now). But what puzzles me a bit is how to do this correctly so that the access policy to the nvindex makes it behave like a real PCR and doesn't add weaknesses real PCRs do not have.

So I want a policy that allows reading and writing (via
TPM2_NV_Extend) unrestricted to anyone, just like PCRs. So much I guess is straightforward. But what concerns me is how to make sure that people cannot just remove my nvindex and recreate it during runtime, thus resetting it to zero freely. After all removal of nvindex is normally unrestricted too.

What would probably work is if I had an nvindex that is automatically deleted at reboot, but which would be blocked to be deleted otherwise. But I don't think such a policy can actually be defined.

I mean I could set TPMA_NV_POLICY_DELETE which would mean I need platform authorization to delete the thing, but this sounds less than ideal to me…

Any ideas how to make this work? I can't be the first one who actually wants to use nvindexes as fake PCRs? There must be some prior art?
Google didn't find me anything though?

Or do I have to enforce a policy on writing instead, for example PolicySigned with an HMAC key maybe, so that only "trusted" clients can write to the PCR and initialize it, and thus anyone who deletes wouldn't really gain much because they couldn't initialize it properly after recreating it? I mean, I guess that would work, but it's somewhat restrictive, no? And would make these nvindex "fake" PCRs quite different from traditional PCRs that anyone can write to.

Any help/suggestions appreciated on this!

Lennart