6.3. What’s New in 7.1.0
This section describes what’s new, compared to the RTI Security Plugins 7.0.0.
6.3.1. Changes Related to Dynamic Participant Renewal, Revocation, and Expiration
6.3.1.1. Support for notification when the Local Participant’s own certificate is about to expire
During DomainParticipant creation, the Builtin Security Plugins check that the desired certificate is currently valid, as described in Verifying the certificate validity on the current date and time in the RTI Security Plugins User’s Manual. When the certificate is about to expire, you may want to be notified so that you can replace the certificate with one that expires later. In this release, the Builtin Security Plugins do not yet support replacing the certificate, but they do support the notification mechanism, which is a DomainParticipantListener callback function combined with a property that configures how much advance notice you want.
For more information, see Dynamic Certificate Expiration of the Local DomainParticipant in the RTI Security Plugins User’s Manual.
6.3.1.2. Support for kicking Remote Participants off a system because of an expired certificate
As described in Verifying the certificate validity on the current date and time in the RTI Security Plugins User’s Manual, when mutually authenticating with a remote DomainParticipant, the local DomainParticipant checks that the remote DomainParticipant’s certificate is currently valid.
If the certificate is currently valid but later becomes expired, the local DomainParticipant may want to stop communicating with the remote DomainParticipant. In this release, the Builtin Security Plugins now support this behavior.
When the certificate expires, the local DomainParticipant will automatically and immediately remove the remote DomainParticipant and, if Key Revisions are enabled, it will regenerate and redistribute key material.
For more information, see Dynamic Certificate Expiration of Remote DomainParticipants in the RTI Security Plugins User’s Manual.
6.3.2. Changes Related to Cryptography
6.3.2.1. Pre-Shared Key-based RTPS protection mechanism
This release introduces a new Pre-Shared Key-based RTPS protection mechanism, “RTPS PSK Protection.” This is a Cryptography Plugin mechanism that supports basic communication protection, based on a pre-shared key that is distributed out-of-band to DomainParticipants.
RTPS PSK Protection does not require authentication. Consequently, it does not support more sophisticated security features such as granular-security and topic permissions enforcement. RTPS PSK Protection offers metadata and data protection on the wire and restricts communication to only participants holding the pre-shared, user-configurable key.
RTPS PSK Protection can be leveraged in two different ways:
As part of the Builtin Security Plugins: RTPS PSK Protection works alongside existing Builtin Security Plugins features and secures the communication that occurs before two participants authenticate each other.
As part of Lightweight Builtin Security Plugins: In this case, all traditional DDS Security mechanisms are disabled and the entire communication is protected with RTPS PSK Protection.
6.3.2.2. Support for Additional Authenticated Data (AAD) when using RTPS protection
If AAD is enabled, the RTPS Header and Header Extension (if present) submessages are passed as additional authenticated data to the encode AES operations. This means that the Security Plugins will check the integrity of those headers. In previous releases, the Security Plugins checked for the integrity of the RTPS Header in a different way. The main benefit of enabling AAD is that it reduces the size of the RTPS messages that we send on the wire.
If AAD is disabled, the Security Plugins behave as previously. The plugins include an INFO_SRC submessage (20 Bytes) right after the Header of the RTPS message. This submessage is protected (along with the others) using the algorithm given by the com.rti.serv.secure.cryptography.encryption_algorithm property. Doing so protects the integrity of the header data, at the expense of a few extra bytes on the wire.
AAD is disabled by default. You can enable it with the com.rti.serv.secure.cryptography.enable_additional_authenticated_data boolean property. The property must be TRUE if you are enabling the RTPS 2.5 Header Extension.
6.3.3. Changes Related to Performance and Scalability
6.3.3.1. RTI Lightweight Security
This release of the Security Plugins introduces Lightweight Security, a lightweight solution that uses a pre-shared key (distributed out-of-band) to protect the information. This new feature can be used with the OpenSSL 1, OpenSSL 3, and wolfSSL crypto libraries. The new library, nddslightweightsecurity, is included with the Security Plugins bundles.
Using pre-shared key protection, we can protect the confidentiality or integrity of the communication, without the overhead of authentication, key exchange, and enforcing permissions. Therefore, the RTI Lightweight Security library can be useful in resource-constrained scenarios.
The Lightweight Security library does not use the most demanding (CPU and memory wise) DDS Security mechanisms like authentication or access control. As a consequence of this, RTI Lightweight Security does not support more sophisticated security features like granular-security and topic permissions enforcement: it only protects against spoofing, tampering, and information disclosure from actors not holding the pre-shared, user-configurable key.
In this version of the Security Plugins, secure DomainParticipants skip authentication and access control. Instead, security is based on a per-participant, pre-shared key that protects all messages (including discovery). The Security Plugins derive the per-participant pre-shared key based on a seed that the user must set consistently across the whole system. The property for configuring the seed is com.rti.serv.secure.cryptography.rtps_protection_preshared_key. The entire communication is protected by default using the AES256+GCM cryptographic algorithm. You can choose another algorithm with the com.rti.serv.secure.cryptography.rtps_protection_preshared_key_algorithm property. The available options are AES128+GCM, AES256+GCM, AES128+GMAC, and AES256+GMAC.
Note that DomainParticipants from the Lightweight Builtin Security Plugins library are not interoperable with those from the Builtin Security Plugins library (nddssecurity).
For more information, see Lightweight Security in the RTI Security Plugins User’s Manual.
6.3.4. Changes Related to APIs
6.3.4.1. Information from the Trust Plugins added to builtin topic data in Java API
The ParticipantBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData entities contain two new fields with data from the Trust Plugins:
trust_algorithm_info has the algorithms associated with the discovered DomainParticipant.
trust_protection_info has data that is dependent on the Trust Plugins implementation.
Connext 7.0.0 introduced these two fields in the C, traditional C++, and modern C+ APIs. Connext 7.1.0 added these fields to the Java API.
For more information, see Relevant Connext APIs in the RTI Security Plugins User’s Manual. The section on the discovered_participant_data API describes these types and includes some relevant links.
6.3.4.2. Changes to Trust APIs to match future DDS Security specification with respect to Security Algorithm Info and Security Protection Info
This release updates several of the types introduced in Connext 7.0.0, to match the OMG DDS Security 1.2 specification (pending publication). In particular, the wire representation and user-level API types associated with Cryptographic Algorithms configuration (Trust Algorithms Info, Security Algorithm Info) have been updated. The user-level API types associated with the Security Plugins configuration (Trust Protection Info, Security Protection Info) have also been updated.
For more information, see:
Relevant Types for the Governance Document in the RTI Security Plugins User’s Manual
Relevant Types for the Security Algorithms in the RTI Security Plugins User’s Manual
6.3.5. Changes Related to Usability
6.3.6. Changes Related to Debuggability
6.3.6.1. Adjusted verbosity of several security event logged messages
This release updates the verbosity level of several security event logged messages. In particular, security event logged messages now follow this schema:
DDS_LOGGING_EMERGENCY_LEVEL: Used to log fatal error conditions that prevent Security Plugins from continuing to run properly.
DDS_LOGGING_ALERT_LEVEL: Used to log security alerts. Usually derived from a remote peer not being properly configured or being malicious.
DDS_LOGGING_CRITICAL_LEVEL: Used to log critical, unexpected errors. In most cases, these errors will be triggered by the local host running out of resources. While the Security Plugins can continue operating, it is likely that new errors will continue to be triggered.
DDS_LOGGING_ERROR_LEVEL: Used to log error conditions.
Higher verbosity levels: Used to log non-error conditions, from warnings to informative messages.
6.3.7. Changes Related to Third-Party Software
6.3.7.1. Upgraded OpenSSL to versions 1.1.1t and 3.0.8
The following third-party software, used by the Security Plugins, has been upgraded:
Third-party Tool |
Old Version |
New Version |
|---|---|---|
OpenSSL |
1.1.1n |
1.1.1t 3.0.8 |
The Security Plugins now support the latest LTS version of OpenSSL (OpenSSL 3.0). In this release, the Security Plugins are available as both a set of nddssecurity libraries built against OpenSSL 1.1.1t (supported until September 2023) and a set of nddssecurity libraries built against OpenSSL 3.0.8 (supported until September 2026).
OpenSSL 3.0 has replaced the Engine API with the Provider API (see https://www.openssl.org/docs/man3.0/man7/migration_guide.html and search for the ‘Engines and “METHOD” APIs’ section).
If you are using OpenSSL Engines (see Support for OpenSSL Engines in the RTI Security Plugins User’s Manual), please note that the Security Plugins 7.1.0 do not support providers (see https://www.openssl.org/docs/man3.0/man7/provider.html), but the Security Plugins 7.3.0 do support providers.
See the Migration Guide on the RTI Community Portal (https://community.rti.com/documentation) for migration issues related to this upgrade.
6.3.7.2. Upgraded to wolfSSL 5.5.1
The Security Plugins for wolfSSL are now based on, and API-compatible with, wolfSSL version 5.5.1 (no earlier versions).
For this release, the Security Plugins for wolfSSL have only been tested by RTI using wolfSSL 5.5.1.
6.3.8. Changes Related to System Extensibility and Configurability
6.3.8.1. Deprecated properties related to the propagation of security info
Communication between DataWriters and DataReaders using inconsistent Governance Topic-Level Rules is not compliant with the DDS Security Specification.
Likewise, configuring DomainParticipants within the same domain with inconsistent Governance Domain-Level Rules is also not compliant with the DDS Security Specification.
Both of these scenarios can make the system more vulnerable to attackers. Therefore the following properties have been deprecated:
dds.participant.discovery_config.disable_endpoint_security_info_propagation
dds.participant.discovery_config.disable_participant_security_info_propagation
Support for these properties may be removed in future versions of the Security Plugins. Using these properties is highly discouraged.
6.3.9. Changes Related to Supported Platforms
6.3.9.1. New Platforms
This release adds support for this platform:
Red Hat® Enterprise Linux® 9 on x64 (x64Linux4gcc7.3.0)
6.3.9.2. Removed Platforms
The following platforms are no longer supported:
macOS® 10.13, 10.14, 10.15
VxWorks® 21.11
6.3.10. Changes Related to Shipped Examples
6.3.10.1. Support building shipped examples using different crypto libraries
This release adds supports for compiling the security shipped examples (the C, C++ and Java hello_security examples, and the hello_banish C example) using any of the available crypto libraries (OpenSSL 3.0, OpenSSL 1.1.1, or wolfSSL 5.5). Use the crypto library matching your installation of the Security Plugins.
The examples for Windows® systems now include new build modes, so that you choose the crypto library.
On Linux and macOS systems, you can indicate the crypto library as a parameter of the make command when compiling the example. Please see the hello_security READ_ME.txt files for more details.
6.3.10.2. Security examples now support secp384r1 curve
The hello_security examples now accept “p384” as the third command-line argument, whereas they previously only accepted the “rsa” value. The publisher or subscriber application will create a DomainParticipant that uses ECDHE-CEUM+P384 for key establishment and ECDSA+P384+SHA384 for digital signatures. For examples of commands to generate ECDSA secp384r1 certificates, see the Hands-on 4 in the RTI Security Plugins Getting Started Guide.
6.3.10.3. New example for banishing participants
There is a new C example that demonstrates how to use:
DDS_DomainParticipant_get_discovered_participant_subject_name()
DDS_DomainParticipant_get_discovered_participants_from_subject_name()
DDS_DomainParticipant_banish_ignored_participants()
You can find the example in <path to examples>/connext_dds/c/hello_banish. See Relevant Connext APIs in the RTI Security Plugins User’s Manual for more information.
6.3.11. Other Changes
6.3.11.1. Redaction of sensitive properties when logging DDS ‘Entities’ PropertyQos configuration
Connext has the ability to log the DDS Entity QoS configuration when a DDS Entity is created and when the DDS Entity QoS is set. The logged information includes all the Entity’s PropertyQos properties that have non-default values.
This release now redacts the values of sensitive properties (for example, those containing cryptographic keys) before they are output to the log. For example, logging the dds.sec.auth.private_key property will result in the following output:
...
<element>
<name>dds.sec.auth.private_key</name>
<value>[redacted]</value>
</element>
...
Connext considers as sensitive any property that ends with any of the following suffixes:
“.cryptography.key”
“.internal_license_string”
“.internal_license_validation”
“.key_material_key”
“.license_file”
“.license_string”
“.participant_discovery_protection_key”
“.password”
“.private_key”
“.private_key_file”
“.private_key_password”
“.rsa_private_key”
“.rsa_private_key_file”
“.rtps_protection_key”
“.rtps_protection_preshared_key”