[systemd-devel] systemd-cryptenroll with TPM2

[Lennart Poettering]

On Mo, 21.08.23 19:56, Aleksandar Kostadinov (akostadi at redhat.com) wrote:

> Thanks, this is what I was also considering the feasibility of. And whether
> it made sense to begin with. Any idea how can this be done with systemd?
>
> In man I read:
>
> >       Note that currently when enrolling a new key of one of the five
> >       supported types listed above, it is required to first provide a
> >       passphrase, a recovery key or a FIDO2 token. It's currently not
> >       supported to unlock a device with a TPM2/PKCS#11 key in order to
> enroll
> >       a new TPM2/PKCS#11 key. Thus, if in future key roll-over is desired
>
> So I wonder if systemd already does that, or is it just an artificial
> limitation? Would be wonderful if it already did so.

It's just that noone implemented this. The unlocking code paths via
cryptsetup and in cryptenroll are quite different, which doesn't make
this trivial.

But pacthes welcome.

Generally, I am very much of the opinion that we shouldn't change the
disk whenever PCRs change. Instead we should use signed PCR policies
to accomodate for "clean" PCR changes (as mentioned in the other mail
in this thread), i.e. simply sign a new PCR policy if we learn about a
new "golden" PCR state we want to permit. This is much more robust and
scales better. Moreover, it makes it easy to invalidate old golden
states, by implicitly binding things to an nvindex counter object in
the TPM at the same time. Such rollback protection is kinda crucial I
am sure to guarantee security of non-interactive systems.

> P.S. Also another thing I was considering was that if I did this
> "extension", then I'm not sure how to then properly setup the sealing. But
> maybe with the signed PCRs support it can work as PCRs don't need to be in
> the expected state at configuration time. But also I want to do with as
> little modifications from defaults as possible. If I have to rewrite the
> whole thing, it will be hard but also I don't want to risk making mistakes
> that original scripts already avoid.

Neither for the literla PCR policies nor for the signed PCR policies
the PCRs actailly need to be in the state we expected states when
enrolling. Support for the former was recently added upstream.

Lennart

--
Lennart Poettering, Berlin