Raspberry Pi hands out prizes to all in the RP2350 Hacking Challenge Raspberry Pi has given out prizes for extracting a secret value from the one-time-programmable (OTP) memory of the Raspberry Pi RP2350 microcontroller – awarding a pile of cash to all four entrants. The RP2350 went on sale to the public on August 8, 2024, a substantial improvement over its predecessor, the RP2040. One notable …
Does that extend to explaining how they fucked up, made what in retrospect were schoolboy errors, which weren't identified by themselves or those contracted to test and verify the design?
Everyone makes mistakes so I don't entirely blame the implementers but more the reviewers. But you have to wonder why those implementing the design appear to have not known that data consistency does not prove data integrity and single points of failure are a bad thing.
Laser and EMF injected glitches nay be hard to detect, but Aedan Cullen did their glitching using much simpler and traditional means.
They can present the outcome as some kind of success but it's also another failure added to the list.
For a company that's on its second chunk of homespun silicon, I reckon they're doing OK and, unlike a lot of chip makers they're owning their cockups in public.
They're damned either way though, if they offer stuff up for this sort of contest in an attempt to discover and fix issues they get hammered, if they don't discover flaws they get hammered.
although they managed to interfere with the chip's operation, they weren't able to do so in a way that exposed anything useful.
My reading of things is they proved the supposed security of the chip can be rendered ineffective, with some ways far easier than others.
Is that not correct?
Neither description of the results is entirely correct. The attacks were successful, and they did reveal things that are useful to an attacker. If, for example, someone built a system out of these but stored an encryption key in them so the communication couldn't be spoofed, these attacks would be sufficient to retrieve the key. That makes "they weren't able to do so in a way that exposed anything useful" wrong. Depending on what you were doing, though, that doesn't make all the security features ineffective. Injecting new code is not easy compared to retrieving that data, meaning that not every desired exploit is equally feasible with these methods.
Nor is this something unique to this chip. While there are some chips that are produced with the intent that it be even more difficult to break into them, a lot of embedded parts with similar security methods wouldn't stand up to people with lasers either. They're just not offering any money to the people who can use them. There is a limited number of devices which need to remain impenetrable when you have access to the hardware, expensive tools, and the willingness to destroy it. Many of the devices that would benefit from that level of security don't get it anyway. Therefore, although it is fair to call this a security failure on Raspberry Pi's fault, it is not a failure that should cause much concern for most users, including industrial users, especially as they're going to change the design to make the methods stop working*.
* The primary method that is of concern is the one that messes with the power supply. Not that this would be particularly easy to abuse either, but it is simpler than lasers or ion beams and it's the one they have the most likelihood of fixing in the design.
> single points of failure are a bad thing
I am sure the designers are well aware that single points of failure are bad. But when you are building a microcontroller for devices the size of a bus ticket (or smaller - https://www.seeedstudio.com/Seeed-XIAO-RP2350-p-5944.html), the opportunities for full hardware redundancy are sort of limited.
> how they fucked up, made what in retrospect were schoolboy errors
This is absolutely not what happened. The previous microcontroller, the RP2040 didn't have security flaws - it simply didn't have any features to protect software from being extracted or prevent memory from being read, or malicious code from being inserted and executed. Being aimed at hobbyists and tinkerers, the RP2040 has good support for debugging, allowing access to these things. With the RP2350 they added features to prevent this sort of access. This will appeal to commercial customers who don't want to share their IP or code, or have data extracted from the chip, or even to have people create a better version of their software or device.
If you read Upton's article - https://www.raspberrypi.com/news/security-through-transparency-rp2350-hacking-challenge-results-are-in/ - you'll see it was not schoolboy errors. Things like the order of instructions generated by the compiler come into play for some of the hacks. And if you read the hack write-up, you can see the extent they went to to extract this data. https://media.ccc.de/v/38c3-hacking-the-rp2350 Aedan says "Ultimately, the significant amount of luck (or lack thereof) involved is a reminder of the need to meticulously understand and validate complex systems."
If you can do better, please have a go.
Which is fine until the trousers are in the wash, the ones with the extra big pockets and hoops to hold the EDC
For the those of an age, remember The Goodies making movies, with Graeme's full-size cine film camera on a tripod? It was pocket-sized, but - you did have to have the right sort of pockets!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
