From 29818c4e99e0a65bac800a000c4b3b1549d5a084 Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Thu, 13 Oct 2022 09:47:48 +0200 Subject: update NEWS --- NEWS | 43 +++++++++++++++++++++++++------------------ 1 file changed, 25 insertions(+), 18 deletions(-) (limited to 'NEWS') diff --git a/NEWS b/NEWS index 2599884138..f049e53b23 100644 --- a/NEWS +++ b/NEWS @@ -44,36 +44,43 @@ CHANGES WITH 252 in spe: systemd-stub is booted. This is useful for implementing TPM2 policies for LUKS encrypted volumes and encrypted system/service credentials, that robustly bind to kernels carrying appropriate PCR signature - information. The signed expected PCR information may be embedded - inside UKI images for this purpose so that it is automatically - available in userspace, once the UKI is booted. + information. The signed expected PCR information, and the public key + used for the signature may be embedded inside UKIs for this purpose, + so that it is automatically available in userspace, once the UKI is + booted. systemd-cryptsetup, systemd-cryptenroll and systemd-creds have been updated to make use of this information if available in the booted - kernel. - - Net effect: if you boot a properly prepared kernel, TPM-bound disk - encryption now defaults to be locked to kernels which carry PCR - signatures from the same signature key pair. Example: if a - hypothetical distro FooOS prepares its UKI kernels like this, - TPM-based disk encryption is now – by default – bound to only FooOS - kernels, and encrypted volumes bound to the TPM cannot be unlocked on - other kernels from other sources. (But do note this behaviour - requires preparation/enabling in the UKI, and of course users can - always enroll non-TPM ways to unlock the volume.) + kernel: when locking an encrypted volume/credential to the TPM + systemd-cryptenroll/systemd-creds will use the public key embedded in + the booted UKI to bind the volume/credential to the kernel (and + future versions thereof, as long as it carries PCR information signed + by the same key pair). When unlocking such an encrypted + volume/credential systemd-cryptsetup/systemd-creds will use the + signature embedded in the booted UKI to gain access. Binding TPM-based disk encryption to public keys/signatures of PCR values — instead of literal PCR values — addresses the inherent "brittleness" of traditional PCR-bound TPM disk encryption schemes: - disks remain accessible even if the UKI image is updated, without any - prepartion during the update scheme — as long as each UKI carries the - necessary PCR signature information. + disks remain accessible even if the UKI is updated, without any TPM + specific preparation during the OS update — as long as each UKI + carries the necessary PCR signature information. + + Net effect: if you boot a properly prepared kernel, TPM-bound disk + encryption now defaults to be locked to kernels which carry PCR + signatures from the same signature key pair. Example: if a + hypothetical distro FooOS prepares its UKIs like this, TPM-based disk + encryption is now – by default – bound to only FooOS kernels, and + encrypted volumes bound to the TPM cannot be unlocked on other + kernels from other sources. (But do note this behaviour requires + preparation/enabling in the UKI, and of course users can always + enroll non-TPM ways to unlock the volume.) * systemd-pcrphase is a new tool that is invoked at 4 places during system runtime, and measures additional words into TPM2 PCR 11, to mark milestones of the boot process. This allows binding access to specific TPM2-encrypted secrets to specific phases of the boot - process. (Think: LUKS2 disk encryption key only accessible in the + process. (Example: LUKS2 disk encryption key only accessible in the initrd, but not later.) Changes in systemd itself, i.e. the manager and units -- cgit v1.2.1