Skip to Content
MDPIMDPI

Advanced

ElectronicsElectronics
PDF
  • Article
  • Open Access

24 June 2026

41 Pages

CertiFlash: A Cryptographic Framework for Secure Firmware and Logic Updates in SCADA and Industrial IoT Networks

and
Warwick Manufacturing Group, University of Warwick, Coventry CV4 7AL, UK
*
Author to whom correspondence should be addressed.
Electronics2026, 15(13), 2780;https://doi.org/10.3390/electronics15132780
Version Notes
Order Reprints

Abstract

Across the world’s electrical substations, water-treatment plants, and manufacturing lines, a single engineer with valid credentials and a laptop can today push new control logic to a programmable logic controller (PLC) and change the physical behaviors of safety-critical equipment within minutes. Firmware and ladder-logic updates on SCADA and industrial IoT systems are privileged operations: an attacker installing a malicious update controls the physical process. Existing protections concentrate install authority in a single party with no externally verifiable record; compromise of the vendor key, the engineering workstation, or any operator credential suffices to deliver an attacker-chosen payload to a PLC. CertiFlash binds every update to four independent approvals: a vendor signature, a FROST-Ed25519 threshold signature from an operator quorum, a per-session nonce from the PLC, and a monotonic counter. Every decision is recorded in an append-only Merkle transparency log. The PLC verifies the aggregate with a standard RFC 8032 Ed25519 verifier, requiring no FROST-specific device code. Four security properties (authenticity, authorization, rollback resistance, auditability) are machine-checked in Tamarin under a Dolev–Yao adversary with up to t − 1 compromised operators and corroborated through ten attack scenarios. The implementation runs with concurrent Modbus TCP and Siemens S7 traffic, blocks all attacks, signs in 27–192 ms (k = 3–10), keeps ML-DSA-65 within 6% of Ed25519 from 1 KiB to 10 MiB, and sustains 30.1 updates/s on 100 PLCs. The operator-quorum signature remains FROST-Ed25519: the design is partially post-quantum in the evaluated version. The framework maps to IEC 62443-3-3 SR 3.4 and NIS2 Article 21(2)(d–e).

1. Introduction

In June 2010, the Stuxnet worm [1,2] showed that an attacker who could modify ladder logic on PLCs could manipulate the physical process the controllers governed, in that case, uranium enrichment centrifuges, without alerting the operators monitoring them. The pattern recurred: the 2015 Ukrainian power-grid attack [3], the 2017 TRITON intrusion against a Saudi petrochemical safety system [4], and the 2021 Colonial Pipeline shutdown [5]. Sixteen years later, the prerequisites that made Stuxnet possible remain present in the field. PLCs and remote terminal units (RTUs) accept firmware and logic updates from anyone who reaches them with valid credentials and a properly signed image. The signing key sits with one party, typically the vendor; the install authorization sits with one party, typically a single engineer at the asset owner; and what gets installed is recorded, if at all, in operator-managed logs that the operator can edit. An attacker who breaches any one of these parties, through phishing, supplier compromise, or credential theft, can install whatever they choose on the targeted device, and can edit the local audit trail to remove evidence afterward.
Stuxnet is the canonical case, but what it exposed is the routine update workflow in many critical sectors today: a control engineer pushing a tuning change to a pump-station PLC, a substation engineer loading a corrected protection-relay logic block, or a maintenance technician staging a firmware upgrade on a fleet of motion controllers. Each is a normal, well-intentioned workflow. Each also concentrates the authority to alter physical equipment in a single human at a single workstation, with no externally verifiable record of what was installed.
Recent industry advisories and academic studies confirm this remains a live problem rather than a historical one. A USENIX Security 2024 study of firmware-update vulnerabilities by Wu et al. [6] catalogs the breadth of update-flow weaknesses in deployed embedded systems. The IEC 62443-3-3 standard [7] requires that PLCs verify the integrity of firmware before use but says nothing about who is authorized to install an update, how the install record is preserved, or how a third party can audit the install history. The EU NIS2 Directive [8] adds supply-chain and audit-evidence obligations on critical-infrastructure operators that current update mechanisms do not meet.
This paper presents CertiFlash, a protocol and reference implementation for firmware and ladder-logic updates on SCADA and industrial IoT systems. The design follows from one observation: an update is consequential enough that no single party should authorize it alone, and the record of what was installed should be visible to parties beyond the installer. Four protections follow. First, the vendor signs the update with a long-term key, attesting authenticity. Second, a k-of-n quorum of operators at the asset owner co-authorizes the install with a single threshold signature, with k chosen by site policy. Third, the PLC issues a fresh challenge nonce per session and accepts only signed bundles that commit to that nonce, preventing replay. Fourth, the PLC maintains a strictly monotonic counter, preventing rollback. Every accept-or-reject decision is published to an append-only transparency log monitored by an external auditor. Compromising any single operator, the engineering workstation, or the PLC itself leaves the framework’s safety guarantees intact; full vendor-key compromise is out of scope (Section 4.3).
Two of these protections warrant additional context. The operator quorum replaces single-party authorisation with a requirement that several engineers consent to the same install, binding their collective consent cryptographically to the specific bundle being installed. Sites retain their existing change-control roles and seniority structures; what changes is that authorisation becomes participation in a short cryptographic protocol rather than a signature on a paper form. The transparency log extends a discipline established by Certificate Transparency, where any party (not only the certificate authorities themselves) can detect when a TLS certificate has been issued for a domain it should not have been. The same property applies to firmware: once every install decision is published to an append-only log, a tampered local audit trail on the device no longer conceals the installation history, and any operator or auditor can later determine what was installed on a given PLC and under whose authorisation. In industrial settings, where accountability today rests largely on operator-managed records, this is a meaningful shift.
A third design property, one of the framework’s more practical contributions, is easily overlooked. The engineering workstation (the laptop or programming station used by the engineer) holds no signing key in CertiFlash. It coordinates the update but cannot itself authorize one. The engineering workstation is empirically the most attractive target on an industrial network: it carries the vendor tooling, routinely talks to controllers, is often connected briefly to the IT environment, and is rarely subject to the same endpoint controls applied to corporate assets. Existing mechanisms concentrate install authority precisely on this machine. CertiFlash relocates that authority to a co-signing quorum, so a compromised workstation can deny service or mislead its operator but cannot, by itself, install anything.
Three design properties make the framework deployable rather than aspirational. First, the threshold-signature scheme is FROST-Ed25519 [9,10], and the aggregated signature is a standard RFC 8032 Ed25519 signature [11]: the PLC-side verifier requires no FROST-specific code, and existing PLC firmware that already includes an Ed25519 verifier can be retrofitted without changes to the cryptographic stack. Second, the bundle format is canonical CBOR [12] with domain-separated signing images, deterministic in encoding, and transport-agnostic; CertiFlash can be carried over OPC UA, MQTT, HTTPS, or a vendor-specific channel without changes to the verifier. Third, the cryptographic primitives are algorithm-agile: the same protocol works with Ed25519 today and ML-DSA-65 [13] for post-quantum migration, with measured verification latency within 6% across both algorithms.
We make five contributions:
  • Protocol. CertiFlash binds vendor authenticity, operator-quorum authorization, rollback resistance, and external auditability to each install command using a single canonical bundle format and a nine-step verification pipeline on the PLC. The protocol is transport-agnostic and primitive-agnostic on the device side.
  • Formal verifications. We model the protocol in Tamarin under a Dolev–Yao network adversary with up to t − 1 compromised operators, and machine-check all four security properties: update authenticity, authorization correctness, rollback resistance, and log auditability. The formal modeling exercise also uncovered an abstraction gap in an early version of the threshold-signature rule, which we corrected.
  • Implementation. We provide a reference implementation comprising a vendor signer, per-operator FROST signing services, a coordinator, an engineering-workstation client, a PLC verifier with Modbus TCP and Siemens S7 runtime stubs, and a transparency log with an external auditor. The full system runs as a multi-service Docker stack reproducible end-to-end with a single command. The implementation supports both Ed25519 and ML-DSA-65 signatures.
  • Security Evaluation. We catalog ten attack scenarios, covering forged signatures, sub-threshold operator collusion, replay across sessions, rollback, log tampering, network man-in-the-middle, compromised workstation, mid-update power loss, and wrong-target delivery, and demonstrate that CertiFlash blocks all ten with explicit rejection reasons.
  • Performance evaluation and regulatory mapping. We measure FROST signing latency from k = 2 to k = 10, end-to-end update latency for both classical and post-quantum signature variants, bundle-size overhead, and fleet throughput to 100 PLCs. We map the protocol’s controls to IEC 62443-3-3 SR 3.4 [7], IEC 62443-4-2 CR 3.4 [14], and NIS2 Article 21(2)(d–e) [8]. Figure 1 summarizes the contrast between today’s deployed mechanisms and the four-approvals discipline this work introduces.
    Figure 1. ICS firmware updates today versus CertiFlash. Left: deployed mechanisms grant a single party, the engineer holding vendor-signed images and credentials, the authority to install, with no externally visible record. Right: CertiFlash binds every install to four approvals (vendor signature, operator-quorum signature via FROST-Ed25519, PLC challenge nonce, monotonic counter) and records every accept-or-reject decision on an append-only transparency log that any third party can audit. The vendor key remains a root of trust; full vendor-key compromise is out of scope (Section 4.3). The failure modes shown in the figure are exemplified by the Stuxnet attack [1,2] and CISA advisory ICSA-25-023-02 [15].
None of the cryptographic primitives CertiFlash uses is new; each is well understood, standardized, and library-supported. The contribution is in their composition: a specific arrangement that satisfies operational requirements no current industrial update mechanism meets together, with formal and empirical evidence that the composition holds up under attack.
The remainder of the paper is organized as follows. Section 2 reviews the relevant background on SCADA and IIoT update mechanisms and the cryptographic primitives the protocol uses. Section 3 surveys related work on secure firmware updates, threshold cryptography in critical infrastructure, and formal verification of update protocols. Section 4 states the threat model. Section 5 specifies the CertiFlash protocol. Section 6 gives security definitions for the four properties and proof sketches. Section 7 describes the Tamarin model and verification results. Section 8 presents the implementation. Section 9 evaluates the framework. Section 10 discusses deployment considerations, limitations, and the regulatory mapping. Section 11 concludes.

2. Background

Three areas of background are required for the rest of the paper. Section 2.1 describes how firmware and logic updates are performed in deployed SCADA and IIoT systems, and what the existing standards do and do not require. Section 2.2 introduces the cryptographic primitives the protocol composes. Section 2.3 describes the Tamarin prover used in Section 7 to verify the protocol’s security properties. Readers familiar with all three may proceed to Section 3.

2.1. Firmware and Logic Updates in Scada and Iiot

A modern SCADA or industrial IoT site is a layered structure. At the bottom sit the controllers—PLCs, RTUs, intelligent electronic devices, running control logic against pumps, valves, breakers, motors. Above them, a SCADA server and HMI watch and intervene. Two artifacts get pushed down to those controllers over a device’s lifetime, and both matter for security. Firmware is the device’s runtime, which decides what the device fundamentally is. Application logic, typically written as IEC 61131-3 [16] ladder diagrams or function blocks, decides what the device does on a given day. Replace either, and you have changed the system.
In practice, every major vendor ships its own update mechanism. Siemens, Rockwell, Schneider Electric, ABB, Hitachi Energy, each has a proprietary firmware-transfer flow, usually over Ethernet, sometimes wrapped in TLS, increasingly accompanied by a vendor-signed image. Those signatures attest that the vendor signed the image. They do not attest that anyone at the asset owner ever authorized the install, that the install record outlives the device’s local logs, or that the version being installed is the most recent known-good one rather than an older signed image with known holes. The CISA advisory for the Hitachi Energy RTU500 [15] is a recent illustration of exactly this gap: an authenticated user installing an unsigned image because the vendor’s protection was misconfigured on some communication module. The signed-firmware story works, but only as far as it goes.
The IETF Software Updates for Internet of Things (SUIT) working group has done careful work in this space, as captured in RFC 9019 [17]. SUIT defines a manifest format and an update architecture aimed at constrained IoT devices. It is strong on content authentication and integrity. It is silent on multi-party authorization at the asset owner, and silent on the question of whether an external party can verify what was installed and when. The Update Framework (TUF) and its automotive descendant Uptane [18,19] take a different angle: role-key separation and threshold multi-signature on metadata roles, designed for the supply-chain side of the problem. Uptane’s threshold sits on repository roles, not on the install command at the device, and the framework targets vehicles rather than industrial control. There is no ratified Uptane profile for ICS or SCADA at the time of writing.
The standards landscape adds requirements without prescribing protocols. IEC 62443-3-3 system requirement SR 3.4 [7] mandates integrity verification of firmware before use; IEC 62443-4-2 component requirement CR 3.4 [14] makes that obligation explicit at the device level, with requirement enhancement RE(1) (authenticity of software and information) mapping directly to the cryptographically signed update bundles that CertiFlash provides. The EU NIS2 Directive [8] pulls in supply-chain security (Article 21(2)(d)) and audit-evidence retention (Article 21(2)(f) and Articles 32–33) for critical-infrastructure operators. NIST SP 800-82 Revision 3 [20] is the current OT-security guidance document, recommending update-integrity practices but stopping short of specifying mechanisms. None of these prescribe a specific update protocol. CertiFlash is intended to satisfy what they require, and to extend along the two axes the multi-party authorization and external auditability, that they leave open.

