Looking at the images here, there is zero attempt at security here from the ledger team. They’re using an MCU (ST MCU with Cortex M4 core) that doesn’t have any meaningful security features (ie, no secure boot, no differentiation between trusted and user mode operation - features the newer Cortex M33 core supports and newer ST parts implement). So there’s no way to guarantee that the software running on this has not been tampered with.
There is no physical tamper detection either. No tamper pads to detect case openings, no seal that gets broken when it’s opened that prevents operation. As others have mentioned, the most basic precaution would be to glue the whole thing together, which they didn’t do either.
Trusting Ledger with securing anything secret would be a very bad idea.
> Looking at the images here, there is zero attempt at security here from the ledger team. They’re using an MCU (ST MCU with Cortex M4 core) that doesn’t have any meaningful security features (ie, no secure boot, no differentiation between trusted and user mode operation - features the newer Cortex M33 core supports and newer ST parts implement).
That MCU is explicitly not assumed to be critical in their security model [1]. It handles Bluetooth and USB communication, both of which are assumed to be insecure transport layers. Securing the MCU would not have helped in this particular incident, and I can't think of a scenario in which it would be critical.
Button input and screen output, which are critical, are handled by a secure element. Unfortunately, at some point even the most hardened secure element will have to output data to be displayed on a screen; that's what was attacked here. Electronic shoulder surfing, basically.
> They’re using an MCU (ST MCU with Cortex M4 core) that doesn’t have any meaningful security features (ie, no secure boot, no differentiation between trusted and user mode operation - features the newer Cortex M33 core supports and newer ST parts implement).
This doesn't help any bit against the hardware implant we're discussing here.
> So there’s no way to guarantee that the software running on this has not been tampered with.
While true, I don't think it matters too much, other than the possibility of turning the device into something like a rubberducky.
> There is no physical tamper detection either. No tamper pads to detect case openings, no seal that gets broken when it’s opened that prevents operation. As others have mentioned, the most basic precaution would be to glue the whole thing together, which they didn’t do either.
Now that is the real meat. Unfortunately, for any given attack it's possible to bypass it. Tamper pads, if you know where they are, you can drill through the housing and, depending what it is, keep the button pressed by a jig, or solder wires if it's a sense trace to bridge it. The housing itself can easily be fully replicated, it's just a matter of coughing up some money for custom molds.
The only way to make something relatively tamper proof is to use injection molding over the full housing with something like glitter as part of the plastic, that will distribute randomly - and most importantly: not replicable! - across the housing, and then take high quality photographs and store them on your website together with the serial number.
That way the customer can photograph the device they have, and compare the random glitter specks with those on the website.
Tamper proofing hardware is among the hardest things there are, especially if you are up against nation-state actors like North Korea (that has been known to engage in cryptocurrency theft in the past).
While secure boot and the other software features might not have defended against this attempt, it highlights the abject failure of the company to even make an attempt at security.
You bring up a good point about bypassing physical tamper detection, but those defenses increase the cost and complexity of the attack, making them harder to succeed undetected. As it is, this attack seemed quite trivial to implement.
> it highlights the abject failure of the company to even make an attempt at security.
Do you know anything about their security model to pass judgement like that? They actually have a quite thorough hardware security model, outlining which components are and aren't considered critical: https://www.ledger.com/ledger-nano-x-bluetooth-security-mode...
> As it is, this attack seemed quite trivial to implement.
Have you looked at the miniature LTE board implant? It's an extremely sophisticated attack against a very sophisticated target, in my view.
Isn’t it all moot if you’re buying from a reseller rather than the manufacturer? Because I’m thinking your photos to compare the glitter with will be provided by the middle man anyway
not really. nor does the glitter and the photo really help. problem is they will infiltrate vendor ,or maybe your ISP or he device u take picture with, replace photo.
u would need something that you do not have to check online which is physically given to you by a known person. who do you really know at the vendor? no one. there isnt this person.
that being said,.so it comes back to trusting someone if you are dealing with digital things, somewhere down the line. That trust can be attacked, so u need to ne aware of it and if anything dont put all your eggs in the same basket.
Say you have 10 million$. you would want to split it up in chunks the size of your acceptable loss * the chances of such loss occurring, so that whenever you lose something, its within accepted risk parameters :')
This is a great observation! I regularly end up with M33 devices I program as they make sense for reasons other than security. (E.g. an Atmosic one, and St ones like L5/U5/H5). I look at the secure flash functionality and think "This is annoying and I have no current or projected use for this."
I ponder "What applications would I want this security stuff for?" Crypto wallets are a great example... and the crypto wallets in the wild aren't using them, as you point out!
Which ones would you suggest? I actually consider Ledger one of the more competent vendors in this space. A lot of alternatives don't even perform all key operations in secure hardware, yet loudly proclaim themselves as superior.
Not practical when one makes any type of transaction regularly. For those who don't want to research or generally trust HW wallet manufacturers, they can easily make their own though by using an old offline device and sign the transactions there.
People should do better research before buying things, and - it should go without saying - especially when it's about security. Ledger has a whole list of issues, they became the most popular brand not because they're the most trustworthy but because of their marketing and focus on supporting a massive number of coins. You'd think though that security should be the number one priority for a hardware wallet brand, not convenience.
It's just amazing to me sometimes that people get so far with so little sense of professional responsibility. I have no particular expertise in hardware security and even I would have made put more effort in. And this company has been around since 2014! What excuse can there be?
Edit: For folks down voting me, please explain. I'm genuinely curious about your perspective.
I would start with filling the product with potting compound, which has been a standard process in tamper-proofing hardware for a long time. Keep in mind the whole value proposition of a hardware wallet is security.
Yes, it's safe to do with lithium ion batteries as long as you use the right potting compound (potting compound isn't just one thing). There are compound specifically designed for battery encapsulation that assist with thermal management and preventing ruptures. As the person you're replying to has already stated, using potting compound to fill in cavities and discourage tampering on electronics is a standard practice.
Depending on your design requirements you can also use different battery chemistries or cell constructions to minimize the need for mechanical venting.
As a professional in the space, this echoes my experiences. I’m far more productive in Rust than C, despite having many more years programming embedded software in C. Cargo and the crate ecosystem are a dream compared to the lack of any easy-to-use build tooling and the difficulty of integrating third party libraries in C.
Furthermore, the code I’ve produced in Rust is generally as fast (or faster) than the code I’ve written in C for the same task, and it’s easier and faster to write.
And I also maintain an open source HAL for an STM32 family! Previously those have just been in house HALs in C because there were no such community efforts.
Very cool! Which one? I have been using mostly G4 and H7 on my personal and work projects, but the HAL (`stm32-hal2` is the crate name) works for most of the one s in a certain time band; i.e. not any that were obsolte when I started it, and spotty or no support on some of the newer ones like U series and H5. And weaker / non-vetted support on MCU variants I haven't used, or haven't used a MCU/feature combo on.
I think in the future if I do an embedded rust project on a new MCU where there isn't an existing HAL, or one that is more work to repair than start over, I would just implement the subset needed for a project's reqs. Easier to keep track of scope that way. Currently the challenge is "X periph on Y variant of Z STM-32 family doesn't work under A condition" or "Doesn't work after this PAC update changed the syntax".
I’ve been developing https://github.com/stm32-rs/stm32h5xx-hal. It’s been a slow process adding functionality because I’ve focused on what we need from it, so it’s missing a lot of functionality. Making progress bit by bit though.
V cool! I think I got the RCC and basics working on that but I think my impl is missing and or broken for many periphs. Similar to H7 in a lot of ways though!
Nothing is really going to protect you from a direct lightning strike. Lightning strikes are on the order of millions of volts and thousands of amps. It will arc between circuits that are close enough and it will raise the ground voltage by thousands of volts too. You basically need a lighting rod buried deep into the earth to prevent it hitting your house directly and then you’re still probably going to deal with fried electronics (but your house will survive). Surge protectors are for faulty power supplies and much milder transient events on the grid and maybe a lightning strike a mile or so away.
So I'm still left with int0x29's original question: "Isn't this [an electricity spike that a UPS could protect against] what a surge protector is for?"
There is no physical tamper detection either. No tamper pads to detect case openings, no seal that gets broken when it’s opened that prevents operation. As others have mentioned, the most basic precaution would be to glue the whole thing together, which they didn’t do either.
Trusting Ledger with securing anything secret would be a very bad idea.