2.2.2.4. 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.1.0.
Attention
For important information on new and deprecated features in 7.1.0, see What’s New in 7.1.0 in the Security Plugins Release Notes.
2.2.2.4.1. Changes to building an application
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.2.2.4.2. OpenSSL upgrade
Release 7.1.0 of the Security Plugins uses OpenSSL® 1.1.1t and OpenSSL 3.0.8. (Release 6.1.1/6.1.2 used OpenSSL 1.1.1n.)
Security Plugins 7.1.0 includes two sets of
target bundles: rti_security_plugins-7.1.0-target-openssl-1.1.1-<architecture>.rtipkg and
rti_security_plugins-7.1.0-target-openssl-3.0-<architecture>.rtipkg. The openssl-1.1.1
version is API-compatible with OpenSSL versions 1.1.0 through 1.1.1t, not with
versions earlier than OpenSSL 1.1.0. The openssl-3.0 version is
API-compatible with OpenSSL versions 3.0.0 through 3.0.8, not with versions
earlier than OpenSSL 3.0.0. Note that Security Plugins 7.1.0 has only been tested
by RTI using OpenSSL 1.1.1t and OpenSSL 3.0.8. If you need Security Plugins 7.1.0
to run against older versions of OpenSSL, please contact support@rti.com.
OpenSSL 1.1.1 will only be supported until 2023-09-11 (https://www.openssl.org/policies/releasestrat.html), so it is recommended that you upgrade the version of OpenSSL that you are using to OpenSSL 3.0.8 for release 7.1.0.
For instructions on installing the latest version of OpenSSL, see the RTI Security Plugins Installation Guide 7.1.0.
2.2.2.4.3. wolfSSL upgrade
In release 7.1.0, the Security Plugins for wolfSSL are now based on wolfSSL version 5.5.1. Security Plugins 7.1.0 is API-compatible with wolfSSL version 5.5.1, not with versions earlier than wolfSSL 5.5.1. Note that Security Plugins 7.1.0 has only been tested by RTI using wolfSSL 5.5.1.
2.2.2.4.4. Updated shipped examples to support different cryptographic libraries
Release 7.1.0 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 cryptographic libraries (OpenSSL 3.0, OpenSSL 1.1.1, 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 7.0.0’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.2.2.4.5. Wire Compatibility
2.2.2.4.5.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.1.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.1.0 DataReader.
For more information, see Serialized Data Protection, in the Security Plugins User’s Manual.
2.2.2.4.5.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.1.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.1.0 DataWriter using this combination.
For more information, see Serialized Data Protection, in the Security Plugins User’s Manual.
2.2.2.4.5.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.2.2.4.5.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.2.2.4.6. Configuration
2.2.2.4.6.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.2.2.4.6.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).