2️⃣ Here's the 2nd installment of posts highlighting key new features of the upcoming v257 release of systemd.

2️⃣ Here's the 2nd installment of posts highlighting key new features of the upcoming v257 release of systemd.

In the past year and a bit I spent a lot of time on boot integrity (i.e. boot-time TPM measurements and policies built on top of them) of Linux, covering the boot from the boot loader (systemd-boot), over the UKI EFI stub (systemd-stub) through the initrd into early regular userspace, and then locking disk encryption to it.

If you ask me, it's a fundamental requirement for any modern Linux-based OS to provide boot time integrity and as baseline provide unattended disk encryption bound to it. To make this happen, we added two essential TPM policy concepts to systemd-cryptenroll/systemd-cryptsetup:

1. Signed TPM PCR policies allow locking a disk to a public signing key of an OS vendor, ensuring that disks can only be unlocked if an OS signed by said vendor is booted.

@pid_eins but do we have the software/hardware infrastructure needed to actually make this secure on a typical Linux desktop machine?
To me, the core purpose of disk encryption is protect a machine against an attacker who steals the entire, powered-off machine; and it's easy to mess up unattended disk encryption so that this is easy to break. The communication with the TPM needs to be protected against interposer attacks somehow (see https://www.nccgroup.com/us/research-blog/tpm-genie-interposer-attacks-against-the-trusted-platform-module-serial-bus/ ); the disk ideally should not just be encrypted but also integrity-protected (because in some settings, the disk encryption is then relied on for security against adaptive online attacks instead of security against a one-time-snapshot passive attacker); you need rollback protection against someone booting a super vulnerable outdated OS image; bugs in device drivers turn into disk encryption bypasses (and notably Linux basically trusts PCI devices to not be actively evil); and so on.

So I'm worried that providing TPM-based disk unlock as an easy-to-configure mechanism might give people a false sense of security. With password-based disk encryption, to me, the core security promise is easy: If someone steals your (not-too-recently-) powered-off computer, they can't get any of the data out of it unless they break your password. With TPM-based unlock, the story is a lot more complex...

@jann @pid_eins

> The communication with the TPM needs to be protected against interposer attacks somehow

TPM2.0 supports encrypting the communication on the bus. Systemd does this, and so does the kernel these days.

This is very much a solved problem.

EDIT:
See this post from Chris Fenner.
https://www.dlp.rip/tpm-genie

@Foxboron @pid_eins does that also guard against an unauthorized kernel collaborating with an interposer to power-cycle the TPM and then pretend to the TPM that the system is going through a reboot? with something like the Host Secret approach from https://trustedcomputinggroup.org/wp-content/uploads/TCG_-CPU_-TPM_Bus_Protection_Guidance_Active_Attack_Mitigations-V1-R30_PUB-1.pdf ? https://www.kernel.org/doc/html/next/security/tpm/tpm-security.html doesn't read to me like Linux setups guard against that, though I am not an expert on TPM stuff and might well be missing something...

@jann @Foxboron If you can power cycle the TPM independently of the CPU, then this allows you to reset the PCRs, and that would of course compromise all of boot integrity. A hw bug like that is hard to fight.

Some aspects of that could probably be addressed with @jejb's recent kernel TPM work, but only passively (i.e. we could eventually detect that this happens, and reboot, but not stop people to continue access the TPM for a while with the reset PCRs).

@jann @Foxboron @pid_eins since 6.10 the Linux kernel will detect and mitigate reset attacks. I demoed this working in my #OSSummit talk in Tokyo this week. The video should be up on YouTube.

@pid_eins @jann @Foxboron no, its active. If the kernel detects a reset attack it disables the TPM. It takes the kernel about a minute to detect because it has to ping the TPM to detect, which usually happens with RNG reseeding.

@jejb sure, but that's what i meant with "passive" actually: within that minute all apps will talk to the TPM not knowing it is compromised. And a minute is a long time.

@pid_eins so I also gave some advice on how apps can detect instantly, but they have to salt sessions using the null seed to benefit from this.