Faults in Our Bus: Novel Bus Fault Attack to Break ARM TrustZone

Faults in Our Bus: Novel Bus Fault Attack to Break ARM TrustZone

Speakers: Nimish Mishra

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=usj51JNZyvo

Overview

The proliferation of Internet of Things (IoT) devices, often powered by complex, high-frequency Systems-on-a-Chip (SoCs), presents a significant security challenge. With billions of connected devices anticipated by 2025, their widespread deployment in unsupervised environments makes them prime targets for physical adversaries. Traditional physical attacks, particularly Fault Injection (FI), have historically targeted cryptographic implementations on hardware like FPGAs and microprocessors through methods such as voltage manipulation, clock glitches, or electromagnetic (EM) and optical pulses. However, modern SoCs are increasingly resilient to these conventional techniques, often lacking accessible interfaces, featuring protective metal shields, and employing robust operating system access controls.

This talk, "Faults in Our Bus: Novel Bus Fault Attack to Break ARM TrustZone," by Nimish Mishra, addresses this evolving threat landscape by introducing a groundbreaking attack vector: the system bus. The research demonstrates the first practical implementation of injecting electromagnetic pulses onto the system bus during processor-memory interactions. This novel approach bypasses many existing hardware and software countermeasures, revealing critical vulnerabilities in the fundamental architecture of SoCs.

The findings are profound, illustrating how address bus faults can compromise software implementations of masked ciphers, including state-of-the-art post-quantum cryptography (PQC) schemes like Dilithium, SABER, and KYBER, leading to complete secret key leakage with a single fault. Furthermore, data bus faults are precisely controlled to enable Differential Fault Analysis (DFA) attacks on table-based AES implementations. The most significant revelation is the complete breakdown of ARM TrustZone's security guarantees, allowing the installation of malicious Trusted Applications (TAs) and the theft of symmetric encryption keys. This attack leverages loopholes in the GlobalPlatform API specification, making it portable across any TEE conforming to this standard, as demonstrated on OP-TEE and MyTEE on Raspberry Pi 3 and 4. The talk concludes with proposed countermeasures that have since been integrated into the SoC environment, leading to the public assignment of CVE-2022-47549.

Background

▶ Watch: Introduction: SoC security challenges and fault injection (0:00)

Fault Injection (FI) attacks have long been a significant concern in hardware security, primarily targeting cryptographic implementations. Early countermeasures often relied on detection-based approaches, employing redundancy to identify and mitigate faults. Masking, a well-established countermeasure against Side Channel Attacks (SCA), was also adapted for FI, where secret information is divided into multiple shares to prevent leakage. However, even masked implementations have proven vulnerable to sophisticated fault attacks under specific conditions.

The landscape of embedded systems has shifted dramatically with the widespread adoption of SoCs, particularly in the IoT ecosystem. Unlike FPGAs, SoCs are not reconfigurable, meaning cryptographic algorithms are predominantly implemented in software. This distinction renders many hardware-based FI countermeasures developed for FPGAs largely inapplicable. High-end SoCs, such as the popular Raspberry Pi family, incorporate inherent resistance mechanisms against traditional FI attacks. These include the absence of externally manipulable voltage or clock interfaces, the presence of metal shields over processors preventing direct EM or laser access without depackaging, and robust operating system access control policies that restrict unauthorized hardware manipulation.

Despite these advancements, SoCs are not entirely impervious. Prior FI attacks on SoCs have explored avenues such as targeting Dynamic Voltage-Frequency Scaling (DVFS) interfaces, where undervolting or overclocking induces timing violations and faults in software-based AES. Other approaches involve invasive external hardware-backed injections, like physically hooking onto Serial Voltage Identification buses or using clock glitches to bypass memory protection or load malicious firmware. Laser fault injections have also demonstrated success on various SoCs. However, these known SoC FI attacks often face strong countermeasures: DVFS-based attacks are mitigated by proper access control policies on software interfaces; low-cost SoCs like the Raspberry Pi often lack external clock/voltage interfaces, eliminating glitch attacks; and most modern SoCs feature metal casings, making EM/laser injections improbable without invasive depackaging. Memory fault attacks like Rowhammer are also typically prevented on modern SoCs.

