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

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

Niusen Chen

Bo Chen

arXiv:2608.11489v1 [cs.CR] 11 Aug 2026

Department of Computer Science Department of Computer Science and Engineering Department of Computer Science Michigan Technological University University of Nevada, Reno Michigan Technological University Houghton, Michigan, USA Reno, Nevada, USA Houghton, Michigan, USA bchen@mtu.edu niusenc@unr.edu jwdafoe@mtu.edu

demonstrated that ECU programmability can often be enabled without proper authentication [22], [24], and the attacker can utilize such vulnerabilities to inject malware into vehicle ECUs in the real world [32], [36]. Defending against malware injection attacks on ECUs requires mechanisms that can both detect compromised ECU firmware and repair it. Importantly, the detection and repair components should be highly integrated because: 1) the repair component needs to be triggered by the detection component, which requires communicating malware detection results to the repair component despite disrupted communications due to compromised firmware, and 2) the repair component should return the compromised ECU to a state that can be verified by the detection component. Why is it challenging to integrate the two components in vehicles? The runtime ECU firmware repair can be decomposed into rollback and reboot: rollback is a restoration of the previous benign firmware in the flash storage, while reboot removes the malware from volatile memory and loads the restored benign firmware. Hence, a reboot should always be performed after the rollback. Fundamentally, the rollback is a local operation performed by the flash storage of each individual ECU [13]. Therefore, it does not immediately disrupt ECU functionality and can be performed promptly after detecting malware. Unlike rollback, rebooting an ECU temporarily disrupts its functionality, which can be dangerous depending on the current situation of the vehicle, e.g., rebooting a brake controller during driving should be avoided. Therefore, a reboot decision cannot be made locally and requires a broader vehicle context (i.e., a context-aware reboot). A typical detection mechanism is firmware attestation 1 which can be broadly categorized as self-attestation and remote-attestation. We argue that regardless of which detection strategy is used, integrating both detection and repair components to meet critical vehicle constraints is always challenging: Strategy I: self-attestation. In this strategy, each ECU has a trust anchor (e.g. a bootloader loaded from ROM or a trusted execution environment) internally, which will perform

Abstract—The evolution of automotive technology increasingly integrates components, transforming vehicles into interconnected systems of systems. Modern vehicles are controlled by a distributed system of computing devices, known as electronic control units (ECUs). However, this interconnectedness means that any error poses significant risks to the vehicle operator. In particular, malware can be injected into ECUs, threatening vehicle safety. To address this, we need mechanisms to detect compromised ECUs then repair them to a benign state. Existing approaches mainly focus on detection and do not address the challenge of integrating detection with runtime ECU repair. This integration is nontrivial because runtime repair involves both local rollback and reboot with timing determined from global vehicle context to avoid unsafe behavior. In this work, we have designed DACER, a runtime decentralized attestation and coordinated repair framework for automotive ECUs. 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. In DACER, each ECU performs efficient local self-attestation and self-repair functions, enabling low-overhead coordination for distributed operations. In addition, DACER takes advantage of the hierarchical vehicle computing architecture. Our resulting DACER design checks the entire state of the vehicle, resists single points of failure, conforms to real-time constraints, and enables firmware restoration during runtime. The key functions are enabled by the ARM TrustZone equipped within each ECU and the secure flash memory controller embedded in the storage device. We implemented DACER on real-world hardware and experimentally demonstrated its low overhead. Index Terms—autonomous vehicles, electronic control unit, malware, TrustZone, flash memory controller, attestation, repair.

I. I NTRODUCTION The modern vehicle is increasingly intelligent, with its functions (e.g., accelerating, braking, shifting gears) controlled by specialized computers known as electronic control units (ECUs). These ECUs are resource-constrained, low-power embedded systems that communicate over in-vehicle networks. The vehicle also has a main controller that acts as the “brain” of the entire vehicle. Increasingly, the main controller and ECUs are more complex in their software code base. For example, the software of a vehicle can contain up to 100 million lines of code [4]. This growing complexity of the software stack has created opportunities for various malware attacks on vehicles. One of the most significant being the injection of malware into vehicle ECUs: previous work has

1 Another approach is through intrusion detection [16], which does not directly verify firmware integrity and suffers from a few limitations, for example, malicious firmware that does not produce anomalous network behavior may remain undetected; in addition, a small false positive rate will incorrectly trigger frequent system restorations [17].

1

firmware verification. For a failing verification, it can invoke a local rollback during runtime [11], but it is hard to coordinate externally for the context-aware reboot due to the potential denial of service (DoS) attacks performed by malicious firmware that controls the network interface. Additionally, the existing self-attestation design inherently lacks robustness, as it may be disabled by a compromised or a failed ECU. Strategy II: remote-attestation. In this strategy, a remote entity is designated to verify the integrity of the individual ECU or the integrity of the entire vehicle, and this remote entity can be within the vehicle itself (e.g., a special ECU or multiple ECUs) or outside of the vehicle (e.g., another vehicle or an edge server). This strategy performs an explicit vehiclewide integrity check, making context-aware reboot possible. However, it cannot securely invoke the rollback that occurs locally in the compromised ECU due to the potential DoS attack from the malicious firmware. How to integrate the two components while meeting vehicle-specific constraints? A fundamental challenge not addressed by all previous works is to unify local rollback with the external context-aware reboot. To address this challenge, we have proposed DACER, a Decentralized Attestation and Coordinated ECU Repair framework for autonomous vehicles. Our 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. Thus, the externalized results provide other in-vehicle computers with a reliable view of the ECU state. This information can be used to coordinate the reboot timing among in-vehicle computers with contextual awareness. As a result, DACER can resolve the shortcomings of the existing approaches [2], [11], [14], [20], [21], [30], [33], [34] by simultaneously i) complying with strict realtime constraints in the vehicle, ii) verifying the state of the software of the entire vehicle, iii) remaining robust to single point failure for malware detection, and iv) supporting the safe automatic runtime restoration of compromised ECUs. DACER consists mainly of two 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. 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. This low overhead is crucial for the vehicle context which has strict realtime constraints [9]. 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 [3], [7]. 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. Contributions. Our contributions are summarized below: (i) We have designed the first framework that 1) integrates detection and repair components to address malware injection attacks on ECUs, 2) complies with the critical constraints of vehicles during runtime, and 3) resists against single points of failure. (ii) We have introduced a new decentralized attestation through which the ECUs mutually check the reliable firmware state information produced by self-attestation. Then, these results inform our coordinated repair mechanism, in which we utilize the hierarchical nature of the vehicle computing architecture, introducing “vertical” coordination between the ECUs and the main controller to make informed decisions on the reboot timing. (iii) We have implemented a prototype of DACER in realworld embedded systems and evaluated its performance. II. BACKGROUND ARM TrustZone (TZ). In automotive platforms, in-vehicle computers commonly use ARM-based processors (e.g., Cortex-A and Cortex-M families) [28], [29], where TrustZone support is widely available [5], [6]. TrustZone is a trusted execution environment (TEE) that isolates protected application data and instructions from the untrusted system at the hardware level. In TrustZone, the protected environment is known as the secure world, in which trusted applications are isolated at the hardware level, while the unprotected environment is known as the normal world, which runs the normal host OS. The TrustZone hardware enforces that the normal world cannot access the isolated memory of the secure world, but the secure world can access both normal and isolated memory. A TrustZone-based application is commonly structured as a trusted component (TApp) running in the secure world and an accompanying untrusted component (UApp) running in the normal world that mediates interaction with the rest of the system. Calls into the TApp are typically initiated by UApp via a narrow predefined interface (i.e., an SMC instruction). TrustZone also typically supports a mechanism to store secrets that must persist over time (e.g., cryptographic keys) with confidentiality and integrity. In-Vehicle computing architecture. Electronic control units (ECUs) are low-power embedded systems that run real-time operating systems. Physically connected ECUs communicate directly over a shared CAN bus, which is a broadcast based communication bus. The groups of ECUs are known as zones and each zone is managed by a zone controller. Zone controllers typically have more powerful computing hardware and manage the information flow with the rest of the vehicle.

