Référence en anglais
Cette page technique est disponible en anglais. Les guides d’utilisation et d’installation sont traduits en français.
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.