This work introduces a fundamentally new attack vector by targeting the system bus. While prior research has explored bus faults through simulations, this presentation marks the first practical demonstration of such an attack on an SoC. Existing defenses are primarily concentrated on protecting the processor or memory modules, leaving the system bus—the critical conduit for all data and address traffic between these components—largely unaddressed. This approach significantly diverges from previous bus fault attacks on simpler systems like the CAN bus or invasive clock glitches, which are not directly portable to the high-frequency system buses of modern SoCs. The presented method is non-invasive and aims to change memory contents, rather than merely skipping memory cycles, enabling more drastic effects such as bypassing TEE signature verification.

Key Findings

▶ Watch: Bus fault attack: a fundamentally new SoC attack vector (3:00)

The research unveils several critical vulnerabilities and attack methodologies by exploiting faults in the system bus of modern SoCs:

• First Practical System Bus Fault Attack: The talk presents the first practical demonstration of injecting faults onto the system bus of an SoC using electromagnetic pulses. This establishes the system bus as a previously unaddressed and vulnerable attack surface, bypassing traditional processor and memory-centric countermeasures.
• Data Bus Faults for Symmetric-Key Cipher Breakdown: By precisely injecting EM pulses during data transfer on the data bus, the researchers demonstrated the ability to induce bit-flip faults in table-based software implementations of AES S-Boxes. This enabled a successful Differential Fault Analysis (DFA) attack on AES-128, leading to full-key retrieval with a single fault.
• Address Bus Faults for Post-Quantum Cryptography Key Leakage: The study showed that injecting faults onto the address bus during memory store operations could corrupt memory addresses, leading to SIGSEGV signals and subsequent coredumps. This novel technique was used to extract entire secret keys from NIST PQC finalists such as Dilithium, SABER, and KYBER, even from their theoretically fault-resistant masked implementations.
• Complete Breakdown of ARM TrustZone Isolation: The bus faulting strategies, combined with specific loopholes in the GlobalPlatform API specification, allowed for a comprehensive attack on ARM TrustZone. This included bypassing signature verification to install malicious, self-signed Trusted Applications (TAs) into the secure world of OP-TEE and MyTEE, and stealing symmetric encryption keys from other benign TAs.
• UUID Confusion Vulnerability: A critical design flaw in the GlobalPlatform API was identified, allowing multiple TAs to possess the same Universally Unique IDentifier (UUID). This enabled a malicious non-persistent TA to masquerade as a benign, persistent TA, intercepting and controlling communication and undermining source authentication within the TEE.
• Portability Across Platforms and TEEs: The demonstrated attacks proved portable across different hardware platforms (Raspberry Pi 3 and 4) and TEE implementations (OP-TEE and MyTEE) with minimal adjustments. This highlights that the vulnerabilities stem from fundamental design decisions in the GlobalPlatform API rather than specific implementation bugs.

Technical Deep Dive

▶ Watch: Core methodology: injecting EM faults onto the system bus (4:00)

The core of this research lies in the precise injection and characterization of faults on the system bus, which serves as the critical conduit for all processor-memory interactions. The methodology differentiates between two primary types of bus faults: Data Bus Faults and Address Bus Faults.

Data Bus Faults Characterization

Data bus faults are induced by injecting electromagnetic (EM) pulses during a load instruction, specifically when data is being transferred from memory to a destination register via the data bus. The objective is to corrupt this transient data. To demonstrate this, the researchers targeted table-based software implementations of AES S-Boxes. Unlike prior attacks that focused on hardware S-Box circuits, this approach corrupts the data as it is loaded from the S-Box table in memory. This induces bit-flip faults in the S-Box substitutions, rendering the AES implementation vulnerable to Differential Fault Analysis (DFA). Experiments showed reliable induction of bit-flips in the 8th round of AES-128, enabling full-key retrieval via DFA. In detailed characterization, 62% of injections resulted in data corruption, with 27% changing the data value to 0x0. Corruptions primarily affected the upper 16-bits of 32-bit data values, without significant bias in bit-flip patterns. A key finding was the ability of data bus faults to enable "register sweeping," effectively changing non-zero values to 0x0.

