What Researchers Actually Found When They Attacked Hardware Wallets

Every few months there's a headline saying hardware wallets get hacked. I wanted to know what the published attacks actually needed, so I went through them.

The short version

Researchers have extracted keys from hardware wallets. But every documented case required physical access to the device, often with the case opened, or a unit that had been tampered with before the owner unboxed it. Nobody has done it remotely to someone using their wallet normally.

Wallet.fail (2018)

At the Chaos Communication Congress in December 2018, three researchers presented Wallet.fail after spending months taking apart Trezor, Ledger and KeepKey devices.

• On the Trezor One they pulled the private key out. It only worked because no passphrase was set. A passphrase (the optional "25th word") closes that exact path.
• On the Ledger Nano S they compromised the bootloader and ran their own firmware. They got it to play Snake. The secure element holding the key was not affected.

Both attacks needed the physical device, usually opened up with a screwdriver.

The supply chain angle

In March 2018, Saleem Rashid, then 15, showed that the Ledger Nano S's non-secure microcontroller could be made to misreport the installed firmware to the secure element. The realistic risk is a device tampered with during manufacturing or shipping, not a wallet attacked while you use it. Ledger patched the flaw and now points buyers to its own store and verified resellers.

EUCLEAK (2024)

NinjaLab's EUCLEAK attack hit a cryptographic library from Infineon. That library sits in security chips like those in YubiKeys and, more broadly, some hardware wallets. The flaw went unnoticed for roughly 14 years and passed around 80 Common Criteria evaluations. Getting the key out took electromagnetic side-channel measurements and specialized lab equipment. Certification lowers risk, but it doesn't remove it.

The 2020 Ledger "hack" that wasn't a wallet hack

In June 2020, Ledger's e-commerce and marketing database was breached. About one million email addresses and roughly 270,000 physical addresses and phone numbers were exposed. Recovery phrases, private keys and funds were not touched. The leak did lead to targeted phishing, which is a real problem, but it is a different one from compromised hardware.

What I'd do with this

• Set a passphrase. It directly defeated the Wallet.fail key extraction on the Trezor One.
• Buy from the vendor or an authorized reseller to avoid the supply chain risk.
• Keep the device somewhere a stranger can't casually reach it. Every attack above needed uninterrupted physical access.
• Update the firmware when the vendor tells you to.

I wrote a longer version with more detail on my site: https://www.cryptonnft.com/wallets-security/can-hardware-wallet-be-hacked/

Comments

[Harun - solo dev]

crypton, this is a brilliantly clear breakdown of hardware wallet security. separating the sensationalized headlines from the actual attack vectors (physical access, supply chain, side-channel) is exactly the kind of nuanced analysis the web3 space needs.

your point about the passphrase being the ultimate fallback is a perfect example of defense-in-depth. when the physical boundary (the secure element or microcontroller) is compromised, the logical boundary (the 25th word) is what actually protects the user.

this mirrors the exact same philosophy i apply to software security, like building secure js sandboxes for ai execution: assume the outer layer can be breached or tricked, and design the inner layer to strictly validate and fail closed. whether it's a hardware wallet or a constrained browser environment, the rule remains the same—never rely on a single point of failure.

thanks for cutting through the noise and focusing on the actual mechanics of these attacks. 🐯