BUSTed: Exploiting Bus Interconnect Arbitration to Bypass TrustZone-M

TLDR: Researchers have demonstrated a practical microarchitectural side-channel attack called BUSTed that targets ARM Cortex-M microcontrollers. By exploiting timing differences in the bus interconnect arbitration logic, an attacker can extract sensitive data like PIN codes even when hardware-based isolation like TrustZone-M is active. This research proves that resource-constrained embedded devices are not immune to microarchitectural analysis and highlights a critical need for constant-time programming in secure embedded applications.

Microarchitectural side-channel attacks have long been the boogeyman of high-performance computing. We spent years obsessing over Spectre and Meltdown, assuming these issues were confined to the complex, speculative-execution-heavy processors found in servers and laptops. The industry consensus was that simple, resource-constrained microcontrollers (MCUs) were inherently safe from these threats because they lacked the complex features like branch predictors and out-of-order execution engines that make such attacks possible.

That assumption is now dead. The BUSTed attack proves that even the most basic embedded systems can leak secrets through their hardware architecture. If you are performing security assessments on IoT devices or embedded systems, you need to stop ignoring the hardware layer.

The Mechanics of the BUSTed Attack

At the heart of the BUSTed attack is the bus interconnect, the central nervous system of an MCU. In a typical ARM Cortex-M architecture, the CPU, DMA controller, and various peripherals all compete for access to memory banks via a shared bus. When multiple masters attempt to access the same memory bank simultaneously, the bus interconnect’s arbitration logic must decide which request gets priority.

This arbitration process is not instantaneous. It introduces a measurable delay for the lower-priority master. The researchers identified that this timing difference is a side channel that can be exploited. By carefully timing memory access requests, an attacker can infer whether a victim process is currently accessing a specific memory address.

The researchers introduced the concept of "hardware gadgets" to automate this. A hardware gadget is a peripheral or a combination of hardware components that can be configured to perform memory operations in the background without CPU intervention. By creating a "smart gadget network," an attacker can continuously monitor the bus for contention, effectively creating a high-resolution spy that operates independently of the main application code.

From Theory to Real-Time PIN Extraction

To demonstrate the practicality of this, the team targeted an ARM Cortex-M system running Trusted Firmware-M (TF-M), which provides the software implementation of TrustZone-M. They set up a scenario where a user enters a PIN on a trusted keypad. The goal was to extract this PIN from the secure world.

The attack flow is straightforward but requires precise timing:

1. Profiling Phase: The attacker characterizes the timing behavior of the bus in a lab setting to identify the specific clock cycles where contention occurs during the victim's PIN verification routine.
2. Exploitation Phase: The attacker deploys the hardware gadgets to monitor the bus in real-time. As the victim processes the PIN, the gadgets detect the specific timing signatures associated with each digit, allowing the attacker to reconstruct the PIN digit by digit.

This is not a theoretical exercise. The researchers successfully extracted PIN codes from a target device in real-time. The code snippet below illustrates the vulnerability in a typical PIN verification routine:

// Vulnerable PIN verification logic
for (int i = 0; i < 4; i++) {
    if (input_pin[i] == secret_pin[i]) {
        // Branch taken if digit matches
    } else {
        // Dummy operation to balance timing
        dummy_op();
    }
}

While the developer attempted to mitigate timing attacks using dummy_op(), the underlying bus contention caused by the branch instruction itself created a unique timing signature that the hardware gadgets could detect.

Real-World Applicability for Pentesters

If you are testing an embedded device, you should look for code that branches based on secret data—like authentication routines, cryptographic key comparisons, or sensitive configuration checks. Even if the code is written in a "constant-time" style, the hardware architecture might be betraying you.

During an engagement, focus on the peripherals. Can you trigger a DMA transfer that overlaps with a sensitive operation? If you can control a peripheral that shares a bus with a secure memory bank, you have the potential to build your own hardware gadgets. This is particularly relevant for devices that use STM32 microcontrollers, which are ubiquitous in industrial and consumer IoT.

Defending Against Hardware Side Channels

Defending against BUSTed is difficult because the vulnerability is baked into the hardware design. However, developers can significantly raise the bar by:

• Avoiding Secret-Dependent Branching: The most effective defense is to ensure that the execution path of sensitive code does not depend on secret data. Use bitwise operations to compare values instead of if statements.
• Bus Isolation: Where possible, use hardware features to isolate sensitive memory banks from peripherals that can be accessed by untrusted code.
• Randomization: Introducing jitter or random delays into the execution of sensitive routines can make it harder for an attacker to correlate bus contention with specific operations, though this is often a "security through obscurity" approach.

The BUSTed research is a wake-up call for the embedded security community. We can no longer rely on the simplicity of our hardware to protect our secrets. As we continue to push more security-critical logic into the secure world of TrustZone-M, we must ensure that our software is not just logically secure, but also architecturally silent. If you are building or testing these systems, start looking at the bus. The timing data is there, and it is waiting to be read.