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
