This isn't actually as bad as it sounds.<p>Almost all general purpose microcontrollers with "readout protection" are vulnerable to glitching attacks like this one. It may be a stretch to claim that <i>most</i> 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.<p>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.<p>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.<p>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.
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]<p>Is there any meaningful downside to anyone but Nordic and Nordic’s customers?<p>[0]<a href="https://www.reddit.com/r/homeautomation/comments/esiv9b/psa_to_harmony_hub_users_avoid_unnecessary/" rel="nofollow">https://www.reddit.com/r/homeautomation/comments/esiv9b/psa_...</a>
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.<p>(Note that most of those cases are very far from where you would typically find an NRF52)<p>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.<p>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.<p>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).<p>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.<p>An encapsulated root CA in its CEO's pocket? Someone will get fired, but it won't be the right person.<p>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.
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.<p>Making things open is a good thing on society's security.
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.<p>NRF, STM32, PSoC, ESP32, Xilinx. All of them have silicon or ROM errata that leak the firmware or the encryption around it.
“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.<p>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.”<p>Ooof.
> 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.<p>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.<p>Edit: He talks about his glitcher here: <a href="https://limitedresults.com/2019/05/pwn-mbedtls-on-esp32-dfa-warm-up/" rel="nofollow">https://limitedresults.com/2019/05/pwn-mbedtls-on-esp32-dfa-...</a>
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.<p>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.
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.
The following Nordic chips seem to have gone through some security evaluation <a href="https://www.psacertified.org/certified-products/?_company=nordic-semiconductor" rel="nofollow">https://www.psacertified.org/certified-products/?_company=no...</a>