The First Single-Stepping Framework for Arm TrustZone-M
M-Step is the first framework enabling single-stepping — instruction-granular observation — inside TrustZone-M's Secure World.
By carefully profiling previously undocumented Cortex-M interrupt-handling behavior, M-Step allows an attacker controlling the untrusted operating system to pause secure-world execution one instruction at a time and measure tiny timing differences that reveal what the secret code is doing.
This technique, previously limited to high-end server processors via frameworks like SGX-Step, is now brought to the billions of microcontrollers powering the Internet of Things.
Cannot be interrupted during execution. M-Step schedules the interrupt immediately afterwards to advance exactly one instruction.
Can be interrupted mid-execution and then resumed. M-Step exploits this to achieve precise intra-instruction observations.
Are restarted from scratch when interrupted. M-Step times its interrupt to the final execution cycle for deterministic progress.
Smart Lock Attack: Interactive Demo
Try it: press two digits (e.g. 1 then 2) on the simulated keypad, or use your keyboard (Clear resets). M-Step single-steps the secure world and records each instruction's interrupt latency of one or two cycles — every dot is one instruction. The traces look alike across digits, but a few instructions differ from the average keystroke (amber). For clarity the demo is trimmed to nine loop iterations of the PIN check, one per digit, so digit N's leak lands in iteration N. Your two most recent presses are stacked (previous on top, current below); drag-select the overview to zoom in. Watching the leak move between digits is all an attacker needs to recover the secret.
Breaking Real-World Cryptography
We demonstrate a single-trace attack that recovers a full RSA private key from a single execution of Mbed TLS on an Arm Cortex-M33 microcontroller.
Vulnerability identified in the Binary Extended Euclidean Algorithm (BEEA) used in modular arithmetic on the Mbed TLS cryptographic library for embedded IoT devices.
This affects devices where Mbed TLS acts as the cryptographic backbone for Trusted Firmware-M (TF-M).
Technical Deep-Dive: Interrupt Complexity
The core challenge on Cortex-M is that the interrupt-handling mechanism is highly optimized for real-time responsiveness. Unlike large cores, multi-cycle instructions may be abandoned or paused mid-execution.
How Cortex-M handles an interrupt during instruction execution. Each row shows one of the three instruction classes discovered by M-Step. The red bar marks when the IRQ fires. Atomic instructions defer it and complete before the handler runs; resumable instructions suspend mid-execution and pick up where they left off; restartable instructions are abandoned entirely and reissued from scratch.
Questions and Answers
- Cristiano Rodrigues (Centro ALGORITMI, Universidade do Minho)
- Marton Bognar (DistriNet, KU Leuven)
- Sandro Pinto (Centro ALGORITMI, Universidade do Minho)
- Jo Van Bulck (DistriNet, KU Leuven)
Billions of everyday devices — from smart home sensors and medical implants to industrial controllers and payment terminals — are powered by low-cost microcontrollers (MCUs). To protect sensitive operations such as cryptographic key storage and secure boot on these devices, modern Arm-based MCUs include a hardware security feature called TrustZone-M, which creates an isolated Secure World that is supposed to remain hidden even when the rest of the device software is fully compromised. Prior work had even concluded that the simple architecture of microcontrollers makes them "immune" to interrupt-based side-channel attacks. M-Step overturns this assumption.
in Mbed TLS
single-trace attack
shipped annually
fully software-based
A microcontroller (MCU) is a tiny, low-cost chip that combines a processor, memory, and peripherals in a single package. MCUs are found in an enormous range of everyday devices: smart home sensors, fitness trackers, medical implants, industrial controllers, automotive systems, payment terminals, and more. Arm estimates that over billions of Cortex-M-based chips are shipped every year.
Unlike the powerful processors in laptops or cloud servers, MCUs are optimized for low power and real-time responsiveness — but they are increasingly trusted with sensitive tasks: storing cryptographic keys, authenticating users, securing firmware boot, and protecting confidential data. This makes them high-value targets for attackers seeking to compromise devices at scale.
TrustZone-M is a hardware security feature built into modern Arm Cortex-M microcontrollers (the Armv8-M architecture). It divides the chip into two isolated worlds: a Secure World for trusted, security-sensitive code (e.g., cryptographic key management, secure boot, authentication), and a Non-Secure World for the regular application software.
The key guarantee of TrustZone-M is hardware-enforced isolation: even if the non-secure application software is fully compromised by an attacker, it should not be able to observe or tamper with the code and data inside the Secure World. M-Step breaks this guarantee through a software-only, microarchitectural side-channel attack.
Processors handle hardware interrupts — signals that briefly pause the running program to handle an urgent event, such as a timer firing. On Cortex-M, the non-secure world controls these timers and can use them to preempt secure-world execution.
By programming a timer interrupt to fire after every single instruction, M-Step forces the victim program to execute just one instruction before being paused. The attacker then measures the interrupt latency — the precise time from when the interrupt fires to when control is returned — which varies depending on what instruction the secure code executed and what data it accessed.
This instruction-granular view is extremely powerful: secret-dependent branches or data accesses that are invisible to a coarser observer leave a measurable timing signature. The same principle powers the SGX-Step framework for Intel SGX, which has enabled more than 48 published security attacks.
M-Step leakage analysis (Figure 6 from the paper) — each heatmap shows interrupt latency or memory-access probability measured on the real Cortex-M33 target. Left to right: (a) data-dependent integer division timings leak both divisor and dividend values; (b) eight representative instructions produce clearly distinct latency profiles; (c) an ICache covert channel maps each instruction to the cache line it accesses; (d) memory contention distinguishes SRAM1, SRAM2, Flash, and peripheral bus accesses. Together these show that M-Step captures a wide range of microarchitectural leakage sources far beyond simple interrupt latency.
Yes. The prior work Nemesis (ACM CCS '18) studied interrupt-latency attacks on microcontrollers and concluded that Cortex-M platforms were "immune" to such attacks. The reasoning was that the simpler MCU architecture, combined with Cortex-M's interrupt-response optimizations, prevented reliable instruction-level observation.
M-Step shows this conclusion was premature. By profiling Cortex-M interrupt handling at the instruction level — uncovering the three instruction classes (atomic, resumable, and restartable) described above — we developed an adaptive algorithm that dynamically adjusts the interrupt timer for each instruction type. The result is reliable, deterministic single-stepping of arbitrary production code on real Cortex-M33 hardware, debunking the prior immunity claim.
Mbed TLS is an open-source, lightweight cryptographic library developed by Arm, designed specifically for embedded and IoT devices. It implements standard cryptographic algorithms (RSA, AES, ECDSA, etc.) and is widely used across the embedded industry.
Crucially, Mbed TLS is the cryptographic backbone of Trusted Firmware-M (TF-M), Arm's official open-source reference implementation for TrustZone-M. This means Mbed TLS runs directly inside the Secure World on a broad range of production TrustZone-M devices from manufacturers including ST Microelectronics, NXP, Nordic Semiconductor, and others.
Using M-Step against a device running vulnerable Mbed TLS, an attacker who has compromised the non-secure OS can recover RSA private keys stored inside the Secure World — the long-term cryptographic secret used to authenticate a device, sign firmware updates, or decrypt sensitive communications.
In our demonstration, full key recovery succeeds from a single execution trace, with no need for repeated measurements. In practice, this means a software exploit on a connected MCU-based device can silently steal the cryptographic keys that TrustZone-M was designed to protect, potentially enabling device impersonation, firmware forgery, or decryption of past and future communications.
M-Step requires software control of the non-secure OS on the target device — an attacker who has already exploited a vulnerability in the application software. This is a realistic scenario for Internet-connected IoT devices, which are well known to run software with vulnerabilities and may be reachable by remote attackers.
Importantly, M-Step is a fully software-based attack: no physical access, specialized hardware, oscilloscopes, or debug connectors are required. The entire attack runs from the compromised non-secure software side of the chip, making it stealthy and practically relevant even for devices deployed in the field.
Once non-secure OS control is achieved, M-Step's key extraction is fast and reliable — a single execution trace suffices.
Yes — the immediate vulnerability in Mbed TLS has been patched following responsible disclosure to Arm, Trusted Firmware-M, and Mbed TLS on June 28, 2025:
- Mbed TLS v3.6.5 (October 15, 2025): replaced the vulnerable BEEA implementation with a constant-time alternative.
- Trusted Firmware-M v2.2.2 (November 27, 2025): incorporated the patched Mbed TLS.
- Arm assigned CVE-2025-54764 and published a security advisory.
- ST Microelectronics published guidance pointing users to the updated Mbed TLS version.
However, the underlying attack surface — interrupt-driven microarchitectural side channels on TrustZone-M — is not closed by a single patch. Other non-constant-time code running in the Secure World may still be observable via M-Step. Developers of TrustZone-M applications should audit their security-critical code for timing leakage.
Not necessarily. Many MCUs include dedicated hardware crypto engines (such as the ST SAES and SPKA on STM32L5), which are often assumed to eliminate software-level side-channel risks. Our experiments show that 7 of the 24 vulnerable Mbed TLS call sites remain exploitable even on ST platforms with hardware accelerators, because software fallback code in Mbed TLS still executes the vulnerable BEEA algorithm on certain code paths.
Regardless of whether a device uses hardware crypto acceleration, updating to Mbed TLS v3.6.5 and TF-M v2.2.2 is required to mitigate CVE-2025-54764.
-
TrustZone-M is not immune to microarchitectural side-channel attacks.
Prior assumptions about the safety of Cortex-M platforms must be revised. Interrupt-driven single-stepping is practical on modern MCUs, opening the door to the same class of high-impact attacks previously demonstrated on high-end processors.
-
Constant-time programming matters on microcontrollers too.
The Mbed TLS BEEA vulnerability illustrates that non-constant-time algorithms can expose cryptographic secrets even on the simplest platforms, especially when a high-resolution observation primitive like M-Step is available.
-
Hardware accelerators are not a complete defense.
Devices with dedicated hardware crypto engines may still be vulnerable through software fallback paths. End-to-end constant-time guarantees must be verified for all code paths, including fallbacks.
-
Update affected software.
Devices running older versions of Mbed TLS or TF-M should update to Mbed TLS v3.6.5 and TF-M v2.2.2 to mitigate the specific vulnerability (CVE-2025-54764) we exploited.
Yes. The complete M-Step framework — including the single-stepping core, microarchitectural side-channel plugins (interrupt latency, cache activity, bus contention), and proof-of-concept attack code — is open-source and available on GitHub. The repository includes all code needed to reproduce our results on an STM32L5 development board (Arm Cortex-M33).
The USENIX Security '26 artifact evaluation awarded M-Step all three badges: Available, Functional, and Reproduced.
The M-Step logo is a running pony silhouette. The design is a deliberate nod to the SGX-Step project logo — a galloping horse — which pioneered interrupt-driven single-stepping on high-end Intel SGX processors. M-Step brings the same technique to low-end embedded microcontrollers (Cortex-M), so we use a pony: same spirit, smaller scale.
The logo is released under the CC0 1.0 Universal public domain dedication — you are free to use, modify, or redistribute it without any restrictions or attribution required.
- Research paper — full technical details (USENIX Security '26)
- GitHub repository — open-source framework and attack code
- Mbed TLS security advisory — CVE-2025-54764
- Black Hat USA '26 talk — "Tiny Chips, Big Leaks: Breaking TrustZone-M with Single-Stepping Attacks"
- USENIX Security '26 presentation page
M-Step
A research project focused on exposing architectural side-channels in modern microcontrollers. Conducted at Centro ALGORITMI & DistriNet, KU Leuven.
Acknowledgements
Cristiano Rodrigues was supported by FCT grant 2020.08729.BD. This work has been supported by FCT - Fundação para a Ciência e Tecnologia within the R&D Unit Project Scope UID/00319/2025 - Centro ALGORITMI (ALGORITMI/UM), the European Union’s Horizon Europe research and innovation program under grant agreement No 101070537, project CROSSCON (Cross-platform Open Security Stack for Connected Devices), the Research Fund KU Leuven, and the Cybersecurity Research Program Flanders.
