Ohio University's Das, Agendia, Adjei and Oun Cut Post-Quantum Attestation Cost for OpenPLC Controllers 90-Fold With Checkpointed ML-DSA Signing, arXiv 2611.07476, 5 November 2026: TRL 4
Quentir Defense Monitor
Evidence-based insights for quantum defense and security. Published by Quentir Systems LLC · November 7, 2026.
Rishabh Das, Gerald Agendia, Jibriel Adjei and Ahmed Oun of Ohio University in Athens, Ohio, posted a protocol called AMORT-V1 to arXiv on 5 November 2026. It answers a cost problem in post-quantum attestation for industrial controllers: when every status report from a controller has to carry a lattice signature, the signing and the disk write behind it eat most of each round trip. AMORT-V1 moves the signature and the durable write off the individual report and onto a periodic checkpoint, then measures what that saves on a seven-node Raspberry Pi 5 testbed with five physical OpenPLC provers. The controller's cost per report falls 90 times without a durable log and 878 times with one, and verifying which device wrote a report costs 2.95 microseconds.
Programmable logic controllers run the physical side of a base, a shipyard, a water plant and a weapon system's support equipment, and operators keep them in service for decades. The paper opens with Stuxnet, which rewrote centrifuge logic and hid the change, and states the problem plainly: remote attestation rests on signatures over reported evidence, and a quantum adversary who can forge those signatures makes tampering invisible. This post reads AMORT-V1 as a defensive capability in the post-quantum cryptography pillar, sub-branch roots of trust in hardware, and sets out what separates a laboratory testbed from a fleet a program office could rely on.
What the arXiv paper of 5 November 2026 establishes: one ML-KEM-768 exchange per epoch, a 16-octet HMAC per report, and an ML-DSA-65 checkpoint over a Merkle tree
The starting measurement comes from the authors' earlier work on OpenPLC attestation, which the paper cites: hash-based signing took 88 to 99 percent of each attestation round trip, and a stateful hash-based signer, which must persist its one-time-key state before releasing each signature, was held to 217 synchronous operations per second by that write. A controller reporting at 1 hertz paid both costs every second even when its software had not changed.
AMORT-V1 restructures the work in five stages. An epoch opens when the controller encapsulates to the device's static ML-KEM-768 public key, which only the device can decapsulate, and signs an EpochOpen message with its long-term ML-DSA-65 key so that a rogue controller cannot open an epoch. Each report is then an 83-octet message carrying the device identifier, the epoch, a per-device sequence number, a timestamp, the measurement digest and a policy identifier, closed by a truncated HMAC-SHA-256 tag of 16 octets.
The controller adds each verified report to a Merkle tree built with the RFC 6962 hashing rules used by Certificate Transparency. At the checkpoint it signs the tree root, the hash of the previous checkpoint, the total leaf count and, for each device, its sequence range and a subtree root over that device's own reports. The subtree root exists because an earlier revision committed only the sequence range, and attack case A20 in the authors' 27-case attack matrix showed a controller could drop one report, insert another and keep the range continuous. The chain of checkpoint hashes also turns equivocation into evidence: two signed checkpoints for the same position prove the controller misbehaved.
One more mechanism carries the defense value. A shared message authentication key proves nothing about origin to a third party, because the controller holds the same key. AMORT-V1 adapts the TESLA idea of delayed key disclosure: the device draws a seed from its own entropy, derives a one-way hash chain, commits the chain anchor inside the signed EpochOpen, tags each report with the next chain key, and releases that key only after a signed checkpoint has committed the report. A cold auditor holding no secret can hash the disclosed key back to the anchor and recompute the tag.
The numbers from the seven-node Raspberry Pi 5 testbed: a 2.81 microsecond floor, 90 and 878 times cheaper, 2.95 microseconds to verify origin, and no missed 10 millisecond scan deadline in 210,000 cycles
The timing work runs in C on liboqs and OpenSSL, checked against a Python reference model with 149 differential test vectors. On the controller node at 2400 megahertz, a HMAC over an 83-octet report costs 2.15 microseconds and a Merkle hash 0.66 microseconds, a floor of 2.81 microseconds per report. Per checkpoint, an ML-DSA-65 signature costs 254.9 microseconds, a 4 kibibyte write with fsync 4.24 milliseconds, and an SLH-DSA-128f signature 31.52 milliseconds. The durable write costs more than sixteen ML-DSA-65 signatures, which is why amortizing the write matters more than amortizing the signature under ML-DSA.
Sweeping the checkpoint interval from 1 to 4,096 reports, the ML-DSA-65 cost per report falls from 306.2 to 3.40 microseconds without a durable log, a 90-fold reduction, and from 4,354 to 4.96 microseconds with one, 878-fold. The price is detection delay: an omission visible in checkpoint metadata stays hidden for at most one interval, and in 200 trials per interval the next checkpoint exposed an injected omission after a median of about half the interval and never beyond it. Detecting substitution that preserves the sequence range requires the underlying device reports to recompute the per-device subtree root; a checkpoint-only auditor cannot detect every omission. The disclosure chain lets an auditor verify origin in order at 2.95 microseconds per report. On the OpenPLC prover locked at 1500 megahertz, 210,000 scan cycles across seven configurations produced no deadline miss against the 10 millisecond control deadline, with a worst case of 317 microseconds, even with checkpoint signing running on the same core.
Quantum pillar: post-quantum cryptography (roots of trust in hardware). Use posture: defensive. Technology readiness: TRL 4 of 9. For the reader this means the protocol has been assembled end to end and measured on laboratory hardware with real controller software, while the fleet is five devices, the plant is a timing harness and the vendor controllers a force actually buys have not yet run it.
Why the panel reads post-quantum cryptography (roots of trust in hardware), defensive and TRL 4
The pillar is post-quantum cryptography because the quantum content of the paper is the threat, and the instruments are the algorithms NIST standardized to meet it: ML-KEM, ML-DSA under FIPS 204, published 13 August 2024, and SLH-DSA under FIPS 205. The sub-branch is roots of trust in hardware, which Quentir's capability map defines as firmware, hardware security modules and keys burned into long-life platforms. A controller's static ML-KEM-768 key, the measured software image it reports, and the TPM 2.0 monotonic counter that anchors its sequence state across a restart are that root.
The posture is defensive. The value lies entirely in protecting one's own controllers and in knowing, with evidence a third party can check, that their logic has not been altered. Nothing in the protocol degrades an adversary's systems. The readiness level is 4. The shared ladder places bench assembly and laboratory testing at level 4, and that is what seven Raspberry Pi 5 nodes, five physical OpenPLC provers, a C implementation and a control-cycle harness amount to. It sits above level 3 because the pieces were integrated and run together under timing constraints. It sits below level 5 because the 10,000 identities are synthetic, the control loop is a harness, and no production control network has carried the traffic.
What it would let a force do: keep a controller fleet under continuous software-state check through the CNSA 2.0 transition, with a TPM 2.0 counter against rollback
The policy pull is already in place. The joint factsheet from CISA, NSA and NIST of 21 August 2023 tells organizations that support critical infrastructure to inventory their cryptography and plan the migration, and the paper cites NSA's Commercial National Security Algorithm Suite 2.0 as the reason a signature scheme chosen for a controller today must already be post-quantum. Neither document supplies a way to keep thousands of programmable logic controllers reporting their software state under post-quantum signatures without the signing budget swallowing the control budget. AMORT-V1 is a measured answer to that gap.
For a force, the capability is continuous, cheap, publicly checkable authentication and commitment of reported evidence from the controllers that run its physical infrastructure. Under the stated threat-model assumptions, a verifier can check the freshness, origin and committed history of that evidence. An inspector, a coalition partner or an incident responder can later verify who wrote which report without being handed the fleet's secret keys. Revoking one compromised identity leaves every other identity attesting.
Rollback is where the hardware root enters. A restarted device that resumes from stale state can reuse a sequence number or a disclosed key. The authors anchor the device's sequence state to a monotonic counter in a discrete TPM 2.0, defined in the Trusted Computing Group's TPM 2.0 Library specification, revision 1.83 of March 2024. Across 150 rollback trials on the five physical provers, the TPM-backed scheme detected every stale state and reused no sequence number, while an unanchored scheme reissued 19,200. A buyer should notice what the TPM is doing here. It is a counter, kept off the per-report path, and that role needs no post-quantum algorithms inside the TPM itself, which separates this design from the question of whether a TPM counts as post-quantum ready under TCG's PTP 1.07 profile. The post-quantum work sits in the controller's checkpoint signature and the device's ML-KEM key, the same systems question Quentir raised when cloud key management services began offering post-quantum signing: the algorithm is the easy part, and the roots of trust and the signing path around it decide whether a fleet is protected.
What stands between the testbed and a program office relying on it: full-image measurement at 392 milliseconds to 8.35 seconds, the threat model's edge and the port to vendor controllers
Five items separate this preprint from a requirement. The first is the one the authors measure themselves. The checkpoint results use a 4 kibibyte cached representation of software state. Measuring the full OpenPLC v3 installation, 6,239 files and 355 megabytes, takes 392 milliseconds with a warm cache, the equivalent of 1,511 ML-DSA-65 signatures, and 8.352 seconds from a cold cache, 32,752 signatures. Checkpointed attestation amortizes authentication and persistence; it does nothing for measurement, and the authors say the savings hold only when a deployment avoids a full image read per report through caching, incremental measurement or hardware support.
The second is the threat model's edge. It excludes physical key extraction, compromise of the trusted measurement agent, runtime-memory attacks after measurement and denial of service. The protocol authenticates the freshness, origin and committed history of a software-state claim; it does not establish that the agent making the claim is intact, or that the reported state is correct. The third is the hardware: a Raspberry Pi 5 running OpenPLC v3 is a research platform, and vendor controllers carry firmware, toolchains and certification regimes a protocol has to enter before it protects anything. The fourth is the checkpoint policy: the authors say that no single interval is right for every deployment, so an operator has to choose a detection window and defend it, with 550 kilobyte checkpoints at 10,000 identities crossing operational technology links the paper notes can run below 10 megabits per second. The fifth is independent evaluation. The paper is a cs.CR preprint under a CC BY 4.0 license, with no peer review yet and no run on a production control network, which the authors list as future work.
What the sources support is this. Four Ohio University researchers have published a complete, tested design that takes ML-DSA checkpoint signing and ML-KEM epochs into industrial attestation at a per-report cost of a few microseconds, with origin evidence a third party can verify and TPM-anchored rollback resistance, on five physical OpenPLC provers. The policy demand for exactly this exists in the CISA, NSA and NIST factsheet and in CNSA 2.0. A port to vendor controllers, an incremental-measurement companion, and a run on a real control network are the next three pieces of evidence to wait for.
Sources
Primary source: Rishabh Das, Gerald Agendia and Jibriel Adjei (J. Warren McClure School of Emerging Communication Technologies, Scripps College of Communication) and Ahmed Oun (School of Electrical Engineering and Computer Science, Russ College of Engineering and Technology), Ohio University, Athens, Ohio, "AMORT-V1: Checkpointed Post-Quantum Attestation for Industrial Controllers," arXiv 2611.07476, submitted 5 November 2026, including Sections III through VI, Tables I through V and Appendix A, read in full this run. Other material: the NIST CSRC page for FIPS 204, Module-Lattice-Based Digital Signature Standard, published 13 August 2024; the CISA, NSA and NIST factsheet Quantum-Readiness: Migration to Post-Quantum Cryptography, 21 August 2023; the Trusted Computing Group's TPM 2.0 Library specification page, revision 1.83, March 2024. The capability reading, the posture argument, the readiness placement and the buyer items are Quentir analysis.