zk-ScalHard: Scalable and Hardware-Rooted Privacy-Preserving Authentication for Secure OTA Updates in Zonal SDVs Shrikant Tangade1,2,3,* , Bansi Pambhar2 , Valeria Loscrı̀1 , and Mauro Conti4,5 1
arXiv:2607.07371v1 [cs.CR] 8 Jul 2026
SERENDIPITY Team, Inria Lille – Nord Europe, France 2 autoMoTIVe-X Lab, Belagavi, India 3 Anuvartik Mirji Bharatesh Institute of Technology, Belagavi, India 4 University of Padua, Padua, Italy 5 Örebro University, Örebro, Sweden Emails: {shrikant.tangade, valeria.loscri}@inria.fr, {shrikant.tangade, bansi.pambhar}@motivex.in, [email protected]
Abstract—Today’s automotive industry is transitioning to a zonal-oriented architecture (ZoA) for software-defined vehicles (SDVs). This enables frequent, flexible software updates for 100+ electronic control units (ECUs) via over-the-air (OTA) updates. Although OTA updates improve vehicle efficiency and fix security bugs, they can also pose security risks that may lead to safety-critical issues. To provide secure OTA updates, current industry standards include the Uptane framework and the AUTOSAR adaptive platform. These solutions are based on public-key infrastructure (PKI). However, vehicle authentication during OTA updates creates a significant bandwidth bottleneck in in-vehicle (IV) and vehicle-to-cloud (V2I) communications as ECU density increases. It also exposes a vehicle’s sensitive configuration and passenger data. Furthermore, their centralised architecture creates a single point of failure. The new Zonal SDV requires decentralised, scalable vehicle authentication with data privacy. To address these issues, we propose zk-ScalHard, a scalable and privacy-preserving silicon-to-cloud authentication protocol. To design and implement zk-ScalHard, (1) we introduce a decentralised, hybrid, and hierarchical trustpromotion architecture model which utilises hardware-rooted silicon physical unclonable functions (PUFs). We design and code two zero-knowledge proof (ZKP) circuits: (2) zonal identity and integrity (ZIDI) and (3) high-performance computing aggregation (HPCA). These ZIDI and HPCA circuits employ multi-party computation (MPC) and recursive aggregation to achieve decentralisation and scalability, respectively. The integration of ZKPs and silicon PUFs ensures 100% vehiclelevel data sovereignty. We benchmark zk-ScalHard against the industry-standard Uptane framework. Evaluation results demonstrate that zk-ScalHard achieves constant O(1) commu*Corresponding author: [email protected]. S. Tangade is an MSCA SoE Fellow at Inria Lille, Director of the autoMoTIVe-X Lab, and a Professor at AMBIT, Belagavi, India. B. Pambhar is a Research Assistant at the autoMoTIVe-X Lab. V. Loscrı̀ is the Head of the SERENDIPITY Team at Inria Lille. M. Conti is a Professor with the University of Padua and Örebro University, and Head of the SPRITZ Research Group. This work was supported by the MSCA Seal of Excellence (SoE), awarded by the European Commission and funded by the University of Lille. Source code: https:// github.com/autoMoTIVe-X/zk-ScalHard.
nication and verification complexity, down from linear O(n). Further, it reduces authentication bandwidth and the temporal attack surface by 99.2% and 99.9%, respectively. These results demonstrate that zk-ScalHard provides a scalable, secure, and GDPR-compliant architecture for next-generation Zonal SDVs.
1. Introduction The next-generation automotive industry is moving towards software-defined vehicles (SDVs). Advanced SDVs equipped with 100+ electronic control units (ECUs) are also called computers-on-wheels. Each ECU performs its task, such as automatic braking or steering control, using specific software/ firmware. This software enables improvements in vehicle efficiency, new feature additions, and bug fixes through over-the-air (OTA) updates with the Internet, rather than through traditional offline updates (i.e., taking the vehicle to the service station). In 2024 (Q4), 5.1 million Tesla vehicles received bug fixes via OTA updates [1]. The OTA updates benefit both automotive original equipment manufacturers (OEMs) and vehicle owners. The OEMs save intermediate vehicle service stations billions of dollars on software updates. In addition, OEMs are adopting a software-as-a-service (SaaS) business model to drive revenue. Whereas vehicle owners save time by not taking their vehicles to a service station and receive updates from their home or office parking. Furthermore, vehicles are now more customizable and have longer lifespans thanks to softwaredriven OTA updates. The OTA update process connects SDV’s 100+ ECUs to the OEM’s backend OTA cloud server through the Internet. This introduces a new cyberattack surface that hackers can exploit, enabling them to inject malicious software into ECUs and take control of the vehicle. This leads to safetycritical issues in which passengers’ lives and the vehicle itself are at risk. To ensure SDVs’ safety and security, the United Nations (UN) introduced new automotive-specific regulations, UN Regulation No. 155 (UN-R155) [2] and UN Regulation No. 156 (UN-R156) [3], for cybersecurity
and software updates, respectively. The automotive industry introduced two international standards for road vehicles to comply with these regulations: ISO/SAE 21434 - the cybersecurity management system (CSMS) [4], which aligns with UNR155 and ISO/SAE 24089 - the software update management system (SUMS) [5], which aligns with UNR156. To implement SDV’s robust security and enhanced safety, these regulations and standards must complement each other. This makes secure OTA updates mandatory for SDV, not optional [6]. Since SDVs are connected to the external world via wireless networks such as Wi-Fi and the Internet, they are more prone to remote cyberattacks. This forces frequent OTA updates to fix bugs and also enable/add new features based on customer needs. When the OTA update system itself is insecure, it exposes the system to serious security threats, such as malware injection and remote vehicle control. In today’s transitional automotive industry, the supply chain (i.e., OEMs, Tier 1, & Tier 2 suppliers) is facing challenges in implementing a secure OTA update system to ensure SDVs’ safety. In addition, it should comply with new automotive cybersecurity regulations/standards (UNR155, R155; ISO/SAE 21434, 24089) and general-purpose data regulations such as the GDPR, CCPA, and the EU Cybersecurity Act to ensure SDVs’ data privacy and sovereignty. We define data sovereignty in the context of secure OTA updates for Zonal SDVs as the vehicle’s architectural capability to maintain exclusive control over its sensitive configuration metadata and physical identity.
1.1. Motivation Next-generation SDVs are increasingly characterized as connected and autonomous vehicles (CAVs). This transition marks the rise of the ’Data Centre on Wheels’ [7], where the vehicle’s value is increasingly defined by its software stack and cloud connectivity. Further, the automotive Electric & Electronics (E/E) architecture is evolving from legacy centralized gateway architecture (CGA) and domain-oriented architecture (DoA) toward zonal-oriented architecture (ZoA) [8]. Recent automotive industry projections estimate that adoption will rise from 2% in 2023 to nearly 45% in ZoA in 2030 [9] with 80% of OEMs already initiating this structural shift [10]. In parallel with this architectural evolution, communication technologies are migrating from Controller Area Network (CAN) to Automotive Ethernet (AE), facilitating the shift from traditional offline maintenance to frequent OTA updates. While CGA and DoA models rely on relatively static configurations with limited OTA capabilities, the ZoA supports dynamic orchestration and frequent software deployment for 100+ ECUs. The current focus in the automotive industry remains on “pull-based” OTA updates, in which the vehicle initiates the update request. These pull-based OTA updates require a robust authentication mechanism to verify the vehicle’s identity and software metadata against the OTA server before releasing sensitive firmware binaries.
However, the shift to Zonal SDVs introduces significant security challenges. Supporting flexible OTA updates for high-density ECU environments creates a massive scalability bottleneck and exposes sensitive configuration metadata, compromising data privacy. Furthermore, the hardware heterogeneity between resource-constrained edge ECUs and the central HPC introduces systemic vulnerabilities and potential single points of failure. Consequently, there is an urgent need for a Zonal-native, scalable, and decentralized authentication protocol that preserves privacy throughout the secure OTA update lifecycle.
1.2. Problem Statement and Gap Analysis Current industry standards for OTA updates, such as the Uptane framework and the AUTOSAR Adaptive Platform, provide robust integrity but face a critical “Scalability Wall” in terms of bandwidth, latency, and data privacy. When an SDV initiates a software update request, it must transmit a comprehensive vehicle manifest containing metadata for 100+ ECUs. This results in unsustainable communication and computational overheads that act as bottlenecks for high-density zonal networks. To quantify the scalability limits of these standards, we conducted a systematic benchmarking of the Uptane reference implementation (detailed in Section 7 & Appendix). Our evaluation reveals that, for an SDV equipped with 100 ECUs, the vehicle version manifest (VVM) payload grows linearly (O(n)) to 98.6KB. Furthermore, the total VVM verification latency reaches 15.4s per vehicle. Beyond performance, these frameworks rely on centralized, trusted authorities (such as PKI) for key management and store persistent secrets in Flash memory, creating a systemic single point of failure. While existing scientific research has addressed individual aspects of authenticity, scalability, and privacy, no current solution simultaneously meets all these requirements for vehicle authentication during OTA updates (see Section 9: Related Work). To resolve these conflicts, we introduce zk-ScalHard, a scalable authentication protocol built on a multi-tier, heterogeneous trust-promotion architecture. This model maps cryptographic intensity to the underlying hardware constraints of Zonal SDVs, replacing stateful, identity-revealing signatures with hardware-bound, recursive proofs. By moving the “Trust Ceremony” from the cloud to the vehicle’s Zonal Controllers, we eliminate centralized risk while achieving asymptotic O(1) scalability. Table 1 provides a comparative gap analysis between zk-ScalHard and current industry and research standards. While legacy frameworks like Uptane and emerging PQC standards address integrity and quantum threats, they suffer from linear metadata bloat (O(n)) and persistent exposure of secrets. zk-ScalHard is the first to achieve asymptotic invariance (O(1)) in both communication and verification, while simultaneously providing temporal isolation to protect physical silicon identities.
TABLE 1. C OMPARATIVE G AP A NALYSIS OF AUTOMOTIVE AUTHENTICATION S OLUTIONS Framework
Asymptotic Scalability
Temporal Isolation
Identity Privacy
Trust Model
Post-Quantum
Uptane/ PKI [11], [12]
Linear O(n)
No (Persistent)
Revealed
Centralized
No
IBM Idemix [13], [14]
Linear O(n)
No (Persistent)
Zero-Knowledge
Centralized
No
MS U-Prove [15]
Linear O(n)
No (Persistent)
Selective
Centralized
No
NIST PQC [16], [17]
Linear O(n)
No (Persistent)
Revealed
Centralized
Yes
zk-ScalHard (Proposed)
Constant O(1)
Yes (Ephemeral)
Zero-Knowledge
Decentralized
Yes
1.3. Research Questions To secure the next generation Zonal SDVs OTA updates and compliance with new automotive cybersecurity regulations/ standards, this paper addresses the following four fundamental research questions (RQ): •
•
•
•
RQ1 (Trust Architecture): How can a multi-layer trust hierarchy be designed to bridge the gap between a resource-constrained ECU (Layer-0) and a global OTA cloud server (Layer-3) while aligning cryptographic intensity with heterogeneous hardware capabilities? RQ2 (Asymptotic Scalability): Is it possible to achieve constant communication and verification complexity (O(1)) as ECU density increases, thereby decoupling security overhead from the Zonal SDV architectural scale? RQ3 (Decentralized Trust): How can a Zonal SDV’s cryptographic root-of-trust be initialized via in-situ multi-party computation (MPC) to eliminate the systemic single point of failure inherent in centralized trusted setups? RQ4 (Temporal Isolation): How can the temporal attack surface for key extraction be minimized by integrating silicon PUFs as dynamic witnesses, thereby shifting from persistent stateful storage to a transient execution window?
•
•
1.4. Our Contributions We address the above challenges and research questions by designing and implementing a novel zonal SDV native hybrid, heterogeneous trust-promotion hierarchy zkDieHard-SDV authentication protocol for secure OTA updates. Our key contributions to advancing the state of the art are as follows: •
Contribution 1 (Hierarchical Trust Architecture): We propose zk-ScalHard, a multi-tier hierarchical architecture for trust promotion. It orchestrates trust from edge ECUs to the central OTA cloud server by integrating hardware-rooted silicon PUFs as a temporal dynamic witness (Layer-0), performing in-situ decentralized trust ceremonies (Layer-1),
•
and executing recursive proof aggregation (Layer2). This architecture achieves scalable, secure, and GDPR-compliant vehicle-to-cloud (Layer-3) attestation within the OTA update lifecycle. Contribution 2 (Asymptotic Scalability): We design and implement a High-Performance Computing Aggregation (HPCA) ZKP circuit that performs recursive proof aggregation at the vehicle central hub (Layer-2). By compressing four zonal proofs into a single atomic vehicle-level proof for the cloud (Layer-3), we achieve constant-size O(1) communication and verification complexity in contrast to the linear O(n) growth of the industry-standard Uptane framework. Our evaluation quantifies that for a Zonal SDV with 100 ECUs, zk-ScalHard reduces V2I bandwidth by 99.2% (from 98.6KB to 809B) and achieves a constant V2I verification latency of 2.1s (down from 15.47s), representing a 7.3x speedup over the Uptane framework. This effectively decouples security overhead from Zonal SDV architectural scale. Contribution 3 (Decentralized Trust): We design the Zonal Identity and Integrity (ZIDI) circuit to enable an in-situ zonal multi-party computation (MPC) ceremony at each Zonal Central Unit-ZCU (Layer1). By using noisy silicon entropy from local edge ECUs to generate unique ZKP proving (pk ) and verification (vk ) keys locally, we eliminate the systemic single point of failure inherent in centralized OTAtrusted setups. This anchors the cryptographic root of trust within the vehicle’s physical zonal topology, providing resilience against global parameter compromise in the OTA cloud. Contribution 4 (Temporal Isolation): We propose a stateless authentication model that integrates silicon PUFs as dynamic witnesses across the vehicle hierarchy (ECUs, ZCUs, and HPC). These physical secrets are generated on-the-fly and reside in volatile memory for only 4.2s during the ZKP generation window. Our evaluation demonstrates a 99.9% reduction in the temporal attack surface for physical key extraction. This model, combined with the ZIDI and HPCA circuits, ensures 100% vehicle-level data sovereignty by eliminating the transmission of sen-
sitive identity metadata to the OTA cloud.
2. Background To contextualize the design and evaluation of zkScalHard, this section delineates the fundamental technological and cryptographic pillars upon which our hierarchical protocol is built. We first describe the Zonal SDV architecture to establish the physical network constraints and trust boundaries of modern vehicles. We then provide an overview of the industry-standard Uptane framework to highlight the specific scalability and privacy gaps our work aims to address. Finally, we formalize the Zero-Knowledge Proof (ZKP) primitives, specifically Groth16 and Plonky3, which serve as the mathematical engines for our multi-tier trust promotion model.
Figure 1. SDV’s Zonal-oriented Architecture (ZoA)
2.1. SDV Zonal Architecture The SDV zonal architecture is a centralised system in which edge ECUs are grouped into 3 to 5 physical zones (e.g., front-left, front-right, centre) as shown in Fig. 1. These are managed by zonal control units (ZCUs) through limitedbandwidth communication protocols such as CAN, CANFD, LIN, and FlexRay. These ZCUs connect to central 2-3 high-performance Computing (HPC) systems via the highspeed AE protocol. The SDV’s HPC connects to the OEM’s OTA update cloud server over the internet to receive frequent software updates.
2.2. Uptane Framework and OTA Update Uptane is the current industry standard for secure Overthe-Air (OTA) updates, extending The Update Framework (TUF) to the automotive context. As illustrated in Fig. 2 [18], it utilizes a ’Separation of Trust’ model involving four primary roles: the Image Repository, the Director Repository, the Primary ECU (HPC), and Secondary ECUs. Security is maintained through Public Key Infrastructure (PKI), where each ECU generates an ECU Version Report (EVR) signed with an asymmetric key. The Primary ECU aggregates these into a Vehicle Version Manifest (VVM). However, this model introduces a linear O(n) metadata dependency; as ECU density increases, the VVM size balloons, leading to significant bandwidth bottlenecks and increased verification latency at the cloud tier. 2.2.1. Operational Workflow and Metadata Lifecycle. The end-to-end update lifecycle and metadata orchestration within the Uptane framework are illustrated in Fig. 3. Algorithm 1 formalizes the high-level operational flow, highlighting the sequential accumulation of individual ECU signatures. The process begins with an OTA update ‘pull’ request at each edge EUC, followed by the generation of an ECU Version Report (EVR). Each ECU’s EVR contains its current firmware hash with a digital signature. As illustrated, the Primary ECU (HPC) collects and bundles n individual EVRs into a comprehensive VVM.
Figure 2. Uptane Secure OTA Update Framework Design (Adapted from [18])
This architecture reveals the fundamental scalability flaw of legacy standards: the VVM size and the subsequent cloud-side verification workload grow linearly (O(n)) with ECU density. For a 100-ECU Zonal SDV, the Director Repository must verify 100 independent signatures per vehicle check-in, creating the computational and communication bottleneck that zk-ScalHard is designed to eliminate through recursive aggregation. 2.2.2. EVR Framework Structure. The ECU Version Report (EVR) is the fundamental unit of attestation in Uptane. As shown in Fig. 4, each EVR contains a physical hardware ID, firmware metadata, and a unique digital signature. While secure for a single node, the requirement that each ECU generate and transmit a full cryptographic signature imposes a significant computational burden at the edge. The comprehensive attestation sequence for edge-node metadata is formalized in Algorithm 6 (Appendix A.1). 2.2.3. VVM Framework Structure. The Vehicle Version Manifest (VVM) is the top-level metadata object transmitted to the cloud. As illustrated in Fig. 5, the VVM is a linear concatenation of all n EVRs within the vehicle. This structure is the primary source of the linear scalability crisis; since the VVM size is O(n), the communication overhead and cloud-side verification time grow proportionally with ECU density. The VVM aggregation and signing logic is delineated in Algorithm 7 (Appendix A.2).
ECU 1
ECU 2
ECU 3
EVR Framework (ECU Version Report)
ECU N
List of n-ECUs Version Reports (one per ECU, signed independently)
Filename
EVR: ECU Version Report Architecture (one EVR per ECU)
Payload EVR Signature Block 1. Public key ID 2. Signing method 3. Hash: {EVR payload hash + Hash()} 4. Signature on EVR payload hash
Image Parameters
ECU ID
EVR Payload Block 1. ECU ID 2. Image: {filename + length + hash} 3. Security attack indicator 4. EVR generated Latest time 5. Nonce / counter
Attack indicator
Length
Hash
EVR Generated Latest Time
detected security attack flag
most recent time ECU can verify
Nonce / counter Public key ID
Signing method
16-bit key ID
ed25519 / rsassa-pss
Hash of EVR Payload Primary ECU Collects and bundles n-ECUs EVR: SIgn VVM
VVM Payload Block 1. Vehicle VIN 2. Primary ECU serial number 3. List of n-ECUs EVR
VVM Framework (Vehicle Version Manifest) Payload
ECU 2 Version Report
ECU 3 Version Report
Vehicle ID
Primary ECU ID
List of all n-ECUs EVR
List of ECU version reports (all with original signatures intact) ECU 1 Version Report
Signature
Figure 4. The individual ECU report (EVR)
VVM: Vehicle Version Manifest Architecture VVM Signature Block signs entire VVM payload 1. Public key ID 2. Signing method 3. Hash: {VVM payload hash + Hash()} 4. Signature on VVM payload hash
Hash ( )
Signature on EVR Hash
ECU N Version Report
Public key ID
Signing method
16-bit key ID
ed25519 / rsassa-pss
Hash of VVM Payload
Hash ( )
Signature
Director repo receives VVM, verifies each EVR using corresponding public key from inventory DB
Signature on VVM Hash
OTA cloud server/Director Repository
Figure 5. The aggregated vehicle manifest, illustrating the linear O(n) growth of the VVM payload
1. Identify the vehicle via decodes the manifest.
2. Query inventory database: Retrieve ECU info for vehicle using the unique vehicle identifier
3. Check manifest for accuracy Verify each ECU in DB is in manifest Primary & Secondary ECU signature checks Validate timestamps in ECU version report Drop request if any check fails
4. Check nonce / counter for replay attacks : Ensure nonce or counter in ECU report has not been used before · Drop if reused
5. Determine images to install Extract current image info from manifest Check if vehicle is up-to-date Resolve dependencies & conflicts using established techniques
6. Encrypt images (if required): Encrypt images for ECUs that require confidential delivery
2.3. ZKP Primitives Zero-Knowledge Proofs (ZKPs) allow a Prover to convince a Verifier of the validity of a statement without revealing the underlying secret (the witness). Our protocol utilizes a hybrid selection of ZKP primitives: •
7. Generate & send metadata to Primary: Create Targets, Snapshot, and Timestamp metadata Send to Primary based on dependency resolution from Step 5
•
Figure 3. Uptane Operational Workflow and Metadata Lifecycle. The diagram illustrates the linear accumulation of n ECU Version Reports (EVRs) into a single Vehicle Version Manifest (VVM), highlighting the O(n) signature-verification bottleneck at the Cloud tier.
Algorithm 1 Uptane OTA Update Request Lifecycle Require: Software update request for n ECUs. Ensure: Fleet-wide authentication and target identification. 1: Tier-0 (Edge): Each secondary ECU generates a signed EVR. (See Algorithm 6 in Appendix). 2: Tier-2 (Hub): Primary ECU collects n EVRs and bundles them into a signed VVM. (See Algorithm 7 in Appendix). 3: Tier-3 (Cloud): Director Repository validates the VVM against the inventory database and determines the required software images for all n ECUs. (See Algorithm 8 in Appendix).
Groth16: A pairing-based zk-SNARK known for its ultra-succinct proof size (256 bytes) and constanttime verification. We utilize Groth16 for Tier-1 (ZCU-to-HPC) communication where internal bus bandwidth is the primary constraint. It requires a one-time ”Trusted Setup,” which we decentralize via our Zonal MPC ceremony. Plonky3 / FRI-based SNARKs: These are ”transparent” protocols that do not require a trusted setup and offer Post-Quantum (PQ) resilience by relying on hash-based polynomial commitments (FRI). We utilize these at Tier-2 (HPC-to-Cloud) to provide long-term security against quantum adversaries and to enable Recursive Aggregation, allowing the vehicle to compress multiple zonal proofs into a single vehicle-level attestation.
3. Adversary Model and Design Goals In this section, we formalize a robust adversarial model A′ spanning the vehicle’s physical silicon (Layer-0) to the OEM’s OTA cloud infrastructure (Layer-3). Furthermore, we establish the core design requirements for achieving a ′
secure, scalable, and privacy-preserving authentication protocol for OTA updates in Zonal SDV.
3.1. Adversary Model We categorize the adversarial threat landscape into two primary vectors based on the Zonal SDV’s architectural topology: vertical (Silicon-to-Cloud) and horizontal (Device-to-Network). This dual-perspective approach ensures a comprehensive analysis of both physical-layer vulnerabilities and logical network exploits.
3.2. Design Goals To mitigate the aforementioned vertical and horizontal threat vectors, we establish the following four system-level security and performance requirements for the zk-ScalHard protocol. •
3.1.1. Vertical Threat Vector (Silicon-to-Cloud). •
•
Physical Level (The Silicon): The adversary ′ A′ is assumed to have temporary physical access to the vehicle’s ECUs/ZCUs (e.g., during maintenance or at a service station). This enables ‘A’ to execute physical attacks, including voltage glitching and side-channel analysis (SCA), on persistent flash memory to extract digital secrets, such as stored private keys. Infrastructure Level (The Cloud): ′ A′ may act as an external attacker targeting the centralized OEM’s OTA server or act as a malicious insider with administrative access privileges. The main goal of ‘A’ is to compromise the ”Toxic Waste” (the secret parameters of the trusted setup) to enable the forgery of authentication proofs for the entire vehicle fleet.
•
•
3.1.2. Horizontal Threat Vector (Node-to-Network). •
•
Node Level (Central HPC): The central HPC in a Zonal SDV serves as the primary logical attack surface, as it acts as the gateway between the internal zonal backbone and external network interfaces. We assume ′ A′ can exploit software vulnerabilities during the OTA update process to achieve rootlevel privilege escalation within the HPC’s execution environment. In this compromised state, the ′ A′ acts as a malicious aggregator, capable of intercepting internal zonal metadata or attempting to bypass the secure boot sequence to gain persistent remote control over the vehicle’s central computing functions. Network Level (IV/V2I Communication): We adopt the Dolev-Yao adversary model to characterize threats across both in-vehicle (IV) and vehicle-toinfrastructure (V2I) channels. In this model, the adversary ′ A′ can sniff, intercept, and replay messages transmitted over the internal CAN-FD or Automotive Ethernet backbones. Furthermore, ′ A′ can manipulate V2I traffic exchanged via the Internet between the vehicle and the OEM cloud. By executing Man-in-the-Middle (MITM) and replay attacks, the adversary aims to capture valid zk-ScalHard proofs and reuse them to impersonate a legitimate ECU or ZCU, thereby compromising the overall integrity of the Zonal SDV.
•
Goal 1. Hierarchical Trust Promotion: The vehicle authentication protocol must establish a multitier trust hierarchy that bridges the gap between resource-constrained edge ECUs (Layer-0) and highperformance OTA server (Layer-3). The objective is to align cryptographic intensity with heterogeneous hardware capabilities, ensuring that the overall system security is orchestrated from the silicon level up to the cloud without overburdening low-power edge nodes. Goal 2. Asymptotic Scalability: The protocol must achieve constant-size O(1) complexity for both communication overhead and verification latency. This requirement ensures that the authentication tax remains invariant as the number of vehicle edge ECUs (n) increases, effectively decoupling the security overhead from the Zonal SDV’s architectural complexity. Goal 3. Decentralized Trust Initialization: The protocol must facilitate the in-situ generation of unique ZKP proving (pk) and verification (vk) keys within each ZCU. By deriving the necessary secret randomness (i.e., ’toxic waste’) locally via multi-party computation, the system must eliminate the systemic single point of failure inherent to centralized trusted setups. This ensures that a compromise of a global server cannot be leveraged to forge credentials for the entire vehicle fleet. Goal 4. Temporal Secret Isolation and Sovereignty: The protocol must ensure that the unique secrets (witnesses) of vehicle nodes are ephemeral, generated on-the-fly, and resident in volatile memory only during the transient execution window of the ZKP generation. By eliminating the reliance on static private keys resident in persistent Flash memory, the system must minimize the temporal attack surface for physical extraction. This approach ensures 100% vehicle data sovereignty, protecting the vehicle’s physical identity from long-term side-channel analysis and memory-dump exploits.
4. The zk-ScalHard Architecture - The ”Trust Pyramid” We introduce zk-ScalHard, a novel multi-tier hierarchical trust pyramid architecture (Fig. 6) anchored in a ‘Silicon-to-Cloud’ security philosophy. This architecture is designed to support scalable vehicle-to-cloud authentication throughout the secure OTA update lifecycle in Zonal SDVs. As illustrated in the authentication flow (Fig. 7), it orchestrates trust from the physical hardware (edge ECUs)
ity
il ab
tP rom oti Tr us
Layer-2
Layer-3
ZCU 1
1 HPC
Cloud (OTA)
ECU 1 al Sc
{1 HPC. Aggregation}
Layer-2: Central Aggregator (HPCA)
Layer-1
tic
Layer-3: Global Governance
pto ym
Layer-0
{1Cloud. Authentication}
As
on
Silicon-to-Cloud Authentication: Trust Promotion, Asymptotic Scalability, & Data Sovereignty
ECU 25
{4 ZCUs. In-Situ MPC Ceremony} Layer-1: Zonal Integrity (ZIDI)
ZIDI Circuit Proof (L1 -> L2)
{100+ Edge ECUs. Silicon PUFs. Physical Entropy} Layer-0: Hardware Root of Trust
HPCA Circuit Proof (L2 -> L3)
Data Sovereignty
Figure 7. Vehicle-to-Cloud Authentication During Secure OTA Update Lifecycle Figure 6. The zk-ScalHard Hierarchical Trust Pyramid
to the global cloud (OTA server) based on three primary design principles: (i) Trust promotion through hierarchical attestation, (ii) Asymptotic scalability leveraging recursive proof aggregation, and (iii) Data sovereignty via hardwarerooted silicon PUFs. Upon initiating an OTA update request, the architecture escalates cryptographic strength across tiers: edge ECUs (Layer-0) first perform symmetric MAC-based authentication to their respective ZCUs. Subsequently, each ZCU (Layer-1) authenticates to the central HPC via a zk-SNARKbased ZIDI proof. Finally, the vehicle’s central HPC (Layer2) aggregates these zonal proofs into a single, asymptotically compressed HPCA proof for verification by the global OTA server (Layer-3). The detailed operations of each layer are discussed below.
4.1. Layer-0: The Hardware Root of Trust This layer anchors each edge ECU’s identity to its unique Silicon PUF, replacing persistent digital keys. These physical secrets are never stored in non-volatile Flash memory; instead, they are reconstructed on-the-fly in response to an OTA update request. The PUF response serves a dual purpose: (i) it provides the entropy for symmetric MAC generation during local ZCU authentication, and (ii) it serves as the source of noisy entropy (i.e., ‘toxic waste’) for the in-situ Zonal MPC ceremony executed at Layer-1.
4.2. Layer-1: The Zonal Integrity (ZIDI) In this tier, each ZCU operates as a ‘Zonal Judge’ responsible for validating the integrity of its local zone subECU. To establish a decentralized root-of-trust, each ZCU executes an in-situ ‘Zonal MPC Ceremony’ (offline Phase 2, see Section 5) utilizing the noisy PUF entropy from its 25
local edge ECUs to generate a vehicle’s zonal-unique pair of proving (pk) and verification (vk) keys. This process ensures that the ‘toxic waste’ is consumed and destroyed locally within the zonal hardware. During the runtime OTA update cycle (online Phase 3, see Section 5), the ZCU verifies the 25 sub-ECU MACs and utilizes the ZIDI circuit to generate a succinct 809byte proof. This proof is constructed using the ZCU’s own Silicon PUF as a ‘private witness’, which is reconstructed on-the-fly and immediately purged from volatile memory post-execution. The ZCU subsequently transmits only the proof to the central HPC, which utilizes the pre-distributed vk to verify the zone’s integrity without ever accessing the raw silicon identities.
4.3. Layer-2: Central Aggregation (HPCA) The Zonal SDV’s HPC serves as the vehicle’s central processing hub. It acts as a ‘transparent’ aggregator, consolidating the vehicle’s global security state to achieve asymptotic O(1) scalability. Upon receiving the four ZIDI proofs from the Layer-1 ZCUs- collectively representing the integrity of 100 edge ECUs- the HPC executes the HPCA circuit. This circuit performs recursive aggregation and mathematically validates the four zonal proofs while simultaneously integrating the HPC’s on-the-fly PUF-derived witness. This process culminates in a single, vehicle-level proof of constant size (805 bytes) that encapsulates the metadata integrity of the entire vehicle (100 ECUs, 4 ZCUs, and the HPC). The resulting succinct proof is then transmitted to the OTA cloud server for final vehicle-to-cloud authentication.
4.4. Layer-3: Global Governance In this final tier, the OEM’s OTA cloud server acts as the global verifier for the vehicle fleet. Upon receiving
the constant-size proof from the vehicle’s HPC, the cloud retrieves the corresponding verification key (vk) from its ‘Digital Twin’ database (originally generated during the offline Phase-2 Factory Ceremony, see Section 5), to validate the attestation. Because the vehicle transmits a single aggregated proof, the cloud performs only a single O(1) verification. This ensures that the cloud-side computational tax remains invariant regardless of the internal vehicle’s complexity (i.e., the number of ECUs and ZCUs). Ultimately, the OTA server only learns the vehicle’s binary integrity state; the granular metadata on ECU versions and raw silicon PUF responses remains hidden. This architecture guarantees 100% data sovereignty and full compliance with the GDPR mandates by ensuring that no personally identifiable information (PII) or sensitive configuration data ever leaves the vehicle’s secure environment.
5. Technical Design and Implementation This section describes the formal technical design and implementation of the zk-ScalHard protocol. We first formalize the arithmetic logic for the ZIDI and HPCA circuits, which underpin our claims of decentralized trust initialization and asymptotic scalability. Furthermore, we discuss the temporal secret isolation mechanism that governs the lifecycle of the physical PUF witness. Finally, we describe the implementation specifics, including the arithmetic primitives and the simulation environment used to characterize the protocol’s performance.
5.1. ZIDI Circuit: Zonal Integrity and Trust Initialization The ZIDI circuit design is divided into three phases: Phase 1. Global arithmetic circuit design (offline/ compiletime), Phase 2. In-Situ trust initialization (offline/factoryenrollment), and Phase 3. Runtime authentication (online/ update-cycle). The detailed description of these phases is as follows. 5.1.1. Phase-1: Global arithmetic circuit design (offline/compile-time). This phase focuses on the ZIDI arithmetic logic, implemented in Circom 2.1. The OEM engineers develop this circuit once (offline) and use it across all vehicles, serving as a universal security blueprint. While the blueprint is universal, unique zonal ZKP parameters are generated for each vehicle instance. To accommodate the Zonal SDV’s resource-constrained environment, we implemented a ‘tiered 5x5 hashing’ strategy to aggregate the 25 sub-ECU MACs into five sub-groups using the Poseidon hash function. This tiered approach overcomes the 16-input limit of the Poseidon library primitives. By leveraging optimized permutation constants, the circuit maintains high integrity within a hierarchical structure. Compiling the ZIDI circuit into a Rank-1 Constraint System (R1CS) yields 2,163 non-linear constraints. This succinct constraint count makes it feasible to execute the
Algorithm 2 ZIDI Circuit Arithmetic Constraints (CZIDI ) Require: Private Signals (Witness W ): 1: Wpuf ∈ Fp {Silicon PUF stable bitstring} 2: Wmacs [25] ∈ F25 p {Array of 25 Edge-ECU MACs} Require: Public Signals (Statement X ): 3: IDzcu ∈ Fp {Registered Zonal Identity} 4: Hagg ∈ Fp {Expected Zonal Integrity Root} 5: N ∈ Fp {Freshness Nonce from HPC} 6: Constraint 1: Identity Anchoring 7: hpuf ← Poseidon1 (Wpuf ) 8: assert hpuf ≡ IDzcu {Ensures hardware-software binding} 9: Constraint 2: Tiered Integrity Aggregation 10: for i = 0 to 4 do 11: {Level 1: Hash 5 groups of 5 ECUs} 12: hsub,i ← Poseidon5 (Wmacs [5i . . . 5i + 4]) 13: end for 14: {Level 2: Compute Zonal Root from sub-hashes} 15: hroot ← Poseidon5 (hsub,0 , hsub,1 , hsub,2 , hsub,3 , hsub,4 ) 16: assert hroot ≡ Hagg {Validates 25 ECU states in O(1)} 17: Constraint 3: Temporal Binding 18: dummy ← N ×N {Forces Nonce into R1CS to prevent
replay} 19: return
πzonal {Succinct Zonal Proof}
circuit on 32-bit automotive microcontrollers (ECUs/ZCUs). The algorithmic steps for Phase 1 are detailed in Algorithm 2. 5.1.2. Phase-2: In-Situ trust initialization (offline/factory enrollment). In this phase, the OEM executes the universal ZIDI circuit’s R1CS within each vehicle zone to initiate the In-Situ Zonal MPC Ceremony and generate unique ZKP parameters (pk, vk). This one-time factory enrollment (offline) establishes a unique cryptographic trust relationship within the vehicle’s zonal hardware. The process begins with the ZCU collecting noisy silicon PUF responses from 25 local edge ECUs as physical entropy to derive the secret randomness T (called ‘toxic waste’ ). To accommodate the tiered Poseidon logic defined in Phase 1, we utilize a ‘Powers of Tau’ setup with 214 (16,384) constraint capacity. We utilize the Groth16 setup protocol, taking R1CS and T as inputs to generate a zonal-unique pair of ZKP parameters (pk, vk). The proving key (pk) is provisioned to the ZCUs’ secure Flash memory for use in Phase 3 proof generation, while the verification key (vk) is stored within the vehicle’s central HPC for the subsequent verification phase. Finally, the master entropy (T ) is immediately purged from the volatile memory, ensuring that even the OEM or OTA server cannot forge proofs for the vehicle during its OTA update lifecycle. The algorithmic steps for Phase 2 are detailed in Algorithm 3. 5.1.3. Phase-3: Runtime authentication (online/ updatecycle). This phase is an online operation in which each ZCU performs a 2-way, stateless handshake with the central
Algorithm 3 In-Situ Zonal MPC Trust Initialization Require: Entity: Zonal Controller (ZCUj ), Child ECUs {E1 . . . E25 } Require: Input: Universal R1CS blueprint CZIDI 1: Step 1: Physical Entropy Collection 2: for each Ei ∈ {E1 . . . E25 } do 3: Si ← Trigger PUF(Ei ) {Extract physical silicon noise} 4: end for P 5: τ ← Poseidon( Si ) {Derive local ’Toxic Waste’} 6: Step 2: Parameter Generation (Groth16) 7: {pkj , vkj } ← Groth16.Setup(CZIDI , τ ) 8: Step 3: Secure Provisioning 9: Write(pkj ) → ZCUj .SecureFlash 10: Write(vkj ) → HPC.TrustStore 11: Step 4: Anti-Forensic Purge 12: Erase(τ ) {Master secret destroyed locally} Ensure: Unique Zonal Parameters {pkj , vkj }
HPC during an OTA update. The process begins with the HPC (verifier) issuing a ‘Nonce’—a unique 256-bit random challenge to prevent replay attacks. Upon receiving the ‘Nonce’, the ZCU initiates proof generation by executing the ZIDI prover function with four inputs: (i) its stable silicon PUF bits, reconstructed on-the-fly to serve as a dynamic private witness, (ii) 25 local ECU MACs (from Phase 2), (iii) its unique proving key (pk), and (iv) the ‘Nonce’. This process results in a succinct 809-byte zk-proof (π ). The ZCU transmits π to the HPC, which verifies the proof using the corresponding verification key (vk). Crucially, the HPC achieves constant verification complexity O(1), as the mathematical operations remain invariant regardless of the number of ECUs (n=25). While the total ZCU proving latency is ≈ 4.2s, the verification is near-instant. Throughout this process, raw PUF bits are never transmitted across the vehicle network, ensuring 100% vehicle data sovereignty. Finally, the ZCU purges the PUF witness from RAM, achieving temporal isolation. These Phase-3 steps are formalized in Algorithm 4.
Algorithm 4 Tier-1: Zonal Integrity Handshake Require: Prover: ZCUj with pkj ; Verifier: HP C with vkj 1: HPC → ZCU: Request Update + N once (N ) 2: ZCU Operation: 3: Wpuf ← Reconstruct PUF(ZCUj ) 4: Wmacs ← Collect ECU MACs(E1...25 ) 5: πzonal ← Prove(pkj , [Wpuf , Wmacs ], [ID, Hstate , N ]) 6: ZCU → HPC: πzonal {Succinct 809-byte proof} 7: HPC Operation: 8: if Verify(vkj , πzonal , N ) ≡ 1 then 9: return ZONE_AUTHENTICATED 10: else 11: return ABORT_SESSION 12: end if 13: ZCU: Purge(Wpuf ) from RAM {Temporal Isolation} Algorithm 5 Tier-2: HPCA Recursive Aggregation Require: Prover: HP C ; Verifier: Cloud Require: Input: 4 Zonal Proofs {πzonal,1...4 } Require: Circuit: CHP CA with Proving Key pkhpc 1: Step 1: Inner Proof Verification 2: for j = 1 to 4 do 3: assert VerifyZIDI (vkj , πzonal,j ) ≡ 1 4: end for 5: Step 2: Identity & State Folding 6: Whpc ← Reconstruct PUF(HP C) 7: Hglobal ← Poseidon(Root1 , . . . , Root4 ) 8: Step 3: Global Proof Generation 9: πveh ← Prove(pkhpc , [{πzonal }, Whpc ], [IDveh , Hglobal ]) 10: HPC → Cloud: πveh {Constant-size 805-byte proof} Ensure: Asymptotic O(1) Vehicle-to-Cloud Attestation
entire vehicle state in constant time using the corresponding verification key (vk). These Phase-3 steps are formalized in Algorithm 5.
5.3. Temporal Secret Isolation Mechanism 5.2. HPCA Circuit: Recursive Proofs Aggregation The central HPC acts as a ‘Recursive Aggregator’, executing the HPCA circuit to aggregate the proofs from the four Layer-1 ZCUs. The circuit consumes three primary inputs: (i) the four ZIDI zonal proofs, (ii) the HPC’s stable PUF response, reconstructed on-the-fly as a private witness, and (iii) the proving key (pk). The HPCA circuit is extremely efficient, consisting of only 518 non-linear R1CS constraints. The HPCA prover function mathematically folds these zonal states into a single, vehicle-to-cloud proof (≈ 805bytes). This succinct proof encapsulates the vehicle’s global integrity state (covering 100 ECUs, 4 ZCUs, and the HPC) and achieves asymptotic O(1) scalability. Finally, the HPC transmits this proof to the OTA cloud server, enabling the cloud to verify the
The zk-ScalHard protocol utilizes a hardware-rooted, device-unique silicon PUF as a ‘stateless witness’, in contrast to legacy systems that rely on persistent digital keys stored in non-volatile Flash memory. During the vehicle’s idle state (no active OTA requests), no secrets reside in volatile or non-volatile memory, effectively maintaining a ‘zero-secret attack surface’. The device’s physical PUF response is triggered only upon a valid OTA update request; the secret is reconstructed on the fly in volatile memory, which takes 357ms. Subsequently, the ZKP prover (ZIDI or HPCA) consumes this witness to generate the proof over 3,885ms. Immediately upon proof completion, the witness is ‘securely purged’ from the volatile memory. Consequently, the secret identity is present in the system for only ≈ 4.2s during the OTA update lifecycle.
We demonstrated this (see Section 7, Fig. 10) and compared it with legacy secret exposure over 24 hours. Our protocol achieves a 99.9% reduction in the temporal attack surface.
circuits. Given valid PUF witnesses and correct ECU MACs, the Poseidon-based constraints will always satisfy the R1CS requirements, resulting in a valid proof π.
5.4. Implementation and Benchmarking Environment
Theorem 2 (Soundness). For any probabilistic polynomialtime (PPT) adversary A, the probability that A can generate a valid proof π without knowledge of a valid Silicon PUF witness or a valid set of ECU MACs is negligible. The soundness relies on the collision-resistance of the Poseidon hash function and the discrete-logarithm hardness of the Groth16/Plonky3 schemes. An adversary cannot forge π without the physical PUF response, as the probability of a witness collision is negligible.
The zk-ScalHard protocol’s ZIDI and HPCA circuits are implemented using the Circom 2.1.6 hardware description language and the Poseidon-2 hash primitive to generate universal R1CS constraints. We utilize the Groth16 ZKP proving system and the SnarkJS framework to generate the proving (pk) and verification (vk) parameters, ensuring a constant succinct proof size ≈ 805bytes and constant verification complexity. To evaluate the protocol, we conducted Software-inLoop (SIL) benchmarks within a virtualized Ubuntu 22.04 LTS environment via WSL2. The host system specifications included an 11th Gen Intel Core i5-1135G7 CPU @ 2.40GHz, 8GB of RAM, and Windows 10. For the legacy baseline, we utilized the Uptane Python reference implementation to quantify the linear O(n) metadata overhead and verification latencies. Finally, to facilitate reproducibility and support open science, the official implementation of zkScalHard and benchmarking scripts are hosted in a public GitHub repository: https://anonymous.4open.science/r/zk-S calHard-8C52/README.md
6. Security and Resilience Analysis We evaluate the security posture of zk-ScalHard against the adversary model A defined in Section 3. Table 2 provides a comprehensive mapping of identified threat vectors to our protocol’s specific mitigation mechanisms. This matrix ensures that the hierarchical trust model provides end-to-end coverage, from physical silicon integrity to global cloudlevel verification. TABLE 2. S ECURITY M ATRIX : M APPING T HREATS TO ZK -S CAL H ARD M ECHANISMS Threat Vector (Sec 3) Physical Key Extraction Network MITM / Replay Malicious HPC Aggregator Infrastructure Leakage Quantum Forgery
zk-ScalHard Mechanism Silicon PUF + Temporal Isolation Nonce-Bound R1CS Constraints Recursive Proof Verification In-Situ Zonal MPC Ceremony FRI-based PQ-ZKP (Tier-2)
Security Property Physical Unforgeability Strong Freshness Integrity Isolation Decentralized Trust PQ-Resilience
6.1. Formal Security Properties In this section, we formalize the security of the zkScalHard protocol through the following theorems. Theorem 1 (Completeness). If the Prover (ZCU/HPC) and the Verifier (HPC/Cloud) are honest and follow the zkScalHard protocol, the verification of the aggregated proof πveh will always succeed with probability 1. The completeness of zk-ScalHard is derived from the deterministic nature of the ZIDI and HPCA arithmetic
Theorem 3 (Zero-Knowledge). The zk-ScalHard protocol is zero-knowledge; the Verifier gains no information about the vehicle’s internal configuration (ECU versions) or raw Silicon PUF responses, other than the validity of the integrity state. The protocol achieves computational zero-knowledge by ensuring that the proof π is a succinct commitment that does not leak the underlying witness W . The verifier only learns the binary validity of the state, preserving 100% vehicle configuration privacy.
6.2. Resilience to Physical Key Extraction As quantified in Fig. 10, we achieve temporal isolation. By ensuring the PUF witness exists only during the ≈ 4.2s proving window, we render physical probing attacks statistically infeasible.
6.3. Resistance to Network-Layer Attacks Nonce-binding within the ZIDI circuit ensures that each proof is cryptographically tied to a unique session challenge, effectively neutralizing Man-in-the-Middle (MitM) and replay attacks.
6.4. Integrity under Aggregator Compromise Even if the central HPC is logically compromised, it remains incapable of forging zonal proofs. The ZCUs maintain physical isolation of the PUF witnesses, ensuring that the ’malicious aggregator’ cannot subvert the vehicle’s global integrity state.
6.5. Quantum-Blast-Radius Control By decentralizing the trust ceremony via Zonal MPC, we isolate the impact of a potential cloud-level parameter compromise. Each vehicle maintains a unique, in-situ initialized root-of-trust.
7. Performance Evaluation
Legacy (Uptane VVM) - O(n) zk-ScalHard (Ours) - O(1)
In this section, we evaluate the performance of the zk-ScalHard protocol through a comparative analysis with the industry-standard Uptane framework. We utilize three primary metrics to characterize the system’s performance: (i) asymptotic communication complexity, (ii) asymptotic verification complexity, and (iii) temporal attack surface reduction. As detailed in Section 5.4, all benchmarks were conducted within a ‘SIL’ simulation environment. To test the architecture’s scalability limits, we used a high-density configuration of 100 ECUs in the Zonal SDV model. The results empirically validate our claims of constant O(1) scalability, hardware-rooted physical-layer resilience, and 100% data sovereignty throughout the Zonal SDV’s OTA update lifecycle.
V2I Payload Size (KB)
100 80 60 40
99.2% Bandwidth Reduction
20 0
0
7.2. Asymptotic Verification Complexity We evaluate the computational scalability of the vehiclecloud verification process, with results depicted in Fig. 9. Our results show that the Uptane framework suffers from a linear O(n) verification bottleneck, requiring 15.47s to validate the 100 individual ECU signatures within a single VVM. This linear dependency makes legacy attestation unsustainable for high-density vehicle fleets. In contrast, zkScalHard achieves constant verification complexity, O(1). By using the HPCA circuit at HPC Layer-2 to aggregate zonal proofs, the OTA cloud server only performs a single mathematical verification. As illustrated in Fig. 9, zk-ScalHard achieves an efficiency crossover at n = 14 ECUs, outperforming legacy standards across all modern Zonal SDV configurations. While our prototype exhibits a constant simulation latency of 2.1s due to the high-level Node.js runtime and virtualized WSL environment, the mathematical complexity remains invariant. Specifically, at a scale of 100 ECUs, the comparison between zk-ScalHard (2.1s) and Uptane (15.47s) demonstrates a 7.3x computational speedup. This result confirms that zk-ScalHard is computationally superior
50
75
Number of ECUs in Zonal SDV
100
Figure 8. Asymptotic Communication Complexity
7.1. Asymptotic Communication Complexity
Legacy (Uptane) - O(n) zk-ScalHard (Ours) - O(1)
104
Verification Latency (ms) - Log Scale
Figure 8 illustrates the communication-overhead advantages of zk-ScalHard within the Zonal SDV environment. Our benchmarks show that the V2I payload for the industrystandard Uptane framework grows linearly, O(n), because the vehicle version manifest (VVM) must bundle individual reports and digital signatures for every ECU. For a 100ECU configuration, the Uptane VVM reaches 98.6KB . In comparison, zk-ScalHard achieves a constant-size O(1) vehicle payload by utilizing a succinct HPCA proof of only 809B . This represents a 99.2% reduction in communication overhead. Consequently, zk-ScalHard ensures that network overhead remains invariant with respect to vehicle complexity, maintaining bus stability even as ECU density exceeds 100 nodes.
25
103
Efficiency Crossover (n=14)
1
14
25
50
75
Number of ECUs in Zonal SDV
100
Figure 9. Verification Complexity: O(n) vs. O(1) Scalability
to Uptane even within a non-optimized simulation environment. Furthermore, projecting these results onto productiongrade ‘hardware security modules (HSMs)’, where verification is optimized to ≈ 5ms (see Section 2), zk-ScalHard enables near-instantaneous fleet-wide attestation with zero computational growth.
7.3. Temporal Attack Surface Reduction Figure 10 quantifies the reduction in the ‘temporal vulnerability window’ by integrating Silicon PUFs as ephemeral witnesses, replacing persistent digital secrets. This architectural shift effectively neutralizes physical-layer threats. In legacy frameworks like Uptane, cryptographic keys are stored in non-volatile memory, resulting in a 24/7 exposure window (8.64x107 ms per day). Conversely, zkScalHard’s physical secrets are reconstructed on-the-fly and exist in volatile memory only during the ZK-proving window (≈ 4, 242ms). Our evaluation demonstrates a 99.99% reduction in the temporal attack surface. This ‘temporal
Vulnerability Window (ms) - Log Scale
108
86,400,000 ms
107
106
99.995% Surface Reduction
105
104 4,242 ms
Legacy (Persistent Key)
zk-ScalHard (Ephemeral Witness)
Moving the Security Anchor from Flash (24/7) to a Temporal Window (ms).
Figure 10. Temporal Attack Surface: Persistent vs. Ephemeral Secrets
isolation’ renders physical key extraction—such as sidechannel analysis (SCA) or hardware probing—statistically infeasible, as the secret witness is securely purged before an adversary can successfully exploit it.
8. Discussion and Compliance zk-ScalHard is designed to align with the evolving automotive regulatory landscape. By achieving 100% vehiclelevel data sovereignty, the protocol satisfies the GDPR ’Data Minimization’ principle, as sensitive metadata never leaves the vehicle’s secure enclave. Furthermore, the temporal isolation of secrets addresses the ’Security-by-Design’ mandates of the EU Cyber Resilience Act (CRA) and UNR 155/156, providing a robust defence against the full lifecycle of physical and remote threats in Zonal SDVs.
9. Related Work The existing literature on SDVs has been extensively studied, and we categorise it into four domains: industry standards, privacy-preserving credentials, post-quantum cryptography, and ZKP-based frameworks. While these domains provide robust solutions in isolation, the transition to Zonal SDV architecture (ZoA) demands a “hybrid model with collision of constraints” - high ECU density, limited & high bandwidth (i.e., CAN-FD and high-speed Ethernet), and data privacy & sovereignty needs. In this section, we evaluate these domain categories to highlight the trilemma gap -“Scalability, Privacy, and Resilience” that zk-ScalHard bridges. Industry Standards (Uptane, AUTOSAR): The current secure OTA updates industry standards are Uptane [11], [12], [19], [20], [21], [22] and AUTOSAR [23], [24], [25]. Since both standards are built primarily using PKI
infrastructure, these are robust frameworks. While Uptane provides secure OTA updates by solving the “Separation of Trust” problem, it is the current industry ‘gold standard.’ On the other hand, these standards’ reliance on PKI-based linear signature accumulation leads to the ‘Metadata Blast’ we quantified in Section 1.2. This does not solve the O(n) bandwidth issue; for a 100-ECU scale, the 98.6 KB payload becomes a network liability. Our zk-ScalHard protocol replaces the linear signature set with ‘Recursive Aggregation’ and is the first to achieve O(1) communication complexity, a feature that current Uptane [12] and AUTOSAR [24] frameworks lack. Privacy-Preserving Credentials (Idemix, U-Prove): Existing privacy-preserving credential solutions like Idemix [13], [14], [26] and U-Prove [15] provide strong identity privacy using a ‘Zero-Knowledge’ approach. These are built for high-power platforms such as Hyperledger [14], cloud servers, and XML-heavy web protocols. Further, these are non-aggregable and computationally too heavy RSA math for resource-constrained 32-bit ZCUs. Where zk-ScalHard resolves this gap by utilizing ZKP-friendly Poseidon hashes [27], [28] and recursive SNARKs to aggregate 100+ ECUs’ identities into a single succinct proof, allowing privacypreserving attestation that fits within the limits of SDV’s control units. Post-Quantum Signatures: Recent efforts to NISTstandardize PQC like Dilithium and Falcon [16] to defend against Shor’s algorithm and to integrate PQC signatures into V2X [17]. These address the quantum threats but ignore the Physical Layer Constraints of the vehicle bus. That is, a single Dilithium signature is ≈ 22.5KB ; in Zonal SDV, with 100 ECU signatures, the result is 375 KB. This leads to high-density zonal attestation and on the vehicle’s internal CAN-FD network brick. zk-ScalHard achieves PQ-resilience using FRI-based ZKPs (Plonky3) while maintaining a significantly smaller, constant 805-byte footprint compared to linear PCQ signatures. ZKP Frameworks: Available ZKP frameworks [29], [30], [31], [32], [33] are general-purpose and show the maturity of ZKP libraries. While most of these consider the underlying system to be ‘Flat Architecture’ and ignore the temporal attack surface. That is, they lack the ‘Hybrid Hierarchical Orchestration’ required for Zonal SDVs (ECU → ZCU → HPC → Cloud). Further, many existing ZKPbased solutions [34], [35], [36], [37], [38] assume a singletier prover-verifier model, and they don’t understand the ‘Trust Promotion’ requirement in the secure OTA updates for Zonal SDVs. Hence, these fail in Zonal SDV architecture. Our proposed zk-ScalHard solution is the first to propose a ‘Hybrid Hierarchical Trust Model’ that matches cryptographic intensity to specific hardware tiers (Symmetric → Succinct → Recursive). In addition, zk-ScalHard is the first to integrate PUFs as ‘Dynamic ZKP Witnesses’ in a Hierarchical Trust Pyramid, reducing the attack surface window from 24/7 to 4.2s.
10. Conclusion and Future Work We presented zk-ScalHard, a hardware-rooted ZKP protocol that achieves constant-size O(1) scalability for SDV authentication. Our evaluation demonstrates a 99.2% reduction in bandwidth and a 99.9% reduction in the physical attack surface. Future work will focus on Hardware-in-theLoop (HiL) validation in collaboration with the Inria Astra Team (Paris) to characterize the protocol on productiongrade NXP S32G vehicle network processors.
Acknowledgment This work was supported by the MSCA Seal of Excellence (SoE) Fellowship at Inria Lille, France, funded by the University of Lille. The authors are grateful to the SERENDIPITY Team (Inria) and the SPRITZ Security & Privacy Research Group (University of Padua) for the collaborative research environment. Shrikant Tangade acknowledges the support of the Anuvartik Mirji Bharatesh Institute of Technology (VTU-affiliated), Belagavi, India, for his sabbatical and the establishment of the autoMoTIVe-X Lab. We also thank the IEEE VTS Bangalore Chapter for its leadership in the Automotive Cybersecurity CoE initiative.
References
[10] H. Anand, “Software-defined vehicles: The 4 dimensions of adoption and the OEMs moving fastest,” https://iot-analytics.com/software-d efined-vehicles-adoption-4-dimensions-leading-oems/, 2026. [11] T. Karthik, “Uptane: Securing Software Updates for Automobiles,” in Proc. 14th escar Europe, 2016. [12] ——, “Securing Software Updates for Automotives Using Uptane,” USENIX ;login:, vol. 42, no. 2, 2017. [13] IBM, “IBM Identity Mixer: Authentication without identification,” IBM Research, Tech. Rep., 2015. [Online]. Available: https: //www.zurich.ibm.com/pdf/csc/Identity Mixer Nov 2015.pdf [14] Hyperledger Fabric, “MSP Implementation with Identity Mixer,” ht tps://hyperledger-fabric.readthedocs.io/en/release-1.3/idemix.html, 2018. [15] C. Paquin, “U-Prove Technology Overview V1.1, Revision 3,” Microsoft Corporation, Tech. Rep., 2023. [16] G. Alagic et al., “Status Report on the Third Round of the NIST PostQuantum Cryptography Standardization Process,” National Institute of Standards and Technology (NIST), Gaithersburg, MD, USA, Tech. Rep. NIST IR 8413-upd1, 2022. [17] P. Ravi, V. K. Sundar, A. Chattopadhyay, S. Bhasin, and A. Easwaran, “Authentication Protocol for Secure Automotive Systems: Benchmarking Post-Quantum Cryptography,” in Proc. IEEE International Symposium on Circuits and Systems (ISCAS), 2020, pp. 1–5. [18] Uptane Project. (2024) Uptane Design Overview. https://uptane.org/l earn-more/design. Accessed: 2026-06-12. [19] R. Lorch, D. Larraz, C. Tinelli, and O. Chowdhury, “A Comprehensive, Automated Security Analysis of the Uptane Automotive Over-the-Air Update Framework,” in Proc. 27th Int. Symposium on Research in Attacks, Intrusions and Defenses (RAID). ACM, 2024, pp. 594–612.
[1]
C. Hinton, “Tesla Leads in Recalls in 2024: More than one in four vehicles on U.S. roads—totaling 72.7 million—carry at least one open recall,” https://www.thebuzzevnews.com/2024-vehicle-recall-trend s-safety-insights/, 2025.
[2]
UNECE, “UN Regulation No. 155 - Cyber security and cyber security management system,” United Nations Economic Commission for Europe, Tech. Rep., 2021. [Online]. Available: https://unece.org/tran sport/documents/2021/03/standards/un-regulation-no-155-cyber-sec urity-and-cyber-security
[3]
——, “UN Regulation No. 156 - Software update and software update management system,” United Nations Economic Commission for Europe, Tech. Rep., 2021.
[4]
ISO/SAE, “ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering,” International Organization for Standardization, Standard, 2021.
[23] C. Bodei, M. D. Vincenzi, and I. Matteucci, “Formal analysis of an AUTOSAR-based basic software module,” Int. J. Softw. Tools Technol. Transfer, vol. 26, pp. 495–508, 2024.
[5]
ISO, “ISO/SAE 24089:2023 Road vehicles — Software update engineering,” International Organization for Standardization, Standard, 2023.
[24] AUTOSAR, “Requirements on Secure Onboard Communication,” AUTOSAR, Tech. Rep. Document ID 653, 2025. [Online]. Available: https://www.autosar.org/fileadmin/standards/R25-11/FO/AUTOSAR FO RS SecureOnboardCommunication.pdf
[6]
UNECE, “UN Regulations on Cybersecurity and Software Updates to pave the way for mass roll out of connected vehicles,” https: //unece.org/sustainable-development/press/un-regulations-cyberse curity-and-software-updates-pave-way-mass-roll, 2020, accessed: 2026-06-11.
[25] N. Subrahmanyam, “KeyM Technical Reference Configuration of Digital Certificates,” Vector Informatik GmbH, Tech. Rep., 2025, version 1.00.02.
[7]
McKinsey & Company, “The future of connectivity: Data center on wheels,” McKinsey Center for Future Mobility, Tech. Rep., 2019. [Online]. Available: https://www.mckinsey.com/industries/automoti ve-and-assembly/our-insights/the-future-of-connectivity-mobility-a s-a-service-is-the-new-frontier
[8]
[9]
P. Laclau, “Design of dynamic architectures for software defined vehicles,” Ph.D. dissertation, Université de Technologie de Compiègne, Compiègne, France, 2024, nNT: 2024COMP2833. HAL Id: tel05161614. S. Blanco, “Talking SDVs and zonal architecture with TE Connectivity,” https://www.sae.org/articles/2025/11/talking-sdvs-zonal-archi tecture-te-connectivity, 2025.
[20] A. Mukherjee, R. Gerdes, and T. Chantem, “Trusted Verification of Over-the-Air (OTA) Secure Software Updates on COTS Embedded Systems,” in Workshop on Automotive and Autonomous Vehicle Security (AutoSec), 2021. [21] I. Boureanu, “Formally Verifying the Security and Privacy of an Adopted Standard for Software-Update in Cars: Verifying Uptane 2.0,” in Proc. IEEE Int. Conf. on Systems, Man, and Cybernetics (SMC), 2023, pp. 1301–1306. [22] T. K. Kuppusamy, L. A. DeLong, and J. Cappos, “Uptane: Security and Customizability of Software Updates for Vehicles,” IEEE Vehicular Technology Magazine, vol. 13, no. 1, pp. 66–73, 2018.
[26] J. Camenisch and E. V. Herreweghen, “Design and implementation of the idemix anonymous credential system,” in Proc. 9th ACM Conf. on Computer and Communications Security (CCS), 2002, pp. 21–30. [27] L. Grassi, D. Khovratovich, C. Rechberger, A. Roy, and M. Schofnegger, “Poseidon: A New Hash Function for Zero-Knowledge Proof Systems,” in Proc. 30th USENIX Security Symposium, 2021, pp. 519– 535. [28] C. Liu et al., “AcclMT: A Highly Resource-Efficient and Flexible Poseidon Hash-Based Merkle Tree Architecture,” in Proc. 62nd ACM/IEEE Design Automation Conference (DAC), 2025, pp. 1–7. [29] N. Sheybani, A. Ahmed, M. Kinsy, and F. Koushanfar, “ZeroKnowledge Proof Frameworks: A Systematic Survey,” arXiv preprint arXiv:2502.07063, 2025.
[30] arkworks contributors, “arkworks zk-SNARK ecosystem,” https://gi thub.com/arkworks-rs, 2022. [31] G. Botrel, T. Piellard, Y. E. Housni, I. Kubjas, and A. Tabaie, “Consensys/gnark: v0.9.0,” https://github.com/ConsenSys/gnark, Feb. 2023. [32] hyraxZK, “hyraxZK,” https://github.com/hyraxZK/hyraxZK, 2023. [33] LegoSNARK, “LegoSNARK,” https://github.com/imdea-software/le gosnark/, 2023. [34] libsnark, “libsnark,” https://github.com/scipr-lab/libsnark, 2023. [35] J. Eberhardt and S. Tai, “ZoKrates - Scalable Privacy-Preserving OffChain Computations,” in Proc. IEEE Int. Conf. on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), 2018, pp. 1084–1091. [36] Mirage, “Mirage,” https://github.com/akosba/mirage, 2023. [37] PySNARK, “PySNARK,” https://github.com/meilof/pysnark, 2023. [38] J. Baylina, “snarkjs,” https://github.com/iden3/snarkjs, 2020.
Appendix A. Uptane Framework A.1. ECU Version Report (EVR) Generation Algorithm 6 delineates the attestation process at the hardware edge. Each secondary ECU is responsible for constructing a self-contained report that binds its current software state to its cryptographic identity. The requirement that each edge node compute an independent digital signature (Sign) contributes to the overall computational overhead at Tier-0. Algorithm 6 Tier-0: Secondary ECU Metadata Generation Require: IDecu , Vimg , Limg , Himg , P Recu , P IDecu Ensure: Signed ECU Version Report (EV R). 1: Init: ID ← {IDecu , P IDecu }, IM G ← {Vimg , Limg , Himg } 2: Check: F LAG ← Attack Detection() 3: Time: Tevr ← EVR Time() 4: Nonce: N ← Nonce() 5: Payload: P L ← {IDecu , IM G, N, F LAG, Tevr } 6: Integrity: Hevr ← Hash(P L) 7: Auth: DSIG ← Sign(P Recu , Hevr ) 8: Attr. Block: Sigattr ← {P IDecu , Meth, Hevr , Func, DSIG} 9: Assembly: EV R ← {Sigattr , P L} 10: Transmit: Send EV R to Primary ECU.
A.2. Vehicle Version Manifest (VVM) Generation Algorithm 7 formalizes the aggregation logic at the vehicle’s central hub. The Primary ECU (HPC) passively bundles all n incoming reports. This linear concatenation results in a VVM payload size that scales at O(n), directly leading to the communication bottlenecks observed in legacy high-density SDV configurations.
Algorithm 7 Tier-2: Primary ECU (HPC) Metadata Aggregation Require: V IN, IDpecu , {EV R1 , . . . , EV Rn }, P Rpecu Ensure: Signed Vehicle Version Manifest (V V M ). 1: Aggreg.: SETevr ← {EV R1 , . . . , EV Rn } 2: Self-Attest: EV Rpecu ← GenPrimaryReport() 3: Payload: P L ← {V IN, IDpecu , SETevr , EV Rpecu } 4: Integrity: Hpvvm ← Hash(P L) 5: Auth: DSIG ← Sign(P Rpecu , Hpvvm ) 6: Attr. Block: SIGattr ← {IDpecu , Meth, Hpvvm , Func, DSIG} 7: Assembly: V V M ← {P L, SIGattr } 8: Transmit: Send V V M to Director Repository.
A.3. Director Repository
Algorithm 8 details the multi-stage verification process at the Director Repository. Upon receiving the VVM, the repository identifies the vehicle via its VIN and retrieves the corresponding public keys from the inventory database. The process enforces a two-tier cryptographic check: first validating the global VVM signature to ensure the Primary ECU’s integrity, followed by a sequential verification of each secondary ECU’s EVR. This ensures that only authorized hardware with untampered metadata can proceed to the image identification phase. Algorithm 8 Director Repository: Vehicle and Metadata Verification Require: V IN , V V M , DBinventory , P Rdir Ensure: Vehicle authentication and update target identification. 1: Receive: DRvvm ← {V V M (P LOADvvm , SIGattr )} 2: Decode: V IN ← Extract(P LOADvvm ) 3: Query DB: RECORDSecu ← DB.Query(V IN )
{Retrieve keys and image records} 4: Verify VVM Signature: 5: SIGV ERIvvm ← DSV erif y(P Upecu , V V M ) 6: if SIGV ERIvvm == T RU E then 7: Proceed to ECU validation. 8: else 9: Abort: Drop request, log alert. 10: end if 11: Verify individual EVR Signatures: 12: for each EV R ∈ V V M do 13: SIGV ERIevr ← DSV erif y(P Uecu , EV R) 14: if SIGV ERIevr == F ALSE then 15: Abort: Drop request, log alert. 16: end if 17: end for 18: Return: AUTHENTICATION_SUCCESS