2.2. Cryptographic Primitives

CertiFlash composes five well-established building blocks: two digital-signature schemes (Ed25519 and ML-DSA-65), a Schnorr threshold construction over Ed25519 (FROST), a canonical binary serialization format (CBOR), and an append-only Merkle log structure derived from Certificate Transparency. The framework introduces no new cryptography; the contribution lies in their composition.
Ed25519. Defined in RFC 8032 [11], Ed25519 is the EdDSA instantiation over the twisted Edwards curve edwards25519 (birationally equivalent to Curve25519). Signatures are 64 bytes, public keys 32 bytes, and verification is one double-scalar multiplication on the curve (one fixed-base term plus one variable-base term). The scheme is widely deployed across TLS, SSH, code-signing, and package-management systems, and is supported by every modern cryptographic library. CertiFlash uses Ed25519 as the default vendor signing scheme and as the underlying primitive for the threshold construction described next.
FROST-Ed25519. FROST [9,10] is a Schnorr threshold-signature scheme producing a standard Ed25519 signature through two communication rounds among any t-of-n participants. The aggregated signature is byte-identical to a single-party RFC 8032 Ed25519 signature, indistinguishable to the verifier from a single-key signature. CertiFlash uses the per-participant binding-factor variant from Section 4.4 of RFC 9591 [10], which addresses a forgery class identified after the original 2020 construction. The signing side requires two rounds of operator communication and coordinator-side share aggregation; none of this complexity reaches the verifying device.
ML-DSA-65. The post-quantum signature scheme standardized in NIST FIPS 204 [13], derived from the CRYSTALS-Dilithium submission. The 65-parameter set targets NIST security category 3, producing signatures of approximately 3.3 KiB and public keys of 1.95 KiB. CertiFlash treats ML-DSA-65 as a drop-in replacement for the vendor-side Ed25519 signature; the operator-quorum signature remains FROST-Ed25519, as no practical post-quantum threshold scheme yet offers a drop-in equivalent.
Canonical CBOR. RFC 8949 [12] specifies the Concise Binary Object Representation, a compact binary serialization with deterministic encoding rules in Section 4.2.1 of RFC 8949. CertiFlash uses canonical CBOR for the update bundle to ensure the byte image used in signing is unambiguous across implementations, allowing the protocol to compute domain-separated signing images without recursing into the bundle’s logical structure.
Append-only Merkle transparency logs. Certificate Transparency [21] introduced append-only Merkle trees for public, third-party-auditable logs of cryptographic events, with two proof primitives: inclusion proofs (an entry is present at a given log size) and consistency proofs (a later log root extends an earlier one rather than forking from it). The structure allows any party to verify that a given event was recorded and that the log has grown only by appending; any rewriting of history produces a mathematically detectable inconsistency. CertiFlash adopts the same machinery, proof discipline, and external-auditor model. Sigstore’s Rekor [22] and the tile-based Sunlight design [23] confirm that the architecture scales operationally beyond CT’s original use case.

2.3. Formal Verification with Tamarin

Tamarin [24] models security protocols as multiset rewriting systems. Rules describe how facts evolve over time; properties are first-order logic formulas over traces of action facts; the prover attempts automated proof by saturating sources, applying induction, and exploring state space backwards from each property’s negation. When a property does not hold, Tamarin produces an explicit counterexample trace, which is, in our experience, more useful than a binary proved/unproved verdict, because the trace tells you why the property fails.
Tamarin has a real track record in industrial-protocol analysis. Cremers et al. analyzed DNP3 Secure Authentication v5 [25] under a Dolev–Yao adversary, finding flaws that the protocol’s designers subsequently addressed. On the OTA-update side specifically, Ponsard and Darquennes formalized UpKit [26], and Lorch et al. recently combined Tamarin with the Kind 2 model checker for a comprehensive analysis of Uptane [27] that uncovered six new vulnerabilities and rediscovered five known ones. CertiFlash extends this line along two axes: a domain axis (SCADA and PLC, rather than substations, IoT, or automotive) and a threat-model axis. Specifically, our model includes an explicit operator-compromise rule with a numeric bound, allowing the adversary to corrupt up to t − 1 operators while still requiring the protocol’s authorization properties to hold.

4. Threat Model

This section names the assets the protocol protects, the entities involved, what the adversary can and cannot do, and the assumptions we rely on. The model is the reference that Section 6 (security definitions) and Section 7 (Tamarin model) both work against, so it has to be precise.

4.1. Entities and Assets

Six entities take part in a CertiFlash deployment.
The vendor holds a long-term signing key and is the source of legitimate firmware images and ladder-logic packages. There is one vendor per device line in the simplest case; nothing in the protocol prevents multi-vendor deployments.
A set of operators at the asset owner’s site holds shares of a FROST-Ed25519 group key. The site-policy threshold t and the operator count n are configured at commissioning. Operators co-authorize each install command; no single operator can sign on behalf of the group.
The engineering workstation is the machine an engineer uses to initiate an update. It does not hold any signing key. Its job is to coordinate the operator quorum, build the bundle, and push it to the target PLC.
The PLC (or RTU, or other controller) is the target device. It holds two public verification keys, the vendor’s and the FROST group’s, plus a strictly monotonic per-bundle-type counter and the most recently issued challenge nonce. The PLC has no signing key of its own.
The transparency log is an external, append-only Merkle log service. It accepts entries, typically one per accept-or-reject decision, and exposes inclusion and consistency proofs to anyone who asks.
The auditor is any third party that monitors the log for tamper evidence by checking consistency proofs across observed roots. CertiFlash assumes at least one honest auditor exists; it does not require any specific auditor identity.
The assets that need protection are the firmware and ladder logic of the PLC, the integrity and ordering of installed-version history, and the audit record of which install events the device accepted or rejected. The asset not in scope is real-time process data flowing through the PLC during normal operation; that is a separate problem with a separate literature.

4.2. Adversary Capabilities

We model a Dolev–Yao network adversary with two extensions.
The first extension is full network control. The adversary controls the network connecting all entities. They can read every message, drop messages, replay messages from any past session, modify messages in transit, and inject new messages of their own choosing. Network confidentiality is not assumed at any point in the protocol.
The second extension is bounded operator compromise. The adversary can compromise up to t − 1 operators in any quorum, where t is the site-policy threshold. A compromised operator is fully under adversarial control: the adversary holds the operator’s secret share, can operate the operator’s signing service, and can participate in any signing session in that operator’s name. Compromised operators do not count toward the honest-quorum requirement. The bound t − 1 is enforced as an explicit numeric restriction in the Tamarin model (Section 7) and corresponds to the standard threshold-cryptography assumption that fewer than t compromised parties cannot produce a valid aggregate.
The adversary can also compromise the engineering workstation. A compromised workstation has no signing keys to leak, but it can participate in operator-quorum sessions, lie about target PLC identifiers, and present false success states to its operator. Compromise of the workstation alone does not yield install authority; the operator quorum must still co-sign. The adversary can also compromise the vendor signing host the software side of the build pipeline that talks to the offline HSM. The HSM-resident key cannot be exfiltrated (this is what Figure 2’s trusted-zone placement records), but a compromised host can request signatures over attacker-chosen payloads. The operator quorum is the in-protocol defense: a valid vendor signature alone does not authorize an install, and the operator signing services run on infrastructure independent of the vendor host. The adversary can compromise the transparency-log service. A compromised log may refuse new entries, drop existing entries, equivocate on its served STH, or attempt to forge inclusion proofs. None of these capabilities lets the adversary cause a malicious install to succeed; they bound only the auditability property. Equivocation is detected by the witness co-signing scheme of Section 5.6; refusal to publish surfaces is a locally accepted but not audit-confirmed install; forging an inclusion proof against a witness-co-signed STH requires a Merkle second preimage and is computationally infeasible. The adversary can mount denial-of-service attacks. CertiFlash does not promise update availability under network partition or under sustained DoS against the operator services or the transparency log. We do promise that no fraudulent update succeeds even when DoS is in progress.
Figure 2. CertiFlash threat model. Components are grouped into three color-coded trust tiers. Green (TRUSTED): vendor signing key in offline HSM, monotonic per-PLC counter, at least one honest operator per quorum, at least one honest auditor. Yellow (ADVERSARY-REACHABLE): vendor signing host, engineering workstation, transparency log, and up to t − 1 operators. Red (ADVERSARY-CONTROLLED): full network control (Dolev–Yao). Out-of-scope items (vendor-key exfiltration, PLC physical tampering, side channels) are listed in Section 4.4.

4.3. Trust Assumptions

The vendor’s long-term signing key is not compromised. Vendor compromise is the most serious failure case in any signed-firmware design and is out of scope here for the same reason it is out of scope in TUF [18], Uptane [19], and SUIT [17]: there is no protocol-level recovery from full vendor-key compromise without a separate root of trust.
The PLC’s persistent state is intact at the moment of verification. We do not require the PLC to be unconditionally trustworthy; we require that the values the verification logic reads from local storage trust roots and counter have not been tampered with during the execution of that logic. Section 10 discusses how hardware-backed key storage strengthens this assumption in production.
At least one auditor of the transparency log is honest and active. The protocol’s auditability guarantee is that an external party who monitors the log can detect tampering; if no one ever monitors the log, the property degenerates to “the log was append-only at the time it was written.” We make no assumption about which third party is the honest auditor, just that one exists.
At least one operator in any signing quorum is honest. Since the adversary is bounded to t − 1 compromises and each quorum requires t signers, this follows by counting; we name it explicitly because Section 7 refers to it directly.

4.4. Out of Scope

Several real threats are not addressed by CertiFlash and are not claimed to be. We list each below with a short justification, because an unexplained out-of-scope item invites the reader to assume an omission rather than a deliberate boundary.
Side-channel attacks on PLC hardware. Power analysis, electromagnetic emanation, and fault injection can defeat any cryptographic verifier and are addressed by hardware countermeasures rather than protocol design. CertiFlash’s verification logic is constant-time-friendly and uses standard primitives, but we do not analyze it under a side-channel adversary. This is the appropriate scope boundary because no protocol-level change to the bundle, the signature scheme, or the verification pipeline would alter the side-channel posture; the relevant defenses live in the silicon and in the device’s physical packaging.
Physical tampering with the PLC. An attacker who can open the chassis and overwrite flash directly bypasses every protocol-level protection. Physical security is an asset-owner responsibility. Physical access is also, in practical industrial settings, controlled by means—locked enclosures, fenced substations, badge-controlled motor-control rooms—that are themselves the right place for that defense to live, rather than the update protocol.
Post-install runtime compromise of the PLC. CertiFlash protects the install pathway; what runs after the install is a different question that depends on the firmware itself. Once an install has been authorized by the vendor and the operator quorum and accepted by the device, the protocol has done its job; runtime defenses for what executes after that point are a separate research and product question.
Vulnerabilities in the firmware or ladder-logic content. CertiFlash ensures that what gets installed is what the vendor- and operator quorum-approved; it does not certify that what they approved is free of bugs. That latter question is addressed by software-quality and certification work; Tacchella et al. [28] address an adjacent question regarding formal guarantees about the content of an update and the two designs composed.
Quantum adversaries against current Ed25519 deployments. Section 8 describes the ML-DSA-65 variant; the Ed25519 path is not quantum-secure, and we do not claim otherwise. We treat post-quantum security as a migration path the framework supports rather than as a property that today’s vendor-side Ed25519 deployments already enjoy.

5. The Certiflash Protocol

This section specifies the protocol in enough detail that an independent implementation could be built from it. Section 5.1 gives the high-level shape of an update. Section 5.2 defines the bundle format and signing-image rules. Section 5.3 describes the operator-quorum signing protocol. Section 5.4 walks through a complete update session message-by-message. Section 5.5 details the nine-step verification pipeline the PLC runs on every received bundle. Section 5.6 specifies the transparency-log interface: leaf and STH formats, proof types, retry policy, witness co-signing, and the completeness condition.

5.1. Overview

