Topic · Spec-Referenz

PKI Reference — Cert-Lifecycle & Trust-Anker

Das DDS-Security 1.2 Authentication-Plugin nutzt X.509-PKI als Default-Identity-Modell. Diese Referenz dokumentiert den ZeroDDS-PKI-Stack: Trust-Anker, Identity-Token, 3-Way-Handshake mit Diffie-Hellman, CRL-/OCSP-Revocation, Multi-Tier-Delegation, plus Pre-Shared-Key-Fallback. Konkrete Setup-Rezepte (Root-CA, Cert-Rotation, HSM-Integration) im PKI Governance Cookbook.

Spec: DDS-Security 1.2 §9.3 + §10 Crate: zerodds-security-pki Auth-Plugin: X.509 + rustls-webpki

Überblick

DDS-Security 1.2 §9.3 spezifiziert ein Plugin-Interface fuer Authentication; das vorgesehene Default-Modell ist X.509-PKI mit Diffie-Hellman-Handshake (§10). ZeroDDS implementiert beide Pfade in crates/security-pki:

  • X.509-Identity — der „echte" Pfad fuer Production. CA-signierte Certs als Identity, periodische Revocation-Checks via CRL/OCSP.
  • Pre-Shared-Key (PSK) — der Spec-konforme Fallback fuer Lab-Setups oder embedded ohne PKI-Infrastruktur. §10.7.

Pro Participant gibt es einen Trust-Anker (eine oder mehrere CA-Certs), ein eigenes Identity-Cert/Private-Key-Paar, und optional eine CRL/OCSP-Quelle. Alles steckt im PropertyQosPolicy am DomainParticipantQos — siehe Cookbook-Rezept §1.

Identity & Trust-Anker

X.509 Identity-Cert DDS-Security 1.2 §9.3.2.1 + §10.3.1

Crate: crates/security-pki/src/identity.rs · identity_token.rs

Format: PEM-encoded X.509-Cert. Subject-Name aus Cert wird zu SubjectName für AccessControl-Lookup. ZeroDDS akzeptiert RSA (2048+), ECDSA (P-256/P-384/P-521) und Ed25519.

Trust-Chain-Validation: via rustls-webpki. Caller liefert ein oder mehrere CA-Certs als Trust-Anker (Property dds.sec.auth.identity_ca); jeder Remote-Cert muss dorthin chainen. Selbst-signierte Roots sind erlaubt fuer geschlossene Deployments.

IdentityToken (Wire-Form) §10.3.2.1

Wire-Repräsentation des Identity-Cert auf SPDP-Discovery-Beacons. Trägt das DER-encoded X.509-Cert plus eine Hash-Algorithm-ID. Wird in PID_IDENTITY_TOKEN als ParameterList-Item übertragen. Implementation: identity_token.rs.

3-Way-Handshake

HandshakeRequest → Reply → Final DDS-Security 1.2 §9.3.3 + §10.3.2.2-§10.3.2.4

Crate: crates/security-pki/src/handshake_token.rs

Flow:

  1. Request (Initiator → Replier): IdentityToken + AuthRequestToken (zufällige 32-Byte Challenge1) + DH-PublicKey-A.
  2. Reply (Replier → Initiator): IdentityToken + Challenge1-Echo + AuthRequestToken (Challenge2) + DH-PublicKey-B + Hash_C1 (HMAC über Challenges + DH-Keys, mit Replier-Identity signiert).
  3. Final (Initiator → Replier): Challenge2-Echo + Hash_C2 (analog, mit Initiator-Identity signiert).

Nach erfolgreichem Handshake leiten beide Seiten via HKDF aus dem DH-SharedSecret das Key-Material für den Cryptographic-Plugin ab (siehe Cryptographic-Plugin Reference).

DH-Kurven: P-256 (Default), P-384, P-521. Implementiert via ring-Crate.

AuthRequest-Challenges: 32 zufällige Bytes pro Seite, geschützen gegen Replay-Attacks. Implementation: auth_request.rs.

Revocation — CRL + OCSP

CRL — Certificate Revocation List RFC 5280 §5

Crate: crates/security-pki/src/crl.rs

Mechanik: CA publisht regelmäßig eine signierte Liste der revoked Serial-Numbers. ZeroDDS lädt die CRL (Property dds.sec.auth.identity_crl = file:/path) und prüft jeden Handshake-Remote-Cert gegen die Liste. Match → Authentication abgelehnt.

Lookup: parse_crl_serials(der) -> Vec<Vec<u8>> + validate_crl(der, cert_serial) -> Result<()>. Einfache Linear-Search; bei großen CRLs (10k+ Einträge) ist eine BTreeMap-Wrapper-Schicht in Phase-2.

