Secure Boot and TPM: What They Protect (and What They Don't)

The threat that Secure Boot and measured boot exist to address is a specific one: persistent compromise of the system before the operating system loads. Malware that achieves persistence at the bootloader or firmware level — below the operating system — is unusually hard to detect and remove, because the OS itself is running on a compromised foundation. Every tool you run to investigate the compromise is itself potentially compromised.

UEFI bootkits like FinFisher/FinSpy (used in targeted attacks), the "MosaicRegressor" UEFI implant documented by Kaspersky in 2020, and more recently the BlackLotus bootkit (publicly documented by ESET in 2023) represent this class of attack. Understanding what Secure Boot and TPM do requires understanding this threat first.

Secure Boot: What It Actually Checks

Secure Boot is a UEFI firmware feature. When enabled, the firmware will only execute bootloaders whose cryptographic signatures can be verified against a database of trusted keys stored in firmware. On most consumer hardware, this database contains Microsoft's key (the "Microsoft Corporation UEFI CA 2011") and potentially OEM-specific keys.

The chain of trust works as follows:

1. UEFI firmware starts (trusted by assumption — it's on the hardware)
2. Firmware checks the signature of the bootloader against its key database
3. If the signature is valid, the bootloader runs
4. The bootloader checks the signature of the OS kernel
5. The kernel boots

If any link in this chain fails — if an unsigned or maliciously signed bootloader is present — Secure Boot prevents execution. This stops an attacker who has physical access to your machine and tries to boot from a USB drive with a malicious OS, or who modifies the bootloader on disk after the fact.

The BlackLotus Exception: When Secure Boot Gets Bypassed

In 2023, ESET documented BlackLotus — the first publicly known UEFI bootkit capable of bypassing Secure Boot on fully patched Windows 11 systems. It exploited a vulnerability (CVE-2022-21894, known as "Baton Drop") to roll back a legitimate signed bootloader to a vulnerable version, then used that vulnerable bootloader as its entry point.

The vulnerability was patched by Microsoft in January 2022, but the signed vulnerable bootloader couldn't be immediately revoked without breaking a large number of legitimate systems that hadn't updated. Distributing a revocation via the Secure Boot key database requires a process called "dbx" (Secure Boot Forbidden Signature Database) updates, which are pushed more slowly and carefully than typical patches. BlackLotus exploited this window.

This illustrates a structural limitation: Secure Boot's effectiveness depends on timely revocation of compromised signatures. The revocation infrastructure is slower than the attack. A determined adversary with access to a signed but vulnerable bootloader can potentially bypass Secure Boot even on otherwise up-to-date hardware.

TPM: The Secrets Hardware

A Trusted Platform Module (TPM) is a dedicated security chip (or firmware implementation) that provides tamper-resistant key storage and a set of cryptographic operations. The TPM 2.0 specification (required for Windows 11) includes:

• Key generation and storage: Private keys generated inside the TPM cannot be extracted in plaintext — they're used for operations inside the chip.
• Platform Configuration Registers (PCRs): SHA-256 hash registers that record measurements of the boot process. Each stage of boot extends a PCR with a hash of what ran, creating an immutable record of the boot sequence.
• Sealing: Secrets (like a disk encryption key) can be sealed to specific PCR values — they can only be unsealed if the boot process matches the expected measurements exactly.
• Attestation: The TPM can sign a statement about the current PCR values, allowing a remote party to verify what state the system is in.

The most widely used application of TPM sealing is disk encryption. BitLocker (Windows) and LUKS with TPM2 binding (Linux) can seal the volume encryption key to PCR values. If someone removes the disk and puts it in another machine — or modifies the bootloader to change the PCR values — the key doesn't unseal and the disk stays encrypted.

Measured Boot vs. Secure Boot: The Important Difference

These are related but distinct concepts that are often conflated:

Feature	Secure Boot	Measured Boot
What it does	Prevents unsigned or untrusted code from running at boot	Records a hash chain of what actually ran into TPM PCRs
Mechanism	Signature verification; blocks execution on failure	Hash measurement; records without blocking
Enforcement	Active — prevents malicious boot	Passive — records what happened for later verification
Primary use case	Prevent bootkit installation	Seal disk encryption keys; remote attestation
Bypassed by	Signed-but-vulnerable bootloaders; firmware attacks	Pre-measurement firmware compromise; Evil Maid with physical PCR reset

What Neither Technology Protects Against

Secure Boot and TPM together address the boot integrity threat model. They say nothing about what happens after the OS loads. Once you're past the boot chain:

• Kernel exploits that run malicious code with kernel privileges after boot
• User-space malware delivered via browser exploit, phishing, or malicious software
• Privileged process compromise — a compromised process running as root can modify the running system even if boot was clean
• Hardware implants installed below the firmware level (e.g., on the PCIe bus, embedded network controllers, or baseboard management controllers)
• Cold boot attacks — physical RAM extraction while the system is running or recently suspended; RAM contents persist briefly after power loss and can be read with specialized equipment
• Evil Maid attacks that modify the firmware itself (not the bootloader) — firmware updates are typically not covered by Secure Boot's chain

Secure Boot protects the boot process. It does not protect the running system. An attacker who exploits a vulnerability in your browser or email client after boot can still compromise your system entirely, regardless of how clean the boot was.

TPM-Backed Disk Encryption: A Practical Example

Consider a laptop with LUKS full-disk encryption, where the encryption key is sealed to TPM PCR values representing a clean boot. What does this protect?

• ✓ Someone steals the laptop and removes the disk — they cannot decrypt it on another machine
• ✓ Someone modifies the bootloader on disk (changes PCR values) — the key won't unseal, encryption stays in place
• ✗ Someone boots the laptop normally with your password — they access your data
• ✗ Someone compromises a running service after boot — they can access decrypted data in memory
• ✗ Someone has a cold boot attack opportunity — decrypted key may still be in RAM

TPM-sealed disk encryption protects against theft of the physical hardware. It does not protect data against an attacker who can authenticate as you, or who compromises the running system.

Relevance to Encrypted Communications

For applications like encrypted messaging and email, the boot integrity layer matters primarily as a foundation. An app can be cryptographically sound — using MLS or forward-secret protocols — but if the OS it runs on has been compromised at the boot level, the attacker can read plaintext messages directly from memory. A valid Secure Boot chain is a prerequisite for trusting the software stack above it, not a guarantee of security throughout.

Haven's server infrastructure uses LUKS2 with TPM2 binding for disk encryption, providing protection against disk extraction. Beyond that, the security model relies on application-layer encryption: MLS for group messaging and PGP for email, with client-side key derivation that means keys exist on the server only briefly during active sessions. The boot integrity layer is necessary but not sufficient — it's one layer of a defense-in-depth stack.

If you're evaluating your own system security, Secure Boot and TPM 2.0 enabled is a sensible baseline. Pair it with full-disk encryption, minimal software footprint, and current OS updates — and understand that together these address the boot integrity and theft threat model, not the broader "running system under attack" threat model.