• Threat: Many users lack basic background knowledge such as the difference between a secure display and an insecure display as mentioned in the Introduction chapter of this page.
• Conclusion: 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.
• Workarounds:
  • 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.

• Threat: 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 Ledger Nano S ^[archive] 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 Ledger Nano X ^[archive] does not have the above problem and shows the full account number at once, providing an opportunity to verify it in full.
• Conclusion: 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.
• Workaround: Use multiple computers to discover the account number in the hope they are not all compromised.

• Threat: 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.
• Conclusion: The screen could be modified by malware to fraudulently redirect the withdrawal to an account number held in the attacker's wallet.
• Workarounds:
  • 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.

• Threat: Even if cryptocurrency has been received on the device, the balance is not shown on the hardware wallet secure display.
• Conclusion: The user might mistakenly believe they have received more value than was actually transferred.
• Workaround: Use multiple computers to check the balance (watch-only accounts), in the hope they are not all compromised.

• Threat: 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.
• Workarounds:
  • 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.

• Threat: Quote EthClipper: A Clipboard Meddling Attack on Hardware Wallets with Address Verification Evasion ^[archive]:

  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.

• Workaround: All characters of the account number should be verified on the hardware wallet secure display.

• Information:
  • 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 Does Electrum trust servers? ^[archive]:

[...]

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.

[...]

• Threat: 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.
• Workarounds:
  • Some full validating crypto currency wallets might allow being paired with hardware wallets. Unfortunately, for Bitcoin the official 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 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 10x Security Bitcoin Guide ^[archive]:

    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.

• 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.

• 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.
  • security:
    • 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 ^[3] sufficient to hack Trezor. Trezor was impressively hacked by a 15 years old for a price of $3,700 (0.85 BTC at the time) ^{[archive] [4]}
      • Ledger was vulnerable to malware, evil maid and supply chain attacks. Ledger got impressively hacked by the same 15 years old. ^[archive]
    • 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 carry: yes
• easy to backup: yes
• easy to replace device: yes
• easier than Qubes OS (offline vault VM): yes

• browser support on/off
• ledger device applications do not auto start

• more obscure to attack than a "simple trojan horse": yes

• TODO: short explanation what multisig is
• useful for diversification in multisig: yes
• multisig is easier to use: no
• easy restoration process: no
• risk of restoration issues: higher

• Avoid Non-Freedom Software!
• Ledger firmware is non-freedom software at time of writing. ^[5]

• Threat:
  • 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. See this list of references.
  • security-misc ^[archive] (installed by default in Kicksecure ™ 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 for details.
  • Quote ledger hardware wallet on Quality of randomness ^[archive]:

    • Hardware RNGs like the one used in Ledger hardware wallets use several sources of randomness.

    • But does not elaborate on that page what these several sources of randomness are.
  • Trezor: has a lot more documentation. ^[6]
• Conclusion: A hardware wallet should not be trusted with recovery phrase creation.
• Workarounds:
  • 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. Quote ledger hardware wallet ^[archive]:

    • The Passphrase is an advanced feature that adds a 25th word of your choosing of max 100 characters to your recovery phrase

    • 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:

      • Human-generated passwords: People are notoriously poor at achieving sufficient entropy to produce satisfactory passwords.

      • Simplified: Most human generated passwords are insecure.
    • For information on strong password, see the Passwords page.
  • Would 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?

• Threat: 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).
• Conclusion: It is likely most workarounds will be neglected during various phases due bad usability (difficult to use), limited awareness/skills and/or time pressure.