1. Introduction to RTI Security Plugins

Prerequisites	RTI Connext® installed, including SDK (see the RTI Connext Installation Guide) RTI Security Plugins installed (see the Security Plugins Installation Guide) Familiarity with Connext (i.e., you’ve completed Introduction to Publish/Subscribe) Familiarity with Connext tools, such as RTI Administration Console Familiarity with security concepts and techniques (digital certificates, public key infrastructure, private/public key pairs, authentication, encryption, etc.) Familiarity with defining QoS profiles to Connext applications in XML format
Time to complete	2 hours
Concepts covered in this document	Introduction to DDS Security and RTI Security Plugins Enabling Security Plugins in your Connext applications Dynamic linking against RTI Security Plugins and OpenSSL Translating the security requirements of your system to a Governance Document Publishing/Subscribing with different protection kinds (authentication, encryption, etc.) Authenticating your applications with custom digital certificates and private keys Defining privileges for your applications with Permissions Documents

RTI Security Plugins allow you to address your databus security requirements in a granular and pluggable way. To support this, each of the Security Plugins covers 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 DomainParticipants and establish a shared secret.

• Access Control. Provides the means to enforce policy decisions on what DDS-related operations an authenticated entity 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. Supports auditing of all DDS security-relevant events.

The OMG DDS Security specification <https://www.omg.org/spec/DDS-SECURITY/> defines a set of builtin plugins for providing interoperable authentication, access control, cryptography, and a logging Topic. The Security Plugins are the Connext implementation of these OMG DDS Security builtin interoperability plugins. This way, the Security Plugins offer a DDS Security solution that can interoperate with DDS implementations from other vendors.

Figure 1.1 Architecture of an application using Security Plugins. All the currently available security plugins (Authentication, Access Control, Cryptography and Logging) are implemented in a single nddssecurity library.

1.1. Key Features

• The OMG DDS Security specification decouples the different security aspects in a set of plugins:

  • Authentication: Ensures that DDS entities are authenticated.

  • Access Control: Enforces access control for Domains, Topics, etc.

  • Cryptography: Maintains data integrity and confidentiality.

  • Logging: Supports auditing of all DDS security-relevant events, allowing you to increase the system’s visibility, which may help track and improve system’s availability.

• The Security Plugins can potentially run over any transport, including the builtin UDP transport with multicast and TCP transport.

• Secure multicast support enables efficient and scalable distribution of data to many Subscribers.

• You can customize the Security Plugins to accommodate proprietary or FIPS 140-2 compliant cryptography solutions, take advantage of custom security hardware or change the behavior of the plugins in any number of ways. The Security Plugins SDK enables you to customize the Security Plugins to meet your system’s security requirements.

• The OMG DDS Security specification addresses the security aspect of the communication in a one-to-many, friendly, data-centric way, enabling applications to define different security policies based on the nature of the shared data. This aligns with the decentralized nature of DDS and asserts its benefits:

  • No single point of failure

  • High performance and scalability

• The Security Plugins support all of the cryptographic algorithms specified by the OMG DDS Security specification. For more information about the supported algorithms, refer to Supported Cryptographic Algorithms in the Security Plugins User’s Manual.

1.2. Paths Mentioned in Documentation

This documentation refers to the following directories, depending on your operating system:

LinuxmacOSWindows

• $NDDSHOME This refers to the installation directory for Connext.

  The default installation paths are:

  • Non-root user:

    /home/<your user name>/rti_connext_dds-<version>

  • Root user:

    /opt/rti_connext_dds-<version>

  $NDDSHOME is an environment variable set to the installation path.

• <path to examples> By default, examples are copied into your home directory the first time you run RTI Launcher or any script in $NDDSHOME/bin. This document refers to the location of the copied examples as <path to examples>.

  Wherever you see <path to examples>, replace it with the appropriate path.

  Default path to the examples:

  /home/<your user name>/rti_workspace/<version>/examples

Sometimes this documentation uses <NDDSHOME> to refer to the installation path. Whenever you see <NDDSHOME> used in a path, replace it with $NDDSHOME for Linux or macOS, with %NDDSHOME% for Windows, or with your installation path.