Implement forward sealing of firmware upgrades

[tlaurion]

Sharing @marmarek idea posted here:

High level effect: preserve TOTP/HTOP secret, _if the firmware update is
properly signed_. This include two things:
 - verifying firmware update signature (probably independently of
   coreboot's vboot)
 - if signature is ok, calculate expected PCRs values of the new firmware
   and seal the secret to them

This "forward sealing" is supported by OpenXT, so it may be a good idea
to take a look at how they do that in details. Some documentation is
here:
https://openxt.atlassian.net/wiki/spaces/TEST/pages/76910241/Forward+Seal+Test+Procedures
https://openxt.atlassian.net/wiki/spaces/DC/pages/77302339/TPM+2.0
(AFAIR they had this for TPM 1.2 too)
The actual script for this (OpenXT specific):
https://github.com/OpenXT/xenclient-oe/blob/master/recipes-openxt/openxt-measuredlaunch/openxt-measuredlaunch/seal-system

If you'd like to tackle this, I can connect you with OpenXT people
and/or forward some questions.

[tlaurion]

@pietrushnic: an interesting idea to keep in mind for the fwupd project and measurements strategies to be adopted under #721

[tlaurion]

The idea is feasible, implementation is difficult. Had put some thoughts into it... And this is the resulting brain dump.

PCRs usage under heads.

PCR 2: coreboot regions
Quite easy for the same coreboot version. Upgrading to a newer coreboot version would not guarantee the same regions are measured. I have done PoC for that. It involves taking the firmware to flash, and basically take the output of current cbmem -L and wrap around the files measured by coreboot in their TCPA log: bootblock, romstage, postcar,ramstage,cpu_microcode_blob, vbt, dstd.aml and finally payload (for the x230 with measured boot).

For other platforms, the list can be extended, depending if vboot is used or not. If FSP blobs are present etc.

PCR-3: MRC cache. Hard to tell if measurements would be the same between upgrades, while maximized builds are wiping the cache and is retrained on first boot (while not measured on x230, but would vary between platforms.
Not sure that part can be resolved and not sure how others deal with that, if they do.

In theory, we would expect the same regions to be measured when upgrading firmware. In practice, more regions will be measured by coreboot in future.

PCR-5: loaded kernel modules
This is where it gets complicated, but still feasible, while hard to maintain. The platform could switch config as well (you going to usb support for example coming from a non-keyboard support board). And that would require prior-flashing exploration of initrd expended to be used as Heads filesystem to search for its /etc/config to see what is defined there and measure those "normal" boot modules. We can exclude usb storage and ethernet modules, for example, but what to do with usb-hid module would need a parser to see if the board config defines it.

PCR-6: LUKS header.
Quite easy, that measurement should not change. Can be used as is in futurecalcpcr

PCR-7: User config files
includes gpg trustdb pubring and config.user overlay. Can be used as is in futurecalcpcr

As you know, the Disk Unlock Key is invalidated after firmware upgrade because of the same problem. If forward sealing was possible, we could reseal secrets before reboot (at flash), including TPMTOTP Qr Code, HOTP and change the Disk Unlock Key.

That would still require from the user to seal HOTP with GPG Admin PIN, renew/change Disk Unlock Key by providing Disk Recovery Key passprase, and sign new default boot option with GPG User PIN. But yeah, it could be done prior of flashing.
The PCR-3 and PCR-5 problems needs to be figured out, where I not sure there is a solution for MRC cache if overwritten.

How would fwupd deal with that? I don't think it should, outside of deploying a detached signed archive containing rom image and hashes.txt (reflecting expected initrd packed content).