Bypassing disk encryption on systems with automatic TPM2 unlock

Original Article ↗ Hacker News Discussion ↗

Motivations and Concerns Around Passwordless TPM FDE

  • Many find passwordless TPM-based full-disk encryption (FDE) inherently risky under physical-compromise threat models.
  • Others argue it’s “good enough” for opportunistic theft: a random thief is unlikely to exploit OS or bootloader vulnerabilities.
  • Several people see automatic encryption as dangerous UX: users can be locked out by hardware failure or policy without realizing their data was ever encrypted.

Use Cases: Laptops, Servers, and Remote Systems

  • Laptops: Many prefer typing a strong passphrase at boot; some use biometrics for OS login but still want FDE with a password.
  • Home/remote servers and NAS: Owners want protection if disks/servers are stolen but also require unattended reboot, making manual passphrases impractical.
  • Corporate environments: Compliance teams often mandate TPM/Secure Boot based on vendor messaging, not deep understanding.

Alternatives for Unattended Boot

  • Network-based unlock: Clevis/Tang, dracut-sshd, Dropbear, Mandos allow remote or network-bound decryption.
  • Hardware tokens/USB: Random keys on USB or FIDO2 tokens used at boot, with plausible deniability and convenience, but risks of loss/theft.
  • kexec tricks: Boot into a small environment that forwards the FDE passphrase to the real system.

TPM, PCRs, and Proposed Mitigations

  • Discussion of sealing LUKS keys to TPM PCRs (0,2,7,8,9,15) and how updates break measurements.
  • The specific attack works even if kernel/initrd are measured, because it swaps the encrypted volume and relies on the initrd’s password fallback.
  • Mitigations proposed:
    • Measure or verify the encrypted volume itself (e.g., LUKS header hash, “prehash” file on rootfs).
    • Use PCR15 as a one-shot: extend it with random data after first unseal so later code can’t re-unseal.
    • Combine LUKS encryption (confidentiality) with dm-verity/fs-verity (integrity).
    • Use intrusion switches or case tamper detection to lock TPM.

Secure Boot, initramfs, and OS Ecosystem

  • Criticism that desktop Linux typically does not sign or verify initramfs, weakening Secure Boot.
  • UKI and tools like openSUSE’s sdbootutil aim to bind kernel+initrd+command line to TPM measurements and update them automatically, but workflows are complex.
  • ChromeOS, Android, and Apple are cited as examples where verified boot plus encryption and a smaller, simpler boot chain provide stronger guarantees.

Disk Encryption Tradeoffs and Threat Models

  • FDE simplifies RMA/disposal and allows fast data destruction by wiping TPM keys.
  • Physical destruction of drives is debated as simpler vs wasteful and not always reliable.
  • Concerns about future cryptanalysis mostly target public-key schemes; symmetric AES with long keys is seen as safer.
  • Some argue per-file or per-user encryption (Android, APFS) is more user-friendly than classic FDE, but desktop support is limited.

Windows/BitLocker and TPM+PIN/Password

  • BitLocker is discussed; it also faces TPM-bypass style issues in other research.
  • TPM+PIN is viewed favorably but rarely deployed; combining TPM with a user password (deriving/wrapping keys) is suggested as a stronger hybrid.