2.1.2.2. RTI Security Plugins

The following issues affect backward compatibility in RTI Security Plugins when migrating from release 7.1.0 to release 7.2.0.

2.1.2.2.1. Changes to Building an Application

2.1.2.2.1.1. OpenSSL 3.0 upgrade and 1.1.1 removal

Release 7.2.0 of the Security Plugins uses OpenSSL® 3.0.9. The Security Plugins 7.2.0 include only one set of target bundles: rti_security_plugins-7.2.0-target-openssl-3.0-<architecture>.rtipkg. These bundles are API-compatible with OpenSSL versions 3.0.0 through 3.0.9, not with versions earlier than OpenSSL 3.0.0. Note that Security Plugins 7.2.0 has only been tested by RTI using OpenSSL 3.0.9. If you need Security Plugins 7.2.0 to run against older versions of OpenSSL, please contact support@rti.com.

The support of OpenSSL 1.1.1 has been removed, because it is end-of-life in September, 2023 (https://www.openssl.org/policies/releasestrat.html).

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, please note that the Security Plugins do not support providers (see https://www.openssl.org/docs/man3.0/man7/provider.html).

2.1.2.2.1.2. wolfSSL upgrade

Starting in release 7.1.0, the Security Plugins for wolfSSL are now based on wolfSSL version 5.5.1. Starting with 7.1.0, the Security Plugins are API-compatible with wolfSSL version 5.5.1, not with versions earlier than wolfSSL 5.5.1. Note that the Security Plugins have only been tested by RTI using wolfSSL 5.5.1.

See the RTI Security Plugins Installation Guide.

2.1.2.2.1.3. wolfSSL build flags

You must build wolfSSL with two additional flags: --enable-certext and --enable-aesgcm-stream. RTI has added these two new options to the list of flags that you must build wolfSSL with. For more information, see Building wolfSSL, in the RTI Security Plugins Installation Guide.

2.1.2.2.1.4. Security Plugins SDK no longer uses cmocka

The tests included in the Security Plugins SDK no longer depend on the cmocka third-party library. Starting in 7.2.0, the SDK uses a test library shipped with Connext. There is no need to install the cmocka bundle.

2.1.2.2.2. API Compatibility

2.1.2.2.2.1. Added unique identifier to pre-shared key property

The Security Plugins now expect a different format for the cryptography.rtps_protection_preshared_key property. In previous releases, the property value was simply <SEED>, where <SEED> was the secret seed used by the Security Plugins (along with other publicly available data) to derive the per-participant pre-shared key. Starting in 7.2.0, the property value must be str:<ID>:<SEED>, where <ID> is a number between 0 and 254 that uniquely identifies the <SEED>.

RTPS messages that are protected using a pre-shared key have this <ID> associated with them. This allows DomainParticipants to compare the pre-shared key used to protect the incoming message with their local pre-shared key. If the identifiers do not match, the local DomainParticipant will drop the incoming RTPS message.

2.1.2.2.2.2. Removed check_remote_topic

The DDS Security specification describes the Access Control plugin operation check_remote_topic. This function was implemented and invoked during endpoint discovery starting from Security Plugins 6.0.0. However, due to the absence of TopicBuiltinTopicData propagation, this invocation was ineffective. Starting in 7.2.0, the Security Plugins no longer call check_remote_topic. If you have a custom Access Control plugin that was relying on check_remote_topic to enforce access control rules, you should move your implementation of this function to both check_remote_datawriter and check_remote_datareader.

2.1.2.2.3. Wire Compatibility

2.1.2.2.3.1. Enabling key revisions not backwards compatible

When enabling key revisions by setting the property dds.participant.trust_plugins.key_revision_max_history_depth to a value other than 0, a 7.2.0 DomainParticipant will not communicate with a 7.1.0 DomainParticipant. If they attempt to communicate, both DomainParticipants will get a getDecryptCryptoState error upon trying to decode content from each other. This compatibility issue is a result of changing the Crypto Header format to improve debuggability (e.g., using Wireshark), usability, and forward compatibility of key revisions.

2.1.2.2.3.2. Pre-Shared Key (PSK) Protection not backwards compatible

Pre-Shared Key (PSK) Protection in 7.2.0, both in the Security Plugins and Lightweight Security Plugins, is not compatible with release 7.1.0. (PSK Protection was introduced in 7.1.0.)

2.1.2.2.3.3. PID changes affect compatibility with previous 7.x releases

In 7.2.0, RTI has changed the PIDs that were introduced in 7.0.0, related to the cryptographic algorithms. (See Information about supported and used cryptographic algorithms propagated in discovery.) This change is enforced by the OMG DDS Security specification (version 1.1). This change makes 7.2.0 incompatible with releases 7.1.0 and 7.0.0. (Releases 7.0.0 and 7.1.0 are compatible, but they will not operate with 7.2.0.)

Table 2.1 Participant Discovery PID Changes

Field	Algorithm	Old PID	New PID	Name
digital_signature	PID_PARTICIPANT_SECURITY_DIGITAL_SIGNATURE_ALGO	0x1006	0x1010	ParticipantSecurityDigitalSignatureAlgorithms
key_establishment	PID_PARTICIPANT_SECURITY_KEY_ESTABLISHMENT_ALGO	0x1007	0x1011	ParticipantSecurityKeyEstablishmentAlgorithms
symmetric_cipher	PID_PARTICIPANT_SECURITY_SYMMETRIC_CIPHER_ALGO	0x1008	0x1012	ParticipantSecuritySymmetricCipherAlgorithms

Table 2.2 Endpoint Discovery PID Changes

Field	Algorithm	Old PID	New PID	Specification
symmetric_cipher	PID_ENDPOINT_SECURITY_SYMMETRIC_CIPHER_ALGO	0x1009	0x1013	EndpointSecuritySymmetricCipherAlgorithms

2.1.2.2.4. Configuration Changes

2.1.2.2.4.1. Deprecated properties in favor of pre-shared key (PSK) protection

In 7.2.0, the following properties are deprecated:

• com.rti.serv.secure.cryptography.rtps_protection_key

• com.rti.serv.secure.authentication.participant_discovery_protection_key

Although the properties are still available for use, you should use pre-shared key (PSK) protection instead, specifically the com.rti.serv.secure.cryptography.rtps_protection_preshared_key property. The deprecated properties will be removed in a future release.

Note that the deprecation of these properties follows the deprecation of the HMAC-Only mode in the previous release. (See RTPS-HMAC-Only Mode, in the RTI Security Plugins User’s Manual 7.2.0.) These properties were based on the HMAC-Only mode. With enhancements to PSK in 7.2.0 (adding PSK protection to RTI Cloud Discovery Service and RTI Real-Time WAN Transport), release 7.2.0 offers a complete alternative to HMAC-Only protection. Starting in 7.2.0, you can now build your solution HMAC-free.

2.1.2.2.4.2. Secure BuiltinLoggingTopic renamed to BuiltinLoggingTypeV2

In the year 2038 support added in 7.2.0, the secure BuiltinLoggingType type has been renamed BuiltinLoggingTypeV2, the DDS:Security:LogTopic Topic has been renamed DDS:Security:LogTopicV2, and the type’s IDL has changed. To receive both the old (from applications running ealier versions of the Security Plugins) and new Topics, you will need to create two DataReaders: one subscribed to DDS:Security:LogTopic and one subcribed to DDS:Security:LogTopicV2.

See further information about year 2038 support near the end of the API Compatibility section and in RTI Tools.

2.1.2.2.5. Discovery Performance

2.1.2.2.5.1. Simple Participant Discovery 2.0 interaction with Security Plugins

In releases 7.0.0 and 7.1.0, there were known scalability challenges with large-scale systems using the Security Plugins in combination with Simple Participant Discovery 2.0, where “large” means multiple hundreds of participants discovering each other at once. These issues may have manifested as excess bandwidth usage, lack of complete discovery, liveliness lost events, or incomplete authentication periods. These issues have been addressed in release 7.2.0.