Bypassing TrustZone-M Isolation via DMA on Microchip SAML11

TLDR: Researchers at Black Hat 2024 demonstrated that CPU-level isolation in ARM TrustZone-M is insufficient if the system lacks hardware-level Memory Protection Controllers (MPCs). By using Direct Memory Access (DMA) to bypass the CPU, an attacker can read or write to secure memory regions, effectively nullifying the Trusted Execution Environment. This research highlights a critical gap in IoT security where developers assume CPU-centric isolation is enough, leaving sensitive cryptographic keys exposed to unauthorized access.

Security researchers often treat the Trusted Execution Environment (TEE) as a black box that magically protects sensitive assets. We assume that if we place our cryptographic keys or sensitive logic inside the "Secure World" of an ARM TrustZone-M implementation, they are unreachable from the "Non-Secure World." This assumption is dangerous. The recent research presented at Black Hat 2024 on the Microchip SAML11 microcontroller proves that CPU-level isolation is only half the battle. If your system architecture lacks a robust, system-wide memory protection strategy, your TEE is essentially a locked door in a house with no walls.

The Illusion of CPU-Centric Isolation

The core issue identified by the researchers is the disconnect between CPU-level access control and system-level memory access. ARM TrustZone-M provides primitives like the Security Attribution Unit (SAU) and the Memory Protection Unit (MPU) to enforce boundaries at the processor level. These units check memory access requests generated by the CPU core. However, in modern embedded systems, the CPU is not the only bus master. Peripherals, specifically those capable of Direct Memory Access (DMA), can move data across the system bus without the CPU ever touching the transaction.

When a system designer implements TrustZone-M but fails to include a hardware-level Memory Protection Controller (MPC), they create a massive blind spot. The MPC is the gatekeeper for the system bus. Without it, a DMA-capable peripheral can be configured to read or write to memory addresses that the CPU would normally be blocked from accessing. The researchers demonstrated this by targeting the Microchip SAML11, a device marketed for its robust security features, including TrustZone-M and secure boot. Despite these features, the lack of an MPC meant that the hardware-enforced isolation was strictly limited to the CPU core.

Exploiting the DMA Blind Spot

During their assessment, the researchers identified that they could use a malicious application running in the Non-Secure World to configure a DMA transfer. Because the DMA controller operates independently of the CPU’s MPU and SAU, it does not respect the security state of the memory being accessed. The attack flow is straightforward:

1. Identify a DMA-capable peripheral that the Non-Secure application can control.
2. Configure the DMA controller to target a memory region within the Secure World.
3. Trigger the transfer to read sensitive data, such as cryptographic keys, or write malicious code into secure memory.

This technique is a classic example of Broken Access Control in an embedded context. The researchers showed that by manipulating the DMA configuration, they could extract cryptographic keys from the secure storage of the SAML11. This is not a theoretical flaw; it is a fundamental architectural oversight. If you are performing a penetration test on an IoT device, stop looking only at the software APIs. Start looking at the hardware data sheet. If you see DMA controllers and a lack of bus-level protection, you have a clear path to privilege escalation.

The Need for System-Wide Security

The researchers proposed a "DMA Mediator" as a software-based mitigation. Since the hardware lacks the necessary MPC to block these unauthorized bus transactions, the firmware must step in. A DMA mediator acts as a gatekeeper, ensuring that any request to use a DMA-capable peripheral is validated against a whitelist of authorized memory regions. This adds a layer of software complexity, but it is a necessary evil when the hardware architecture is incomplete.

For those of us building or testing these systems, the takeaway is clear: CPU-centric security is not system security. When evaluating a platform, look for the presence of Memory Protection Controllers or similar bus-level enforcement mechanisms. If they are missing, the TEE is likely bypassable.

What This Means for Your Next Engagement

If you are auditing an IoT device, your methodology needs to evolve. Don't just fuzz the communication protocols or look for buffer overflows in the application code. Map the system bus. Identify which peripherals have DMA capabilities and determine if they can reach the memory regions where the TEE stores its secrets. If you find that the hardware lacks bus-level protection, you have found a critical vulnerability that renders the entire security model moot.

The industry is slowly moving toward more comprehensive security architectures, such as those defined in the Platform Security Architecture (PSA), but adoption is inconsistent. As researchers, we need to keep pushing vendors to provide complete hardware-level isolation. Until then, we must assume that any system without an MPC is vulnerable to these types of bus-level bypasses. The next time you see a "secure" microcontroller, check the data sheet for an MPC. If you don't find one, you know exactly where to start your exploit development.