Pith. sign in

REVIEW 3 major objections 5 minor 38 references

zk-ScalHard: Scalable and Hardware-Rooted Privacy-Preserving Authentication for Secure OTA Updates in Zonal SDVs

T0 review · 3 major / 5 minor · reviewed 2026-07-13 · grok-4.5

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read zk-ScalHard turns vehicle OTA authentication into a constant-size zero-knowledge proof rooted in silicon PUFs, cutting bandwidth 99% and shrinking the key-exposure window to seconds.

desk verdict Solid hierarchical ZKP design that correctly kills Uptane’s linear VVM, but the headline numbers rest entirely on laptop SIL and the security arguments stay sketch-level. read the letter →

arxiv 2607.07371 v2 pith:RBS2WHBR submitted 2026-07-08 cs.CR

Shrikant Tangade , Bansi Pambhar , Valeria Loscri , Mauro Conti This is my paper · ORCID
classification cs.CR
keywords software-definedvehicleszonalarchitectureover-the-airupdateszero-knowledgeproofsphysicalunclonablefunctionsrecursiveaggregationdatasovereigntyUptane
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Software-defined cars with 100-plus control units need frequent over-the-air software updates, yet today’s PKI-based standards force every unit to ship a signed report. The resulting vehicle-wide manifest grows linearly, bloating the wireless link and leaving private configuration data and long-lived keys exposed. zk-ScalHard replaces that model with a four-layer “trust pyramid.” Edge chips contribute only a short MAC derived from an on-the-fly physical unclonable function; each zonal controller folds those MACs into a succinct zero-knowledge proof; the central computer recursively compresses the zonal proofs into one 800-byte vehicle proof that the cloud verifies in constant time. Because the physical secret never leaves volatile memory and is erased after roughly four seconds, the temporal window for key theft collapses by three orders of magnitude, while the vehicle itself never reveals its internal inventory. The authors claim this combination finally gives next-generation zonal architectures scalable, privacy-preserving, and GDPR-compliant authentication.

What carries the argument

The ZIDI and HPCA zero-knowledge circuits: ZIDI performs an in-situ multi-party ceremony that turns local PUF entropy into zonal proving keys and then proves the integrity of 25 edge MACs; HPCA recursively aggregates the four zonal proofs plus the central computer’s own PUF witness into a single constant-size vehicle attestation.

What would settle it

Run the identical ZIDI and HPCA circuits on production-grade automotive processors (for example NXP S32G-class devices) with 100 real ECUs and measure whether the vehicle-to-cloud payload remains under 1 KB and cloud verification stays near-constant while the PUF witness is still purged within a few seconds.

Watch

Extended reading notes

Core claim

A hierarchical, hardware-rooted protocol can reduce vehicle-to-cloud authentication from linear O(n) communication and verification cost to constant O(1) size and time, while simultaneously eliminating persistent digital keys and keeping all identity and configuration data inside the vehicle.

Load-bearing premise

That proof sizes and latencies measured on a laptop virtual machine accurately represent what resource-constrained 32-bit zonal controllers and production automotive hardware will achieve.

Editorial extensions

If this is right

  • Vehicle-to-cloud authentication bandwidth becomes independent of the number of ECUs, removing the scalability wall that currently blocks high-density zonal fleets.
  • Sensitive firmware versions, hardware IDs and passenger-related configuration data never leave the car, satisfying data-minimisation rules by construction.
  • Physical key-extraction attacks become statistically impractical because secrets exist only for a few seconds of volatile memory rather than 24/7 in flash.
  • A cloud-side compromise of global parameters cannot forge proofs for an entire fleet, because each vehicle generates its own zonal keys in situ.
  • The same hierarchical pattern can be reused for other multi-tier automotive attestation tasks beyond OTA updates.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the SIL-to-hardware gap proves small, the same recursive-aggregation pattern could be applied to other dense IoT fleets (robotics, industrial controllers) that currently suffer linear metadata bloat.
  • The four-second temporal window suggests a natural upper bound for any future PUF-based ZKP witness lifetime; designs that cannot meet that bound will re-open the side-channel surface.
  • Because the cloud learns only a binary integrity bit, fleet operators lose fine-grained diagnostics; complementary privacy-preserving telemetry channels may still be required.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes zk-ScalHard, a hierarchical Silicon-to-Cloud authentication protocol for OTA updates in Zonal SDVs. It maps trust across four layers (edge ECUs with silicon PUFs, ZCUs running a ZIDI Groth16 circuit with in-situ MPC setup, an HPC running recursive HPCA aggregation, and the OTA cloud). The central claim is that recursive aggregation yields constant O(1) V2I communication and verification (reported 809 B / 2.1 s at 100 ECUs) versus Uptane’s linear O(n) VVM (98.6 KB / 15.47 s), together with a 99.9 % reduction in the temporal key-extraction window via ephemeral PUF witnesses. Algorithms 2–5, constraint counts (2 163 for ZIDI, 518 for HPCA), and SIL benchmarks against a Uptane reference implementation are supplied; source code is linked.

Significance. If the construction is feasible on production automotive hardware, the work would be a genuine advance for secure OTA in high-density Zonal architectures: it simultaneously attacks the metadata-bloat problem of Uptane/AUTOSAR, the single-point-of-failure of centralized trusted setups, and the persistent-key exposure surface of conventional PKI. The public Circom/SnarkJS implementation, explicit R1CS sizes, and side-by-side Uptane baseline are concrete strengths that make the asymptotic claim falsifiable and the bandwidth numbers reproducible. The hierarchical mapping of cryptographic intensity to hardware tiers is a useful architectural contribution even if some quantitative claims later need revision.

major comments (3)
  1. [§5.4, §5.1.1, Contribution 4, Fig. 10] Section 5.4 and Contribution 2 / Fig. 9: all latency and bandwidth numbers that underwrite the O(1) and 99.2 % claims are obtained exclusively in a WSL2 Node.js/SnarkJS SIL environment on an Intel i5 laptop. The same manuscript asserts (Section 5.1.1) that the 2 163-constraint ZIDI circuit is “feasible to execute on 32-bit automotive microcontrollers (ECUs/ZCUs)” and treats the measured 4.2 s proving window as the temporal attack surface (Contribution 4, Fig. 10). No cycle counts, RAM footprints, or prover timings on any automotive-grade MCU or HSM are provided; the only hardware statement is a future-work promise of NXP S32G HiL (Section 10). Without at least one platform-realistic measurement, both the asymptotic-scalability numbers and the 99.9 % temporal-isolation claim remain unanchored for the intended target.
  2. [§5.1.2, Algorithm 3, RQ3] Section 5.1.2 / Algorithm 3: the security of the in-situ Zonal MPC ceremony rests on the claim that 25 edge-ECU PUF responses can be combined into Groth16 toxic waste that is then securely erased, so that neither the OEM nor the cloud can later forge proofs. The paper supplies no concrete MPC protocol, no leakage analysis under the physical-adversary model of Section 3.1.1, and no argument that a compromised ZCU cannot retain the toxic waste. This is load-bearing for the “decentralized trust / no single point of failure” claim (RQ3, Contribution 3).
  3. [§2.3, §5.4, Table 1, Table 2] Section 2.3 versus Algorithms 4–5 and the evaluation: the background states that Plonky3/FRI is used at Tier-2 for post-quantum resilience and recursive aggregation, yet the implementation description (Section 5.4) and the reported 805–809 B constant proofs are those of Groth16/SnarkJS. The evaluation never measures a FRI-based recursive proof. The PQ claim in Table 1 and the security matrix (Table 2) is therefore not supported by the concrete artifact that produces the O(1) numbers.
minor comments (5)
  1. [Abstract, Contribution 4, Fig. 10] The abstract and Contribution 2 report a 99.2 % bandwidth reduction and a 99.9 % temporal-surface reduction; Fig. 10 caption and body text use 99.995 %. Align the figures.
  2. [§4.2–4.3, §7.1] Proof sizes are stated as both 809 B and 805 B in different places (ZIDI vs HPCA). Clarify whether the difference is intentional (public inputs, serialization) or a rounding inconsistency.
  3. [§1.4, title] The title and several headings use “zk-ScalHard” while Contribution 1 and the introduction also introduce “zk-DieHard-SDV”. Standardize the protocol name.
  4. [§7.1–7.2, Figs. 8–9] Figures 8–9 would be clearer if the Uptane baseline were also plotted with error bars or at least the exact measurement methodology (number of runs, warm-up) stated in Section 5.4.
  5. [§9] Related-work discussion of Idemix/U-Prove and NIST PQC is useful but could more precisely cite the concrete signature sizes that produce the “375 KB” claim for 100 Dilithium signatures.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: O(1) complexity and measured reductions follow from the recursive aggregation construction and independent SIL benchmarks against Uptane, not from fitted inputs or self-definitional loops.

full rationale

The paper's central claims (constant O(1) V2I communication/verification via HPCA recursive folding of four ZIDI proofs into one ~805-byte vehicle proof; 99.2% bandwidth cut from 98.6 KB Uptane VVM to 809 B; 99.9% temporal attack-surface reduction from 24/7 persistent keys to a measured ~4.2 s PUF-witness window) are obtained by design of the ZIDI/HPCA R1CS circuits (Algorithms 2-5, Poseidon-based constraints, Groth16/Plonky3) plus direct Software-in-the-Loop measurements of the implemented circuits versus the independent Uptane Python reference (Section 5.4, Figs. 8-10). Proof size is constant by the known property of the chosen SNARK aggregation, not by fitting a free parameter to data and then 'predicting' a related quantity. No uniqueness theorem, ansatz, or load-bearing premise is imported solely via self-citation; the only self-reference is the public GitHub repository for reproducibility. The derivation chain is therefore self-contained against external benchmarks and does not reduce by construction to its own inputs. Feasibility concerns about SIL laptop numbers versus 32-bit ZCUs are correctness/platform issues, not circularity.

Assumptions & free parameters 2 free parameters · 4 assumptions · 3 invented entities

The central O(1) and privacy claims rest on standard cryptographic hardness assumptions, the physical properties of silicon PUFs, and the authors’ own circuit constructions. No numerical free parameters are fitted to external data; the only free design choices are the circuit sizes and the 4-zone / 25-ECU-per-zone topology used for evaluation.

free parameters (2)
  • number of zones / ECUs per zone = 4 zones, 25 ECUs/zone
    Evaluation fixes 4 ZCUs × 25 ECUs = 100 ECUs; the O(1) claim is independent of this choice but the concrete byte and latency numbers are not.
  • ZIDI / HPCA constraint counts = 2163 / 518
    2 163 and 518 non-linear R1CS constraints are design outcomes of the Circom implementation; they determine proving time but are not fitted to external measurements.
assumptions (4)
  • standard math Groth16 and Plonky3/FRI are computationally sound and zero-knowledge under standard discrete-log / hash assumptions
    Invoked for Theorems 1–3 and for the security matrix in Section 6; no new hardness proof is supplied.
  • domain assumption Silicon PUFs produce stable, unclonable bit-strings that can be reconstructed on-the-fly with negligible error for the duration of a 4.2 s proving window
    Load-bearing for the temporal-isolation and hardware-root claims (Sections 4.1, 5.3); no measured bit-error-rate or aging data are given.
  • ad hoc to paper An in-situ multi-party computation among 25 edge ECUs can securely generate and then erase the Groth16 toxic waste without leakage to the OEM or cloud
    Core of Contribution 3 and Algorithm 3; security of the concrete MPC protocol is asserted rather than reduced.
  • ad hoc to paper The Software-in-the-Loop environment faithfully models the timing and memory constraints of production automotive ZCUs and HSMs
    All quantitative claims in Section 7 rest on this; the paper itself lists HiL validation as future work.
invented entities (3)
  • ZIDI circuit (Zonal Identity and Integrity)
    purpose: Aggregates 25 ECU MACs plus a local PUF witness into a single succinct zonal proof via tiered Poseidon hashing and Groth16
    Novel circuit design introduced in Section 5.1; no independent prior publication of this exact R1CS.
  • HPCA circuit (High-Performance Computing Aggregation)
    purpose: Recursively folds four zonal proofs plus the HPC PUF into one constant-size vehicle-level proof
    Novel recursive aggregator introduced in Section 5.2; enables the O(1) claim.
  • zk-ScalHard hierarchical trust pyramid (Layers 0–3)
    purpose: Maps cryptographic intensity to the physical ECU–ZCU–HPC–Cloud topology of zonal SDVs
    Architectural construct that organises the protocol; not previously published as a named model.

how reviews work

0 comments
Cite this review

Pith. "Pith review of zk-ScalHard: Scalable and Hardware-Rooted Privacy-Preserving Authentication for Secure OTA Updates in Zonal SDVs." pith.science (2026). https://pith.science/paper/RBS2WHBR

@misc{pith2026260707371,
  author       = {Pith},
  title        = {Pith review of: zk-ScalHard: Scalable and Hardware-Rooted Privacy-Preserving Authentication for Secure OTA Updates in Zonal SDVs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RBS2WHBR}},
  note         = {Machine review of arXiv:2607.07371}
}
read the original abstract

The automotive industry is transitioning to Zonal-oriented Architectures (ZoA) for Software-Defined Vehicles (SDVs), enabling frequent over-the-air (OTA) updates for 100+ Electronic Control Units (ECUs). While OTA updates improve efficiency, they introduce safety-critical security risks. Current standards like Uptane and AUTOSAR Adaptive rely on Public-Key Infrastructure (PKI). However, PKI-based authentication creates bandwidth bottlenecks in in-vehicle and vehicle-to-cloud (V2I) communication as ECU density increases. It also risks exposing sensitive vehicle configurations and passenger privacy due to centralized architectures. Next-generation Zonal SDVs require decentralized, scalable authentication with data privacy. To address this, we propose zk-ScalHard, a hardware-rooted, privacy-preserving authentication protocol. We introduce a decentralized, hierarchical trust-promotion model utilizing Silicon Physical Unclonable Functions (PUFs) and two novel Zero-Knowledge Proof (ZKP) circuits: (1) Zonal Identity and Integrity (ZIDI) and (2) High-Performance Computing Aggregation (HPCA). These circuits employ multi-party computation (MPC) and recursive aggregation to achieve decentralization and scalability. The integration of ZKPs and PUFs ensures 100% vehicle-level data sovereignty. Benchmarked against Uptane, zk-ScalHard achieves constant O(1) communication and verification complexity, improving upon the linear O(n) complexity of current systems. Evaluation shows a 99.2% reduction in authentication bandwidth and a 99.9% reduction in the temporal attack surface. Our results demonstrate that zk-ScalHard provides a scalable, secure, and GDPR-compliant architecture for future Zonal SDVs.

Figures

Figures reproduced from arXiv: 2607.07371 by the authors.

