Re: Enrolling PCR11 does not work as expected

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mi, 05.07.23 13:11, Felix Rubio (felix@xxxxxxxxx) 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