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''
! scope="col"| '''Threat Domain'''
! scope="col"| '''Description and Recommendations'''
! scope="row"| Failure to Understand Basic Threat Model Risk
* <u>Threat</u>: Many users lack basic background knowledge such as the difference between a <code>secure display</code> and an <code>insecure display</code> as mentioned in the [[#Introduction|Introduction chapter of this page]].
* <u>Conclusion</u>: The computer screen could be modified by malware to fraudulently ask the user to enter the backup recovery seed phrase (recovery phrase) (perhaps under pretense of seed phrase verification) which would then give the attacker full access to all cryptocurrency holdings of the user.
** Learn how to use hardware wallets in combination with a malware free computer first with tiny amounts of cryptocurrency for testing purposes to learn the basic process. Later be suspicious about changes in the workflow and ask for trustworthy advice before proceeding.
! scope="row"| Recipient Account Number Discovery Risk
* <u>Threat</u>: It is difficult for the user view their own recipient account number on the hardware wallet's secure display.
** Ledger Live has a "show address on device" ("show account number") feature, which shows the account number on the secure hardware wallet display.** In some devices, even if the account number is shown it is difficult to read from the display.
*** The [https://shop.ledger.com/products/ledger-nano-s Ledger Nano S] only has a small display and the account number -- which can be 35-45 random characters long -- and is displayed as ticker text which automatically scrolls over the display at high speed. This means at best it is only possible to view the first few and last few characters, while skipping all those in the middle. This provides an opportunity for attackers to try to create an address where the start and end of the address match, but the middle section is under their control.
*** The [https://shop.ledger.com/products/ledger-nano-x Ledger Nano X] does not have the above problem and shows the full account number at once, providing an opportunity to verify it in full.
*** The [https://shop.ledger.com/pages/ledger-stax Ledger Stax] might have a bigger display.
*** The [https://www.ledger.com/ledger-blue-an-enterprise-grade-security-device Ledger Blue] has a big display. The device was once sold as a premium device but later deprecated. <ref name=ledger-blue-deprecation>
* https://www.reddit.com/r/ledgerwallet/comments/flyxo8/is_ledger_blue_fully_unsupporteddeprecated_at/
* https://www.reddit.com/r/ledgerwallet/comments/10lhrd7/now_how_do_i_add_my_ledger_blue_lol_i_know_its/
* https://www.reddit.com/r/ledgerwallet/search/?q=ledger%20blue
* <u>Conclusion</u>: The regular user of a ledger hardware wallet will have difficulty in discovering their own recipient account number in a secure manner, due to the risk of fraudulent modification by malware running on the computer. This means it is also difficult to tell senders of the correct recipient account number without potentially being misled by [[Malware and Firmware Trojans|malware]].
* <u>Workaround</u>: Use multiple computers to discover the account number in the hope they are not all compromised.
! scope="row"| Receiving Account Number Transmission Risk
* <u>Threat</u>: When receiving coins -- such as when withdrawing cryptocurrency from the cryptocurrency exchange -- the user's recipient account number is entered into their computer, which is utilizing an insecure display.
* <u>Conclusion</u>: The screen could be modified by malware to fraudulently redirect the withdrawal to an account number held in the attacker's wallet.
** Use withdrawal account number whitelists if they are offered by the sender.
** This issue does not apply if the user can transmit the recipient account number through a trusted channel.
! scope="row"| Account Balance Discovery Risk
* <u>Threat</u>: Even if cryptocurrency has been received on the device, the balance is not shown on the hardware wallet secure display.
* <u>Conclusion</u>: The user might mistakenly believe they have received more value than was actually transferred.
* <u>Workaround</u>: Use multiple computers to check the balance (watch-only accounts), in the hope they are not all compromised.
! scope="row"| Recipient Account Number Transmission Risk
* <u>Threat</u>: When sending cryptocurrency to merchants or cryptocurrency exchanges, the recipient account number is shown on the computer's insecure display. It could be modified by malware to redirect the receiving account number to the attacker. Since the hardware wallet secure display will ask for confirmation (account number and amount), at least smaller transactions are protected. For example if the user has 1 Bitcoin but only wants to send 0.1 Bitcoin, there is an option to abort the transaction if the ledger display asks to confirm a transaction that is larger than expected.
** This issue does not apply if the recipient account number can be verified through a trusted channel. For example, multiple devices can be used (since it is unlikely they are all infected) or a personal meeting with the sender can occur beforehand.
** It is possible to send funds in small installments and then confirm with the recipient via a secure channel they were received. This limits the amount of funds that may be lost to the size of the installment.
! scope="row"| Clipboard Attack Risk
* <u>Threat</u>: Quote [https://arxiv.org/pdf/2108.14004.pdf EthClipper: A Clipboard Meddling Attack on Hardware Wallets with Address Verification Evasion]: <blockquote>Hardware wallets are designed to withstand malware attacks by isolating their private keys from the cyberspace, but they are vulnerable to the attacks that fake an address stored in a clipboard. To prevent such attacks, a hardware wallet asks the user to verify the recipient address shown on the wallet display. Since crypto addresses are long sequences of random symbols, their manual verification becomes a difficult task. Consequently, many users of hardware wallets elect to verify only a few symbols in the address, and this can be exploited by an attacker. In this work, we introduce EthClipper, an attack that targets owners of hardware wallets on the Ethereum platform. EthClipper malware queries a distributed database of pre-mined accounts in order to select the address with maximum visual similarity to the original one. We design and implement a EthClipper malware, which we test on Trezor, Ledger, and KeepKey wallets.</blockquote>
* <u>Workaround</u>: All characters of the account number should be verified on the hardware wallet secure display.
! scope="row"| SPV Wallet Risk
** There are two different types of wallets. Blockchain full validating and SPV wallets. Full validating wallets have higher system requirements but are more secure.
** For example, [[electrum]] is a popular SPV wallet (which can be combined with hardware wallets) which eloquently documents it disadvantages. Quote [https://electrum.readthedocs.io/en/latest/faq.html#does-electrum-trust-servers Does Electrum trust servers?]:
One of the servers, arbitrarily, is selected as the “main” server.
* The client subscribes to its own addresses (nit: sha256 hashes of scriptPubKeys) so that it would be notified of new transactions touching them. It also synchronizes the existing history of its addresses. This means the client sacrifices some privacy to the server, as the server can now reasonably guess that all these addresses belong to the same entity.
* As above, confirmed transactions are verified via SPV.
* The server is trusted about unconfirmed transactions.
* The server can lie by omission. That is, it can “forget” to mention (both confirmed and unconfirmed) transactions that are relevant to the client.
* The main server is also used for fee estimates, and is trusted with those (low-high sanity limits are applied in the client)
* The main server is also used to broadcast the transactions the client makes.
* <u>Threat</u>: Most if not all official hardware wallet desktop or mobile applications provided by the vendor of the hardware wallet are SPV wallets. Thereby use of SPV wallets is encouraged.
** Some full validating crypto currency wallets might allow being paired with hardware wallets. Unfortunately, for [[Bitcoin]] the official [[Bitcoin#Bitcoin_Core|Bitcoin Core]] has no hardware wallet support yet.
** Therefore alternatively, a full validating node can be run in concert with a SPV wallet. The full validating wallet would run in watch-only mode, either permanently or occasionally whenever the user wants to double check incoming transactions and account balances.
** Running a blockchain full validating node such [[Bitcoin#Bitcoin_Core|Bitcoin Core]] for [[Bitcoin]] is a very good idea since it is much more secure than merely relying on a SPV wallet to verify incoming transactions and account balances. For the expense of setting up a full validating node (setup time, download quota, CPU utilization) a lot higher certainty of receiving real coins can be accomplished. Quote [https://btcguide.github.io/setup-computer/bitcoin-node 10x Security Bitcoin Guide]: <blockquote>Think of your bitcoin node as a fake bitcoin detector, it will confirm that bitcoin’s consensus rules are being followed so that when you receive a payment you can validate that you are getting real bitcoins.</blockquote>
! scope="row"| Privacy Disaster
* <u>Threat</u>: Due to the widespread usage of wallet software provided by vendors like Ledger Live, privacy concerns have become a major issue. This is primarily because the hardware wallet relies on SPV (see above) to manage all cryptocurrencies. Consequently, the server associated with the hardware wallet possesses access to crucial information such as the user's crypto account numbers (addresses), transaction histories, and IP address. This data could potentially be linked together, unveiling the user's pseudonym. Once a single coin or transaction is tied to the user's real identity, the wallet software's server gains complete visibility into all activities originating from the hardware wallet.
* <u>Workaround</u>: Same as above.
! scope="row"| Purchase Data Leaks
* <u>Threat:</u> Real names, shipping addresses, e-mail addresses and phone numbers of buyers have been leaked in the past. See:
** [https://cointelegraph.com/news/ledger-data-leak-a-simple-mistake-exposed-270k-crypto-wallet-buyers Ledger data leak: A ‘simple mistake’ exposed 270K crypto wallet buyers].
** [https://www.coindesk.com/markets/2020/07/29/crypto-wallet-maker-ledger-loses-1m-email-addresses-in-data-theft/ Crypto Wallet Maker Ledger Loses 1M Email Addresses in Data Theft]
** [https://www.coindesk.com/business/2020/12/23/from-sim-swaps-to-home-invasion-threats-ledger-leak-has-cascading-consequences/ From SIM-Swaps to Home-Invasion Threats, Ledger Leak Has Cascading Consequences] ([[Mobile_Phone_Security#SIM_Swapping_Attack|Account and Mobile Devices Security chapter SIM Swapping Attack]])
* <u>Workarounds:</u> Buying a hardware wallet offline with cash.
! scope="row"| Time of Compromise Matters
* Once funds are on the hardware wallet they are safe - depending on the security of hardware wallet - until the user attempts to spend those funds.
* This means if/when the user's computer is compromised later on (after stocking up funds), less funds are lost but all the aforementioned threats apply.
! scope="row"| Unauthorized Physical Access (attacker gains physical access to the device)
| {{anchor|Unauthorized_Physical_Access}}* If the hardware wallet and/or computer are stolen, all funds are safe as long as the user still has the backup recovery seed phrase (recovery phrase). This assumes the attacker is unable to circumvent the hardware wallet PIN entry and/or extract the keys from the device.
* If the user stores the hardware wallet and PIN in the same place and loses it, all funds will be lost.
* If the recovery phrase is lost and hardware wallet or PIN code is lost all funds are irretrievable.
* Compared to full disk encryption:
** usability: It is easier to keep private keys secured.
*** The protections afforded by hardware wallet security are not necessarily stronger than computer full disk encryption (such as LUKS in Linux).
*** Those hardware wallets that include a Secure Element are generally more secure.
*** Some hardware wallets are reported to have been hacked before. Examples:
**** Simple physical theft was <ref>
No actual reports of this happening in the media. More correct wording might be "would have been"?
</ref> sufficient to hack Trezor.
***** [https://www.wired.com/story/i-forgot-my-pin-an-epic-tale-of-losing-dollar30000-in-bitcoin/ Trezor was impressively hacked by a 15 years old for a price of $3,700 (0.85 BTC at the time)] <ref>
{{Twitter_link|el33th4xor/status/925013437226221569|Twitter}}****** A trezor can be secured against physical attacks, theft by using a passphrase. See: [https://blog.trezor.io/our-response-to-the-read-protection-downgrade-attack-28d23f8949c6 Crypto Security Firm Unciphered Claims Ability to Physically Hack Trezor T Wallet]
***** [https://www.coindesk.com/tech/2023/05/24/crypto-security-firm-unciphered-claims-ability-to-physically-hack-trezor-t-wallet/ Crypto Security Firm Unciphered Claims Ability to Physically Hack Trezor T Wallet]
**** Ledger was vulnerable to malware, evil maid and supply chain attacks. [https://saleemrashid.com/2018/03/20/breaking-ledger-security-model/ Ledger got impressively hacked by the same 15 years old.]
*** For some hardware wallets there might be no public reports yet of attackers who gained physical access but not the PIN code (or recovery phrase) and then managed to steal funds.
* easier to safely split bitcoin / bitcoin cash / bitcoin gold: yes
* easy to replace device: yes
* easier than Qubes OS (offline vault VM): yes
! scope="row"| Miscellaneous
* more obscure to attack than a "simple trojan horse": yes
* Introduction: [https://en.bitcoin.it/wiki/Multi-signature multisig] enhances security by requiring multiple signatures for transaction authorization.
* Might hardware wallets be useful for diversification in multisig in theory? Yes.
* Do hardware wallets make multisig easier to use? No, not necessarily.
* easy of restoration process: [[Cryptocurrency_Security_Threats#multisig|no]]
* risk of restoration issues: [[Cryptocurrency_Security_Threats#multisig|higher]]
! scope="row"| Non-Freedom Software / Closed Source Code
* [[Avoid_nonfreedom_software|Avoid Non-Freedom Software]]!
* Ledger firmware is not Open Source. It is non-freedom software at time of writing. <ref>
* https://www.reddit.com/r/ledgerwallet/comments/6vgl1z/is_the_nano_ss_firmware_open_source/
</ref> It will most likely remain closed source according to Ledger. <ref>
Cannot open-source some specific chip-related information due to non-disclosure agreements.
https://www.ledger.com/academy/security/not-all-chips-are-born-equal
We are working on open-sourcing more of Ledger's source code running on top of the Secure Element within the possible limits.
https://www.ledger.com/academy/security/not-all-chips-are-born-equal
The translation and summary of "within the possible limits" in plain English is: It will never be fully Open Source.
* There might be other, Open Source, Freedom Software based hardware wallets.
! scope="row"| Low Quality of Randomness
** The quality of randomness required by the device to create the backup recovery seed phrase (recovery phrase) might be too low. An attack might find a a weakness in the Random Number Generator (RNG) which helps to attacker to guess other other user's recovery phrase and thereby steal their cryptocurrency.
** Since well encrypted data is indistinguishable from random data, it would even be possible for an attacker to subvert the production process of a hardware wallet, thereby compromising the RNG. All tests for verification of randomness would pass but the attacker could have user a cryptographic algorithm and private key which turns the apparently random data into predictable data for the attacker only. Thereby the attacker could wait for the hardware wallet to be widely used before stealing huge amounts of cryptocurrency.
** Suspicious and even proven to be broken RNG's exist. [[Dev/Entropy#RDRAND|See this list of references]].
** [https://github.com/{{project_name_short}}/security-misc security-misc] (installed by default in {{project_name_short}} and Whonix) distrusts the CPU for initial entropy at boot as it is not possible to audit, may contain weaknesses or a backdoor.** [[Kicksecure]] and [[Whonix]] improve entropy generation due to pre-installed entropy generators. See wiki page [[Dev/Entropy#RDRAND|Dev/Entropy]] for details.
** Quote [https://support.ledger.com/hc/en-us/articles/360010073520-Quality-of-randomness ledger hardware wallet on Quality of randomness]:
*** <blockquote>Hardware RNGs like the one used in Ledger hardware wallets use several sources of randomness.</blockquote>
*** But does not elaborate on that page what these several sources of randomness are.
** Trezor: has a lot more documentation. <ref>
* https://wiki.trezor.io/Recovery_seed
* https://wiki.trezor.io/Microcontroller
* https://www.st.com/content/ccc/resource/technical/document/reference_manual/51/f7/f3/06/cd/b6/46/ec/CD00225773.pdf/files/CD00225773.pdf/jcr:content/translations/en.CD00225773.pdf
* https://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf#page=767
* <u>Conclusion</u>: A hardware wallet should not be trusted with recovery phrase creation.
** Create the recovery phrase on a device with high quality randomness (i.e. a computer). This will be very difficult for most users since this requires a malware free computer to begin with.
** Use a passphrase. [https://www.ledger.com/academy/passphrase-an-advanced-security-feature Quote ledger hardware wallet]:
*** <blockquote>The Passphrase is an advanced feature that adds a 25th word of your choosing of max 100 characters to your recovery phrase</blockquote>
*** The passphrase needs a good password strength. Ideally at least as strong as the password strength of recovery phrase since the recovery phrase is in question here. However, such as strong passphrase is difficult to generate for most users. (That is why the default workflow that most hardware wallet vendors lay out is for the recovery phrase to be generated by the hardware and not by the user.) Quote Wikipedia:
**** <blockquote>Human-generated passwords: People are notoriously poor at achieving sufficient entropy to produce satisfactory passwords.</blockquote>
**** Simplified: Most human generated passwords are insecure.
*** For information on strong password, see the [[Passwords]] page.
** Would [[Cryptocurrency_Security_Threats#multisig|multisig]] be an enhancement if one of the signing keys was created on a device different device than a hardware wallet, i.e. a computer?
! scope="row"| Impracticality of Workarounds Risk
* <u>Threat</u>: As denoted by the term, a 'workaround' is not an actual fix. For workarounds to be effective, they require: awareness (of which there is probably very little); wide adoption (very few people are applying these), and easy steps (most are cumbersome due to bad usability).
* <u>Conclusion</u>: It is likely most workarounds will be neglected during various phases due bad usability (difficult to use), limited awareness/skills and/or time pressure.
! scope="row"| Device Deprecation Risk
* The ledger blue was once sold as a premium device but later deprecated. <ref name=ledger-blue-deprecation />
* [https://www.reddit.com/r/ledgerwallet/comments/12syqsx/comment/jh7aktu/?utm_source=reddit&utm_medium=web2x&context=3 Quote Ledger Co-Founder btchip]: <blockquote>That's difficult to say, depends what you mean by long term. I wouldn't suggest to rely on an electronic device for several decades for example.</blockquote>
* In such cases, the user must import the Secret Recovery Phrase (SRP) into different hardware or software wallet.
! scope="row"| Risk from Physical Possession of a Hardware Wallet
* <u>Threat</u>: Possession of a wallet indicates you have crypto and care about not loosing it.
! scope="row"| Malicious Wallet Firmware / Trust
(1/2) Technically speaking it is and always has been possible to write firmware that facilitates key extraction. You have always trusted Ledger not to deploy such firmware whether you knew it or not.
[https://web.archive.org/web/20230518063234/https://twitter.com/ledger_support/status/1658892462440456192 Ledger]
Using a wallet requires a minimal amount of trust. If your hypothesis is that your wallet provider is the attacker, you’re doomed.
[https://twitter.com/P3b7_/status/1659187088477114372 Ledger CTO]
See also [[#Key Extraction|Key Extraction]].
! scope="row"| Targeted Attacks / Firmware Verification of your Hardware Wallet
{{anchor|verify_firmware_device}}Even if the software (firmware) running on a hardware wallet is,
* 100% Open Source and Freedom Software,
* supports [https://en.wikipedia.org/wiki/Reproducible_builds reproducible builds]...
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.
* '''A)''' <u>Computer Hardware:</u> A hard drive can be removed from one computer and plugged into another computer without executing any (malicious) code from the hard drive. The hard drive can then be securely analyzed. (Ignoring the possibility of malicious hard drive firmware.)
* '''B)''' <u>Hardware Wallet:</u> The author is not aware of any hardware wallets that have all their firmware stored on detachable storage medium. For example, in case of the Ledger hardware wallet, the storage is not detachable.
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.
! scope="row"| Hardware Backdoors
And open source doesn’t really solve this. It’s impossible to have guarantees that the electronic itself is not backdoored, nor that the firmware that runs inside the wallet is the one you audited.
[https://twitter.com/P3b7_/status/1659187094764285952 Ledger CTO]
If the wallet wants to implement a backdoor, there are many ways to do it, in the random number generation, in the cryptographic library, in the hardware itself. It’s even possible to create signatures so that the private key can be retrieved only by monitoring the blockchain
[https://twitter.com/P3b7_/status/1659187092184879104 Ledger CTO]
In the past there might have been very limited ways to verify the loaded firmware using the JTAG interface.
You can access the JTAG of the unsecured chip on Ledger Nano X, this allows you to verify the loaded firmware. Please note that upon any signed application launch, the JTAG channel will be permanently closed and cannot be reopened.
[https://support.ledger.com/hc/en-us/articles/360015216913-Frequently-asked-questions Ledger FAQ]
But that information is likely [https://github.com/LedgerHQ/ledger-live/issues/3541 outdated]. It also was not very helpful for a few reasons:
* "upon any signed application launch, the JTAG channel will be permanently closed and cannot be reopened."
* the hashes of the unsecured chip have not been published as criticized by Kraken, quote [https://blog.kraken.com/post/5590/kraken-security-labs-supply-chain-attacks-against-ledger-nano-x/ Kraken Security Labs Identifies Supply Chain Attacks Against Ledger Nano X Wallets]
** <blockquote>This is misleading, because Ledger currently does not actually publish any hashes that would make it possible to check the memory contents against a known firmware image.</blockquote>
* The hardware wallet firmware not being fully open source and not supporting reproducible builds.
* Only mentioning the unsecured chip but not the secure element.
* Requires specialized hardware that most users do not possess.
In a later blog post Ledger in context of fixing a security issue Ledger stated that JTAG has been disabled by default
The new Ledger Nano X firmware update includes an MCU update where the JTAG/SWD debug protocol will be disabled by default instead.
[https://www.ledger.com/enhancing-the-ledger-nano-xs-security Ledger Blog Post]
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.
| Firmware might not only be closed source but might even be encrypted.
When BOLOS needs to be upgraded, a secure channel is established between the Secure Element of the device and Ledger’s HSM. This channel allows to send our firmware in an encrypted way.
[https://www.ledger.com/firmware-1-4-deep-dive-security-fixes Ledger Blog Post]
! scope="row"| Vulnerabilities
| [https://thecharlatan.ch/List-Of-Hardware-Wallet-Hacks/ List of Hardware Wallet Hacks]
! scope="row"| Secure Element
| Different hardware wallets have different secure elements. These have different security properties and certifications. See [https://bitcointalk.org/index.php?topic=5304483 Secure Element in Hardware Wallets].
or create an account