ENOLA: Linear-Space and Low-Overhead Control-Flow Attestation for Microcontroller-based Systems

arXiv:2501.11207 · cs.CR · Submitted 2026-08-11 · Read on arXiv

Listen

Radio episode about this paper

Transcript

Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "ENOLA: Linear-Space and Low-Overhead Control-Flow Attestation for Microcontroller-based Systems".

Jane: The paper was written by Md Armanuzzaman, Engin Kirda and Ziming Zhao from University of Texas at El Paso and Northeastern University.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Title and Authors: Tom: Welcome back to the show, everyone! Today we're diving into a paper that's got a seriously catchy name — "ENOLA: Linear-Space and Low-Overhead Control-Flow Attestation for Microcontroller-based Systems." Jane, I gotta say, the title alone tells you they're tackling two big problems at once.

Jane: Absolutely, Tom. And the author list is stacked — Md Armanuzzaman from UTEP, Ziming Zhao from Northeastern, and Engin Kirda also from Northeastern. These folks have serious credentials in embedded systems security. But let's break down that title for our listeners, because "control-flow attestation" sounds intimidating.

Tom: Please do, because I was about to butcher it.

Jane: So imagine you're a security guard at a factory, and you need to verify that a worker followed the exact path through the building that they were supposed to. Control-flow attestation is basically that — a remote verifier wants proof that a program executed the correct sequence of instructions, not some hijacked path.

Tom: And the "microcontroller" part is crucial here. We're talking about those tiny computers inside medical pumps, car sensors, industrial controllers — devices with maybe a few hundred kilobytes of memory and a processor that's way slower than your phone.

Lu: If I can jump in — that's what makes this paper so exciting. Existing solutions for control-flow attestation were built for big, powerful processors. They generate so much data that a tiny microcontroller would choke trying to send it. ENOLA is specifically designed for these resource-constrained devices.

Jane: Exactly, Lu. And the "linear-space" part of the title means the amount of data they need to send grows proportionally with the program size, not exponentially like some previous approaches. That's a game-changer for scalability.

Meng: From an engineering standpoint, that's the difference between "we can attest this tiny demo program" and "we can attest a real-world application like wolfSSL." The paper actually shows they tested it on wolfSSL, which is a real TLS library used in embedded systems. That's not a toy.

Tom: So they're not just theorizing — they actually built this thing and tested it on real hardware?

Jane: They did. And we're going to get into the nitty-gritty of how they pulled it off. But first, let's just appreciate the scope — they're trying to secure the devices that run our critical infrastructure, and they've found a way to do it that actually fits within the hardware constraints.

Tom: I'm hooked already. Let's keep going and dig into what this paper actually proposes.

Summary: Tom: Alright, so we've established that ENOLA is about proving to a remote verifier that a microcontroller ran the correct code path. Jane, what's the core idea here?

Jane: The core insight is actually pretty elegant. Instead of recording every single control-flow event — which is what previous solutions like Blast or OAT did — ENOLA records something much smaller: a count of how many times each basic block was executed. A basic block is just a straight-line sequence of instructions with no branches in or out.

Lu: And that's the linear-space breakthrough. The trace size is bounded by the number of basic blocks in the program, not by how many times those blocks execute. So a loop that runs a million times only counts once in the trace — you just record the count.

Tom: So it's like saying "I visited this intersection fifty thousand times" instead of listing every single trip through it?

Jane: Exactly that. But here's the clever part — they don't just rely on the counts. They also compute two cryptographic measurements: one for the forward path, meaning calls and jumps, and one for the backward path, meaning function returns. These measurements are chained together using hardware support.

Meng: And that hardware support is the ARM Pointer Authentication extension. It's basically a built-in message authentication code generator. The paper shows it's about four hundred eighty times faster than using a software hash like BLAKE2s. That's a massive performance win.

Lu: The other big security move is that they store these measurements in dedicated CPU registers, not in memory. So even if an attacker corrupts the device's RAM, they can't tamper with the attestation data.

Jane: And they use TrustZone — the ARM security extension — to protect the trace recording. The attested program runs in the normal world, but the trace is logged in the secure world. That way, even a compromised program can't fake its own execution history.

