Raspberry Pi’s new microcontroller, the RP2350, has a small section of memory that is meant for storing secrets. It’s protected by anti-glitching and other countermeasures, and the Raspberries wanted to test it. So this summer, they gave them out, pre-programmed with a secret string, as part of the badge for DEFCON attendees. The results of the cracking efforts are in, and it’s fair to say that the hackers have won.
First place went to [Aedan Cullen], who also gave a great talk about how he did it at 38C3. One of the coolest features of the RP2350, from a hacker perspective, is that it has dual ARM and dual RISC-V cores onboard, and they can be swapped out by multiplexers. The security module has a critical register that has disable bits for both of these processors, but it turns out that the ARM disable bits have priority. When [Aedan] glitched the security module just right, it disabled the ARM cores but left the RISC-V cores running in the secure context, with full debug(!), and the game was over. As of yet, there is no mitigation for this one, because it’s baked into the secure boot module’s silicon.
[Marius Muench] managed to pre-load malicious code into RAM and glitch a reboot-out-of-secure-mode on the USB module. This one is possibly fixable by checking other reboot flags. [Kévin Courdesses] has a sweet laser fault-injection rig that’s based on the 3D-printable OpenFlexure Delta Stage, which we’ve seen used for microscopy purposes, but here he’s bypassing the anti-glitching circuitry by exposing the die and hitting it hard with photons.
Finally, [Andrew Zonenberg] and a team from IOActive went at the RP2350 with a focused ion beam and just read the memory, or at least the pairwise-OR of neighboring bits. Pulling this attack off isn’t cheap, and it’s a more general property of all anti-fuse memory cells that they can be read out this way. Chalk this up as a mostly-win for the offense in this case.
If you want to read up on voltage glitching attacks yourself, and we promise we won’t judge, [Matthew Alt] has a great writeup on the topic. And ironically enough, one of his tools of choice is [Colin O’Flynn]’s RP2040-based Chip Shouter EMP glitcher, which he showed us how to make and use in this 2021 Remoticon talk.
Hopefully they now have enough of reasons to hurry up a new stepping. I do care about the secure storage but I care about fixing up that massive GPIO current leak infinite times more.
Amen! I have an audio reactive project that I have working on a Pico W and was excited at the prospect of a drop in upgrade in clock rate. Now my analog mic to digital conversion sticks at 0xFF when I upload a new Circuit Python sketch until I reset the chip. I’m more of a software nerd so I’m left wondering if I magic-smoked something, have a bad solder joint (given my skill, very possible but unlikely to be root cause), some other bug, or ????. I’m still researching circuit and software workarounds but it’s a bummer. Stuff like this is a killer if you’re a tinkerer and not a full on EE. Once that seed of doubt about a product is in your head, it’s always there making you wonder if it’s your problem or the product’s.
Maybe the delay in shipping product to distribution is the hacks. I have 5 boards ready to go to production as soon as parts are shipping in quantity.
I’ll never care about the secure storage, so doesn’t matter here. But it was neat that RPI awarded the $20K prize to all of the hacker teams.
Nothing that enables or facilitates DRM should be lauded, and it especially has no place in hardware aimed at open source and education like Raspberry Pi does. Shame on them for adding it to the hardware in the first place, and thank you to the hackers for publicly breaking it. Sadly this will give feedback to the designers to harden the DRM mechanisms next time.
All the RP designers energy should be towards a new stepping to fix the hardware GPIO problems that make the RP2350 unfit for just about everything. In order to make things really right, they need to refund everyone who’s bought one so far, and send out replacement chips with fixed silicon without the current leaks.
There are plenty of uses for secure storage other than DRM. Fixing the GPIO issue is much more important, but they may be able to fix both on the same stepping. More security vulnerabilities will most likely be found even after they fix this one though.
“Nothing that enables or facilitates DRM should be lauded”
Guess we’re getting rid of all of cryptography then, UT doesn’t like some things that can be done with it.
The problem is that the OTP section and Secure Boot apparently can be used to limit the ability to repurpose the silicon.
Security and hackability are often at odds, and I know where you’re coming from.
On the other hand, this is a $1 microcontroller produced in the millions. Losing too much sleep over its reusability is not really where the bodies are buried in this era of landfills worth of throw-away smartphones produced in the billions.
Indeed, it is actually very hacker friendly while actually being something you can use in the real world with some degree of confidence the secrets required to make your platform work properly and securely remain secret.
How on earth is that an argument? “There’s already tons of throw-away e-waste, so don’t worry about adding more vendor locked DRMed hardware to it?” In what way does the current existence of unusable locked e-waste excuse ANY addition to it?
Ah, if we got rid of everything that’s scarred us there would be little left.
“…to scar us left.” Is the part you forgot to type. Personally I don’t find suffering to be a thing we all must experience to be accepted as a human. Why not get rid of the bad stuff and just let everyone be happy? Jealousy doesn’t count.
Because that is an impossible scenario. Newer generations will never learn of the mistakes of the past, if nothing exists to teach them. Text books are just words on paper and can easily be ignored, but physical, real life Representations will force you to realize their existence and accept their problems as being real. We are not the final generations of humanity. Thus we need to perpetuate the existence of our past mistakes, lest they are doomed to happen again and again, hurting more rather than less.
i finally put my finger on what this attitude reminds me of….uefi paranoia. i heard that secureboot would be the end of the pc. i knew it was nuts a 13 years ago when people were freaking out about it, and now everyone knows… for most users, uefi just means it’s more convenient to install a new bootloader. most people benefit from the standardization of a modern interface, and each vendor has to decide independently how much they want to harm their relationship with their userbase. and in practice most vendors have realized “this pc can also run linux” is such a great value add that they haven’t even considered locking it down unless the customer specifically requests it.
maybe freak out about the rare thing that is so cool you want to hack it but so locked down that you can’t. but i wouldn’t freak out preemptively about the tool that might facilitate that. if people want to lock down their products, whether raspberry puts this feature in the rp2350 or not won’t make a difference. the fact of the matter is, most of the locked things in my life, i don’t want to peer behind the curtain anyways. like, even if i wanted to pirate movies, there are many much easier options than hacking the DRM in my android tv so i can record the output from a streaming service.
obvious example is the raspberry pi firmware, which i very much wish i could hack on. which is a great example of why i don’t freak out about this feature of the rp2350, when there is a very real problem from the same company which i’d much rather point at. even and especially when i am standing on principle, it is important to keep the real cases in mind, not to allow the principle to obscure its practical application.
I Have a bunch of secure keys, but will try my best to hide them from you.
That is the cat and mouse game and it will never be watertight. These devices need keys/secure storage (for valid reasons) but they are right there in your hand.
As far as I know, perfect security is near impossible, it is just means to slow an attacker down.
For a chip which hasn’t gone through formal evaluation, it’s quite a strong result. If this is truly the lowest skilled and effort attack possible, it may be elligable for PSA2 certification. Most of the attacks are wonderful and clever, but rarely used in formal evaluations. Laser are more common, bit FIB are rarely used in practice. I hope to see more of these challenges and those attacks 🙂
The discussion if Raspberry Pi should have the ability to protect the memory and lock the device down is interesting. There are many reasons for which you want to lock down the chip. Even if it is just to ensure the educational material remains intact. Using open devices for education has a high risk of someone replacing the firmware for something nefarious. A rubber ducky, or worse.
Locking down a system also reduces the risk of having IP stolen and reproduced in China, and enable secure updates, which is currently a requirement in the EU. As the chip is not formally evaluated, you shouldn’t use it for anything important, unless you want to go through the formal evaluation process yourself.
“Using Open Devices for education has a high risk of someone replacing the firmware with something nefarious!” LMAO 😂🤦 No! It doesn’t. There’s hundreds of thousands of Raspberry Pi’s, Arduino’s and Open Source 3d Printers in THOUSANDS of schools around the world. Regular schools and Art schools use the daily! Where’s all the reports of thousands of Pi’s or Arduino’s being found with NEFARIOUS FIRMWARE?!?!? There’s NONE! There’s the pi zero that was found on a campus, that turned out to be private property of a company the school hired to track students capacity in certain buildings. How does locking a device down, make it easier to find out if it hacked? Being I
Open Source, should make it far easier!
Hi Ed. Sorry to say, but that’s not how risk works. It doesn’t have to happen often, if it has a big effect. I value reputation highly, where a single successful attack can be rather damaging.
When teaching embedded, it is often required to have a way to restore the hardware to its original state for the next class. Alternatively, you can give every student their own hardware, but this isn’t always possible. Locking down the device can be a rather useful way to revert to original state, as there isn’t a state which can be changed permanently.
The ability to lock down a device is a useful feature and there is little reason to hate it. You don’t need to use it, but not having it will leave you wanting.
having taken embedded classes at a college level….. some of which were taught by a professor who used to work at the NSA…. we never worried about this. It’s a microprocessor. Wiping it’s memory is hardly difficult to do. It’s a standard part of the development cycle. Also you’re rarely uploading dangerous / critical code or systems to a chip in an educational format.
If you’re using a microcontroller as a development board, you very specifically do not want firmware signing to be turned on. And you’re letting students write whatever code they want and upload it. I don’t see how locking not this chip down in an educational context could possibly lead to any issues. Please provide a counterexample if you have one.
“ensure the educational material remains intact.” This doesn’t make sense for a microcontroller. What educational material is there on a microcontroller that you’re trying to keep secure in an educational context??
Afik the only reasons (they are valid) for this technology is protecting cryptographic secrets, and preventing cloning of firmware. Not really sure you’re needing those features outside of course of teaching students how to use them for comercial applications.
My apologies if I pretended to teaching programming at a university. To me, education is a lot bigger. In this context, I teach professionals in cryptography, and pentesting the basics of embedded security. My boards are realistic but custom devices, quite similar to a hardware CTF. These are not intended to be reprogrammable by the users. However, the users can change states, which would ruin the challenge for the next participant. (Solved = true)
Reprogramming an embedded chip is indeed part of the usual cycle. However, there isn’t an easy and safe way to reprogram a USB device if the content is not proven to be safe. Not having to reprogram the device is thus ideal.
Plenty of educational uses where you’d not want to be able to overwrite or harm the bootloader and core code – for instance those turtle type things for younger kids where you tell it go forward x, right y, etc, or navigate a maze with the limited external sensors – You want it to accept a new ‘program’ of the sort the kids are intended to make, but not have core programming that makes it behave like a turtle/scara arm etc borked.
The kids only need to be able to put in their program perhaps only into the RAM, on an SD etc. Then the locked down lower level software hardware layers turn it into the right action reliably – you’d want to lock that down or a kid like me and probably half the HAD readers would be playing way off script of the boring lessons and likely leave the device in a borked state for the next class etc..
Congrats, you have beaten yourself in the debate. RP2040 cannot be locked in any way and thus can always be reflashed. RP2350 can be locked and thus rendered unusable for the next student.
As for the remote updates, they can be safely provided without locking the device. You might not have noticed, but Linux, Mac and Windows were in fact receiving system updates over the internet for quite some time now.
The important difference is that without locked bootloader one can repurposed the system or change vendor shipping those. With locked one once the vendor goes out of the business, you’d have to desolder the RP2350 and replace it with another.
No small feat for your average hacker.
I’m not using the devices to teach programming, specifically. If you want to teach programming on a full or partially locked device, students can still use the NVM to temporarily store their content and execute the program, if you so allow. uPython is usually run from RAM, as an example.
Secure updates aren’t trivial to do correctly in an embedded device. The firmware is likely encrypted and signed. Only the update with the correct keys are to be installed. I like to learn more about how you propose to update a device securely without locking down the bootloader.
Seems like the simple answer is that there is a lot of commercial demand for Raspi devices and chips and Raspi is now answering to the commercial demand of IC safety. I know for a fact that many companies use raspberry devices in their products when they need an SBC because their one or two in-house programmers are familiar with them.
That is indeed the case. RPi started life as an Open Source development board, but like Arduino it has become an essential part of commercial products as it, especially together with Arduino, enables businesses to spend less time making custom PCBs and more time making new and improved products for their lineup, effectively giving them greater chances at commercial success.
Custom PCBs are cheap enough to produce, but not necessarily to design. Their designs can take a lot of company time and if the owners can’t do it themselves, then also lots of resources on one or more designers on their payroll, just to build custom microcontrollers and sensors. Not really worth it when there’s a cheap, public alternative that’s easy to modify to your exact product needs and then lock it down. Then these resources can be funneled towards making more products or product variations, rather than spending time and money on constantly reinventing the wheel.
That is of course a slight negative for tinkerers and enthusiasts, but the reality is that neither of those would ever have been a sustainable customer base to support both development and manufacturing of both new and existing boards, so at best it would never have been improved beyond the capabilities of the first card without drastically increasing prices if they had never catered to the commercial sector. So it’s more of a win than a loss. And most wins include some tough pills to swallow.
Good thing they figured that one out. I wouldn’t want my leds blinking at the wrong rate.
I guess the proverbial “shitting of the repo hot tub” is still in never mode for these people.
Amazon:
“Support C/C++, MicroPython, Arduino”
Which software technologies targeted for attacks?