
Breaking the Ledger Security Model - danr4
https://saleemrashid.com/2018/03/20/breaking-ledger-security-model/
======
AlphaWeaver
Saleem Rashid, the security researcher who discovered this vulnerability and
proof of concept is 15 years old. [0]

[0]: [https://krebsonsecurity.com/2018/03/15-year-old-finds-
flaw-i...](https://krebsonsecurity.com/2018/03/15-year-old-finds-flaw-in-
ledger-crypto-wallet/)

~~~
ReverseCold
I met him on Telegram a while back. The joke is that he developed a wallet app
in X months, but could have done it in less if he didn't have homework.

He's definitely one of my motivations to pursue blockchain/cryptography. I
used to be secure (in my bubble) that I was the best at what I do (for my age)
until I met Saleem.

Gratz Saleem :)

------
rdl
I was willing to tolerate Ledger's issues here (I'm a user and I've heavily
recommended their products) if they fixed them -- the problems never should
have happened, but they are marginally better than Trezor in a lot of other
ways.

Unfortunately, the Ledger team appear to be asshats, so there's every reason
to fear using them in the future, even if they've fixed this specific issue.
If they're going to handle a legit issue like this (downplaying it, etc.), I'm
not willing to trust them.

I'd love to see three products created:

1) Split client/server wallets (so you don't need to trust the operator or
your local machine alone); some work has been done on this. Also, split PC +
SGX or phone + secure element wallets. This is basically software-only in
cost, but at higher security, so it would be suitable for $0+ balance
accounts.

2) A low end ($20?) wallet with a cheap display and button. If you retailed
them at $100 but sold them to providers at $40 they could probably give them
away for a lot of accounts; basically like Yubikeys but with displays.

3) Some higher-end hardware wallets; essentially HSMs plus display/input. HSM
technology basically stagnated in 1995; there's a lot of need for something
better today. This could be in the $10-50k per unit range for a lot of high-
value keys if actually implemented well and in a way which had no "trust us"
demons. There are hundreds or thousands of potential customers, and more by
the day.

~~~
hahainternet
> I was willing to tolerate Ledger's issues here ... if they fixed them

> Unfortunately, the Ledger team appear to be asshats, so there's every reason
> to fear using them in the future, even if they've fixed this specific issue

Your first two lines completely contradict each other.

The Nano S is #3 in your list.

~~~
rdl
The problem wasn't the breach, it was their messaging around the breach. I
accept that most products have bugs, even security-critical bugs in security
products (although this one was a bit extreme to tolerate...).

The Nano S isn't really an HSM-containing-wallet. It (and the Trezor) are
somewhere between a smartcard containing just the keys and an HSM. There's
"trusted" display and input, but not the whole wallet. The Nano S also does
have an element of "trust us" vs. an easily verifiable design.

------
Blackthorn
> Before I get to the details of the vulnerability, I would like to make it
> clear that I have not been paid a bounty by Ledger because their responsible
> disclosure agreement would have prevented me from publishing this technical
> report.

Ridiculous. Ledger, pay him the bounty that he quite clearly deserves.

~~~
jv22222
On the ledger blog:

[https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-
secu...](https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-
fixes/)

> We would like to congratulate the three security researchers who found these
> bounties.

> Saleem Rashid – MCU fooling

> We fully appreciate their contribution, and they certainly deserve their
> rewards.

> We have asked each security researcher to sign our Ledger Bounty Program
> Reward Agreement, that you can review as part of our transparency process

> (this document doesn’t prevent the researcher to publish their own reports).

~~~
EthanHeilman
The "Ledger Bounty Program Reward Agreement" appears to have a clause that may
allow Ledger to prevent a researcher from publish their own report.

>"You have complied and will continue to comply with the responsible
disclosure process described in the Ledger Bounty Program which includes your
agreement (a) not to disclose the security related bug to anyone without
Ledger’s prior written consent," \- [0]

I'm not a lawyer so I could be reading this wrong or maybe they never intended
to enforce that clause.

[0]: Ledger Bounty Program Reward Agreement [https://www.ledger.fr/wp-
content/uploads/2018/03/Ledger-Boun...](https://www.ledger.fr/wp-
content/uploads/2018/03/Ledger-Bounty-Program-Reward-Agreement.pdf)

------
StavrosK
I got a Ledger wallet and was too paranoid to trust its seed generation, so I
wrote some code to generate my own seed on an ESP8266 (after a failed attempt
at doing the same thing with just a PDF and dice).

Here's the writeup, with code you can audit/try:

[https://www.stavros.io/posts/perfectly-secure-bitcoin-
wallet...](https://www.stavros.io/posts/perfectly-secure-bitcoin-wallet-
generation/)

~~~
fokinsean
Shit I got mine through Amazon a few months ago and was a bit worried it could
be compromised. My paranoia is kicking in a bit more now after this article.
Do you have any recommendations on checking that my Ledger isn't compromised?
Ledger has some suggestions on their site, but as far as I understand they
only check the integrity of the wallet apps.

