Distinction between TPM measurements and sealing/unsealing TPM operations

[tlaurion]

That question was answered on slack/matrix here: https://matrix.to/#/!pAlHOfxQNPXOgFGTmo:matrix.org/$SDLnmO-F3ALUZKvlnW0TR8SY8nZlbFaR_8C7Hgygoxw?via=matrix.org&via=nitro.chat&via=talk.puri.sm :

in coreboot with measured boot activated, the TPM is used to measure coreboot different stages before they are loaded and executed. It does so in SRTM measured boot mode, extending a single PCR(2). TCPA log is given when running cbmem -L from Heads recovery shell, which gives a trace of the measurements that were taken, and for which PCR2 was "extended" from those measurements and in which order those measurements have been taken. By itself, if those measurements are not sealed/unsealed, those measurements are not implying any security by themselves more then measurement traces. When coreboot finishes "measured boot" itself, the PCR2 contains the final firmware measurements, extended from the bootblock up to the payload (Heads), prior of booting into it.

Heads then takes measurements of its own in different PCRs. The details are under https://osresearch.net/Keys/#tpm-pcrs

The TPM also provides storage in its own memory NVRAM regions. Those regions are used to seal/unseal "secrets" from Heads.

Those "secrets" are first sealed after a firmware flash/upgrade. When flashing a firmware upgrade, the first thing Heads does on next boot is inform the user that unsealing TOTP/HOTP secret failed, asking the user to reseal that secret into the TPM. Sealing is the process of taking actual measurements and using them as a key to store "secret" under distinct TPM NVRAM memory regions.

Under Heads, there are currently two sealed secrets. One is sealed/unsealed as part of TOTP/HOTP remote attestation. Another one is part of TPM disk encryption sealing/unsealing.

So on boot, Heads attempts to unseal a previously sealed secret used for TOTP/HOTP remote attestation. It will use current PCRs measurements to attempt to unseal the previously sealed TOTP/HOTP secret, which will result in both TOTP code generated on screen/2FA app (where the secret was scanned from Qr code to share that secret with 2FA app) and used as a token to be challenged through HOTP against the USB Security dongle (Nitrokey). At this point, if the user decides to not plug its USB Security dongle on boot, the secret is unsealed already if the PCRs measurements can unseal that TPM NVRAM region. This will generate a TOTP code on screen, that can be used to remote attest on a smartphone 2FA app which should show the same TOTP code (if time is in sync between the two devices). HOTP is simply more convenient then TOTP for that reason: HOTP doesn't require time to be in sync between the two devices. HOTP will take care of the remote attestation and provide visual attestation on the USB Security dongle itself, flashing the LED green/red and providing visual feedback on Heads as well. It is to note that if the measurements were different at this point, the unsealing operation would fail. The reason why it is important to validate those measurements on a separate device is simply because they could have been resealed, and the TPM wouldn't know. HOTP/TOTP permits to verify that the unsealed secret is the same that was sealed by the user behind the platform. This is why remote attestation is needed to verify the sealed state against something that is outside of the device (second factor) to be validated. This is why this is called remote attestation.

Now to address your question of TPM decryption key, the same reasoning applies. The sealing operation takes more measuring points into account but relies on the same principles. You would not want to input a passphrase before making sure that the place where you input that passphrase is safe, you are right. One should verify TOTP/HOTP prior of typing any passphrase.

Yet again, when someone defines a TPM disk encryption key, firmware measurements, loaded kernel modules measurements, LUKS header AND sealed TPM nvram region passphrase are all expected to be consistent to unseal the TPM disk encryption key from that specific TPM NVRAM region. If one of the above is different, the TPM won't unseal the LUKS encryption key, resulting into variations of the following ouput: https://osresearch.net/Keys/#disk-unlock-key-passphrase-prompt-output, which is provided only when all measurements are valid but the TPM nvram region passphrase is invalid. Providing the valid TPM NVRAM passphrase to unlock the secret, if any of the required measurements are invalid would result into unsealing errors.

The short version is: all measurements used at sealing time of a TPM NVRAM region are REQUIRED to be consistent at the time of unsealing them for the unsealing operation to succeed, otherwise failing.

[tlaurion]

It should probably be added to either https://osresearch.net/ about section or https://osresearch.net/Keys/

[tlaurion]

@maltfield just read your article at https://tech.michaelaltfield.net/2023/02/16/evil-maid-heads-pureboot/

Two small corrections there.

• Librem key is a rebranded nitrokey pro, not nitrokey storage
• TXT is the base for D-RTM and is possible on neutered ME (ivy/sandy) which is possible to integrate with trenchboot and in PoC stage for QubesOS next gen AEM: https://forum.qubes-os.org/t/trenchboot-anti-evil-maid-for-qubes-os/16559/9 (read comments there).

On t440p (and other Haswell based platforms), bootblock is possible to be made part of IBB and measured by ACM blob to populate PCR0 with IBB measurements. Since bootblock is where first measurement (extend op to TPM), faking measurements inside of coreboot (PCR2 only) to get PCR 0-4 measurements sealed into TOTP/HOTP would become extensively complicated to replay.

Also

• WP# protection can soon be applied by "cyberpunks" to define WP ranges to SPI regions (manually as of now) and then short WP to GND on the spi chip. A bit unpractical but feasible (easy for kgpe-d16 with a jumper on SPI adapter as documented at https://docs.dasharo.com/variants/asus_kgpe_d16/spi-wp/). That flashrom version was tested for regression and passed. It is gonna be used under Heads soon.
• io386 PR could be merged today, and will use SMI platform lock, which is possible to enable directly on pre-FSP hardware (ivy/sandy/haswell) so that only Heads can flash(modify) firmware internally, prior of locking the platform bits (before kexec calls to next OS kernel). Not really powerful against evil maid without enabling authentication under Heads recovery shell first, and then enabling auth prior of calling USB boot, going to recovery shell or flashing new firmware. Heads Authentication is coming in the next months (enabling detach signing based GPG authentication with good UX requires gpg key material key backup on encrypted storage at key generation (factory reset/Re-ownership) ) to not lock users out of their platforms in case USB Security dongle is lost and while waiting for replacement, while permitting reprovisioning with backup key material upon replacement arrival and enabling direct usage of backup key material without USB security donglen itself, reducing acquisition costs to use Heads without HOTP as well (non-hotp board configs under Heads).

---

@maltfield: Any simplification you would suggest on the OP here that should be part of main documentation for seal/unseal/extend operations for end users?

[maltfield]

Librem key is a rebranded nitrokey pro, not nitrokey storage

@tlaurion thanks, I've fixed this in the article

TXT is the base for D-RTM and is possible on neutered ME (ivy/sandy) which is possible to integrate with trenchboot and in PoC stage for QubesOS next gen AEM: https://forum.qubes-os.org/t/trenchboot-anti-evil-maid-for-qubes-os/16559/9 (read comments there).

Sorry, I don't understand exactly what the mistake in the article is regarding this (and what you want corrected). I did add a link to TrenchBoot in the "Further Reading" section. This is the first I'm hearing about it, and I'm not quite sure what it solves that Heads does not (would be nice if they added this to their FAQ).

[tlaurion]

@maltfield well, it trickles down to asking the ACM to redo fresh measurements on-demand, since ACM is almighty on resume path.

[tlaurion]

Also relevant https://github.com/StarLabsLtd/firmware/issues/104#issuecomment-1724128152

https://forum.qubes-os.org/t/trenchboot-anti-evil-maid-for-qubes-os/16559/10

https://github.com/TrenchBoot/documentation/issues/20

[tlaurion]

Merge this with https://github.com/linuxboot/heads-wiki/issues/62 when updating documentation