Tom: So they've got three layers: the compact trace, the hardware-accelerated measurements, and the secure enclave for recording. That's a solid trifecta.

Meng: It is, but I want to be clear about the trade-off. The paper reports execution overhead that can be pretty high in some cases — like three hundred percent or more for certain benchmarks. The real win is in the data transmission. They cut the attestation report size by an average of fifty-two times compared to Blast.

Jane: And that's the right trade-off for microcontrollers. Sending data over a low-power radio is expensive and slow. Computing a few extra instructions is cheap. They've optimized for the bottleneck that actually matters.

Lu: Plus, they show that the verification side is practical too. The verifier uses a backtracking algorithm that can handle the compact trace format without getting lost.

Tom: So the summary is: ENOLA makes control-flow attestation actually feasible for microcontrollers by shrinking the data and using hardware tricks to speed things up. What's next — how do they improve on existing work?

Improvements: Tom: We've covered the basics of ENOLA. Now let's talk about what makes it a genuine improvement over what came before. Jane, what were the old approaches doing wrong?

Jane: The old approaches had three fundamental problems. First, they generated way too much data — either exponential growth with program size or linear growth with execution length. Second, they stored keys and measurements in regular memory, which attackers could corrupt. Third, they used slow software hashing and constantly switched between the normal and secure execution environments.

Lu: ENOLA attacks all three problems at once. The compact trace handles the data explosion. The dedicated registers and TrustZone-protected storage handle the memory corruption threat. And the Pointer Authentication hardware eliminates the need for software hashing.

Meng: The context switch reduction is particularly clever. Previous solutions like C-FLAT would switch to the secure world for every single control-flow event — both forward and backward edges. ENOLA only switches for forward edges. The backward edges, the function returns, are handled entirely in the normal world using the PA instructions.

Jane: That's a huge deal. Function returns are often the most frequent control-flow event in a program. Eliminating those context switches cuts a massive chunk of overhead.

Tom: And they also added something to deal with interrupts, right? Because microcontrollers are constantly handling interrupts from timers, sensors, communication interfaces.

Jane: Right. They built a secure interrupt dispatcher inspired by ISC-FLAT. When an interrupt fires, the dispatcher saves the attested program's context and measurements in secure memory, marks the program's stack as read-only so the interrupt handler can't tamper with it, and then restores everything when the handler finishes.

Lu: That's important because a compromised interrupt handler could otherwise corrupt the attestation state. The dispatcher makes sure that even if the handler goes rogue, the deviation gets flagged in the attestation report.

Meng: And they actually tested this. They ran a toggle-LED application with a SysTick interrupt firing every ten milliseconds, and the overhead was only about thirteen percent. That's very reasonable for the security guarantee you're getting.

Tom: So the improvements are: less data, faster computation, fewer context switches, and interrupt safety. What about the practical impact — can this actually be deployed?

Meng: That's the exciting part. They evaluated on a real Cortex-M85 microcontroller, which is a modern, commercially available chip. They tested on Embench, which is a standard embedded benchmark suite, and wolfSSL, which is a real-world TLS library. The largest application they tested had over five thousand basic blocks.

Jane: And they showed the attestation size stays linear with the number of basic blocks, not with the number of executed events. That's the scalability guarantee that makes this viable for production systems.

Lu: I think the biggest implication is that we can now have verifiable control-flow integrity for the billions of microcontrollers deployed in critical infrastructure, medical devices, and industrial systems. That's a massive security upgrade for the Internet of Things.

Tom: Alright, so we've got the improvements. Let's wrap this up and talk about what it all means.

Conclusion: Tom: We've spent the show talking about "ENOLA: Linear-Space and Low-Overhead Control-Flow Attestation for Microcontroller-based Systems," and I think we can all agree this is a significant step forward for embedded security.

Jane: Absolutely. Let's recap what makes this paper special. ENOLA solves the scalability problem that plagued previous control-flow attestation schemes. Instead of generating exponential or execution-length-proportional data, it produces a trace that's linear in the number of basic blocks. That's the difference between attesting a toy program and attesting a real TLS library.

