Hacking the most popular cryptocurrency hardware wallets [video]
media.ccc.de
media.ccc.de
- Holographic stickers are worthless.
- A modified Ledger can include an antenna and chip that will click the "yes" button when signaled.
- It's possible to radio sniff the PIN from a Ledger Blue.
- It's tricky but possible to install custom firmware on the Ledger without it getting flagged as unverified. Said firmware could pass a different transaction into the secure chip than the one you think you're signing.
- It's possible to make the Trezor chip glitch and give you the 24-word seed and the PIN.
nothing critical
This is a full damage contain mode PR article. That said, I do agree that what was presented doesn't mean all ledger's are compromised and or as vulnerable as claimed.
A few attack vectors have been shown that weaken the overall security: When you buy a ledger and you get a box with "tamper proof stickers" and installation software that "verifies the genuine hardware" you don't expect those features to be as circumventable as they are. If ledger knew they were bad/worthless they should have been informing their users about it / removing them.
Also the article states that:
> It is quite an unpractical scenario, whereas it might be easier for a motivated attacker to install a camera in the room to look for the PIN entry.
That's a scenario end users understand and can try to defend themselves again (cover the thing with your other hand). This video proves there is are different attack vectors no one was expecting that is harder to protect against.
> In particular they did not succeed to extract any seed nor PIN on a stolen device. Every sensitive assets stored on the Secure Element remain secure.
I'm not sure they ever claimed that. When I buy a hardware wallet I want it to protect my coins. For me it doesn't matter whether they get stolen through stealing the private key, or through completely owning the wallet and sending coins to hackers when I think I am sending coins to my friend.
Also I am not sure about:
> This scenario requires:
> [..]
> Physically waiting in a side room with an antenna for the victim to enter his PIN and launch the Bitcoin app.
Why does the attacker needs to be there physically? I don't see why this whole thing can't be automated on a raspberry pi that you shove above the ceiling (which is clearly harder to detect than a camera).
The reason for that is that such devices are primarily designed to move the key materialoutside of the effectively allways online client device and thus the typical HSM-style threat models are outside of the design scope.
This is somewhat understandable because designing truly secure HSM is borderline impossible and certainly not economically meaningful for most of the target market.
0. All units tested were easy to open up to access PCB.
1. The security stickers are easily removed and reattached. (There have been clones created).
2. A hardware implant could be created to remotely "hit" the "OK" button for transaction authorizations sent to the hardware with minimal $partcount.
3. Ledger Nano S has an easy-to-access interface (e.g. with pogo pins) for its STM32 MCU (used for its insecure tasks). There is also a 'Secure Enclave" STM31. A compromised STM32 could send malicious transactions to the ST31. Unsigned firmwares used to be loadable, but not anymore. But the bootloader doesn't verify flash on each boot (after a firmware upgrade), instead verifying a space in memory. But STM32's memory map mirrors some addresses. So you can write to the mirrored location the constant it wants to see and load your own unsigned firmware.
4. STM32 sends the firmware to the STM31 to verify it. But they had a workaround with compression and RAM to send the original firmware to the STM31, while running something else. Youtuber: LiveOverflow has further info on this.
5. The Ledger Blue. Has a BT LE module. It doesn't have it enabled, but does have an antenna (on the PCB). With a USB cable as an antenna, they could sniff PIN input. They believe it was probably because the PIN input changes the colour of the button when pressed. They were likely sniffing the display output. 90% accuracy per input. They used AI with automated physical input to train.
6. Trezor 1: Vulnerabilities to glitching attacks. They admit that they couldn't find any other vulnerabilities into it. Using an STM32 again. The Tresor protects against a formerly published UV-based security downgrade attack (Obermaier attack). They attempt to downgrade the Read-Out bytes to give them access (which are in flash). They knew based on how long MCU takes to boot from boot ROM and when application execution is to narrow down when to try to glitch. They used an FPGA to get the timing right (their timing is predictable). A multiplexer was used to switch voltages. Just glitch and see if they have JTAG access. Rinse repeat. Took 3 months to get a successful glitch. They couldn't read the flash, only RAM. Seed is stored in flash. So needed method to get seed into RAM. Upgrade procedure is designed to allow firmware upgrades without erasing seed. It does this by copying seed to RAM. So they would start the firmware process, then dump the RAM. Voila, seeds are plaintext in the dump. And the PIN.
They've built a Trezor glitcher (would require desoldering the chip and placing it in the device socket). They think an Arduino could be fast enough to do the glitch.
To protect against this glitch attacks, a passphrase should do it.
It's overly surprisingly to me something so simple didn't seem to be a feature in these devices.
If it’s full of glue, remove glue, add your implant and add enough counterweight so it weighs the same as the stock device.
It's supposed to be "potting compound", which is a form of epoxy, and if the right one is chosen it's very hard to get it off with anything short of fuming nitric acid. Combined with the microwires trick it can be made extremely difficult to get at the PCB without triggering the tamper detection.
See FIPS 140: https://webcache.googleusercontent.com/search?q=cache:HERKv5... (google cache version because the US has decided to be a failed state for a few weeks again)
Of course, getting there earlier in the supply chain..
I've heard the same for fake IDs: clubs will weigh them to see if their weight is within range of real IDs.
The Ledger Blue was vulnerable to sniffing the PIN entry by radio, but Ledger claims it's not usable in practice.
All attacks against the Ledger Nano required them to get access to the device then give it back to you.
All attacks against the Ledger Nano required them to
get access to the device then give it back to you.
Doctor the devices to use predictable private keys, sell at a loss to be the cheapest seller on Amazon, then grab all the bitcoins at a time of your choosing, because you know the private keys.
An interesting topic nonetheless. I dunno why people put such faith in tiny devices less known than an offline airgapped piece of x86 hardware.
I'm sure bad entropy with hardware wallets is a real problem, but clearly there are far more practical problems.
(Each word is actually 11 bits of entropy, so the last word is 3 bits of entropy plus an 8-bit checksum on all the random bits. You could either determine those 3 random bits in advance and narrow the list to the 256 words that match those 3 bits, or just pick 23 words and randomly pick from the full list for the last word until one works; this is a bit simpler but risks having to try even more than 256 words.)