LoginSecurity through transparency: RP2350 Hacking Challenge results are in
We launched our second-generation microcontroller, RP2350, in August last year. Building on the success of its predecessor, RP2040, this adds faster processors, more memory, lower power states, and a security model built around Arm TrustZone for Cortex-M. Alongside our own Raspberry Pi Pico 2 board, and numerous partner boards, RP2350 also featured on the DEF CON badge, designed by Entropic Engineering, with firmware by our friend Dmitry Grinberg.
All chips have vulnerabilities, and most vendors’ strategy is not to talk about them. We consider this to be suboptimal, so instead, we entered into the DEF CON spirit by offering a one-month, $10,000 prize to the first person to retrieve a secret value from the one-time-programmable (OTP) memory on the device. Our aim was to smoke out weaknesses early, so that we could fix them before RP2350 became widely deployed in secure applications. This open approach to security engineering has been generally well received: call it “security through transparency”, in contrast with the “security through obscurity” philosophy of other vendors.
Nobody claimed the prize by the deadline, so in September we extended the deadline to the end of the year and doubled the prize to $20,000. Today, we’re pleased (ish) to announce that we received not one but four valid submissions, all of which require physical access to the chip, with varying degrees of intrusiveness. Outside of the contest, Thomas “stacksmashing” Roth and the team at Hextree also discovered a vulnerability, which we describe below.
So with no further ado, the winners are:
“Hazardous threes” – Aedan Cullen
RP2350’s antifuse OTP memory is a security-critical component: security configuration bits are stored in OTP and read early in the reset process. A state machine called the OTP PSM is responsible for these reads. Unfortunately, it turns out that the OTP PSM has an exploitable weakness.
The antifuse array is powered via the USB_OTP_VDD pin. To protect against power faults, the PSM uses “guard reads”: reads of known data very close to reads of security-critical data. A power fault should cause a mismatch in the known guard data, indicating that the associated security-critical read is untrustworthy. We use a single guard word: 0x333333.
However, the OTP may retain the last sensed read data during a power fault, and subsequent reads return the most-recently-read data from when power was good. This is not itself a flaw, but it interacts poorly with the choice of guard word. If USB_OTP_VDD is dropped precisely after a guard read has occurred, 0x333333 will be read until power is restored. Therefore, an attacker can overwrite security-critical configuration data with this value.
If the CRIT0 and CRIT1 words are replaced by 0x333333 during the execution of the OTP PSM, the RISCV_DISABLE and ARM_DISABLE bits will be set, and the DEBUG_DISABLE bit will be cleared. ARM_DISABLE takes precedence, so the chip leaves reset with the RISC-V cores running and debugging allowed, regardless of the actual configuration written in the fuses. Dumping secret data from the OTP is then straightforward.
More information can be found in Aedan’s GitHub repository here, and in his Chaos Communication Congress presentation here.
No mitigation is currently available for this vulnerability, which has been assigned erratum number E16. It is likely to be addressed in a future stepping of RP2350.
USB bootloader single-instruction fault with supply-voltage injection – Marius Muench
A foundational security feature of RP2350 is secure boot, which restricts the chip to only run code signed with a specific private key. If an attacker can bypass or break out of secure boot, they can run their own unsigned code, which can potentially dump secret data from the OTP.
Marius discovered a weakness in the boot ROM’s reboot API. This supports several different reboot modes, one of which is REBOOT_TYPE_PC_SP, which reboots and starts execution with a specific program counter and stack pointer. This can only be triggered from secure firmware already running on the chip, but if an attacker could trigger this boot mode externally, and with controlled parameters, we would start executing code at an attacker-supplied address – without verifying the signature of the code!
But how can one enter this boot mode, if it is only accessible to signed and verified firmware?
The answer (of course) is fault injection. By issuing a normal reboot command to the USB bootloader, and injecting a fault (in this case by glitching the supply voltage) so that an instruction is skipped just at the right time, it is possible to trick the reboot API into believing that REBOOT_TYPE_PC_SP was requested. If an attacker has loaded malicious code beforehand into the RAM, this code can be executed and used to extract the secret.
An interesting aspect of this attack is that the code for accepting the reboot command is actually hardened against fault injection. Unfortunately, the function implementing the reboot logic itself assumes that the incoming parameters (including the requested boot mode) are sanitised. Due to an unlucky arrangement of instructions emitted by the compiler, injecting a fault which skips one out of two very specific instructions confuses the chip into rebooting to the hazardous boot type.
Marius says: “While this break may seem straightforward in retrospect, reality is quite different. Identifying and exploiting these types of issues is far from trivial. Overall, this hacking challenge was a multi-month project for me, with many dead-ends explored along the way and countless iterations of attack code and setups to confirm or refute potential findings. Nonetheless, I had plenty of fun digging deep into the intricacies of the new RP2350 microcontroller, and I would like to thank Raspberry Pi and Hextree for hosting the challenge!”
Several effective mitigations are available against this attack, which has been assigned erratum number E20. The most precise mitigation is to set the OTP flag BOOT_FLAGS0.DISABLE_WATCHDOG_SCRATCH, which disables the ability to reboot to a particular PC/SP where that function is not required by application code.
Signature check single-instruction fault with laser injection – Kévin Courdesses
Kévin discovered an exploitable weakness in the secure boot path, just after the firmware to be validated has been loaded into RAM, and just before the hash function needed for the signature check is computed. Injecting a single precisely timed fault at this stage can cause the hash function to be computed over a different piece of data, controlled by the attacker. If that data is a valid signed firmware, the signature check will pass, and the attacker’s unsigned firmware will run!
The most common method of introducing faults, seen in Marius’s attack, is to briefly pull down the supply voltage, introducing a brief “glitch”, which causes the digital logic in the chip to misbehave. RP2350 contains glitch detector circuitry, which is designed to spot most voltage glitches and to purposely halt the chip in response. To permit the injection of faults without triggering the glitch detectors, Kévin built a custom laser fault injection system; this applies a brief pulse of laser light to the back of the die, which has been exposed by grinding away part of the package. And, although several technical compromises were necessary to keep the setup within a limited budget, it worked!
More information can be found in Kévin’s paper here.
No mitigation is available for this attack, which has been assigned erratum number E24. It is likely to be addressed in a future stepping of RP2350.
Extracting antifuse secrets from RP2350 by FIB/PVC – IOActive
OTP memories based on antifuses are widely used for storing small amounts of data (such as serial numbers, keys, and factory trimming) in integrated circuits because they are inexpensive and require no additional mask steps to fabricate. RP2350 uses an off-the-shelf antifuse memory block for storing secure boot keys and other sensitive configuration data.
Antifuses are widely considered to be a “high security” storage medium, meaning that they are significantly more difficult for an attacker to extract data from than other types of memory, such as flash or mask ROM. However, with this attack, IOActive has (almost) demonstrated that data bits stored in the RP2350 antifuse memory array can be extracted using a well-known semiconductor failure analysis technique: passive voltage contrast (PVC) with a focused ion beam (FIB).
The current form of the attack recovers the bitwise OR of two physically adjacent memory cells sharing common metal-1 contacts. However, with some per-bit effort it may be possible for an attacker to separate the even/odd cell values by taking advantage of the circuit-editing capabilities of the FIB.
IOActive has not yet tested the technique against other antifuse IP blocks or on other process nodes. Nonetheless, it is believed to have broad applicability to all antifuse-based memories. Dr Andrew Zonenberg, who led the technical team on this project along with Antony Moor, Daniel Slone, Lain Agan, and Mario Cop, commented: “Our team found a unique attack vector for reading data out of antifuse memory, which we intend to further develop. Those who rely on antifuse memory for confidentiality should immediately reassess their security posture.”
The suggested mitigation for this attack is to employ a “chaffing” technique, storing either {0, 1} or {1, 0} in each pair of bit cells, as the attack in its current form is unable to distinguish between these two states. To guard against a hypothetical version of the attack which uses circuit editing to distinguish between these states, it is recommended that keys and other secrets be stored as larger blocks of chaffed data, from which the secret is recovered by hashing.
Glitch detector evaluation, and OTP read double-instruction fault with EM injection – Hextree
We commissioned the Hextree team to evaluate the secure boot process, and the effectiveness of the redundancy coprocessor (RCP) and glitch detectors. They found that at the highest sensitivity setting, the glitch detectors can detect many voltage glitches; however, the rate of undetected glitches is still high enough to make attacks feasible with some effort.
The majority of their work focused on electromagnetic fault injection (EMFI), which delivers a high-voltage pulse to a small coil on top of the chip. This creates an electromagnetic field which will collapse in the chip, providing for the injection of very localized faults which do not disturb the glitch detectors. Testing yielded multiple security-relevant results, notably that it is possible to corrupt values read from OTP by injecting faults very early in the boot process, and that random delays provided by the RCP are susceptible to side-channel measurements.
The team also found a path to bypass an aspect of the OTP protection of the chip using a double fault: the s_varm_crit_nsboot function, which locks down the OTP permissions prior to entering BOOTSEL mode, has two instructions which, when both are disturbed by precisely timed faults, can prevent an OTP page from being correctly locked, effectively allowing the user to read-out and write to the OTP even when the chip configuration forbids this. The double fault can be triggered with reasonable reliability by EMFI.
Several effective mitigations are available against this attack, which has been assigned erratum number E21. The attack occurs when the device is running non-secure bootloader code, and the OTP keys are extracted via the PICOBOOT interface. The USB bootloader can be disabled by setting the OTP flags BOOT_FLAGS0.DISABLE_BOOTSEL_USB_PICOBOOT_IFC and BOOT_FLAGS0.DISABLE_BOOTSEL_USB_MSD_IFC, which mitigates this vulnerability at the cost of removing the ability to update firmware on the device over USB.
We’d also like to express gratitude to Colin O’Flynn and his team at NewAE for collaborating with both us and Thomas Roth / Hextree on this advanced silicon security research, as well as enabling us with their fantastic ChipWhisperer kit.
What’s next?
We’d like to thank everyone who participated in the challenge. While the rules specify a single $20,000 prize for the “best” attack, we were so impressed by the quality of the submissions that we have chosen to pay the prize in full for each of them.
As expected, we’ve learned a lot. In particular, we’ve revised downward our estimate of the effectiveness of our glitch detection scheme; the difficulty of reliably injecting multiple faults even in the presence of timing uncertainty; and the cost and complexity of laser fault injection. We’ll take these lessons into account as we work to harden future chips, and anticipated future steppings of RP2350.
And while this hacking challenge is over, another one is about to start. As a component of the broader RP2350 security architecture, we’ve been working to develop an implementation of AES which is hardened against side-channel attacks (notably differential power analysis), and we’ll be challenging you to defeat it. Check back next week for more details.
All vendors have security vulnerabilities in their chips. We are unusual because we talk about them, and aim to fix them, rather than brushing them under the carpet. Security through transparency is here to stay.
The post Security through transparency: RP2350 Hacking Challenge results are in appeared first on Raspberry Pi.
