Cryptocurrency Hardware Wallet: Threat Model

From Kicksecure
Jump to navigation Jump to search

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.

Introduction[edit]

Info Hardware wallets might increase security under some threat models but this requires knowledge. Most users lack the required background knowledge and will still lose their cryptocurrency under many different attack models. [1]

Info Note: The term "account number" rather than "address" is used throughout this wiki entry in order to avoid confusion.

Hardware walletsarchive.org 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 air gaparchive.org:

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.

Summary[edit]

While a tiny bit oversimplified and more nuanced [2], 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/archive.org

The proposed solution is multi-sig across a variety of hardware devices to hedge that risk.XMR2020archive.org, Monero XMR reddit moderator, comment on redditarchive.org

To add:

  • 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[edit]

It is absolutely crucial to understand the concept of an insecure display versus a secure display.

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" (WYSIWYSarchive.org). [3]

Threat Model[edit]

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
  • 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.
Recipient Account Number Discovery Risk
  • 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 Sarchive.org 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 Xarchive.org does not have the above problem and shows the full account number at once, providing an opportunity to verify it in full.
      • The Ledger Staxarchive.org might have a bigger display.
      • The Ledger Bluearchive.org has a big display. The device was once sold as a premium device but later deprecated. [4]
  • 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.
Receiving Account Number Transmission Risk
  • 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.
Account Balance Discovery Risk
  • 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.
Recipient Account Number Transmission Risk
  • 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.
Clipboard Attack Risk
  • Threat: Quote EthClipper: A Clipboard Meddling Attack on Hardware Wallets with Address Verification Evasionarchive.org:

    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.
SPV Wallet Risk
  • 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.org:

[...]

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 Guidearchive.org:

      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.

Privacy Disaster
  • Threat: 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.
  • Workaround: Same as above.
Purchase Data Leaks
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.
Unauthorized Physical Access (attacker gains physical access to the device)
Usability
  • 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
Miscellaneous
  • more obscure to attack than a "simple trojan horse": yes
Multisig
  • Introduction: multisigarchive.org 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: no
  • risk of restoration issues: higher
Non-Freedom Software / Closed Source Code
  • Avoid Non-Freedom Software!
  • Ledger firmware is not Open Source. It is non-freedom software at time of writing. [7] It will most likely remain closed source according to Ledger. [8]
  • There might be other, Open Source, Freedom Software based hardware wallets.
Low Quality of Randomness
  • 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-miscarchive.org (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 randomnessarchive.org:

      • 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. [9]
  • 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 walletarchive.org:

      • 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?
Impracticality of Workarounds Risk
  • 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.
Device Deprecation Risk
  • The ledger blue was once sold as a premium device but later deprecated. [4]
  • Quote Ledger Co-Founder btchiparchive.org:

    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.

  • In such cases, the user must import the Secret Recovery Phrase (SRP) into different hardware or software wallet.
Risk from Physical Possession of a Hardware Wallet
  • Threat: Possession of a wallet indicates you have crypto and care about not loosing it.
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.Ledgerarchive.org

Using a wallet requires a minimal amount of trust. If your hypothesis is that your wallet provider is the attacker, you’re doomed.Ledger CTOarchive.org

See also Key Extraction.

Targeted Attacks / Firmware Verification of your Hardware Wallet

Introduction:

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.

Comparison

  • A) Computer Hardware: 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) Hardware Wallet: 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.

Discussion

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.

Conclusion

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.

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.Ledger CTOarchive.org

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 blockchainLedger CTOarchive.org

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.Ledger FAQarchive.org

But that information is likely outdatedarchive.org. 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 Kraken Security Labs Identifies Supply Chain Attacks Against Ledger Nano X Walletsarchive.org

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

  • 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.Ledger Blog Postarchive.org

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.

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.Ledger Blog Postarchive.org

Vulnerabilities List of Hardware Wallet Hacksarchive.org
Secure Element Different hardware wallets have different secure elements. These have different security properties and certifications. See Secure Element in Hardware Walletsarchive.org.

Recommendations[edit]

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!Thread: 10 Rules for Verification on a #Bitcoin Hardware Walletarchive.org

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!

ledger feature request: show balance on hardware wallet screenarchive.org

Capabilities and Limitations[edit]

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.

Key Extraction[edit]

Ledger in the past claimed.

The secret keys or seed are never exposed to the BLE stack and never, ever leave the Secure Element.Ledger Blog Postarchive.org

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.Ledger Twitterarchive.org

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.Ledger blog post, web archived version from 13 February 2020archive.org

Private keys always remain within the Secure Element.https://www.ledger.com/academy/security/not-all-chips-are-born-equalarchive.org

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?@TanukiBTC on Twitterarchive.org

More importantly, what stops Ledger themselves updating the firmware with a backdoor that uploads your keys to whichever government agency asked them nicely?@HaxorMarty on Twitterarchive.org

The only concern is if we get subpoenaed by a government.Ledger CEOarchive.org

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]Christopher Allenarchive.org

Donations[edit]

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.

Bitcoin accepted here Donate Bitcoin (BTC) to Kicksecure.

3DaJWfHyLv4RVnvMD7K2Mz2AX2r3fwiQwV

Monero accepted here Donate Monero (XMR) to Kicksecure.

84ozcSohQfoV6nRgGfaQ8uBvWphXAH8zDTTuotVnJWF1JMNQfvgNFdbEo4ZnJ9hxPMeYfJuUoWGH3MRaXCfbYk8sFFgm4XL

Ethereum accepted here Donate Ethereum (ETH) or Token to Kicksecure.

0xf27EAe399f186600Dc6e5A418793C4A3D58a74e7

See Also[edit]

Open Source Secure Elements:

Footnotes[edit]

  1. ↑ Twitterarchive.org
  2. ↑ The part about the random number generator being a black box. Some hardware vendors are providing more information. This is documented below.
  3. ↑ In other words, just sign what you see.
  4. ↑ 4.0 4.1
  5. ↑ No actual reports of this happening in the media. More correct wording might be "would have been"?
  6. ↑ Twitterarchive.org
  7. ↑
  8. ↑

    Cannot open-source some specific chip-related information due to non-disclosure agreements.https://www.ledger.com/academy/security/not-all-chips-are-born-equalarchive.org

    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-equalarchive.org

    The translation and summary of "within the possible limits" in plain English is: It will never be fully Open Source.

  9. ↑
Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Hardware_Wallet_Security&oldid=84641"