By now, you might have read about the OMG DDS Security Specification which enhances the existing DDS standard with a security architecture and model. Version 1.0 of that specification is about to be finalized by the OMG. This means that a data-centric security model will now be natively integrated into the DDS standard – the only open communications standard that was designed to deliver the flexibility, reliability and speed necessary to build complex real-time applications, including many types of Industrial IoT systems.
One of the striking features introduced in DDS Security Spec is the notion of a Service Plugin Interface (SPI) architecture. The mechanism of SPIs allows users to customize the behavior and technologies that the DDS implementation uses for Information Assurance, without changes to the application code.
This blog post briefly explains the SPI architecture and demonstrates an easy way to leverage the RTI Connext DDS Secure built-in security plugins to have them execute selected cryptographic actions with the cryptography library of your choice.
DDS Secure Service Plugin Interfaces (SPIs)
The DDS Security Specification does not introduce any changes in the way applications interact with the DDS infrastructure. Instead, it defines five different plugin components that are leveraged by the infrastructure when needed. Each of those components provides a certain aspect of the Information Assurance functionality and has a standardized interface, as defined by the DDS Security Specification. This is what the name Service Plugin Interfaces (SPIs) refers to. The plugin architecture is illustrated in the image below.
As you can see, there are five SPIs that collectively provide Information Assurance to DDS systems. Their names and purposes are as follows:
|SPI Name||Purpose of its types and operations|
|Authentication||Support verification of the identity of DDS DomainParticipants, including facilities to perform mutual authentication and to establish shared secrets.|
|AccessControl||Make decisions on what protected DDS-related operations an authenticated DDS DomainParticipant is allowed to perform, including joining of a DDS Domain and creating Topics, DataReaders and DataWriters.|
|Cryptography||Support cryptographic operations, including encryption and decryption, hashing, digital signatures and message authentication codes.|
|Logging||Support logging of security-related events for a DDS DomainParticipant.|
|Data Tagging||Provide the ability to add a security label or tag to data, for application-specific purposes.|
The SPI-architecture gives you a lot of freedom to customize the Information Assurance aspects of your secure DDS system. All aspects mentioned in the above bullet list can be modified or re-implemented by using your own implementation of the SPIs. What you can not change, is the mechanism when the DDS implementation actually invokes the methods of the SPIs — they just get invoked when necessary. This is actually a good thing because it means that the middleware continues to behave as prescribed in the specification and you do not have to worry about breaking that.
In addition to the interfaces of the SPIs, the DDS Security specification also provides a functional description of the so-called builtin plugins, described in detail in Chapter 9 of that document. Their primary intention is to provide out-of-the-box interoperability between different implementations of DDS Security. With RTI Connext Secure DDS, the builtin plugins also happen to be an excellent starting point for customization.
Customizing the RTI Connext DDS Secure builtin plugins
The builtin security plugin binaries shipped with Connext DDS Secure can be used out-of-the-box to create your DDS system that includes Information Assurance. All you need to do is properly configure the PropertyQosPolicy of your DomainParticipant as explained in the specification to point to the desired security artifacts like access control and governance configuration files as well as identity certificates, among others.
For those who wish to modify the behavior of the plugins, a set of buildable source code files is provided as well. However, for many situations, the Connext DDS Secure plugins offer a much easier option. Enter the OpenSSL EVP API…
Swapping out cryptographic algorithm implementations
The builtin Connext DDS Secure plugins source code makes use of the OpenSSL cryptographic library — not for its SSL or TLS functionality, but for its set of cryptographic function implementations and a number of helper classes used with those. If you are familiar with OpenSSL programming, you will know that it is good practice to leverage the so-called EVP interface. (In case you are wondering about it, like I did: EVP stands for EnVeloPe.) The Connext DDS Secure plugins invoke a subset of its functions, namely those related to the items in the table below:
|Functionality||Algorithms specified for builtin DDS Security plugins|
|Symmetric encryption and decryption||AES in Galois Counter Mode (GCM) for 128-bits or 256-bits key sizes|
|Signing and verifying||RSA-PSS or ECDSA signature algorithms with SHA-256 as their hash function|
|Key exchange||Diffie-Hellman using modular arithmetic (DH) or elliptic curves (ECDH), with specified parameters|
|Message authentication codes||HMAC, with with SHA-256 as its hash function, and GMAC|
|Secure hash functions||SHA-256|
|Random number generation||Any cryptographically-strong random number generator|
The plugins shipped with the product use the OpenSSL implementations of these functions, as found in the standard OpenSSL EVP engine. However, they also support inserting your own engine. Your OpenSSL engine implementation could invoke other implementations of these cryptographic functions, for example leveraging the cryptographic library of your choice, maybe because you are required to use FIPS-compliant implementations. Some libraries already support an EVP engine, in which case you only have to configure the plugins. Otherwise, you will have to write a shim layer that invokes the right functions from your library.
Modifying the builtin plugins themselves
It might happen that the algorithms and mechanisms in the builtin plugins, outlined in the previous section, do not meet the needs of your project. In that case, you will have to resort to making modifications to the code of the actual plugins, the code that invokes the EVP functions. For example, you can make small modifications like selecting different algorithms than those defined by the specification, possibly using different key sizes or algorithm parameters. As another example, you can change from dynamic to static linking if you prefer.
It is possible to go beyond minor changes and, for example, introduce an entirely different identity authentication mechanism. Going down that path becomes complicated pretty quickly and we strongly recommend contacting us to discuss your needs and plans. We are looking forward to engaging with you!