Thanks for you reply. My point is that defeating the PCR update in the measuring step of systemd-crypsetup could be not so hard to realize (see the two ways in my initial email) <div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Le dim. 9 mars 2025 à 09:02, Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com">arvidjaar@gmail.com</a>> a écrit : </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">08.03.2025 22:40, Andrei Borzenkov wrote: > 08.03.2025 21:52, Diorcet Yann wrote: >> 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 : >> > > tpm2-measure-pcr is in /etc/crypttab which is included in the signed > initrd and so cannot be forged. As long as the second device depends on > the result of the measurement of the first (root), replacing root will > fail to automatically unlock it. > Sorry, you actually were right. Normally root will not depend on any previous measurements and we trust device metadata to provide the list of PCRs. You will need to add the PCR into which root is measured to the root metadata. It would normally be in the initial well known state directly after boot (so, when root is normally unlocked) but will change if you exchange the real root for the fake one. >> - 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: >> >> <a href="https://github.com/systemd/systemd/blob/bd0d22c2a5bdbf427c68eab630dc06f55dc96c72/src/cryptsetup/cryptsetup.c#L1085" rel="noreferrer noreferrer" target="_blank">https://github.com/systemd/systemd/blob/bd0d22c2a5bdbf427c68eab630dc06f55dc96c72/src/cryptsetup/cryptsetup.c#L1085</a> >> >> 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 >> >> >> >> > </blockquote></div>