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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Do, 30.05.24 22:43, Lennart Poettering (lennart@xxxxxxxxxxxxxx) wrote:

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

Eh, I might have figured out a way how I can do this, somewhat
inspired by this:

TPMs implement hierarchies of keys after all where each key is wrapped
by its parent, and you can apparently nest things pretty liberally, to
as many levels as one likes.

So here's what systemd's TPM2-based FDE does right now:

When enrolling: it ensures that a "storage root key" (SRK) exists on
the TPM. It then loads the plaintext FDE encryption key as a symmetric
key into the TPM, so that it is "wrapped" by the SRK. It then reads
back the wrapped (i.e. encrypted) key (this is called "sealing") and
writes that to the LUKS superblock. When unlocking we take that
wrapped key, load it back into the TPM and then read back the
plaintext key (this is called "unsealing"). Since the SRK is specific
to the TPM only the TPM can give us access to our FDE key. This model
is then enriched with TPM2 "extended policies" which we set while
sealing and which tell the TPM to insist that during unsealing the
PCRs are in a specific state.

So much so good. This allows us to define *one* extended policy for the
FDE key. And as mentioned that's a problem for us, because we'd like
to define *two* extended policies (i.e. the pcrlock one, and the
signed PCR one). But if we take benefit of the fact we can wrap keys
arbitrarily we can do it like this:

when enrolling: as before, take care of the SRK. But now generate
another key, wrapped by the SRK and with our first policy built into
it. And then seal the FDE key against that "intermediate" key, and
build our 2nd policy into that sealing.

To unlock we then first have to load the intermediate key (which will
just work) and then load the FDE key below it (which will require us
to fulfill policy 1) and then the unseal the FDE key (which will
require us to fulfill policy 2).

Unless I am missing something this should work and do exactly what I
want: I can combine policies arbitrarily.

Lennart

--
Lennart Poettering, Berlin