From defdfae68d0f09e0f47bef0a52ace7afa778a450 Mon Sep 17 00:00:00 2001 From: Owen W. Taylor Date: Apr 12 2023 17:32:52 +0000 Subject: Improve documentation about secure boot Update the text to reflect that fact that simply binding to PCR 7 (the secure boot state) is insufficient; that we additionally need to make sure that the system is being unlocked from a trusted initrd. --- diff --git a/notes/encryption.md b/notes/encryption.md index 2ffac7f..4c55f35 100644 --- a/notes/encryption.md +++ b/notes/encryption.md @@ -159,7 +159,8 @@ A user will need a recovery key in a range of situations: * Reinstall keeping home directory data * Booting a custom initrd or kernel * A bios setting is changed that affects the PCR contents -(Some of these can be handled by ) + +(Some of these can be handled by the user temporarily disabling encryption.) Microsoft and Apple store recovery keys in their cloud services by default. We don't have that option - even if we *did* have a Fedora cloud service, @@ -175,7 +176,7 @@ are *independent* threats.) ## Draft plan -* Encrypt / exclusive of /home with a TPM2-stored key, bound to PCR 7 +* Encrypt / exclusive of /home with a TPM2-stored key * Encypt the /home subvolume with the same key * Encrypt home directories with the user password @@ -207,7 +208,12 @@ it depends on the grub config and kernel command line. See the following Fedora * [Unified_Kernel_Support_Phase_1](https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1) (accepted for F38) * [Unified_Kernel_Support_Phase_2](https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2) (proposed for F39) -If we want to support PCR 7 binding, then we have to have and require a Fedora-signed unified kernel image. +We need some way to bind unlocking the key to the initrd phase of a Fedora-trusted initrd. + +One way to do this would be to compute the PCR11 value of the Fedora UKI, +and embed a signature of value this in the UKI. +Then we could bind the encryption key to the Fedora public key used to create the signatures. +(In addition to PCR7.) **Secure boot with NVIDIA proprietary driver** - it is currently difficult to use the NVIDIA proprietary drives with secure boot enabled @@ -223,6 +229,11 @@ rather than just the keys used to verify them, we need to update the TPM2-key storage so that the filesystem can be decrypted by the new kernel+initrd. +**Key rollover support on secure boot db/dbx updates** - +When fwupd updates the secure boot trust database, +the TPM2 stored key needs to be updated, +since the PCR7 value will change. + **Recovery user experience** - if the user replaces their motherboard, or something goes wrong with the update process, @@ -262,14 +273,17 @@ that are currently installed. This will require updating the encryption key on O * Bind the encryption key to the signatures used to verify the boot chain components: * Advantage: simplicity of implementation * Advantage: less likely to go wrong and require a recovery key - -[The systemd-cryptenroll(1) man page](https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html) -recommends the second approach: - -> For most applications it should be sufficient to bind against PCR 7 (and possibly PCR 14, if shim/MOK is desired), as this includes measurements of the trusted certificates (and possibly hashes) that are used to validate all components of the boot process up to and including the OS kernel. In order to simplify firmware and OS version updates it's typically not advisable to include PCRs such as 0 and 2 in the binding of the enrollment, since the program code they cover should already be protected indirectly through the certificates measured into PCR 7. Validation through these certificates is typically preferable over validation through direct measurements as it is less brittle in context of OS/firmware updates: the measurements will change on every update, but code signatures likely will validate against pre-existing certificates. - -Hybrid approaches are possible where we use PCR 7 to handle firmware/shim/bootloader -with protection via certificates but measure the kernel/initrd directly. + * Note: simply binding to PCR 7 is not sufficient, +since this would allow any booted Fedora system (such as a LiveUSB key) to unlock the key. +We need to additionally bind to something that is only available during a verified initrd. +One possibility is binding to a RSA signature on the systemd-defined PCR 11 value, +which is extended with information about the kernel, initrd, kernel command line, and boot phase. +See [systemd-stub](https://www.freedesktop.org/software/systemd/man/systemd-stub.html) and +[systemd-measure](https://www.freedesktop.org/software/systemd/man/systemd-measure.html). + * Note: The PCR 7 value changes when the secure boot trust databases (db and dbx) are updated. +This poses a challenge for dual boot, +since Fedora will be unaware if Windows updates the dbx, +and vice-versa. On Windows, BitLocker [seals the encryption key with PCR 7 and 11](https://learn.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-group-policy-settings#about-pcr-7)