]> Independent Researcher

Brazil augusto.cleiton@gmail.com https://github.com/cleitonaugusto/CleitonQ

Security Individual Submission post-quantum cryptography command provenance non-repudiation autonomous systems audit tamper-evident logging ML-DSA ML-KEM UAS security AI agents Autonomous machines such as uncrewed aircraft, ground robots, and spacecraft execute commands issued by human operators and, increasingly, by AI agents. When an incident occurs, no independent evidence exists of which commands the machine received: conventional logs are mutable by the operating party, symmetric message authentication codes cannot demonstrate origin to a third party, and records signed with elliptic-curve cryptography lose their evidentiary value once cryptographically relevant quantum computers exist. This document defines the Anchor: a post-quantum digital signature over a compact commitment to a window of authenticated machine traffic. An anchor chain constitutes a tamper-evident, non-repudiable record of what a machine was commanded to do and what it reported back, verifiable by any third party without trusting the operator, without network access at recording time, and with security that survives the quantum transition. The construction is protocol-agnostic and is designed for bandwidth-constrained links where per-message post-quantum signatures are impractical.

Introduction Command-and-control (C2) links for autonomous machines increasingly require two distinct security services that current deployments conflate or omit:

1. Real-time authentication: the machine must verify, at line rate, that each received command originates from an authorized party. Symmetric constructions (HMAC) satisfy this within tight bandwidth and latency budgets.
2. Durable provenance: after the fact, parties other than the operator -- insurers, accident investigators, regulators, courts -- must be able to verify which commands the machine received and which telemetry it emitted. Symmetric constructions cannot provide this service: either session party could have generated any message, so proof to a third party is impossible.

Per-message digital signatures would provide both services but are impractical on constrained links when post-quantum signature sizes are considered: an ML-DSA-87 signature is 4627 bytes, which at a 100 Hz telemetry rate implies 3.7 Mbit/s of signature traffic alone -- exceeding the total budget of most deployed C2 radio links by two orders of magnitude. This document specifies a construction, the Anchor, that decouples the two services: symmetric per-message authentication at line rate, plus one post-quantum signature per window of traffic that converts the accumulated symmetric authenticators into third-party-verifiable evidence. Per-message overhead remains constant regardless of window size. The underlying problem of deploying authentication extensions across relay-mediated protocol stacks (MAVLink v2, ROS2/DDS, CAN/AUTOSAR) is documented in . This document addresses the complementary question: once messages are authenticated, how is durable, quantum-resistant evidence of the traffic produced within the same link budget?

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Window:

A contiguous sequence of authenticated messages delimited by a maximum message count W and a maximum duration T, whichever bound is reached first.

Commitment:

A cryptographic hash over the ordered concatenation of the MAC tags of all messages in a window.

Anchor:

A record comprising window metadata, the window commitment, and a post-quantum digital signature over both.

Anchor chain:

The ordered sequence of anchors emitted over a session or mission, linked by monotonic anchor sequence numbers.

Auditor:

Any party, possibly adversarial to the operator, that verifies an anchor chain after the fact.

The Accountability Gap

Mutable Logs Flight logs and command histories are files under the operator's control. In a liability dispute, the party producing the log is the party with both the motive and the means to alter it. A log format without cryptographic binding to the traffic it claims to record has no evidentiary weight beyond the operator's testimony. Regulatory frameworks increasingly require more: high-risk AI systems, including AI safety components of regulated machinery, are required to automatically record events over their lifetime in a manner that enables post-hoc reconstruction of individual decisions .

Authentication Without Non-Repudiation Symmetric MACs -- including quantum-resistant constructions such as HMAC with SHA-3 -- prove authenticity only to the holder of the session key. Because both session parties hold the same key, a MAC-authenticated archive proves nothing to an auditor: the operator could have fabricated the entire archive after the fact.

Quantum-Expiring Evidence Records signed with ECDSA or EdDSA -- including records anchored to distributed ledgers, which inherit the elliptic-curve signatures of their underlying platforms -- become forgeable when a cryptographically relevant quantum computer exists. Machines entering service today operate for one to three decades; their evidence trails must remain verifiable for at least as long, including for incidents litigated years after recording. Evidence whose integrity guarantee expires before the statute of limitations is structurally inadequate. National guidance already mandates the transition away from quantum-vulnerable algorithms for security systems .

AI Agents as Command Issuers When commands originate from AI agents rather than human operators, the provenance question acquires a second dimension: not only whether the machine received a given command, but which identity -- human or agent -- issued and authorized it. Existing agent-authorization mechanisms bind tokens to software API calls; they do not extend to the physical machine boundary and do not employ post-quantum cryptography. An anchor chain over the machine link records the authenticated command stream at exactly that boundary, regardless of whether the issuer was human or machine.

The Anchor Construction The construction assumes an established authenticated channel in which each message i carries a MAC tag mac_i computed with a session key (for example, established via ML-KEM-1024 and authenticated with HMAC-SHA3-256). Window closure is governed by two parameters: W, the maximum number of messages per window, and T, the maximum window duration. An anchor MUST be emitted when either bound is reached. The anchor sequence number MUST be strictly monotonic; a verifier MUST reject an anchor whose sequence number does not exceed that of the last verified anchor. The signer retains no per-message state beyond the running MAC accumulation for the current window. Per-message overhead on the link is the MAC tag plus framing (32-44 bytes in the instantiations of ), independent of W.

Properties

Tamper evidence:

Alteration, insertion, or deletion of any message MAC in a window changes the commitment; the anchor signature no longer verifies.

Non-repudiation:

The ML-DSA-87 signature binds the window to the holder of the signing key. Neither session party can later disclaim an anchored window.

Third-party verifiability:

Verification requires only the MAC sequence, the anchor records, and the public verifying key -- not the session key and not the operator's cooperation.

Offline operation:

Anchors are generated and stored locally. No network connection, ledger, consensus mechanism, or external service is required at recording time, making the construction suitable for disconnected, intermittent, and low-bandwidth environments.

Quantum durability:

ML-DSA-87 (NIST security category 5) and SHA3-256 remain secure against known quantum attacks; the evidentiary value of an anchor chain does not expire with the quantum transition.

Constrained-link fit:

One signature amortized over a window keeps per-message overhead constant. Amortized anchor cost at W=256 is approximately 18 bytes per message; at W=4096, approximately 1.1 bytes.

The construction is deliberately not a distributed ledger: it requires no consensus, no replication, and no energy cost beyond one signature per window. It provides evidence, not confidentiality; a confidentiality layer composes independently.

Instantiations Two instantiations have been specified by the author. Both use the construction of ; they differ only in metadata fields and windowing policy. Anchor Instantiations

	High-Rate Telemetry (TAP)	CCSDS Telecommand
Per-message overhead	42 bytes	44 bytes
Window policy	W=256 packets or T=10 s	One ground contact window
Anchor size	4685 bytes	4687 bytes (5 TC frames)
Link budget fit	48.2 kbit/s total at 100 Hz	18.7 s at 2 kbit/s, once per pass

Specifications for both instantiations are published in the repository referenced in the author's address block. The same construction applies to ROS2/DDS topics and CAN buses; the relay-transparency considerations for those stacks are documented in . Session keys for the MAC layer are established via ML-KEM-1024 . Signing-key revocation employs SLH-DSA-SHA2-128s as a hash-based mechanism whose security is independent of lattice assumptions.

Verification Model An auditor holding (1) the stored MAC sequence for the period in question, (2) the anchor records, and (3) the signer's ML-DSA-87 verifying key -- distributed at provisioning time, for example through a documented key ceremony -- proceeds as follows:

1. Partition the MAC sequence into windows according to the anchor metadata.
2. Recompute each window commitment from the stored MACs.
3. Verify each anchor signature over the recomputed commitment and metadata.
4. Verify that anchor sequence numbers are strictly monotonic and gap-free for the claimed period.

A verified anchor chain establishes that the recorded traffic is exactly what the signer authenticated at recording time. The operator cannot retroactively insert, delete, or modify messages without breaking the chain. Verification requires no live system and no trust in the party producing the archive.

Security Considerations

Signer compromise:

An attacker holding the signing key can anchor forged windows from the moment of compromise onward. Anchors emitted before the compromise remain valid evidence. Deployments SHOULD provision a revocation mechanism; the instantiations referenced here use SLH-DSA-signed revocation certificates.

Selective omission:

An operator may withhold entire windows from an archive. Because anchor sequence numbers are monotonic, gaps in the presented chain are themselves detectable and constitute evidence of omission. An auditor MUST treat a gapped chain as an incomplete record.

Commitment security:

SHA3-256 provides 128-bit classical collision resistance. Known quantum collision-search algorithms do not reduce this below practical security margins under realistic memory assumptions.

Replay across sessions:

Anchor metadata binds each window to session-scoped identifiers. A verifier MUST validate window boundary identifiers against the session context in addition to signature validity.

Algorithm agility:

The construction is parametric in H and Sig. Migration to future signature standards changes the anchor format version, not the architecture.

IANA Considerations This document has no IANA actions.

References Normative References National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology Informative References European Parliament and Council National Security Agency

Acknowledgements This work builds on the relay-transparency analysis and the two-layer authentication protocols developed in the CleitonQ project.