Full Report
Joe Grand demonstrated a fault injection attack on the Trezor One hardware wallet in order to recover the key off the device. The original post is very dramatic but shy's area from some technical details. In this post, the author publishes their research on how this attack was performed. Fault injection is the intentional glitching of the system to produce undefined behavior. Hopefully, this benefits us, the hacker, by skipping an instruction, changes a register value or something else. There are three main types of glitching with various benefits: clock, voltage and Electromagnetic. The target of this attack is the Trezor One hardware wallet. This is a low-cost and open source wallet built around the STM32F2. The security feature is set to RDP2, meaning that flash is locked, RAM reads are locked and the debug interface is locked. If the instruction for verifying this configuration was glitched, we could re-enable these settings. The goal is to glitch the voltage/power of the wallet. To do this, the author decided to attack the internal voltage regulator. Since this is the internal voltage regulator, modifications to this line(VCAP_1 and VCAP_2) would directly affect kernel logic, flash memory and IO logic. These lines are accessible from the outer layer of the PCB as well. The vulnerability being exploited was an issue with the BootROM of the STM32F2, commonly referred to as Chip.Fail. This bug allows an attacker to inject a fault around 170 microseconds after BootROM execution in order to glitch the RDP security check. Since RDP2 is no longer in use, a debugger can be turned on to read out the SRAM of the device to get the wallets contents. How do we practically set this up though? First, we remove capacitors connected to the VCAP lines. The capacitors will attempt to keep the voltage stable, which do not want. Hooking up an oscilloscope is required, since we need to know when the device turns on in order to launch the attack. Additionally, we need to solder to the RESET line in order to turn off the board with an unsuccessful glitch. Finally, we need to solder to the SWD port for the debugging interface. Finally, with everything setup, we can replicate the attack! The author used the fancy ChipWhisperer to power the wallet, trigger the reset line and glitch the VCAP line. They used an STLink for the debugging portion of the project. If a glitch was unsuccessful, they simply changed the parameters and tried again. They knew if a glitch was successful or not by using the STLink SWD enumeration code. Prior to using this on the real board, they did this on a developer STM32 board. With the ChipWhisperer, they had to perfect the width of the glitch, the timing of it and the amount of clock cycles to repeat the glitch for. After playing with these settings and letting the setup run for an entire weekend, they successfully got the SWD debugger enabled! Overall, I love the post. One of my big hurdles for fault injection was knowing how to wire everything up on the board itself. This gives me a good idea of how to do that, which I really appreciate.
Analysis Summary
# Vulnerability: Fault Injection Bypass of Readout Protection on Trezor One
## CVE Details
- CVE ID: Not explicitly assigned in the provided text.
- CVSS Score: Not explicitly assigned in the provided text. (Note: This vulnerability targets hardware security features, often referenced by the underlying chip flaw.)
- CWE: CWE-244 (Improper Preservation of Confidentiality due to Unintended Operation or Execution) or similar hardware design flaws relating to protection mechanisms.
## Affected Systems
- Products: Trezor One hardware wallet.
- Versions: Any Trezor One utilizing the STM32F2 series MCU.
- Configurations: Devices configured with Readout Protection level 2 (RDP2), where flash is locked, RAM reads are locked, and the debug interface is locked.
## Vulnerability Description
The vulnerability exploits a known flaw in the BootROM of the STM32F2 series microcontroller (known as **Chip.Fail**). This flaw allows an attacker to interfere with the device's initialization sequence by exploiting the voltage regulation circuit. By performing a precise power/voltage fault injection targeting the VCAP lines (VCAP_1 and VCAP_2) approximately 170 microseconds after BootROM execution begins, the attacker can glitch the instruction responsible for enforcing the RDP2 security configuration. A successful glitch causes the RDP check to be bypassed or disabled, effectively unlocking the device's debug interface (SWD).
## Exploitation
- Status: Proof-of-Concept (PoC) available (The article details a successful reproduction of the attack).
- Complexity: High (Requires specialized hardware (ChipWhisperer, Oscilloscope, STLink), precise physical modification (soldering to VCAP lines, RESET, and SWD), and extensive tuning of glitch parameters (width, timing, clock cycles)).
- Attack Vector: Physical (Requires direct access to the device PCB).
## Impact
- Confidentiality: High (Successful exploitation allows complete read access to SRAM, leading to the compromise of the wallet's critical secrets/keys).
- Integrity: Medium (While the focus is on extraction, disabling boot ROM protections can allow for firmware modification).
- Availability: Low (The attack is destructive in nature if performed incorrectly, but a successful exploit yields access rather than denial of service).
## Remediation
### Patches
- **Software/Firmware:** No software patch is applicable as the vulnerability resides in the underlying STM32F2 BootROM configuration enforcement logic. Effective patching requires either hardware revision or firmware countermeasures that may not fully rely on RDP2 locks if the underlying BootROM cannot be fully trusted.
- **Vendor Specific:** Information on an official vendor patch for the Trezor One is not provided, as this is a hardware-level attack targeting the MCU.
### Workarounds
1. **Physical Security:** Preventing unauthorized physical access to the device is the primary mitigation against this type of fault injection attack.
2. **Hardware Revision:** Utilizing newer hardware revisions of cryptocurrency wallets that employ microcontrollers lacking the Chip.Fail vulnerability or employing more robust anti-tamper circuits that detect or shield against VCAP line modification is recommended.
## Detection
- Indicators of Compromise:
- Signs of physical tampering on the PCB, specifically around the VCAP regulator lines, or unauthorized soldering near debugging interfaces (SWD).
- Detection Methods and Tools:
- Voltage monitoring during startup may reveal anomalies consistent with successful voltage glitches, although specialized equipment is needed to confirm.
- Analyzing the persistent security state of the device (if read protection status can be queried post-boot) to check if RDP2 is still active when it should be.
## References
- Vendor Advisories: Referencing materials from the original discovery (chip.fail) and Joe Grand's subsequent demonstration is necessary for full context.
- Relevant Links:
- hxxps://voidstarsec.com/blog/replicant-part-1 (Article providing the detailed reproduction steps)
- hxxps://chip.fail/ (Original research context)
- hxxps://www.youtube.com/watch?v=WOMAOGOvXnA (Related EMFI talk referenced)