[systemd-devel] Is tpm2-measure-pcr really an additional security?

[Yann Diorcet]

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 <arvidjaar at 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
> >>
> >>
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250309/6ffe9407/attachment-0001.htm>