2

Zone controllers typically communicate with each other and a main controller using Ethernet. The main controller synthesizes information and makes high-level control decisions. The control signals are then passed to the correct ECUs through the respective zone controller. Self-attestation and self-repair. Self-attestation enables a trusted entity within a node to verify software integrity. While traditional secure boot relies on a secure bootloader or TPM check a cryptographic signature over the entire firmware before booting, the strict real-time in-vehicle constraints make this impractical: ECUs are typically required to boot within 50–100 ms [20], [33]. Thus, we focus on probabilistic selfattestation schemes which reduce the auditing time significantly, although detecting corruptions with higher probability requires multiple attestations over time. The trusted component (e.g. an HSM or TEE) achieves this by creating unique challenges on the firmware image, each one corresponding to a fixed-length subset of the firmware [11], [18], [26]. In this paper, we model the behavior of a probabilistic self-attestation scheme over time by using an epoch time TSA in which exactly one self-attestation is performed, and an associated probability function Pr[D | Γ] denoting the probability that corruption is detected in a given attestation, where Γ refers to system states (i.e., the proportion of the firmware image that has been modified, the number of attestations already performed, etc.). Self-repair enables the results from an attestation to transition the ECU storage into a “repaired” state. Previous work proposes a protocol between TrustZone and trusted local storage hardware, allowing an invalid self-attestation result to trigger rollback by a storage controller that maintains the previous benign firmware [10]. Notably, this mechanism ensures rollback to the most recent benign firmware upon either (i) an invalid self-attestation result or (ii) denial of service attacks performed by a Dolev-Yao adversary on the channel between the trusted component and the storage device. In practice, rollback can be achieved using the out-of-place update feature inherent in flash memory storage [10], [13] or using a dual-bank update design [27].

Fig. 1: System model overview. The dotted sections represent horizontal domains. The ECUs within a zone are interconnected by CAN bus, and the zone controllers and the main controller are interconnected by Ethernet cable. Note that each zone controller is part of two domains, and acts as a communication gateway between the ECUs and MC.

Fig. 2: The internal architecture of an in-vehicle computing node (ECU, zone controller, or main controller). parent zone controller). We use Ddℓ to denote the dth horizontal domain associated with layer ℓ. In our three-layer architecture, 1 Layer 1 has m horizontal domains, D11 , . . . , Dm , where each domain consists of the ECUs in one zone together with their zone controller. Layer 2 has a single horizontal domain, D12 , consisting of all m zone controllers and MC. Our design can be easily extended to support additional layers. The internal architecture of an in-vehicle computer is shown in Figure 2, which is a typical computing system equipped with a processor, RAM, and flash memory. Flash memory is managed by a flash memory controller (FMC) that runs secure firmware isolated from the host OS at the hardware level. Importantly, this secure firmware performs some mechanism sufficient to enable a self-repair primitive [11], [27]. Additionally, each processor is enabled with TrustZone 2 . In the secure world, a trusted application (TApp) is running, and in the normal world, an untrusted application (UApp) is running. Unlike TApp, which is isolated in the secure world, UApp which runs on the host OS can directly access the FMC read/write interface and the network controllers (i.e. CAN controller or Ethernet controller). Therefore, communications

III. M ODELS AND A SSUMPTIONS System model. We consider a modern vehicle following a layered architecture (§ II). Specifically, we consider 3 layers, each consisting of one or more in-vehicle computers (Figure 1). Layer 3 contains only the main controller (MC). Layer 2, in turn, contains m zone controllers, each acting as the parent node for a zone of ECUs. As such, each zone controller can communicate directly with all ECUs in its zones, other zone controllers, and the main controller. Then, the ECUs make up Layer 1 and are partitioned into m disjoint zones, each corresponding to a zone controller (each zone is managed by one zone controller). Within a zone, the ECUs can communicate directly, while the ECUs in different zones cannot communicate directly; this communication must be facilitated by the zone controllers. Importantly, we define a horizontal domain as a group of peers that can communicate directly (e.g. the ECUs in a single zone, along with their

2 Some in-vehicle computer (such as the main controller) may use a different TEE. Our design can be adapted if that TEE meets assumptions 2 and 3 in the “assumptions” of § III.

3

between TApp and any other component go through UApp 3 . For each domain, the manufacturer generates a key KDdℓ and counter γDdℓ and shares them between TApp in all nodes in the domain. Additionally, the local self-attestation and selfrepair functions may use a shared key between TApp and FMC (unique to each ECU). Unless otherwise noted, all counters are incremented after each use.

IV. DACER D ESIGN A. Design Overview DACER is organized into two primary functional components: decentralized attestation and coordinated repair. Decentralized attestation is a protocol for detecting malware in ECUs. Each ECU runs a local self-attestation, which allows other nodes to efficiently check the software integrity of the ECUs in their domain. Coordinated repair then leverages the self-attestation results to first perform local rollback, then uses the decentralized-attestation results to inform context-aware repair decisions on reboot timing of the target nodes, enabling safe restoration at runtime. To enable external awareness of an ECU’s firmware integrity, DACER performs a decentralized attestation, in which the nodes in a domain collaborate to verify each other’s firmware integrity. An immediate solution is to directly employ traditional remote-attestation, where each node directly verifies a cryptographic proof. However, this is expensive as it requires computation over the entire firmware image to generate a proof, and maintaining per-node state information (e.g. hashes) to verify. More importantly, traditional remote-attestation only enables external verification of firmware integrity. Because the verification result is produced outside the compromised ECU, it cannot reliably trigger the local firmware rollback needed for runtime repair. DACER unifies the local nature of rollback and distributed nature of reboot by adopting a probabilistic self-attestation primitive on each ECU, and developing a decentralized-attestation protocol for externalizing the selfattestation results. To achieve this, we leverage TrustZone as the trusted component responsible for both local selfattestation verification and decentralized coordination among nodes within the same domain. Our decentralized-attestation protocol enforces that nodes are periodically challenged to report their state to a set of verifiers. After self-attestation results trigger rollback via self-repair, the ECU needs to be rebooted in a timely manner. If at least one verifier in the decentralized-attestation protocol is benign, then the coordinated-repair can be initialized (see § V). While the latest benign firmware has already been restored to local storage, the code executing from RAM remains malicious until it reboots. The coordinated repair helps ensure that this reboot is safe and secure. Specifically, the reboot timing should not be decided locally, as there is limited contextual information and a runtime reboot is not always safe [3]. For example, the vehicle may attempt to stop while the brake controller is rebooting, causing a collision. We propose that the decision about when to reboot a malicious ECU for repair should be propagated “up” to MC, which has the necessary contextual information and computational capabilities to determine a safe reboot window. Importantly, while the decentralized attestation is “horizontal” within a domain, the coordinated repair is “vertical”, since the reboot signal is initiated above the target node. However, this vertical approach introduces a dependency on the parent zone controller, since the communication path used to repair an ECU must remain reliable. We address this

Adversarial model. An attacker may compromise the firmware of any ECU. In particular, if the adversary can gain access to the in-vehicle network (e.g., through OTA update paths, diagnostic tooling, compromised OBD-II devices, or compromised mobile phones [8]), they may invoke the ECU’s reprogramming mode and install malicious firmware. Note that we only consider an attacker that aims to establish persistence, and so we consider the malware which is committed to flash memory. This injected malware may disrupt the ECU function or send malicious control messages over the CAN bus. Furthermore, since UApp mediates all communication between TApp and FMC, and between TApp and the CAN bus, a malicious UApp may perform man-in-the-middle (MITM) attacks on these communication channels. We model this as a Dolev-Yao-style adversary, positioned between TApp and both the FMC and the network interfaces. This adversary can observe, forge, modify, delay, or drop messages on these channels. Additionally, there may be malware on any invehicle computer. Assumptions. Our design relies on a few assumptions: 1) The TrustZone is secure (i.e. TApp is trusted). This is a common assumption in secure designs that rely on secure hardware [13]. Hardening TrustZone security itself has been actively investigated in the literature [37], and is beyond our scope. In addition, the FMC is secure (i.e. FMC is trusted). This assumption can be realized, since i) the FMC firmware is stored in ROM or can be measured via secure boot, and ii) is isolated by the flash storage hardware, which offers a limited read/write interface to the host OS. 2) For each domain, TApp on the associated parent controller is equipped with a secure mechanism to send a reboot signal to each computer in its domain. A “secure” mechanism to send a reboot signal is defined as a signal that can be sent only by the TApp, guaranteeing that the target ECU will reboot. This mechanism can be implemented as a GPIO pin on the parent, accessible only by TApp [35], which is connected to the reset pin of the target ECU. 3) There is a direct physical communication interface between the vehicle operator and TApp in MC. This interface can be implemented through GPIO pins [35] that are only accessible to TApp in MC. 4) The clocks of all in-vehicle computers maintain adequate synchronization using standard automotive network protocols [1].

3 Another option is to add storage/network driver functionality into TApp. However, this would not be practical because it 1) requires significant implementation effort, and 2) increases the overall memory footprint, which is expensive for the resource-constrained ECUs.

4

problem by applying DACER at multiple layers. Specifically, the zone controllers participate in a horizontal domain with MC, allowing malicious zone controllers to be detected by their peers and directly repaired by MC. Recovery of MC itself relies on Assumption 3. Then, once the zone controllers are repaired, they can correctly forward the detection alert to further repair the ECUs.

Algorithm 1 Decentralized Attestation Challenge Generation Require: Key K, counter γ, number of nodes m, number of verifiers v, response length l, current node index i. Ensure: Role of current node R, challenge value C (if applicable), challenged node index p, verifier indices V . 1: procedure G ENERATE C HALLENGE(K, γ, m, v, l, i) 2: p ← g(K, γ, ⌈log2 m⌉) mod m 3: V ←∅ 4: for t ← 0 v − 1 do 5: k ← g(K, γ, ⌈log2 m⌉) mod m 6: V.append(k) 7: end for 8: C ← g(K, γ, l) 9: if i = p then 10: return (Challenged, C, p, V ) 11: else if i ∈ V then 12: return (Verifier, C, p, V ) 13: else 14: return (None, C, p, V ) 15: end if 16: end procedure

B. Decentralized Attestation To properly update a target ECU, an external entity should initiate a reprogramming mode. Importantly, the reprogramming mode typically allows arbitrary manipulation of the ECU firmware. The reprogramming mode is entered over CAN through a protocol like Unified Diagnostic Services (UDS). This update mechanism may be compromised by an attacker, who may upload malware to an ECU [12], [22], [24]. Therefore, it is necessary to check whether the firmware running on a given ECU is provided by a valid software distributor (such as the OEM). While self-attestation can perform this check locally, coordinated repair requires that result to be visible to other in-vehicle computers. To externalize this local integrity state, DACER leverages decentralized attestation among nodes in the same horizontal domain. Within each domain, a random node is periodically challenged and any node in the domain can verify this response. The remaining challenge is how a node can externally verify the local self-attestation state of another node without performing the expensive firmware measurement used by traditional remote-attestation. To address this challenge, we decouple the decentralized attestation protocol from firmware measurement. This firmware measurement is performed only by probabilistic self-attestation. Then, a decentralized attestation is reduced to verifiers asking the question: have all local self-attestations on the challenged ECU returned valid results since the last reboot? To answer this question, the challenged ECU TrustZone releases a secret verifiable “challenge value” only when its self-attestation state is valid. Importantly, this value depends only on per-challenge state derived from the shared domain key (KDdℓ ), not on any per-ECU firmware measurement. This information is independent of the ECU being challenged and enables any node in a domain to verify any other node with constant storage regardless of the domain’s size. The remainder of this section describes our protocol for secure verification of this information. Similarly to self-attestation, decentralized attestation challenges are issued periodically. Due to the substantial difference in computing power between in-vehicle computers at different layers, we may desire different epoch lengths for different layers. We define Tℓ as the time length of a decentralized attestation epoch in domains at layer ℓ. In our protocol, periodic challenges are generated locally by TApp in each node. This eliminates any communication and coordination overhead associated with distributing challenges and agreeing on challenge parameters for each epoch. During each epoch, one node is challenged (this may be extended to more nodes, as discussed in § V) by one or more verifiers, and the challenge

Algorithm 1: Decentralized Attestation Challenge Generation. Each invocation of g increments γ (i.e., γ ← γ + 1), so that all nodes have the same input, and derive identical (p, V, C) without coordination. When constructing V , duplicates are removed and resampled, and the challenged ID p is excluded. Additionally, only nodes with roles Challenged or Verifier use C (others may compute and discard it to preserve γ synchronization). consists of (i) the challenged node ID, (ii) a set of verifier IDs, and (iii) the challenge value. Based on (i) and (ii), TApp in the challenged node and verifier peers can identify themselves and respond appropriately. The purpose of (iii) is to act as a secret per-challenge value that only the trusted component in each node can produce. To generate challenges, respond to them, and verify the response, we rely on a few secrets shared between the TApps. In each domain, we rely on the key KDdℓ and counter γDdℓ shared between TApp in each node in the domain. In addition, we define l, which is a global security parameter, and vdℓ which is the number of verifiers per epoch in a given domain. Importantly, the above shared secrets constitute the only state which needs to be maintained in each in-vehicle computer to achieve the decentralized attestation (enabling mutual verification with constant per-node state, avoiding the pairwise state of alternative designs). In addition, we define a pseudo random function with variable output length, g : {0, 1}κ × {0, 1}∗ × N → {0, 1}∗ such that for every key K ∈ {0, 1}κ , input x ∈ {0, 1}∗ , and length L ∈ N, we have g(K, x, L) ∈ {0, 1}L . The details of challenge generation procedure are presented in Algorithm 1. At the beginning of each epoch, every node will run

5

. Importantly, the counter γDdℓ referenced in this section is not incremented during the generation or verification of these messages. This is because this computation takes place only within a subset of the verifier nodes for this epoch, and incrementing γDdℓ would create an inconsistency across nodes. This is justified since the message is bound to the current γDdℓ value, which will be advanced during the next synchronized challenge generation step (i.e., at the next epoch transition). Replays within the same epoch can be suppressed by deduplicating reports per target node at the receiver TApp (e.g., MC). M will then be sent, through UApp, to the parent node. A benign parent node will definitely forward this to TApp, but a compromised parent may drop M . If the parent is not MC, then M , in this form, cannot be verified by MC, since MC is not in the same domain as the target ECU. Therefore, MC does not have access to KDdℓ or γDdℓ . However, MC is in the same domain as the zone controller, and so the zone controller can generate a new MAC, and forward this to MC. Then, TApp in MC will verify M , and make a decision about when to safely reboot the compromised node, based on the rich contextual information available only to MC. When the decision is made to reboot the compromised node, this signal is propagated down, which is feasible by our assumption 2. Importantly, while a zone controller may contain malware at some time (breaking the dependency chain for coordinated repair), assumption 3 ensures that MC can always be repaired, which can eventually repair the zone controllers.