Aktualisierungs-Strategie: CRL hat eine nextUpdate-Frist; CRL-Re-Load passiert beim Participant-Start. Live-Reload ohne Restart ist Roadmap.

OCSP — Online Certificate Status Protocol RFC 6960

Crate: crates/security-pki/src/ocsp.rs

Mechanik: Live-Lookup pro Cert via OCSP-Responder; ZeroDDS implementiert OCSP-Stapling (Cert trägt eine kürzlich signierte OCSP-Response). Cert-Holder muss die Stapling-Response in der IdentityStatusToken-Property mitliefern.

Wann OCSP statt CRL: große Deployment-Skalen (10k+ Certs), Real-Time-Revocation-Reaktion. OCSP-Stapling reduziert Latency (kein Live-Round-Trip pro Cert), bedeutet aber Lifetime-Aufwand am Cert-Holder.

IdentityStatusToken (Wire-Form) DDS-Security 1.2 §10.3.2.5

Crate: crates/security-pki/src/identity_status.rs

Wire-Repräsentation des Revocation-Status eines Remote-Certs. Drei States: good (Cert ist gültig, expiry-Zeitpunkt im Token), revoked (Cert revoked, optional OCSP-Response als Beweis), unknown (Status unbekannt). Wird über SEDP-builtin-topic DCPSParticipantStatelessMessage propagiert.

Multi-Tier-Delegation

DelegationLink — Chained-Authority DDS-Security 1.2 §9.4.1.2.4

Crate: crates/security-pki/src/delegation.rs

Use-Case: in Multi-Tenant-Setups will man nicht jeden Participant direkt von der Root-CA signieren. Stattdessen: Root → Tenant-CA → Participant-Cert. Spec erlaubt mehrere Delegations-Stufen, sofern jede Stufe eine signierte Delegation-Behauptung trägt.

API: DelegationLink::new(subject, authority, scopes), sign(pkcs8_key), verify(public_key). Implementation via ECDSA-Signatur (gleiche Kurve wie Identity).

Validation: AccessControl-Plugin (siehe Security Reference §AC) prüft beim Permissions-Match die Delegation-Chain — Subject darf nur Topics nutzen, die in der eigenen Authority-Subset liegen.

Pre-Shared-Key-Fallback

Builtin PSK-Authentication DDS-Security 1.2 §10.7

Crate: crates/security-pki/src/psk.rs

Mechanik: Beide Participants teilen einen Pre-Shared-Key (32 Byte). Der „Handshake" reduziert sich auf einen Mutual-MAC-Check über zwei Nonces. Kein DH, kein Cert, kein CA.

Wann nutzen:

  • Lab/Test-Setups ohne PKI-Infrastruktur.
  • Embedded ohne genug Speicher für Cert-Parsing (Cortex-M3/M0).
  • Closed-Network mit Hardware-Provisioning (Smart-Card mit eingravierter PSK).

Limitierung: kein Key-Rotation ohne Re-Provisioning. Keine Permissions-Subject-Identität (Permissions-XML kann nicht pro Participant differenzieren). Skaliert nicht jenseits weniger Peers (PSK pro Participant-Pair wäre N×N Keys).

Topic · Spec reference

PKI Reference — cert lifecycle & trust anchor

The DDS-Security 1.2 Authentication plugin uses X.509 PKI as the default identity model. This reference documents the ZeroDDS PKI stack: trust anchor, identity token, the 3-way handshake with Diffie-Hellman, CRL/OCSP revocation, multi-tier delegation, plus the pre-shared-key fallback. Concrete setup recipes (root CA, cert rotation, HSM integration) in the PKI Governance Cookbook.

Spec: DDS-Security 1.2 §9.3 + §10 Crate: zerodds-security-pki Auth plugin: X.509 + rustls-webpki

Overview

DDS-Security 1.2 §9.3 specifies a plugin interface for authentication; the intended default model is X.509 PKI with a Diffie-Hellman handshake (§10). ZeroDDS implements both paths in crates/security-pki:

  • X.509 identity — the "real" path for production. CA-signed certs as identity, periodic revocation checks via CRL/OCSP.
  • Pre-shared key (PSK) — the spec-conformant fallback for lab setups or embedded without PKI infrastructure. §10.7.

Per participant there is a trust anchor (one or more CA certs), its own identity-cert/private-key pair, and optionally a CRL/OCSP source. It all lives in the PropertyQosPolicy on the DomainParticipantQos — see Cookbook recipe §1.

Identity & trust anchor

X.509 identity cert DDS-Security 1.2 §9.3.2.1 + §10.3.1

Crate: crates/security-pki/src/identity.rs · identity_token.rs