Address Bus Faults Characterization

Address bus faults are targeted during a store instruction, where the processor places a destination memory address onto the address bus. By injecting EM pulses at this precise moment, the address on the bus is corrupted. In multi-application SoC environments running an operating system, memory isolation is paramount. If a process attempts to access memory it doesn't own, the OS raises a SIGSEGV (segmentation fault) signal, terminating the process. The attack leverages this by corrupting the address bus to point to an inaccessible memory location, triggering a SIGSEGV. While a SIGSEGV in isolation might seem harmless, on Linux-based systems, it is often accompanied by the generation of a coredump. Analyzing this coredump can reveal the in-memory stack contents, potentially including secret keys stored in plaintext.

As a proof-of-concept, the researchers targeted post-quantum cryptographic (PQC) algorithms such as Dilithium, SABER, and KYBER. For Dilithium, an address bus fault was injected during the PQCLEAN_DILITHIUM2_CLEAN_crypto_sign function, specifically when the secret key is loaded onto the stack. This caused a SIGSEGV, and the subsequent coredump allowed for the extraction of the entire secret key. Crucially, even first-order masked implementations of SABER and KYBER, which are designed to be resistant to fault injections by dividing secrets into shares, were compromised. These implementations encapsulate all secret shares within a single C structure. By faulting the address bus during the loading of this structure onto the stack in functions like crypto_kem_dec_masked, a single fault was sufficient to leak all secret shares from the coredump. This demonstrates a critical implication: the security of PQC schemes is not solely dependent on their algorithmic design but also on the integrity of the execution environment, where system-level vulnerabilities can inadvertently expand the algorithm's trust boundary. Address bus fault injections resulted in SIGSEGV signals in 31% of attempts. Significantly, none of these faults resulted in a valid but incorrect memory address within the stack or heap; faults consistently pointed outside valid memory ranges due to corruptions in the upper 16-bits of 32-bit addresses.

These bus faults are fundamentally distinct from generic processor or memory faults. They are transient, do not cause system freezes, and do not rely on instruction skips. The researchers achieved precise control over fault location and type by adjusting the EM pulse burst length: shorter bursts (around 20 pulses) were effective for data bus faults, while longer bursts (around 100 pulses) were required for address bus faults.

ARM TrustZone & Attack Model

The research further leveraged these bus faults to undermine ARM TrustZone isolation. TrustZone is a hardware-backed Trusted Execution Environment (TEE) designed to create a "secure world" for critical applications, isolated from a potentially compromised "normal world" (Rich Execution Environment, REE). OP-TEE, an open-source implementation adhering to GlobalPlatform API specifications, was the chosen target.

The adversarial model aimed for two primary objectives:

1. Install a malicious, self-signed Trusted Application (TA) into the secure world, bypassing OEM signature verification.
2. Break symmetrically encrypted communication channels between Client Applications (CAs) and TAs, even in the presence of third-party defenses like SeCReT.

The attack adheres to strict goals: G1 (online), G2 (non-invasive), and G3 (timely, 0.5-2 hours). Traditional fault injection mechanisms often fail these criteria. Secure-boot attacks require reboots (violating G1); DVFS attacks are often impossible on Raspberry Pi due to lack of software control; external glitching devices violate G2; and code-based triggers (requiring victim code/kernel modification) violate G1 and G2. The bus fault approach circumvents these limitations.

To install a malicious TA, the attack targets the TA loading process, which occurs post-boot-up. This process involves signature verification against the OEM's public key. Instead of attempting instruction skips (which are often mitigated by Control-Flow Integrity checks), the attack exploits a common programming convention: Linux-based functions typically return 0 for success and a non-zero value for errors. Specifically, the verify_signature() function returns TEE_ERROR_SECURITY (a non-zero value) on failure and TEE_SUCCESS (0x0) on success. A data bus fault is injected during the mov instruction that loads the return value of verify_signature() into register w0. This fault changes the non-zero error value to 0x0, effectively tricking the subsequent cbnz (compare and branch on non-zero) instruction into taking the success path, thereby allowing the self-signed malicious TA to be loaded.

