| Internet-Draft | Anchors | July 2026 |
| Bezerra | Expires 4 January 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
Command-and-control (C2) links for autonomous machines increasingly require two distinct security services that current deployments conflate or omit:¶
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 [FIPS204] 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 [I-D.bezerra-relay-auth-transparency]. 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?¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 [EU-AI-ACT].¶
Symmetric MACs -- including quantum-resistant constructions such as HMAC with SHA-3 [FIPS202] -- 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.¶
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 [CNSA2].¶
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 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 [FIPS203] and authenticated with HMAC-SHA3-256).¶
Given a window of n authenticated messages with MAC tags
mac_0 ... mac_{n-1}:
commitment = H( mac_0 || mac_1 || ... || mac_{n-1} )
anchor = ( metadata,
commitment,
Sig_sk( metadata || commitment ) )
where:
H = SHA3-256 [FIPS202]
Sig = ML-DSA-87 [FIPS204]
metadata = anchor sequence number,
window start identifier,
window end identifier,
message count
¶
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 Section 6), independent of W.¶
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.¶
Two instantiations have been specified by the author. Both use the construction of Section 4; they differ only in metadata fields and windowing policy.¶
| 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 [I-D.bezerra-relay-auth-transparency].¶
Session keys for the MAC layer are established via ML-KEM-1024 [FIPS203]. Signing-key revocation employs SLH-DSA-SHA2-128s [FIPS205] as a hash-based mechanism whose security is independent of lattice assumptions.¶
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:¶
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.¶
This document has no IANA actions.¶
This work builds on the relay-transparency analysis and the two-layer authentication protocols developed in the CleitonQ project.¶