At a high level, a CertiFlash update proceeds as follows. The engineer asks the PLC for a fresh challenge token. The vendor signs the new firmware together with that challenge. A quorum of operators co-signs the same package. The PLC checks both signatures, checks the challenge it issued is the one being answered, checks the version number moving forward not backward, and writes the outcome to a public log. Only after every check has passed does the PLC accept the new firmware. The rest of this section makes each of those steps precise; the structure does not get more complicated than what was just described.
A CertiFlash update is a CBOR-encoded bundle carrying a vendor signature and a FROST-Ed25519 threshold signature, sent over a session that the PLC opened with a fresh nonce. The PLC verifies the bundle, decides to accept or reject, and emits a record of that decision to an external transparency log. Figure 3 shows the entities and trust boundaries; Figure 4 shows the message sequence of a complete update.
Figure 3. CertiFlash system architecture: six entities, two trust boundaries, and the four cryptographic approvals that bind every install. Vendor and operator-quorum sign with long-term keys; the engineering workstation coordinates without holding any signing key; the PLC verifies and enforces. Trust roots (pk_V, pk_Q) are provisioned at commissioning; transparency-log decisions are independently audited.
Figure 4. CertiFlash update protocol message sequence (one update session, t = 3 quorum). Time flows downward across five lifelines. Approval messages 4 (σ_v) and 6 (σ_q) are highlighted in blue; all four cryptographic approvals are bound atomically in the PLC’s verification step. Asynchronous third-party audit (auditor → log) is omitted for clarity; see Figure 3.
Five roles participate. The vendor signs the firmware or ladder-logic payload. The operator quorum, t-of-n operators at the asset owner co-signs the install via FROST, producing one aggregated Ed25519 signature. The engineering workstation orchestrates the session: it asks the PLC for a nonce, asks the vendor to sign the payload and nonce, runs the FROST coordinator against the operator services, and pushes the resulting bundle to the PLC. The PLC verifies and stores or rejects. The transparency log records the outcome.
The protocol is transport-agnostic. The reference implementation uses TCP with length-prefixed framing on a dedicated channel, but nothing in the protocol assumes a specific transport, and the same bundle could ride over OPC UA, MQTT, HTTPS, or any vendor channel that delivers bytes reliably. Authenticity comes from the signatures, not from the channel. We do not require channel confidentiality; an eavesdropper learns the firmware contents but cannot modify them in flight without breaking signature verification.

5.2. Bundle Format

The update bundle is a canonical CBOR map [12] encoded under the deterministic rules of Section 4.2.1 of RFC 8949 [12], so two implementations that agree on the bundle’s logical contents produce byte-identical encodings. The bundle carries identity (the target PLC and a bundle type—firmware, ladder logic, or config for normal installs; emergency or trust root for changes requiring super-quorum approval), freshness (a session nonce and a per-bundle-type monotonic counter), the payload and its SHA-256 hash, an algorithm tag for the vendor signature (Ed25519 or ML-DSA-65), the list of operator identifiers (the quorum field) that participated in the quorum signature, the two signatures themselves, and a format-version field for forward compatibility. The hash is present so that the signing images commit to the payload via a fixed-size fingerprint rather than the raw bytes; step 1 of the verification pipeline (Section 5.5) verifies the binding by checking payload_hash equals SHA-256(payload), so the payload is bound to both signatures through the collision resistance of SHA-256 without inflating the signing image with the payload itself.
Two domain-separated signing images are derived from the bundle. The vendor signing image excludes both signature fields and is prefixed with a vendor-specific domain-separation tag; the quorum signing image excludes only the quorum signature and is prefixed with a quorum-specific tag. Each image is hashed with SHA-256 before signing, and both are deterministic given the bundle’s contents, so any party can recompute and re-verify them independently.
Including the vendor signature inside the quorum signing image is a deliberate composition choice. It binds the quorum’s authorization to a specific vendor signature, so an adversary cannot swap a different vendor signature into a quorum-signed bundle without invalidating the quorum signature.

5.3. Operator Quorum Signing

The quorum signature is produced by FROST-Ed25519 [9,10] using the per-participant binding-factor variant from Section 4.4 of RFC 9591 [10]. The protocol runs in two communication rounds among the t participating operators, coordinated by the engineering workstation. The coordinator does not need to be trusted with secret material; it only sees nonce commitments and signature shares.
Operator signing request. From the coordinator each operator receives the canonical CBOR bundle (without σ_q), the SHA-256 quorum signing image, the participant list of t identifiers, and the vendor signature σ_v. Five checks must be passed before the operator commits to the round: (1) the canonical CBOR encoding of the displayed bundle reproduces the received bytes (encoding-mismatch); (2) the recomputed quorum signing image and its SHA-256 match the hash to be signed (hash-mismatch); (3) σ_v verifies under pk_V over the recomputed vendor signing image (vendor-sig-invalid); (4) the target PLC, bundle type, and sequence match an open authorisation in the operator’s local policy (unauthorized-request); (5) the operator’s own identifier appears in the participant list (not-a-participant). The metadata displayed to the human operator before the consent target PLC, bundle type, sequence, payload SHA-256, vendor identity, and participant list is read from the same bytes the five checks bind to. Any failure produces a typed rejection returned to the coordinator and logged by the operator service. The operator emits its nonce commitments only after all five checks succeed.
Round 1: nonce commitments. Each participating operator generates two fresh scalars, a hiding nonce d_i and a binding nonce e_i and sends the corresponding curve points (D_i, E_i) to the coordinator. The operator keeps (d_i, e_i) as session-local state through Round 2 and discards them immediately after producing its signature share.
Coordinator binding-factor computation. The coordinator collects all (D_i, E_i) pairs from the t operators, plus the message m (the SHA-256 of the quorum signing image). Following RFC 9591 Section 4.4, it computes a binding factor ρ_i per participant by hashing together the participant’s identifier, the message, and the full commitment list. The per-participant binding factor closes a forgery class identified after the original 2020 FROST construction, where a single binding factor was reused across all participants.
Round 2: signature shares. Each operator receives back the commitment list, the message, and the binding factor ρ_i. It computes its signature share z_i using its long-term share s_i, its session nonces (d_i, e_i), and ρ_i. The share goes back to the coordinator.
Aggregation. The coordinator sums the z_i values into a single scalar z, and combines the per-participant commitments into a single curve point R. The pair (R, z) is a standard Ed25519 signature against the FROST group’s public key.
Authentication and round liveness. Operator signing services authenticate to the coordinator over mutual TLS using certificates issued at commissioning; the coordinator validates the certificate chain before any per-session message is accepted. Round 1 has a coordinator-side timeout (default 5 s, site-configurable). If fewer than t commitments arrive by the timeout, or if any participant returns a typed rejection from the five checks above, the session is abandoned: a typed failure naming the missing or rejecting operators is returned to the workstation, no signature is aggregated, and each operator discards its session-local nonces (d_i, e_i) so they cannot be reused. The protocol does not silently retry; any retry is initiated as a fresh session bound to a new PLC challenge nonce, so neither operator nonces nor the PLC freshness state is carried across attempts.

5.4. Update Session

A complete update proceeds through the following message exchange. We use W, PLC, V, Q, L for workstation, target PLC, vendor, operator quorum (collectively), and transparency log, respectively.
W → PLC: OpenSession(workstation_id)
PLC → W: Nonce(N)//32-byte fresh random
W → V: SignRequest(payload, target, seq, N, bundle_type)
V → W: VendorSig(σ_v)
W → Q: QuorumSign(payload, target, seq, N, σ_v, bundle_type)
//FROST 2-round protocol
Q → W: QuorumSig(σ_q)
W → PLC: Bundle(B = {payload, target, seq, N, σ_v, σ_q, …})
PLC: verify(B) → accept or reject
PLC → L: LogEntry(B, decision, reason?)
PLC → W: Result(decision, reason?, log_index?)
Several properties of this flow matter for security.
The nonce is bound at signing time. The PLC issues N before the workstation requests vendor or quorum signatures. Both σ_v and σ_q cover N. An adversary who replays a previously valid bundle to the same PLC will fail the nonce check, because the PLC issues a fresh N for each session and remembers only the most recent one it issued.
The workstation is not trusted. A compromised workstation can issue arbitrary requests to the vendor and the operator quorum, but cannot produce signatures itself. The vendor’s signing service may have its own authorization policy; the operator services require their per-share authentication. Neither contributes anything to the bundle without a properly authorized request. The workstation-authority shift is the framework’s most practical contribution and warrants explicit statement. In current ICS deployments, the engineering workstation is the de facto seat of install authority; whoever controls that machine can, with the vendor tools that live on it, change the behavior of physical equipment. CertiFlash relocates that authority. The workstation becomes a coordinator that orchestrates a process whose authoritative consents come from elsewhere, aside from the vendor’s signing service and the operator quorum. The practical consequence is that the consequences of a workstation compromise are bounded to denial of service, false status reporting back to the engineer, and the usual harms of an attacker on the inside of an OT network, none of which are negligible, but none of which extend to silently pushing a malicious update.
Logging happens after the verification decision. The PLC enqueues a log entry for every accept and reject before replying to the workstation; the queue is durable and publication follows Section 5.6. Auditability (Section 6.5) is conditioned on the entry eventually reaching a witness-co-signed STH, not on synchronous publication.
The operator quorum binds to bundle bytes, not coordinator claims. The operator-side checks of Section 5.3 ensure that what each operator signs is the SHA-256 of the canonical CBOR encoding of the bundle they were shown, with a verified vendor signature inside it. A compromised coordinator that substitutes a different bundle, hash, or vendor signature fails one of those checks and obtains no share.

5.5. Plc Verification Pipeline

When the PLC receives a bundle in the bundle message of Section 5.4, it runs nine ordered checks (Figure 5). Each check has a single rejection reason; on rejection the PLC logs the bundle and the reason, and returns the reason to the workstation.
Figure 5. PLC verification pipeline. Nine sequential checks are applied to each update bundle. Steps 1–3 perform structural and metadata validation; steps 4–7 verify the four cryptographic approvals (blue badges for externally produced signatures, green badges for PLC-internal state); step 8 enforces additional super-quorum approval for emergency or trust-root bundles; step 9 records the decision on the transparency log and atomically applies the firmware. Any step’s failure routes uniformly to a reject result with explicit reason, also recorded on the log.
The full pipeline:
  • CBOR structural validation. The bundle decodes as canonical CBOR with the schema of Section 5.2. All required fields are present with the right types, and payload_hash equals SHA-256(payload). Reject reason: bundle-format.
  • Version check. version == 1. Future protocol versions will require explicit support. Reject reason: unsupported-protocol-version.
  • Target check. target == self.plc_id. A bundle signed for a different PLC is rejected immediately, even though both signatures may verify. Reject reason: target-mismatch (or group-mismatch for group-targeted bundles).
  • Nonce check. nonce == self.last_issued_nonce. The nonce must match the most recent challenge the PLC issued in an open session. The nonce is consumed on accept and on reject—once a nonce has been used in a verification attempt, it cannot be reused. Reject reason: nonce-mismatch.
  • Counter check. seq > self.counters[bundle_type]. The sequence number must be strictly greater than the PLC’s stored counter for the matching bundle type, ensuring no rollback. Reject reason: counter-not-increasing.
  • Vendor signature verification. Recompute the vendor signing image from the bundle, hash it, and verify σ_v with the trust root’s vendor public key under the algorithm named in vendor_sig_alg. Reject reason: vendor-sig-invalid.
  • Threshold signature verification. Recompute the quorum signing image, hash it, and verify σ_q against the FROST group public key using a standard Ed25519 verifier. Reject reason: threshold-sig-invalid.
  • Super-quorum check (conditional). If the bundle’s type is emergency or trust root, the number of operators recorded in the bundle’s quorum field must meet or exceed the PLC’s super-quorum threshold (configured at commissioning). Normal-type bundles skip this check. Reject reason: super-quorum-required.
  • Stage and commit. Three states are distinguished. A bundle in the pipeline is pending. After it passes checks 1–8 the PLC writes payload and seq into the staging slot by writing to a temporary file and renaming it atomically, and marks the slot staged; self.counters[bundle_type] is not touched. Commit atomically swaps the install slot to the staged payload, advances self.counters[bundle_type] to seq, persists both, and enqueues the accept log entry per Section 5.6. The committed counter advances at commit and at no other point. A crash between stage and commit therefore leaves the previous committed firmware and committed counter intact; on reboot the PLC discards the staged-but-uncommitted slot. The same bundle, resubmitted, then re-stages cleanly; this is not a rollback, because no commit has advanced the counter past it (cf. scenario 4, Section 9.1). Crash-recovery scenario 08 (Section 9) exercises this path.
