Skip to content

Proposed PQC Extension for DDS-Security v1.1: relay-transparent authentication + ML-KEM-1024/ML-DSA-87 #22

Description

@cleitonaugusto

Summary

This issue proposes a Post-Quantum Cryptography (PQC) extension to DDS-Security v1.1 addressing two independent problems:

  1. Quantum vulnerability: Current DDS-Security mandates RSA/ECDSA (identity) and DH/ECDH (key exchange), both broken by Shor's algorithm. NSA CNSA 2.0 mandates migration by 2030 for all National Security Systems.

  2. Relay-transparent authentication stripping (newly documented): Any DDS bridge (domain_bridge, zenoh-bridge-ros2dds, ros1_bridge) re-serializes messages at the CDR type-schema boundary. Authentication bytes appended outside this boundary are silently discarded at every bridge hop — the DataReader receives unauthenticated messages with no error indication.

This is documented in:

Proposed Resolution

A full specification draft is available: docs/omg/dds-security-pqc-extension-spec-v0.1.md (available on request — contact below).

Key elements of the proposal:

Algorithm Suite

Role Algorithm Standard
Key encapsulation ML-KEM-1024 FIPS 203
Digital signature ML-DSA-87 FIPS 204
MAC HMAC-SHA3-256 FIPS 202
Hybrid KEM X25519 + ML-KEM-1024 NIST SP 800-227
Hybrid sig Ed25519 + ML-DSA-87 NIST SP 800-227

Relay-Transparent Authentication Pattern (normative)

Authentication material MUST be published as a separate, independently typed DDS topic:

DataWriter publishes:
  /cmd_vel              (original CDR type, unmodified)
  /cmd_vel/pqc_auth     (PQCAuthToken IDL type)

DataReader buffers /cmd_vel and verifies against /cmd_vel/pqc_auth before delivery.

This is relay-transparent: every DDS bridge forwards both topics as first-class typed messages. An adversary who controls a bridge can achieve DoS (drop the auth topic) but cannot inject unauthenticated commands — the DataReader times out and discards unverified messages.

IDL Types (excerpt)

// Published on /topic_name/pqc_auth
struct PQCAuthToken {
  @key unsigned long long nonce;     // monotonic, saturates at 2^64-1
  sequence<octet, 32>  payload_hash; // SHA3-256 of protected CDR payload
  sequence<octet, 32>  mac;          // HMAC-SHA3-256(K_mac_n, nonce||hash)
  sequence<octet, 4627> signature;   // Optional ML-DSA-87 (non-repudiation)
  PQCAlgorithmId signature_algorithm;
  sequence<octet, 16> writer_guid;
};

Performance (measured, criterion.rs, 2026-06-16)

Operation Neoverse-N2 (hw SHA-3) x86-64 (sw SHA-3)
ML-KEM-1024 encaps 70 µs 74 µs
ML-KEM-1024 decaps 84 µs 90 µs
ML-DSA-87 verify 84 µs 102 µs
ML-DSA-87 sign 509–962 µs 403–735 µs
HMAC-SHA3-256 (38 B) 1.1 µs 2.0 µs
Session establish 241 µs 272 µs
Per-message verify (MAC-only) ~85 µs ~104 µs

MAC-only mode is viable at high-frequency topics (85 µs/msg on ARM64). ML-DSA-87 per-message signing is RECOMMENDED only for safety-critical commands.

Reference Implementation

CleitonQ — MIT OR Apache-2.0

  • Rust library: 132 tests, 0 clippy warnings, cargo audit clean
  • C API for ArduPilot/PX4/ROS2 C++ integration
  • Formally verified: ProVerif (4 properties) + Tamarin Prover (5 lemmas, 3.04s)
  • CI: x86-64 (Ubuntu) + ARM64 (GitHub-hosted, AWS Graviton3)

Requesting

  1. Assignment to the DDS-Security FTF (or new FTF) for review
  2. Feedback on the IDL types and parallel-topic binding rule
  3. Interest from CycloneDDS / FastDDS / Connext DDS in interoperability testing

Contact

Cleiton Augusto Correa Bezerra
augusto.cleiton@gmail.com
IETF I-D: https://datatracker.ietf.org/doc/draft-bezerra-relay-auth-transparency/

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions