Heads
Tamper-evident Firmware with User-controlled Keys
Kyle Rankin
Chief Security Officer
Purism
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.
Questions?
Additional Resources