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

[Andrei Borzenkov]

10.03.2025 18:16, Adrian Vovk wrote:
> 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
> 

You do not really need anything of that sort. It will not be possible to 
unlock using TPM anyway. You do need that initrd is configured to fall 
back to the interactive passphrase.

> - 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
> 

Again - no physical intervention is needed.

> - 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?
> 

Sort of. OP described the case of the LUKS container in the initrd, but 
I guess the same is also possible after switch to root. Depending on the 
initrd and the exact root container setup.

> 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
> 

This is not needed.

> - 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.

You can bind root to the PCR15 value *before* initrd and make sure 
initrd will update PCR15 after unlocking root. In this case PCR15 state 
will be different with the fake root and automatic unlock of the real 
root is not possible.

You can use the service suggested by Alberto that prevents leaving 
initrd if PCR15 is different.

It is possible to prohibit interactive unlock for root container, but 
that will effectively lock you out if anything happens with TPM.

But there are so many possibilities to configure that this discussion 
needs at least one real life example that demonstrates that this attack 
is even possible.

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