NRF52 Firmware Readout and Reverse-Engineering Now Possible
limitedresults.com
limitedresults.com
Almost all general purpose microcontrollers with "readout protection" are vulnerable to glitching attacks like this one. It may be a stretch to claim that most embedded engineers understand this, but successful attacks like this one are published at least a few times a year, and eventually one of them targets a part that you've used before.
All it does is force you to think about your threat model. You shouldn't keep sensitive or long-term secrets on a microcontroller and expect them to remain safe. Transient things like BLE session keys? Sure, whatever.
It's why you don't see (responsible) people designing HSMs using parts like these, and why extreme skepticism is warranted when people try to build things like cryptocurrency hardware wallets out of Arduino-caliber parts.
There are special classes of parts with more robust security features that you should consider using if you need anything resembling an HSM. Even those parts get broken from time to time, and those breaks are rarely fixable without new hardware.
All it takes is having brown-out detection which is always on and forces the chip into reset immediately (ie. No 4 cycle interrupt delay). Rate of change of voltage detection might be easier to implement without a precision voltage reference.
Another approach is to put current measurement on the pins. Glitching requires changing the voltage on a pin very quickly, and since the die has quite a lot of capacitance, the current flow is large and easy to measure.
Pretty much, there are lots of solutions to this problem, and any chip designed after 2010 that doesn't implement these shouldn't be considered well designed.
Also, once you protect against power glitching, they'll move on to clock glitching. It's endless.
Historically, this is not something that chip companies or their customers have cared about. Again, unless you're designing an HSM, hardware security is a checkbox sales item that is adequately satisfied by a probably-not-actually-secure firmware readout bit. The sales team is happy with this. The buyers on the other end designing shitty IoT products with a 2 year lifespan can now put a "secure" sticker on the box.
Cost mattered for industrial too, but it was balanced by performance and other considerations. For consumer, it's just cost. Anything that pushed the bill of materials up = bad, not at all win-win in their mind. "Grandpa buys bad electronic devices all the time and will keep doing so, why throw our money away for no reason?" would be a summery of their argument/thought process.
Medical devices are a whole different beast and money was far less of a consideration, or rather, they are far less worried about the cost because it's far easier to recoup the cost of the device.
Kind of like obfuscators in software. It doesn't really make reverse engineering impossible, it just makes it non-trivial.
The moment you say "All it takes" or "Just" or "Simply", you're probably on shaky ground.
The downside of your solutions is "sleep current" which translates directly to "battery life" which translates to "product is nonviable".
Not everything has an HSM threat model.
Part of the reason certain things have a cloud component IS the fact that the client device has to be assumed adversarial under all conditions. (see: practically all modern multiplayer videogames)
Regardless, I think the security benefit will be substantial, since the ease of use will outweigh the risk of someone physically getting the device and extracting the keys by a lot.
On one hand I'd expect most systems that take security seriously would defend against this, but on the other hand the pitiful state of mass market and consumer hardware would indicate that very low expectations would be appropriate.
...and even if they aren't, you can find companies that will read out protected MCUs for a few k$. Keywords are "MCU break". (Whose Google results are currently flooded with other things.)
Is there any meaningful downside to anyone but Nordic and Nordic’s customers?
[0]https://www.reddit.com/r/homeautomation/comments/esiv9b/psa_...
I was considering buying a new high-end mouse but now I will be avoiding Logitech products at all costs.
(Note that most of those cases are very far from where you would typically find an NRF52)
Decryption keys for "broadcast" style DRM schemes? Kind of bad, but usually those also have implementations on far more open hardware, it wouldn't be the weakest link.
A Yubikey-like second factor configured only for presence? When you can take a soldering iron to the device you might just as well keep the one you already have. It would only make a difference for elaborate attacks involving more than one copy of the destroyed original (e.g. sneaking a clone back to the original owner). I'd argue that it retains 98% of the security upside compared to not using a second factor and would still come ahead of many weaker second factors.
A Yubikey-like second factor configured to require on-device decryption of its keys? (e.g. built in PIN pad) Bad because the readout would enable unthrottled attemps, but still only terrible if the resulting key isn't throttled otherwise (e.g. bad for decrypting some offline storage).
An anti-tampering signature for content production, e.g. camera hardware confirming that a pictue is based on actual photons hitting a CCD? Bad, definitely.
An encapsulated root CA in its CEO's pocket? Someone will get fired, but it won't be the right person.
I'm sure that this list could be longer, but so far I don't see any overlap with the usual application domain of NRF52.
A wifi-enabled doorbell, where you don't want people to be able to snatch it and extract your wifi credentials.
A product with an iphone-style activation lock (which deters theft by preventing resale of stolen goods) where you don't want the activation lock bypassed.
A smart energy meter, which needs to accurately track energy usage...
Making things open is a good thing on society's security.
Also with a lot of devices being firmware upgradable, there is little point in enabling read-out protection if you can just download the firmware off the internet. (Unless you want to go through all the hassle of encrypting the firmware image, but most devices won't be doing anything so special to make this worthwhile)
(Don’t conflate security with confidentiality)
NRF, STM32, PSoC, ESP32, Xilinx. All of them have silicon or ROM errata that leak the firmware or the encryption around it.
Even that is not warranted, there are companies who lift contents of hardened microcontrollers for things like smartcards, credit cards, id cards, pos terminals etc no questions asked
Short and sweet, kind of.
All you can really do is make sure anything based around security is one to one and that the attack doesn't scale. You can break you own device, but all that gets you is access to your own device and data.
What you don't want is for data to come off the chip that allows somebody to break other copies of your firmware. That would be BAD(tm). However, that's a failure to consider threat model rather than a firmware fault by Nordic.
Any. Depending on what the stakes are, some examples:
- apologize
- refund
- contact the appropriate secret service and ask them to exfiltrate devices etc etc
> This is a device in the hands of a hostile adversary. You pretty much have to assume that given enough determination an adversary WILL crack the device and read your code
You and I know this. I feel lucky to have had bosses that have a good idea about this, not everyone seems to be so lucky.
If all they said was: "Nordic Semiconductor and LimitedResults did not agree on a responsible disclosure." That's fine. So be it.
However, when I see: "Nordic PSIRT proposes to purchase the full report for a rock-bottom price." They lost my sympathy right there. I have no idea what they told Nordic, and Nordic really doesn't have a good way to defend against that accusation without exposing emails that they likely sent back and forth with confidentiality in place.
That kind of commentary is bad faith even if Nordic may also be acting in bad faith (and I have no real way to verify that).
I read that as the researcher trying to get money out of Nordic--especially with a comment like "rock-bottom price". Did I get that wrong?
That "rock-bottom price" is an unprofessional sideswipe that Nordic probably can't counter without breaking confidentiality agreements.
And, what's a "rock-bottom" price? A hundred dollars? A thousand dollars? Ten thousand dollars?
What price should Nordic pay for a report on a power glitch exploit--something that pretty much affects every microcontroller on the planet?
And what did the researchers disclose to Nordic in order to agree on a price? Nordic certainly isn't going to pay much if you just say "I found an exploit" and don't tell them much else.
That "rock-bottom price" comment adds a whole bunch of character questions to my assessment of the author as "security researcher" that simply wouldn't be in scope if they had left it at "Nordic Semiconductor and LimitedResults did not agree on a responsible disclosure. That’s life."
Given what I've seen with chip companies that aren't used to dealing with third party security researchers, that seems pretty on point. Trying to sell a support contract to someone reporting a security vulnerability.
Due to its intrinsic characteristics, the vulnerability cannot be patched without Silicon redesign, leading to a countless number of vulnerable devices on the field forever.”
Ooof.
Has he released the schematic for this? I'm thinking it's just a small npn pulling the power pin to ground, and controlled by a microcontroller.
Edit: He talks about his glitcher here: https://limitedresults.com/2019/05/pwn-mbedtls-on-esp32-dfa-...
Apparently able to make exploit persistent, and demo coming up in future post on a real consumer product (Logitech Mouse). Couldn't reach agreement with Nordic on a responsible disclosure mechanism.
Well, that's just how the nRF's protection works: you can always disable it, erasing the flash.
They glitched the chip to access debug without disabling protection → can dump the firmware now → obviously possible to disable it and then reflash the recovered firmware.
Can you elaborate more on how this would work?