Hi, Sorry for my english, i'm not english native. Le lun. 10 mars 2025 à 10:04, Lennart Poettering <lennart@xxxxxxxxxxxxxx> a écrit : > > On Sa, 08.03.25 19:52, Diorcet Yann (diorcet.yann@xxxxxxxxx) 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