Cryptocurrency Hardware Wallet: Threat Model
How Bitcoin can be stolen even when using a hardware wallet. Comprehensive compendium of threats and defenses.
Updated on 25 May 2023 to discuss Ledger Recovery key extraction.
Hardware wallets are:
... a physical device on which a user stores their private keys to access their blockchain wallets. These devices don’t have to be electronic. Any physical item that can store a private key is considered a hardware wallet.
From a general perspective, hardware wallets are convenient, secure, and immune to many of the hazards other wallet types can fall victim too.
Hardware wallets are also an implementation of an
An air gap, air wall, air gapping or disconnected network is a network security measure employed on one or more computers to ensure that a secure computer network is physically isolated from unsecured networks, such as the public Internet or an unsecured local area network.
While a tiny bit oversimplified and more nuanced , the following quote is a fair summary.
Hardware wallets essentially require full faith and trust in the manufacturer. The community assesses this trustworthiness primarily by reputation. However, firmware updates are frequent and are pushed on the end user. If a critical exploit or backdoor exists, it is likely to be exploited all at once.
Here are a few issues:
- You can't compile your own software for hardware wallets. Full trust and faith in the manufacturer is required.
- Software frequently updates, and is often forced on the user by vendor wallets. Even a once trustworthy wallet can at any point update to steal all your funds. Every update is a risk for new bugs or backdoors.
- They rely on specialized supply chains vulnerable to hardware (and software) based exploits.
- They are bad from a privacy perspective. If you use manufacturer supplied web-wallet, they are essentially sending your balance and transactions directly to chain analysis.
- Random number generation for the seed is a black box. Users have no way of knowing if the seed is safe.
Using core software on a dedicated air-gapped machine reduces all of these vulnerabilities to a single one: critical flaws in the protocol itself. This drastically reduces the amount of trusted third parties and potential attack surface. No wallet software can protect against a broken protocol.
This podcast episodes discusses some of the limitations of hardware wallets: https://stephanlivera.com/episode/215/
The proposed solution is multi-sig across a variety of hardware devices to hedge that risk.
- Users cannot verify that they are running the same firmware on their hardware wallet that the vendor of the hardware wallet published.
- This and the other points are being elaborated below.
Insecure Display versus Secure Display
It is absolutely crucial to understand the concept of an
insecure display versus a
In essence, hardware wallets seek to secure users' funds under the sane assumption that the computer in use may be compromised by malware. Once infected this way, malware can:
- secretly view all user actions without obvious signs;
- manipulate the screen, such as showing one account number instead of another correct account number; and
- capture all key strokes (sniff passwords), download files and perform other malicious actions.
For these reasons the computer display is considered an untrustworthy, an
insecure display, while the display of the hardware device is considered trustworthy, a
secure display. The reason for considering the hardware device's display to be trustworthy is that vendors of hardware wallets enforce a requirement that only signed software must be used. Unless the cryptographic verification process that prevents unsigned software from running on the hardware wallet can be subverted, the hardware wallet is considered to be free of malware and therefore a secure display. In other arenas, this security concept is referred to as "What you see is what you sign" (WYSIWYS). 
In order to perform cryptocurrency transactions securely, a number of threats must be averted so funds are not lost to attackers.
Table: Hardware Wallet Threats
|Threat Domain||Description and Recommendations|
|Failure to Understand Basic Threat Model Risk||
|Recipient Account Number Discovery Risk||
|Receiving Account Number Transmission Risk||
|Account Balance Discovery Risk||
|Recipient Account Number Transmission Risk||
|Clipboard Attack Risk||
|SPV Wallet Risk||
|Purchase Data Leaks||
|Time of Compromise Matters||
|Unauthorized Physical Access (attacker gains physical access to the device)||
|Non-Freedom Software / Closed Source Code|
|Low Quality of Randomness||
|Impracticality of Workarounds Risk||
|Device Deprecation Risk||
|Risk from Physical Possession of a Hardware Wallet||
|Malicious Wallet Firmware / Trust||
See also Key Extraction.
|Targeted Attacks / Firmware Verification of your Hardware Wallet||
Even if the software (firmware) running on a hardware wallet is,
How can individuals verify that they are running the same firmware on their hardware wallet that the vendor of the hardware wallet published?
That is, of course without trusting the hardware wallet. Sending a command to the hardware wallet which is processed by the firmware is not a valid way to verify that because a malicious firmware would lie and pretend it is genuine.
While Open Source software, security audits, and reproducible builds contribute to the transparency and trustworthiness of the firmware, they do not directly address the issue of verifying the firmware on a specific hardware wallet.
The firmware is usually signed by the vendor using a private key, and the hardware wallet verifies the signature using the corresponding public key during the firmware update process. This ensures that only authentic and unaltered firmware by the hardware wallet vendor can be installed on the device.
Trusting the Hardware Wallet Vendor is Required
While this signature verification process provides some level of assurance, it still requires trust in the vendor's integrity and the security of their signing process. Users must rely on the reputation and track record of the hardware wallet manufacturer to trust that they have implemented secure measures to prevent unauthorized firmware modifications.
In summary, without trusting the hardware wallet manufacturer or the device itself, it is challenging to independently verify the firmware running on a hardware wallet. This has been confirmed by Ledger's CTO, see the citation in the next column.
Users often have to rely on the reputation, security practices, and transparency of the manufacturer to establish confidence in the authenticity and integrity of the firmware.
The author is unaware of any methods for verification of the firmware on a specific hardware wallet. Users are therefore at risk of receiving targeted malicious firmware upgrade.
In the past there might have been very limited ways to verify the loaded firmware using the JTAG interface.
But that information is likely outdated. It also was not very helpful for a few reasons:
In a later blog post Ledger in context of fixing a security issue Ledger stated that JTAG has been disabled by default
While disabling the JTAG by default can fix some security issues, it makes verification of the firmware impossible.
If that JTAG was enabled, one would have to trust the device electronics to output the real firmware and not a different firmware for the purpose of hiding a backdoor.
There might be other hardware wallets with functional JTAG interfaces or other mechanisms to extract the firmware for the purpose of verification.
|Obscurity||Firmware might not only be closed source but might even be encrypted.
|Vulnerabilities||List of Hardware Wallet Hacks|
|Secure Element||Different hardware wallets have different secure elements. These have different security properties and certifications. See Secure Element in Hardware Wallets.|
Rule #1: DO NOT TRUST THE COMPUTER SCREEN.
The very reason for using a hardware wallet is that your computer IS compromised, trusting it makes using the hardware wallet an expensive security theatre (or 2FA at best). Always verify on the HWW device screen!
Indeed. This is a different way to put it than the formal wording above.
Rule #2: Verify your "receive" addresses BEFORE accepting funds.
A compromised computer can be tricked into displaying addresses that belong to an attacker. The only way to make sure you own the addresses is to display them on the HWW device and verify they match.
Always use the "show address on device" feature of the hardware wallet.
Rule #3: Verifying change address should be done by the device when sending funds, not before like receive addresses!
It is pointless at best, and misleading at worst, to verify them beforehand like receive addresses... All hardware wallets support verifying the change address belongs to you AT TIME OF SIGNING A TRANSACTION. Verifying before that is pointless and error-prone.
Crypto change addresses provide additional privacy and security by generating a new address for receiving change in cryptocurrency transactions.
Rule #8: For convenience, you may print out/ write down a large batch of your receiving addresses - verify all at the same time, and rely on that paper list for your day to day verification.
Consider ignoring this advice if all crypto currency addresses should remain concealed and secured by Full Disk Encryption.
Rule #10: Hardware wallets cannot verify your balances - and that's great!
Verifying balances requires getting information from the Bitcoin network - i.e. you need to be online - which would make hww more vulnerable... This is where a full node comes in! It is strongly recommended that you run your own Bitcoin full node - and use it as your main source for verifying your balances and transaction history! For redundancy, you could double-check against block explorers or another node (use a different device for either!). One last thing: These rules apply to any device you use as a segregated signing device - be it a "traditional" hardware wallet, an airgapped laptop, a mobile phone etc.
If you want to separate your keys without having a security theatre, you should verify on your signing device!
Capabilities and Limitations
It is crucial to understand the capabilities and limitations of a hardware wallet.
A hardware wallet can:
- store a private key,
- show an account number on the hardware wallet secure display,
- sign a transaction to spend cryptocurrency.
A hardware wallet doesn't "know":
- account balances,
- if payment receipt account number (those the user intents to send payments to) is correct.
Hardware wallets cannot:
- securely transmit an account number to a third party such as for example a cryptocurrency exchange.
A hardware wallet is not a complete cryptocurrency wallet. It is only the component of the wallet which - hopefully securely - stores the key to access the cryptocurrency. The user needs to be aware of the missing components of a hardware wallet and unfortunately entrust that functionality with the conceptually untrusted computer and its insecure display.
Ledger in the past claimed.
The secret keys or seed are never exposed to the BLE stack and never, ever leave the Secure Element.
Hi - your private keys never leave the Secure Element chip, which has never been hacked. The Secure Element is 3rd party certified, and is the same technology as used in passports and credit cards. A firmware update cannot extract the private keys from the Secure Element.
While Ledger is using a dual chip system with an MCU as well, the important part is that your private keys remain inside the Secure Element – they are not sent out for processing transactions. Equally the device’s firmware and all cryptographic operations are held within the Secure Element chip.
Private keys always remain within the Secure Element.
It later turned out that the Secure Element is not very secure since private keys can be extracted from the Secure Element.
The Ledger firmware update introducing a recovery feature ("Ledger Recovery") is able to effectively extract the key from the Secure Element.
The people who use Ledger hardware wallets never requested this feature. There was a huge community backslash.
The feature which was "lost" is that the secure element should be able to sign transactions but be unable to release its private key under any circumstances.
Even if the secure element were actually as secure from the firmware as Ledger previously claimed, it could still always signed a different transaction, thereby rendering this feature even if it existed would not provide much security. The firmware is always a man-in-the-middle in front of the secure element.
The missing design goal demonstrated here is also to keep the functionality, source code minimal to allow easier audits through third parties, lower complexity and attack surface. Issue here is also that feature creep. Always evolving progress is counter to security. What would be needed here would be something similar to "washing machines". If these were sold only once and then the model kept unchanged. Simple functionality. No firmware updates.
Previously, Ledger could even install a malicious firmware on a seized ledger seized from cold storage and extract the private keys. The Ledger Recovery feature opens up to Ledger having the capability to release a malicious firmware upgrade which gets deployed to select individuals only to remotely steal their private keys.
The Ledger Recovery feature is opt-in. It is protected by the user clicking "yes" on the device. A different ways to see it is to say that leaking the private keys remotely over the internet to third parties is just only one conformation away.
People are worried about the increased attack surface.
1) Answer me this one: What stops a hacker from exploiting the new code that you added to the firmware to extract the shards based on a users seed?
More importantly, what stops Ledger themselves updating the firmware with a backdoor that uploads your keys to whichever government agency asked them nicely?
The only concern is if we get subpoenaed by a government.
One of my concerns with the new @Ledger Recover service is that they appears to be sharding via Shamir’s Secret Sharing, but doing so in a proprietary way and possibly in a naive fashion. We don’t know, as it is not open source. [1/11]
If this wiki page has contributed to safekeeping of crypto currency, please consider making a donation to Kicksecure to help keep it running for many years to come.
- EthClipper: A Clipboard Meddling Attack on Hardware Wallets with Address Verification Evasion
- Kraken Security Labs Identifies Supply Chain Attacks Against Ledger Nano X Wallets
- Ledger Phishing Scam Targets Crypto Hardware Wallet Users
- Anatomy of a Phishing Attack
- Beware of phishing attempts
- Ongoing phishing campaigns
- Hack #1 – Check out this link!
- Hack #2 – A stranger is calling you
- Hack #3 – Do you have WiFi password?
- Hack #4 – The hacker sees all
- Hack #5 – Malicious Wallet App
- Cryptocurrency Security Threats
- Social Engineering and (Spear) Phishing
Open Source Secure Elements:
- Twitter (alternative)
- The part about the random number generator being a black box. Some hardware vendors are providing more information. This is documented below.
- In other words, just sign what you see.
- No actual reports of this happening in the media. More correct wording might be "would have been"?
- Twitter (alternative)
Cannot open-source some specific chip-related information due to non-disclosure agreements.
We are working on open-sourcing more of Ledger's source code running on top of the Secure Element within the possible limits.
The translation and summary of "within the possible limits" in plain English is: It will never be fully Open Source.