2.2.4. RTI Security Plugins

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

2.2.4.1. Wire Compatibility

2.2.4.1.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 releases prior to Connext 7.0.0. A Connext 7.0.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.0.0 DataReader.

For more information, see Serialized Data Protection, in the Security Plugins User’s Manual.

2.2.4.1.2. Data protection kind did not protect serialized keys sent with dispose samples

Before 7.0.0, 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.0.0.

While this change fixes a security weakness, it also affects backwards compatibility with releases prior to Connext 7.0.0. A Connext 7.0.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.0.0 DataWriter using this combination.

For more information, see Serialized Data Protection, in the Security Plugins User’s Manual.

2.2.4.1.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.

Release 7.0.0 does not communicate with 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.

Starting with release 7.0.0, 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 earlier than 7.0.0 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.4.1.4. Deprecated property values for configuring the symmetric cipher algorithm

Release 7.0.0 deprecates the aes-128-gcm and aes-256-gcm values of the cryptography.encryption_algorithm property (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.4.2. Configuration

2.2.4.2.1. Removed support for DSA

In release 7.0.0, 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.4.2.2. Enforcement of supported Digital Signature algorithms now supported in Connext

This release 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).