The RP2350 is actually a pretty secure chip, all things considered. It has secure boot, ARMv8’s TrustZone to split secure and non-secure execution, and you can permanently disable debug — the Pi Foundation even included glitch detection, meaning the traditional ‘zap the chip until it obeys’ technique is blocked. That’s why the [Ledger Donjon] security team went full Bond Villain and strapped everyone’s favourite fruit-flavoured microcontroller to a table with a slowly-approaching laser beam.
Okay — movie clichés aside, the laser was in fact very carefully focused on target before they turned it on. That target was the register that enables the 2350’s debug features. Said register was located by decapsulating the chip and examining the die with photon-emission electron microscopy; the actual attack was carried out on a chip that had been decapped on the back side, with IR shining through the silicon wafer. There was probably more than a little trial-and-error to figure out exactly where on the die adjacent to the register to zap with the laser to flip those bits. But flip they did, restoring the debugger’s access to the secure execution zone. Then, after resetting the chip, [Ledger]’s team read the 128-bit secret the Pi Foundation hid in memory as part of the 2350 hacking challenge.
It’s long been accepted that once the black hats — or white hats, for that matter — have their hands on your hardware, they’re going to find a way in. The effort it takes to break into a simple microcontroller here is actually kind of impressive. We’ve talked about laser fault injection before; ironically, we’ve also featured Pi Pico-powered glitching attacks — the kind that this chip’s glitch detection thwarts.
Nice i love jt
Interestingly even this does not seem like an unavoidable exploit, but rather something that can be taken into account in the next RPxxxx chip. The DEBUGEN could use an encoding where neighboring bits need to be set to “01” to enable debug, instead of just flipping all to “1”. That would make it much harder to override with a laser.
In software, setting more debug-blocking registers like DBGFORCE and BUSCTRL increases the number of bits that have to be flipped before debugger access succeeds.
Clearly the answer is mirrors
Naaah, it’s booze. Or a wrench. Perhaps a jolly one.
Close enough. Many chip makers put metal shields over those bits. Maybe RP does as well hence firing the laser from underneath.
The laser has to play “the game of life” on the memory bits to change the state :-D
It would be interseting to know if this is considered to Cyber Resilience Act EU compliant. As these new rules are coming into force and the exact requirements for compliance are still being worked out.
I believe CRA to be steps in the right direction, but it will still take a decade (if ever) for hardware attacks to be in scope. It is not the low-hanging fruit, and not the place for companies to start. I just hope it won’t be checklist security, and companies will do more than what is expected of them.
Holy Moly
Security should be considered defeated if attacker has a psychical access to your device. Just like with copying music or videos. In the end as long as there is an anal gap people will use it.
I’m sorry, a what?
He said what he said.
Getting my anal gap removed ASAP, I don’t want anyone having psychical access!
Got my anal gap removed immediately after reading this
If someone has physical access to literally put a laser beam onto a microscopic depotted register of a microchip on your device then you’re already in deep water
You got bigger problems than digital security at that point
Once you need physical hacks security is already perfect
While laser fault injection is quite a complicated and expensive attack, sometimes it enables you to find the scalable issue in a device. For example, you need access to the code to reverse engineer it and find scalable issues. Or when a device is cryptographically protected, and the key is reused, this then can compromise any device in the field.
If this is a threat, that depends on the product and the threat model. The devices you bought, are not necessarily yours to do with what you want. Be it a console where you can only run the companies games, or a bank card which requires a pin only known to the bank and the owner, or a printer which can only print from genuine cartridges. Each spends quite a lot of time on hardware attacks.
“The devices you bought, are not necessarily yours to do with what you want.”
I disagree with this sentence. Corporations can claim whatever they want, but I’m under no obligation to obey the whims of whichever corporation arbitrarily and unilaterally decides their rights trump mine.
the thing is there are problem domains where it is essential to put trade secrets into a delivered product. in that case, the single purchaser who goes through this process doesn’t just ‘unlock’ their single device, they expose a trade secret that can redefine your whole market. in that case, the security is not perfect.
there are many different kinds of requirements and they can’t all be reasonably satisfied.
In the product engineering field, there’s joke that these 2 features are added always at the end of product development schedule – power management and security. And because these features have system-wide implications (hw, sw and full product behavior), and of coarse it’s too late, they’re always botched.
That’s the general case. I’m not saying the RPi’s case is the same, quite the opposite. The company was very open with their intentions, implementation and documentation. They were also open to community feedback in a responsible way, something that’s so rare in these artificial times.
One place I worked would do stuff like this with an ion beam
Pray tell, in what way exactly is it ironic that this publication has covered topics such as using a Pi to execute voltage/current/pulse based glitch attacks against less fortified devices? There is nothing ironic about using a hardened device to detect bugs on lesser hardware, as there are no consequences contrary to the expected, no incongruity between expectation and reality, nor has the device been thwarted by its own glitch protection measures. This does not fit the definition of irony by any reputable measure, nor is it even an interesting coincidence, it’s purely an expected feature of such a design. /$0.02
Don’t let the CRA people in EU see this…
But what for? You tend to do bank transactions on a thinker board?
For those who would use this chip on a commercial product, maybe ?
They use rp modules in commercial and professionnal, why not an rp2035 ?