Secure Your IIoT System with Custom Cryptography Libraries

The OMG DDS Security Specification is advancing to Version 1.0, bringing a native data‑centric security model into the DDS standard. This evolution empowers Industrial IoT (IIoT) solutions with the flexibility, reliability, and real‑time performance that DDS already offers.

A standout feature of the specification is the Service Plugin Interface (SPI) architecture. SPIs let you tailor the security mechanisms—authentication, access control, cryptography, logging, and data tagging—without modifying your application code.

This article explains the SPI framework and shows how to configure RTI Connext DDS Secure’s built‑in plugins to delegate cryptographic operations to the library of your choice.

DDS Secure Service Plugin Interfaces (SPIs)

The DDS Security Specification does not alter the application API. Instead, it defines five plug‑in components that the DDS middleware invokes as needed. These plug‑ins provide distinct information‑assurance functions through standardized interfaces.

The five SPIs are:

The SPI architecture offers extensive customization of each security aspect. While you can replace any SPI implementation, the timing of SPI invocations remains governed by the DDS middleware, ensuring compliance with the specification.

Built‑in plugins described in Chapter 9 of the specification provide seamless interoperability across DDS implementations. RTI Connext DDS Secure ships with these plugins and a straightforward path for customization.

Customizing the RTI Connext DDS Secure Built‑In Plugins

The bundled security plugin binaries enable immediate deployment of a secure DDS system. Configure your DomainParticipant’s PropertyQosPolicy to point to the required security artifacts—access control files, governance documents, and identity certificates—per the specification.

If deeper modification is needed, RTI supplies buildable source files. For most scenarios, however, leveraging the OpenSSL EVP API offers a simpler solution.

Swapping Out Cryptographic Algorithm Implementations

The built‑in plugins use OpenSSL’s EVP engine for cryptographic functions, but they allow you to inject a custom engine. Your engine can redirect calls to a FIPS‑compliant library or any other cryptographic provider that supports the EVP interface.

The functions exposed by the plugins include:

To use a different cryptographic provider, either configure the plugin to load your EVP engine or implement a shim that forwards calls to your library.

Modifying the Built‑In Plugins Themselves

If the default algorithms or parameters do not meet your requirements, you can alter the plugin source code. Common changes include selecting alternative algorithms, adjusting key sizes, or switching from dynamic to static linking.

For more extensive customizations—such as a new identity authentication scheme—consult with RTI experts to ensure that your modifications remain compatible with the DDS Security Specification.