The order is deliberate. Cheap checks come first so trivially malformed bundles are rejected before expensive cryptographic operations. The target, counter, and nonce checks all come before signature verification: an adversary who has somehow obtained a valid bundle for a different PLC, a stale-seq bundle, or a valid bundle from a past session learns that fact without the PLC spending two signature verifications on it. The counter check precedes the nonce check because the counter is persistent PLC state independent of the session; rejecting on persistent state first surfaces rollback attempts uniformly regardless of session context.
Step 8, the super-quorum check, has an operational implication worth noting. The super-quorum threshold raises the authorisation bar for the two bundle classes emergency firmware and trust-root rotation where the consequences of a wrong install are most severe. The trade-off is response time: a higher threshold means more operators must be reachable to authorize an emergency change, and in precisely the incident-response situations where emergency updates are needed, operator availability is least certain. Sites should set the super-quorum threshold deliberately, with reference to how many operators they can realistically convene out of hours, and CertiFlash’s per-bundle-type configurability is intended to support that judgment rather than override it.
The pipeline is the operational manifestation of the security properties Section 6 defines formally. Each rejection reason corresponds to a property the bundle would have violated; the property is what is being enforced, and the rejection reason is how the PLC explains its decision to the rest of the system.

5.6. Transparency-Log Interface

Leaf. Canonical CBOR map: timestamp, plc_id, bundle_type, seq, nonce, payload_hash, bundle_digest, vendor_sig_digest, quorum_sig_digest, participant_list, decision, reason (omitted on accept). Leaf hash: SHA-256(0×00‖leaf-bytes), per Section 2.1 of RFC 6962 [21].
STH. tree_size, root_hash, timestamp; signed by the log’s Ed25519 key, whose public counterpart sits in each PLC’s trust root.
Proofs. Inclusion (leaf index plus log_2 N audit-path hashes) places a leaf at a tree size; consistency between sizes s_1 < s_2 shows the later tree extends the earlier. Both verify in O(log N) hashes plus one Ed25519 op.
Split-view defense. The PLC accepts an STH as audit-confirming only with w-of-W witness co-signatures, configured at commissioning. Witnesses check each STH’s consistency against the previous, sign, and gossip; divergence surfaces when two witnesses compare roots.
Retry. Each decision is durably queued before the submit-entry call; failures retry with exponential back-off (1 s → 60 s cap). Nothing is discarded.
Completeness. Locally accepted: Section 5.5 is committed and the entry is queued; the PLC may run the new firmware. Audit-confirmed: a witness co-signed STH and matching inclusion proof are stored. Sites choose which state gates the next update.

6. Security Definitions and Proof Sketches

This section gives precise statements of the four security properties CertiFlash provides, under the threat model of Section 4. We use the word guarantee advisedly: each property holds against the adversary explicitly modeled, not against an arbitrary attacker. We note operational caveats inline where they materially constrain what the property says about a deployed system. The definitions are at the level of detail typically used in applied-security papers’ entity-and-event language with explicit predicates rather than full game-based notation with explicit oracles. Section 7 then describes the Tamarin model that machine-checks all four properties under a concrete adversary; Section 9 reports on attack scenarios that corroborate the same claims through concrete execution.

6.1. Properties and Notation

We use the entity vocabulary from Section 4. The vendor V holds a long-term signing key sk_V; its public counterpart pk_V is provisioned in every PLC’s trust root. The operator quorum Q is a set of n operators with FROST-Ed25519 shares totaling a single group secret sk_Q; the corresponding group public key pk_Q is also in every PLC’s trust root. A PLC π has a unique identifier id_π, a per-bundle-type counter array cnt_π, a most-recently issued nonce N_π, and the same trust root as every other PLC in the deployment. The transparency log L is an append-only Merkle log per RFC 6962 [21] with public root reads.
A bundle B has the schema of Section 5.2. We write B.target, B.seq, B.nonce, B.payload, B.σ_v, B.σ_q for the corresponding fields. We write Acc(π, B) for “PLC π accepted bundle B”, meaning the bundle passed all nine checks of the verification pipeline (Section 5.5) and was committed. We write LogAcc(B) and LogRej(B, r) for accept and reject log entries written to L. The adversary A is the Dolev–Yao network attacker of Section 4.2, with the additional capability of compromising up to t − 1 operators in the t-of-n quorum.
The four properties below hold under the assumptions of Section 4.3.

6.2. P1 Update Authenticity

Property. If a PLC π accepts a bundle B at some point in time, then there exist (a) a valid vendor signing event in which V produced σ_v over the vendor signing image of B, and (b) a valid quorum signing event in which a set of t legitimate operators (of which at least one is honest) produced σ_q over the quorum signing image of B.
Formally: ∀π, B. Acc(π, B) ⟹ ∃ OpSet. VendorSigned(B) ∧ QuorumSigned(B, OpSet) ∧ |OpSet| ≥ t ∧ |OpSet ∩ Honest| ≥ 1.
Proof sketch. Suppose A causes a PLC π to accept a bundle B for which no such vendor and quorum signing events exist. Step 6 of the verification pipeline checks σ_v against pk_V using the algorithm named in B.vendor_sig_alg; for Acc(π, B) to hold, this check must succeed. If V never signed the corresponding vendor signing image, σ_v is an existential forgery against pk_V contradicting EUF-CMA security of the underlying signature scheme (Ed25519 [11] or ML-DSA-65 [13]). Step 7 checks σ_q against pk_Q using a standard RFC 8032 verifier [11]. If no t-of-n operator quorum produced σ_q, then σ_q is a forgery against pk_Q contradicting FROST-Ed25519’s t-of-n unforgeability under up-to-(t − 1) compromise [9,10]. Either contradiction completes the argument. The honest-operator clause follows from the threshold bound of Section 4.2: with at most t − 1 compromised operators and a quorum size of t, at least one participant in any successful quorum signing must be honest.
This property is machine-checked by Tamarin lemma update_authenticity (Section 7).

6.3. P2 Authorization Correctness

Property. No quorum signature σ_q that verifies against pk_Q was produced by a set of fewer than t operators.
Formally: ∀ B. VerifyQuorumSig(B.σ_q, pk_Q, image_q(B)) = ⊤ ⟹ ∃ OpSet. |OpSet| ≥ t ∧ QuorumProduced(B.σ_q, OpSet).
Proof sketch. This property reduces directly to FROST-Ed25519’s threshold unforgeability theorem [9,10]. Under the discrete-log assumption in the Edwards-curve group used by Ed25519, no algorithm running in polynomial time and with access to fewer than t operator shares can produce a signature that verifies against pk_Q with non-negligible probability. The per-participant binding-factor variant from Section 4.4 of RFC 9591 [10] specifically closes a forgery class identified after the original 2020 construction; we use this variant. The quorum signing image construction (Section 5.2) is collision-resistant under the assumption that SHA-256 is collision-resistant and that canonical CBOR encoding is injective both of which hold for the deterministic encoding rules of Section 4.2.1 of RFC 8949 [12].
Note that P2 says nothing about which t operators signed; it says only that at least t did. The honest-operator-in-quorum clause of P1 comes from combining P2 with the adversary’s compromise bound.
This property is machine-checked by Tamarin lemma authorization_correctness (Section 7).

6.4. P3 Rollback Resistance

Property. For any PLC π, the sequence of accepted bundles for a given bundle type has strictly increasing seq values, assuming the persistent-storage assumptions of Section 4.3 hold, and this monotonicity holds across PLC restarts and across crashes between staging and committing an update.
Formally: ∀π, B_1, B_2. Acc(π, B_1) ∧ Acc(π, B_2) ∧ B_1.bundle_type = B_2.bundle_type ∧ time(Acc(π, B_1)) < time(Acc(π, B_2)) ⟹ B_1.seq < B_2.seq.
Proof sketch. Step 4 of the verification pipeline rejects any bundle whose seq is not strictly greater than the PLC’s committed counter for the matching bundle type. By Section 5.5 step 9, the committed counter advances at commit and at no other point, persisted by writing to a temporary file and renaming it atomically, together with the install slot pointer. A crash between stage and commit therefore leaves the committed snapshot counter and payload intact; the staged slot is discarded on reboot. The counter never regresses across crashes or restarts. On restart the PLC reads the committed counter from the disk; the pipeline rejects any bundle whose seq is at-or-below it, including bundles that were valid earlier in the protocol’s history. The property reduces to (a) monotonicity of integer comparison and (b) atomicity of the commit step.
This property is machine-checked by Tamarin lemma rollback_resistance (Section 7), and operationally validated by attack scenario 04 (rollback) and crash-recovery scenario 08 in Section 9.

6.5. P4 Log Auditability

Property. Every accept decision Acc(π, B) is recorded in the transparency log L as LogAcc(B); tampering with any entry is detectable by any honest auditor requesting a consistency proof between two observed log roots.
Formally, the property has two parts. Completeness: ∀ π, B. Acc(π, B) ⟹ ∃ i. L[i] = LogAcc(B). Tamper evidence: for any two log roots r_old, r_new at sizes s_old < s_new, an auditor requesting a consistency proof π_c verifies that r_new’s entries at indices 0 to s_old − 1 match those committed at r_old; any modification breaks the check.
Proof sketch. Completeness follows from Section 5.4: the PLC writes the log entry in the pipeline’s commit phase and the result returned to the workstation includes the log index; a PLC that fails to write has not produced an Acc event. Tamper evidence reduces the consistency-proof soundness of RFC 6962 Merkle logs [21]: given r_old over the first s_old entries, π_c constructs r_new extending r_old; any modification at index i < s_old alters the path from leaf i to the root, breaking either the inclusion or the consistency check. The reduction holds under the second-preimage resistance of SHA-256.
The property is conditional on at least one honest auditor making queries (Section 4.3); an unaudited log provides only the structural append-only guarantee, not detection of tampering.
This property is machine-checked by Tamarin lemma log_auditability (Section 7).
The four properties together characterize the protocol’s security guarantees: authenticated origin and authorized installation (P1, P2), monotonic version advancement (P3), and externally verifiable audit trails (P4). Section 7 presents the Tamarin model and verification results; Section 8 describes the reference implementation.

7. Formal Verification with Tamarin

This section describes the Tamarin model of the CertiFlash protocol and the verification results it produces.
Formal verification matters because it changes what ‘the protocol is secure’ means. Without it, the claim rests on the designers having considered all relevant attacks; with it, the claim rests on an exhaustive symbolic search over the model finding no counterexample. For protocols controlling physical equipment, the distinction is consequential. Building the model also surfaces specification and abstraction issues that prose review and unit testing alone do not catch, as we describe at the end of Section 7.2.

7.1. Modeling Approach

Tamarin [24] models security protocols as multiset rewriting systems. Each rule consumes a set of facts representing the current protocol state and produces a new set of facts; rules can be persistent (the prover may reuse them) or linear (each instance is consumed when used). Properties are first-order formulas over traces of action facts, events the prover records as rules fire. The Dolev–Yao network adversary is built into Tamarin’s standard model; additional adversary capabilities are encoded as rules that emit appropriate facts and outputs.
The protocol-modeling approach for CertiFlash is conventional: each entity from Section 4.1 has a setup rule that establishes its long-term keys and persistent state, and one or more action rules that drive the protocol’s message flow. The cryptographic primitives are abstracted at the level Tamarin’s equational theories support, a signature is an opaque term whose verification is decidable, not a reduction to discrete-log hardness which is appropriate for symbolic protocol analysis. The reductions to standard cryptographic assumptions live in the proof sketches of Section 6.
Two modeling choices deserve mention because they affect what the model actually proves.
The FROST aggregate is treated as a single signature. The model does not capture the two-round FROST signing protocol step-by-step. Instead, it has a Quorum_Sign_Bundle rule that consumes t operator-share facts and emits one aggregated signature plus the action facts naming the participating operators. This abstraction is consistent with the architectural property we care about: the verifier sees a standard Ed25519 signature and is FROST-agnostic. Verifying the FROST construction itself was done by Komlo and Goldberg in their original analysis [9] and is referenced by RFC 9591 [10]; we do not redo that work.
Operator compromise is bounded by an explicit numeric restriction. The model includes a Compromise_Operator rule that emits a compromised fact and outputs the operator’s share to the network. A Tamarin restriction caps the count: any trace with more than t − 1 distinct compromised events is rejected. This restriction is what lets us state security properties that hold under partial operator compromise: the model is sound only for traces in which the compromise bound is respected, which corresponds exactly to the threat model of Section 4.2.

7.2. The Certiflash Model

The model encodes the entities and message flow of Section 5, with rule structure mirroring the protocol description.
Setup. Setup rules establish the vendor’s long-term key, the FROST group public key together with shares for n operators, and the persistent state of a PLC: its trust root, its monotonic counter, and an empty nonce slot. The transparency log is initialized empty. The threshold t and operator count n are concrete parameters; the model is instantiated with t = 3 and n = 5 throughout the verification reported in Section 7.3.
Adversary capabilities. Beyond the standard Dolev–Yao network rules provided by Tamarin, the model adds an operator-compromise rule that releases an operator’s secret share to the network. A numeric restriction caps the number of distinct compromise events at t − 1, enforcing the threshold-cryptography assumption of Section 4.2. Workstation compromise (Section 4.2) is not modeled as a separate rule; it is captured implicitly by the network adversary’s ability to inject any message that a workstation could have produced.
Protocol rules. Six rules encode the message flow. The first issues a fresh challenge nonce at the verifier and records it as session state. The second produces a vendor signature over the bundle. The third produces the aggregated operator-quorum signature, consuming t distinct share facts as inputs and emitting the participating operators as action facts. The fourth and fifth correspond to the accept and reject paths of the verification pipeline of Section 5.5; both emit an action fact recording the decision, which is consumed by the auditability lemma. The sixth models an external auditor querying the transparency log for inclusion proofs.
Constructing the model surfaced a composition issue not visible from the prose specification or from component-level testing. An early formulation of the quorum signing rule admitted adversarial substitution of the aggregate signature, because the verification predicate did not constrain the signature’s relationship to the group key. The corrected rule binds the aggregate to a group-key-derived term, eliminating the substitution path. Such findings, observable under symbolic analysis but not under unit testing, illustrate the value of formal verification for protocols that compose multiple cryptographic primitives.

7.3. Lemmas and Verification Results

The model defines fourteen lemmas: one for each of the four security properties from Section 6, two additional analysis lemmas, and eight reusable helpers that decompose structural reasoning into pieces the prover discharges automatically. Table 2 reports verification results for the security and analysis lemmas.
The verification environment is Tamarin 1.12.0 with Maude 3.5.1, running under WSL2/Ubuntu 24.04 on an Intel Core i9-14900HX. The model and per-lemma proof outcomes are reproducible from the framework’s formal-verification harness.
Eight reusable helper lemmas verify alongside the main security lemmas, all themselves machine-checked.
Model sanity check. The functional_sanity lemma is an existential trace assertion that the model admits at least one valid execution. The unproven status is a real limitation, not a presentational one: a universal lemma over an empty action-fact set is vacuously satisfied, so the four security claims are conditional on non-vacuity. Non-vacuity holds at the symbolic level by structural inspection. Each accept-producing rule’s premise facts (a trust root from the setup rule, a vendor signature from the vendor rule, a quorum signature aggregated from t share facts, and a matching nonce from the verifier-issued challenge) are themselves derivable from the setup rules and the standard Dolev–Yao adversary, so the Acc(π, B) action fact that gates P1, P3, and P4 is reachable in some model trace, and the same holds for the verifier action facts that gate P2. The reference implementation (Section 8) shows that the protocol can be implemented; it does not show that the symbolic model is non-vacuous. Closing the existential mechanically, on a restricted instance or via a custom tactics script, is flagged as a clean follow-up in Section 10.4.
The proofs cite reusable helper lemmas to decompose structural reasoning into pieces the prover discharges automatically, a standard pattern in industrial-protocol Tamarin analyses (Lorch et al. [27], Cremers et al. [25]). All helpers are machine-checked; no security claim depends on an unproven assumption. The combination of formal verification (Section 7) and concrete attack exercise (Section 9) supplies the two-pronged validation discussed in Section 10.2.
The summary table:
Table 2. Tamarin verification results across the model’s nine lemmas.

8. Implementation

The framework is realizable end-to-end as software. A reference realization produces every measurement reported in Section 9 and serves as the artifact-level evidence that the protocol’s specification (Section 5) and security properties (Section 6) admit a concrete, deployable instantiation. This section discusses the technical requirements the framework places on any realization, the cryptographic primitives the protocol composes, and the discipline applied to make the evaluation reproducible. The intent is to characterize the framework’s implementability rather than to describe a specific codebase.

8.1. Implementation Approach

The framework decomposes into seven roles, vendor signing service, per-operator FROST signing services, FROST coordinator, engineering-workstation client, PLC verifier with persistent state, transparency log, and external auditor, each realizable as an independent process. Every protocol message of Section 5.4 corresponds to a real inter-process exchange in the reference realization, and each step of the nine-step verification pipeline (Section 5.5) is enforced on the verifier path. Realization in a single process or across distributed hosts is permitted by the protocol; the role decomposition is a property of the framework, not of any specific deployment topology.
Realization in a high-level language was a deliberate methodological choice. The verifier’s logic should read alongside the Tamarin model so that the relationship between specification and prover is auditable; the cryptographic library surface should be mature and standardized so that no claim depends on bespoke primitive implementations. The reference realization satisfies both constraints with Python 3.12 and the established cryptography, liboqs-python, and cbor2 libraries. Performance under representative workloads (Section 9) is sufficient at this level of abstraction; the verifier path is short and free of language-specific idioms in its hot path, so a port to a systems-programming language for resource-constrained PLC deployment is straightforward (Section 10).

Anticipated Friction in Real Industrial Environments

The reference realization runs on a developer workstation under Docker. A production deployment will encounter friction the laboratory artifact does not surface, and it is worth saying so plainly rather than implying that a containerised stack on commodity hardware translates without effort into a substation cabinet or a factory motor-control room. Three classes of friction in particular are worth naming, both because they shape integration timelines and because they shape what kinds of deployments are accessible in the near term.
Constrained-resource PLCs. A meaningful fraction of the installed base older Siemens S7-300 family parts, legacy Modicon Quantum controllers, Schneider Premium devices runs on tens to low hundreds of kilobytes of RAM and processors in the 100–400 MHz class. These devices may not have an in-firmware Ed25519 verifier today, and adding one may require a vendor firmware update that is itself subject to the same change-control process CertiFlash is meant to govern. The retrofit story for this segment is therefore not ‘drop in the new verifier’; it is closer to ‘bridge through a gateway device that fronts a fleet of legacy controllers and runs the verification on their behalf’. We expect, and the framework’s transport-agnostic design supports, that early production deployments will involve such gateway devices rather than direct in-PLC verification.
Uptime and maintenance windows. Many industrial sites operate under strict availability targets utilities under regulatory uptime contracts, continuous-process manufacturers where a controlled stop costs five to six figures per minute. The deployment of a new update mechanism into such a site is not a software-engineering task on the operator’s normal cadence; it is a scheduled outage, often months in advance, and rolled back to a known-good state if anything regresses. The framework’s commissioning step (trust-root provisioning, operator-share distribution) sits inside that outage envelope and must complete reliably the first time. The reference realization’s deterministic docker compose bring-up is helpful for testing this in a lab; field deployment will need vendor-specific equivalents in vendor tooling.
Outdated firmware and partial-feature stacks. Real ICS environments contain devices that have not been firmware-updated since commissioning, sometimes for excellent operational reasons. The framework’s design does not require synchronous fleet-wide upgrade; CertiFlash can be deployed on a subset of devices, with non-participating devices continuing on their current vendor mechanism, until natural refresh cycles bring the rest of the fleet into the new regime. The transparency log is the architectural piece that makes this gradual rollout tractable, since auditors can monitor only the devices in scope without disrupting the rest.
We do not claim these frictions are solved by the present work. They shape an honest answer to the question ‘how long until CertiFlash protects my plant’, which in current evidence is years rather than months for a production environment of any meaningful size, and which we expect to study further in the field-deployment work outlined in Section 10.4.

8.2. Cryptographic Stack

The framework composes well-understood primitives from established libraries. The composition itself is the cryptographic contribution; no primitive is constructed from scratch beyond what RFC 9591 specifies for the FROST signing protocol. Five composition choices shape what the framework can claim and deserve explicit mention.
Ed25519 verification on the PLC is primitive-agnostic. The aggregate produced by the FROST coordinator is byte-identical to a standard RFC 8032 Ed25519 signature, which means the framework requires no FROST-specific construction on the verification path. A regression test in the reference realization pins this architectural property by verifying a three-of-five FROST aggregate using only the standalone Ed25519 verifier from the cryptography library, with no FROST machinery on the verification path.
FROST follows RFC 9591 strictly. The threshold signing protocol uses the per-participant binding-factor variant from Section 4.4 of RFC 9591 [10], not the original 2020 single-binding-factor construction. Each participant’s binding factor is computed by hashing its identifier together with the message and the full commitment list. This closes a forgery class identified after the original construction was published; we use the fixed variant so that the unforgeability theorem from [9] applies to our composition without caveats.
ML-DSA-65 fails closed. The framework requires that any PQC realization use a standardized FIPS 204 implementation rather than a development stub. The reference realization wraps liboqs-python against a liboqs C build and treats the presence of a working binding as a precondition: a runtime check causes benchmarking to exit with non-zero status if the binding is missing or non-functional. The framework is explicit that any PQC measurement reported against it is a measurement against the standardized algorithm.
Canonical CBOR is a load-bearing security primitive, not just an encoding convenience. The signing-image rules of Section 5.2 are sound only if any two encoders produce byte-identical outputs for logically equivalent bundle contents; if encoder determinism failed, signature-substitution attacks against either signing image would become possible. The framework therefore requires strict adherence to the deterministic encoding rules of Section 4.2.1 of RFC 8949 [12]. The reference realization uses cbor2 with deterministic encoding flags set, and pin encoder determinism with unit tests against fixed bundle inputs.
A control-traffic coexistence requirement is built into the framework. CertiFlash’s update channel must run alongside the SCADA control traffic the PLC already serves, without disrupting it. The reference realization satisfies this by running Modbus TCP and Siemens S7 servers concurrently with the update channel on a simulated PLC; the framework does not depend on a faithful emulation of any specific vendor firmware, since the security argument is about the update protocol’s behavior rather than its integration into a specific runtime. Emulating proprietary vendor flows would change nothing about the security properties; vendor-specific integration is a deployment-engineering question discussed in Section 10.

8.3. Reproducibility

The framework’s reference realization is packaged as a multi-service container stack so that all measurements in Section 9 are reproducible end-to-end from a fresh state, on commodity hardware, in approximately ten minutes. Reproducibility is treated as a property of the framework rather than as a convenience of the realization: the protocol’s role decomposition (Section 5.1) maps onto independent containers, the evaluation harness drives the resulting deployment without manual intervention, and every measurement reported here is regenerable from the same harness.
The development and evaluation environment is Ubuntu 24.04 under WSL2 on Windows 11, on an Intel Core i9-14900HX, with Python 3.12.3, liboqs 0.15.0, liboqs-python 0.14.1, Tamarin 1.12.0 with Maude 3.5.1, and Docker 29.1.3 with Compose v2.40.3. The complete artifact set, Python sources for all services, the Tamarin theory file and proof scripts, Dockerfiles and docker compose with pinned image digests, the evaluation harness that produces every measurement and figure of Section 9, and the raw measurement CSVs are available to academic reviewers and researchers on reasonable request. A public DOI release will accompany the field-deployment study of Section 10.4. Independent replication on a different host has not yet been performed.

9. Evaluation

This section evaluates CertiFlash along three dimensions: security efficacy through a catalog of ten concrete attack scenarios (Section 9.1), performance overhead in verification, bundle size, signing latency, and end-to-end update latency (Section 9.2, Section 9.3, Section 9.4 and Section 9.5), and fleet-scale behavior under sustained load (Section 9.6). Section 9.7 maps the protocol’s controls to the relevant IEC 62443 and NIS2 requirements.
All measurements were collected on the development environment described in Section 8.3 Ubuntu 24.04 under WSL2 on Windows 11, Intel Core i9-14900HX, Python 3.12.3, liboqs 0.15.0, against the live containerized realization. Sample sizes are 50 per measurement cell unless otherwise noted; we report mean, p95, or p99 as appropriate per measurement. All raw measurements are reproducible from the framework’s evaluation harness.
Hardware scope. Vendor and FROST signing run off-device; only the verification pipeline (Section 5.5) runs on the PLC. The numbers below characterize the workstation-class realization. In-PLC CPU, RAM, flash, jitter, and Modbus/S7 stack-coexistence measurements are out of scope here and are flagged in Section 10.3.

9.1. Attack Catalog

