Security claims are easiest to make before an expert has tried to break them. Raspberry Pi chose a more revealing path for its RP2350 microcontroller: publish the design documentation, offer a hacking challenge, and reward researchers who found practical weaknesses.
The company reported the results on January 14, 2025. Researchers used voltage glitches, electromagnetic fault injection, and laser fault injection to interfere with security-sensitive operations. The findings became public errata, mitigations, and input for future revisions of the chip.
An erratum is a documented defect or unexpected behavior in a hardware product. Publishing one does not repair chips already manufactured, but it gives designers a way to assess the risk and apply available workarounds.
What was the challenge testing?
RP2350 includes security features intended to protect firmware and secrets in a finished device. Secure boot verifies that firmware has been approved before it runs. One-time-programmable memory, usually shortened to OTP, stores permanent configuration, security policies, and cryptographic material.
The challenge asked researchers to get past those protections under defined conditions. This was not a remote internet attack against an ordinary Pico 2. The successful entries required physical access, specialized equipment, careful timing, and extensive knowledge of the silicon and boot process.
That distinction affects the threat model. A threat model identifies the assets being protected, likely attackers, available access, and acceptable risk. A hobby sensor in a locked room faces a different threat from a payment terminal or commercial product an attacker can buy and dismantle.
What is fault injection?
A processor assumes that each instruction executes correctly. Fault injection deliberately disturbs the chip at a precise moment so an instruction, data value, or control decision behaves incorrectly.
Voltage glitching briefly pulls the supply away from its normal level. The disturbance may cause digital logic to misread or skip an operation. Electromagnetic fault injection, or EMFI, directs a short electromagnetic pulse at part of the chip. Laser fault injection exposes the silicon die and uses a focused light pulse to disturb a selected region.
These attacks are difficult because the pulse must arrive during a small window. The researcher may repeat a test thousands of times while adjusting timing, position, voltage, or pulse energy. Successful laboratory equipment can range from accessible security tools to very expensive custom systems.
RP2350 contains glitch detectors that are meant to halt the chip when suspicious supply behavior is detected. The challenge showed that detection reduced the attacker's options without making every kind of fault impossible.
What weaknesses did the researchers find?
One entry targeted reboot logic. The code receiving a reboot request had been hardened, but a later function assumed its parameters had already been sanitized. Sanitization means checking and restricting input before it is trusted. A carefully timed fault could skip one of two instructions and cause a reboot into a hazardous boot mode.
Raspberry Pi assigned that issue erratum E20. The company documented a mitigation using an OTP flag that disables the affected watchdog-scratch reboot path when an application does not need it. A watchdog is a timer that resets a system if software stops responding. Scratch registers are small retained values that can communicate information across a reboot.
Another researcher attacked the secure-boot signature check with a laser. A digital signature lets a device verify that firmware came from an authorized source and was not modified. The injected fault caused the hash to be calculated over attacker-controlled data. A hash is a compact mathematical fingerprint of data. If a valid signed image was hashed while different code later ran, the check could be bypassed.
This issue became erratum E24. Raspberry Pi said no mitigation was available at the time and that a future silicon revision would likely address it.
A separate team used a double fault to interfere with OTP permission locking before the USB bootloader started. The attack could leave an OTP page accessible even though configuration was supposed to prevent reading or writing. A mitigation disabled the relevant USB bootloader interfaces, but that also removed firmware-update convenience over USB.
That tradeoff is common in security. A recovery interface is valuable to the owner and potentially useful to an attacker. Disabling it can reduce attack surface while making maintenance harder.
Did the challenge mean RP2350 was insecure?
Security is not a single yes-or-no property. The results showed that a determined attacker with physical possession and specialized tools could bypass some protections. They did not show a simple software-only exploit that anyone could launch remotely.
For many maker projects, the physical attack cost will be much greater than the value of the protected data. For a commercial product containing valuable keys or licensed firmware, laboratory attacks may be within scope. The designer has to make that decision rather than treating the word secure as a guarantee.
Risk also depends on quantity. An expensive attack can become worthwhile if extracting one key compromises thousands of devices. Each unit should use unique credentials where possible, and a backend should be able to revoke or rotate compromised credentials.
Defense in depth helps. This means using several independent controls so one failure does not expose everything. Secure boot, encrypted storage, limited debug access, per-device keys, signed updates, and server-side authorization address different parts of the problem.
Why publish the failures?
Public disclosure gives product designers information they need to protect real systems. It also lets independent researchers review the company's analysis instead of relying on an assurance that a problem was handled privately.
Raspberry Pi paid the full $20,000 prize to each of the successful teams because the submissions taught different lessons. The company said the work changed its estimate of glitch-detector effectiveness, the practicality of multiple faults, and the cost of laser attacks.
Transparency does create responsibilities. Detailed results can help attackers as well as defenders. Vendors generally coordinate disclosure, publish mitigations, and give affected developers time to respond. Hiding a known weakness does not stop researchers or criminals from discovering it independently.
What should RP2350 designers do?
Start with the current data sheet and errata for the exact chip revision. Silicon stepping identifies a particular manufacturing revision. Two RP2350 devices with the same family name may not have identical security behavior if they use different steppings.
Apply every relevant OTP mitigation before production, but test on sacrificial devices first. OTP settings are intentionally difficult or impossible to reverse. A mistaken security configuration can lock out programming, recovery, or manufacturing tests.
Decide whether USB boot recovery is required in the finished product. If it remains enabled, protect the device at other layers and understand what the interface exposes. If it is disabled, create a reliable signed update and recovery plan before units leave the factory.
Do not store one fleet-wide secret if unique device keys are practical. Limit what a stolen key can authorize. Monitor backend behavior so abnormal devices can be blocked.
Finally, match protection to the product. A classroom robot does not need the same physical defenses as an access-control token. Security features add value when they address a realistic threat and are configured correctly.
The RP2350 challenge is important because it turns marketing claims into testable engineering. Researchers found real faults, Raspberry Pi documented them, and designers gained clearer information. The chip did not become perfect. The security process becomes more credible because the failures are visible.
I find this the most reassuring kind of security news: the weaknesses were found, written up, and given workarounds, so you can decide with real information how much physical-attack risk your project needs to handle.
Sources and image credits
- Raspberry Pi challenge results: Security through transparency
- RP2350 product documentation and errata
- Official challenge-results image from Raspberry Pi's news article, credited to Raspberry Pi Ltd.
- Square and vertical crops are edited from the same source image.
