Control-Flow Attestation: Concepts, Solutions, and Open Challenges

TL;DR

This work provides the first comprehensive systematisation of control-flow attestation (CFA), surveying 31 CFA proposals from 2016 to 2024 to unify perspectives from control-flow integrity and platform attestation. It develops a taxonomy across prover-verifier paradigms, trust anchors, instrumentation methods, measurement approaches, and adversarial models, and synthesises findings with a detailed comparison table. The authors identify practical open problems—platform dependence, limited real-world deployment, closed-source implementations, lack of common benchmarks, vulnerability to physical attacks, and opportunities for extended attestation paradigms—and offer concrete recommendations to improve reproducibility, portability, and real-world applicability. Together, these insights aim to guide robust CFA design, evaluation, and deployment in diverse environments such as cloud, embedded, and IoT systems, while highlighting paths toward privacy-preserving and scalable attestation.

Abstract

Control-flow attestation unifies the worlds of control-flow integrity and platform attestation by measuring and reporting a target's run-time behaviour to a verifier. Trust assurances in the target are provided by testing whether its execution follows an authorised control-flow path. The problem has been explored in various settings, such as assessing the trustworthiness of cloud platforms, cyber-physical systems, and Internet of Things devices. Despite a significant number of proposals being made in recent years, the area remains fragmented, with different adversarial behaviours, verification paradigms, and deployment challenges being addressed. In this paper, we present the first survey of control-flow attestation, examining the core ideas and solutions in state-of-the-art schemes. In total, we survey over 30 papers published between 2016--2024, consolidate and compare their key features, and pose several challenges and recommendations for future research in the area.

Figures (20)

• Figure 1: Some control- and data-flow target points from Debes et al. debes2023zekra. An 'impure DOP vulnerability' corresponds to \ref{['attack:decision-making']} if x or y is manipulated to enter the program's 'if' block in Line 1. Line 3 may be susceptible to code reuse attacks via code injection \ref{['lab:code injection attacks']} to divert execution ($3 \to 8$) to ($3 \to X$) or ROP \ref{['lab:code reuse attacks']} to achieve ($3 \to 2$). Line 4 has a 'pure DOP vulnerability' \ref{['attack:dop']} if the argument to broadcast() can be influenced.
• Figure 2: X86-64 assembly examples of control-flow transfers.
• Figure 3: Knowledge areas of state-of-the-art control-flow attestation schemes.
• Figure 4: The C-FLAT system model: an example of an interactive CFA scheme cflat.
• Figure 5: LightHAX: a uni-directional CFA scheme LiteHAX.

Theorems & Definitions (3)

• Definition 1.1: Verifier and Target
• Definition 1.2: Attestation and Verification
• Definition 1.3: Measurement