How hardware wallets protect keys: the security model
A security-engineering look at hardware wallets: seed generation, secure elements versus microcontrollers, trusted displays, air-gapped signing, supply-chain attacks and backup design.
A hardware wallet is a dedicated signing device: it holds private keys, shows you what you are about to sign on its own screen and returns only the signature to an untrusted computer. Whatever you think of the assets they protect, these devices are an excellent case study in isolating a key from a hostile host, and the same design questions apply to any offline signer, from code-signing tokens to root CA ceremonies.
This guide treats them strictly as security engineering. It is not financial or investment advice.
The threat model
A hardware wallet is designed to stay safe when:
- The host is compromised. Malware on the laptop can change what the wallet software displays, swap destination addresses in the clipboard or send manipulated transactions to the device.
- The device is stolen. A thief should not be able to extract keys without the PIN, and repeated wrong PINs should wipe the device.
- The device is lost or destroyed. The owner must be able to restore keys from a backup.
It is not designed to protect against a user who types the recovery phrase into a website, a coerced owner, or a device that was tampered with before it reached the owner. Those are addressed by process, not silicon.
Seeds, derivation and why the backup is the real key
Most wallets follow a family of widely used standards:
| Standard | What it defines |
|---|---|
| BIP-39 | Encoding random entropy as a 12 to 24 word mnemonic, and turning it (plus an optional passphrase) into a binary seed |
| BIP-32 | Hierarchical deterministic derivation: one seed produces a tree of key pairs |
| BIP-44 / BIP-84 / BIP-86 | Derivation path conventions for different account and address types |
| SLIP-39 | Splitting a secret into shares with Shamir's secret sharing (for example any 2 of 3) |
The practical consequence: the mnemonic is the key. Anyone who reads it can recreate every private key on any compatible device, without touching the hardware. A perfectly secured device is worthless if the paper backup is photographed.
Entropy quality matters too. A device must generate the seed from a good hardware random number generator. Devices with auditable firmware sometimes let users add their own entropy (for example dice rolls) and verify how it was mixed.
Secure element versus general-purpose microcontroller
Two architectures dominate:
| Secure element (SE) | General-purpose MCU | |
|---|---|---|
| Silicon | Smart-card-class chip with countermeasures against glitching, side channels and probing, often Common Criteria EAL5+ or higher | Standard microcontroller |
| Physical attack resistance | High; designed against lab attacks | Lower; published research has extracted secrets from some MCUs with voltage glitching |
| Firmware transparency | SE firmware is usually closed and under NDA | Firmware can be fully open source and reproducibly built |
| Typical design | Keys and PIN checks inside the SE; an MCU or the SE drives the screen | Keys protected by the MCU, sometimes encrypted with a PIN-derived key |
Many recent designs combine both: open firmware on the MCU for transparency and an SE for storing a secret that only releases material after PIN verification. There is no universally right answer; decide whether you worry more about physical extraction after theft (favors SE) or about trusting closed code (favors open, reproducible firmware), and look for designs that address both.
A strong passphrase (the optional BIP-39 "extra word") mitigates physical extraction in either architecture, because the stored seed alone is not enough.
The trusted display is the whole point
The most important feature is not the chip; it is what-you-see-is-what-you-sign. The device must show the destination address, amount and fees on its own screen, derived from the transaction it is signing, not from data the host provides for display. If you only ever confirm on the computer screen, clipboard-swapping malware wins.
Good practice for any offline signer:
- Verify the full destination on the device screen, not just the first and last characters.
- Verify receive addresses on the device before sharing them.
- Treat a device that cannot display what it signs (sometimes called blind signing) as a lower-assurance mode, and disable it unless strictly needed.
Connectivity: USB, Bluetooth, NFC or air-gapped
| Mode | How data moves | Considerations |
|---|---|---|
| USB | Direct connection | Largest host attack surface; simplest to use |
| Bluetooth / NFC | Wireless to a phone | Convenient; adds radio stack and pairing to the attack surface |
| Air-gapped (QR codes, microSD) | Partially signed transactions (for example PSBT) moved via camera or card | No electrical connection to the host; slower; the data format still needs parsing |
An air gap removes USB as a path for exploits, but the device still parses untrusted input, so firmware quality still matters.
Supply-chain attacks are the realistic threat
Documented attacks against users rarely involve lab equipment. They look like this:
- Counterfeit or tampered devices sold through third-party marketplaces, sometimes with a pre-printed "recovery phrase" card so the attacker knows the key.
- Physical mail scams after customer-database leaks, sending look-alike devices or letters asking users to "update" by entering their phrase.
- Fake companion apps and browser extensions that ask for the mnemonic.
- Phishing support channels posing as the vendor.
Countermeasures:
- Buy from the manufacturer or an authorized reseller; avoid second-hand devices.
- Check tamper evidence, then rely on the device's own genuineness check (many models verify an attestation from the vendor during setup).
- Only accept a seed generated on the device during first setup.
- Download software only from the vendor's verified site and verify signatures where offered.
- Remember that no legitimate vendor or support agent will ever ask for the recovery phrase.
Backup design
A backup plan must survive both theft and disaster:
| Approach | Protects against | Weakness |
|---|---|---|
| Paper mnemonic in a safe | Device loss | Fire, water, anyone with safe access |
| Stamped metal plate | Fire and water | Still a single point of compromise |
| Mnemonic + passphrase stored separately | Discovery of the mnemonic alone | Losing the passphrase is permanent |
| Shamir shares (SLIP-39), for example 2 of 3 | Loss of one share, discovery of one share | More moving parts; needs documentation |
| Multisignature across devices | Compromise of one device or backup | More complex setup and recovery |
Whatever you choose, test recovery on a second device with a small amount before trusting it, and write down the procedure for whoever would need to execute it if you cannot.
Evaluation checklist
- Is the seed generated on the device, from a documented RNG, and never exported in the clear?
- What protects keys at rest: secure element, encrypted storage, or both? What certifications exist and for which component?
- Is the firmware open source, reproducibly built and signed? How are updates verified by the device?
- Does the screen show full transaction details for every type of operation you need?
- What is the PIN retry limit and wipe behavior?
- How does the device prove it is genuine at setup?
- Which backup standards does it support (BIP-39, passphrase, SLIP-39, multisig)?
The same questions work for any key-holding device. A hardware wallet is simply one where the cost of getting them wrong is immediate and irreversible.