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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mi, 29.05.24 14:48, Demi Marie Obenour (demi@xxxxxxxxxxxxxxxxxxxxxx) wrote:

> > > > (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)
> >
> > this here is where i discuss what you are saying ^^^
> >
> > so technically this works, but this means objects are effectively
> > protected by local policy only. And whether to also protect by OS vendor
> > policy is then a choice of the local policy, but not a choice of the
> > original object's policy anymore. Or in other words: that shifts
> > around who owns which part of the policy. Ideally we want that when I
> > create a protected object in the TPM I can say: "to unlock this you
> > *must* validate OS vendor policy *and* local pcrlock policy". But you
> > cannot do that. You can only say "to unlick this you *must* validate
> > local pcrlock policy", and then hope that that local policy also
> > enforces validation via OS vendor policy.
>
> What about combining two different secrets, such that _both_ must be
> accessible?  At a minimum, something like HASH(SECRET1||SECRET2) is
> guaranteed to be available if and only if both SECRET1 and SECRET2 are
> available.  This won't work with TPM-bound keys that are not accessible
> outside the TPM, but my understanding is that the most common cases
> (LUKS and fscrypt keys and systemd credentials) must be accessible in
> cleartext on the host _anyway_.  If the secret to be sealed is provided
> externally, then one can use symmetric encryption with a randomly
> generated key to have the same effect.

Hmm, this is an interesting idea, I kinda like it. But I am not sure
how far this will get us, because I think even for FDE we eventually
want to store asymmetric keys, not symmetric ones (i.e. I think we
should start supporting things like TPM2+FIDO or TPM2+PKCS11 or
TPM2+ssh-agent where both devices operate in tandem, in a challenge
response model, not sure how far you get with that if we can only
protect symmetric keys)

Lennart

--
Lennart Poettering, Berlin