Hello, Just to see if I understand your concern correctly, I'll try boiling it down to its simplest, by cutting out the need for two partitions. Here's the scenario:
- An attacker replaces the real rootfs with a malicious one that just drops to a shell. The attacker keeps a copy of the original real rootfs - The system boots, then tries and fails to decrypt the fake rootfs. - The attacker now starts impeding communication between the TPM and the CPU. Potentially by physically interposing on the bus and blocking communication. Or by glitching the bus so that the data isn't successfully measured. Anyway, the attacker somehow makes TPM measurements fail - The attacker unlocks their malicious rootfs, and then the system continues booting. The attacker now gains control of the system via the root shell. - The attacker stops impeding the communication between the TPM and the CPU. The TPM is still in the same state as it was in the initrd. The leave-initrd pcrphase, and the PCR15 measurement of the fake root's volume key, are both missing - The attacker is in control of the system, and the TPM is in the right state to unlock the real rootfs. The attacker talks to the TPM to get the real rootfs's volume key. Attacker wins I think, ultimately, this is the same issue as the one you describe. Do you think that's correct? Lennart would have a better idea than I do of what mitigations to this would look like. But I suspect that: - You can't MITM the TPM, since the communication is encrypted - Other kinds of attacks cause the OS to know that a measurement failed. So perhaps we need to very strict about ensuring that measurements happen. i.e. By not letting the TPM disappear at runtime, and making sure that measurements always succeed (and if it does, failing to boot or something) Best, Adrian On Mon, Mar 10, 2025, 05:23 Yann Diorcet <diorcet.y...@gmail.com> wrote: > Hi, > Sorry for my english, i'm not english native. > > Le lun. 10 mars 2025 à 10:04, Lennart Poettering > <lenn...@poettering.net> a écrit : > > > > On Sa, 08.03.25 19:52, Diorcet Yann (diorcet.y...@gmail.com) wrote: > > > > > Hello, > > 61;7802;1c> > > > 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 > > > > Disable the password prompt via "headless" crypttab option. > Thanks for this tip > > > > > (Not sure if I follow what the issue is supposed to be, i.e. not sure > > what "try unlocks" is supposed to mean or what "the second" refers > > to. Just guessing here). > > > > There's a TODO list item somewhere to provide more finegrained conrol > > of which mechanisms are allowed to allow a disk, and conversely to > > measure the actual mechanism used. But until then simply disable > > interactivity fully. > > > > (note that fido2, tpm2, pkcs11 unlocking needs to be enabled manually, > > it's only passphrase/recovery key unlock which is on by default, and > > which you have to turn off via headless) > > > > > - Make the update of the PCR due to the measuring of the malicious > partition > > > fails > > > > hmm, i really cannot parse this? (not the rest either...?) > > If an attacker jams the communication with the TPM (discret one for > example) during the measuring phase of the first partition (which in > my example is the malicious one), the PCR will not be updated. > Allowing the second partition to be unlocked as it would be unlocked > in normal situtation: as the first unlocked partition. > If you don't add counter measure at the end of initrd in order to fail > this trick (as alplanas explained), you will chroot on the malicious > partition with the the good root partition unlocked and mounted as the > second partition. > > > > > > Lennart > > > > -- > > Lennart Poettering, Berlin > > > > Yann >
