[systemd-devel] systemd-cryptenroll with TPM2

[Mantas Mikulėnas]

Have your initramfs *extend* a PCR after it retrieves the key from the TPM,
before it switches to (or even unlocks) the rootfs. As most PCRs cannot be
rolled back without a reboot, this would prevent the key from being
unsealed from a running system even if it manages to boot (without causing
the initramfs to fail earlier). Systemd already has some tools for this;
see "systemd-pcrphase".

On Mon, Aug 21, 2023, 17:40 Aleksandar Kostadinov <akostadi at redhat.com>
wrote:

> Hello,
>
> This is more of a user question but I didn't find any other suitable forum
> to ask.
>
> I want to install a server that should have an encrypted root but be able
> to reboot unattended.
>
> systemd-cryptenroll with TPM2 looks like a viable option. I'm concerned
> about which PCRs to pin so that an average attacker  won't be able to
> decrypt the volume having physical possession of the server. This means I'm
> not concerned about cracking the TPM chip or reading out life memory.
>
> To me it is acceptable to pin a lot of them so that adding/changing
> devices would prevent automatic decryption. Also 5 looks good about changed
> GPT partitions.
>
> 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?
>
> If it can boot in such a way, which PCRs need to be pinned to remove the
> ability to decrypt the original root volume?
>
> If there is presently no such PCR, can some custom validation be added in
> the process to take care of that?
>
> Thank you!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230821/bb303133/attachment.htm>