Format: PEM-encoded X.509 cert. The subject name from the cert becomes the SubjectName for AccessControl lookup. ZeroDDS accepts RSA (2048+), ECDSA (P-256/P-384/P-521) and Ed25519.

Trust-chain validation: via rustls-webpki. The caller provides one or more CA certs as the trust anchor (property dds.sec.auth.identity_ca); every remote cert must chain to it. Self-signed roots are allowed for closed deployments.

IdentityToken (wire form) §10.3.2.1

The wire representation of the identity cert on SPDP discovery beacons. Carries the DER-encoded X.509 cert plus a hash-algorithm ID. Transmitted in PID_IDENTITY_TOKEN as a ParameterList item. Implementation: identity_token.rs.

3-way handshake

HandshakeRequest → Reply → Final DDS-Security 1.2 §9.3.3 + §10.3.2.2-§10.3.2.4

Crate: crates/security-pki/src/handshake_token.rs

Flow:

  1. Request (initiator → replier): IdentityToken + AuthRequestToken (random 32-byte Challenge1) + DH public key A.
  2. Reply (replier → initiator): IdentityToken + Challenge1 echo + AuthRequestToken (Challenge2) + DH public key B + Hash_C1 (HMAC over the challenges + DH keys, signed with the replier identity).
  3. Final (initiator → replier): Challenge2 echo + Hash_C2 (analogous, signed with the initiator identity).

After a successful handshake both sides derive, via HKDF from the DH shared secret, the key material for the Cryptographic plugin (see the Cryptographic plugin reference).

DH curves: P-256 (default), P-384, P-521. Implemented via the ring crate.

AuthRequest challenges: 32 random bytes per side, guarding against replay attacks. Implementation: auth_request.rs.

Revocation — CRL + OCSP

CRL — Certificate Revocation List RFC 5280 §5

Crate: crates/security-pki/src/crl.rs

Mechanism: the CA regularly publishes a signed list of revoked serial numbers. ZeroDDS loads the CRL (property dds.sec.auth.identity_crl = file:/path) and checks every handshake remote cert against the list. A match → authentication rejected.

Lookup: parse_crl_serials(der) -> Vec<Vec<u8>> + validate_crl(der, cert_serial) -> Result<()>. A simple linear search; for large CRLs (10k+ entries) a BTreeMap wrapper layer is in phase 2.

Update strategy: a CRL has a nextUpdate deadline; the CRL reload happens at participant start. Live reload without a restart is on the roadmap.

OCSP — Online Certificate Status Protocol RFC 6960

Crate: crates/security-pki/src/ocsp.rs

Mechanism: a live lookup per cert via an OCSP responder; ZeroDDS implements OCSP stapling (the cert carries a recently signed OCSP response). The cert holder must supply the stapling response in the IdentityStatusToken property.

When OCSP instead of CRL: large deployment scales (10k+ certs), real-time revocation reaction. OCSP stapling reduces latency (no live round-trip per cert) but means lifetime maintenance on the cert holder.

IdentityStatusToken (wire form) DDS-Security 1.2 §10.3.2.5

Crate: crates/security-pki/src/identity_status.rs

The wire representation of a remote cert's revocation status. Three states: good (cert valid, expiry time in the token), revoked (cert revoked, optionally an OCSP response as proof), unknown (status unknown). Propagated over the SEDP builtin topic DCPSParticipantStatelessMessage.

Multi-tier delegation

DelegationLink — chained authority DDS-Security 1.2 §9.4.1.2.4

Crate: crates/security-pki/src/delegation.rs

Use case: in multi-tenant setups you don't want to sign every participant directly from the root CA. Instead: root → tenant CA → participant cert. The spec allows several delegation levels as long as each level carries a signed delegation assertion.

API: DelegationLink::new(subject, authority, scopes), sign(pkcs8_key), verify(public_key). Implemented via an ECDSA signature (same curve as the identity).

Validation: the AccessControl plugin (see Security Reference §AC) checks the delegation chain at permissions match — a subject may only use topics within its own authority subset.

Pre-shared-key fallback

Builtin PSK authentication DDS-Security 1.2 §10.7

Crate: crates/security-pki/src/psk.rs

Mechanism: both participants share a pre-shared key (32 bytes). The "handshake" reduces to a mutual MAC check over two nonces. No DH, no cert, no CA.

When to use:

  • Lab/test setups without PKI infrastructure.
  • Embedded without enough memory for cert parsing (Cortex-M3/M0).
  • Closed network with hardware provisioning (a smart card with an engraved PSK).

Limitation: no key rotation without re-provisioning. No permissions subject identity (permissions XML can't differentiate per participant). Doesn't scale beyond a few peers (one PSK per participant pair would be N×N keys).