On Mo, 21.08.23 19:56, Aleksandar Kostadinov (akost...@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
