public inbox for tpm2@lists.linux.dev
 help / color / mirror / Atom feed
* Policies for nvindex based "fake" PCRs
@ 2024-05-29  9:15 Lennart Poettering
  2024-05-31  7:03 ` Andreas.Fuchs
  0 siblings, 1 reply; 2+ messages in thread
From: Lennart Poettering @ 2024-05-29  9:15 UTC (permalink / raw)
  To: tpm2

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-05-31  7:03 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-29  9:15 Policies for nvindex based "fake" PCRs Lennart Poettering
2024-05-31  7:03 ` Andreas.Fuchs

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox