6.1. What’s New in 7.3.0

Security Plugins 7.3.0 is the first release in the 7.3 long-term support (LTS) series. It is built upon and includes all the features in releases 7.0.0, 7.1.0, and 7.2.0 (see Previous Releases).

This section describes new features and improvements in 7.3.0 compared to 7.2.0.

6.1.1. Pre-Shared Key Protection and Lightweight Security

6.1.1.1. Pre-Shared Key Protection is compliant with OMG DDS Security 1.2 standard.

Pre-Shared Key Protection, in both the Builtin Security Plugins and the Lightweight Builtin Security Plugins, now meets the OMG DDS Security 1.2 standard. Changes span from renaming related properties to wire interoperability. See the Migration Guide on the RTI Community Portal.

6.1.1.2. Update to sender’s key identifier used for pre-shared key derivation

The Security Plugins derive Pre-Shared keys from a combination of the secret key seed and some publicly available data. Among this publicly available data is the sender’s key identifier. In previous releases, this value was equal to the DomainId. Starting in 7.3.0, the Security Plugins derive the sender’s key identifier not only from the DomainId but also from the DomainTag. For more information, see How Pre-Shared Key Protection Works, in the RTI Security Plugins User’s Manual.

6.1.1.3. New properties for configuring Pre-Shared Key protection

This release introduces two properties for configuring pre-shared key protection in the Builtin Security Plugins and the Lightweight Builtin Security Plugins. These properties are in the Cryptography plugin (prefix with dds.sec.crypto.):

• rtps_psk_symmetric_cipher_algorithm

• rtps_psk_secret_passphrase

There is also a new property in the Access Control plugin (prefix with dds.sec.access.) that you can use in the Lightweight Builtin Security Plugins:

• rtps_psk_protection_kind

For more information, see Configuring Pre-Shared Key protection, in the RTI Security Plugins User’s Manual and the Migration Guide, on the RTI Community Portal.

6.1.1.4. Pre-Shared Key seed can be provided in a file

The dds.sec.crypto.rtps_psk_secret_passphrase (previously named cryptography.rtps_protection_preshared_key) property now supports the following two input formats:

• data:,<ID>:<SEED> allows you to provide the PSK seed explicitly in the property value.

  • <ID> is an integer [0, 254] that identifies the current seed within the system.

  • <SEED> is a string used to derive (in combination with publicly available data) the key used for encoding RTPS messages.

• file:<FILENAME> allows you to provide the seed in a supplemental file. The file can be optionally tracked by the Security Plugins (via the files_poll_interval property, enabled by default) for changes that are automatically incorporated into present operations.

  • <FILENAME> is the path to a file containing the PSK seed. The content of the file must use the <ID>:<SEED> format.

6.1.2. New Algorithms

6.1.2.1. Compliance with DDS Security 1.2 Specification regarding cryptographic algorithms

This release of the Security Plugins introduces several updates to comply with the DDS Security 1.2 Specification.

It includes changes to conform to naming, such as the addition of the dds.sec.crypto.symmetric_cipher_algorithm property and the rtps_psk_protection_kind Governance Document XML tag. There are updates to the expected behavior during discovery, such as not serializing the last algorithms if they have the default values, or only checking compatibility of the DomainParticipant symmetric cipher algorithms if they have protection enabled at the RTPS message level. This release also changes the values that identify several algorithms (custom ones, like AES192+GCM, and experimental ones, like ECDHE-CEUM+X25519) on the wire.

For more information, see Cryptographic Algorithms, in the RTI Security Plugins User’s Manual.

6.1.2.2. New mask in Parameter ID indicates the default algorithm that endpoints use to protect data

The Parameter ID of the DomainParticipant’s symmetric cipher algorithm information (PID_ENDPOINT_SECURITY_SYMMETRIC_CIPHER_ALGO) used to have three masks: supported_mask, builtin_endpoints_required_mask, and builtin_kx_endpoints_required_mask. This release introduces an additional one, user_endpoints_default_required_mask. The value of this mask indicates the default algorithm that the endpoints of the DomainParticipant use to protect user data traffic (unless the endpoint doesn’t specify directly the algorithm to use).

The Security Plugins will not consider this mask when deciding if two DomainParticipants are compatible.

6.1.2.3. Changes in serialization of cryptographic algorithms

During discovery, DomainParticipants may propagate information about the cryptographic algorithms that they require or support. DomainParticipants propagate this information when they are configured with non-default cryptographic algorithms. Starting in this release, the Security Plugins will skip serialization of the last cryptographic algorithms in a PID (Parameter ID) if they have the default values.

6.1.3. Extensibility and Usability

