“This security investigation presents a way to bypass the APPROTECT on a protected nRF52840, in order to reactivate the Serial Wire Debug Interface (SWD), offering full debug capabilities on the target (R/W access to Flash/RAM/Registers, Code Exec and reprogramming). All the nRF52 versions are impacted.
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.”
Not great, not terrible. You do need physical access to the device and to know what you're doing, if I had a device based on nRF52840 as a user, I wouldn't worry so much. More worrying is maybe for producers of devices, afraid their IP might get stolen. But, honestly, if I put an embedded device out there, I expect a sufficiently determined attacker would be able to read it anyways.
What emergency plan? 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.
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.
What's Nordic going to even agree to? This is a firmware power glitch exploit. It's not like they can patch it in the field.
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).
Did I miss something: "Nordic PSIRT proposes to purchase the full report for a rock-bottom price."
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."
I guess I read that as "Nordic PSIRT [proposes for the researcher] to purchase the full report for a rock-bottom price."
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.
TLDR: Soldered onto some pins, identified power usage pattern during boot sequence characteristic of Flash read, wrote a search program to glitch the chip at just the right moment when it loads the protection flag.
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.
I have come to just accept the firmware will be read out in most microcontrollers unless they are specifically built to hold secrets. Maybe you can keep someone from copying your code for a little while, but eventually it will happen and you should have some other value that protects your business.
NRF, STM32, PSoC, ESP32, Xilinx. All of them have silicon or ROM errata that leak the firmware or the encryption around it.
> unless they are specifically built to hold secrets.
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
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.
It is not awfully hard to protect a chip against readout through glitching.
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.
You might check out the EFR32BG22 from Silicon Labs. It has alot of great security functions, including a dedicated security core with secure boot, secure debug, and unique ID.
I mean, you're not wrong... but the chip industry moves slowly, and by your own definition, most chips produced today would not 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.
The shitty IoT products can then also use a shitty battery/power supply because the advanced brownout protection the grandparent is talking about won't be spazzing out every 5 minutes that a LED causes voltage to droop. It's a win-win.
I worked in consumer, industrial and medical device testing industry for several years. When working with device manufacturers in the consumer space, for most of them most of the time cost of the device is the primary and overriding concern for the product.
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.
Brownout detect is way too expensive, aggressive sleep mode: 200nA, brownout detect 54uA.
I just accept everything can be hacked, works both ways. Vendors won't tell you how the chip actually works, dump the firmware and if you are getting paid, photograph and xray the die.
Brownout detection is not a protection against glitching, in general. You need to actually be looking for and have specific fault injection attacks in mind to protect against; generic brownout detection is often bypassable.
Yeah but realistically this isn't a security chip. It's a BLE chip first. Readout protection is mostly added so that customers don't worry so much about trivial IP theft.
Kind of like obfuscators in software. It doesn't really make reverse engineering impossible, it just makes it non-trivial.
I always thought those movie scenes where the protagonist holds a device up to a keypaf and the door unlocks were pure fantasy. But with tight enough control over a phased array, and detailed knowledge of the hardware.... anything might be possible.
Obviously JTAG access is not the only way get chip readout, but couldn't this entire channel be removed by a physical write-once fuse to ground of the JTAG lines?
> All it takes is having brown-out detection which
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)
I'm very excited about the new Solo keys coming out, but am apprehensive because they use an NXP LPC55S69 processor, which doesn't look like a secure element to me. Does anyone have experience with it?
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.
I have memories of this sort of thing going on back in the early 2000s with DirecTV access cards. One of the methods was to glitch the access card processor during bootup by pulsing and otherwise messing with the power. IIRC, it could be put into a test or debug mode if it was timed right.
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.
Almost all general purpose microcontrollers with "readout protection" are vulnerable to glitching attacks like this one.
...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.)
I can’t help but read this and think that this is a good thing... especially knowing Logitech uses these chips and the scummy things they have been known to do to sabotage the resale value of the hardware they make. [0]
Is there any meaningful downside to anyone but Nordic and Nordic’s customers?
If you’ve put keys or IP in that chip and thought that readout protection would help you, then you’d be hurting right now. There’s a high chance that you’re only doing so if you’re a customer, though, and if you thought that this would actually protect your stuff you’re fairly misguided.
With this, devices that use NRF52 chips are now open to investigators. I think we'll learn of more vulnerabilities of BLE devices whose shitty implementations are hidden in those SoCs. I'm more than excited about the next post about Logitech Pro G mouse.
Making things open is a good thing on society's security.
That is if they have been locked in the first place.
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)
Nordic provides some easy-to-use tools and examples for encrypting and signing firmware images when using a bootloader for in-field updates. I would expect that most products based on the nRF52 that support firmware updates encrypt the image.
Nordic's off-the-shelf firmware upgrade process has signed image verification only. The image itself sent over BLE is not encrypted. So anyone using that right off the bat is in for a nice surprise.
Partially because they call their firmware upgrade process "secure Device Firmware Update (DFU) functionality" (lifted from their documentation). Obviously, an engineer needs to go see the source to see what is actually happening under the hood.
I've been trying to come up with scenarios where someone relying on that security would suffer worse from this revelation than merely enabling hardware clone manufacturing.
(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.
Stolen devices, and devices that are legitimately in the possession of someone who is not the owner.
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...
Are these SoC devices often used to act as serial-over-BLE bridges? I have a barbecue controller from ThermoWorks that I have been trying to reverse engineer. Sniffing BLE has been pretty useless for this thing because it appears to be using BLE as a mechanism to do basic serial comms. I would like to understand more how these serial implementations work and to find some resources that I could use to capture the protocol.
> My low-cost voltage gliching is an homemade HW electronic system, dedicated to perform fault injections in a suitable manner. The total cost of this electronic board is less than 5$, which proves fault injection is a very low cost technique and can be achieved by limited hackers.
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.
I read it as the guy at LimitedResults sent an extortion demand and was rebuffed, then released the information under his company alias to and avoid the appearance of extortion by investigating authorities that Nordic would have had a duty to its stakeholders to file a complaint with.
56 comments
[ 4.1 ms ] story [ 118 ms ] threadDue 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.
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.
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.
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
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.
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)
(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...
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-...
Can you elaborate more on how this would work?