~~~
StavrosK
From what the article says, you basically can't be sure, unless you check the
hardware. I would advise at least flashing the original firmware that you can
get from Ledger themselves.

~~~
gh02t
Am I correct in understanding that the exploit would most likely be cleared by
re-flashing the firmware to a known good image before you use it? Especially
if you did so using JTAG it seems like it'd be very difficult (albeit probably
not impossible) for the firmware modifications described in the article to
persist through a reflash as long as you're reasonably confident that the
hardware itself hasn't been altered. That doesn't get rid of the evil maid
scenario, but it does get rid of the supply chain attack, which is IMO the
more concerning one. Evil maid attacks can be mitigated by physical security,
but the supply chain attack is out of your control.

~~~
aeternus
The problem is, if you flash with JTAG you're basically just trusting your
host computer not to be compromised. And isn't not having to trust your host
computer the entire point of a hardware wallet?

~~~
gh02t
Big difference, you're only trusting the host computer (and the JTAG dongle)
_once_. This is manageable, use an airgapped junk laptop with no HDD or
similar if you're ultra paranoid. Sure perhaps the firmware is compromised and
leaking data through some super exotic attack but I mean come on. That should
give you a pretty reasonable level of confidence. You can never 100% trust a
device you didn't design and fabricate every aspect of yourself, there's
always some risk with any hardware token.

I'd also argue that trusting your host computer is certainly better than
trusting the supplier. Shifting the burden of trust from a device you don't
control to one you do is at least an improvement.

