On Di, 22.08.23 19:16, Aleksandar Kostadinov (akost...@redhat.com) wrote: > > > I'm concerned though about an attacker replacing the encrypted root volume > > > with a non-encrypted one. Which may result in system booting an attacker > > > controlled environment while PCRs may be in a state that allows decryption > > > of the original root volume. > > > > > > Would anything prevent the system from booting with a replaced root > > > volume? > > > > Well, when you bind your disk to the TPM then this means you place a > > TPM-encrypted key in the LUKS header. This key has to be passed to the > > right TPM to be unlocked. This means that if an attacker just has the > > disk it's hard for them to acquire the decrypted key if it lacks the > > TPM. But it also means that if an attacker wants to replace the disk > > its very hard to forge key that is locked against that specific TPM. > > 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@.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. > > It analyzes the UEFI TPM event log (which lists all measurements made > > to PCRs), tries to recognize components in it safely. And then is > > supposed to use that to generate signed PCR policies from that, based > > on a keypair stored on the local TPM, that is itself protected by one > > of its own signed PCR policies. > > > > In the long run the way I envision this we'd have two signed PCR > > policies in place: > > > > 1. A vendor supplied one that covers the UKI and its resources (this > > already pretty much exists), i.e. PCR 11. This one is pre-computed > > at build time of the OS and hence can only cover resources known at > > that time. > > > > 2. A locally maintained one on the individual system, based on a local > > key, that covers everything inherently local that is hard to > > predict from the outside (and for good measure also covers the > > vendor supplied stuff, because why not). This would then cover PCRs > > 0-7, 9, 11-13, 15, i.e. everything that is reasonably stable > > locally. > > > > Alas, as mentioned this is WIP, still. > > 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. Lennart -- Lennart Poettering, Berlin
