DDS-Security: Middleware Protection in RTPS

• DDS-Security is a specification that secures DDS middleware by enforcing message authentication, confidentiality, and access control in distributed real-time systems.
• It employs robust technologies such as X.509 certificates, AES-GCM encryption, and a three-way handshake to establish secure channels and derive session keys.
• Empirical studies show that activating full DDS-Security can double latency and reduce throughput by up to 50%, highlighting critical performance trade-offs.

The Data Distribution Service Security (DDS-Security) specification, formalized in OMG DDS™ Security v1.1, defines an extension of the DDS middleware architecture to enforce message authentication, confidentiality, integrity, fine-grained access control, and auditability across distributed real-time publish/subscribe systems. DDS-Security is the foundation of security in systems such as ROS 2 and increasingly in domains including robotics, Industrial IoT, and automotive Ethernet networking. Its design combines X.509-based public key infrastructure (PKI), modern cryptographic primitives (AES-GCM, ECDHE, RSA/ECDSA), XML-encoded policy artifacts (governance and permissions), and a plugin-based service architecture. The following exposition systematizes the design, configuration, threat profile, vulnerabilities, empirical performance impacts, and best-practice guidelines of DDS-Security, strictly based on technical analyses and representative experimental studies.

1. DDS-Security Model and Protocol Structure

DDS-Security is realized through three primary domains: authentication, encryption/confidentiality, and access control (Kim et al., 2018, Vilches et al., 2022). All are mandatory for "secure" operational modes. The architecture leverages a Service Plugin Interface (SPI) with defined plugin hooks for authentication, access-control, cryptography, logging, and (optionally) data tagging (DiLuoffo et al., 2019, White et al., 2019).

Specification Elements

• Authentication: Participants must present X.509 v3 certificates (signed by a trusted Identity CA) at join time.
• Key Exchange: Three-way handshake (HandshakeRequest, HandshakeReply, HandshakeFinal) transmits certificates, Diffie–Hellman (DH/ECDH) public parameters, and random nonces. Session keys are derived via HKDF from the shared secret $K = g^{ab} \mod p$ (or ECDH variant) and nonces.
• Encryption/Integrity: All data and optionally metadata are encrypted or signed using symmetric AES-GCM (128 or 256 bits) and authenticated with AES-GMAC. The default policy enables both confidentiality (ENCRYPT) and integrity (SIGN) per-topic and per-metadata.
• Access Control: XML-encoded governance and permissions documents—signed by a dedicated CA—define what operations each participant is authorized to perform on each resource (topics, partitions).
• Audit Logging: Optional, defined by the Security SPI, for recording and inspecting security-relevant events.

Plugin Loading

DDS-Security plugins are loaded dynamically by the DDS middleware at runtime, parsing the XML policy artifacts and installing hooks on message sends/receives, handshake, and participant/DataReader/DataWriter object creation (Vilches et al., 2022).

2. Security Handshake and Policy Artifacts

DDS-Security mutual authentication and session key establishment follows a rigid sequence:

1. HandshakeRequest: Initiator sends its X.509 certificate, DH/ECDH public key, nonce $N_A$.
2. HandshakeReply: Responder returns its certificate, public key, nonces $N_A$, $N_B$, and a signature binding these fields.
3. HandshakeFinal: Initiator signs a message confirming receipt of nonces and public keys.
4. Session Key Derivation: Both derive $$K_\mathrm{sess} = \mathrm{KDF}(g^{ab} \| N_A \| N_B)$$.
5. Secure Channel: Subsequent RTPS data, discovery, liveliness, and non-data submessages are protected per the policy via encryption/signature settings.

Policy Artifacts

• Governance Document (governance.xml): Specifies domain-wide security enablement, allowed protection kinds (NONE/SIGN/ENCRYPT for each submessage class), and whether unauthenticated participants are allowed.
• Permissions Document (permissions.xml): Per-participant grants, structured as capability lists specifying (ALLOW/DENY) rules at topic, partition, and data-tag granularity (Brodie et al., 8 May 2026).
• Certificate Chain: CA private/public keys and per-participant certificates.