Algorithm 1, with the correct input associated with its domain. This is used for TApp in each node to 1) generate the challenge value C, and 2) determine whether the given node is challenged, is a verifier, or neither. The decentralizedattestation protocol works as follows: First, in the challenged node, TApp reveals the challenge value C to UApp if and only if the node’s local self-attestation state is valid. UApp is then expected to broadcast C to the verifier nodes. However, since UApp is untrusted, it broadcasts some value C ′ , which may differ from C either because UApp never received C, or because UApp tampered with it. Note that, since self-attestation is probabilistic, there is a small probability (i.e. 1 − P r[D | Γ]) that the challenged node is compromised, yet UApp received C. Then, each verifier node’s UApp either receives some value C ′ or receives no response before the timeout. If a value is received, the verifier’s UApp forwards it to its local TApp. Since the verifier’s UApp is also untrusted, it may forward some value C ′′ (which may or may not equal C ′ ) instead. Finally, the verifier TApp compares C ′′ with the challenge value C that it independently generated. If C ′′ equals C, then the challenged node is considered valid for that epoch. Otherwise, either the challenged node failed to produce the correct response, or the verifier’s UApp is malicious and manipulated C ′ . To distinguish these cases, the verifier TApp checks its own self-attestation state. If the verifier has failed any self-attestations, it cannot conclude that the challenged node definitely contains malware, and therefore suppresses the report. If the verifier’s self-attestation state is valid, then the challenged node has malware unless the verifier is itself compromised and undetected, which occurs with probability at most 1 − Pr[D | Γ]. The verifier TApp therefore generates an invalid attestation report.

V. A NALYSIS AND D ISCUSSION A. Security Analysis To analyze the security of decentralized attestation, we consider false positives, false negatives, and eventual recovery in the worst case. A more detailed security analysis including a derivation of the mean time to repair is given in § B. For false positives, we observe that this can only occur when C ′ = C and C ′′ ̸= C for some verifier ECU. In addition, this ECU will only generate a false positive if it has not failed any self-attestations. Given ζ malicious verifiers, where the malware in verifier k is independently detected via spotchecking with probability Pr[Dk | Γ], the probability that at least one has not failed its self-attestation is given by

C. Coordinated Repair Upon external detection of malware via decentralized attestation, it is highly likely that the challenged node has failed its internal self-attestation, as analyzed in § V. Consequently, a rollback has been performed (or is imminent § II). However, as previously mentioned, this rollback only addresses persistent storage, and the malware remains active in the node’s volatile memory. Therefore, a safe and timely reboot is required. To achieve this, the verifier nodes will propagate an invalid attestation report “up” to MC, which can orchestrate a safe reboot of the target ECU. The first challenge towards propagating this attestation report is that, in malicious nodes, the adversary may manipulate communications between TApp and the CAN bus. Since UApp can simply drop the invalid attestation report, we can only assure that benign peers will actually propagate the message. Therefore, ruling out false-negatives requires a benign node to be part of the verifier set. The remaining challenge is to prevent the adversary from forging false positives. To achieve this, TApp computes a MAC over the invalid attestation report, by generating

ℓ

1−

ζd Y

Pr[Dk | Γ].

k=1

In the worst case, where every malicious ECU manipulates the challenge value, this corresponds to the probability of a false positive. 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 1−P r[D | Γ]: given that the challenged node contains malware, TApp will not reveal the value C to its associated UApp if any self-attestation has produced invalid results, with probability P r[D | Γ]. Given that there

M = “invalid”||g(KDdℓ , γDdℓ ||p||“invalid”, l)

6

is a benign verifier, a false negative occurs only when selfattestation misses the malware, so its probability is 1−P r[D | Γ]. Note that such a round does not prevent later detection, as the node remains subject to future self and decentralized attestations. For eventual recovery, we have established that a node failing local self-attestation is detected when it is selected as the challenged node and a selected verifier is benign. 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.

Fig. 3: Left: the 6-node Raspberry Pi 3/3B+ testbed connected through a CAN bus. Right: A Raspberry Pi attached to an LPC-H3131 development board used as flash storage.

B. Discussion Context-aware reboot policy. While coordinated repair provides the mechanism to initiate a reboot, the logic for when MC should issue that signal remains an open challenge. In Level 4 or 5 autonomous vehicles, this decision may mostly be automated, so that the vehicle smartly schedules reboot or drives into a safe state before rebooting the target node. In lower levels of automation, MC might simply notify the driver in all cases, so that they can pull over before manually issuing a reboot command. Further, the reboot timing depends heavily on the specific ECU being repaired [3]. While non-critical ECUs may reboot during runtime with low risk, safety-critical ECUs require a more complex decision. Importantly, by decoupling the repair mechanism from the reboot policy, our design allows manufacturers to implement various strategies. An application to VANET security. Vehicular ad hoc networks (VANETs) enable V2V and V2I communications, but malicious code injection can cause compromised vehicles to mislead not only the impacted vehicle but also the entire VANET. Previous VANET security solutions [15], [17], [31] propose computing a signature on the entire software on each vehicle computer or blockchain based consensus mechanisms. However, these strategies are expensive and can violate the real-time requirements of the vehicle. A slight modification of DACER can efficiently enable secure participation in VANETs. Specifically, an external entity may simply perform remote-attestation with TApp in MC, and obtain, through a secure channel, a view of the entire vehicle software integrity. The layered approach of our solution becomes analogous to the merkle tree used by other approaches [17], [31]. Challenging multiple nodes. To significantly improve repair time, we introduce aℓ , which is the number of nodes challenged in layer ℓ during each decentralized-attestation epoch. This requires two small modifications of DACER: 1) Algorithm 1 generates aℓ challenged node IDs and their respective challenge responses. 2) Each verifier validates all aℓ challenged nodes. The significant impact of aℓ on the mean time to repair is shown in Table VI.

our implementation, we simulate 6 ECUs using Raspberry Pi, where four ECUs are simulated using Pi 3B+, and two are Pi 3B (with a 1.2GHz (3B+ is 1.4GHz) 64-bit quad-core ARM Cortex-A53 CPU, and 1GB LPDDR2 SDRAM) with TrustZone enabled. Communication between nodes is implemented using the RS485 CAN hat, which supports CAN 2.0. We implemented UApp under our modification of the standard OP-TEE (Open Portable Trusted Execution Environment) OS installation. We implemented TApp in the ARM TrustZone secure world. For our self-attestation and self-repair schemes, we used the constructions from [11]. FMC was implemented on a USB 2.0 header development board LPC-H3131 (with ARM9 32-bit RM 926EJ-S, 180Mhz, 32MB of SDRAM and 512MB of NAND flash). We have ported the OpenNFM open source NAND flash manager to LPC-H3131 and modified it for our FMC implementation. B. Experimental Evaluation In addition to implementing DACER, we have performed an experimental analysis to evaluate the cost. For self-attestation, our experimental results are summarized in Table I. There is a setup phase, which consists of first verifying a signature over the entire firmware image, then, if this is valid, generating verification tags over each block. Immediately, we notice that this is the most expensive operation in our design, taking up to 5.720 seconds to initialize a 400KiB firmware image. This high cost is expected due to the use of expensive cryptographic operations performed in the TrustZone. This high cost justifies our design choice to run this operation in the parent node, where far more computational power is available than a basic ECU. Additionally, we note that this operation only occurs once and therefore will not impact normal vehicle behavior. In contrast, the regular self-attestation operations (i.e. Challenge generation, proof generation, and proof verification) are very quick due to the spot-checking technique used by [11], allowing runtime self-attestation to meet the real-time invehicle requirement. Additionally, we see that the costs of the attestation-phase scale roughly linearly with the size of the data challenged. For self-repair, our experimental results are summarized in Table II. There are two dedicated operations for self-

VI. I MPLEMENTATION AND E VALUATION A. Implementation To demonstrate the feasibility of our design, we have implemented DACER on real-world computing hardware. In

7

Procedure

Component

Setup (one time)

Parent Node TApp

Challenge Generation

TApp

Proof Generation

UApp

Proof Verification

TApp

Size 200KiB 400KiB 100KiB 200KiB 100KiB 200KiB 100KiB 200KiB

Time (ms) 3,996 5,720 17.9 21.2 19.2 39.9 23.8 31.6

Procedure Challenge Generation Response Generation Proof Verification

Component FMC FMC

Time (ms) 14.5 7.7 7.8

TABLE III: Run time for the Decentralized-Attestation phases. The time for challenge generation depends on |Ddℓ | and vdℓ . The time for response generation and proof verification depend only on the security parameter l.

