Hardware wallets and account separation

EN source master · P03-L06 · needs_review

Offline/read-only study only. Never provide secrets, passwords or authentication codes. No wallet connection, real approval, live revocation, transaction signature, transfer, funds or trade. Visuals are specifications only.

Separating signing roles can reduce how much authority is routinely exposed, but the benefit depends on the actual capabilities and shared dependencies. A hardware device is not a universal safety verdict.

Separate keys from the requested action

The manufacturer documentation describes signing inside hardware and checking a trusted display [HW]. This is a mechanism description, not proof that every supported request is safe or fully intelligible. Keeping keys inside a device does not remove the consequences of a harmful authorization that is knowingly or mistakenly accepted.

Design the roles on paper

The fixture uses a watch-only role, an interaction role and a reserve-signing role. List which tasks each needs: public inspection, application interaction or infrequent authorization. Do not assume a role can do something merely because its screen shows a balance. No accounts are created and no funds moved in this exercise.

Compare design A, where two signing roles share one recovery capability, with design B, where the fixture stipulates separate capabilities. A separation of labels or addresses does not necessarily separate failure domains. If a shared recovery capability is exposed, the fixture's two roles depend on the same secret. BIP-39 explains a recovery derivation mechanism [BIP39]; it is not a guarantee about every wallet's derivation or independence.

Name residual risks

Even in design B, an untrusted prompt can ask the interaction role for excessive permissions. The reserve role can also authorize harmful effects if review fails. Display support, firmware/software provenance, physical handling and confidential backup handling are separate dependencies. The fixture supplies no assessment of a real product or current firmware.

Use a dependency matrix rather than a claim of zero risk. If the card does not specify whether two roles share a recovery capability, mark that relationship UNKNOWN. Never ask the learner to enter a backup to determine it. A sanitized architectural statement is sufficient for the classroom exercise.

State the bounded benefit

OBSERVED: stipulated role/capability rows. INFERRED: how the stated shared dependency affects the separation model. UNKNOWN: actual devices, backups and operational behavior. INSUFFICIENT EVIDENCE: “hardware guarantees safety.” Separation is a workflow design to be evaluated under assumptions, not personalized financial guidance or an instruction to transfer real holdings.

• Watch-only: observation role without supplied signing capability.
• Signing role: capability-bound authorization function.
• Failure domain: shared dependency that can affect several roles.
• Trusted display: device-local review surface with its own support limits.

ILLUSTRATIVE paper designs. Roles WATCH/INTERACT/RESERVE. WATCH has public locators only. Design A: INTERACT and RESERVE use the same stipulated RECOVERY-CAP-A placeholder. Design B: distinct placeholder capabilities CAP-B/C, no real secrets. Both include a device-review step; decode/display coverage UNKNOWN. No balances or real accounts supplied.

Wallet-role graph with typed displays/authorizes/shared-recovery edges. Design A shares one confidential-dependency node; design B separates it under stipulation. Add residual prompt/display/provenance risks to both, never a green ‘guaranteed safe’ badge.

Role assignments and shared-dependency differences stipulated in two illustrative designs.

Real account independence, immunity to harmful signing, safe firmware, recovery correctness or guaranteed protection.

• Different addresses assumed independent secrets.
• Hardware assumed to prevent every harmful authorization.
• Collecting backups to prove architectural separation.

Build a role/capability matrix for A/B and list three remaining risks. Assess what the watch role can do. Write a bounded benefit statement without asking for secrets or prescribing real transfers.

Submit a table and bounded conclusion using only supplied offline material. Editorial time allocation: study 12 min, exercise 8 min, correction/quiz 10 min.

• Define tasks before role labels.
• Separate display from authorization.
• Record shared dependencies without secrets.
• List review/provenance residual risks.
• Keep benefits conditional and offline.

Role separation must follow capabilities and dependencies. Hardware isolation supports a specific security mechanism while authorization, backup and interface risks remain.

• Design a separation workflow and state its residual risks
• Design role separation without supplying credentials.
• Identify remaining approval, recovery and interface risks.

P03-L07 after prerequisite and correction review.

NONE in authoritative catalog. Provided offline data suffice; no product purchase or wallet operation required.

• [HW] Trezor hardware wallet documentation — Device-isolated signing and trusted display; manufacturer explanation, not safety guarantee.
• [BIP39] BIP-39 mnemonic seed specification — Mnemonic-to-seed derivation with optional passphrase; not fixture authentication.

Documentation explains mechanisms. Historical records retain their declared source class. Source inspection is not independent editorial acceptance.