[systemd-devel] systemd-cryptenroll with TPM2

[Lennart Poettering]

On Di, 22.08.23 22:35, Aleksandar Kostadinov (akostadi at redhat.com) wrote:

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

As I said earlier: if you don't encrypt you lost anyway. This is not a
scenario I care about in my view of the world. And frankly, it really
doesn't make much sense to try to lock down boot but not actually
encrypt the disk...

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

No, we measure the decrypted volume key (or actually, we measure the
result of an HMAC of a fixed string, keyed by the volume key, since we
don't want the key to show up in measurement logs in any useable way).

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

LVM? what's LVM got to do with anything?

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

In my view of the world you have an authenticated + measured UKI that
unlocks the encrypted root fs, and simply refuses to boot if the root
fs is not encrypted with a key it can acquire somehow. This should
give you all the protection you need.

Lennart

--
Lennart Poettering, Berlin