Revise the PCRs usage in LUKS TPM2 PIN

[miczyg1]

Dasharo version v0.9.0

Dasharo variant Dasharo Enterprise

Affected component(s) or functionality LUKS TPM2

Brief summary Even the smallest change cause the TPM2 PIN to stop working, rendering the OS unusable for the user. User should be able to enter the OS if the PCRs do not match, e.g. after a conscious software update, and reseal the disk decryption password without knowing the password from 3mdeb database. I.e. there should be a password for 3mdeb and a password for the user (used for resealing).

Also it may be wise to rethink what PCRs to use. Currently used PCRs in LUKS are 0,1,2,3,7. Current PCR usage on the laptops:

cb_pcrs.TXT eventlog.TXT

UEFI Payload does not use PCR2 at all, but coreboot measures all the components there. vboot uses PCR0 for boot mode and PCR1 for GBB HWID. Then PCR0 is used for CRTM in UEFI Payload and PCR1 for UEIF variable measurements. Also PCR4 and PCR5 has an interesting use in UEFI Payload: PCR4 store measurements of EFI actions like calling EFI applications, which may be significant when someone would alter the boot path; PCR5 stores info about EBS and GPT partition info which also seem important. It looks like PCR1 is less important and it contains a lot of runtime data (except GBB HWID which is not that important TBH). PCR2 and PCR3 are only extended with a separator event in UEFI Payload, so PCR3 can be ignored.

[dpsmith]

The correct answer is to do a forward-seal of the environment, but the SRTM chain is so long and complicated. You can resolve through a user recovery password, which can be achieved through a few means. These being:

• Use a LUKS key slot directly for recovery password
• A slight alternation is to seal a key split behind PCR0, which should be more stable, and then XOR the split with hash of user password and use that for a LUKS key slot
• A pure TPM approach would be to use an Enhanced Auth (EA) policy, PolicyPassword and PolicyOr, to construct a policy for either correct PCRs or correct password

[pietrushnic]

@dpsmith I wonder if you consider the enterprise nature of what we try to do here. It is ok for the user to do updates and resealing, but we need the enterprise always to decrypt the disc no matter what the user does with the device. Of course, assuming the device was not destroyed physically and the user did not change/circumvent Intel Boot Guard, vboot, and UEFI Secure Boot or other pre-OS security mechanisms existing or planned (STM, TrenchBoot).

Use a LUKS key slot directly for recovery password

IIUC This is what we are doing now.

A pure TPM approach would be to use an Enhanced Auth (EA) policy, PolicyPassword and PolicyOr, to construct a policy for either correct PCRs or correct password

AFAIU This would be the direction we would like to go. If we can describe what is involved here, we can transition to this model or implement it in a future version of Dasharo Enterprise.

[pietrushnic]

Some links related to the problem (credits to @stacktrust):

• https://www.linux.com/topic/embedded-iot/device-we-trust-measure-twice-compute-once-xen-linux-tpm-20-and-txt/
• https://openxt.atlassian.net/wiki/spaces/DC/pages/81035265/Measured+Launch

[DemiMarie]

The correct answer is to do a forward-seal of the environment, but the SRTM chain is so long and complicated.

This is exactly what systemd-pcrlock is for.