Critical design note: The handshake leaks the signed permissions token $\sigma_{CA}(\Pi)$ in cleartext, exposing the capability mapping of each participant to passive sniffers (White et al., 2019).

3. Security Configurations, Systemic Vulnerabilities, and Attack Models

Configurations

Typical operational modes, as standardized and empirically benchmarked, are:

Configuration	Authentication	Access Control	Crypto Protection	Signing	Encryption	Logging
Not Used	No	No	No	No	No	No
None	Yes	Yes	Plug-in loaded, No protection	No	No	No
Sign	Yes	Yes	Yes	Yes	No	Optional
Encrypt	Yes	Yes	Yes	Yes	Yes	Optional

Activating progressively stronger protections incurs measurable throughput and latency costs (Brodie et al., 8 May 2026).

Vulnerabilities

• OpenSSL Spy: If an attacker can preload a custom libcrypto.so wrapping critical cryptographic calls, plaintext messages, key material, and session keys can be exfiltrated directly from memory. DDS-Security does not by default validate the integrity of its cryptographic or plugin binaries at runtime (DiLuoffo et al., 2019).
• Credential Masquerade: Lack of property file integrity protection allows privilege escalation if an attacker can point security config files to rogue credentials and policies. No built-in runtime certificate-chain cross-check on governance/permissions loading (DiLuoffo et al., 2019).
• Handshake Context Leakage: The cleartext transmission of signed permissions tokens during handshake exposes fine-grained policy mapping to passive adversaries, enabling full topology inference and targeted attacks with minimal packet injection (White et al., 2019).
• Vendor SPI Implementation Bugs: Omitted partition checks or argument swaps in string pattern matching (fnmatch) may open covert channels or allow unauthorized access even when policies are set correctly (White et al., 2019).

Threat Models

• Passive Attacker: Network sniffer extracts $Cert_{ID}$ and $\Pi$ during handshake, reconstructs pub-sub graphs, infers reachability, targets minimal-cut selective DoS/partitioning (White et al., 2019).
• Active Attacker with Local Privilege: Exploits binary or property file integrity lapses to subvert plugin behavior, extract secrets, or hijack participant identity (DiLuoffo et al., 2019).
• Semantic (QoS/Policy) Attacker: Exploits misconfigurations in QoS.xml or rulesets to escalate access or amplify attacks (e.g., OWNERSHIP_STRENGTH, unbounded LIFESPAN, locator redirection) (Abaimov, 2021).

4. Performance and Empirical Evaluation

Multiple experimental studies have quantified the performance costs of DDS-Security at both system and submessage level:

Latency and Throughput

• Latency Overhead $(\Delta \ell)$: Measured as $$\Delta \ell = \ell_\mathrm{secure} - \ell_\mathrm{plaintext}$$, typically doubles upon enabling full SROS2 (DDS-Security) compared to plaintext; VPN-based protection yields lower overhead for two-node systems but requires centralization (Kim et al., 2018).
• Throughput Ratio $N_A$0: $N_A$1 falls to $N_A$2 (i.e., a 50% reduction) under full encryption; "Sign-only" configurations incur ~20% overhead (Kim et al., 2018, Brodie et al., 8 May 2026).
• Implementation Benchmarks (wired link, 16 B/4 KB packets) (Kim et al., 2018):

| Mode | Latency (ms) | Throughput (Mbps) | |-----------|--------------|-------------------| | Plaintext | 0.45–0.48 | 48–52 | | VPN | 0.80–0.85 | 45–50 | | SROS2 | 1.10–1.15 | 24–26 |

• Fine-Grained Evaluation: For best-effort transport, "Sign" reduces throughput to ~7,100 samples/sec, "Encrypt" to ~4,200 samples/sec on a 1 Gbps LAN (cf. >8,700 for unprotected) (Brodie et al., 8 May 2026).

Static Analysis and Compliance

• Detected bugs: misconfigured IV lengths (specification: 96 bits, implementation: 128 bits), non-standard random number generation (BN_rand vs NIST DRBG), memory management defects (uninitialized vars, missing frees).
• Forward secrecy gap: Use of static DH/ECDH keys in X.509 certificates means loss of secrecy if a long-term key is compromised. Use of DHE/ECDHE is recommended (Kim et al., 2018).