We constructed ten concrete scenarios, nine adversarial attacks targeting one or more of the security properties from Section 6, and one fault-tolerance test for the crash-recovery behavior of step 9. Each is implemented as a self-contained script that constructs the input, sends it through the protocol, and checks the outcome. All nine attacks are blocked by the implementation with explicit rejection reasons, and the crash-recovery scenario completes without exposing exploitable state.
Before listing the attacks, a word on how realistic each is in current ICS environments. The ten scenarios were chosen to span the protocol’s attack surface for coverage purposes, not because they are all equally likely in practice. We classify each into one of three categories: commonly observed scenarios for which credible public incident reports exist within roughly the past five years; plausible but not widely reported scenarios that follow naturally from documented attacker capabilities (e.g., access to vendor toolchains, OT-network footholds) but for which we cannot point to a specific published incident; and primarily defensive coverage, scenarios that are unlikely in practice but exercise a specific protocol property whose absence would be a meaningful design flaw. The categorisation appears in Table 3 below. We label rather than rank because operators’ threat-model priorities vary by sector—a utility under active state-sponsored interest will weight insider/credential scenarios differently to a contract manufacturer worried primarily about cybercriminal tooling—and a single ranking would obscure that variation.
1. Forged vendor signature. The adversary constructs a bundle with a vendor signature that was not produced by the legitimate vendor key. Blocked at step 4 of the verification pipeline; rejection reason vendor-sig-invalid. Validates property P1.
2. Sub-threshold operator collusion. The adversary controls t − 1 = 2 of the five operators and attempts to produce a quorum signature using only their shares. The aggregation either fails because the FROST coordinator does not receive enough shares, or, if the adversary forges a synthetic aggregate, the signature does not verify against the group public key. Blocked at step 6; rejection reason quorum-sig-invalid. Validates property P2.
3. Replay within a session. The adversary captures a valid bundle and resends it after the original session completes. The PLC has issued a fresh nonce in the meantime, so the captured bundle’s nonce no longer matches. Blocked at step 7; rejection reason nonce-mismatch. Validates the nonce-binding component of P1.
3a. Cross-session replay. Two-part attack. First, the adversary replays a previously accepted bundle to the same PLC in a later session—fails at the nonce check. Second, the adversary replays the same bundle to a different PLC with that PLC’s fresh nonce—fails at the target check. Blocked at steps 7 and 3, respectively. Validates the nonce-binding and target-binding components of P1.
4. Rollback. The adversary captures a valid older bundle and attempts to install it after a newer bundle has been accepted. The PLC’s stored counter has advanced past the older bundle’s seq value. Blocked at step 5; rejection reason counter-not-increasing. Validates property P3.
5. Log tampering. The adversary modifies an existing entry in the transparency log’s storage. The auditor, on its next consistency-proof check, detects that the new log root does not extend the previously observed root in a way that preserves the modified entry’s leaf value. The tampering is detected, with the auditor producing the inconsistent proof as evidence. Validates property P4.
6. Network man-in-the-middle. The adversary modifies the bundle in transit, attempting to substitute a different payload, target, or seq. Any modification to a field in either signing image causes the signature check to fail. Blocked at step 4 or 6 depending on which signature was first to fail. Validates the integrity component of P1.
7. Compromised engineering workstation. The adversary fully controls the workstation, including its identity material. The workstation can request signing services and forward bundles, but it has no signing keys of its own. Without operator-quorum cooperation, the adversary cannot produce a valid quorum signature; without vendor cooperation, no valid vendor signature. The workstation can deny service but cannot forge an accepted update. The attack does not produce an accept; we record this as a successful defense.
8. Crash recovery (fault-tolerance test, not an adversarial attack). A power loss or process kill terminates the PLC between the stage and commit phases of step 9; the durability and atomicity component of P3 requires that such events leave no exploitable state. On restart the PLC finds the previously committed configuration intact and discards the staged but uncommitted slot. Because the committed counter advances at commit and at no other point, it is unchanged here, and the same bundle re-stages cleanly not a rollback (cf. scenario 4), since no commit has advanced the counter past it. The previous configuration continues operating until a successful commit. Validates the durability and atomicity component of P3.
9. Wrong target PLC. The adversary sends a bundle that was correctly signed for PLC π_1 to a different PLC π_2. The target field does not match. Blocked at step 3; rejection reason target-mismatch. Validates the target-binding component of P1.
The realism categorisation of the ten scenarios is:
Table 3. Realism categorisation of the ten attack scenarios. Operators with different threat-model priorities may weight these categories differently; the table is a descriptive aid, not a ranking.
Summary. All nine attack scenarios were blocked, and the crash-recovery fault-tolerance test passed. Three of the nine attacks were blocked by the cheap pre-cryptographic checks (target, nonce, counter), saving the verifier from running signature operations on inputs that would have failed downstream. The complete catalog with per-scenario outcomes is reproducible from the framework’s evaluation harness.

9.2. Verification Latency

Verification latency is the time the PLC takes to run the full nine-step pipeline of Section 5.5 against a received bundle. We measured this for both vendor signature algorithms (Ed25519 and ML-DSA-65) across payload sizes from 1 KiB to 10 MiB, with 50 measurements per cell.
For Ed25519, median verification time is 2.84 ms at 1 KiB payload and rises to 5.43 ms at 1 MiB. The p95 stays within roughly 25% of median across all payload sizes, indicating low variance. The dominant cost across payload sizes is the SHA-256 hash over the signing image, which scales linearly with payload size; the signature verification itself is constant-time relative to payload.
For ML-DSA-65, median verification time is 2.63 ms at 1 KiB and 5.33 ms at 1 MiB. The PQC variant is slightly faster at small payloads (FIPS 204 verification is well optimized in liboqs) and tracks Ed25519 closely as payload size grows, since the dominant cost shifts to hashing rather than signature verification. Across the full range of payload sizes tested, ML-DSA-65 verification stays within 6% of Ed25519, a result that is, candidly, more favorable than we expected before measurement, and one that supports treating ML-DSA-65 as a practical drop-in for Ed25519 vendor signatures on PLC-class hardware (Figure 6).
Figure 6. PLC verification latency vs. payload size, by signature algorithm. Lines show median of 50 measurements per cell; shaded bands extend to p95. Across all payload sizes from 1 KiB to 10 MiB, ML-DSA-65 verification stays within 6% of Ed25519, supporting use of the post-quantum variant as a practical drop-in.

9.3. Bundle Size

The bundle’s cryptographic overhead the size of everything in the bundle excluding the payload is essentially flat across payload sizes, since both signature schemes produce fixed-size outputs and the schema fields are fixed width.
For Ed25519, the cryptographic overhead is 408 bytes at small payloads and 412 bytes at payloads of 100 KiB or larger; the 4-byte spread is the CBOR varying-width integer encoding of the payload_size field (Figure 7). The breakdown at 412 bytes is: 64 bytes for the Ed25519 vendor signature, 64 for the FROST aggregate, plus the schema headers, target identifier, sequence number, nonce, and the signing-image domain separators. For ML-DSA-65 on the vendor side (with FROST-Ed25519 still on the quorum side), overhead rises to 3656–3660 bytes, an 8.9× increase driven entirely by the larger ML-DSA-65 signature size (3.3 KiB vs. Ed25519’s 64 bytes).
Figure 7. Bundle cryptographic overhead by signature algorithm and payload size (log–log). Overhead is essentially flat across payload sizes for both algorithms; ML-DSA-65 incurs a constant ≈ 8.9× increase over Ed25519, driven entirely by the larger ML-DSA-65 signature size (3.3 KiB vs. Ed25519’s 64 bytes).
In absolute terms 3660 bytes is negligible against any non-trivial firmware payload. In relative terms it matters only at the smallest payload sizes—at a 1 KiB payload the bundle is roughly four times the payload size, while at a 1 MiB payload the cryptographic overhead is under half a percent. For the firmware sizes typical of PLC and RTU updates (hundreds of KiB to several MiB), the PQC variant’s bundle-size overhead is in the noise.

9.4. Frost Signing Latency

The FROST quorum signing protocol drives the most variable cost in the system, because it scales with the number of participating operators. We measured signing latency at quorum sizes k = 2, 3, 5, 7, and 10, with 20 measurements per cell, against the live docker compose stack with operator services running on different containers (network round-trips included).
Figure 8 shows the result. At k = 3, the smallest meaningfully defended quorum, mean signing latency is 26.5 ms with p95 at 27.9 ms. At k = 5 and k = 7 it rises to mean values of approximately 59 ms and 98 ms respectively. At k = 10, mean latency is 192.05 ms with p95 at 212.23 ms. Latency scales roughly linearly with quorum size, which is the expected behavior for FROST’s two-round signing protocol; round 1 collects commitments from each participant, round 2 collects shares, and each round adds one network round-trip per participant under the implementation’s serial collection strategy.
Figure 8. FROST quorum signing latency vs. quorum size k. Mean line with shaded band extending to p95 over 20 measurements per quorum size. Latency scales near-linearly with k, consistent with the two-round protocol adding one network round-trip per participant under the implementation’s serial collection strategy. A meaningfully defended quorum (k = 3) signs in 26.5 ms; even a ten-operator quorum stays under 200 ms.
For context, prior work on threshold signatures in critical infrastructure has reported substantially higher signing latencies. Reijsbergen et al. [31], using the Gennaro–Goldfeder threshold ECDSA construction [32] in an AMI-firmware setting, report approximately 25 s of threshold signing latency at k = 16 members. The two orders of magnitude difference reflects the algorithmic gap between FROST-Ed25519’s two-round Schnorr-style protocol and Gennaro–Goldfeder’s multi-round MPC with Paillier-based proofs. Modern threshold-ECDSA constructions [33,34] narrow this gap considerably; we discuss the trade-off in Section 3.2.
The practical implication is that operator-quorum signing is fast enough to run interactively; a quorum of three operators can sign in 27 ms, which is well within typical operator-action timing budgets for a SCADA console. Quorums of seven or ten remain under 200 ms, which is acceptable even for unattended scheduled-update workflows.

9.5. End-to-End Update Latency

End-to-end latency is the wall-clock time from the workstation issuing the OpenSession message in Section 5.4 through to the PLC returning the result. This includes the challenge round-trip, the vendor signing call, the FROST quorum signing protocol, the bundle push, the PLC verification pipeline, and the transparency log append.
Measured across 50 runs at 1 KiB payload with k = 3 quorum, mean end-to-end latency is 30.15 ms for the Ed25519 variant and 29.25 ms for the ML-DSA-65 variant (Figure 9). At 1 MiB payload, both variants come in around 34.3–34.4 ms. The difference between the two algorithms is within measurement noise across all payload sizes tested. The dominant contributor across both variants is the FROST signing round-trips (roughly 27 ms at k = 3), with bundle marshaling, network transit, verification, and log append each contributing single-digit milliseconds.
Figure 9. End-to-end update latency at two payload sizes, by signature algorithm, t = 3 quorum. Bars show mean of 50 runs; whiskers extend to p95. End-to-end cost is dominated by the FROST signing round-trips (≈27 ms at k = 3); the choice of vendor signature algorithm contributes negligibly across both payload sizes tested.
A representative cold-start end-to-end run against a freshly deployed containerized realization completed in 109.32 ms, with the higher latency reflecting first-time service-to-service connection establishment rather than steady-state behavior.
A natural question is how this overhead compares to deployed vendor workflows. We do not have those baseline numbers: vendor flows are proprietary and exercise device-side code paths we cannot measure. The framework’s overhead sits well within the budgets typical of operator-interactive update windows in a SCADA console (single-digit seconds) and of scheduled-update batches (minutes per device). A controlled side-by-side comparison on representative hardware is included in our future-work plan (Section 10.4).

9.6. Scalability

We measured the framework’s ability to handle a fleet of PLCs receiving updates concurrently. The test deploys N PLC services and pushes a steady stream of updates from a single vendor through a coordinator and the operator quorum. Throughput is the rate of accepted updates, and failure rate is the fraction of pushes that did not successfully complete.
At N = 10 PLCs, throughput is approximately 30 updates per second with no failures. At N = 100 PLCs, throughput stays at approximately 30.1 updates per second sustained, again with zero failures across 100 PLCs (Figure 10). The throughput plateau reflects the FROST coordinator’s serial signing strategy—each update consumes one quorum signing session, and with a single coordinator the rate is bounded by signing latency rather than by PLC verification throughput. A production deployment with multiple parallel coordinators would scale linearly until network or operator-service capacity becomes the bottleneck.
Figure 10. Sustained update throughput vs. fleet size N, with a single coordinator. The dashed horizontal line marks the sustained throughput ceiling of approximately 30.1 updates/second observed at the largest fleet size tested. Throughput plateaus near this level across N ∈ {1, 10, 50, 100} with zero failures recorded.
The scalability test is not a stress test of either FROST or the transparency log under adversarial concurrent access—that is a separate question we leave for future work. What it does demonstrate is that the protocol’s overhead is small enough that a fleet of 100 PLCs can be sustained from one administrative origin without throughput degradation.

9.7. Regulatory Mapping

CertiFlash’s design was shaped in part by the requirements of IEC 62443 and the EU NIS2 Directive. Table 4 maps the protocol’s specific controls to the relevant clauses, distinguishing the requirements the protocol provides directly through a technical control from the requirements it supports by furnishing the cryptographic evidence a broader compliance regime needs. The mapping is engineering guidance, not a claim that deploying CertiFlash by itself satisfies any regulatory obligation; full compliance requires the surrounding governance, key-management, incident-response, and audit-practice elements discussed in Section 10.1 and Section 10.3.
Table 4. Mapping of CertiFlash protocol controls to IEC 62443 and NIS2 clauses, distinguishing requirements the protocol provides directly from those it supports.
The mapping is intended as practical guidance for operators evaluating CertiFlash against their compliance obligations, not as a normative claim that deploying the protocol satisfies any specific regulatory requirement on its own. Compliance is a deployment and process question that includes governance, key management, incident response, and audit practice in addition to protocol-level controls.

