Individual Submission C. Bezerra Internet-Draft Independent Researcher Intended status: Informational 3 July 2026 Expires: 4 January 2027 Anchors: Post-Quantum Command Provenance for Autonomous Machine Links draft-bezerra-anchors-command-provenance-00 Abstract 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. Status of This Memo 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. Bezerra Expires 4 January 2027 [Page 1] Internet-Draft Anchors July 2026 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. The Accountability Gap . . . . . . . . . . . . . . . . . . . 4 3.1. Mutable Logs . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Authentication Without Non-Repudiation . . . . . . . . . 4 3.3. Quantum-Expiring Evidence . . . . . . . . . . . . . . . . 4 3.4. AI Agents as Command Issuers . . . . . . . . . . . . . . 4 4. The Anchor Construction . . . . . . . . . . . . . . . . . . . 5 5. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Instantiations . . . . . . . . . . . . . . . . . . . . . . . 6 7. Verification Model . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. 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. Bezerra Expires 4 January 2027 [Page 2] Internet-Draft Anchors July 2026 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 [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? 2. 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 [RFC2119] [RFC8174] 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. Bezerra Expires 4 January 2027 [Page 3] Internet-Draft Anchors July 2026 Auditor: Any party, possibly adversarial to the operator, that verifies an anchor chain after the fact. 3. The Accountability Gap 3.1. 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 [EU-AI-ACT]. 3.2. Authentication Without Non-Repudiation 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. 3.3. 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 [CNSA2]. 3.4. 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 Bezerra Expires 4 January 2027 [Page 4] Internet-Draft Anchors July 2026 authenticated command stream at exactly that boundary, regardless of whether the issuer was human or machine. 4. 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 [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. 5. 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. Bezerra Expires 4 January 2027 [Page 5] Internet-Draft Anchors July 2026 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. 6. Instantiations 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 | 42 bytes | 44 bytes | | overhead | | | +-------------+---------------------------+-------------------+ | Window | W=256 packets or T=10 s | One ground | | policy | | contact window | +-------------+---------------------------+-------------------+ | Anchor size | 4685 bytes | 4687 bytes (5 TC | | | | frames) | +-------------+---------------------------+-------------------+ | Link budget | 48.2 kbit/s total at 100 | 18.7 s at 2 kbit/ | | fit | Hz | s, once per pass | +-------------+---------------------------+-------------------+ Table 1: Anchor Instantiations Bezerra Expires 4 January 2027 [Page 6] Internet-Draft Anchors July 2026 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. 7. 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. 8. 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. Bezerra Expires 4 January 2027 [Page 7] Internet-Draft Anchors July 2026 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. 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References [FIPS202] National Institute of Standards and Technology, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", NIST FIPS 202, August 2015, . [FIPS203] National Institute of Standards and Technology, "Module- Lattice-Based Key-Encapsulation Mechanism Standard", NIST FIPS 203, August 2024, . [FIPS204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", NIST FIPS 204, August 2024, . [FIPS205] National Institute of Standards and Technology, "Stateless Hash-Based Digital Signature Standard", NIST FIPS 205, August 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Bezerra Expires 4 January 2027 [Page 8] Internet-Draft Anchors July 2026 10.2. Informative References [CNSA2] National Security Agency, "Commercial National Security Algorithm Suite 2.0", September 2022, . [EU-AI-ACT] European Parliament and Council, "Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 12: Record-keeping", June 2024, . [I-D.bezerra-relay-auth-transparency] Bezerra, C., "Authentication-Transparent Protocol Extensions in Middleware-Relayed Systems", Work in Progress, Internet-Draft, draft-bezerra-relay-auth- transparency-00, June 2026, . Acknowledgements This work builds on the relay-transparency analysis and the two-layer authentication protocols developed in the CleitonQ project. Author's Address Cleiton Augusto Correa Bezerra Independent Researcher Brazil Email: augusto.cleiton@gmail.com URI: https://github.com/cleitonaugusto/CleitonQ Bezerra Expires 4 January 2027 [Page 9]