Lu: And it does this while maintaining strong security guarantees. The measurements are stored in dedicated registers, protected from memory corruption. The trace is recorded in the TrustZone secure world. The keys never touch regular memory. And the hardware-accelerated measurements are hundreds of times faster than software hashing.

Meng: From an engineering perspective, the fact that they evaluated on real hardware — a Cortex-M85 — with real workloads like wolfSSL and Embench gives me confidence this isn't just a theoretical exercise. The fifty-two times reduction in attestation data size is the kind of number that makes a deployment decision easy.

Jane: And the interrupt dispatcher addresses a real-world concern that most academic papers ignore. Microcontrollers live in a world of constant interrupts, and ENOLA handles that gracefully with only about thirteen percent overhead in their test case.

Tom: So what's the big picture here? What does this mean for the world?

Lu: It means we can finally trust the software running on the tiny devices that control our power grids, our medical equipment, our vehicles. Remote attestation gives us a way to verify that a device hasn't been compromised, even after it's deployed in the field. ENOLA makes that verification practical for the devices that need it most.

Meng: And it opens the door for more research. The paper mentions future work on reducing runtime overhead further, maybe using hardware trace components or coarser attestation granularity. There's room to optimize.

Jane: The authors also acknowledge limitations — they don't handle multitasking environments yet, and their interrupt dispatcher doesn't support nested interrupts. But those are clear next steps, not dead ends.

Tom: Well said. ENOLA is a paper that takes a hard problem, makes it tractable, and demonstrates it on real hardware. That's the kind of research that moves the field forward.

Jane: And with that, we'll say goodbye to ENOLA and get ready for our next paper. Thanks for listening, everyone!

Tom: See you next time!

Md Armanuzzaman, Engin Kirda, Ziming Zhao

University of Texas at El Paso · Northeastern University

cs.CR

Submitted: 2026-08-11

Comments: 18 pages and 10 figures

DOI: 10.1109/TCAD.2026.3722819

Code: https://github.com/CactiLab/ENOLA-Efficient-CFA-for-EmbeddedSystems

License: http://creativecommons.org/licenses/by/4.0/

Importance score: 71/100

The gist: Control-Flow Attestation (CFA) aims to precisely verify execution paths to a remote verifier.

Key concepts

Control-Flow Attestation
It is the process of proving remotely that a program executed the correct sequence of instructions. It verifies that a device followed its intended path and was not hijacked by an attacker.
Linear-Space Trace
A breakthrough feature where the size of the data needed for attestation grows proportionally with the program's basic blocks, rather than exponentially or with the total number of executed events.
Microcontroller-based Systems
These are small, low-power computers found in devices like medical pumps and car sensors. They have limited memory (kilobytes) and processors much slower than modern phones.
TrustZone
An ARM security extension used to protect the trace recording process. It allows the attested program to run in a normal world while the sensitive log is stored securely in a separate, protected 'secure world'.

Terminology

Summary

Control-Flow Attestation (CFA) aims to precisely verify execution paths to a remote verifier. However, existing solutions are fundamentally incompatible with resource-constrained, microcontroller-based systems due to three key reasons: "(1) the overhead of transmitting measurement and trace data scales poorly (i.e., often exponentially) with the number of basic blocks or linearly with the length of execution traces, making such approaches impractical even on high-end microprocessor-based systems and entirely infeasible on microcontrollers; (2) cryptographic keys and measurement data are typically stored in memory, rendering them vulnerable to cold boot and memory corruption attacks, which is a serious threat for field-deployed devices; and (3) reliance on software-based measurements, combined with frequent context switches between the Rich Execution Environment (REE) and the Trusted Execution Environment (TEE), introduces significant performance overhead."

The paper presents ENOLA, a linear-space and low-overhead control-flow attestation solution for microcontroller-based systems. ENOLA achieves linear transmission complexity with basic blocks, guaranteeing scalability for larger programs. It uses hardware-assisted measurement computation present in off-the-shelf devices, avoids key storage in memory, and allocates general-purpose registers for measurements to thwart memory corruption attacks. ENOLA significantly reduces context switching overhead by eliminating transitions from REE to TEE for backward-edge measurements.

