Some concepts are mixed in here.
Heads is a payload of coreboot, and coreboot is enabling measured boot.
As a result, coreboot in measured boot (platform dependent) will initialize the TPM as early as possible (bootblock/romstage) and measure its stage (bootblock) and then measure other stages of coreboot (romstage, ramstage etc) into PCR2. Those are called TPM extend operations. As a result of those measurements (XOR operations upon prior measurements) the TPM keeps in this PCR2 extended measurements resulting in final PCR2 hash. Then coreboot launches its measured payload. leaving a trace of its measurements into a log (TCPA log) that can be observed from Heads recovery shell (linux) by calling cbmem -L).
Then, while Heads payload boots, it measures different stuff in different PCRs as documented Keys and passwords in Heads | Heads - Wiki
The important part here is to differentiate measurements from secret sealing/unsealing which I dumped here for review prior of being added into the wiki: https://github.com/osresearch/heads-wiki/issues/116
In short to address your comment above and the next:
Heads, upon firmware flashing/upgrade, will not be able to “unseal” its first secret (remote firmware integrity attestation) expected to be sealed into a distinct TPM NV memory region, which is expected to be the result of PRCs 0-4 previous sealed measurements… This is what was sealed and communicated to smartphone through Qr code (secret) scanned to generate TOTP on both phone and laptop. HOTP takes this secret and “seals” it into the USB Security dongle in a similar fashion with GPG admin PIN to store in there. This is the same secret, sealed inside of the TPM, which is used to unseal both TOTP code generation and to validate its integrity on the Nitrokey Pro/Nitrokey Storage/Librem Key upon challenge, resulting in green/red LED flashing and confirming “HOTP:Success” message on Heads main screen at each boot.
There is another “more advanced” sealed secret under Heads (Heads runtime state attestation), which is the consequence of the same prior PCRs (remote firmware integrity attestation), adding PCR 5-6-7 into the pool, but this time uses the TPM as a secret storage device, sealing those measurements (PCR 0-1-2-3-4-5-6-7) into TPM NV memory with a passphrase: this passphrase is used to unseal the Disk unlock key, added into the LUKS header when setting a new boot default, to be passed by Heads as the LUKS decryption key when booting a default boot option (through an additional cpio file applied on top of initramfs’ OS kernel to permit the OS to unlock disk without prompting user for the Disk Recovery Key passphrase). This TPM disk unlock key, that can be released only if all measurements are as when they were sealed, will release secret only if the passphrase can unseal that TPM memory region, with the same prior measurements that were taken when sealing the secret.
Now, and this is where some misinterpretation were done on what Heads does and doesn’t:
Heads is coreboot+linux payload in our scenario here. So PCR2 contains those measurements.
Then, really early in boot (init script calls cbfs-init), measurements of user’s gpg key material is measured inside of PCR7.
Heads creates digests of /boot files, and asks the user to detach sign its content.
When asked to setup a default boot option, it will also extract boot options (xen, kernel, boot options) and save those under /boot/kexec_* files, also detached signed with user’s private key from USB Security dongle (and GPG User PIN). On each boot, those detached signed digests are verified (integrity+authenticity) against that firmware injected, measured and extracted user’s public key prior of permitting to boot. Upon dom0 upgrade and reboot, Heads will see changes (new files, changed files, deleted files as compared to digest) and will ask the user to confirm knowledge of the changes by recreating new digests and detach signing them. When selecting default boot option that changed, the user is asked to enroll a new default boot option, and also has to detach sign that new configuration.
So on each boot, Heads:
- Remote attests firmware integrity through TOTP+HOTP (coreboot + payload → PCR2)
- Extract public key material from firmware (+measure into PC7) to be able to verify that /boot content is as expected (integrity+authenticity).
- On-demand (per boot policy) needed kernel modules are measured (PCR5) prior of being loaded (usb modules in case of USB Security dongle to remote attest through HOTP)
- If user needs to boot to USB thumb drive, usb storage and other needed kernel modules are measured and loaded (PCR5), invalidating possibility to do a default boot (measurement mismatch, impossible to unseal disk unlock key)
- When booting default boot option with TPM disk unlock key unsealing, the LUKS header is measured against sealed value (PCR6), which TPM disk unlock key will not unseal if different
- And of course, going into recovery console will invalidate measurements as well since PCR4 is extended, being part of TOTP/HOTP secret sealing/unsealing. So someone going into recovery will not be able to unseal any secret in that boot session.
Future (TXT and D-RTM)
As @pietrushnic noted, S-RTM and D-RTM are two different and complementary mechanisms of operations. S-RTM being useful for pre-boot integrity validation only, requiring to reboot to validate the integrity of the system, where D-RTM can be re-launched on demand.
To address specifics:
On above notes: it is currently impossible for ivy/sandy bridge (xx20/xx30 Lenovo Thinkpads x230/x220/t420/t430/t530/w530 Optiplex etc) to have bootblock measured in a totally trusted way, even with D-RTM on those platforms, but I would be really happy to be challenged wrong under WIP xx30/Haswell+ TXT support, IBB CPU anchored RoT through ACM blobs? by tlaurion · Pull Request #1172 · linuxboot/heads · GitHub. The reasoning is that sandy/ivy bridge cannot have bootblock under IBB and have ACM blob measure it to PCR0 from TXT.
Actually, there is no IBB definition possible for sandy/ivy bridge (xx20/xx30) based platforms; IBB + FIT descriptor only having happened under Haswell+ (which t440p could be interesting candidate) where the cpu cannot measure bootblock into PCR0 before haswell+.
A small PoC was attempted under WIP xx30/Haswell+ TXT support, IBB CPU anchored RoT through ACM blobs? by tlaurion · Pull Request #1172 · linuxboot/heads · GitHub for the x230.
The results were:
- ACM blob + sINIT blobs (download+ extraction provided), enables TXT and bases for D-RTM (firmware enablement).
- ivy bridge/sandy bridge, being pre-haswell, cannot include the bootblock as part of IBB (Haswell+ could have bootblock as part of IBB Measured Boot — coreboot 4.22-679-gcc2ab49525 documentation, not ivy bridge/sandy bridge)
So from my current understanding, D-RTM could be possible on ivy/sandy/haswell since TXT is possible there.
Questions are, for Heads:
- Blobs redistribution problems for ACM blobs (totally possible as per WIP xx30/Haswell+ TXT support, IBB CPU anchored RoT through ACM blobs? by tlaurion · Pull Request #1172 · linuxboot/heads · GitHub for users to compile/have CircleCI stitch ROMs for end-users)
- bootblock will not be measured by CPU ACM (into PCR0) but for haswell+ (t440p and newer Intel platforms, with additional blobs)
- Heads relies on linux + kexec to boot into next linux kernel.
- What changeset would need to be included into coreboot’s linux kernel to be slaunch compatible?
- What changeset would need to be included into kexec to be able to chainload multiboot2 kernels? (Heads linux kernel → kexec → slaunch-> Xen → Qubes OS dom0 kernel(+initrd)
I hope this post answers both user needs and future collaborators.