The attack also identified a UUID Confusion vulnerability in the GlobalPlatform API specification. The API does not prevent multiple TAs from having the same UUID, and OP-TEE prioritizes non-persistent TAs over persistent ones in case of a UUID conflict. This allows an adversary to install a malicious non-persistent TA with the same UUID as a benign, persistent TA (e.g., the Gatekeeper), enabling the malicious TA to masquerade as the benign one, intercepting and controlling communication, and effectively removing source authentication from the system.

Furthermore, the research demonstrated stealing symmetric encryption keys. Even with third-party defenses like SeCReT, which protects against other agents accessing a CA's memory holding symmetric keys, the attack succeeded. Address bus faults were used to force the CA itself to incur faults when accessing its own memory page, leading to a SIGSEGV and a coredump containing the symmetric session key. This bypasses SeCReT's threat model, as it assumes the CA behaves innocently.

Demo / Proof of Concept

▶ Watch: Data Bus Faults: corrupting AES S-Boxes for DFA (4:20)

The experimental setup was meticulously designed to precisely inject and characterize bus faults. The target platforms were Raspberry Pi 3 Model B and Raspberry Pi 4 boards, chosen for their ubiquity in IoT, high-frequency SoCs, and inherent resistance to traditional FI attacks (e.g., lack of external clock/voltage interfaces). While the RPi3 OP-TEE port had minor limitations regarding secure boot or memory isolation, the attack's focus on platform-agnostic GlobalPlatform API specifications ensured broad applicability.

The fault testbed comprised:

• A Keysight 33500B signal generator
• A Keysight 81160A pulse train generator
• A Teseq CBA 400M-260 power amplifier
• A Rigol NFP-3 P3 electromagnetic probe
• A Tektronix 4034B Mixed Signal Oscilloscope for monitoring outputs, connected via LAN to an adversarial RPi4 for data export.

The EM probe was mounted on an automated XYZ table, allowing for precise positioning on the backside of the RPi3 board, specifically targeting the system bus interconnecting the Broadcom processor and memory chip.

To determine optimal fault parameters amidst an exponential search space and the risk of immediate reboots, a profiling phase was conducted using a dummy program on normal world Linux. This program isolated a mov instruction, mirroring the one in OP-TEE's signature verification. For this profiling only, code-based triggers were employed to precisely identify timing. Three triggers and two delays ensured the fault was isolated to the mov instruction. Over 1,000,000 parameter searches yielded optimal values:

• Keysight 33500B (Signal Generator): 10 KHz frequency, 2V amplitude, 1V offset, 1 microsecond pulse width, 1 cycle count.
• Keysight 81160A (Pulse Train Generator): 200 MHz frequency, -8.13 dBm amplitude, 0V offset, 2 nanosecond pulse width, 15 pulse counts.
• Triggering: 1V threshold on rising edge, 2.312 microsecond delay for signal generator, 0 microsecond for pulse train generator. These parameters enabled precise EM pulse injection to coincide with the victim operation.

For the actual attack, to maintain non-invasiveness (Goal G2), the researchers switched from code-based triggers to power trace analysis. OP-TEE's signature verification involves computationally intensive RSA operations, which exhibit distinct power consumption patterns. An adversarial RPi4 continuously monitored the oscilloscope's power trace output. Upon detecting the power signature corresponding to RSA verification, it switched a chosen GPIO pin to HIGH, initiating the EM pulse injection sequence. This temporal localization of faults was achieved without any modifications to the victim code or kernel.

The results validated the proof-of-concept for all attack vectors:

• DFA on AES: Data bus faults successfully induced bit-flips in AES S-Boxes, enabling full-key retrieval.
• PQC Key Leakage: Address bus faults on Dilithium, SABER, and KYBER led to SIGSEGV and coredumps, revealing secret keys and all masked shares.
• TrustZone Bypass: Data bus faults successfully modified the return value of verify_signature() from TEE_ERROR_SECURITY to TEE_SUCCESS (0x0), allowing the installation and execution of a malicious, self-signed TA in the secure world.
• Symmetric Key Theft: Address bus faults on CAs caused SIGSEGV and coredumps, leaking symmetric session keys, even bypassing SeCReT.
• UUID Confusion: The ability to install a malicious TA with the same UUID as a benign TA was demonstrated, enabling masquerading and man-in-the-middle capabilities.

