Re: PCR signing / enrolling on UKI and validation by systemd-cryptenroll

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

On Tue, May 28, 2024 at 10:55 PM Lennart Poettering
<lennart@xxxxxxxxxxxxxx> wrote:
>
> On Di, 28.05.24 21:21, Andrei Borzenkov (arvidjaar@xxxxxxxxx) wrote:
>
> > On 28.05.2024 17:49, Lennart Poettering wrote:
> > >
> > > systemd-cryptenroll supports pin, literal PCR, signed PCR — in any
> > > combination. (plus pcrlock, but that's currently cannot be combined
> > > with signed PCR, because afaics not expressible in the TPM policy language).
> > >
> >
> > Why not? You can AND pcrlock with other policies just like currently literal
> > PCR is ANDed with signed PCR. You can even use signed PCR in pcrlock policy
> > - PolicyOR does not care what policies are combined, literal PCR (like is
> > done currently) or signed PCR. Or what semantic do you have in mind that
> > cannot be expressed?
>
> pcrlock is ultimately a PolicyAuthorizeNV policy, and signed policies
> use PolicyAuthorize. Both of these policy items do not *extend* the
> policy so far enqueued, but *replace* it instead. (This is different
> from policies such as PolicyPCR or PolicyAuthValue and so on, which
> result in extension, i.e. "AND") Thus, there's not directly obvious
> way how you could combine them.
>

And? You *already* combine PolicyAuthorize with subsequent PolicyPCR,
that is exactly how you build a policy if both tpm2-pcrs and
tpm2-public-key-pcrs are provided. You already use PolicyOR (which
*replaces* the policy as well) in pcrlock. Why is it not a problem?

What you have now is

PolicyPCR(PCR1, PCR2, ...)
PolicyAuthorize
PolicyPCR(PCR3, PCR4, ...)
Unseal

If you use pcrlock for more flexibility it will change into

PolicyPCR(PCR1, PCR2, ...)
PolicyAuthorize
PolicyPCR(PCR3, PCR4, ...)
PolicyOR(digest1, digest2, ...)
PolicyAuthorizeNV
Unseal

I am sorry, I still miss the problem. Why is the former acceptable but
the latter is not? Where is the difference?

The reverse order is indeed more challenging. In this case we would
need to effectively sign a digest that indirectly includes pcrlock
PCRs which rather defeats the idea of separating the local registers
from remotely controlled ones.

> (you can of course include PolicyAuthorizeNV in the policy you sign
> for PolicyAuthorize, but that doesn#t work, since we want to pin the
> local nvindex really, and allocate it localy, and the signer (i.e. the
> OS vendor) cannot possibly do that. Or you could include the
> PolicyAuthorize in the policy you store in the nvindex for
> PolicyAuthorizeNV use, but that feels much less interesting since it
> means the enforcement of the combination is subject to local,
> delegated policy choices instead of mandated by the policy of the
> actual object we want to protect)
>
> I have so far not found a nice way out of this problem. Seems to be a
> limitation of the TPM policy language.
>
> Lennart
>
> --
> Lennart Poettering, Berlin