6.1.3.1. Security Plugins now support OpenSSL providers

The OpenSSL default implementations of security algorithms may not meet the needs of every security application. As described in https://www.openssl.org/docs/man3.0/man7/provider.html , OpenSSL providers are a way of loading alternative implementations of algorithms. The Security Plugins now support OpenSSL providers, which are the OpenSSL 3.0 replacement for the OpenSSL 1.1.1 Engine API (see https://www.openssl.org/docs/man3.0/man7/migration_guide.html and search for the ‘Engines and “METHOD” APIs’ section). To use an OpenSSL provider with a Security Plugins application, you must use an OpenSSL configuration file to specify the providers you want to load, as described in https://www.openssl.org/docs/man3.0/man5/config.html, and you must set the appropriate environment variables. Then the Security Plugins will perform the following actions:

• Log, at a higher verbosity level, which providers are loaded and activated.

• Adjust the DomainParticipant discovery data based on which algorithms your providers support.

• Use your providers for security operations.

One example of a provider is the OpenSSL FIPS provider, described in https://www.openssl.org/docs/man3.0/man7/fips_module.html. RTI has tested that the OpenSSL FIPS provider works seamlessly with the Security Plugins, with the only caveat being that the FIPS provider does not support the DHE-MODP+2048+256 Key Establishment Algorithm.

See Support for OpenSSL Providers, in the Security Plugins User’s Manual for more information.

6.1.3.2. Ability to send security events to logging aggregator backend with RTI Observability Framework

Now you can use RTI Monitoring Library 2.0 to forward security events logged by the Security Plugins’ Logging plugin to RTI Observability Collector Service. The service will store the security events in a logging aggregator backend, such as Grafana® Loki®. Then you can use the message visualization and query functionalities offered by the aggregator backend and Grafana Dashboards.

For more information, see:

• Support for RTI Observability Framework, in the RTI Security Plugins User’s Manual

• RTI Connext Observability Framework User’s Manual

6.1.3.3. Improved format of Security Plugins SDK documentation

The Security Plugins SDK documentation used to be located inside the RTI_SecurityPlugins_BuildableSourceCode_Instructions.txt file of the root directory. This file contained instructions on how to build the SDK and run the tests, as well as API changes between releases. This information is now part of the new HTML documentation shipped with the Security Plugins SDK under doc/html (start by opening the index.html landing page). The new documentation shares the look and feel of RTI’s other API documentation pages.

6.1.3.4. Reduced severity of benign log message related to ParticipantCryptoTokens

When using a Governance Document whose rtps_protection_kind is a value other than NONE, you may see a benign log message containing PRESParticipant_processParticipantCryptoTokens. This log message raises awareness of an automatically recoverable situation. Therefore, the NDDS_Config_LogLevel of the log message has been adjusted from NDDS_CONFIG_LOG_LEVEL_ERROR to NDDS_CONFIG_LOG_LEVEL_STATUS_REMOTE.

6.1.3.5. Deprecated property related to payload encoding alignment

The property dds.data_writer.history.use_530_encoding_alignment was introduced in Security Plugins 6.0.0 in order to mimic 5.3.0 behavior on the sending side of payload protection. However, this behavior does not impact backward interoperability with 5.3.0. The receiving side of payload protection can process 4-byte-aligned and unaligned protected payloads equally well. Therefore, this property is not necessary and has been deprecated. Support for this property may be removed in future versions of the Security Plugins. Using this property is highly discouraged.

6.1.4. Robustness and Security

6.1.4.1. Remote Secure DomainParticipants with Incompatible Configurations now Treated as Unauthenticated

If a local DomainParticipant has a Governance Document with the allow_unauthenticated_participants XML tag set to TRUE, communication will still happen over unsecure topics (those that have all the topic-level rules set to FALSE or NONE) even if the remote DomainParticipant is not authenticated.

In previous releases, a remote DomainParticipant was considered unauthenticated if it was not using security, or if the authentication process failed. However, if matching failed during discovery, the local and remote DomainParticipants wouldn’t communicate with each other, even over unsecure topics. This behavior has changed.

Starting in this release, local DomainParticipants will also consider a remote DomainParticipant to be unauthenticated if it has an incompatible secure configuration or an incompatible set of security plugins. Communication with them may happen for unsecure topics if allow_unauthenticated_participants is TRUE.

6.1.4.2. Security Plugins now robust against sensitive information leaks when using non-secure Dynamic Memory Managers

To make the Security Plugins robust against potential sensitive information leaks when running on operating systems using non-secure Dynamic Memory Managers, the Security Plugins now sanitize the dynamically allocated buffers used to hold keys and passwords before releasing them.