new pcrlock tool for generating signed PCR policies for PCR 0, 1, 4, …

[poettering]

We already support signed PCR policies based on UKIs, computed at UKI build time, based on PCR 11.

This adds a second mechanism for signed PCR policies, covering evreything local, i.e. the firmware, and boot PCRs. The idea is to analyze the event log, identify components of the boot, then use it to precalculate a set of expected PCRs. Then generate a signing key pair, store it in the TPM, lock it down with a signed PCR policy of itself against the PCRs. Whenever a PCR change is expected we can generate a new access policy for the next boot.

This is heavily WIP. Currently only event log analysis is implement and pre-calculating expected PCR measurements. On typical systems this covers 95-100% of the events measured.

Next step is to use this analyze to calculate all expected PCRs and then generate a PCR policy for this.

I am posting this mostly to get initial CI coverage. No ready for review, but it's already a lot of fun to play with the analysis so far.

[arianvp]

Haven't had the time to fully review this yet; but I wanted to share the following link about avoiding footguns whilst verifying the event log.

https://github.com/google/go-attestation/blob/master/docs/event-log-disclosure.md

We should really carefully review the code that makes trust decisions based on the event log contents. As multiple event logs can lead to the same PCR values and this allow a smart attacker to tamper with the event log without the user noticing.

But from my initial reading of the code we're only using the event log to re-calculate the PCRs. Not actually trusting any of the other fields as trusted. So maybe this is not a concern at all.

[poettering]

But from my initial reading of the code we're only using the event log to re-calculate the PCRs. Not actually trusting any of the other fields as trusted. So maybe this is not a concern at all.

so there's three cases where we do use the event log for more:

1. "systemd-pcrlock lock-firmware-code"
2. "systemd-pcrlock lock-firmware-config"
3. "systemd-pcrlock lock-secureboot-authority"

These three validate the event log and then generate policy for future boots from it by reusing the hashes listed in the event log.

In case of lock-firmware-code + lock-firmware-config we'll do so blanket for PCRs 0-3, and up to the separator record for PCRs 4,5. The separator record is hard to fake though, since the hash is about a fixed string, and we validate that. People cannot just tag arbitrary records with EV_SEPARATOR, it must also have the right contents. For PCR 4 we also accept the EV_ACTION with "Calling EFI Application from Boot Option" as point where we stop copying records. This is optional however, as some systems appear not to generate it (in contradiction to the spec afaics). Situation is similar here though.

In case of "lock-secureboot-authority" we'll generate policy records from all EV_VARIABLE_AUTHORITY records we find. Here too, the contents is protected by the hash. We do some further checks, such as ensuring the other mesaurements in PCR 7 are in order, i.e. PK, KEK, db are all measured, and in the right order, beofre the first EV_VARIABLE_AUTHORITY.

We could go further on EV_VARIABLE_AUTHORITY (and I think Windows does), by ensuring the data in it is always a subset of the "db".

But I think we are fairly well protected here so far. While you can corrupt the event log it should be hard to do so in meaningful ways.

Also, note that this is not a remote attestation situation, but local only. Or in other words: we very much trust the source of the event log here, it's the kernel and firmware, i.e. stuff we have to rely on anyway.

[poettering]

All points addressed.

[poettering]

I posted an issue on fwupd, in the hope we can convince them to supply expected firmware PCR measurements as .pcrlock files to us:

fwupd/fwupd#6318