.. include:: /../getting_started/vars.rst .. _section-Product-Security-700: 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 :link_sec_whats_new_710:`What's New in 7.1.0 in the Security Plugins Release Notes <>`. Changes to building an application ================================== .. include:: ../../710/product710/sec_build_app.txt OpenSSL upgrade =============== Release 7.1.0 of the |SP| uses OpenSSL® 1.1.1t and OpenSSL 3.0.8. (Release 6.1.1/6.1.2 used OpenSSL 1.1.1n.) .. include:: ../../710/product710/sec_openssl.txt wolfSSL upgrade =============== .. include:: ../../710/product710/sec_wolfssl.txt Updated shipped examples to support different cryptographic libraries ===================================================================== .. include:: ../../710/product710/sec_shipped_ex.txt Wire Compatibility ================== 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 |DW| using this combination will not communicate with a |DR| of an earlier release, and a |DW| of an earlier release using this combination will not communicate with a |CONNEXT| 7.1.0 |DR|. For more information, see :link_connext_sec_cryptography_data_protection_um_710:`Serialized Data Protection, in the Security Plugins User's Manual <>`. .. SEC-1408 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 :link_dwprotocol_usersman_710:`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 |DR| will fail to process dispose samples from a |DW| 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 |DR| of an earlier release will fail to process dispose samples from a |CONNEXT| 7.1.0 |DW| using this combination. For more information, see :link_connext_sec_cryptography_data_protection_um_710:`Serialized Data Protection, in the Security Plugins User's Manual <>`. .. SEC-627 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 |DP| supports discovery changes related to propagation of cryptographic algorithms, discussed in detail in :link_connext_sec_crypto_algorithms_discovery_um_710:`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 |DP| tries to configure AES-192 as the ``cryptography.encryption_algorithm`` (see :link_connext_sec_cryptography_data_protection_um_710:`Properties for Configuring Cryptography, in the Security Plugins User's Manual <>`) while communicating with a |DP| not supporting algorithms during discovery propagation, you will see the following error message: .. code-block:: console 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: :link_connext_sec_crypto_algorithms_um_710:`Cryptographic Algorithms <>` and :link_connext_sec_authentication_crypto_algorithms_um_710:`Authentication Cryptographic Algorithms<>` in the *Security Plugins User's Manual*. 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 :link_connext_sec_crypto_config_properties_um_710:`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``. .. SEC-1394 Configuration ============= 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 :link_connext_sec_digital_signature_algorithms_um_710:`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: .. code-block:: console RTI_Security_AuthenticationData_create:[...]"unknown private key type"}} .. SEC-1667 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 |DPs| only use supported Digital Signature algorithms. You can find the list of supported algorithms in :link_connext_sec_digital_signature_algorithms_um_710:`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 |DP| or when creating the local |DP|. 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): .. code-block:: console 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 |DP| is using a Digital Signature algorithm the local |DP| does not support: .. code-block:: console 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 :link_connext_sec_digital_signature_algorithms_um_710:`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). .. SEC-1395