Topic · Spec-Referenz

DDS-Security Plugin Reference

DDS-Security 1.2 spezifiziert fünf Plugin-Traits, die in einer Kette an jeder Submessage hängen: Authentication → AccessControl → Cryptographic → Logging → DataTagging. ZeroDDS implementiert alle fünf, plus die Trust-Anker-Surface in 7 Crates. Pro Plugin: Trait-Methoden, Spec-§, Default-Implementation, Code-Pfade. Konkrete Setup-Rezepte (PKI-Setup, Permissions-XML, KeyExchange-Modi) im Security-Plugin-Chain Cookbook.

5 Plugin-Traits · 7 Crates Spec: DDS-Security 1.2 · DDSI-RTPS 2.5 §7.8 Trait-Root: zerodds-security

Überblick

DDS-Security 1.2 definiert ein Plugin-Architektur-Modell: ein Service-Plugin-Interface (SPI) je Sicherheits-Aspekt, mit klar abgegrenzten Trait-Surfaces und definierten Token-Austausch-Flüssen.

Die fünf Plugins:

  • Authentication (§9.3) — Wer bist du? Identity-Token-Austausch, Handshake-Protokoll, Shared-Secret-Etablierung.
  • AccessControl (§9.4) — Was darfst du? Governance-Policies + Permissions-XML, Topic-Zugriffs-Matrix.
  • Cryptographic (§9.5) — Wie wird's geschützt? Sample-Encryption, MAC, Key-Derivation, Crypto-Header.
  • Logging (§9.6) — Was wurde gemacht? Audit-Events mit Severity, Topic-Filter, Fan-Out an Sinks.
  • DataTagging (§9.7) — Inhalts-Klassifizierung als sekundärer Filter (z.B. classification=CONFIDENTIAL).

Spec-Coverage: DDS-Security 1.2 Coverage →

Die Plugin-Chain — Order matters

Bei jedem ausgehenden Sample läuft die Kette von oben nach unten; bei jedem eingehenden in umgekehrter Reihenfolge. Mismatch in einer Stufe blockt das Sample und triggert ein Logging-Event.

ReihenfolgePluginWas passiertWas bei Fail
1AuthenticationIdentity-Handshake (einmalig pro Participant-Pair via SEDP). Liefert SharedSecret.Participant-Match abgelehnt; SECURITY_AUTHENTICATION_FAILED-Event.
2AccessControlPermissions-XML-Lookup: Darf dieser Identity-Holder dieses Topic schreiben/lesen?Endpoint-Match abgelehnt; SECURITY_ACCESS_CONTROL_FAILED.
3CryptographicSample-Encrypt/MAC mit aus SharedSecret abgeleiteten Key-Material (AES-GCM, AES-GMAC).Sample-Drop; SECURITY_CRYPTO_FAILED.
4DataTaggingOptional: Sample-Tag-Match gegen Tag-Filter (z.B. level=SECRET).Sample-Drop ohne SECURITY-Event (data-tagging ist Filter, kein Block).
5LoggingAudit-Event mit Severity, Endpoint-Handle, Timestamp an Sinks (stderr, JSONL, syslog, Fanout).Best-effort; Sink-Failure killt nicht den Sample-Path.

Die Chain-Wire-Repräsentation lebt in zerodds-security-rtps: pro RTPS-Datagram werden Header-AAD und Crypto-Submessage-Wrapper geschrieben (§7.8 DDSI-RTPS 2.5).

Authentication-Plugin

AuthenticationPlugin DDS-Security 1.2 §9.3 · Identity + Handshake

Trait: crates/security/src/authentication.rs::AuthenticationPlugin

Kern-Methoden:

  • validate_local_identity() — eigene Cert/Key laden, IdentityHandle zurück.
  • validate_remote_identity() — Remote-Participant-Cert prüfen (CA-Chain, Validity, Revocation).
  • begin_handshake_request() / begin_handshake_reply() / process_handshake() — 3-Way-Handshake mit Diffie-Hellman, liefert SharedSecret.
  • get_authenticated_peer_credential_token() — Cert-Token für AccessControl-Lookup.

