Full Report
The RP2350 by Raspberry Pi is a MicroController Unit (MCU) chip that provides a root of trust for larger systems, with tools like secure boot. This article explains the chip's security design and how it was defeated in several ways. The RP2350 is a dual-core, dual-architecture MCU with on-chip SRAM and OTP fuses. The chip contains an Cortex-M33 processor that implements TrustZone-M for secure world and non-secure world computing. There are one-time programmable Fuses (OTP) for storing root-of-trust information. There is a glitch detector that runs in 4 physically separate locations that works by detecting manipulation in the clock or voltage. Finally, there is a redundancy co-processor that executes all code in parallel, ensuring deterministic execution and protection against fault injection. For further FI protections in software, there are stack canaries, instruction delays to make FI less consistent, and integer/boolean value validation. The first security issue is around the reading of OTP Power-On State Machine (PSM). To prevent glitching the IPS voltage line, guard reads are in place; if a specific value isn't read before the real value, then the read must be corrupted. The OTP Power Supply (IPS) saves the read data during a power failure, as long as the power remains off. When this happens, the data are interpreted as the value on the IPS line! By carrying forward the guard word, this becomes a major problem. Once the data is read out, it's written back to the OTP rows. By chance, the guard word 0x333333 is written back to the CRIT1 and CRIT2 OTP rows, changing the chip's security. This disables secure boot, bypassing the chip's security. Additionally, DEBUG_DISABLE is also disabled, giving full debug access to the chip. This issue was found by dynamically debugging the chip and observing the results. Pretty neat! Much of the bootloader contains code with hardened checks that assume glitching. For instance, double-checking values, XORing magic values, and many other things are done. By reviewing the ASM of the bootloader, they found a primitive that, when specific instructions were skipped via glitching, allowed them to jump to an arbitrary location in RAM. By loading a malicious firmware into memory, this could be used to load an arbitrary binary. They attempted to do these in order of least difficult. First, they used a debugger on the chip to see whether skipping these instructions would allow their attack to work. Next, they performed the attack both with and without glitch detection. Although the glitch detections prevented the attack most of the time, successful glitches still got through. They think this is because the glitch could be so minor and still succeed. Overall, an interesting attack and good discovery via code review. The next attack uses laser fault injection to create localized errors not detected by the built-in defenses. Their target was the hashing process of loading in the firmware to be verified. Since QSPI flash can be swapped in, it's possible to create TOCTOU bugs on verified vs. executed firmware in conjunction with FI. They found several locations where a successful glitch caused unauthorized code to run. The next attack was another quick glitch in the reading of OTP values. OTP pages are configured to be readable by the firmware but NOT by the otp commands that an attacker could run. This is done by reading the SW_LOCK fuse twice. The code performs left and right 28-bit shifts to clear the upper bits of the locked value. If the right-shift instruction is skipped, then the OTP value will have a corrupted value and the SW_LOCK write to OTP is skipped. This read is performed twice with randomized time delays, but it is still doable with an Electromagnetic fault injection setup. This allows using the OTP boot to read fuses that shouldn't be accessible. The fuses are assumed to be unreadable. Their final attack is to read the fuse data directly from the fuse memory array. They found that Passive Voltage Contrast (PVC) could be used to read the antifuse bitcell memory. A little over my head, but still interesting research. They have a few takeaways: Effectiveness of Hardware Mitigations. Two of their techniques bypass these protections altogether, while others were able to work around the restrictions. These make the attack harder to pull off, but not impossible. The Dangers of Complicated Boot Paths. Bootrom and bootloaders should be minimal to minimize the primitives for exploitation. Other features should be added to a later stage. I personally really enjoyed this research paper, though I did need to learn a lot of the concepts. Still, there's a constant cat-and-mouse game between hardware protections and attackers that hasn't been resolved yet. Great read!
Analysis Summary