[systemd-devel] unlocking LUKS volume using PCRs and UKI

[Felix Rubio]

Hi everybody,

Some months ago I tried to learn about systemd cryptenroll, ukify, etc., 
and I managed to get a UKI that gets updated every time the kernel / 
modules change by running:

######
/usr/lib/systemd/ukify --linux /boot/vmlinuz-linux --initrd 
/boot/amd-ucode.img --initrd /boot/initramfs-linux.img \
                          --os-release=@$OSRELEASE \
                          --cmdline="$CMDLINE" \
                          
--secureboot-certificate=/root/SecureBoot/MOK.crt 
--secureboot-private-key=/root/SecureBoot/MOK.key \
                          --output=$OUTPUTPATH/$UKIFILE build
######

To set up the unlock of the disk, I ran the following command (only 
once, as pcrs 7 and 14 have not changed since then):
systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7+14 
/dev/nvme0n1p5

Since then, systemd-cryptenroll has been extended so that literal values 
can be provided, meaning that (*I think*) I can upgrade my previous 
process to:
######
PCR11=$(/usr/lib/systemd/ukify --linux /boot/vmlinuz-linux --initrd 
/boot/amd-ucode.img --initrd /boot/initramfs-linux.img \
                          --os-release=@$OSRELEASE \
                          --cmdline="$CMDLINE" \
                          
--secureboot-certificate=/root/SecureBoot/MOK.crt 
--secureboot-private-key=/root/SecureBoot/MOK.key \
                          --measure \
                          --phases="enter-initrd" \
                          
--pcr-private-key=/root/SecureBoot/PCRsigning/tpm2-pcr-private.pem \
                          
--pcr-public-key=/root/SecureBoot/PCRsigning/tpm2-pcr-public.pem \
                          --output=$OUTPUTPATH/$UKIFILE build | grep 
11:sha256)
systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto 
--tpm2-pcrs=7+$PCR11+14 /dev/nvme0n1p5
######

Do you guys think this is a sensible approach? As I want to bind the 
unlock of the disk to PCR11, I think I only need to get the measurement 
of that PCR register in the "enter-initrd" phase, right? What are the 
implications of providing as well the pcr-private-key parameter? I have 
gone through the documentation of systemd-cryptenroll, systemd-measure 
and systemd's ukify, but is not clear to me if this set of flags will 
(besides providing the measurement I am interested on) also let the 
kernel continue booting only if the signed policy that gets calculated 
out of that register is fulfilled. Should that be the case, this 
additional control will not harm but I guess is a bit redundant for my 
use case?

Thank you very much for your time,

-- 
Felix Rubio
"Don't believe what you're told. Double check."