Protecting Your Data Without Changing a Single Line of Code

RTI Connext DDS 5.3.0 is now live! I’m really excited to be back with a new blog post about one of the key new features of this release: the RTI Security Plugins. The reason I’m so excited about this one it is because this is our first release that is fully wire-compliant with the OMG DDS Security specification.

If you are looking for a high-level overview of OMG’s DDS Security specification, or you are wondering how can you can get started using it in your application, you are in the right place.

OMG DDS Security

One of the key values of Connext DDS -and the OMG DDS standard- is data-centricity. RTI Connext DDS is not just a pipe for bytes exchange, it is indeed a databus you can rely on to share your data among your applications in a controlled, effective, and efficient way.

The RTI Connext Databus gives you real control over what information your application is going to access. For instance, you can structure your data in different topics, so applications can select what data they are interested in, or even set up a content filter to make sure your applications only receive data that meets certain criteria. As an example, you could define a topic for patient monitoring, then configure Connext DDS to only deliver updates when a patient heart rate falls below a certain threshold.

Given its data-centricity, traditional security solutions -mostly focused on securing a pipeline for byte exchange- do not fit OMG DDS well. Moreover, using a pipeline requires one-to-one sessions between peers -no multicast-, so scalability is limited.

To address these issues, multiple vendors joined efforts and specified OMG DDS Security specification. This specification addresses the security aspect of the communication in a one-to-many friendly, data-centric way: instead of securing pipelines, it enables applications to define different security policies based on the nature of the shared data.

OMG DDS Security specification defines a set of built-in plugins for providing interoperable authentication, access control, cryptography, and a logging topic. RTI Security Plugins are the Connext DDS implementation of these OMG DDS Security built-in interoperability plugins. This way, the RTI Security Plugins offer a DDS Security solution that can interoperate with DDS implementations from other vendors.

RTI Security Plugins

RTI Security Plugins allow you to address your databus security requirements in a granular and pluggable way. As such, each of the RTI Security Plugins cover a different aspect of security:

• Authentication. Provides the means to verify the identity of the application and/or user that invokes operations on DDS. Includes facilities to perform mutual authentication between participants and establish a shared secret.
• AccessControl. Provides the means to enforce policy decisions on what DDS-related operations an authenticated user can perform. For example, which domains it can join, which topics it can publish or subscribe to, etc.
• Cryptography. Implements (or interfaces with libraries that implement) all cryptographic operations including encryption, decryption, hashing, digital signatures, etc. This includes the means to derive keys from a shared secret.
• Logging Service Plugin. Supports auditing of all DDS security-relevant events

After downloading and installing our security plugin bundles and OpenSSL support (using our video tutorials for Linux and PC installation), starting with RTI Security Plugins is easy. You can use the example certificates and security configuration files shipped with Connext DDS 5.3.0 under the following folder: 

EXAMPLE_DDS_SECURITY_FOLDER = “{rti_workspace}/5.3.0/examples/dds_security” 

To use security in your application, you just need to modify your application’s USER_QOS_PROFILES.xml file to include the following QoS profile (which relies on the example certificates and security configuration files mentioned above):

This profile inherits from the built-in BuiltinQosLib::Generic.Security profile to enable RTI Security Plugins in your participant, then it configures the following files:

1. ca_file: Identity certificate for the Certificate Authority (CA). Used to verify that other certificates are legit.
2. permissions_authority_file: Identity certificate for the Permissions Certificate Authority (Permissions CA). Used to verify that other certificates are legit.
3. certificate_file: Public Identity Certificate for the Participant. Signed by the CA.
4. private_key_file: Private Key for the Participant. Only known to the local participant, it is used during the authentication process.
5. governance_file: Governance file that specifies which domains should be secured and how. Signed by the Permissions CA.
6. permissions_file: Permissions file that specifies what domains/partitions the DomainParticipant can join and what topics it can read/write. Signed by the Permissions CA.

By using the profile described above, you are enabling security for your application according to the rules in the Governance and Permissions files. Governance and Permissions allow you to define the security requirements of your system in a data-centric way. Governance file defines how your system is protected, and Permissions file defines who can access what. Let’s have a closer look at what these two files offer.

Governance file defines two levels of configuration properties: domain, affecting participants in the domain; and topic, affecting endpoints from that topic.

Domain-level properties:

1. allow_unauthenticated_participants: Determines if it is allowed to match a participant that is not able to successfully complete the authentication process. By disallowing unauthenticated participants, we prevent them from neither publishing nor subscribing to topics in our system.
2. enable_join_access_control: Determines if the participant-level permissions configured in the Permissions file are enforced or not for local and remote participants.
3. discovery_protection_kind and liveliness_protection_kind: OMG DDS Security defines a new set of secure endpoint discovery and secure participant liveliness built-in topics. These properties determine what level of protection is applied to those built-in topics. Currently supported: ENCRYPT (encrypt & sign messages) / NONE.
4. rtps_protection_kind: Determines what level of protection is applied to RTPS messages. Currently supported: SIGN (sign messages) / NONE.

Topic-level properties:

1. enable_discovery_protection / enable_liveliness_protection: Determines if discovery information/liveliness updates related to endpoints from this topic will be sent through the secure built-in channels.
2. enable_read_access_control / enable_write_access_control: Determines if topic-level permissions configured in the Permissions file are enforced or not for local and remote readers/writers.
3. metadata_protection_kind: Determines what level of protection is applied to RTPS submessages from endpoints of the associated topic. Currently supported: ENCRYPT/NONE.
4. data_protection_kind: Determines what level of protection is applied to the serialized payload from endpoints of the associated topic. Currently supported: ENCRYPT/NONE.

This is an example of what a Governance file looks like:

The Governance file above defines just one configuration to be applied to any domain in the system. Consequently, all the domains and topics in the system are protected in the same way, in particular:

• Only authenticated participants are allowed in the system
• Permissions are checked for any matched and authenticated remote participant
• Secure endpoint discovery and liveliness are encrypted
• All RTPS messages in the system are signed

Then, this Governance defines different levels of protection depending on the topic to protect, such as the following:

• PatientMonitoring topic is access protected, submessages are encrypted, and discovery and liveliness are protected.
• The rest of the topics are not protected at all.

This way, only authenticated and authorized participants are allowed to join the system. Since RTPS messages are signed, only authenticated & authorized participants will be allowed to write messages to the system. Also, since the “PatientMonitoring” updates are sensitive, they are exchanged encrypted, so an eavesdropper will not be able to have access to that data.

We have been talking about how we want to protect our system, but what about who and what we allow in the system? That is the purpose of the Permissions file. Let’s take the following file as an example:

This Permissions file is configuring a grant for “ParticipantA”. In particular, this grant only allows “ParticipantA” (identified by its certificate) to publish and subscribe in domain 0 and partitions starting with “P”, and only in the topic “PatientMonitoring”.

As you can see, the combination of Governance and Permissions gives you full control over what, how, and who can publish and subscribe in your system. But not only that… you can do it while taking advantage of the full potential of the rest of the Connext DDS features, including multicast support. Moreover, RTI Security Plugins are wire-compliant with the OMG DDS Security specification, which makes it possible to interoperate with other DDS implementations!

I hope this post has helped you realize the potential that the RTI Security Plugins have and the impact they can make in your system. This is just a sneak peak though! For more information about all of the features in our Security Plugins, please refer to our Connext DDS 5.3.0 RTI Security Plugins Getting Started Guide.