Threat model ยท open for audit
Here's exactly where we think it holds. Prove us wrong.
A security project that hides its limits is marketing. This page lists what scroll-secure is designed to stop, what it can't stop, and what we haven't checked yet. Every hole you find becomes a fix, a credit and a regression test.
Designed to stop
| Attack | What stops it |
|---|---|
| Stolen or seized machine, powered off | The disk needs this machine's TPM and your FIDO2 key, each with its own PIN, or the recovery passphrase. |
| Evil maid swaps the bootloader, kernel, initramfs or kernel command line | Secure Boot with your keys only: unsigned code doesn't run. A kernel signed by anyone else also fails the signed PCR 11 policy, so the TPM releases nothing. |
| Evil maid changes the firmware's Secure Boot settings or keys | PCR 7 changes, so the TPM releases nothing. You notice because you're asked for the passphrase. |
| Tampering with the OS on disk | The composefs digest of /usr is in the signed command line, so a modified image doesn't boot. |
| Guessing the PINs | The TPM's dictionary-attack lockout, and the FIDO2 key's retry limit (3 per power-up, 8 in total, then it locks). |
| A stolen FIDO2 key, or a shoulder-surfed PIN, alone | Not enough. Both tokens and both PINs are required. |
| Root on the running system asking the TPM for the disk key | PCR 11 is extended when the initramfs ends, so the policy can't be satisfied again until reboot. |
| A confined system service reading the PIN config | The SELinux type tokenvault_conf_t. Tested: NetworkManager is denied. |
| Walking up to an unlocked, idle session | It auto-locks after 5 minutes and before suspend. Unlocking needs the key, the PIN, a touch and the password. A crashed locker leaves the session locked. |
| Being forced to unlock the lock screen | The duress canary: typed at any prompt, it hard-resets the machine instead of unlocking, without touching the key or PAM. Limits under "Not stopped". |
Not stopped. Know these.
- The recovery passphrase skips both tokens. LUKS keyslot 0 stays as your way back in, so your disk is only as strong as that passphrase. Make it long and random, and keep it offline.
- Root compromise while the system is running. The disk is open and its key is in memory. The PINs are in a root-only file (needed for unattended re-enrollment), so root can read them too.
- Downgrade to an older signed kernel. The signed PCR 11 policy accepts any UKI signed with your PCR key, including old ones with known bugs. Rotating the PCR key retires them, and re-enrollment is required.
- Firmware-level implants, malicious firmware updates, and the Intel ME / AMD PSP. These sit below Secure Boot.
- Escaping a VM. KVM shares the host kernel. This isn't Xen-grade isolation; see vs Qubes OS.
- Coercion. If someone can make you type the PINs and touch the key, they get in. At the lock screen you can type the duress canary instead. It never unlocks: the machine hard-resets at once (no shutdown sequence), and the disk is back behind the TPM PIN, the key PIN and a touch. It doesn't help against someone who knows about the canary or watched you set it, against coercion at boot (there is no boot-time duress PIN), or against a copy taken before you're asked. Any process running as you can trigger the reset. RAM isn't wiped: the LUKS volume key is in memory while the system runs, and the reset doesn't erase it. The kernel is built without
CONFIG_RESET_ATTACK_MITIGATIONand nothing sets the firmware's memory-overwrite request (in the VM:MemoryOverwriteRequestControlpresent, value 0). So someone who can read RAM right after the reset (a cold-boot attack) may recover the key. Secure Boot with your keys only stops booting their own tools, not moving the DIMMs. - The headless remote session. VNC has no password. It listens on a Unix socket in the user's runtime directory (mode 0700), so other local users can't reach it, but any process running as the user can. It is meant to be reached over SSH, and it doesn't idle-lock.
Not evaluated yet
- TPM bus sniffing and interposers on discrete TPMs
- Cold boot and DMA attacks on a running machine
- Side channels in the FIDO2 key's
hmac-secretimplementation - Real-hardware runs beyond the single machine this was built on
Found something? We want it.
Report vulnerabilities privately through GitHub security advisories. Use public issues for everything else. Confirmed findings get a fix, credit in the release notes, and a test in the e2e suite so they stay fixed.