TABLE I: Runtime for the Self-Attestation phases with different sizes. For the Setup phase, the size considered is the full data size. For the Attestation phase, (including challenge generation, proof generation, and proof verification) the size considered is the size of the challenged data (i.e. c · |bi |). Procedure Notification Rollback (Mapping Restoration)

Component TApp TApp TApp

System OpenNFM DACER

RW 1723 1644

RR 2029 2130

SW 2223 2221

SR 2763 2779

TABLE IV: Throughput comparison between DACER and original OpenNFM. Throughput is reported in KiB/s.

Time (ms) 2.3 1,315.5

unchanged. These differences are small (≤ 5%) and may fall within typical run-to-run variability; additionally, a slight write speed reduction is expected due to the extra work to maintain the backup mapping table.

TABLE II: Run time for the Self-Repair phases. The rollback operation restores the entire storage available in LPC-H3131. Note that the throughput is limited by the old USB 2.0 interface used between the LPC-H3131 and Raspberry Pi.

VII. R ELATED W ORK A. In-vehicle ECU Firmware Attestation

repair: Notification and Rollback, both implemented in FMC. The notification consists of simply reading a value stored at a special address, generating a corresponding value, and checking whether they match. This is a very simple operation and so has the lowest cost among the operations in our design. Importantly, this is a periodic operation, and so the negligible cost demonstrates that the notification will not interfere with regular storage operations. In contrast, the rollback operation is far more expensive, but occurs only when malware is present, in order to restore the latest benign firmware. However, only the mappings need to be reverted to restore the entire data. For decentralized attestation, our experimental results are summarized in Table III. Our immediate observation is that these operations are very fast and incur a very small cost on top of the self-attestation, while increasing the overall security dramatically. Challenge generation and response generation both consist of simply generating random values from shared secrets. However, challenge generation is run on all nodes, while response generation is performed only by the challenged node and selected verifiers (challenge generation simply determines the role of each node). Given this fact, and the marginally higher runtime of challenge generation, it is by far the most expensive operation in decentralized attestation. However, since we observe that it only takes 14.5ms, the cost is still quite small. Performance impact on the flash storage. In addition to implementing notification as a regular operation on FMC, we modified the garbage collection policy, and explicitly maintain a backup mapping table. To evaluate the impact of these changes on regular storage operations, we have measured the throughput of our modified version of OpenNFM with the original version. These results are summarized in Table IV. We observe that our design largely maintains baseline performance. The RW throughput is -4.6% relative to the original, while RR improves by +5.0%, and SW and SR are effectively

A few existing works use secure boot in automotive ECUs [2], [14], [34], checking the firmware image before boot. In particular, Gui et al. [14] propose using TPM to employ a core root of trust measurement, which computes HMAC digests on the firmware image at boot and compares them with a stored golden measurement. However, secure boot requires computing a signature on the entire firmware image, which is not scalable and generally cannot meet the 50 − 100ms boot time requirement [20], [33]. To mitigate this, Kim et al. [20] propose moving the application memory verification to the background (in an HSM) with prioritized blocks, allowing the ECUs to become operational before completing the complete software verification. Rogala [33] proposes performing secure boot at shutdown, essentially pre-verifying the firmware so that the strict boot-time requirement can be met. Although these solutions try to mitigate the cost associated with secure boot, they still suffer from checking the entire firmware image. Oguma et al. [30] propose using a dedicated master ECU to perform internal remote-attestation of other ECU’s firmware at vehicle startup. Similarly, Kohnhäuser et al. [21] rely on a master ECU to verify the firmware of other ECU’s. Their design requires verification of a pre-defined set of safetycritical ECUs before ignition is allowed. All the aforementioned designs suffer from a few common limitations: 1) they suffer from a single point of failure; and 2) they do not consider the hierarchical nature of the invehicle networks; and 3) they suffer from high computational overhead, since each ECU still needs to compute a hash over the entire firmware image; and 4) they do not integrate a repair component. SPARK [15] introduces a hierarchical swarm attestation that focuses on privacy preservation and allows external attestation for participation in VANETs. It can address the first and second limitations mentioned above, but it still suffers from the high computational cost resulting from hashing the entire firmware on each ECU. Other works [18],

8

[26] introduce various probabilistic self-attestation to meet the real-time requirement, but are still vulnerable to a single point of failure and do not integrate a repair component. Khodari et al. [19] introduced a decentralized firmware attestation design, in which each ECU can challenge any other ECU, as long as the valid signature (among other metadata) is stored in its local database. The challenged ECU will then generate a signature on the firmware image (using some trusted hardware extension) and transmit it to the verifier. Compared with DACER, their design suffers from a few limitations: 1) verifier storage grows linearly with the number of ECUs it may challenge; and 2) attestation requires computing a signature over the entire firmware image, which is expensive; and 3) the protocol involves multiple communication rounds rather than a single lightweight message; and 4) the design assumes a flat network topology and does not exploit the hierarchical structure of in-vehicle networks; and 5) they do not incorporate a repair component.

Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation. R EFERENCES [1] Specification of time synchronization over CAN (cantsyn). Specification Document ID 674, AUTOSAR - Automotive Open System Architecture, Munich, Germany, 2023. AUTOSAR Classic Platform Release R23-11. [2] Nilabh Anand and Aakash Kedia. Achieving faster secure boot time on am26x devices. Application Brief SPRADM8, Texas Instruments, Dallas, Texas, November 2024. Application Brief on secure boot optimization techniques for AM263x and AM263Px SoC family. [3] Erik Andréasson and Ivan Lyesnukhin. Device attestation for in-vehicle network. Master’s thesis in computer science and engineering, Chalmers University of Technology and University of Gothenburg, Gothenburg, Sweden, July 2022. Master’s Thesis 2022, Department of Computer Science and Engineering. [4] Vard Antinyan. Revealing the complexity of automotive software. In Proceedings of the 28th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE ’20). ACM, 2020. [5] ARM Ltd. Trustzone for cortex-a. https://www.arm.com/technologies/ trustzone-for-cortex-a, 2025. Accessed: August 3, 2025. [6] ARM Ltd. Trustzone for cortex-m. https://www.arm.com/technologies/ trustzone-for-cortex-m, 2025. Accessed: August 3, 2025. [7] AUTOSAR. Requirements on firmware over-the-air. Technical Report Document ID 944, AUTOSAR – Automotive Open System Architecture, November 2020. AUTOSAR Classic Platform Release R20-11. [8] Russ Bielawski, Ron Gaynier, Di Ma, Sam Lauzon, and Andre Weimerskirch. Cybersecurity of firmware updates. Final report DOT HS 812 807, United States. Department of Transportation. National Highway Traffic Safety Administration, October 2020. [9] Alvaro A. Cárdenas, Saurabh Amin, Bruno Sinopoli, Annarita Giani, Adrian Perrig, and Shankar Sastry. Challenges for securing cyber-physical systems. In Workshop on Future Directions in Cyber-physical Systems Security, Washington, DC, July 2009. DHS. [10] J. Dafoe, H. Singh, N. Chen, and B. Chen. Enabling real-time restoration of compromised ecu firmware in connected and autonomous vehicles. In Proc. of Security and Privacy in Cyber-Physical Systems and Smart Vehicles (SmartSP), pages 15–33, 2024. [11] Josh Dafoe, Job Siy, Niusen Chen, and Bo Chen. Hardware-assisted runtime in-vehicle ecu firmware self-attestation and self-repair. In Proc. of Security and Privacy in Cyber-Physical Systems and Smart Vehicles (SmartSP), pages 140–161. 2025. [12] V. den Herrewegen and F. Garcia. Beneath the bonnet: A breakdown of diagnostic security. In P. Lopez, W. Zhou, and E. Soriano, editors, Computer Security, pages 305–324. Springer International Publishing, Cham, 2018. [13] Le Guan, Shijie Jia, Bo Chen, Fengwei Zhang, Bo Luo, Jingqiang Lin, Peng Liu, Xinyu Xing, and Luning Xia. Supporting transparent snapshot for bare-metal malware analysis on mobile devices. In Proceedings of the 33rd annual computer security applications conference, pages 339– 349, 2017. [14] Yutian Gui, Ali Shuja Siddiqui, and Fareena Saqib. Hardware based root of trust for electronic control units. In SoutheastCon 2018, pages 1–7. IEEE, 2018. [15] Wouter Hellemans, Nada El Kassem, Md Masoom Rabbani, Edlira Dushku, Liqun Chen, An Braeken, Bart Preneel, and Nele Mentens. Spark: Secure privacy-preserving anonymous swarm attestation for invehicle networks. In Proceedings of the 10th IEEE European Symposium on Security and Privacy (EuroS&P), pages 903–917. IEEE, 2025. [16] T. Hoppe, S. Kiltz, and J. Dittmann. Applying intrusion detection to automotive it-early insights and remaining challenges. Journal of Information Assurance and Security (JIAS), 4:226–235, January 2009. Early work on automotive intrusion detection systems. [17] Kaster. Automotive Software Attestation: Self, Remote, and Peer Building Trust in Autonomous Driving Safety Systems. PhD thesis, University of Michigan, Ann Arbor, Michigan, 2024. [18] R. Kaster, D. Ma, A. Behl, and B. Bakalarczyk. Sliced secure boot. In 19th escar Europe: The World’s Leading Automotive Cyber Security Conference, November 2021.