The paper's contributions are summarized as follows:

  1. Formalization of CFA complexity: The authors formalize the concept of control-flow attestation, and identify the limitations present in prior studies, characterizing the transmitted-authenticator scalability of representative CFA schemes.

  2. Novel authenticator design: ENOLA introduces a novel authenticator achieving linear space complexity with respect to the number of basic blocks in the attested program. On the Embench benchmark, ENOLA reduces transmitted data by 52 times on average compared to Blast. "To safeguard the authenticator against memory corruption, ENOLA retains the forward- and backward-edge measurement chains in two compiler-reserved general-purpose registers rather than REE memory, while using TrustZone-protected memory for occurrence trace storage."

  3. Implementation on ARMv8.1-M: ENOLA is implemented on an ARMv8.1-M Cortex-M85 microcontroller system leveraging compiler instrumentation, TrustZone, MPU, and PA-based measurement computation. These mechanisms enable efficient authenticator generation, protect measurement state and measurement keys under the stated threat model, and reduce TEE context switches by computing backward-edge measurements directly in the REE.

System model: ENOLA assumes the embedded system processor provides a TEE, an MPU, and hardware capabilities for keyed message authentication code computations within the REE. The attested program can execute at unprivileged or privileged level within the REE, while the ENOLA attestation engine operates within the TEE. The verifier can reside on any powerful system.

Threat model: The paper assumes secure boot to ensure both: (1) the ENOLA attestation engine's code and data, and (2) the REE software, are securely loaded at boot time. Attackers could attempt to compromise memory content within the REE, use ROP gadgets to manipulate general-purpose registers, and modify key registers. TOCTOU attacks, physical attacks such as power analysis or electromagnetic analysis, timing attacks, and data-only attacks are considered out of scope.

The authenticator Auth = (T, M) includes a basic block occurrence trace (TO) and two measurements M = ⟨Mf, Mb⟩, representing the forward path (Mf) and backward path (Mb) taken by the program. The backward path specifically refers to the sequence of function returns.

