On Sa, 25.05.24 09:00, Felix Rubio (fe...@kngnt.org) wrote: > Hi everybody, > > For some time now I have been using UKIs, with SB enabled and tying FDE > decryption on PCRs 7+11+14, with the PCR 11 being measured during UKI > creation. Then, I use systemd-cryptenroll to update the secret: > > ######## > PCR11=$(/usr/lib/systemd/ukify -c /etc/kernel/uki.conf --measure > --output=/tmp/arch-linux.efi build | grep 11:sha256) > systemd-cryptenroll --unlock-key-file=/root/creds/fdepassword.txt > --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7+11:sha256=d05ee4...+14 > /dev/nvme0n1p5 > ######## > > This works, flawlessly. Now, I am exploring the possibility to not bind to > the value of those PCRS but to their signature, given that I am also > embedding that in the UKI (the correspondent .pcrsig section is in place). > However, I am a bit lost: > * in .pcrsig there is only the signature for pcr11, and there seems to be no > way to embed the signatures for other PCR values.
systemd-measure/ukify doesn't support embedding anything else, since those measurements do not depend on the UKI but on external factors, hence it makes little sense to include them in the UKI pcrsig section, except for specialist cases where you know your hardware/systemd very well and never update it separately from the kernel. > * when used in cryptenroll, how should I use this? So far, seems should be a > call like > ######## > systemd-cryptenroll --unlock-key-file=/root/creds/fdepassword.txt > --wipe-slot=tpm2 --tpm2-device=auto > --tpm2-public-key=/root/creds/tpm2-pcr-public.pem > --tpm2-public-key-pcrs=<what?> > ######## > > ... but then I do not see what should be provided in tpm2-public-key-pcrs. > The same values I am currently giving to --tpm2-pcrs? the signatures that I > get from the .pcrsig for 11 + the calculated signatures for the current > values of the PCRs 7 and 14? You can specify whatever you like there, as long as you then can provide the right signature files. Thing though is that systemd-measure/ukify won't prep those signatures for you, you'd have to use a different tool for that. (Or prep a patch teaching literal PCR specifications in systemd-measure, we would be open to merging this I guess). Or in other words: there are three parts to signed PCR policies: 1. enrollment 2. unlocking 3. signing Of these steps 1 + 2 as implemented in systemd should just work for PCRs other than 11. But step 3 is simply not. That all said, With recent systemd versions we added "systemd-pcrlock" that is supposed to cover other PCRs than 11 nicely, maintaining a local policy (which I think is much preferable for the other PCRs, since they are dependent on local configuration, hardware and so on, not OS constructs). Lennart -- Lennart Poettering, Berlin