Thanks, this is what I was also considering the feasibility of. And whether it made sense to begin with. Any idea how can this be done with systemd?
In man I read: > Note that currently when enrolling a new key of one of the five > supported types listed above, it is required to first provide a > passphrase, a recovery key or a FIDO2 token. It's currently not > supported to unlock a device with a TPM2/PKCS#11 key in order to enroll > a new TPM2/PKCS#11 key. Thus, if in future key roll-over is desired So I wonder if systemd already does that, or is it just an artificial limitation? Would be wonderful if it already did so. P.S. Also another thing I was considering was that if I did this "extension", then I'm not sure how to then properly setup the sealing. But maybe with the signed PCRs support it can work as PCRs don't need to be in the expected state at configuration time. But also I want to do with as little modifications from defaults as possible. If I have to rewrite the whole thing, it will be hard but also I don't want to risk making mistakes that original scripts already avoid. On Mon, Aug 21, 2023 at 7:37 PM Mantas Mikulėnas <graw...@gmail.com> wrote: > 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 <akost...@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! >> >
