[systemd-devel] systemd-cryptenroll with TPM2

[Aleksandar Kostadinov]

On Tue, Aug 22, 2023 at 8:10 PM Lennart Poettering
<lennart at poettering.net> wrote:
> On Di, 22.08.23 19:16, Aleksandar Kostadinov (akostadi at redhat.com) wrote:
<...>
> > If attacker replaces volume with unencrypted one, and it boots without
> > messing up the sealing PCRs, then probably attacker can query the TPM
> > and obtain the encryption key. Despite the fact that this is not (yet)
> > implemented in cryptenroll.
>
> Sure, if you allow unencrypted systems to boot in your OS then all
> bets are off. You shouldn't do that of course.
>
> (in my model of mind, where automatic GPT image dissection is used the
> image dissection policies are how this should be locked down, see
> systemd.image-policy(7). You can confgure that via the kernel cmdline:
> in systemd.image_policy=.
>
> In systemd there's the "systemd-pcrfs at .service" and
> "systemd-pcrmachine.service" which will measure the identity of file
> systems and of /etc/machine-id into PCR 15. (systemd-cryptsetup also
> mesures a derivate of the volume key to PCR 15). PCR 15 is supposed to
> be an identifier of the OS instance.

Wait. I was looking at this PCR. But wouldn't it be set only after the
volume has been unlocked? This means that before a volume is unlocked,
it cannot protect anything? Actually it may protect in case where
attacker replaced the volume with another encrypted volume. But not if
attacker replaced with a plain volume.

Or is it measured with the *encrypted* volume key which would actually
protect from volume replacement of any sort (I think) and would mostly
solve my concern?

I mean if somehow the LVM structure including the encrypted key(s) are
measured somewhere, then such an attack should not be viable.

I guess I should test whether replacing the volume with non-encrypted
will work. If it works, then there might be an issue. If it does not
work, then sealing with PCR 15 might be what will get me going,
because replacing with an encrypted volume will definitely modify it
and block decrypting of the original key.

<...>
> > I didn't expect the unattended server TPM2 encryption to be such a
> > muddy ground. Probably because serious use cases also involve more
> > infrastructure and dedicated admins, etc.
>
> It is certainly my intention to make this all "just work" and "default
> on", even on consumer hw. Windows does it, so we should be able to do
> that as well.

Much needed! ♥

> Lennart
>
> --
> Lennart Poettering, Berlin
>