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@.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@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
