BA-10 · LESSON 05

Hardware-wallet threat models

KEY DEFINITIONS

Terms used in this lesson

UX: User experience: how a person understands and interacts with a product or device.
PSBT: Partially Signed Bitcoin Transaction: a format for passing an unsigned or partly signed transaction between constructors and signers.
Descriptor: A machine-readable description of the scripts, keys, and derivation paths a Bitcoin wallet watches or can spend.

Secure elements, firmware, host compromise, supply chains, and verification UX define actual signing security.

35 min Difficulty 3/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · coinjoin inferenceCoinJoin changes the observer's set of plausible linksSelect any state to inspect its exact role.

RELATIONSHIP MAPOrdered mechanism flow

01
INPUTS5 users, independent inputs
Multiple participants contribute inputs to one transaction.
02
OUTPUTSFive equal 100k outputs
Equal denominations make direct input-to-output assignment less certain.
03
OBSERVERFive plausible equal outputs
The transaction changes inference probabilities; it does not prove anonymity.
04
AFTERWARDKeep coins separated
Post-mix spending can undo earlier ambiguity.
05
BOUNDARYResidual timing and network risk
Network observers, coordinator knowledge, and unique amounts remain separate threat surfaces.

Rule shown: Equal-value collaborative outputs can weaken deterministic-looking payment links, but amount, timing, input ownership, later consolidation, and coordinator metadata still matter.

STAGE 1 OF 5INPUTS: 5 users, independent inputs

Multiple participants contribute inputs to one transaction.

Governing relationship: Equal-value collaborative outputs can weaken deterministic-looking payment links, but amount, timing, input ownership, later consolidation, and coordinator metadata still matter. Complete path: 1. INPUTS, 5 users, independent inputs. Multiple participants contribute inputs to one transaction. 2. OUTPUTS, Five equal 100k outputs. Equal denominations make direct input-to-output assignment less certain. 3. OBSERVER, Five plausible equal outputs. The transaction changes inference probabilities; it does not prove anonymity. 4. AFTERWARD, Keep coins separated. Post-mix spending can undo earlier ambiguity. 5. BOUNDARY, Residual timing and network risk. Network observers, coordinator knowledge, and unique amounts remain separate threat surfaces.

1. State transitionWhat exists, what changes, and what results

BEFORE

Host proposes input 1,000,000 sats, payment 600,000, supposed change 390,000, and fee 10,000.

MECHANISM

The device should use adequate entropy and keep secrets within its protected storage. Users need a verifiable backup and setup process.

AFTER

A trusted display needs trusted policy derivation, not merely correct input-minus-output arithmetic.

Text equivalent: Starting from Host proposes input 1,000,000 sats, payment 600,000, supposed change 390,000, and fee 10,000. The mechanism begins when The device should use adequate entropy and keep secrets within its protected storage. Users need a verifiable backup and setup process. The resulting lesson is A trusted display needs trusted policy derivation, not merely correct input-minus-output arithmetic.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Generate keys in a trusted boundary

The device should use adequate entropy and keep secrets within its protected storage. Users need a verifiable backup and setup process.

Complete path: 1. Generate keys in a trusted boundary: The device should use adequate entropy and keep secrets within its protected storage. Users need a verifiable backup and setup process. 2. Receive an untrusted proposal: A host supplies address requests or a Partially Signed Bitcoin Transaction (PSBT). Malware can substitute destinations, amounts, fee, change, or derivation data. 3. Parse and display independently: The device derives expected scripts and shows critical transaction facts on its own screen. Limited displays and blind-signing modes weaken this defense. 4. Authorize exact data: After user confirmation, firmware signs only the defined digest under policy. A compromised device or malicious firmware can still violate this promise. 5. Verify firmware and physical lifecycle: Authentic updates, reproducible builds where available, tamper evidence, vendor recovery, duress claims, and disposal all belong in the threat model.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

The signing device independently checks recipient intent, complete value arithmetic, descriptor-derived change, fee limit, and trusted-display confirmation before authorizing exact bytes.

CHANGED CONDITION

Destination substitution, false change, excessive fee, malicious firmware, or untested backup remains dangerous even when the private key never leaves the device.

Important distinction: A hardware wallet makes a compromised computer harmless. It can prevent direct key extraction, but the host can still manipulate transaction proposals, availability, privacy, updates, or what the user sees outside the device.

Text equivalent: The accepted path is enforced by The signing device independently checks recipient intent, complete value arithmetic, descriptor-derived change, fee limit, and trusted-display confirmation before authorizing exact bytes. If the required condition changes, Destination substitution, false change, excessive fee, malicious firmware, or untested backup remains dangerous even when the private key never leaves the device.

Loading lesson visuals...

Learn the idea

A hardware wallet is a signing device intended to keep private keys isolated from a potentially compromised host. A secure element is a chip designed to resist key extraction. Firmware is the device software, and supply-chain risk covers tampering before the user receives it. Security depends on transaction verification, update trust, backup, and recovery, not just chip isolation.

GUIDED EXPLANATION1/5 ideas inspected

Generate keys in a trusted boundary

The device should use adequate entropy and keep secrets within its protected storage. Users need a verifiable backup and setup process.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A hardware wallet makes a compromised computer harmless.”

It can prevent direct key extraction, but the host can still manipulate transaction proposals, availability, privacy, updates, or what the user sees outside the device.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.