feuristic threat model¶
This document states what feuristic protects, against whom, and where its protection ends (spec §10.9). It is reviewed with every release.
1. Assets¶
| Asset | Where it lives |
|---|---|
| FIDO2 discoverable credential keys, U2F/non-discoverable wrapping keys | protected storage (FIDO_CREDS, keys derived from the master secret) |
| OpenPGP, PIV, AES keys | protected storage (CARD) |
| OTP secrets, HOTP counters | protected storage (OTP), public counters |
| device master secret (32 B) | protected storage (SYS), RAM only while unlocked |
| device PIN, FIDO clientPIN, OpenPGP/PIV PINs | PIN: upstream storage + Optiga stretching; app PINs: salted hashes |
| backup passphrase | never stored; RAM during export/restore only |
| user intent | physical confirmation on the device screen |
Protected storage is upstream's norcow storage: every protected value is encrypted with ChaCha20-Poly1305 under a data key wrapped by the PIN-derived key (PBKDF2 + Optiga PIN stretching), with a global authentication tag.
2. Attackers and scenarios¶
| # | Scenario (spec §10.9) | Mitigations | Residual risk |
|---|---|---|---|
| T1 | Compromised host (malware on the PC) | Every private-key operation, export, erase and overwrite requires a physical confirmation that shows the operation, the relying party / key role and a fingerprint (spec §6.3); FIDO prompts show the RP ID verified by the platform; nonces for AES-GCM are generated by the device; no secret ever leaves over USB in normal mode; all USB parsing (CTAP CBOR, APDUs, SCSI, images) runs unprivileged with strict bounds. | The host chooses what is signed/decrypted; the device shows a digest ("Signature d'empreinte non interprétée"), not the meaning. A user approving blindly can be abused. |
| T2 | QR photographed by a third party | OTP export requires the device PIN, a DANGER confirmation with an explicit warning, and hides the QR after 60 s; backup frames are AES-256-GCM encrypted. | A plaintext otpauth:// QR photographed during display reveals the OTP secret (by design, spec §8.1). |
| T3 | Stolen backup images | Encrypted envelope (AES-256-GCM), key from PBKDF2-HMAC-SHA256 with 600 000 iterations, 16-byte salt, passphrase ≥ 12 characters chosen on the device. | Offline guessing of a weak passphrase. Users are told that a backup makes keys recoverable (spec §8.2). |
| T4 | Device lost | PIN required at power-on and after 5 min idle; storage encrypted at rest; master secret dropped from RAM on lock. | Attacks on the MCU/Optiga beyond upstream's guarantees; see §3. |
| T5 | Altered restore (malicious frames) | Frames have a CRC (transport) and the envelope is authenticated before any parsing; plaintext must be canonical CBOR and pass strict schema validation; every overwrite shows the identity name and fingerprint and needs a specific confirmation; restore is atomic per identity. | An attacker who knows the passphrase can produce a valid backup (it is then simply a backup). |
| T6 | Hostile USB host / malicious files | MSC volume never exposes secrets; images are decoded unprivileged into a bounded bitmap (no full-frame buffer), size/dimension limits, fuzzed decoders (PNG/zlib, JPEG, QR, FAT12/SCSI, CCID, CTAP); the kernel classes only move 64-byte packets and copy data into kernel buffers; mode switches only happen from the device menu. | Bugs in decoders are contained to the unprivileged coreapp by upstream's MPU isolation, but the coreapp holds unlocked key material. |
| T7 | Flash failure / power loss | Copy-on-write record store with generations, A/B blobs, redundant counters written stale-first, nonce reservation; tested with power-cut injection at every storage step. | Wear-out of the 64 KiB storage sectors over very long use; upstream norcow behaviour on T2B1 partial writes (fault → PIN counter). |
| T8 | Wrong PIN / brute force | Upstream PIN: exponential delays, wipe after 16 failures (Optiga counter). FIDO clientPIN: 8 attempts, 3 per power cycle. OpenPGP/PIV PINs: 3 attempts, counters decremented before checking and persistent. | — |
| T9 | Device theft with observation (shoulder surfing of the PIN) | PIN entry on the device (carousel, not the host keyboard). | An observer of the PIN who later steals the device. |
3. Trust boundaries and assumptions¶
- Bootloader unlocked. feuristic runs under the official bootloader's "unsafe vendor" header. Unlocking wipes the Optiga pairing secret: the shielded channel and attestation keys are unavailable (so FIDO uses self attestation), but Optiga PIN stretching remains in use.
- No secure boot of feuristic. Anyone with physical access can install other firmware, which wipes the storage (vendor change), so secrets are not exposed — but a malicious firmware could later capture a newly entered PIN. Users should treat a device that left their control as untrusted.
- Side channels. Cryptography runs on the MCU (trezor-crypto, BearSSL constant-time i31 code with blinding and result verification for RSA). "Computed in the Trezor" does not mean "inside the secure element" (spec §1.1).
- RAM cleanup. Locking closes private workers and pollers, drops provider
caches and the master-secret reference, and runs collection. Temporary native
image buffers and explicitly mutable backup keys/passphrases are wiped before
release. MicroPython immutable
bytes/str, decrypted object copies and Rust text-input buffers do not currently have a complete zeroization guarantee; upstream GC does not clear every freed block. A locked device therefore does not establish forensic absence of prior secrets from SRAM. R15 requires instrumented inspection and a recorded decision before stable qualification. - Emulator. The emulator and debug builds (debuglink, insecure storage testing mode) are for development only.
4. Non-goals¶
- Protecting against a user who approves malicious operations.
- Hiding which RPs or services a device is used with from someone holding the unlocked device.
- Resistance to invasive hardware attacks beyond the upstream design.
5. Review triggers¶
Any change to: storage layout, KDF labels, USB descriptors or classes, parsers of untrusted input, confirmation prompts, backup format, PIN handling.