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. (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...?) Lennart -- Lennart Poettering, Berlin