Figure 1
Figure 1. SDV’s Zonal-oriented Architecture (ZoA) [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Uptane Secure OTA Update Framework Design (Adapted from [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. The individual ECU report (EVR) VVM Framework (Vehicle Version Manifest) Vehicle ID Primary ECU ID List of all n-ECUs EVR Public key ID Signing method 16-bit key ID ed25519 / rsassa-pss Hash of VVM Payload Hash ( ) Signature on VVM Hash Payload Signature [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figures from the paper (6 more)
Figure 5
Figure 5. Figure 5: The aggregated vehicle manifest, illustrating the linear [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 3
Figure 3. Figure 3: Uptane Operational Workflow and Metadata Lifecycle. The [PITH_FULL_IMAGE:figures/full_fig_p005_3.png]
Figure 7
Figure 7. Figure 7: Vehicle-to-Cloud Authentication During Secure OTA Update [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: illustrates the communication-overhead advan￾tages of zk-ScalHard within the Zonal SDV environment. Our benchmarks show that the V2I payload for the industry￾standard Uptane framework grows linearly, O(n), because the vehicle version manifest (VVM) must bundle individu…
Figure 9
Figure 9. Figure 9: Verification Complexity: O(n) vs. O(1) Scalability to Uptane even within a non-optimized simulation environ￾ment. Furthermore, projecting these results onto production￾grade ‘hardware security modules (HSMs)’, where verifica￾tion is optimized to ≈ 5ms (see Section 2), …
Figure 10
Figure 10. Figure 10: Temporal Attack Surface: Persistent vs. Ephemeral Secrets [PITH_FULL_IMAGE:figures/full_fig_p012_10.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 1 linked inside Pith

  1. [1]

    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,

    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

    2024

  2. [2]

    UN Regulation No. 155 - Cyber security and cyber security management system,

    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

    2021

  3. [3]

    UN Regulation No. 156 - Software update and software update management system,

    ——, “UN Regulation No. 156 - Software update and software update management system,” United Nations Economic Commission for Europe, Tech. Rep., 2021

    2021

  4. [4]

    ISO/SAE 21434:2021 Road vehicles — Cybersecurity en- gineering,

    ISO/SAE, “ISO/SAE 21434:2021 Road vehicles — Cybersecurity en- gineering,” International Organization for Standardization, Standard, 2021

    2021

  5. [5]

    ISO/SAE 24089:2023 Road vehicles — Software update en- gineering,

    ISO, “ISO/SAE 24089:2023 Road vehicles — Software update en- gineering,” International Organization for Standardization, Standard, 2023

    2023

  6. [6]

    UN Regulations on Cybersecurity and Software Updates to pave the way for mass roll out of connected vehicles,

    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

    2020

  7. [7]

    The future of connectivity: Data center on wheels,

    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

    2019

  8. [8]

    Design of dynamic architectures for software defined ve- hicles,

    P. Laclau, “Design of dynamic architectures for software defined ve- hicles,” Ph.D. dissertation, Universit´e de Technologie de Compi `egne, Compi`egne, France, 2024, nNT: 2024COMP2833. HAL Id: tel- 05161614

    2024

Show all 38 references
  1. [9]

    Talking SDVs and zonal architecture with TE Connec- tivity,

    S. Blanco, “Talking SDVs and zonal architecture with TE Connec- tivity,” https://www.sae.org/articles/2025/11/talking-sdvs-zonal-archi tecture-te-connectivity, 2025

    2025

  2. [10]

    Software-defined vehicles: The 4 dimensions of adoption and the OEMs moving fastest,

    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

    2026

  3. [11]

    Uptane: Securing Software Updates for Automobiles,

    T. Karthik, “Uptane: Securing Software Updates for Automobiles,” inProc. 14th escar Europe, 2016

    2016

  4. [12]

    Securing Software Updates for Automotives Using Uptane,

    ——, “Securing Software Updates for Automotives Using Uptane,” USENIX ;login:, vol. 42, no. 2, 2017

    2017

  5. [13]

    IBM Identity Mixer: Authentication without identification,

    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

    2015

  6. [14]

    MSP Implementation with Identity Mixer,

    Hyperledger Fabric, “MSP Implementation with Identity Mixer,” ht tps://hyperledger-fabric.readthedocs.io/en/release-1.3/idemix.html, 2018

    2018

  7. [15]

    U-Prove Technology Overview V1.1, Revision 3,

    C. Paquin, “U-Prove Technology Overview V1.1, Revision 3,” Mi- crosoft Corporation, Tech. Rep., 2023

    2023

  8. [16]

    Status Report on the Third Round of the NIST Post- Quantum Cryptography Standardization Process,

    G. Alagicet al., “Status Report on the Third Round of the NIST Post- Quantum Cryptography Standardization Process,” National Institute of Standards and Technology (NIST), Gaithersburg, MD, USA, Tech. Rep. NIST IR 8413-upd1, 2022

    2022

  9. [17]

    Authentication Protocol for Secure Automotive Systems: Bench- marking Post-Quantum Cryptography,

    P. Ravi, V . K. Sundar, A. Chattopadhyay, S. Bhasin, and A. Easwaran, “Authentication Protocol for Secure Automotive Systems: Bench- marking Post-Quantum Cryptography,” inProc. IEEE International Symposium on Circuits and Systems (ISCAS), 2020, pp. 1–5

    2020

  10. [18]

    (2024) Uptane Design Overview

    Uptane Project. (2024) Uptane Design Overview. https://uptane.org/l earn-more/design. Accessed: 2026-06-12

    2024

  11. [19]

    A Compre- hensive, Automated Security Analysis of the Uptane Automotive Over-the-Air Update Framework,

    R. Lorch, D. Larraz, C. Tinelli, and O. Chowdhury, “A Compre- hensive, Automated Security Analysis of the Uptane Automotive Over-the-Air Update Framework,” inProc. 27th Int. Symposium on Research in Attacks, Intrusions and Defenses (RAID). ACM, 2024, pp. 594–612

    2024

  12. [20]

    Trusted Verification of Over-the-Air (OTA) Secure Software Updates on COTS Embedded Systems,

    A. Mukherjee, R. Gerdes, and T. Chantem, “Trusted Verification of Over-the-Air (OTA) Secure Software Updates on COTS Embedded Systems,” inWorkshop on Automotive and Autonomous Vehicle Se- curity (AutoSec), 2021

    2021

  13. [21]

    Formally Verifying the Security and Privacy of an Adopted Standard for Software-Update in Cars: Verifying Uptane 2.0,

    I. Boureanu, “Formally Verifying the Security and Privacy of an Adopted Standard for Software-Update in Cars: Verifying Uptane 2.0,” inProc. IEEE Int. Conf. on Systems, Man, and Cybernetics (SMC), 2023, pp. 1301–1306

    2023

  14. [22]

    Uptane: Security and Customizability of Software Updates for Vehicles,

    T. K. Kuppusamy, L. A. DeLong, and J. Cappos, “Uptane: Security and Customizability of Software Updates for Vehicles,”IEEE Vehic- ular Technology Magazine, vol. 13, no. 1, pp. 66–73, 2018

    2018

  15. [23]

    Formal analysis of an AUTOSAR-based basic software module,

    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

    2024

  16. [24]

    Requirements on Secure Onboard Communication,

    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

    2025

  17. [25]

    KeyM Technical Reference Configuration of Digital Certificates,

    N. Subrahmanyam, “KeyM Technical Reference Configuration of Digital Certificates,” Vector Informatik GmbH, Tech. Rep., 2025, version 1.00.02

    2025

  18. [26]

    Design and implementation of the idemix anonymous credential system,

    J. Camenisch and E. V . Herreweghen, “Design and implementation of the idemix anonymous credential system,” inProc. 9th ACM Conf. on Computer and Communications Security (CCS), 2002, pp. 21–30

    2002

  19. [27]

    Poseidon: A New Hash Function for Zero-Knowledge Proof Systems,

    L. Grassi, D. Khovratovich, C. Rechberger, A. Roy, and M. Schofneg- ger, “Poseidon: A New Hash Function for Zero-Knowledge Proof Systems,” inProc. 30th USENIX Security Symposium, 2021, pp. 519– 535

    2021

  20. [28]

    AcclMT: A Highly Resource-Efficient and Flexi- ble Poseidon Hash-Based Merkle Tree Architecture,

    C. Liuet al., “AcclMT: A Highly Resource-Efficient and Flexi- ble Poseidon Hash-Based Merkle Tree Architecture,” inProc. 62nd ACM/IEEE Design Automation Conference (DAC), 2025, pp. 1–7

    2025

  21. [29]

    Zero- Knowledge Proof Frameworks: A Systematic Survey,

    N. Sheybani, A. Ahmed, M. Kinsy, and F. Koushanfar, “Zero- Knowledge Proof Frameworks: A Systematic Survey,”arXiv preprint arXiv:2502.07063, 2025

    2025 arXiv

  22. [30]

    arkworks zk-SNARK ecosystem,

    arkworks contributors, “arkworks zk-SNARK ecosystem,” https://gi thub.com/arkworks-rs, 2022

    2022

  23. [31]

    Consensys/gnark: v0.9.0,

    G. Botrel, T. Piellard, Y . E. Housni, I. Kubjas, and A. Tabaie, “Consensys/gnark: v0.9.0,” https://github.com/ConsenSys/gnark, Feb. 2023

    2023

  24. [32]

    hyraxZK,

    hyraxZK, “hyraxZK,” https://github.com/hyraxZK/hyraxZK, 2023

    2023

  25. [33]

    LegoSNARK,

    LegoSNARK, “LegoSNARK,” https://github.com/imdea-software/le gosnark/, 2023

    2023

  26. [34]

    libsnark,

    libsnark, “libsnark,” https://github.com/scipr-lab/libsnark, 2023

    2023

  27. [35]

    ZoKrates - Scalable Privacy-Preserving Off- Chain Computations,

    J. Eberhardt and S. Tai, “ZoKrates - Scalable Privacy-Preserving Off- Chain Computations,” inProc. IEEE Int. Conf. on Internet of Things (iThings) and IEEE Green Computing and Communications (Green- Com) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Dat...

    2018

  28. [36]

    Mirage, “Mirage,” https://github.com/akosba/mirage, 2023

    2023

  29. [37]

    PySNARK,

    PySNARK, “PySNARK,” https://github.com/meilof/pysnark, 2023

    2023

  30. [38]

    snarkjs,

    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 ...

    2020

Pith tools

Reviewed July 13, 2026 · model on record in the stance chip above.