5. Attack Surface, Defense-in-Depth, and Formal Vulnerability Analysis

Attack Techniques

• Spy Library and Credential Masquerading: Achieves exfiltration of all on-wire protected content, including session keys, if library or config file integrity is not enforced by the OS/hardware root-of-trust (DiLuoffo et al., 2019).
• Passive Topology Enumeration: By parsing exposed $N_A$3 tokens, construct directed bipartite graphs of $N_A$4, then infer reachability and minimal cut-sets for selective DoS (White et al., 2019).
• QoS/Subtle Policy Attacks: QoS misconfigurations exploited for covert channel creation, session hijack, or volumetric DoS (Abaimov, 2021).

Defense Mechanisms

• OS/HW Anchoring: Use Trusted Boot & TPM (PCR-chain), IMA/EVM for runtime file measurement, code-signing on DDS plugins, and hardware-backed HSM for private key material. These detect or block rogue OpenSSL/plugin binaries and improper config changes (DiLuoffo et al., 2019).
• Policy Minimization: Minimal permissions in the permissions document, partition and topic isolation, and per-topic protection_kind settings (NONE/SIGN/ENCRYPT) reduce the attack surface (Brodie et al., 8 May 2026).
• Formal Methods: Use of model checkers (e.g., Imandra) to verify inferences of data-flow, reachability, and effect of policy modifications; formal enumeration of attack paths yields precise minimal-cut DoS/partitioning strategies and uncovers implementation bugs (White et al., 2019).

6. Tuning, Usability, Scalability, and Best Practices

Configurable trade-offs: Per-topic configuration of encryption/SIGNATURE/NONE, selection of BEST_EFFORT or RELIABLE QoS, and selective enforcement of access control can optimize between confidentiality, integrity, low latency, and system throughput for resource-constrained nodes or high-throughput scenarios (Brodie et al., 8 May 2026, Vilches et al., 2022).

CLI/API abstractions: Tools such as SROS2 automate keystore creation, policy artifact generation, and plugin loading, hiding boilerplate but imposing “all-or-nothing” encryption domains and manual certificate and policy management. Areas for improvement include dynamic policy reload, finer-grained cipher selections, lifecycle automation, and scalable multi-robot or fleet deployment (Vilches et al., 2022).

Measuring impact: Performance evaluation via standardized metrics (ΔL, R, ΔU) across varying message sizes and network topologies is necessary for application-specific tuning (Kim et al., 2018, Brodie et al., 8 May 2026).

Policy management: Governance and permissions XML files should be signed and integrity-protected, certificate-revocation and renewal must be planned, and policy distribution for large deployments must be automated (Vilches et al., 2022).

7. Security Monitoring, Intrusion Detection, and Remaining Gaps

• ML-based Approaches: Conventional intrusion detection systems (IDS) are ineffective on DDS traffic, which lacks recognizable signatures at the network layer. Deep-learning models (e.g., CNNs over flow metadata) can detect DoS with high recall, but struggle with stealthy or semantic attacks; however, privacy-preserving and IP-agnostic detection are limitations (Abaimov, 2021).
• Hybrid IDS and Static Checks: Augmentation of DDS plugins with flow analysis, periodic static code analysis (e.g., Cppcheck, ProVerif), and runtime monitoring of access violations is recommended.
• Unresolved Design Flaws: The handshake context leak (exposed $N_A$5) persists in DDS-Security v1.1; until an encrypted attestation exchange is introduced, topology leaks and passive reconnaissance remain feasible (White et al., 2019).

Summary Table – Empirical Overhead of DDS-Security (Kim et al., 2018, Brodie et al., 8 May 2026):

Protection	Latency Overhead	Throughput Reduction	Topology Requirement
VPN	~0.3–0.4 ms	~6–10%	Central server (star)
SROS2/DDS	~0.7–1.1 ms	~50%	Peer-to-peer (decentralized)

Best practices include enforcing secure-boot/TPM measurement, strict code- and policy-signing, session key rotation, per-topic security tailoring, and continuous integration of static and dynamic security analysis pipelines for DDS deployments.