Distinction between TPM measurements and sealing/unsealing TPM operations

Nobody has claimed this yet.

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.

Read the explanation in this issue and the linked Keys page, then compare it with the existing Heads wiki documentation. Done means adding a clear distinction between TPM measurements and sealing/unsealing operations, including how PCR measurements and TPM NVRAM secrets relate to attestation and disk unlocking.

Written by the indexing model from the issue text.