2.3.2.3. RTI Security Plugins
The following issues affect backward compatibility in RTI Security Plugins when migrating from release 6.1.1/6.1.2 to release 7.2.0.
Attention
For important information on new and deprecated features in 7.2.0, see What’s New in 7.2.0 in the Security Plugins Release Notes.
2.3.2.3.1. Changes to building an application
2.3.2.3.1.1. Link against both libssl and libcrypto
When building an application, you must now link against both libssl and libcrypto instead of only libcrypto. libssl has been added to the hello_security example makefiles and project files.
2.3.2.3.1.2. 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.3.2.3.1.3. 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.
2.3.2.3.1.4. 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.3.2.3.1.5. 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.3.2.3.1.6. Degradation of Security Plugins performance when switching from OpenSSL 1.1.1 to OpenSSL 3.0
The throughput of the Security Plugins for OpenSSL 3.0 is worse than that of the Security Plugins for OpenSSL 1.1.1. This degradation is not due to the Security Plugins; it is due to the OpenSSL cryptographic library. OpenSSL 3.0.8 is slower than OpenSSL 1.1.1t, at least for most algorithms that the Security Plugins support. The root cause is this OpenSSL issue: https://github.com/openssl/openssl/issues/20171. See Cryptographic Libraries, in the RTI Connext Performance Benchmarks, for more information.
2.3.2.3.2. API Compatibility
2.3.2.3.2.1. 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.3.2.3.3. Updated shipped examples to support different cryptographic libraries
Release 7.1.0 (which release 7.2.0 subsumes) added support 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 cryptographic libraries (OpenSSL 3.0 or wolfSSL 5.5). Use the cryptographic library matching your installation of the Security Plugins. When linking statically, the default cryptographic library is now OpenSSL 3.0. (Release 6.1.2’s default was OpenSSL 1.1.1.)
The examples for Windows systems now include new build modes, so you can choose the cryptographic library. On Linux and macOS systems, you can indicate the cryptographic library as a parameter of the make command when compiling the example.
Please see the hello_security READ_ME.txt files for more details.
2.3.2.3.4. Wire Compatibility
2.3.2.3.4.1. Batching of protected data is not backwards compatible
When enabling batching and serialized data protection, the serialized data protection is now applied to the entire batch instead of to the individual samples within the batch. While this change improves throughput, it also affects backwards compatibility with 6.1.2 releases and earlier. A Connext 7.2.0 DataWriter using this combination will not communicate with a DataReader of an earlier release, and a DataWriter of an earlier release using this combination will not communicate with a Connext 7.2.0 DataReader.
For more information, see Serialized Data Protection, in the Security Plugins User’s Manual.
2.3.2.3.4.2. Data protection kind did not protect serialized keys sent with dispose samples
In releases 6.1.2 and earlier, if you set serialize_key_with_dispose in the
DATA_WRITER_PROTOCOL QoS Policy to
TRUE (and the Governance document tag data_protection_kind was not
NONE), then the key that was serialized with a dispose
sample was (incorrectly) not protected. In order to protect this key, you
had to set the Governance document tag metadata_protection_kind or
rtps_protection_kind to a value other than NONE. This problem has been
fixed in release 7.1.0.
While this change fixes a security weakness, it also affects backwards
compatibility with releases 6.1.2 and earlier. A Connext 7.2.0 DataReader
will fail to process dispose samples from a DataWriter of an earlier release that is
setting serialize_key_with_dispose to TRUE and data_protection_kind to
a value other than NONE, and a DataReader of an earlier release will fail to
process dispose samples from a Connext 7.2.0 DataWriter using this combination.
For more information, see Serialized Data Protection, in the Security Plugins User’s Manual.
2.3.2.3.4.3. AES-192 is not supported when communicating with earlier releases
This issue affects you if you currently configure AES-192 as the
cryptography.encryption_algorithm in combination with a Governance document
that enables any protection kind other than NONE.
Releases after 6.1.2 do not communicate with 6.1.2 and earlier versions or with other vendors using AES-192, unless the remote DomainParticipant supports discovery changes related to propagation of cryptographic algorithms, discussed in detail in Discovery of a Remote Secure Entity, in the Security Plugins User’s Manual.
After 6.1.2, supported and used cryptographic algorithms are propagated in order to determine matching and to improve debuggability. To maintain backward compatibility, and to save bandwidth, the default values are not propagated. The defaults are set to match values recommended in previous releases and allowed by the OMG DDS Security specification. In the case of Endpoint Symmetric Cipher Algorithms and Participant Symmetric Cipher Algorithms, the default ‘used algorithm’ is AES-256, while the default ‘supported algorithms’ are AES-128 and AES-256.
As a result, AES-192 is not supported when communicating with
releases 6.1.2 and earlier and with vendors not propagating their cryptographic
algorithms during discovery. If the local DomainParticipant tries to configure AES-192 as
the cryptography.encryption_algorithm
(see Properties for Configuring Cryptography, in the Security Plugins User’s Manual)
while communicating with a DomainParticipant not supporting algorithms during discovery propagation,
you will see the following error message:
PRESParticipant_getRemoteParticipantInitialSecurityState:[...]security info for authenticated remote participant [...] does not match the one for local participant [...]. Dropping participant announcement..."}}
Additionally, AES-192 is now deprecated. Please reconfigure your system to use other, supported algorithms. For details about cryptographic algorithms and their default values, see: Cryptographic Algorithms and Authentication Cryptographic Algorithms in the Security Plugins User’s Manual.
2.3.2.3.4.4. Deprecated property values for configuring the symmetric cipher algorithm
After release 6.1.2, the aes-128-gcm and aes-256-gcm values of the
cryptography.encryption_algorithm property are deprecated (see
Properties for Configuring Cryptography, in the Security Plugins User’s Manual).
These values can still be used, but may be removed in a future release. Instead,
configure the symmetric cipher algorithm with either AES128+GCM or
AES256+GCM.
2.3.2.3.5. Configuration Changes
2.3.2.3.5.1. Removed support for DSA
After release 6.1.2, the support for Digital Signature Algorithm (DSA) was removed, following its deprecation in earlier releases.
The DSA is no longer accepted in the configuration and must be replaced with a different, supported algorithm. For the list of supported algorithms, see Cryptographic Algorithms Used for Digital Signatures, in the Security Plugins User’s Manual. For example, if you try to configure a DSA private key, you will get errors similar to the following:
RTI_Security_AuthenticationData_create:[...]"unknown private key type"}}
2.3.2.3.5.2. Enforcement of supported Digital Signature algorithms now supported in Connext
Release 7 adds the ability to enforce restrictions on the cryptographic algorithms that are allowed in your system. As part of this feature, the Security Plugins check that DomainParticipants only use supported Digital Signature algorithms. You can find the list of supported algorithms in Cryptographic Algorithms Used for Digital Signatures, in the Security Plugins User’s Manual.
For example, the verification of the Identity Certificate Authority fails if the combination of signature algorithm and digest type is not compatible. The failure will happen when authenticating a remote DomainParticipant or when creating the local DomainParticipant. For example, the Security Plugins will log the following error when trying to load an Identity Certificate signed using ECDSA P256 with SHA-1 (because this combination is not supported):
RTI_Security_CertHelper_logIncompatibleDigest:!Found unknown digest type when sha256 digest type was expected: The Certificate Authority's public key is of type id-ecPublicKey and curve prime256v1
RTI_Security_CertHelper_verifyCert_errorIfCrlMissing:!invalid digest type
[...]
RTI_Security_Authentication_getCertificate:[..] "Identity verification failed. Make sure it was signed by the right authority."
In the following example, the remote DomainParticipant is using a Digital Signature algorithm the local DomainParticipant does not support:
RTI_Security_CertHelper_isDigestTypeAllowed:!unexpected key type. Valid key types are ECDSA (NIST P-256 or NIST P-384) and RSA
RTI_Security_CertHelper_verifyCert_errorIfCrlMissing:!invalid digest type
RTI_Security_CertHelper_verifyCert:[...]"X509_verify_cert returned -1 with error 0: ok
Valid configurations are RSA with SHA-256, ECDSA secp256r1 with SHA-256, and ECDSA secp384r1 with SHA-384. For more information, read Cryptographic Algorithms Used for Digital Signatures, in the Security Plugins User’s Manual.
Previous releases of the Security Plugins applied no restrictions with respect to the allowed Digital Signature algorithms, as long as the underlying cryptographic library (e.g., OpenSSL) supported them. As a result, applications using the Security Plugins relying on an unsupported configuration need to update the affected configuration artifacts (Identity Certificates, CA Certificates, Governance Document, and or Permissions Document).
2.3.2.3.5.4. 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.