Is tpm2-measure-pcr really an additional security?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I'm in the process of using SecureBoot, TPM2.0 and LUKS2 to protect an industrial embedded computer.

I have a chain of trust in the UEFI (own secure boot keys/certificates), signed grub2, all files used by grub2 signed including kernel and initramfs,  and successfully automatically unlocked LUKS partitions using TPM2.0 using PCR7.

The main concern remaining is to be sure to chroot on the "good" root partition (and not a malicious one allowing to decrypt using TPM the "good" partition).

pcrphase ensures that "good" root partition can only be unlocked in the good phase (after enter-initrd for example), this is an additional security.

tpm2-measure-pcr provides a way to only decrypt other partitions after the "good" root partition: Using for example 7+11+15


But in the case of multiple partitions unlocked by the initrd, I can't figure why an attacker couldn't succeed to :

- Clone the original disk (notably ESP)

- Replace root partition by a malicious one

- Fake the second (using UUID/PARTLABEL/...) but using LUKS partition from the "good" root partition

- Boot the machine

- The initrd will try unlocks the malicious partition as root. As the TPM token will not work, the attacker will use the password of his malicious LUKS

- Make the update of the PCR due to the measuring of the malicious partition fails

- Initrd will try to unlock the second partition, which is the "good" root partition, and it will succeed, allowing the attacker to finally access all data from the partition.


The main point here is to "Make the update of the PCR due to  the measuring of the malicious partition fails".

Indeed the measuring may be never executed:

https://github.com/systemd/systemd/blob/bd0d22c2a5bdbf427c68eab630dc06f55dc96c72/src/cryptsetup/cryptsetup.c#L1085

This may happens in few cases:

- volume_key_size == 0? Is it possible to make cryptsetup to unlock a malicious partition during initrd with this condition? I'm not aware of the details for example with LUKS2

- Making the measure_volume_key fails will not produce any counter reaction (just an error message for example "Could not extend PCR: 15"): "OK if fails"

A way to make it happens, is to glitching at a specific moment the communication with the TPM2.0, or using MITM faking/failing an update of the PCR allowing automatic unlock of the "good" root partitions as second partition. Adding a check on measure_volume_key return value may be not sufficient.


Maybe I missing some pieces, but I only see two ways to defeat that:

- Enforcing the use of TPM2.0 exclusively (no fallback on password): cryptsetup exiting with non zero exit code making initrd fails. Is it possible?

- Don't use multiple encrypted partitions.


May I miss understanding something?


Regards,

Yann







[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux