Can mounting an untrusted root be avoided?

[Ablu]

I am wondering: Assuming I want a dm-verity /usr and a read-writable, encrypted / (auto-created by systemd-repart). Then, when transitioning from an UKI to the final rootfs. How can it be ensured that this rootfs is genuine?

I understand that encryption keys of the rootfs can be measured into TPM, disallowing access to secrets if that filesystem is not there. But how can auto-discovering and mounting a maliciously forged partition be avoided? Is there a mechanism that allows the initramfs to reject such a partition?

[bluca]

Why would it matter?

[bluca]

They can though - it can be swapped with a different partition, still encrypted, say for example against PCR7 or some other known and predictable quantities. It would still happily run. So again, it goes back to remote attestation to check which volume key is used, but again that's after the fact.

Hm. I fear I do not know all the concepts well enough to understand this. How do I forge a LUKS partition that will be accepted in place of my original one?

The policy simply says "this must be encrypted". We are talking about unattended cases like servers, so realistically that will be against some PCRs - but those are very easy to predict, so right now you just encrypted against the expected value of PCR7 and everything will happily load, even with that policy. Even with the enhancements proposed here, to have a policy that mentions a PCR, that still doesn't help much for the root case, as the threat model assumes full physical access, so one can check what the measurements of all PCRs are, and encrypt against that.

[Ablu]

The policy simply says "this must be encrypted". We are talking about unattended cases like servers, so realistically that will be against some PCRs - but those are very easy to predict, so right now you just encrypted against the expected value of PCR7 and everything will happily load, even with that policy. Even with the enhancements proposed here, to have a policy that mentions a PCR, that still doesn't help much for the root case, as the threat model assumes full physical access, so one can check what the measurements of all PCRs are, and encrypt against that.

Thanks for the explanation! Since I probably do not know enough about TPMs and LUKS I just want to confirm:

The idea is that since there is no authenticity data of the partition is required for unlocking key, the attacker can just predict the TPM state and derive a key that will be accepted?

Is there no secret from the TPM required for that? Or does it require some degree of code execution for creating the key for the fake partition?

[bluca]

Yes it requires access to the TPM, but in this threat model there is full physical access so that can be obtained, otherwise changing the disk is also impossible

[Ablu]

Sure! Just wanted to make sure I understand it correctly. Thanks a lot!

[Ablu]

I have unmarked this as "solved" then for now.

[poettering]

I am not sure I understand the question. What does "genuine" mean? If the OS booted up, found no existing root fs, and created one, locking it to the TPM (which means encrypting the LUKS unlock key with a key that is only known to the TPM), then you will need the TPM to get access. If some other root fs comes along then it will not have its unlock key encrypted with that TPM's encryption key, and thus cannot be unlocked. Except of course if you have two images that both were created initially on the local system. But in that case both are equally "genuine".

It might make sense to authenticate the OS to the user logging in (traditionally it's the user who authenticates to the OS, but not vice versa). This is a form of "remote attestation" and is typically done via TOTP: for example with stuff like this:

https://github.com/mjg59/tpmtotp

The idea is basically that at login time you get shown a code that proves for the current time that the OS in order and is the system you think it is. You can verify that with your phone.

We have discussed a couple of times, whether we should add something like this to systemd itself, to just be there out of the box, but I am not sure if this isn't too far in "nerd shit" territory.

[Ablu]

If some other root fs comes along then it will not have its unlock key encrypted with that TPM's encryption key, and thus cannot be unlocked.

My core question is how this "cannot be unlocked" is done. From my understanding of the discoverable partition part, wouldn't a non-encrypted partition also be discovered and used? Is there some mechanism that allows me to prevent that?

[poettering]

https://www.freedesktop.org/software/systemd/man/systemd.image-policy.html

[poettering]

I understand that encryption keys of the rootfs can be measured into TPM, disallowing access to secrets if that filesystem is not there.

So we do measure the LUKS volume key to some TPM PCR. But generally, this PCR is not used for unlocking the disk, because that would be a cyclic dependency then: you'd have to have measured to the volume key to acquire the volume key.

[poettering]

note that the image policy stuff we probably should extend a bit, and allow encoding some rules on how an encrypted disk is unlocked, so that you can declare that unlocking via pw is never allowed.

i.e. systemd.image_policy=root=encrypted-tpm2+encrypted-fido2 would dictate that you can only unlock via tpm2 or fido2, but not via pw or so. Happy to take patches for that ;-)

[bluca]

That would certainly be useful, but still wouldn't help with this specific use case - assuming unrestricted physical write access, creating a 'malicious' partition encrypted against say PCR7 or so is just as trivial, and then it would pass that policy. But again, the key thing is defining the threat model and what it needs to protect against. Normally the concern with physical attacks in datacenters is more around data exfiltration. If the concern is code integrity, then the partition is just one of many vectors, and not even remotely the easiest one to exploit.

[poettering]

creating a 'malicious' partition encrypted against say PCR7 or so is just as trivial

is it? you'd need to have access to the TPM for that.

[bluca]

The threat model defined here assumes full physical access (eg: to swap disks), so you run whatever you want to get what you need, and then prepare the vector

[ElvishJerricco]

which of course requires either a stock OS signed by a vendor, or a firmware that allows someone with physical access to freely disable secure boot

[bluca]

Not a whole OS, just a kernel from any of the vendors that get signed by the UEFI 3rd party CA, of which there is many

[Vogtinator]

IMO this is a valid concern and I also raised that with the the related GRUB TPM protector development, resulting in (so far) https://lists.gnu.org/archive/html/grub-devel/2023-10/msg00025.html

The best way to protect against this would be to use authenticated encryption with the authentication key measured before attempting to unlock.

[poettering]

The best way to protect against this would be to use to use authenticated encryption with the authentication key measured before attempting to unlock.

Note that systemd-cryptsetup can measure the volume key for you on unlock already, see the tpm2-measure-pcr= crypttab option. This is in fact enabled by default if you use the systemd-gpt-auto-generator logic on a UKI boot.

systemd-repart currently doesn't support formatting a disk with authenticated encryption (i.e. dm-crypt + dm-integrity), but we certainly should add that.

[Vogtinator]

systemd-repart currently doesn't support formatting a disk with authenticated encryption (i.e. dm-crypt + dm-integrity), but we certainly should add that.

Yeah. FWICT this is handled rather transparently by cryptsetup, so the existence of dm-integrity is mostly an implementation detail.

[Ablu]

Do I understand this correctly, that if systemd-repart could set up the authenticated encryption then my described scenario would be solved? Since revealing the unlock key would be sealed against the authentication key I would no longer be able to forge a different partition by predicting TPM state (as sketched in https://github.com/orgs/uapi-group/discussions/87#discussioncomment-7271771)?

[poettering]

@bluca btw, there's one more thing we need: with Dan's support for encrypting disks against an SRK offline we can have really nice confext DDIs that can be prepared offline and then can only be unlocked on a specific system. But for this to be useful we'd also need the ability to sign the image with some admin key, so that the system can authenticate things before it applies the configuration.