Source-linked AI summary
C-FLAT: Control-FLow ATtestation for Embedded Systems Software
Tigist Abera, N. Asokan, Lucas Davi, Jan-Erik Ekberg, Thomas Nyman, Andrew Paverd, Ahmad-Reza Sadeghi, Gene Tsudik
TL;DR
Static remote attestation checks whether benign software is loaded but does not attest its runtime execution path, leaving embedded systems exposed to control- and data-flow exploits. C-FLAT measures application control flow at the binary level and combines it with static attestation; its Raspberry Pi prototype detects deviations and unauthorized valid paths in an embedded syringe-pump application.
Problem
Static attestation verifies binary integrity but not runtime behavior, so verifiers cannot determine whether embedded software followed an unauthorized control-flow path.
Method
C-FLAT uses verifier-side CFG analysis and path measurements together with binary-level control-flow attestation, complemented by static attestation.
Results
C-FLAT detects runtime exploitation techniques and control-flow deviations, including attacks that produce unexpected valid measurements, in the Raspberry Pi syringe-pump prototype.
Takeaways & Limitations
C-FLAT enables the verifier to trace the exact executed control-flow path and detect runtime attacks against embedded software.
Takeaways & Limitations
The initial proof of concept focuses on single-threaded programs on small IoT MCUs and excludes pure data-flow attacks that preserve control flow.
Abstract
from arXiv · showhide
Remote attestation is a crucial security service particularly relevant to increasingly popular IoT (and other embedded) devices. It allows a trusted party (verifier) to learn the state of a remote, and potentially malware-infected, device (prover). Most existing approaches are static in nature and only check whether benign software is initially loaded on the prover. However, they are vulnerable to run-time attacks that hijack the application's control or data flow, e.g., via return-oriented programming or data-oriented exploits. As a concrete step towards more comprehensive run-time remote attestation, we present the design and implementation of Control- FLow ATtestation (C-FLAT) that enables remote attestation of an application's control-flow path, without requiring the source code. We describe a full prototype implementation of C-FLAT on Raspberry Pi using its ARM TrustZone hardware security extensions. We evaluate C-FLAT's performance using a real-world embedded (cyber-physical) application, and demonstrate its efficacy against control-flow hijacking attacks.
1. INTRODUCTION
Embedded systems need attestation that covers runtime behavior, because static measurements verify loaded binaries but not execution paths vulnerable to control-flow attacks. C-FLAT addresses this gap by attesting application control flow at binary level, with a proof-of-concept implementation and evaluation on embedded software.
- Embedded devices are widely deployed yet difficult to secure because they are special-purpose and resource-constrained.
- Static remote attestation authenticates software state and binary integrity but does not capture runtime control-flow behavior.
- Control-flow hijacking and data-oriented exploits can divert execution or select unauthorized valid paths that static attestation cannot distinguish.
- Goals and Contributions: C-FLAT computes an aggregated authenticator for the exact sequence of executed instructions, including branches and function returns.
- The initial proof of concept targets single-threaded programs on small IoT MCUs rather than arbitrary complex applications.
- Goals and Contributions: The prototype combines static control-flow analysis, binary instrumentation, and an ARM TrustZone trusted application that monitors runtime control flow.
2. PROBLEM SETTING
Runtime attacks exploit memory vulnerabilities to manipulate control-flow information or data that influences execution, producing malicious actions through apparently valid paths. The problem setting therefore includes both control-flow hijacking and non-control-data attacks, while excluding pure data-oriented programming that leaves control flow unchanged.
- Runtime attacks exploit vulnerabilities such as buffer overflows to corrupt control-flow information stored on the stack or heap.
- The Figure 1 example models a program whose authentication-dependent branch can be redirected after an attacker overwrites a code pointer.
- Non-control-data attacks can alter variables such as auth to select a privileged, valid control-flow path without changing the CFG.
- Pure DOP attacks manipulate memory loads or stores while preserving the original control flow, so they are outside C-FLAT’s control-flow-attestation scope.
3. SYSTEM MODEL
C-FLAT extends remote attestation from static software integrity to precise runtime control-flow attestation on embedded devices. The verifier precomputes legal paths, challenges the prover, and checks a signed runtime measurement against those paths.
- The system model includes a verifier, a remote embedded prover, and an application module whose binaries both parties can access.
- Verifier preprocessing: The verifier generates the application’s CFG, measures possible control-flow paths, and stores their results in a database during one-time offline preprocessing.This shifts CFG construction and path enumeration away from the resource-limited prover.
- Attestation protocol: The prover executes the challenged module while a trusted Measurement Engine computes a cumulative control-flow authenticator, which is signed with the challenge and nonce.The nonce provides freshness, while the signed report binds the challenge to the runtime measurement.
- Verification: Static attestation authenticates the intended application, while C-FLAT measures execution so the verifier can detect illegal paths and unexpected measurements within the valid CFG.This includes detecting non-control-data attacks that produce an unexpected but valid-CFG measurement.
- Adversarial model: The adversary may introduce arbitrary malware and hijack execution through malicious public inputs, but physical attacks are excluded.The model also assumes data-execution prevention and an isolated, non-modifiable trust anchor.
4. C-FLAT DESIGN
C-FLAT hashes the exact sequence of control-flow transitions into a compact authenticator that the verifier matches against legal executions. Its design addresses path-size, loops, recursion, call-return matching, and break statements.
- High-level design: Recording every executed instruction is infeasible, so C-FLAT uses cumulative hashing of control-flow transitions to produce a compact path measurement.The design extends static hash-based attestation from binary files to dynamic runtime paths.
- Path representation: C-FLAT models CFG nodes at branch-ending basic-block granularity, allowing the verifier to precisely validate direct and indirect jumps, calls, and returns.
- Security outcome: Any unexpected measurement signals an illegal path, while the reported measurement lets the verifier determine whether a privileged path executed.
- Authenticator: BLAKE-24 computes the cumulative authenticator, and the final report authenticates that value together with the verifier’s challenge using a signature or MAC.
- Loops: Loops can create combinatorially many authenticators, so C-FLAT measures each loop execution separately and merges its value at loop exit.
- Loops: Loop measurements include observed path counts and the prior measurement stage, preserving both iteration behavior and the loop’s entry context.Separate chains also support nested loops and recursive calls, with call-return matching distinguishing concurrent loop instances.
- Break statements: Break statements are treated as special loop exits because they terminate the loop without returning through the usual conditional exit.
- Call-return matching: Call and return edges receive matching indices so legal measurements preserve which call site a subroutine returns to.
5. IMPLEMENTATION
The prototype combines offline program analysis, binary instrumentation, runtime tracing, and an isolated trusted Measurement Engine. It was implemented on Raspberry Pi 2 using ARM TrustZone-A because lightweight embedded trust anchors were unavailable commercially.
- Platform: Because lightweight TrustLite and TrustZone-M trust anchors were not commercially available, the prototype uses Raspberry Pi 2 with ARM TrustZone-A.
- Architecture: The prototype contains a program analyzer, Runtime Tracer, and isolated trusted Measurement Engine for computing and checking runtime control-flow measurements.
- Architecture: The program analyzer dynamically generates valid measurements for traced inputs, while the Runtime Tracer and Measurement Engine trace and measure the runtime path.
- Instrumentation: Instrumentation records direct branches and loops in read-only branch and loop tables, then redirects control-flow instructions through Runtime Tracer trampolines.
- Runtime tracing: Trampolines identify branch sources, destinations, and instruction types before triggering the Measurement Engine’s incremental path measurement.
- Trusted execution: The Measurement Engine runs in ARM TrustZone’s Secure World, isolating trusted measurements from the untrusted target program and Runtime Tracer.
- Node IDs: The implementation selects basic-block addresses as node IDs because many embedded systems lack ASLR support from an MMU.If ASLR is used, the base address can be reported or alternative node-ID schemes adopted.
- ARM instrumentation: ARM instrumentation must account for direct register access, including the program counter, and the variable-length ARM, Thumb, and Thumb-2 instruction sets.
6. EVALUATION
The evaluation applies C-FLAT to two embedded cyber-physical applications, measuring precise control-flow attestation and its performance overhead. Results show that overhead depends on control-flow activity but remains small relative to the physical timescales of the tested systems.
- 6.1 Case Study of a Cyber-Physical System: C-FLAT was evaluated on an open-source syringe pump application ported from Arduino to Raspberry Pi with ARM TrustZone support.The attested functionality covers actions immediately following external input, including setting and moving the syringe.
- 6.2 Attestation Results: 1527 bytes was the maximum Auth length for set-quantity, compared with 1179 bytes for move-syringe.The set-quantity path contains 16 loop invocations and 18 unique loop paths; move-syringe contains 12 loop invocations and 14 unique paths.
- 6.2 Attestation Results: Identical final hash values for repeated control-flow paths enable the verifier to determine the precise executed path.In this application, the hash remained unchanged across different dispensed or withdrawn quantities because the state variable affects loop repetitions rather than the measured path structure.
- 6.3 Performance Impact: Attestation overhead is linearly proportional to the number of control-flow events.Each event invokes a trampoline, a context switch, and the Secure World algorithm; loop handling is more costly than other event types.
- 6.3 Performance Impact: 79.8% of set-quantity overhead and 72.3% of move-syringe overhead came from the Secure World algorithm.The remaining overhead comprised trampolines and context switches, with percentages differing between the two paths.
- 6.4 Second Case Study: 237 µs was the average overhead added to one PID-controller iteration, with 0.03% overhead when attesting once per second.The measurement averaged 100 runs and had a 1 µs standard deviation; the maximum Auth length was 490 bytes.
7. SECURITY CONSIDERATIONS
C-FLAT detects runtime attacks by attesting complete control-flow behavior, including unexpected paths, loop counts, and function-call structure. Its security analysis covers code injection, return-oriented programming, function-reuse, and non-control-data exploits.
- Security evaluation: C-FLAT detects a syringe-pump return-oriented attack because its gadget chain produces an unexpected hash measurement.The verifier is thereby informed that a malicious program path was executed.
- Security evaluation: C-FLAT detects non-control-data corruption that changes liquid volume because the attestation reports precise iterations of the critical loop.The attack does not violate the program’s control-flow graph, but loop counts reveal how much liquid was dispensed.
- Security evaluation: C-FLAT detects keypad key-map corruption because the key-processing loop’s iteration count reveals which key the program appears to recognize.If the verifier knows the physical key was not pressed, the behavior is identifiable as unintended.
- Attack coverage: C-FLAT detects return-oriented programming when execution takes invalid control-flow edges or begins nodes from unauthorized locations.Missing CFG edges yield unknown hash values, while execution from the middle of a node cannot generate a valid measurement.
- Limitations: Unresolved indirect calls require dynamic analysis or over-approximation, creating a control-flow-analysis trade-off.The authors report that tailored embedded code and basic dynamic analysis enabled precise CFG analysis in the syringe-pump example.
- Attack coverage: C-FLAT detects function-reuse attacks because it attests the program’s entire control flow.The security discussion also identifies indirect calls as difficult when static analysis cannot resolve their targets.
8. DISCUSSION
C-FLAT is demonstrated on Raspberry Pi 2 using ARM TrustZone-A as the hardware trust anchor, with discussion of its path toward resource-constrained microcontrollers. Performance can be improved by caching control-flow information outside the Secure World before bulk transfer.
- Prototype platform: Raspberry Pi 2 serves as C-FLAT’s prototype platform, representing the higher-end of the embedded-device spectrum.The Measurement Engine is isolated using TrustZone-A in ARM application cores.
- Toward MCUs: ARM TrustZone-M targets lightweight isolation of security-critical functionality on next-generation microcontrollers.The discussion places TrustZone-M in embedded industry, automotive, and home computing contexts.
- Performance: Caching control-flow information in the Non-Secure World before bulk transfer to the Secure World can increase overall performance.This design reduces the frequency of transfers to the Measurement Engine.
- Hardware assumptions: TrustLite and TrustZone-M reduce trusted-application invocation overhead to a few cycles on highly resource-constrained embedded devices.TrustZone-M handles Secure/Non-Secure transitions through processor circuitry without a dedicated Secure Monitor context.
9. RELATED WORK
C-FLAT complements static-attestation schemes by attesting runtime behavior at control-flow-path granularity. Related dynamic approaches provide narrower or coarser behavioral coverage, while runtime-exploit defenses generally do not reveal the actual path taken.
- Static attestation: Static attestation includes TPM-based, software-based, and hybrid schemes, but TPMs are poorly suited to low-end embedded devices because of cost.Hybrid schemes such as SMART, TrustLite, and TyTAN use minimal hardware trust anchors.
- C-FLAT’s position: C-FLAT is complementary to static attestation because it measures runtime behavior, which is orthogonal to static integrity measurement.It extends the attestation scope from loaded binaries to execution paths.
- Runtime defenses: CFI, code randomization, and CPI mitigate aspects of runtime exploitation but do not provide the verifier with the actual control-flow path.CFI also does not cover non-control-data attacks that follow unauthorized but valid CFG paths.
- Alternative approaches: Software-based attestation can avoid a hardware trust anchor, while property-based attestation generally requires a trusted third party.These approaches differ from C-FLAT’s whole-path runtime measurement.
- Dynamic attestation: ReDAS checks selected runtime properties, whereas trusted virtual containers attest module launch order only at a coarse-grained level.Neither approach captures the whole application control-flow path.
10. CONCLUSION
C-FLAT addresses precise verification of embedded-application control flow and detects code-injection, code-reuse, and non-control-data attacks. Its Raspberry Pi prototype detects runtime exploitation, including manipulation of syringe-pump liquid volume.
- Conclusion: C-FLAT enables verifiers to detect control-flow deviations caused by code injection, code reuse, and non-control-data attacks.The paper frames this as addressing the absence of precise application-control-flow verification for embedded systems.
- Conclusion: The ARM-based Raspberry Pi prototype detects runtime exploitation against embedded software, including attacks that manipulate the amount of liquid dispensed by a syringe pump.The source code of C-FLAT is publicly available.