Administered by:
Here's the 2nd installment of posts highlighting key new features of the upcoming v257 release of systemd. #systemd257
In the past year and a bit I spent a lot of time on boot integrity (i.e. boot-time TPM measurements and policies built on top of them) of Linux, covering the boot from the boot loader (systemd-boot), over the UKI EFI stub (systemd-stub) through the initrd into early regular userspace, and then locking disk encryption to it.
If you ask me, it's a fundamental requirement for any modern Linux-based OS to provide boot time integrity and as baseline provide unattended disk encryption bound to it. To make this happen, we added two essential TPM policy concepts to systemd-cryptenroll/systemd-cryptsetup:
1. Signed TPM PCR policies allow locking a disk to a public signing key of an OS vendor, ensuring that disks can only be unlocked if an OS signed by said vendor is booted.
2. Dynamic, locally managed systemd-pcrlock policies cover everything else about the system boot, i.e. the aspects not defined by the OS vendor but inherently local to the machine, i.e. choice of local hw, local firmware, local configuration.
So far, you could only use one of these two policies, but not the combination of the OS vendor one *and* the locally managed one at the same time. But at least in my view that's the holy grail of boot integrity, …
… as it comprehensively covers the full boot stack, the stuff the OS vendor can control and the stuff only the local user/admin can control.
With v257 this restriction is removed: you may now use signed PCR policies *and* systemd-pcrlock policies together: simply use systemd-cryptenroll's --tpm2-public-key= and --tpm2-pcrlock= switches together.
It is my intention to make this good enough so that distributions eventually can default to enable this, …
… and finally provide boot security that is closer to what outside of traditional Linux is the state of the art.
And you might wonder why it took so long to combine these two policies, why this was a challenge. The simple answer to that is: because TPMs don't really allow such a combined policy. Iin TPM terms: you cannot combine a PolicyAuthorize and PolicyAuthorizeNV on equal footing into a single TPM policy. After discussing this at great length with various people who are smarter than me, the way out I came up with is to do key "sharding" instead.
That essentially means that there are not one but two unlock keys revealed by the TPM to the OS, and one is protected by one policy, and the other by the other. The concatenation of both keys is then actually used for the disk encryption, now double the length.
That is amazingly simple, even though the original problem seemed irritatingly hard to solve at first.
@pid_eins I guess there is something preventing me from first booting so that I violate the first policy and then booting so that I violate the second policy? And then once I the both secrets I can combine them to get the disk encryption key?
@lindi2 no there is not. Yeah, the sharding thing is not as good as having a combined policy. It would indeed be better if we could require that both parts of the key can only be unlocked at the same time, but I am not sure how to do that, without an update on the TPM spec.
@pid_eins I suppose with Intel TXT you could seal the secret so that only a special tboot/linux/initramfs combination can read the secret and that initramfs could then enforce the combine policy and kexec the target system? Super ugly for sure