B. In-vehicle ECU Firmware Repair To restore the system after malware attacks, Mansor et al. [25] proposed temporarily backing up the previous firmware during updates, and, if the installation-time checks fail, the old firmware is restored. However, this solution only supports recovery immediately after flashing and cannot address runtime compromise that occurs long after a successful update. Kwon et al. [23] proposed integrating an intrusion detection system and moving compromised ECUs into a “safe mode” before rebooting. Dafoe et al. [10] proposed a selfrepair mechanism for ECUs together with an intrusion detection node that can notify a trusted application in compromised ECUs to orchestrate rollback. They further improved the design by incorporating a probabilistic self-attestation in their subsequent work [11]. However, all these approaches suffer from three limitations: 1) they are vulnerable to a single point of failure, and 2) they do not explicitly verify the entire state of the vehicle and instead provide only local integrity checks, and 3) they do not support context-aware rebooting decisions, because the ECU status is not propagated to the rest of the vehicle. VIII. C ONCLUSION In this work, we have introduced DACER, the first framework that integrates malware detection and repair for ECUs while meeting strict runtime vehicle constraints. Specifically, DACER co-designs efficient attestation and repair mechanisms that unify the “local” nature of rollback with the “global” nature of ECU reboot. Experimental evaluation of embedded systems in the real-world demonstrates the low overhead of DACER. ACKNOWLEDGMENT This material is based upon work supported by the National Science Foundation Graduate Research Fellowship Program under Grant No. 2437847, and by the National Science Foundation under Grant Nos. 2225424, 2043022 and 2623031.

9

node in the domain is challenged, and vdℓ nodes act as verifiers. The challenged node should respond with the specific value C if all self-attestations have returned valid results since the last reboot. For this mechanism to be secure, we have three security requirements, which we analyze as follows:

[19] Mohammad Khodari, Abhimanyu Rawat, Mikael Asplund, and Andrei Gurtov. Decentralized firmware attestation for in-vehicle networks. In Proc. of the 5th ACM Cyber-Physical System Security Workshop (CPSS). ACM, 2019. [20] Daehyun Kim, Eunho Shin, Jin Seo Park, KyungSu LEE, Kok Cheng Gui, and Klaus Scheibert. Secure boot implementation for hard realtime powertrain system. In SAE World Congress Experience (WCX™ 17), number 2017-01-1656 in SAE Technical Paper, Detroit, Michigan, United States, March 2017. SAE International. Paper presented at SAE World Congress Experience, April 4-6, 2017. [21] Florian Kohnhäuser, Dominik Püllen, and Stefan Katzenbeisser. Ensuring the safe and secure operation of electronic control units in road vehicles. In 2019 IEEE Security and Privacy Workshops (SPW), pages 126–131, San Francisco, CA, USA, May 2019. IEEE. [22] S. Kulandaivel, S. Jain, J. Guajardo, and V. Sekar. Candid: A stealthy stepping-stone attack to bypass authentication on ECUs. ACM Journal on Autonomous Transportation Systems, april 2024. [23] H. Kwon, S. Lee, J. Choi, and B. H. Chung. Mitigation mechanism against in-vehicle network intrusion by reconfiguring ecu and disabling attack packet. In Proc. of 2018 International Conference on Information Technology (InCIT), pages 1–5. IEEE, 2018. [24] T. Lauser and C. Krauß. Formal security analysis of vehicle diagnostic protocols. In Proc. of the 2023 International Conference on Availability, Reliability and Security (ARES). ACM, 2023. [25] Hafizah Mansor, Konstantinos Markantonakis, Raja Naeem Akram, and Keith Mayes. Don’t brick your car: Firmware confidentiality and rollback for vehicles. In 2015 International Conference on Availability, Reliability and Security (ARES), pages 139–148. IEEE, August 2015. [26] Ahmad M. K. Nasser, Wonder Gumise, and Di Ma. Accelerated secure boot for real-time embedded safety systems. SAE International Journal of Transportation Cybersecurity and Privacy, 2(1):35–48, July 2019. [27] NXP Semiconductors. AN13497: Firmware Update Using Secondary Bootloader. NXP Semiconductors, December 2021. [28] NXP Semiconductors. S32g3 vehicle networking reference design. https://www.nxp.com/design/designs/ s32g3-vehicle-networking-reference-design:S32G-VNP-RDB3, 2025. [29] NXP Semiconductors. S32k3 automotive telematics box (t-box) reference design board. https://www.nxp.com/design/designs/ s32k3-automotive-telematics-box-t-box-reference-design-board: S32K3-T-BOX, 2025. [30] Hisashi Oguma, Akira Yoshioka, Makoto Nishikawa, Rie Shigetomi, Akira Otsuka, and Hideki Imai. New attestation-based security architecture for in-vehicle communication. In IEEE Global Telecommunications Conference (GLOBECOM), pages 1–6. IEEE, 2008. [31] Chuka Oham, Regio A. Michelin, Salil S. Kanhere, Raja Jurdak, and Sanjay K. Jha. B-ferl: Blockchain based framework for securing smart vehicles. Information Processing & Management, 58(1):102426, 2021. arXiv preprint arXiv:2007.10528. [32] Enrico Pozzobon, Nils Weiss, Juergen Mottok, and Václav Matoušek. Fuzzy fault injection attacks against secure automotive bootloaders. 10 2023. [33] David Ray Rogala. Secure boot at shutdown. European Patent, March 2023. European Patent Office. Patent granted March 8, 2023. [34] Steffen Sanwald, Liron Kaneti, Marc Stöttinger, and Martin Böhner. Secure boot revisited: Challenges for secure implementations in the automotive domain. SAE International Journal of Transportation Cybersecurity and Privacy, 2(2):69–81, 2019. Paper ID: 11-02-02-0008. [35] STMicroelectronics. STM32L5 series GPIO usage with TrustZone®. Technical Report AN5600, STMicroelectronics, January 2021. Application note. [36] Chris Valasek and Charlie Miller. Remote exploitation of an unaltered passenger vehicle. Technical report, IOActive, 2015. [37] Shengye Wan, Mingshen Sun, Kun Sun, Ning Zhang, and Xu He. Rustee: developing memory-safe arm trustzone applications. In Proceedings of the 36th Annual Computer Security Applications Conference, pages 442–453, 2020.

Property 1 (Bounded false positives). Let ζdℓ be the number of malicious verifiers in domain Ddℓ (ζdℓ ≤ vdℓ ), indexed k = 1, . . . , ζdℓ , and let Pr[Dk | Γ] be the probability that corrupted firmware is detected on verifier k. The probability of a false positive is at most ℓ

