
Hacking the most popular cryptocurrency hardware wallets [video] - panarky
https://media.ccc.de/v/35c3-9563-wallet_fail
======
DennisP
Great presentation. Highlights for those short on time:

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

~~~
frozeus
Response from Ledger : [https://www.ledger.fr/2018/12/28/chaos-communication-
congres...](https://www.ledger.fr/2018/12/28/chaos-communication-congress-in-
response-to-wallet-fails-presentation/)

nothing critical

~~~
askmike
[I'm no expert on hardware security]

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

~~~
DennisP
Nitpick: it's the Trezor that has the stickers. The Ledger comes with a
printed note explaining that stickers are worthless.

~~~
askmike
fair point, I keep confusing the two.

------
dfox
Typical cryptocurrency hardware wallet is horribly insecure as far as typical
requirements for HSM go, which is at least to me somewhat expected and
understandable.

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.

~~~
social_quotient
HSM = hardware security module
[https://en.m.wikipedia.org/wiki/Hardware_security_module](https://en.m.wikipedia.org/wiki/Hardware_security_module)

------
Scoundreller
Quick summary for those that can't watch the stream (to the best of my
understanding):

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.

------
technion
I opened up the RSA SecureID token I had years ago. It had a glue poured
inside until the whole thing was basically solid. I spent hours trying to pull
bits off it and ended up snapping the board.

It's overly surprisingly to me something so simple didn't seem to be a feature
in these devices.

~~~
Scoundreller
That works against you. With the hollow devices, you can weigh it to see if
there’s a difference.

If it’s full of glue, remove glue, add your implant and add enough
counterweight so it weighs the same as the stock device.

~~~
pjc50
> remove glue

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...](https://webcache.googleusercontent.com/search?q=cache:HERKv5MloV0J:https://csrc.nist.gov/CSRC/media/Presentations/FIPS-140-3-Section-5-Physical-
Security/images-
media/physecpre18.pdf+&cd=1&hl=en&ct=clnk&gl=uk&client=firefox-b-ab) (google
cache version because the US has decided to be a failed state for a few weeks
again)

~~~
technion
Thanks for that info. These devices are FIPS certified so I'd expect you've
explained exactly what it was.

------
owaty
To make sure I understand, these attacks only work if someone get hold of your
hardware wallet (either before or after it's delivered)? So they are stil safe
if you buy it directly from the vendor (and trust your delivery service etc.)?

~~~
DennisP
The worst attack was against the Trezor; in that case, after your funds are on
the device they could steal it, extract the seed, and steal your funds. Using
a strong passphrase prevents this attack.

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.

~~~
michaelt

      All attacks against the Ledger Nano required them to
      get access to the device then give it back to you.
    

Presumably if you were planning to exploit these things, you'd blend in with
the 90 third-party Ledger Nano S resellers on Amazon [1], offering a slightly
lower price.

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.

[1] [https://www.amazon.com/gp/offer-
listing/B01J66NF46/](https://www.amazon.com/gp/offer-listing/B01J66NF46/)

~~~
DennisP
That'd be devastating but so far none of the attacks have managed to make the
Ledger create predictable private keys. You'd have to hack the secure chip to
pull that off.

------
alexnewman
this is why the yubikey has two processors? one secure one not?

~~~
cyphar
The Ledger also has two processors and that added very little security. Bad
firmware on the insecure chip could completely fool the user, because the
secure chip didn't have access to any of the peripherals. Thus the bad chip
could ask for a different payload to be signed (or could skip verification
entirely) and so on.

~~~
DennisP
Well it added some security, they weren't able to just extract the seed and
PIN like they did with the Trezor. Instead of immediately stealing funds
they'd have to return the Ledger to the user, and a careful user could check
the signed transaction on another device.

------
Scoundreller
Dupe of
[https://news.ycombinator.com/item?id=18771987](https://news.ycombinator.com/item?id=18771987)

An interesting topic nonetheless. I dunno why people put such faith in tiny
devices less known than an offline airgapped piece of x86 hardware.

~~~
dang
Since the video wasn't available yet when that was posted, we've merged the
on-topic comments from there into this thread.

------
paulpauper
offline entropy. only truly safe way to generate keys

~~~
nayuki
Try computing ECDSA by hand and we'll talk.

~~~
DennisP
Instead just generate the word list, which is what you need anyway to put your
handmade key into the hardware wallet. Pick the words by some truly random
method, like Von Neumann coin flips or picking words out of a hat. The last
word is (partly) an 8-bit checksum made by cryptographic hash of the other
bits; the easiest method without using a computer is probably just to try
different words in the hardware wallet until one works. With the Ledger at
least you'll have to re-enter the first 23 words with every attempt, so on
average you'll be inputing 128 * 24 = 3072 words; at ten seconds per word it's
8.5 hours of focused effort.

~~~
owens99
I'm confused. How is it not 128^24?

~~~
DennisP
All you're doing is using the same 23 words each time, and then finding an
8-bit checksum to match.

(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.)

~~~
owens99
Ok, I got it now :)

