[systemd-devel] Is tpm2-measure-pcr really an additional security?

[Diorcet Yann]

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