1−

ζd Y

Pr[Dk | Γ].

k=1

Proof sketch. Recall that Pr[D | Γ] is the probability that corrupted firmware is detected on a given node. A false positive can only occur when at least one verifier returns an invalid attestation report. This occurs in one of three mutually exclusive cases: (a) Challenged node withholds C. TApp in the challenged node does not reveal C to UApp (i.e., C ′ ̸= C). Self-attestation necessarily failed, so malware is definitely present. This is a true positive unless UApp independently guesses C, which succeeds with only negligible probability 21κ . (b) Challenged node’s UApp tampers with C. TApp reveals C (having detected no malware), but a compromised UApp modifies or drops it in transit (i.e., C ′ ̸= C). The challenged node contains malware, so this is again a true positive. (c) Verifier’s UApp tampers with C ′ . The challenged UApp is benign (C ′ = C), but malware in verifier k causes its UApp to modify or drop C ′ in transit (i.e., C ′′ ̸= C). This is the only source of false positives. The malware in verifier k is independently detected via spot-checking with probability Pr[Dk | Γ], in which case TApp will not generate an invalid report. Otherwise (probability 1 − Pr[Dk | Γ]), the compromised verifier may produce a false invalid attestation report. Since spot-checks depend on the local state of each node, the detection events are independent. The probability that all Qζ ℓ ζdℓ malicious verifiers are detected is then kd Pr[Dk | Γ], and the probability that at least one remains undetected and causes a false positive is at most ℓ

1−

ζd Y

Pr[Dk | Γ].

k=1

This is an upper bound, since malicious nodes will not necessarily perform such an attack. Note that even in the rare case of a false positive, the system response is to reboot the challenged node at a “safe” time. This has low impact compared to missing an actual compromise, and the probability of such events is low by the above bound.

A PPENDIX A. Decentralized-attestation In each domain Ddℓ (where 1 ≤ ℓ ≤ 2 and 1 ≤ d ≤ nℓ , with nℓ denoting the number of domains in layer ℓ), a periodic decentralized-attestation will take place, during which one

Property 2 (Decentralized attestation introduces no false negatives). If a challenged node has failed self-attestation and

10

at least one verifier is benign, then the compromise is detected except with negligible probability

benign long enough to participate in the repair of nodes in lower layers. Property 4 (Eventual repair). For any in-vehicle computer cℓk , if cℓk is definitely compromised (i.e., it has failed selfattestation or TApp is disabled), it will be rebooted via coordinated repair within finite time.

Proof sketch. Suppose a node has been challenged, and its selfattestation has failed. As established in Case (a), TApp in the challenged node will not reveal C to UApp. Additionally, C cannot be forged with probability higher than 1/2κ . Therefore, TApp in a benign verifier will not receive C (aside from a negligible probability) and will therefore produce an invalid attestation report.

Proof sketch (strong induction on layers). For the base case, layer n consists solely of MC. If MC’s firmware is compromised, then TApp in MC detects this via self-attestation eventually (since Pr[D | Γ] asymptotically approaches 1 as the number of self-attestations increases). Then by Assumption 3, TApp can alert the vehicle operator, who can move the vehicle into a safe state (e.g., parked) and manually reboot MC.

Property 3 (Per-round false-negative rate). Suppose a malicious node is selected as the challenged node in a given decentralized-attestation round. Then that round reports the node as valid with probability at most 1 − Pr[D | Γ].

For the inductive step, suppose that for some i with 1 < i ≤ n, any detected malware in layers n through i has been repaired via self-repair and coordinated repair (inductive hypothesis). Suppose some node ci−1 in layer i − 1 k is compromised and has failed self-attestation. Since all nodes in layers n through i are eventually repaired, the parent of ci−1 is eventually repaired. After this point, either a benign k node in layer i − 1 or the parent itself will be selected to verify ci−1 during decentralized attestation. By Property 1–2 k (§A), this will be detected by the benign verifiers, and an invalid attestation report will be propagated upward. Since all compromised nodes in upper layers have been repaired (inductive hypothesis), this message is guaranteed to reach MC intact. MC can then determine a safe window in which to reboot ci−1 k , which is feasible by Assumption 2.

Proof sketch. There are two cases, depending on whether selfattestation has already failed on the challenged node: (a) Self-attestation has failed (probability Pr[D | Γ]). By Property 2, the benign verifier detects the compromise. This case contributes no false negatives. (b) Self-attestation has not detected the compromise (probability 1 − Pr[Dc | Γ]). TApp perceives no invalid result and honestly reveals C. If the compromised UApp forwards C unmodified, the verifiers receive the correct value and report the node as valid, resulting in a false negative. If instead it modifies or drops C, the round reports the node as invalid (Property 1, case (b)) and the compromise is caught. Since a false negative occurs only in case (b), the per-round false-negative probability is exactly 1 − Pr[D | Γ].

Remark. This proof sketch implicitly assumes that once a node is repaired, it remains benign long enough to facilitate repair of lower layers. While we can ensure that repair will occur eventually, we also need to ensure that this repair is timely. To determine this, we want to compute the mean time to repair for each layer (M T T Rℓ ). We define the mean time to repair as the time until repair is feasible. That is, the time until TApp in MC is aware of malware on a given node. At this point, repair may take place at any point, decided by MC. First, we note that for a given compromised node in layer i, there are a few conditions to guarantee that an invalid attestation report will reach MC: (1) The node has failed a selfattestation, (2) The node is selected to be challenged during decentralized attestation, (3) a benign verifier is selected during this challenge, (4) a specific node in each layer k where i < k ≤ n is benign (i.e. the parent controllers up to MC). Note that (3) and (4) are required because we assume the worst case attacker, which performs a DoS attack on broadcasting an invalid attestation report. To compute M T T Rℓ , we want to determine the mean time until all of these conditions have been met. We compute M T T Rℓ in two different ways: analytically by solving the fixed point presented below, and via a Monte Carlo simulation. The two results agree, as shown in Tables VII and VI. Both models consider a more general design than we presented in the main text. Specifically, we consider challenging aℓ nodes per

Recall that Γ considers the number of self-attestations performed since the compromise. This can be 0, in which case 1−Pr[D | Γ] = 1−0 = 1. Additionally, A false-negative round does not prevent later detection: the node remains subject to self and decentralized attestations and will be challenged again. Pr[D | Γ] increases with each subsequent attestation and the probability of indefinite non-detection goes to zero. The mean time, beginning from node compromise, during which a decentralized-attestation challenge results in a false negative is quantified by W1 in § B. B. Coordinated-repair For coordinated-repair to be secure, we want to ensure that over time, any node that is definitely compromised (i.e., it has failed self-attestation or TApp is disabled) is eventually rebooted into a benign state. To do this, the invalid attestation report generated by a verifier node needs to first successfully reach MC. Since MC can initiate repair of any node (by Assumption 2), this is sufficient for repair to take place. We provide a proof sketch below (by strong induction on the layers 4 ): For the following property, let cℓk denote the kth in-vehicle computer in layer ℓ, where layer n contains only MC. The argument assumes that once a node is repaired, it remains 4 Note that in this section, we use a generalized system model, with a vehicle architecture consisting of n layers.

11

decentralized-attestation epoch (§ V). Additionally, we assume that rebooting takes place at the instant a benign MC receives a invalid decentralized-attestation report. Analytic solution. Let Pm = Pr[D | Γ]. First, (for condition (1)) we model the number of self-attestations until corruption is detected locally as a random variable (NSA ) that follows a geometric distribution. The expected value for the number of self-attestations until corruption is detected locally is therefore E[NSA ] =

For condition (3), we also need a benign node to be selected as a verifier. To do this we take into account the availability of the nodes in the same layer: Aℓ =

where M T T Fℓ is the mean time to failure for a given node in layer ℓ. Given this, the probability, at any time, that at least one verifier is benign is