Defensive Implications

▶ Watch: Address Bus Faults: triggering SIGSEGV for privilege escalation (4:55)

Recognizing the severity of the demonstrated vulnerabilities, the researchers actively collaborated with the OP-TEE developers and Linaro to propose and evaluate effective countermeasures. The core strategy involved moving away from the conventional use of 0x0 to denote success and introducing robust redundancy mechanisms.

The OP-TEE developers have since implemented two key software countermeasures that have been evaluated and proven successful in preventing the specific attack vectors detailed in this research:

1. callee_done_not_zero: This function is integrated into checks for every sensitive function call. Its purpose is to ensure that the return code is not 0 when an error is expected. If a 0 is detected in an error state (indicating a potential fault injection like the one demonstrated to bypass signature verification), the system immediately panics and exits. This directly mitigates the data bus fault attack that manipulated return values to achieve TEE_SUCCESS.
2. callee_done_memcmp: This function is responsible for ensuring the integrity of memory copies to TEE memory. It re-executes memory copies and performs redundant comparisons with the return code. This mitigates data bus faults that might corrupt memory contents during transfer, providing an additional layer of verification for critical data.

While changing the success convention from 0x0 to a non-zero value was also proposed as a more fundamental fix, it was not implemented by OP-TEE due to the widespread and deeply entrenched adoption of the 0x0-for-success convention across Linux-based systems and associated APIs. The implemented countermeasures provide targeted protection without requiring such a significant, ecosystem-wide paradigm shift.

Regarding the portability of the attack, its success on MyTEE (a hardened implementation of OP-TEE with enhanced features like secure memory and DMA extensions) and on the Raspberry Pi 4 (with only minor parameter adjustments) underscored that the vulnerabilities exploited are rooted in design decisions within the GlobalPlatform API specification rather than specific implementation bugs or platform quirks. This reinforces the need for a holistic security approach that considers the architectural specifications themselves.

The findings were responsibly disclosed to the OP-TEE security team and Linaro. Following a 90-day embargo period, a fix was developed, tested, and released. The incident report has been made public, and the vulnerability was assigned CVE-2022-47549 under the category of "Improper Verification of Cryptographic Signature," highlighting the critical bypass of trust mechanisms.

Key Takeaways

• The system bus represents a novel and critical attack surface for Fault Injection (FI) attacks on modern SoCs, previously overlooked by traditional countermeasures.
• Electromagnetic (EM) bus faults can bypass sophisticated SoC protections, including metal shields, robust OS access controls, and the absence of external voltage/clock interfaces.
• Data bus faults can precisely induce bit-flips in table-based software implementations of AES S-Boxes, enabling successful Differential Fault Analysis (DFA) for full-key retrieval.
• Address bus faults can force SIGSEGV signals, leading to coredumps that leak entire secret keys from Post-Quantum Cryptography (PQC) schemes like Dilithium, SABER, and KYBER, even from their masked implementations.
• ARM TrustZone can be completely compromised through bus fault attacks, enabling the installation of malicious, self-signed Trusted Applications (TAs) and the theft of symmetric encryption keys, effectively breaking its security guarantees.
• A UUID Confusion vulnerability in the GlobalPlatform API allows malicious TAs to masquerade as legitimate ones, undermining source authentication and enabling man-in-the-middle attacks.
• Effective software countermeasures, such as callee_done_not_zero and callee_done_memcmp, have been integrated into OP-TEE to mitigate these specific bus fault attack vectors by introducing redundancy and stricter error handling.
• A holistic security approach is essential for SoCs, considering all architectural components, including the system bus, to ensure robust protection against sophisticated physical adversaries.

About the Speaker(s)

The talk was presented by Nimish Mishra. Based on the content of this detailed technical presentation, Nimish Mishra is a proficient researcher in the field of hardware security, specializing in fault injection attacks, trusted execution environments (TEEs), and the security of cryptographic implementations on modern Systems-on-a-Chip (SoCs). His work demonstrates a deep understanding of SoC architecture, micro-architectural vulnerabilities, and practical exploitation techniques, particularly concerning ARM TrustZone and post-quantum cryptography.