Profile picture
Matthew Green @matthew_d_green
, 22 tweets, 4 min read Read on Twitter
Good morning Twitter. This post about Ledger cryptocurrency hardware wallet vulnerabilities is extremely cool, and not just for cryptocurrency people. Let me talk a bit about it. 1/…
There is a common architectural theme in certain embedded devices: they incorporate a secure processor (or processor component) to protect critical secrets or ensure correct behavior. I’ve seen this in all kinds of devices, not just cryptocurrency wallets. 2/
(For an obvious example, every recent iPhone has a Secure Enclave processor that stores your fingerprint data and cryptographic keys. But these devices are used elsewhere as well.…) 3/
Secure co-processors typically incorporate some kind of tamper-resistant physical casing as well as a limited interface to protect secret data. They often have some crypto functions on board, and can “attest” (prove to remote parties) that they’re running the right software. 4/
None of these processors can withstand all attacks. But let’s ignore that part and assume they can, for the moment. This still leaves a huge gaping hole in many devices. 5/
You see, the typical “secure element” isn’t powerful enough to drive your entire device (including the pretty GUI and peripherals and network communication if that’s available). So most devices have a second “insecure” processor to do all that stuff. 6/
(A very few devices make exceptions to this. 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.) 7/
Anyway, the upshot of this design is that even if the secure processor works correctly, it’s entirely dependent on the (relatively) insecure general processor for nearly all functions, including driving a user interface. Basically it’s a hostage. 8/
In some cases this is ok. For example, a good SEP can use crypto to establish secure communications with a trusted outside device (like a remote server). If this is done right, even a compromised app processor can only block communications, not tamper with them. 9/
In others it’s super bad news. If the security of the device relies on the idea that the user can trust what they see on the display. But they can’t if the app processor controls that, and it becomes compromised. 10/
Solving this problem is incredibly hard. Systems like TPMs try to do it by giving the secure chip access to the same RAM as the app processor, which allows it to check which code the app processor is running. 11/
But most secure processors don’t have even this capability. They have no way of knowing whether the app processor is running good or compromised code. 12/
Which (finally!) brings us to the brave, ambitious, scary thing Ledger did. In Ledger wallets, the secure processor *asks* the app processor (nicely) to send it a copy of the firmware that it’s running. 13/
(When I mentioned this to my grad student Gabe, he got a look on his face like I had just handed him Durian candy. Then he started muttering “no, no, that can’t possibly work”) 14/
The reason to be concerned about this approach is because *if* the app processor is compromised, then why would you trust it to send over the actual (malicious) code it’s running? It could just lie and send the legit code. 15/
Ledger tries to square this circle, in a novel way. Their idea is that the device has a fixed amount of NVRAM storage. If you install compromised firmware on it, you’d need room to store that. But you’d also need to store the original firmware to satisfy the checks. 16/
If you make it hard for the attacker to find the room to do this, you win!

This time around, Ledger did not win. Saleem writes about why that is in his post, which I linked to 9,000 tweets up this thread. 17/
But, as Garth says to young Indiana Jones in “The Last Crusade”: You lost today, kid, but that doesn't mean you have to like it. 18/
And since Ledger can’t update the hardware on their devices presumably they’re going to have to try to harden their approach even further. I’m really interested to see whether they win this! 19/
Because if someone can make this approach work, it would have huge implications for a large class of devices beyond wallets. I’m deeply skeptical. But I’m always skeptical. Excited to see how it goes. 20/20 fin
And by the way, nothing in the post or thread above means you should freak out about these vulns, or that you should assume other wallets are better. Just be safe.
Also, if you don’t like massive 20-tweet rants, here’s the above Ledger thread in one page.…
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Matthew Green
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!