Heads

Tamper-evident Firmware with User-controlled Keys

Kyle Rankin

Chief Security Officer

Purism

Author of Linux Hardening in Hostile Networks

@kylerankin

https://kylerank.in/talks/security/heads.html

Introduction

• I'm not a BIOS/UEFI/TPM expert
• I do have some experience with coreboot/libreboot

• I joined Purism to help work on security
• My first assignment: integration with Heads
• I've ramped up pretty quickly on this type of tamper-evident boot
• This talk:
• Why tamper-evident boot matters
• How Heads Works
• Usability Challenges with Tamper-evident Boot.

Why Tamper-evident Boot Matters

• Many different ways to attack a system
• Goal is to persist in a system undetected
• Some attacks are easier to detect than others
• BIOS and kernel/initrd backdoors hardest to detect
• System trust is anchored in your boot code
• Without trusted boot, decryption keys, login passwords at risk
• To trust boot, need a way to detect tampering with boot code.

UEFI Secure Boot

• A number of different approaches to protect boot
• UEFI Secure Boot most popular method
• Most commonly associated with Windows, but can be used with Linux
• UEFI Secure Boot ensure boot firmware signed by vendor-provided signature
• Only executables with proper signature allowed to run
• Vendor signature typically provided by Microsoft
• RH, Ubuntu, others have gotten boot "shim" signed by MS to support Secure Boot
• UEFI shim then loads the rest of the Linux boot process
• Secure Boot usually (but not always!) can be disabled in UEFI settings.

Intel Trusted Boot

• Intel Trusted Boot uses TPM to verify only trusted code has been executed
• Trusted Platform Module (TPM) a security chip on some motherboards
• TPM acts as a kind of Hardware Security Module (HSM) by generating/storing own keys
• Can perform limited (ie. slow) cryptographic operations on chip w/ own keys
• Stores measurements of executed code in Platform Configuration Registers (PCR)
• Combines hashes of previous measurements with subsequent measurements to confirm trusted code
• If all measurements match, can unlock a secret (disk decryption key for instance)
• Used with Secure Boot, can detect tampering in boot-time executables.

Secure Boot Limitations

• Requires signatures by keys under others' (usually MS) control
• Uses proprietary/closed code, can't change it yourself, can't audit
• Proves that computer executing signed code, but not same code
• What happens if MS signing keys leaked/shared?
• Only validates executables, can't validate initrd, GRUB settings
• Not under user control.

Heads Above the Rest

• Heads is Free Software firmware that provides similar features to Secure+Trusted Boot
• Uses Open Source coreboot firmware as BIOS to initialize hardware
• Provides tamper detection not tamper proofing
• Uses TPM + signing keys under user's control
• Can detect tampering in firmware, kernel, initrd, GRUB
• Limited to hardware w/ TPM that supports coreboot (Thinkpad X220/230, Librem laptops, some servers).

How Heads Works

• Coreboot loads Heads as main payload (instead of SeaBIOS or GRUB)
• Heads uses own Linux kernel + initrd
• Detects tampering in two stages:
• Stage 1: Use TPM to prove Heads not tampered with
• Stage 2: Use user GPG keys to prove files in /boot not tampered with
• If everything checks out, loads GRUB config and boots default kernel.

Boot Security and the TPM

• Stage 1: Use TPM to prove Heads not tampered with
• TPM stores hashes of executables in Platform Configuration Registers (PCR)
• TPM stores TOTP/HOTP secret using TPMTOTP
• As code executes, measurements sent to TPM to store in PCRs
• Each PCR assigned to particular stages of boot code, combines with previous hash
• TPM configured to unlock TPMTOTP secret only if all hashes match
• Integrates with Librem Key/Nitrokey over USB using HOTP
• Can fall back to TOTP code
• TOTP/HOTP secret generates 6-digit code you verify on your key/phone
• If Heads changes, measurements change, TOTP/HOTP code not unlocked
• If attacker modifies TPM, previous code erases, TOTP/HOTP code won't match
• Once Heads is proven safe, can move on to /boot.

Boot Security and GPG Keys

• Stage 2: Use user GPG keys to prove files in /boot not tampered with
• Heads contains GPG keyring that stores trusted GPG public keys
• Store private keys on hardware smart card (Librem Key, Nitrokey, Yubikey, etc.)
• Heads configuration files stored in /boot, signed with your private key
• Checksums for all files in /boot also stored in /boot, signed with your private key
• Before Heads boots your OS, confirms no files in /boot have changed
• If attacker modifies initrd, grub.cfg, or any other file in /boot, Heads complains.

Usability Challenges

• As easy to use as GRUB when nothing changes
• When things change, alert fatigue a real challenge
• User must update key HOTP/phone TOTP code when reflashing BIOS
• User must use GPG smart card to re-sign files in /boot when those change
• How to tell legitimate changes from attacks?
• Reflashing BIOS rare, so Heads changes can trigger stern warnings
• Initrd/grub.cfg changes much more common, triggered by package updates
• If files same before package updates, only changed after, probably legitimate
• If files modifed before package updates, sign of tampering
• What should users do in case of real tampering?
• Sane defaults + providing actionable info vital.

Current Status

• Somewhat limited hardware support
• Started with X220/X230, which requires hardware flashing
• Nitrokey + Insurgo Technologies offering pre-flashed X230s
• Purism supports it as part of "PureBoot" on full laptop / server line
• Offers it as a pre-install firmware option alongside coreboot
• Recent Heads improvements centered on better hardware support and UI.

Tamper-evident Demo

Questions?

Additional Resources

• This talk: https://kylerank.in/talks/security/heads.html
• Official Heads page: http://osresearch.net
• Purism article on Heads integration: https://puri.sm/posts/librem-now-most-secure-laptop-under-full-user-with-tamper-evident-features/