[systemd-devel] Enrolling PCR11 does not work as expected

[Felix Rubio]

In order to achieve the check of a number of PCRs, what do you guys 
think of this approach?

1. When running ukify, add the "measure" flag so that the expected value 
of the PCR11 is printed.
2. Then, script the reset of an unused PCR (in my case, 23), and the 
extend it with the current value of PCRs 7 and 14, and the expected 
value of PCR 11
3. Run systemd-cryptenroll against PCR 23
4. add a configuration drop to 
/etc/systemd/system/systemd-cryptsetup at .service.d, so that at ExecPre a 
similar script of that in 2 is run, but in this case resetting PCR 23 
and extending it with the actual values of PCRs 7, 14 and 11.

Do you guys this approach is sound?

Thank you,
Felix

On 2023-07-05 14:26, Lennart Poettering wrote:
> On Mi, 05.07.23 13:11, Felix Rubio (felix at kngnt.org) wrote:
> 
>> For what is explained on the the systemd-pcrphase.service(8) and 
>> comparing
>> it to what I see in the log of the systemd services, there are three 
>> events
>> in relation to this question:
>> 
>> systemd-pcrphase-initrd.service
>> [...]
>> [systemd-ask-password-console.service]
>> [...]
>> systemd-pcrphase-sysinit
>> systemd-pcrphase
>> 
>> This means that, indeed, running cryptenroll after the new kernel has 
>> booted
>> will never provide the correct PCR registry for 11. But then... what 
>> options
>> do I have? Do I need to choose between having PCRs 7 and 14, so that I 
>> make
>> sure that SB is up and running and all the certs from shim have not 
>> changed,
>> or to have only PCR 11 so that I know that the UKI has not changed 
>> although
>> SB can potentially be even disabled (please, correct me if wrong)?
> 
> The idea is that with systemd-measure you sign the pre-calculated PCRs
> for all phases you care about with a key, and then you use enroll the
> public key that matches that signature in the disk encryption, rather
> than literal PCR values.
> 
> Using signed PCR policies enables you to do multiple things at once:
> 
> 1. You can easily enroll one public key, and have it cover multiple
>    phases of the boot, simply by providing multiple signatures for the
>    PCR values expected in the various boot phases.
> 
> 2. You can easily enroll one public key, and then update the UKI and
>    still boot up correctly, by providing a new set of signatures for
>    the new expected PCR values for the various boot phases.
> 
> Hence, the PCR 11 logic we have in place is *not* designed with TPM
> policies that bind to explicit PCR values in mind. Instead it is
> designed in mind with policies that bind to public keys that match
> signatures of those PCR values.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin