A Runtime Decentralized Attestation and Coordinated Repair Framework for Securing Automotive ECUs

The paper introduces DACER, a runtime decentralized attestation and coordinated repair framework for securing automotive ECUs. The abstract states: DACER is the first approach that co-designs attestation and repair to unify the 'local' nature of firmware rollback with the 'global' nature of ECU reboot. The framework addresses the challenge of malware injection into ECUs, which threatens vehicle safety.

The paper explains the fundamental challenge: A fundamental challenge not addressed by all previous works is to unify local rollback with the external context-aware reboot. The key insight is that locally enforced rollback can be unified with external context-aware reboot by externalizing self-attestation results. Within each ECU, a failed attestation result triggers timely local rollback, and the externalized results provide other in-vehicle computers with a reliable view of the ECU state, which can be used to coordinate reboot timing with contextual awareness.

DACER consists of two main components: 1) a horizontal decentralized attestation that identifies malicious ECUs, and 2) a vertical coordinated repair that enables restoration of compromised ECUs at runtime. In the decentralized attestation component, "each of the individual ECUs performs self-attestation locally, and, meanwhile, they coordinate using a trusted execution environment (which also performs self-attestation) to verify whether each local self-attestation state is valid or not. This is efficient because the coordinated verification checks only the self-attestation status (which is small in size compared to the ECU firmware image), each decentralized attestation can be performed in constant time and requires only a constant persistent state per node. Additionally, all ECUs can be verifiers, achieving robustness against node failure."

The coordinated repair component uses vehicle-wide integrity information produced through decentralized attestation to guide repair. While local rollback can restore benign firmware on external storage, rebooting an ECU during runtime may be unsafe. Therefore, DACER securely propagates the attestation results 'up' to the main controller, which uses its broader view of the vehicle state to determine a safe time to initiate the reboot. Since intermediate nodes may be compromised, DACER applies decentralized attestation across all layers, ensuring that compromised intermediate nodes can be detected and repaired.

The paper's contributions are: (i) designing the first framework that integrates detection and repair components to address malware injection attacks on ECUs, complies with critical vehicle constraints during runtime, and resists single points of failure; (ii) introducing a new decentralized attestation through which ECUs mutually check reliable firmware state information produced by self-attestation, informing a coordinated repair mechanism that utilizes the hierarchical nature of the vehicle computing architecture with vertical coordination between ECUs and the main controller for reboot timing decisions; and (iii) implementing a prototype of DACER on real-world embedded systems and evaluating its performance.

The system model considers a 3-layer architecture: Layer 3 contains only the main controller (MC), Layer 2 contains m zone controllers, and Layer 1 contains ECUs partitioned into m disjoint zones. A horizontal domain is defined as a group of peers that can communicate directly. The internal architecture of each in-vehicle computer includes a processor with TrustZone enabled, RAM, and flash memory managed by a flash memory controller (FMC) that runs secure firmware isolated from the host OS.

The decentralized attestation protocol works as follows: a random node is periodically challenged and any node in the domain can verify this response. The protocol decouples decentralized attestation from firmware measurement, which is performed only by probabilistic self-attestation. The challenged ECU's TrustZone releases a secret verifiable 'challenge value' only when its self-attestation state is valid. This value depends only on per-challenge state derived from the shared domain key, enabling any node to verify any other node with constant storage. Challenges are generated locally by TApp in each node using Algorithm 1, which determines the challenged node, verifier set, and challenge value from shared secrets.

For coordinated repair, when malware is detected via decentralized attestation, the verifier nodes will propagate an invalid attestation report 'up' to MC, which can orchestrate a safe reboot of the target ECU. TApp computes a MAC over the invalid attestation report to prevent forgery. The report is forwarded through the parent node, and MC verifies it and makes a decision about when to safely reboot the compromised node based on rich contextual information.

The security analysis covers false positives, false negatives, and eventual recovery. For false positives, the probability is bounded by 1 - ∏ Pr[Dk Γ] for ζ malicious verifiers. For false negatives, when a compromised node is challenged and at least one verifier is benign, the round reports the node as valid with probability at most 1 - Pr[D Γ]. For eventual recovery, "in the worst case, all in-vehicle computers are compromised. By Assumption 3, the vehicle operator can reboot MC. After being restored, MC verifies and repairs the zone controllers. Then, the benign zone controllers will verify ECUs and help repair them."

The implementation uses 6 Raspberry Pi nodes (four Pi 3B+ and two Pi 3B) with TrustZone enabled, communicating over CAN bus via RS485 CAN hats. TApp was implemented in the ARM TrustZone secure world using OP-TEE, and FMC was implemented on an LPC-H3131 development board with OpenNFM NAND flash manager.

Experimental results show: self-attestation setup takes up to 5.720 seconds for a 400KiB firmware image (one-time cost), while regular self-attestation operations are very quick (17.9-39.9 ms). Self-repair notification takes 2.3 ms and rollback takes 1,315.5 ms. Decentralized attestation operations are very fast: challenge generation takes 14.5 ms, response generation 7.7 ms, and proof verification 7.8 ms. The flash storage throughput comparison shows DACER largely maintains baseline performance, with RW throughput at-4.6% relative to original, RR improving by +5.0%, and SW and SR effectively unchanged.

The paper also discusses context-aware reboot policy, noting that the reboot timing depends heavily on the specific ECU being repaired and that by decoupling the repair mechanism from the reboot policy, our design allows manufacturers to implement various strategies. It also presents an application to VANET security and discusses challenging multiple nodes to improve repair time. The mean time to repair (MTTR) analysis shows Layer 1 MTTR of 41.16 seconds, Layer 2 of 9.08 seconds, and Layer 3 of 2.07 seconds under baseline parameters, with close agreement between analytical and Monte Carlo simulation results.

Improvements to AI Systems Based on DACER:

1. Context-Aware Runtime Self-Healing for AI Agents: Integrate DACER’s “vertical” coordinated repair into AI agents deployed in safety-critical environments (e.g., autonomous driving, robotics). The AI system can continuously self-attest its model/firmware integrity, and when a compromise is detected, it can defer its own reboot/rollback until a central coordinator (e.g., a mission controller) confirms that the environment is safe for downtime—preventing unsafe interruptions during active tasks.

2. Decentralized Trust Verification for Multi-Agent AI Networks: Apply DACER’s horizontal attestation protocol to AI systems running on distributed edge nodes. Each AI agent can locally verify its own state (via a trusted execution environment) and share only small, verifiable status tokens with peers. This enables constant-time, low-overhead mutual verification of AI agents without transmitting large model weights, ensuring robustness against node failures and single points of compromise.

3. Hierarchical Anomaly Reporting and Coordinated Recovery in AI Pipelines: Use DACER’s layered architecture (ECUs → zone controllers → main controller) to design AI systems with hierarchical monitoring. Lower-level AI components report integrity failures upward, and a high-level AI orchestrator uses global context (e.g., task priorities, resource availability) to schedule safe recovery actions, minimizing disruption while ensuring eventual system-wide restoration.

4. Efficient Challenge-Response Integrity Checks for AI Models: Implement DACER’s challenge-based verification (where a secret verifiable value is released only if self-attestation is valid) to periodically validate AI model integrity in production. This allows any node in a network to verify any other node’s model state with constant storage and time, making it scalable for large AI deployments without re-hashing entire models.

5. Resilient AI Systems with Eventual Recovery Guarantees: Incorporate DACER’s security analysis (bounded false positives/negatives and eventual recovery) into AI system design. Even if all AI nodes are compromised, the system can be manually rebooted at the highest level, then systematically repair lower levels—ensuring that AI services recover to a benign state without requiring simultaneous global reset.

6. Context-Aware Reboot Policies for AI Services: Decouple the repair mechanism from the reboot policy, as DACER does, to allow AI systems to implement manufacturer-defined strategies. For example, an AI service can delay its own rollback until a safe checkpoint (e.g., no active user interactions, no critical computations) is reached, reducing operational risk.

7. Low-Overhead Integrity Monitoring for AI on Embedded Hardware: Leverage DACER’s performance metrics (e.g., 7.8 ms proof verification, 14.5 ms challenge generation) to design AI integrity checks that run in real-time on resource-constrained devices, enabling continuous monitoring without degrading AI inference throughput (as shown by only-4.6% write throughput impact).

What the Improved AI System Can Do:

• Detect and recover from malware or model tampering in real time, without halting operations unless safe.

• Operate in decentralized networks where peers mutually verify integrity with minimal bandwidth and storage.

• Automatically coordinate recovery across hierarchical AI components, using global context to choose optimal reboot times.

• Guarantee eventual restoration to a trusted state even under total compromise, via manual top-level reboot.

• Run on embedded hardware with negligible performance loss, suitable for automotive, industrial, and IoT AI applications.