The trace TO is structured as: TO = (⟨vi.s, #vi⟩i = 0,..., V − 1 ∧ #vi ≠ 0, ti ti ∉ ∪vi.s), where vi.s represents the start address of basic block vi, and #vi denotes the occurrence count of vi during execution. The trace space complexity is linear with respect to the number of basic blocks, i.e., O(V).

Both measurements use the same hash chain approach: Mi = HKm(0, di) if i = 0, and Mi = HKm(Mi−1, di) if i > 0, where HKm represents the measurement function with key Km.

The workflow consists of three stages:

Compile-time: The ENOLA compiler instrumentation serves two purposes: (1) reporting control-flow events to the attestation engine for constructing TO, and (2) calculating and storing measurements using PA instructions in designated general-purpose registers. The ENOLA analyzer constructs an Indirect Target List (ITL) containing valid destination addresses for all potential indirect branches or calls. The ENOLA code scanner verifies that no programs in the normal state contain instructions or gadgets capable of tampering with critical registers.

Run-time: The ENOLA attestation engine runs in the secure state. At system boot, it receives a nonce from the remote verifier, retrieves keys from secure storage, and configures the PA key registers. During execution, instrumented instructions trigger the attestation engine to record the occurrence trace TO, and invoke the PA hardware to generate measurements stored in reserved registers. On completion, the attestation engine retrieves these values and generates a signature over Auth, constructing the attestation report.

Verification-time: The ENOLA verifier authenticates the signature and abstractly executes the program guided by the trace TO, comparing recalculated measurements with received values using a backtracking algorithm.

The attestation engine provides non-secure callable functions report direct and report indirect for the attested program to report branch destinations. For direct branches, ENOLA inserts bl instructions at the beginning of each branch target basic block. For indirect branches, the destination is available in r0 for the attestation engine. For loops, ENOLA instruments the loop body and exit basic blocks, but not the loop condition block since it is the immediate dominator of both.

The ENOLA attestation engine retrieves the measurement key Km from secure storage and loads it into PA key registers with the privileged msr instruction, ensuring the key is never spilled to memory. The compiler reserves general-purpose registers r10 and r11 to securely store Mf and Mb respectively. For forward path measurements, the compiler inserts pacg instructions at the start of all destination basic blocks. For backward path measurements, pacg instructions are inserted before all function returns—for non-leaf functions, the return address is loaded from the stack into a free register, while leaf functions use pacg r11, lr, r11 directly.

ENOLA employs a modified version of ISC-FLAT to ensure ISRs always return benignly to the program. The dispatcher intercepts all normal state interrupts, saves the context of the program (including stack pointer, measurements, and system registers) onto the secure stack, and configures the MPU to mark the program's stack as read-only during ISR execution. On ISR completion, the dispatcher restores the saved context. A flag Ix is recorded in TO on interrupt entry and cleared upon ISR return, signaling any deviation from expected ISR behavior.

The paper identifies six attack prerequisites and explains how ENOLA mitigates each: (P1) disabling or bypassing instrumented code is mitigated through MPU-enforced code immutability; (P2) tampering with measurements or keys is prevented since they are never spilled to memory; (P3) hash collisions are infeasible as QARMA block cipher has a collision probability of 2−60; (P4) exploiting trampoline interfaces is prevented by prohibiting direct world-switch calls; (P5) replay or corruption of Auth is prevented through secure state signing and random nonce; (P6) exploiting vulnerable ISRs is mitigated through the secure ISR dispatcher.

The ENOLA LLVM compiler modules comprise 4,675 lines of C++ code. The attestation engine consists of 307 lines of C and inline assembly code. The analyzer, code scanner, and verifier are implemented with 138, 93, and 694 lines of Python code respectively, leveraging angr and pyelftools libraries. The compiler extends LLVM 16.0.0 ARM embedded toolchain with front-end Annotator and back-end Instrumentor passes, and modifies ARMBaseRegisterInfo to reserve r10 and r11.

Syringe pump application: For the move-syringe path, ENOLA achieved the lowest average execution time overhead of 1.3% compared to Blast's 6.6%. ENOLA's maximum Auth size was 88 bytes, far smaller than C-FLAT's 1,179 bytes. In the set-quantity path, ENOLA incurred 67.9% overhead with 48 bytes Auth, whereas C-FLAT produced up to 1,527 bytes.

Embench applications: ENOLA incurs average execution overhead of 322.20% and 278.64% for O2 (with/without loop unrolling), and 284.54% and 431.53% for Oz. Code size overhead is 29.71% and 38.57% with O2, and 35.3% and 32.62% with Oz. ENOLA Auth size under O2 and Oz averages 397 bytes and 224 bytes respectively, while Blast produces an average of 21,009 bytes, resulting in a 52 times or greater reduction.

wolfSSL applications: ENOLA was evaluated on four larger applications including AES, MD5, HMAC, and RSA (with 5,480 basic blocks). The average execution time is notably lower for both optimization levels compared to Embench. Auth sizes scale linearly with basic blocks even for larger applications.

Secure ISR dispatcher: With SysTick interrupts every 10ms, the dispatcher incurs a modest overhead of 13.33% (6.73 million vs 7.53 million clock cycles).

Micro-level performance: A pacg instruction consumes 12 CPU cycles, while Oz-optimized SHA-256 and BLAKE2s need 5,083 and 7,939 cycles respectively, making ENOLA's measurement calculation at least 480 times faster than software-based approaches.

The paper notes that ENOLA currently lacks multitask attestation support for real-time operating systems, and its secure interrupt dispatcher is designed for bare-metal applications without nested interrupt support. Future work includes minimizing runtime overhead through hardware trace components, eliminating TEE reliance through unprivileged load/store instructions, and enabling TOCTOU defenses like RATA.

Improvements for AI systems

Based on the E NOLA paper, I can improve AI systems in the following specific ways:

  • Improvement: Integrate E NOLA’s LLVM-based instrumentation passes into AI model compilation pipelines (e.g., for edge AI on MCUs) to automatically insert control-flow attestation hooks.

  • Capability: The AI system can now compile its own neural network inference code with built-in, hardware-accelerated control-flow integrity checks, detecting and reporting any runtime hijacking (e.g., ROP attacks) without manual code modification.

  • Improvement: Train an AI classifier on E NOLA’s basic-block occurrence traces (TO) and forward/backward measurement chains (Mf, Mb) to detect subtle control-flow deviations that are not caught by simple count checks.

  • Capability: The AI system can distinguish between benign loop iterations and maliciously injected code paths (e.g., a syringe pump dispensing an incorrect bolus) with high precision, using only a linear-size attestation report (O(V)) rather than exponential or full-trace data.

  • Improvement: Replace the exponential worst-case backtracking verifier with a reinforcement learning (RL) agent that learns to prune infeasible CFG paths based on historical attestation reports and program structure.

  • Capability: The AI verifier can reduce verification time from O(2 V) to near-linear in practice for large programs (e.g., wolfSSL RSA with 5,480 basic blocks), enabling real-time attestation of complex embedded workloads.

  • Improvement: Use a graph neural network (GNN) over the binary’s control-flow graph to automatically detect ROP gadgets or privileged msr instructions that could tamper with E NOLA’s reserved registers (r10, r11) or PA key registers.

  • Capability: The AI system can proactively flag unsafe code patterns in vendor libraries or handwritten assembly before deployment, eliminating the need for manual code review and reducing the risk of memory-corruption attacks on measurement state.

  • Improvement: Implement a meta-learning algorithm that dynamically selects between basic-block-level and function-level attestation (as discussed in Section IV-B) based on the program’s CFG complexity and real-time security requirements.

  • Capability: The AI system can trade off between verification granularity and runtime overhead (e.g., 1.3% vs. 67.9% overhead on syringe pump paths), automatically choosing the optimal setting for each execution context to meet both security and performance SLAs.

  • Improvement: Train a predictive model on interrupt patterns and E NOLA’s dispatcher logs to preemptively save/restore measurement state and configure MPU protections before an interrupt occurs.

  • Capability: The AI system can reduce the 13.33% interrupt-handling overhead by anticipating high-frequency interrupts (e.g., SysTick) and batching context-switch operations, while still detecting malicious ISR behavior via the Ix flag in TO.

  • Improvement: Use transfer learning to map E NOLA’s ARMv8.1-M-specific PA instructions and TrustZone configurations to other architectures (e.g., RISC-V with PMP or x86 with SGX) by learning the semantic equivalence of security primitives.

  • Capability: The AI system can automatically generate E NOLA-compatible attestation engines for new MCU platforms, reducing development time from months to days and enabling broader deployment of linear-space CFA.

  • Improvement: Integrate an AI anomaly detector that monitors the reserved registers (r10, r11) and PA key registers for unexpected changes (e.g., due to DMA or cold-boot attacks) using hardware performance counters.

  • Capability: The AI system can trigger immediate attestation failure or secure re-keying if it detects any unauthorized modification to measurement state, even if the attack bypasses software-level checks.

Abstract

Control-Flow Attestation (CFA) aims to precisely verify execution paths to a remote verifier. However, existing solutions are fundamentally incompatible with resource-constrained, microcontroller-based systems due to the following reasons: (1) the overhead of transmitting measurement and trace data scales poorly (i.e., often exponentially) with the number of basic blocks or linearly with the length of execution traces, making such approaches impractical even on high-end microprocessor-based systems and entirely infeasible on microcontrollers; (2) cryptographic keys and measurement data are typically stored in memory, rendering them vulnerable to cold boot and memory corruption attacks, which is a serious threat for field-deployed devices; and (3) reliance on software-based measurements, combined with frequent context switches between the Rich Execution Environment (REE) and the Trusted Execution Environment (TEE), introduces significant performance overhead. In this paper, we present ENOLA, a linear-space and low-overhead control-flow attestation solution for microcontroller-based systems. ENOLA achieves linear transmission complexity with basic blocks, guaranteeing its scalability for larger programs. Moreover, ENOLA uses hardware-assisted measurement computation present in off-the-shelf devices, and avoids key storage in memory. ENOLA also allocates general-purpose registers for measurements to thwart memory corruption attacks. ENOLA significantly reduces context switching overhead by eliminating transitions from REE to TEE for backward-edge measurements. We developed the ENOLA compiler using LLVM passes and a custom attestation engine targeting the ARMv8.1-M architecture. Our evaluation shows that ENOLA reduces data transmission overhead by an average of 52x on the Embench, while maintaining performance comparable to (or exceeding) that of existing approaches.

Related papers