10. Discussion

This section steps back from the protocol and the measurements to discuss four operational questions the framework has to answer to be useful in practice: how a deployment actually unfolds at a real site (Section 10.1), what the two-pronged validation strategy of Section 7 and Section 9 buys that either alone would not (Section 10.2), where the present design’s limits sit honestly stated (Section 10.3), and where the work goes from here (Section 10.4).

10.1. Deployment Considerations

Consider a regional distribution operator running a medium-voltage substation: three protection relays, two RTUs, a feeder-management PLC, and a five-engineer team across two shifts. Today, one engineer pushes routine firmware updates from a vendor laptop, with the change recorded on a paper form countersigned by a senior on shift.
With CertiFlash, the engineer opens an update session; the PLC issues a fresh challenge nonce, and the vendor signs the firmware against it. Three of the five operators independently approve through their signing services after verifying the bundle parameters against the change ticket. FROST aggregates the shares, the workstation pushes the bundle, the PLC verifies and writes the decision to the transparency log, and a NOC-side auditor confirms the entry. The engineer sees a single “install successful” result with a log-entry reference. End-to-end latency is under 100 ms (Section 9.5), dominated by the operator-quorum step at roughly 27 ms for three signers (Section 9.4).
The operator-quorum approval differs structurally from countersigning a paper form. Each operator’s signing service displays the bundle’s key parameters (target PLC, firmware version, change-ticket reference); the operator confirms a match with the approved work, and the service produces its share. The interaction takes seconds but is a deliberate cognitive act, not a procedural formality. The reject path carries the same low friction as approval, surfacing disagreement promptly to the session initiator; designing operator-side UI for rejection is flagged as field-deployment work (Section 10.4).
The transparency log carries an operational cost. Large utilities can extend existing security monitoring to cover the auditor function; smaller operators may lack that capability. CertiFlash separates the log from the auditor, so the two roles can be filled by different parties: a shared sector-hosted log, or a vendor-operated log audited by a contracted third party. The auditability guarantee is conditional on at least one honest auditor making queries (Section 4.3); shared infrastructure is the right pattern for low-monitoring-maturity environments.
The workstation-trust shift (Section 5.4) also changes laptop lifecycle. Under CertiFlash, the engineering workstation holds no signing keys; it can be patched, replaced, and subject to the same endpoint controls as other corporate assets without the change-control caution that surrounds today’s engineering-workstation refresh. Losing the laptop costs the engineer their working environment, not the operator their ability to authorize.
A fourth, harder consideration concerns emergency-response updates and the super-quorum requirement (Section 5.5 step 8). Industrial control systems are not always updated on schedule: vulnerabilities under active exploitation, misbehaving control loops, and short-notice regulatory mandates each force firmware changes during off-hours with whatever subset of operators is reachable. Super-quorum raises the authorization bar exactly when reaching enough operators is hardest, and the operational cost is response time.
There is a real trade-off here, and the protocol does not silently take a side. A site that sets super-quorum to a majority of all enrolled operators (say five of five in our running example) will, by construction, struggle to authorize an emergency change at 03:00 on a public-holiday weekend; a site that sets super-quorum equal to the normal-quorum threshold may as well not have a super-quorum at all. A reasonable middle ground is super-quorum slightly above the normal threshold (e.g., four-of-five against a three-of-five normal quorum) combined with an out-of-band escalation path, typically an emergency operations on-call rota whose members are paid to be reachable. The protocol’s per-bundle-type configurability supports that judgment; the threshold value is a site-policy decision, not a protocol decision. The framework’s guarantee is not that an authorisation was wise but that it is on the public record when an organization later asks who approved a change and under what authority, the answer is recorded in a form that any party can independently verify. Key rotation is supported as a special bundle class. The vendor’s public key and the FROST aggregate public key sit in the PLC’s trust roots; either is rotated by a *trust-root rotation* bundle signed by the outgoing key(s) and authorized by the operator super-quorum (Section 5.5 step 8). Operator FROST shares can also be refreshed proactively without changing the aggregate public key, in which case the PLC’s trust roots are untouched and no on-device update is required. Either path produces a transparency-log entry, so the rotation event is publicly observable.

10.2. Two-Pronged Validation Strategy

Two findings show what each prong catches that the other would miss. The symbolic model exposed an early version of the Quorum_Sign rule in which the aggregate term was effectively a free variable, allowing signature substitution; Tamarin caught this before any concrete attack would have surfaced it. Conversely, the crash-recovery scenario (scenario 8 in Section 9) exercises behavior the symbolic model abstracts: Tamarin does not natively model atomicity of disk writes, and our model treats counter-bumping as a single rewrite step. The two methods give stronger evidence together than either alone.

10.3. Limitations and Scope

Several limitations of the present work are worth stating plainly.
Trusted-dealer setup for FROST. The reference implementation uses a single-party dealer at commissioning to compute and distribute operator shares of the FROST group secret. This is the simplest setup mode and matches what RFC 9591 calls trusted-dealer keygen. The dealer trusts the shares it produces but the shares are then distributed to operators over authenticated channels and the dealer’s role is complete. A distributed-key-generation (DKG) setup, where no single party ever holds the full secret, is supported by FROST and is appropriate for higher assurance deployments. We have not evaluated the DKG-setup variant in this work.
Threshold-ECDSA peers not benchmarked head-to-head. Section 3.2 discusses the algorithmic gap between FROST-Ed25519 and threshold-ECDSA constructions; we did not run head-to-head benchmarks against modern threshold-ECDSA (Doerner et al. [33], Canetti et al. [34]) in the same environment. The performance numbers in Section 9.4 are absolute, not comparative.
Quantum-secure operator quorum. CertiFlash’s PQC variant replaces the vendor-side Ed25519 with ML-DSA-65 but keeps the operator-quorum signature as FROST-Ed25519. A fully quantum-secure design would require a practical PQC threshold scheme; the current state of the art does not yet offer a drop-in replacement with FROST’s properties (verifier sees a standard signature, two-round signing). This is an open research problem we discuss in Section 10.4.
No machine learning in the loop. The protocol does not analyze the firmware content; it only verifies who authorized the install. ML-based anomaly detection on update behavior is complementary and out of scope here.
Process-data integrity is a separate problem. CertiFlash protects the install pathway; the runtime data the PLC exchanges with the SCADA server during normal operation is a separate question with its own literature (e.g., DNP3-SAv5 work [25] and Reijsbergen et al.’s AMI work [31]). The two problems compose well but are not unified here.
In-PLC hardware measurements. The measurements of Section 9 are workstation-class. The off-device costs (vendor signing, FROST signing) do not depend on PLC hardware; the on-device cost reduces to one Ed25519 verify plus one SHA-256 over the payload, both well characterized in public micro-benchmarks for ARM Cortex-A-class industrial gateways and Cortex-M-class controllers. What we have not measured ourselves are the verifier’s in-PLC CPU, RAM, and flash footprint; control-cycle jitter under concurrent update load; and interaction with the device’s Modbus/S7 stack on the same physical CPU. A direct port and in-PLC measurement is the empirical centerpiece of the field-deployment study (Section 10.4).
No controlled comparison against deployed vendor workflows. As noted in Section 9.5, the absence of a same-environment comparison between CertiFlash’s end-to-end latency and the corresponding overhead in deployed Siemens/Rockwell/Schneider firmware-update flows is a real gap in the evaluation. Closing it requires either cooperation with a vendor or a controlled reverse-engineering effort that we have not undertaken. It belongs in the future-work plan rather than this work’s evaluation, but should be named here to set reader expectations honestly.

10.4. Future Work

One technical loose end remains in the Tamarin model: the functional_sanity existential lemma (Section 7.3). Closing it requires either a tactic-based proof script or a more aggressive custom oracle; as the lemma is a model self-check rather than a security claim, the work is low priority for the framework’s correctness but is a clean follow-up exercise for the formal-methods component of the project.
On the protocol side, there are three directions:
First, vendor–protocol integration. The reference implementation runs Modbus TCP and Siemens S7 stubs alongside the update channel to show coexistence. Production deployment requires implementing the verification pipeline inside vendor firmware against vendor-specific update transports; this is engineering work that depends on vendor cooperation but is straightforward in protocol terms; the verification pipeline of Section 5.5 is the same regardless of transport.
Second, post-quantum threshold signatures. The asymmetry between Ed25519 (FROST available) and ML-DSA-65 (no practical threshold variant yet) is the most significant gap in CertiFlash’s PQC story. Recent work on threshold lattice signatures [37] is encouraging but not yet at the maturity where it could replace FROST-Ed25519 in CertiFlash. We expect this to be a live area for several years.
Third, a controlled field-deployment study. Among the practical questions that none of this paper’s measurements can answer is the one that most prospective users will ask: how does CertiFlash behave inside a real OT environment over a sustained period across operator turnover, vendor toolchain updates, network reconfigurations, and the routine wear-and-tear of an industrial site? Designing such a study, finding willing site operators, and reporting the results including negative outcomes is the natural next step beyond this paper. A side-by-side comparison against the incumbent vendor workflow on the same hardware, addressing the gap noted in Section 9.5 and Section 10.3, is the natural empirical centerpiece of that study.
Finally, governance and key-management practice. CertiFlash specifies a protocol; it does not specify operator-share rotation schedules, vendor-key ceremony procedures, or transparency-log governance arrangements. These are the harder operational questions whose answers will determine whether the framework gets used in practice. Finally, standardization. If field deployment proves CertiFlash useful, the natural next step is submission to standardization bodies. The IETF SUIT working group is the closest community on the IoT-update side, and CertiFlash’s bundle and verifier are structurally compatible with SUIT’s manifest framing (Section 3.1). IEC TC 65 and ETSI TC CYBER are the natural homes on the OT and cybersecurity sides; the existing alignment with IEC 62443 SR/CR 3.4 and NIS2 Article 21(2) (Section 9.7) is the entry point.

11. Conclusions

CertiFlash is a cryptographic framework for firmware and ladder-logic updates on SCADA and industrial IoT systems. It binds every install to four independent approvals vendor signature, operator-quorum signature via FROST-Ed25519, PLC challenge nonce, and a strictly monotonic counter and publishes every accept-or-reject decision to an append-only Merkle transparency log that any third party can audit. The threshold signature aggregates to a standard RFC 8032 Ed25519 signature, which means the PLC verification path requires no FROST-specific code and existing firmware that already includes an Ed25519 verifier can be retrofitted without changes to its cryptographic stack.
We defined four security properties for the protocol, machine-checked all four in Tamarin under a Dolev–Yao adversary with up to t − 1 compromised operators and corroborated the same claims through a catalog of ten attacks against the live reference implementation. The implementation is containerised and re-runs end-to-end from a fresh state, demonstrating that the protocol’s overhead is modest: 30 ms end-to-end at a three-of-five quorum, FROST signing under 200 ms even at quorums of ten, and the ML-DSA-65 vendor-signature variant verifies within 6% of Ed25519 across payload sizes from 1 KiB to 10 MiB. The operator-quorum signature remains FROST-Ed25519: post-quantum coverage in the evaluated design is partial, pending a practical threshold PQC scheme (Section 10.3 and Section 10.4). The framework maps directly to IEC 62443-3-3 SR 3.4 [7] and to NIS2 Article 21(2)(d) and (e) requirements [8].
The contribution is composition rather than invention. None of the cryptographic primitives is new; each is a well-understood, standardized building block backed by mature libraries. What is new is the specific assembly a true threshold signature wired to per-install device challenges, and the transparency log running in the binary-update tradition, all of it formally grounded under a threat model that takes operator compromise seriously alongside Dolev–Yao network control. The security of industrial control systems is more likely to improve through careful composition of trusted parts than through bespoke cryptography. CertiFlash is one instance of that approach.
Beyond the specific protocol, CertiFlash addresses a broader shift in how industrial infrastructure establishes trust. Today’s industrial trust architectures are built on procedural accountability: change tickets, signed forms, local audit trails, the assumption that the people doing the work are who they say they are and did what they said they did. Those assumptions were defensible in a less-connected era and they are not defensible now. The transition we have in mind, which CertiFlash is one early instance of, is toward cryptographically accountable industrial infrastructure: industrial systems where the consequential acts installing firmware, rotating credentials, modifying safety logic, and opening a breaker are bound at the moment they happen to externally verifiable evidence of who authorized them, against which key, in what sequence, and recorded where any sufficiently motivated third party can later check. This is the same architectural shift the web’s PKI went through with Certificate Transparency in the previous decade, and the case for it is, if anything, stronger in industrial settings, where the consequences of unaccountable action reach into physical equipment that millions of people depend on.
There is a great deal of operational, governance, and regulatory work between the protocol presented here and that broader transition, and we have been candid about how much of it the present framework does not solve. The protocol is one piece of the picture, the piece that ensures, once the rest of the picture has been built, that each installation event is bound to evidence that survives the device, the operator, and the operator’s local audit logs.