Default-Implementation: zerodds-security-pki — Identity ist X.509-Cert, Handshake via DH (P-256 Default), SharedSecret via HKDF. CRL-Pfad in crl.rs.

Custom-Auth: eigenes Plugin implementiert AuthenticationPlugin. Use-Cases: HSM-basierte Keys (PKCS#11), externe IdP (OAuth2-Token-Mapping), Hardware-attestation.

AccessControl-Plugin

AccessControlPlugin DDS-Security 1.2 §9.4 · Governance + Permissions

Trait: crates/security/src/access_control.rs::AccessControlPlugin

Kern-Methoden:

  • validate_local_permissions() — eigenes Permissions-XML laden (CMS-signiert).
  • validate_remote_permissions() — Remote-Permissions prüfen.
  • check_create_participant() / check_create_datawriter() / check_create_datareader() — Endpoint-Erstellung gegen Permissions matchen.
  • get_governance_document() — Domain-Level-Policies (Default-Encryption, Allow-Unauthenticated, ...).

Default-Implementation: zerodds-security-permissions — XML-Loader, CMS-Signatur-Validierung, Topic-Glob-Match. Governance + Permissions sind separate XML-Files mit Subject-Name aus dem Identity-Cert.

Permission-Match: Glob-Pattern auf Topic-Namen (z.B. customer-*/odom). Delegation-Check in delegation_check.rs für Multi-Tier-CA-Setups.

Cryptographic-Plugin

CryptographicPlugin DDS-Security 1.2 §9.5 · Sample-Encrypt + MAC

Trait: crates/security/src/crypto.rs::CryptographicPlugin

Kern-Methoden:

  • register_local_participant() / register_remote_participant() — Key-Material-Slot pro Peer.
  • encode_serialized_payload() / decode_serialized_payload() — Sample-Encrypt/Decrypt.
  • encode_datawriter_submessage() / encode_datareader_submessage() — Submessage-Wrapping (AES-GCM oder AES-GMAC).
  • encode_rtps_message() — Datagram-Level Crypto-Header.

Default-Implementation: zerodds-security-crypto — AES-128-GCM, AES-256-GCM, AES-128-GMAC, AES-256-GMAC. Hardware-Acceleration via AES-NI in aes_gcm_hw.rs.

Wire-Form: RTPS-Crypto-Submessages in zerodds-security-rtps. Header-AAD-Verdrahtung (§9.5.3.3.4) in header_aad.rs.

Logging-Plugin

LoggingPlugin DDS-Security 1.2 §9.6 · Audit-Trail

Trait: crates/security/src/logging.rs::LoggingPlugin

Kern-Methoden:

  • log() — strukturiertes Event mit Severity (Emergency/Alert/Critical/Error/Warning/Notice/Info/Debug), Plugin-Class, Message, Timestamp, Endpoint-Handle.
  • set_log_options() — Severity-Filter, Topic-Filter, Export-Format.

Default-Implementation: zerodds-security-logging mit vier Sinks:

  • stderr_sink.rs — Standard-Error mit Severity-Farbe.
  • jsonl.rs — newline-delimited JSON für Log-Aggregator (Loki, ELK).
  • syslog.rs — RFC 5424 mit DDS-spezifischen Facility-Codes.
  • fanout.rs — Multi-Sink-Fanout, jeder Sink mit eigenem Severity-Filter.

DataTagging-Plugin

DataTaggingPlugin DDS-Security 1.2 §9.7 · Sample-Klassifizierung

Trait: crates/security/src/data_tagging.rs::DataTaggingPlugin

Kern-Methoden:

  • get_data_tag() — Tag pro Sample (Key/Value-Pairs, z.B. classification=CONFIDENTIAL).
  • check_data_tag() — eingehende Sample-Tags gegen Reader-Filter matchen.

Default-Implementation: Built-in in zerodds-security-runtime/src/data_tagging.rs. Tags reisen als RTPS-Parameter-List-Eintrag (PID_DATA_TAGS, §7.4.8).

Use-Case: Classification-Bell-LaPadula-style Read-Down/Write-Up Filter — Reader mit level=SECRET-Filter empfängt nur Samples mit level=SECRET oder darunter.

Implementation-Crates — Crates-Map

CrateRollePlugin-Trait-ImplRepo
zerodds-securitySPI-Traits + Token-Types—crates/security
zerodds-security-pkiX.509 + CRL + HandshakeAuthenticationPlugincrates/security-pki
zerodds-security-keyexchangeDH-Key-Exchange + HKDFSharedSecretProvidercrates/security-keyexchange
zerodds-security-permissionsPermissions-XML + GovernanceAccessControlPlugincrates/security-permissions
zerodds-security-cryptoAES-GCM/GMAC + AES-NI HWCryptographicPlugincrates/security-crypto
zerodds-security-loggingAudit-Sinks + FanoutLoggingPlugincrates/security-logging
zerodds-security-rtpsWire-Codec + Header-AAD—crates/security-rtps
zerodds-security-runtimePlugin-Wiring + Builtin-Topics—crates/security-runtime
Topic · Spec reference

DDS-Security Plugin Reference

DDS-Security 1.2 specifies five plugin traits that hang in a chain on every submessage: Authentication → AccessControl → Cryptographic → Logging → DataTagging. ZeroDDS implements all five, plus the trust-anchor surface, across 7 crates. Per plugin: trait methods, spec §, default implementation, code paths. Concrete setup recipes (PKI setup, permissions XML, key-exchange modes) in the Security Plugin-Chain Cookbook.

5 plugin traits · 7 crates Spec: DDS-Security 1.2 · DDSI-RTPS 2.5 §7.8 Trait root: zerodds-security

Overview

DDS-Security 1.2 defines a plugin architecture model: a service plugin interface (SPI) per security aspect, with clearly bounded trait surfaces and defined token-exchange flows.

The five plugins:

  • Authentication (§9.3) — who are you? Identity-token exchange, handshake protocol, shared-secret establishment.
  • AccessControl (§9.4) — what may you do? Governance policies + permissions XML, topic access matrix.
  • Cryptographic (§9.5) — how is it protected? Sample encryption, MAC, key derivation, crypto header.
  • Logging (§9.6) — what was done? Audit events with severity, topic filter, fan-out to sinks.
  • DataTagging (§9.7) — content classification as a secondary filter (e.g. classification=CONFIDENTIAL).

Spec coverage: DDS-Security 1.2 coverage →

The plugin chain — order matters

On every outgoing sample the chain runs top to bottom; on every incoming one in reverse order. A mismatch at any stage blocks the sample and triggers a logging event.

OrderPluginWhat happensOn fail
1AuthenticationIdentity handshake (once per participant pair via SEDP). Yields the SharedSecret.Participant match rejected; SECURITY_AUTHENTICATION_FAILED event.
2AccessControlPermissions XML lookup: may this identity holder write/read this topic?Endpoint match rejected; SECURITY_ACCESS_CONTROL_FAILED.
3CryptographicSample encrypt/MAC with key material derived from the SharedSecret (AES-GCM, AES-GMAC).Sample drop; SECURITY_CRYPTO_FAILED.
4DataTaggingOptional: sample tag match against a tag filter (e.g. level=SECRET).Sample drop without a SECURITY event (data tagging is a filter, not a block).
5LoggingAudit event with severity, endpoint handle, timestamp to sinks (stderr, JSONL, syslog, fanout).Best-effort; a sink failure does not kill the sample path.

The chain's wire representation lives in zerodds-security-rtps: per RTPS datagram a header AAD and a crypto submessage wrapper are written (§7.8 DDSI-RTPS 2.5).

Authentication plugin

AuthenticationPlugin DDS-Security 1.2 §9.3 · identity + handshake

Trait: crates/security/src/authentication.rs::AuthenticationPlugin

Core methods:

  • validate_local_identity() — load your own cert/key, return an IdentityHandle.
  • validate_remote_identity() — check the remote participant cert (CA chain, validity, revocation).
  • begin_handshake_request() / begin_handshake_reply() / process_handshake() — 3-way handshake with Diffie-Hellman, yields the SharedSecret.
  • get_authenticated_peer_credential_token() — cert token for AccessControl lookup.

Default implementation: zerodds-security-pki — identity is an X.509 cert, handshake via DH (P-256 default), SharedSecret via HKDF. CRL path in crl.rs.

Custom auth: your own plugin implements AuthenticationPlugin. Use cases: HSM-based keys (PKCS#11), an external IdP (OAuth2 token mapping), hardware attestation.

AccessControl plugin

AccessControlPlugin DDS-Security 1.2 §9.4 · governance + permissions

Trait: crates/security/src/access_control.rs::AccessControlPlugin

Core methods:

  • validate_local_permissions() — load your own permissions XML (CMS-signed).
  • validate_remote_permissions() — check remote permissions.
  • check_create_participant() / check_create_datawriter() / check_create_datareader() — match endpoint creation against the permissions.
  • get_governance_document() — domain-level policies (default encryption, allow-unauthenticated, ...).

Default implementation: zerodds-security-permissions — XML loader, CMS signature validation, topic glob match. Governance + permissions are separate XML files with the subject name from the identity cert.

Permission match: glob patterns on topic names (e.g. customer-*/odom). Delegation check in delegation_check.rs for multi-tier-CA setups.

Cryptographic plugin

CryptographicPlugin DDS-Security 1.2 §9.5 · sample encrypt + MAC

Trait: crates/security/src/crypto.rs::CryptographicPlugin

Core methods:

  • register_local_participant() / register_remote_participant() — a key-material slot per peer.
  • encode_serialized_payload() / decode_serialized_payload() — sample encrypt/decrypt.
  • encode_datawriter_submessage() / encode_datareader_submessage() — submessage wrapping (AES-GCM or AES-GMAC).
  • encode_rtps_message() — datagram-level crypto header.

Default implementation: zerodds-security-crypto — AES-128-GCM, AES-256-GCM, AES-128-GMAC, AES-256-GMAC. Hardware acceleration via AES-NI in aes_gcm_hw.rs.

Wire form: RTPS crypto submessages in zerodds-security-rtps. Header AAD wiring (§9.5.3.3.4) in header_aad.rs.

Logging plugin

LoggingPlugin DDS-Security 1.2 §9.6 · audit trail

Trait: crates/security/src/logging.rs::LoggingPlugin

Core methods:

  • log() — a structured event with severity (Emergency/Alert/Critical/Error/Warning/Notice/Info/Debug), plugin class, message, timestamp, endpoint handle.
  • set_log_options() — severity filter, topic filter, export format.

Default implementation: zerodds-security-logging with four sinks:

  • stderr_sink.rs — standard error with severity colouring.
  • jsonl.rs — newline-delimited JSON for the log aggregator (Loki, ELK).
  • syslog.rs — RFC 5424 with DDS-specific facility codes.
  • fanout.rs — multi-sink fanout, each sink with its own severity filter.

DataTagging plugin

DataTaggingPlugin DDS-Security 1.2 §9.7 · sample classification

Trait: crates/security/src/data_tagging.rs::DataTaggingPlugin

Core methods:

  • get_data_tag() — a tag per sample (key/value pairs, e.g. classification=CONFIDENTIAL).
  • check_data_tag() — match incoming sample tags against the reader filter.

Default implementation: built-in in zerodds-security-runtime/src/data_tagging.rs. Tags travel as an RTPS ParameterList entry (PID_DATA_TAGS, §7.4.8).

Use case: Bell-LaPadula-style read-down/write-up classification filters — a reader with a level=SECRET filter receives only samples at level=SECRET or below.

Implementation crates — crates map

CrateRolePlugin trait implRepo
zerodds-securitySPI traits + token types—crates/security
zerodds-security-pkiX.509 + CRL + handshakeAuthenticationPlugincrates/security-pki
zerodds-security-keyexchangeDH key exchange + HKDFSharedSecretProvidercrates/security-keyexchange
zerodds-security-permissionspermissions XML + governanceAccessControlPlugincrates/security-permissions
zerodds-security-cryptoAES-GCM/GMAC + AES-NI HWCryptographicPlugincrates/security-crypto
zerodds-security-loggingaudit sinks + fanoutLoggingPlugincrates/security-logging
zerodds-security-rtpswire codec + header AAD—crates/security-rtps
zerodds-security-runtimeplugin wiring + builtin topics—crates/security-runtime