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)
Le dim. 9 mars 2025 à 09:02, Andrei Borzenkov <arvidj...@gmail.com> a écrit : > 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: > >> > >> > 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 > >> > >> > >> > >> > > > >
