💻 computer science

State Authenticity under Multiple Bus Masters: A Non-Secure DMA Gap and Mitigation for TrustZone-M Proofs of Executio

This paper reveals that TrustZone-M proofs of execution are vulnerable to state tampering via non-secure DMA controllers because their security guarantees rely solely on CPU isolation, and proposes a lightweight mitigation using per-channel DMA security to ensure state authenticity against all bus masters.

Original authors: Arash Razban

Published 2026-07-30

📖 7 min read🧠 Deep dive

CC BY 4.0

Original authors: Arash Razban

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a world where tiny, cheap computers are scattered everywhere—inside your smart thermostat, your fitness tracker, and even the sensors on a factory floor. These little devices are supposed to be honest reporters, sending back data like temperature readings or movement counts. But what if a hacker took over one of these devices and started lying, feeding fake data into a giant cloud database? To stop this, we use a digital "proof of execution." Think of it like a notary public for computers: the device signs a receipt saying, "I promise I ran this specific math problem exactly as asked, without anyone messing with the numbers."

For this to work, the device needs two things: a secure way to prove it ran the right code, and a way to prove the data it used (the "state") hasn't been tampered with. The paper we're discussing looks at a specific, high-tech version of this proof system called TrustZone-M, which is built into many modern microchips. It's like a super-secure vault inside the chip that separates "trusted" tasks from "untrusted" ones. The big question is: if a hacker breaks into the "untrusted" side, can they sneakily change the data while the computer is doing its math, tricking the system into signing a fake receipt? This paper investigates whether the current rules of the vault are strong enough to stop a sneaky, invisible helper that can write data without the main computer ever noticing.

The Invisible Pen: How a "Ghost" Hacker Fooled a Secure Chip

In the high-stakes game of embedded security, researchers recently proposed a clever scheme called SLAPP (Stateful Proofs of Execution). Imagine SLAPP as a very strict librarian who wants to verify that a student (the device) solved a math problem correctly. The librarian checks two things: first, that the student used the right textbook (the code), and second, that the student didn't cheat by changing the numbers in their notebook (the state) while solving the problem.

The librarian's logic was simple and seemed airtight: "If the student tries to change the numbers in their notebook, they must first open the textbook to find the instructions on how to do it. But since we have a magic scanner that watches the textbook, any change to the instructions would be caught immediately. Therefore, if the textbook looks perfect, the numbers in the notebook must be honest, too."

This paper, however, pulls back the curtain to reveal a flaw in that logic. The researchers discovered that the "student" isn't the only one who can write in the notebook. There is a second, invisible writer: a DMA controller (Direct Memory Access).

The "Ghost" Writer

To understand the DMA, imagine the main computer processor (the CPU) as a busy chef chopping vegetables. The chef is the only one allowed to touch the cutting board (the memory) in the kitchen. The chef is watched by a security camera (the TrustZone-M isolation) that ensures no one else can touch the board.

But wait! There's a robotic arm (the DMA controller) sitting in the kitchen. This robot is programmed to move ingredients from the fridge to the cutting board automatically. The security camera is only watching the chef's hands. It doesn't know the robot exists. The robot can reach over, grab a bag of flour, and dump it on the cutting board while the chef is busy chopping. The chef never sees the robot, and the security camera never blinks because the chef's hands didn't move.

In the world of the SLAPP security scheme, the "robot" is the DMA controller. The researchers found that the security system was only watching the chef (the CPU). It assumed that if the recipe book (program memory) wasn't changed, no one could change the ingredients (the state). But the robot could change the ingredients without touching the recipe book.

The Attack: A Silent Poisoning

The researchers set up a test on a real chip (an STM32L5 microcontroller) to see if this "ghost" writer could actually break the system. They created a scenario where a hacker, who had already taken over the "untrusted" part of the chip, used the DMA robot to swap a legitimate number for a fake one right in the middle of the calculation.

Here is how the trick played out:

The Check: The secure part of the chip checked the notebook and saw the numbers were clean. It gave a thumbs-up.
The Swap: Immediately after the check, but before the final result was signed, the DMA robot swooped in and replaced the number with a "poison" value.
The Signature: The chip finished the math using the poisoned number and signed the receipt.
The Result: The security camera looked at the recipe book, saw it was untouched, and accepted the receipt as valid.

The result was a "proof of execution" that was mathematically valid but factually lies. The system certified a result based on data that had been tampered with, all while the main computer thought everything was fine.

Why the Usual Defenses Failed

The researchers then asked: "Why didn't the chip's built-in security stop this?" They tried three standard defenses, and each failed for a different, funny reason:

The "Lock the Robot" Attempt: They tried to tell the security system to lock the robot's arm. But the system said, "I don't control robots; I only control the chef." The security gate simply didn't apply to the robot.
The "Lock the Table" Attempt: They tried to lock the cutting board so no one could touch it. But this was too strict! The chef needed to write on the board too. If they locked the board, the chef couldn't do their job, and the whole system stopped working.
The "Alarm" Attempt: They tried to set up an alarm that would ring if the robot touched the board. But the alarm only rings if someone breaks a rule. Since the robot was allowed to touch the board (it was just the wrong kind of touch for this specific security rule), the alarm stayed silent.

The Fix: Taming the Robot

The solution wasn't to build a bigger wall or a louder alarm. It was to give the robot its own little security badge. The researchers found that the robot (the DMA controller) actually had a hidden switch inside it that could be flipped by the secure chef.

By flipping this switch, the secure world could say, "This specific robot arm is now under my control. If the hacker tries to tell it to move, it will ignore them and raise a red flag."

This fix was surprisingly cheap and easy. It didn't slow down the chef or require new hardware. The researchers tested it by securing all the robot arms on the chip. When they tried the attack again, the robot refused to move, the alarm went off, and the fake receipt was rejected.

The Big Lesson

The most important takeaway from this paper isn't just about one specific chip or one specific hacker trick. It's a lesson about how we think about security.

For a long time, security designers assumed that if you protect the main brain (the CPU), you protect everything. This paper proves that on modern chips, there are other "hands" reaching into the memory that the brain doesn't see. If you want to trust a computer's data, you can't just watch the brain; you have to watch every hand that can touch the data.

The researchers showed that the SLAPP system, as it was published, had a hole in its logic because it forgot about the "robot hands." They didn't just find the hole; they showed exactly how to patch it with a simple, lightweight fix. It's a reminder that in the world of tiny computers, the most dangerous hackers might not be the ones typing on a keyboard, but the invisible robots working in the background, waiting for someone to forget to check their ID.

Technical Summary: State Authenticity under Multiple Bus Masters

Problem Statement
The paper identifies a critical soundness gap in stateful proofs of execution on commodity Arm TrustZone-M platforms, specifically targeting the scheme SLAPP (published in IEEE TIFS 2025). SLAPP aims to provide remote attestation guarantees that a low-end embedded device executed a function correctly over authentic, unmodified state, even if the non-secure world is fully compromised.

The core vulnerability lies in Property P4 (State Authenticity). SLAPP's security argument relies on a reduction: it assumes that any adversary tampering with the attested state ( $S$ ) during execution must modify the program memory ($PMEM$) to do so. Since SLAPP measures $PMEM$ integrity, it concludes that state tampering would be detected.

However, this reduction is unsound on TrustZone-M hardware. The platform's address-based isolation (SAU/IDAU) constrains only the CPU. Other bus masters, such as DMA controllers, are not subject to these CPU-centric security attributes. On the target STM32L5 platform, DMA controllers are non-secure and programmable by default. An adversary can program a DMA channel to write directly to the attested state in data memory without the CPU fetching any instructions, thereby modifying $S$ while leaving $PMEM$ untouched. Consequently, the measurement $h = H(PMEM, \dots)$ remains valid, and the proof is accepted over a poisoned state.

Methodology
The authors validate this gap using the exact reference hardware and adversary model defined by SLAPP:

Threat Model: A fully compromised non-secure world with access to all non-secure code and data, but no access to secure memory or hardware faults.
Attack Construction: The authors implemented a purely software-based attack on a NUCLEO-L552ZE-Q board.
- A non-secure adversary pre-arms a DMA channel (configured for memory-to-memory transfer) to overwrite the protected state (a randomized-response cache) with a poison value.
- The attack is triggered within the "check-then-commit" window: after the secure world verifies the state (CheckState) but before the state is committed (SetState).
- The DMA transfer executes autonomously, corrupting the state without CPU intervention.
Evaluation of Atomicity: The authors tested the attack against both SLAPP's strict configuration (interrupts disabled) and its relaxed configuration. They demonstrated that disabling CPU interrupts does not constrain the DMA bus master, meaning the attack succeeds even in the strictly atomic, as-published configuration.
Analysis of Native Defenses: The paper systematically evaluates why the platform's native TrustZone-M isolation facilities fail to mitigate this:
- Peripheral Security Controller (TZSC): Does not govern DMA controllers; attempting to secure them via TZSC causes a boot fault.
- Block-Based Memory Protection (MPCBB): Filters based on transaction security attributes (secure vs. non-secure) rather than the issuing master. It cannot distinguish between a legitimate non-secure CPU write and a malicious non-secure DMA write; securing the memory blocks the CPU, breaking the scheme.
- Illegal Access Controller (TZIC): Only reports violations; it cannot prevent the transfer if the access is technically "legal" (non-secure master writing non-secure memory).

Key Contributions

First On-Silicon Demonstration: The paper provides the first empirical proof that a published TrustZone-M stateful proof-of-execution scheme (SLAPP) fails to enforce its state-authenticity property against a non-secure DMA adversary on its own reference hardware.
Atomicity Independence: The authors show that the vulnerability is not a result of optional atomicity relaxations but affects the strictly atomic configuration, as CPU interrupt masking does not constrain bus masters.
Systematic Defense Analysis: A detailed analysis explaining why the three natural TrustZone-M isolation primitives (TZSC, MPCBB, TZIC) are insufficient, establishing specific design constraints for any correct mitigation.
Lightweight Mitigation: The authors propose and validate a minimal fix using the DMA controller's native per-channel security (DMA_CCRx.SECM). By securing the DMA channel from the secure world at boot, non-secure software is prevented from reprogramming the channel. This blocks the adversary at the master level without affecting the CPU's ability to read/write the state.
General Principle: The paper establishes that for any attestation scheme over mutable state on a multi-master platform, authenticity must be mediated against every bus master capable of writing the state, not just the CPU.

Results

Attack Success: On the reference board, the adversary successfully corrupted the attested state within the protocol window. The scheme raised no errors, and the prototype verifier accepted the proof over the poisoned output.
Mitigation Success: When all 16 DMA channels on the device were secured at boot:
- The adversary's attempt to reprogram the DMA channel was trapped (illegal-access interrupt fired).
- The state remained uncorrupted.
- The benign protocol executed correctly with negligible overhead (the fix is a one-time boot-time register write).
- The fix was shown to be "surgical," blocking the DMA path while preserving the CPU's legitimate access to the state.
Overhead Analysis: The strict atomicity configuration (disabling interrupts) incurs a significant real-time cost (~654ms masked window) but provides zero security benefit against the DMA threat. The relaxed configuration removes this cost without sacrificing security against this specific attack vector.

Significance and Claims
The paper claims that the specific, published SLAPP scheme has no enforcement of its state-authenticity guarantee against a non-secure DMA adversary on its reference hardware. The failure is rooted in an unsound reduction in the scheme's formal argument, which incorrectly equates state integrity with code integrity under a single-writer (CPU) assumption.

The authors emphasize that this is a failure of the argument and the specific implementation, not a proof that no secure stateful attestation is possible on TrustZone-M. The proposed mitigation (per-channel DMA security) is sufficient for the published SLAPP workload (which does not use DMA) and restores the intended security property. The paper concludes that any future attestation scheme reasoning about mutable state on multi-master platforms must explicitly mediate all bus masters, not just the CPU.