8. Out of scope

This profile does not defend against the following, and a signer that conforms to it does not either. Most of the list is docs/THREAT-MODEL.md, "Out of scope", restated without the nullroute specifics.

• Physical extraction. No secure element is assumed. An attacker holding the storage is limited by the passphrase and the key-stretching cost only.
• Side channels and fault injection on the signer's hardware: power, electromagnetic, acoustic, timing, glitching. SP-SIG-1 gives up the fault injection resistance that random aux_rand would add.
• A signer whose boot chain is not verified by its silicon (below tier 2), where an attacker who rewrites the boot partition controls every value in section 4.
• Evil maid access without tier 2. Tier 1 makes an unsophisticated change visible to a user who reads the boot screen, and nothing more.
• Malicious hardware in the supply chain. Nothing in this profile checks that the board is what it claims to be.
• Coercion. Nothing here helps someone under credible physical threat.
• Unfair or observed dice. The signer cannot detect either (SP-ENT-11).
• A user who does not read the screen. Every requirement in section 3 assumes the review is read. SP-REV-21 makes the user scroll through it and cannot make them read it.
• A malicious address the user intended. The review shows where money goes; it cannot know where the user meant it to go. Checking a receive address on the signer is the defence against a coordinator showing a different one.
• Privacy from anyone who sees the screen. A QR code is a picture, and an extended public key reveals every address the wallet will use.
• Two implementations wrong the same way. Differential tests catch disagreement, not shared error.
• The user's own operational security.