Using Connext DDS Secure 6.0 to Protect your Data

**Please note that with the April 2024 release of Connext Professional 7.3 LTS, the functionalities formerly comprising Connext Secure are now available as an optional component to Connext Professional, named Security Extensions. 

If enforcing system-wide security has turned into an elaborate puzzle, I’m pleased to share that we have the answer! RTI Connext DDS Secure 6.0 introduces a robust set of security capabilities to your system, including authentication, encryption, access control and logging. And thanks to its support of secure multicast, Connext DDS Secure 6.0 also enables efficient and scalable distribution of data to many subscribers. That’s data-centricity in action.

One of the advantages of Connext DDS Secure 6.0 over other non-data-centric solutions is that it provides fine-grained control over the level of security applied to each data flow. For an example of this approach, Figure 1 below illustrates what a data-centric autonomous car architecture would look like when based on Connext DDS Secure:

Figure 1. Autonomous Vehicle Data-Centric Architecture

Thanks to Connext DDS Secure, we can now architecturally break down messages based on criticality for safety or need for data integrity. In our example architecture, it would make sense to authenticate the data that originated from the vision, radar and LIDAR modules, as we want to ensure that data has not been modified by an external attacker. But for sensors that do not generate sensitive information, we would not need to use encryption for that data. However, we would definitely encrypt all of the messages exchanged between the fusion and the control modules as in our example, because they use a proprietary protocol and need to be protected them from intellectual property theft. Finally, we may decide to not protect the multimedia contents at all, as they are not sensitive.

In this blog entry, I will walk you through the different levels of encryption Connext DDS 6 supports - these are levels that allow you to build systems like the one described above. For our purposes today, I’m assuming you are familiar with basic Data Distribution Service™ (DDS) concepts. If not, I recommend reading a high-level overview on the DDS standard. 

A quick overview of the Real-Time Publish-Subscribe (RTPS) protocol

Connext DDS uses Real-Time Publish-Subscribe (RTPS) protocol to communicate over the wire, which ensure interoperability with other RTPS-compliant vendors. Some of the features of this protocol are:

• Rigorous identity, source and destination indication
• Sequence numbers for state recreation
• Content awareness for efficient delivery
• Timestamps for data and state integrity
• Efficient use of transports
• Proxy and routing support
• Reliability and synchronization handshaking

RTPS has two structural building pieces:

• RTPS message, which consists of a fixed-size leading RTPS Header, followed by a variable number of RTPS Submessage parts.
• RTPS submessage, which consists of a SubmessageHeader and a variable number of SubmessageElements. The SubmessageHeader contains a SubmessageKind that identifies the type of the submessage.

Figure 2. Basic structure of an RTPS message

An example of RTPS SubmessageKind would be DATA, a submessage used to encapsulate user data. However, most of the RTPS SubmessageKinds are focused on protocol metadata (e.g., exchanging reliability protocol information).

Ok, that’s all you need to know about RTPS to understand the basics of how Connext DDS Secure protection works on the wire. So let’s go for it!

Location of cryptographic protection in Connext DDS Secure

Figure 3. Location of the encryption

The authentication and encryption of the messages exchanged by Connext DDS Secure can happen at different levels:

• RTPS protection is a DomainParticipant-level protection that protects all of the content of RTPS messages (including all of their submessages) exchanged with remote peers. This kind of protection happens at wire serialization time, right before handling the data to the transport.
• RTPS submessage protection (also known as meta-data protection in the DDS Security specification) is a DataWriter/DataReader-level protection that protects all of the submessages generated by that entity. This kind of protection happens at wire serialization time, right before applying RTPS protection and handling the data to the transport.
• User data protection (also known as data protection in the DDS Security specification) is a DataWriter-level protection that protects the userdata (including the key, if available) which that user is passing through a DataWriter.write() call. This kind of protection happens only once, when the data is added to the DataWriter queue upon a call to write().

One huge advantage of using Connext DDS Secure - instead of a transport-based solution like Datagram Transport Layer Security (DTLS) - is that it will save CPU in scenarios with multiple subscribers, as it eliminates the need for multiple re-encryptions. This is because RTPS encryption happens only once before delivering the same message with multiple destinations to the transport. Even better: if the network supports multicast, the savings in CPU and network bandwidth will make a big difference in system scalability, as messages will also only need to be protected and delivered to the network stack once as well.

Figure 4. Connext DDS Secure vs DTLS

Connext DDS Secure protection kinds

For the different levels of protection described in the previous section, the OMG DDS Security 1.1 specification defines a set of protection kinds. Connext DDS Secure 6.0 support all of the OMG DDS Security 1.1 protection kinds, this was an upgrade with respect to 5.3, which only supported a subset:

Figure 5. Protection kinds support in Connext DDS Secure 6.0

The OMG DDS Security standard defines the protection kinds as follows:

• NONE indicates that no cryptographic transformation is applied.
• SIGN indicates that the cryptographic transformation is purely a Galois message authentication code (GMAC). No encryption is performed, as such, this one provides authentication and integrity protection against outsiders, but not confidentiality. The GMAC is placed after the content. If the receiver finds a missing or incorrect GMAC, the receiver will reject the content.
• ENCRYPT indicates that the cryptographic transformation is an AES encryption followed by a GMAC computed on the ciphertext, also known as Galois/Counter Mode (GCM). This protection kind therefore provides confidentiality against outsiders (in addition to the authentication and integrity properties already present in SIGN protection). The GMAC is placed after the content. If the receiver finds a missing or incorrect GMAC, the receiver will reject the content.
• WITH_ORIGIN_AUTHENTICATION protection kinds. There are two protection kinds that have WITH_ORIGIN_AUTHENTICATION in their names. These protection kinds provide protection against malicious insiders. WITH_ORIGIN_AUTHENTICATION indicates that in addition to using the sender’s key to generate a common GMAC, the sender generates receiver-specific GMACs using keys that are specific to individual sender-receiver pairs. The additional GMACs are placed after the common GMAC. They prove to the receiver that the sender originated the message, preventing other receivers from impersonating the sender. If the receiver finds a missing or incorrect common GMAC, the receiver will reject the content. If the receiver finds a missing or incorrect receiver-specific GMAC that was computed using its own receiver-specific key, the receiver will reject the content.

The WITH_ORIGIN_AUTHENTICATION protection kinds are as follows:

• SIGN_WITH_ORIGIN_AUTHENTICATION indicates that a common GMAC is performed on the content, and receiver-specific GMACs are performed on the common GMAC.
• ENCRYPT_WITH_ORIGIN_AUTHENTICATION indicates that a GCM is performed on the content, and receiver-specific GMACs are performed on the GMAC of the GCM.

Using different protection levels (RTPS submessage, user-data) and protection kinds (encrypt, sign, origin-authentication) you are in full control to do fine-grained protection of your data. If you want more information about how these protections work, please refer to the OMG DDS Security 1.1. specification. Or even better, you can watch the replay of our December 3, 2019 On-Demand Tech Talk webinar.

About the author

Jose Lopez-Vega is currently the lead for the RTI Connext DDS Secure product. He has been an active contributor of the latest OMG DDS Security 1.1 specification. His technical expertise spans large-scale real-time distributed systems, security, and network protocols.
He holds a PhD on Multimedia Systems, and masters in Multimedia Technologies, and in Telecommunications Engineering from the University of Granada.