∞   1 X . (Pm · (1 − Pm )k−1 ) · k = Pm

ℓ

Ps = 1 − (1 − Aℓ )vd .

k=1

To deduce the mean time until self-attestation detects malware, we model the time until corruption is detected locally as a random variable τSA , where τSA = TSA ·NSA . The expected value is TSA . E[τSA ] = E[NSA ] · TSA = Pm

By Property 2, if a compromised node is challenged and at least one verifier is benign, the malware is guaranteed to be detected. Thus Ps is also the probability that a given challenge round successfully detects the malware, and 1 − Ps is the probability that a challenge round fails to detect it (i.e., every verifier selected for that round happens to be malicious). If a challenge round fails, detection must wait for a subsequent decentralized-attestation challenge, which arrives after a further expected time 1/λ2 ; this may again fail with probability 1 − Ps , and so on. Accounting for this retry process, the expected additional time, after self-attestation detects malware, until conditions (2) and (3) are satisfied is

We simply take the reciprocal to get the rate (per unit time) of detection by self-attestation: λ1 =

Pm 1 = . E[τSA ] TSA

Since malware installation occurs at a time independent of the self-attestation schedule, the first check after installation does not land a full TSA later on average, but only TSA /2 later. We therefore define W1 , the expected time until selfattestation first detects malware, as TSA 1 . − W1 = λ1 2 In addition (for condition (2)), we model detection via decentralized attestation. We model the number of decentralizedattestation rounds until the malicious node is challenged (d,ℓ) in domain Ddℓ by the random variable NDA following a geometric distribution. The expected value for the number of decentralized attestations until a given compromised node (d,ℓ) (d,ℓ) is challenged is E[NDA ] = |Ddℓ |. Let τDA be a random variable representing the time until the compromised node is (d,ℓ) (d,ℓ) challenged, so that τDA = Tℓ · NDA . The expected time until being challenged is therefore (d,ℓ)

M T T Fℓ , M T T Fℓ + M T T Rℓ

1 1 + (1 − Ps )2 + ··· λ2 λ2 ∞ 1 X (1 − Ps )k = W2 + λ2

W2 + (1 − Ps )

k=1

1 1 − Ps = W2 + · . λ2 Ps So that the expected time until conditions (1), (2), and (3) are met is 1 − Ps W1 + W 2 + . λ2 · Ps For condition (4), we also need the parent controller in the layers ℓ + 1 through n to be benign for the message to be received by MC. I.e. a particular node in each of the higher layers must be benign. This depends on the value of Ak for ℓ + 1 ≤ k ≤ n. In fact, the probability that all of the parents up to the main controller are benign at any given time is

(d,ℓ)

E[τDA ] = Tℓ · E[NDA ] = Tℓ · |Ddℓ |. Thus, the rate of detection by decentralized attestation is aℓ aℓ λ2 = = (d,ℓ) Tℓ · |Ddℓ |. E[τ ]

n Y

DA

Ak .

k=ℓ+1

Decentralized-attestation challenges occur independently of when self-attestation detects malware, so we define W2 , the expected time until the first decentralized-attestation challenge after detection, as Tℓ 1 − . W2 = λ2 2 Then, the mean time until both conditions (1) and (2) are satisfied is then simply

To incorporate this, we can simply modify Ps : n Y  ℓ Ps = 1 − (1 − Aℓ )vd · Ak . k=ℓ+1

Therefore, we have, as the expected time until conditions (1), (2), (3), and (4) are all met: M T T Rℓ = W1 + W2 +

W1 + W 2 .

12

1 − Ps . λ 2 Ps

However, there is a dependency of M T T Rℓ on Aℓ , and vice versa. But, we have M T T Fℓ Aℓ = M T T Fℓ + M T T Rℓ =⇒ (M T T Fℓ + M T T Rℓ )Aℓ = M T T Fℓ =⇒ Aℓ · M T T Fℓ + Aℓ · M T T Rℓ = M T T Fℓ =⇒ Aℓ · M T T Rℓ = M T T Fℓ − Aℓ · M T T Fℓ =⇒ Aℓ · M T T Rℓ = M T T Fℓ (1 − Aℓ ) =⇒ M T T Rℓ = M T T Fℓ ·

1 − Aℓ , Aℓ

so that by combining the two results for M T T Rℓ , we have   1 − Aℓ 1 − Ps M T T Fℓ · = W1 + W2 + , Aℓ λ2 · P s

Parameter

Value

Description

n Pr[D | Γ] TSA M T T Fℓ T1 , T2 T3

3 0.982 4s 5400 s 2s TSA

Number of hierarchy layers Detection probability per attestation Self-attestation period Mean time to failure for each layer Decentralized-attestation periods Top-layer attestation period

|Dd2 |

4

Number of zone controllers

|Dd1 |

20

Number of ECUs in each domain

vd2

2

Verifiers for layer 2

vd1

5

Verifiers for layer 1

TABLE V: Baseline parameters used for the computations.

which implies that   1 − Aℓ 1 − Ps M T T Fℓ · − W1 − W2 − = 0. Aℓ λ2 · P s To solve for Aℓ , we can use a fixed point approach (e.g. Newton’s method). Using this, we can compute M T T Rℓ . We note that to compute M T T Rℓ , we first need to compute M T T Rk for ℓ < k ≤ n, since it is defined recursively. For the base case, since repair in MC depends only on self-attestation, we have M T T Rn = W1 . Monte Carlo Simulation. To validate the analytical results, we implemented a Monte Carlo simulation of node compromise, self-attestation, decentralized-attestation, and coordinated-repair. Each simulation run samples compromise times, self-attestation results, decentralized-attestation challenges, verifier availability, and parent controller availability. A compromised node was only repaired if all four conditions above were simultaneously met. We tracked the time of compromise and time of repair for each instance, and computed M T T Rℓ as the empirical mean time from node compromise until the compromised node is reported to MC. Table VII shows the baseline parameters used when computing M T T Rℓ using both the analytical results and Monte Carlo Simulation. The baseline results for all layers are shown in Table VII. We also vary several key parameters and report the corresponding value of M T T R1 in Table VI. These results demonstrate both the timely nature of our design and the close agreement between the analytical and Monte Carlo estimates. Across the baseline layer comparison, the maximum relative error is 0.35%; across the M T T R1 parameter sweep, the maximum relative error is 0.49%.

Param.

Value

Analytic

MC mean

Difference

MTTF

5400 2000 800 300 100

41.16 41.30 41.63 42.58 45.84

41.15 41.32 41.71 42.78 46.06

0.01% 0.05% 0.17% 0.49% 0.48%

aℓ

1 2 4 8

41.16 21.10 11.08 6.08

41.15 21.11 11.08 6.08

0.01% 0.07% 0.00% 0.05%

|Dd1 |

10 20 40 80

21.11 41.16 81.24 161.40

21.13 41.15 81.26 161.41

0.06% 0.01% 0.03% 0.01%

v1

1 2 5 10

41.46 41.16 41.16 41.16

41.51 41.15 41.15 41.18

0.12% 0.01% 0.01% 0.05%

TABLE VI: Layer-1 MTTR under parameter sweeps. MC means are over 50 random seeds, each simulating 107 s.

Layer

Analytic

MC mean

Difference

Layer 1 Layer 2 Layer 3

41.16 9.08 2.07

41.15 9.04 2.08

0.01% 0.35% 0.16%

TABLE VII: Baseline analytical and Monte Carlo MTTR across all layers. MC means are over 50 random seeds, each simulating 107 s.

13

Related documents

• ECO/CPO-DAG: A Contradiction-Based Accountability Layer for Adversarial Supply Chains#349607
• CosyVerif: an Online Verification Platform#312059
• Internal police checks under the revised schengen borders code in the light of the ECtHR’s jurisprudence#386509
• CVE-2026-80144 — CRITICAL 9.4#1054390
• CVE-2026-80143 — CRITICAL 9.4#1067286