Finding possible use cases for DRTM payload

[krystian-hebel]

DRTM between coreboot and payload doesn't improve the security by itself. For dynamic launch to be useful, a later component must somehow depend on proof generated by this mechanism. This issue is made to gather the ideas for use cases.

1. Encrypted SMMSTORE

SMMSTORE is used as a backend for UEFI variables for edk2 on top of coreboot. As the name suggests, SMM is used to perform raw accesses to the flash device.

Instead of data written in plain form, it may be encrypted by a TPM using a key sealed with specific PCR values. If the payload is modified, it can no longer access the variables, because its measurement recorder in PCR will be different. This improves confidentiality, but not integrity nor availability properties.

Challenges:

• UEFI update would require forward sealing to preserve the access to SMMSTORE data
• coreboot no longer has access to UEFI variables
• slower access to the variables
• SMM is not measured by DRTM

2. Encrypted boot partition

While solutions like LUKS or BitLocker are called full disk encryption mechanisms, they only encrypt the system partition, and a smaller boot partition must remain unencrypted. Boot partition then contains either a small utility or whole kernel that decrypts the main partition.

It should be possible to implement a driver in UEFI that would read the sealed key from the TPM and use it to decrypt the boot partition, or even MBR/GPT (although this may require support in the operating system as well). By doing so, if the drive were stolen, the attacker would not only be stopped from accessing the root filesystem content, but he also wouldn't be able to detect the flavor of operating system that is installed on that disk. With encrypted MBR/GPT, this would provide plausibly deniable encryption - without the proper key, even the existence of partitions can't be proven.

Challenges:

• requires UEFI driver
• OS can't directly access boot partition, which may make it harder to update the kernel
• MBR/GPT encryption additionally requires OS driver and a way of passing the decryption key from firmware

3. Your use case

Additional ideas are welcomed.