Author Contributions

Conceptualization, P.P. and G.E.; methodology, P.P.; software, P.P.; validation, P.P.; formal analysis, P.P.; investigation, P.P.; writing—original draft preparation, P.P.; writing—review and editing, P.P. and G.E.; visualization, P.P.; supervision, G.E.; project administration, G.E. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Institutional Review Board Statement

Not applicable.

Data Availability Statement

The original contributions presented in this study are included in the article. Further inquiries can be directed to the corresponding author.

Acknowledgments

During the preparation of this work, the authors used ChatGPT (OpenAI) in order to assist with the literature formatting and improve language clarity. After using these tools, the authors reviewed and edited the content as needed and take full responsibility for the content of the publication.

Conflicts of Interest

The authors declare no conflicts of interest. The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

References

  1. Falliere, N.; Murchu, L.O.; Chien, E. W32.Stuxnet Dossier (Version 1.4); Symantec Security Response; Symantec Corporation: Mountain View, CA, USA, 2011. [Google Scholar]
  2. Langner, R. Stuxnet: Dissecting a cyberwarfare weapon. IEEE Secur. Priv. 2011, 9, 49–51. [Google Scholar] [CrossRef] [Scilit]
  3. Lee, R.M.; Assante, M.J.; Conway, T. Analysis of the Cyber Attack on the Ukrainian Power Grid. SANS Industrial Control Systems and E-ISAC, Defense Use Case. 18 March 2016. Available online: https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2016/05/20081514/E-ISAC_SANS_Ukraine_DUC_5.pdf (accessed on 8 February 2026).
  4. Dragos Inc. TRISIS: Analyzing Safety System Targeting Malware. Technical Report. 14 December 2017. Available online: https://www.dragos.com/resources/whitepaper/trisis-analyzing-safety-system-targeting-malware/ (accessed on 8 February 2026).
  5. Cybersecurity and Infrastructure Security Agency (CISA) and Federal Bureau of Investigation (FBI). DarkSide Ransomware: Best Practices for Preventing Business Disruption from Ransomware Attacks. Joint Cybersecurity Advisory AA21-131A. 11 May 2021. Available online: https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-131a (accessed on 8 February 2026).
  6. Wu, Y.; Wang, J.; Wang, Y.; Zhai, S.; Li, Z.; He, Y.; Sun, K.; Li, Q.; Zhang, N. Your Firmware Has Arrived: A Study of Firmware Update Vulnerabilities. In Proceedings of the 33rd USENIX Security Symposium (USENIX Security 24), Philadelphia, PA, USA, 14–16 August 2024; USENIX Association: Berkeley, CA, USA, 2024; pp. 5627–5644. [Google Scholar]
  7. IEC 62443-3-3:2013; Industrial Communication Networks—Network and System Security—Part 3-3: System Security Requirements and Security Levels. IEC: Geneva, Switzerland, 2013.
  8. European Parliament and Council. Directive (EU) 2022/2555 on Measures for a High Common Level of Cybersecurity Across the Union (NIS2 Directive). Off. J. Eur. Union 2022, L 333, 80–152. Available online: https://eur-lex.europa.eu/eli/dir/2022/2555/oj (accessed on 23 April 2026).
  9. Komlo, C.; Goldberg, I. FROST: Flexible round-optimized Schnorr threshold signatures. In Selected Areas in Cryptography SAC 2020; Ser. LNCS; Springer: Cham, Switzerland, 2021; Volume 12804, pp. 34–65. [Google Scholar] [CrossRef] [Scilit]
  10. Connolly, D.; Komlo, C.; Goldberg, I.; Wood, C.A. The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures; RFC 9591, IRTF (CFRG); IETF: Wilmington, DE, USA, 2024. [Google Scholar] [CrossRef] [Scilit]
  11. Josefsson, S.; Liusvaara, I. Edwards-Curve Digital Signature Algorithm (EdDSA); RFC 8032, IRTF (CFRG); IETF: Wilmington, DE, USA, 2017. [Google Scholar] [CrossRef] [Scilit]
  12. Bormann, C.; Hoffman, P. Concise Binary Object Representation (CBOR); RFC 8949; IETF: Wilmington, DE, USA, 2020. [Google Scholar] [CrossRef] [Scilit]
  13. National Institute of Standards and Technology. FIPS 204: Module-Lattice-Based Digital Signature Standard; NIST: Gaithersburg, MD, USA, 2024. [Google Scholar] [CrossRef] [Scilit]
  14. IEC 62443-4-2:2019; Security for Industrial Automation and Control Systems—Part 4-2: Technical Security Requirements for IACS Components. IEC: Geneva, Switzerland, 2019.
  15. Cybersecurity and Infrastructure Security Agency. Hitachi Energy RTU500 Series Product (ICSA-25-023-02), CISA Industrial Control Systems Advisory. 23 January 2025. Available online: https://www.cisa.gov/news-events/ics-advisories/icsa-25-023-02 (accessed on 18 May 2026).
  16. IEC 61131-3:2013; Programmable Controllers—Part 3: Programming Languages. IEC: Geneva, Switzerland, 2013.
  17. Moran, B.; Tschofenig, H.; Brown, D.; Meriac, M. A Firmware Update Architecture for Internet of Things; RFC 9019; IETF: Wilmington, DE, USA, 2021. [Google Scholar] [CrossRef] [Scilit]
  18. Samuel, J.; Mathewson, N.; Cappos, J.; Dingledine, R. Survivable key compromise in software update systems. In Proceedings of the 17th ACM CCS, Chicago, IL, USA, 4–8 October 2010; pp. 61–72. [Google Scholar] [CrossRef] [Scilit]
  19. Kuppusamy, T.K.; Brown, A.; Awwad, S.; McCoy, D.; Bielawski, R.; Mott, C.; Lauzon, S.; Weimerskirch, A.; Cappos, J. Uptane: Securing software updates for automobiles. In Proceedings of the 14th Embedded Security in Cars (Escar Europe), Munich, Germany, 16–17 November 2016; Available online: https://ssl.engineering.nyu.edu/papers/kuppusamy_escar_16.pdf (accessed on 5 February 2026).
  20. National Institute of Standards and Technology. NIST SP 800-82 Revision 3: Guide to Operational Technology (OT) Security; NIST: Gaithersburg, MD, USA, 2023. [CrossRef] [Scilit]
  21. Laurie, B.; Langley, A.; Kasper, E. Certificate Transparency; RFC 6962; IETF: Wilmington, DE, USA, 2013. [Google Scholar] [CrossRef] [Scilit]
  22. Newman, Z.; Meyers, J.S.; Torres-Arias, S. Sigstore: Software Signing for Everybody. In Proceedings of the 29th ACM Conference on Computer and Communications Security (CCS ‘22), Los Angeles, CA, USA, 7–11 November 2022; pp. 2353–2367. [Google Scholar] [CrossRef] [Scilit]
  23. Valsorda, F. The Sunlight CT Log, Design and Reference Implementation. sunlight.dev. March 2024. Available online: https://sunlight.dev/ (accessed on 5 February 2026).
  24. Meier, S.; Schmidt, B.; Cremers, C.; Basin, D. The TAMARIN prover for the symbolic analysis of security protocols. In Proceedings of the 25th International Conference on Computer Aided Verification (CAV); Series LNCS; Springer: Berlin/Heidelberg, Germany, 2013; Volume 8044, pp. 696–701. [Google Scholar] [CrossRef] [Scilit]
  25. Cremers, C.; Dehnel-Wild, M.; Milner, K. Secure authentication in the grid: A formal analysis of DNP3 SAv5. In Proceedings of the 22nd European Symposium on Research in Computer Security (ESORICS); Series LNCS; Springer: Berlin/Heidelberg, Germany, 2017; Volume 10492, pp. 389–407. [Google Scholar] [CrossRef] [Scilit]
  26. Ponsard, C.; Darquennes, D. Towards Formal Security Verification of Over-the-Air Update Protocol: Requirements, Survey and UpKit Case Study. In Proceedings of the 7th International Conference on Information Systems Security and Privacy (ICISSP 2021), Online, 11–13 February 2021; pp. 800–808. [Google Scholar] [CrossRef] [Scilit]
  27. Lorch, R.; Larraz, D.; Tinelli, C.; Chowdhury, O. A Comprehensive, Automated Security Analysis of the Uptane Automotive Over-the-Air Update Framework. In Proceedings of the 27th International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2024), Padua, Italy, 30 September–2 October 2024. [Google Scholar] [CrossRef] [Scilit]
  28. Tacchella, A.; Beozzo, E.; Crispo, B.; Roveri, M. Firmware Secure Updates Meet Formal Verification. ACM Trans. Cyber-Phys. Syst. 2026, 10, 1–26. [Google Scholar] [CrossRef] [Scilit]
  29. Heinl, M.P.; Embacher, V. BT2X: Multi-Leveled Binary Transparency to Protect the Software Supply Chain of Operational Technology. In Proceedings of the 6th Workshop on CPS&IoT Security and Privacy (CPSIoTSec ‘24, Co-Located with ACM CCS 2024), Salt Lake City, UT, USA, 18 October 2024. [Google Scholar] [CrossRef] [Scilit]
  30. Nikitin, K.; Kokoris-Kogias, E.; Jovanovic, P.; Gailly, N.; Gasser, L.; Khoffi, I.; Cappos, J.; Ford, B. CHAINIAC: Proactive software-update transparency via collectively signed skipchains and verified builds. In Proceedings of the 26th USENIX Security Symposium; USENIX: Berkeley, CA, USA, 2017; pp. 1271–1287. Available online: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/nikitin (accessed on 10 February 2026).
  31. Reijsbergen, D.; Maw, A.; Venugopalan, S.; Yang, D.; Dinh, T.T.A.; Zhou, J. Protecting the Integrity of IoT Sensor Data and Firmware with a Feather-Light Blockchain Infrastructure. In Proceedings of the 2022 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), Shanghai, China, 2–5 May 2022. [Google Scholar]
  32. Gennaro, R.; Goldfeder, S. Fast multiparty threshold ECDSA with fast trustless setup. In Proceedings of the 25th ACM CCS, Toronto, ON, Canada, 15–19 October 2018; pp. 1179–1194. [Google Scholar] [CrossRef] [Scilit]
  33. Doerner, J.; Kondi, Y.; Lee, E.; Shelat, A. Threshold ECDSA from ECDSA assumptions: The multiparty case. In Proceedings of the IEEE Symposium on Security and Privacy (S&P), San Francisco, CA, USA, 19–23 May 2019; pp. 1051–1066. [Google Scholar] [CrossRef] [Scilit]
  34. Canetti, R.; Gennaro, R.; Goldfeder, S.; Makriyannis, N.; Peled, U. UC non-interactive, proactive, threshold ECDSA with identifiable aborts. In Proceedings of the 27th ACM CCS, Virtual, 9–13 November 2020; pp. 1769–1787. [Google Scholar] [CrossRef] [Scilit]
  35. Hagen, M.S.; Lundqvist, E.; Phu, A.; Wang, Y.; Strandberg, K.; Schiller, E.M. Towards a Formal Verification of Secure Vehicle Software Updates. Comput. Secur. 2025, 161, 104751. [Google Scholar] [CrossRef] [Scilit]
  36. Schöffel, M.; Lauer, F.; Rheinländer, C.C.; Wehn, N. On the Energy Costs of Post-Quantum KEMs in TLS-based Low-Power Secure IoT. In Proceedings of the ACM IoTDI 2021, Charlottesvle, VA, USA, 18–21 May 2021; pp. 158–168. [Google Scholar] [CrossRef] [Scilit]
  37. del Pino, R.; Katsumata, S.; Maller, M.; Mouhartem, F.; Prest, T.; Saarinen, M.-J.O. Threshold Raccoon: Practical Threshold Signatures from Standard Lattice Assumptions. In Advances in Cryptology—EUROCRYPT 2024; Part V, LNCS; Joye, M., Leander, G., Eds.; Springer: Cham, Switzerland, 2024; Volume 14655, pp. 219–248. [Google Scholar] [CrossRef] [Scilit]
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Article Metrics

Citations

Article Access Statistics

Journal Statistics
Multiple requests from the same IP address are counted as one view.
A Comparative Study of Large Language Models for Industrial Cyber-Physical Security
Previous
Time Dependent Truck–Drone Green Vehicle Routing Problem with Pickup and Delivery in Large Cities
Next