Replies: 6 comments 32 replies
-
Why would it matter? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions