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@xxxxxxxxx> wrote:
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