------
DyslexicAtheist
Matthew Green had a good analysis on why this is interesting also from outside
a crypto currency perspective
[https://twitter.com/matthew_d_green/status/97606641626793984...](https://twitter.com/matthew_d_green/status/976066416267939840)

~~~
berberous
Interesting part: "For example, the iPhone SEP has a direct connection to the
fingerprint reader, because the application processor isn’t trusted with that
data. Weirdly FaceID departs from this but I digress."

Anyone have any info on why FaceID works a different way? Because it needs
more processing power?

~~~
zxcvgm
I have not seen any sources which explicitly state that FaceID doesn't work
the same way as TouchID does, but perhaps it's the lack of specific details in
the iOS Security Guide [0] that might have led to this assumption?

In fact, FaceID solely relies on the IR camera to do its work. You can cover
the front-facing (normal) camera and your iPhone would still unlock
successfully. Conversely, the newly touted Animoji feature does NOT rely on
the IR camera at all, as evidenced in this iPhone X review [1] at 11:40. It
_may_ be the case that the OS don't have access to it.

[0]
[https://images.apple.com/business/docs/iOS_Security_Guide.pd...](https://images.apple.com/business/docs/iOS_Security_Guide.pdf)

[1]
[https://www.youtube.com/watch?v=9Ca8zWJOlFQ&t=700](https://www.youtube.com/watch?v=9Ca8zWJOlFQ&t=700)

~~~
matthewdgreen
I based my speculation on tweets by some developers who have been able to
capture raw TrueDepth data in their apps. See eg
[https://mobile.twitter.com/braddwyer/status/9306828799773614...](https://mobile.twitter.com/braddwyer/status/930682879977361408)

I can’t swear to you that this is exactly the same depth data that FaceID
uses. Maybe it’s been downsampled in some way that makes it safe to give to
apps, without enabling attacks on FaceID. I think I’d be a bit more willing to
believe that if Apple’s Security docs actually said that. To me it seems more
likely that the raw depth maps are available to the app processor (and to
apps!) because the SEP isn’t powerful enough to perform the recognition task
on its own.

------
debatem1
Cool attack, but the the proposed mitigations don't seem to solve the threat
model.

An attacker on the supply chain can always add a part that interposes on all
i/o to the secure parts. This would have the same impact, unless I'm missing
something, as compromising the insecure micro. The underlying problem is that
there's no cryptographically secure path between the secure element and your
eyes.

Ledger's verifiable erasure scheme is pretty interesting, actually. I
prototyped something similar and ultimately abandoned it due to the high
complexity and bandwidth requirements. From the sounds of it the major
differences were that ledger didn't attempt to wipe and then reinitialize, but
instead just tried to verify know state. Might still be made to work by
changing that, although good luck over a uart.

~~~
limpkin
An attack on the supply chain would have to happen at the very last stages
when the device is assembled, as the assembler would otherwise notice the
added component. I would even dare to say that the attack on the supply chain
you're describing can only be done by the device assembler itself.

~~~
thinkmassive
The NSA is laughing [https://arstechnica.com/tech-policy/2014/05/photos-of-an-
nsa...](https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-
factory-show-cisco-router-getting-implant/)

------
asymmetric
Seems like Ledger finally published a security advisory[0].

It also seems like they finally accepted OP's bug report as part of their
bounty program.

[0]: [https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-
secu...](https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-
fixes/)

------
limpkin
Disclosure: I'm the creator of Mooltipass.

When creating the Mooltipass offline password keeper we actually spent a
considerable amount of time thinking about solutions for the particular
problem explained on this website.

We therefore opted for the following techniques:

\- only allow signed firmware updates, signed using an encryption key unique
to each device

\- given that firmware flashing using external programmers requires complete
flash/eeprom erase, we implemented a challenge/response protocol to check for
tampering during shipping.

Obviously things are way easier when you don't allow custom firmwares to be
flashed on a device. But as a general rule I wouldn't trust a device that
would allow other programs to run on it (eg phones, computers...)

------
1upon0
This needs much more visibility than it presently has. Device attestation is a
difficult topic, and the writeup shows exactly why.

~~~
danr4
Agree. What's mostly worrying me is that Ledger's high ranking officials seem
to lack basic communication skills for a company selling such critical
devices.

You can see that in the author's section of his dealing with Ledger, and if
you go to /r/ledgerwallet subrredit you'll be able to see their interaction
rubs off as quite a bit condescending to downright insulting[0] considering
people have lost money over some issues, shrugging it off as "it's your
fault".

[0]
[https://www.reddit.com/r/ledgerwallet/comments/7tvyar/psa_do...](https://www.reddit.com/r/ledgerwallet/comments/7tvyar/psa_do_not_use_the_official_ledger_ethereum_app/dtfqt7j/)

------
limpkin
Wait... so the ledger allows any firmware to be uploaded without signature
checking? damn :(

~~~
ghthor
Seems insane right? Their entire userbase only exists because of the power
that PKCrypto gives us to build lasting lines of trust and they don't sign
firmware images....

------
p0nce
Ledger's synchronized post[0] is a nice read.

[0] [https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-
secu...](https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-
fixes/)

------
nicpottier
I have both a Ledger and Trezor and would recommend the latter even before
this vulnerability. Their Ether support is meh, but for BTC it just feels more
solid and well thought out. That they are open source (hardware and software)
and have been very responsive to attacks found also helps on the trust front.

Haven't played with the newer Model-T with a touchscreen, I'm talking about
the original Trezor which I believe they have no plans to EOL.

~~~
lawn
Trezor's design does have problems of its own:

[https://medium.com/@Zero404Cool/trezor-security-glitches-
rev...](https://medium.com/@Zero404Cool/trezor-security-glitches-reveal-your-
private-keys-761eeab03ff8)

Which to my untrained eye looks more severe.

~~~
nicpottier
That was addressed in a firmware update. All systems will have
vulnerabilities, the important bit is how the companies react. Trezor has been
pretty great IMO in that respect and that all their stuff is open gives me a
bit more confidence that it has been well attacked and patched.

[https://blog.trezor.io/trezor-firmware-security-
update-1-5-2...](https://blog.trezor.io/trezor-firmware-security-
update-1-5-2-5ef1b6f13fed)

------
AlexCoventry
I picked up a Ledger in a raffle at a meetup a few months ago, and it's just
been sitting around ever since because I was concerned about this kind of
risk. It's a bit of a shame... Can't ethically sell it for the same reason.
Fortunately, I was recently able to use it to introduce a curious friend of
mine to Ethereum, using small amounts, so there's been at least some benefit.

~~~
StavrosK
Keep in mind that, even with these vulnerabilities, the Ledger is still the
safest you can get for cryptocurrency storage.

~~~
yarrel
Trezor is better.

~~~
StavrosK
How so? Trezor had a vulnerability where you could extract the private keys by
measuring power draw.

------
lisper
I build and sell a hardware security dongle that runs 100% open-source
software and generates its keys using an on-board HWRNG.

[https://sc4.us/hsm/](https://sc4.us/hsm/)

I'm actively seeking help in porting a wallet app to the hardware. I am
willing to pay to get this done.

------
gruez
>Physical access before setup of the seed

I can't watch the video (says unsupported mime type on my browser), but I
heard the attack goes something like this: intercept the wallet, set up the
wallet and copy the seed, repackage it, hope the victim uses the wallet as-is
(with the seed you copied). Can't this be mitigated by resetting the device
when you first get it?

>2 variants of "firmware reflash"

I thought firmware updates are signed?

edit: disregard the second point. further down it mentions that only SE
firmware is signed

>Evil Maid attack

Is it even possible to mitigate this? At the very least you can steal the
original, replace it with a replica that looks the same, BUT all it does is
send back the password to you (via bluetooth, wifi, gsm, whatever). You can
even hook up the stolen wallet on the other end so it correctly respond
whether the password is correct/wrong and immediately drain the wallet once
the correct password is transmitted.

~~~
StavrosK
> Can't this be mitigated by resetting the device when you first get it?

No, he demonstrates a device going through setup and "generating" a
predetermined seed. It's not the easier "your wallet has already been set up
for you" attack.

~~~
dbrgn
To be precise, he overwrites the entropy source with zeroes, so that all words
(except the last one) of the seed are "abandon". With a non-zero entropy
source, you could generate random looking but deterministic seeds.

------
abhishekjha
I can't say I understand a lot of it. Where can I read more on hardware
exploits and how people figure them out?

------
kirankn
Very logical explanation of the exploit. Thanks.

