2.1.2.2. RTI Security Plugins

2.1.2.2.1. Deprecations or Removals

Deprecated means that an item is still supported, but will be removed in a future release. Removed means that an item is discontinued or no longer supported.

2.1.2.2.1.1. HMAC-Only Mode Deprecation

Starting in release 7.1.0, Builtin Security Plugins’s HMAC-Only mode is deprecated, and Lightweight Builtin Security Plugins should be used instead (see The Lightweight Builtin Security Plugins, in the RTI Security Plugins User’s Manual for details).

HMAC-Only mode remains functional in release 7.3.0 for integration with legacy systems only and should not be used in new deployments. For detailed information on Builtin Security Plugins’s HMAC-Only mode and its configuration, see RTPS-HMAC-Only Mode in the Security Plugins 6.1.2 documentation.

2.1.2.2.2. Logging Changes

2.1.2.2.2.1. Changed fields in Security Events log messages

The following fields in Security Events log messages have changed in this release:

  • msgid ("k" when the Security Event is printed in JSON format):
    Before 7.3.0, this field always contained the string literal "security". Now, it will have a numeric identifier. This change aligns with the message IDs published by RTI Monitoring Library 2.0 for Connext messages, which are also numeric identifiers.

  • guid name-value pair in structured_data ("x" when the Security Event is printed in JSON format):
    The GUID format changed. Starting in release 7.3.0, the hexadecimal letters are shown in upper case, and each component of the GUID (separated by dots) is always 8 characters in length, filling in with leading zeros when necessary. For example, the GUID dfcd91e1.6868b395.a84df008.1c1 now looks like DFCD91E1.6868B395.A84DF008.000001C1.

  • plugin_class name-value pair in structured_data ("x" when the Security Event is printed in JSON format):
    All the plugin class names changed in release 7.3.0 to align with the plugin class names of the OMG ‘DDS Security’ specification, version 1.2. See the following table for the new values:

Table 2.1 Plugin class names comparison

Release 7.2.0 and earlier

Release 7.3.0

Authentication

DDS:Auth:PKI-DH

Access Control

DDS:Access:Permissions

Cryptography

DDS:Crypto:AES-GCM-GMAC

Logging

DDS:Logging:DDS_LogTopic

Common

RTI:Common

RTI also added new plugin class names in this release:

  • DDS:Auth:PSK: Authentication plugin class name for the Lightweight Builtin Security Plugins.

  • DDS:Access:PSK: Access Control plugin class name for the Lightweight Builtin Security Plugins.

  • DDS:Crypto:PSK: Cryptography plugin class name for the Lightweight Builtin Security Plugins.

  • RTI:Auth, RTI:Access, RTI:Crypto, and RTI:Logging: plugin class names used for Security Events logged outside the Security Plugins.

These changes affect both Security Events logged in JSON format through the Connext Builtin Logging System and Security Events distributed over DDS. Keep these changes in mind if your application parses the Security Events log messages or if it subscribes to the Logging topic.

2.1.2.2.3. Wire Compatibility

2.1.2.2.3.1. Pre-Shared Key Protection is not backwards compatible due to OMG standard compliance changes

DomainParticipants that have a Pre-Shared Key Protection enabled (by setting the dds.sec.crypto.rtps_psk_secret_passphrase property) will not communicate with DomainParticipants from previous versions (7.1.0 or 7.2.0).

Compliance with OMG DDS Security 1.2 standard prompted a number of changes in RTI’s implementation of Pre-Shared Key Protection. Some of the changes break interoperability with previous versions. This includes changes in the pre-shared keys derivation algorithm (resulting in different cryptographic keys) and lightweight plugins class ID.

The issue affects both the Builtin Security Plugins when PSK is used and the Lightweight Builtin Security Plugins.

2.1.2.2.3.2. Backwards compatibility broken when configuring non-OMG-default cryptographic algorithms

During discovery, DomainParticipants may propagate information about the cryptographic algorithms that they require or support. The information is propagated when DomainParticipants are configured with cryptographic algorithms that the OMG DDS Security 1.2 specification (pending publication) doesn’t consider as default. You can find these default values in the Cryptography chapter of the RTI Security Plugins User’s Manual (the “allowed_security_algorithms (domain_rule)” section).

Note that the default behavior for the Security Plugins is to support all cryptographic algorithms (including some not considered default by the specification) if your Governance Document doesn’t indicate any. This means that the DomainParticipants will propagate information about their cryptographic algorithms during discovery if there is no allowed_security_algorithms tag in the Governance Document.

In the previous 7.0.0, 7.1.0, and 7.2.0 releases, the Security Plugins serialized all related cryptographic algorithms as long as one of them had a value not considered as default by the OMG DDS Security 1.2 specification (pending publication). Starting in this release, the Security Plugins may skip serialization of some algorithms. As a result, compatibility between 7.3.0 and previous Connext 7 releases is broken when configuring non-OMG-default cryptographic algorithms. Previous Connext 7 releases will attempt to deserialize all algorithms and fail when they are missing.

This release of the Security Plugins also changes the bits that are associated with the experimental algorithms (EDDSA+ED25519+SHA512, EDDSA+ED448+SHAKE256, ECDHE-CEUM+X25519, and ECDHE-CEUM+X448) in the propagated masks. Do not use these experimental cryptographic algorithms if you expect compatibility between 7.3.0 and previous Connext 7 releases. Another non-OMG-default cryptographic algorithm that you should not use when you expect backwards compatibility is AES192+GCM. The value of its cryptographic algorithm identifier has changed in 7.3.0 to match the vendor-specific range that the OMG DDS Security 1.2 specification (pending publication) mandates.

2.1.2.2.4. Performance and Scalability

2.1.2.2.4.1. Scalability is slightly affected in systems with more than 900 matching DomainParticipants

DomainParticipant discovery is slightly degraded in terms of scalability. This issue is only noticeable in scenarios with more than 900 DomainParticipants that belong to the same DomainParticipant partition. This issue was introduced by the fix for RTI Issue ID SEC-2220 (Non-random initial session ID for entities other than the Secure Key Exchange Channel).

2.1.2.2.5. Changes to Properties

2.1.2.2.5.1. Deprecation of the dds.data_writer.history.use_530_encoding_alignment property

This release of the Security Plugins deprecates the plugin-agnostic dds.data_writer.history.use_530_encoding_alignment property. This property no longer has any effect. A warning message will be logged if this property is set to TRUE. You never needed to set this property in order to interoperate with Security Plugins 5.3.0 or 5.3.1, so this deprecation does not break backward interoperability.

2.1.2.2.5.2. Deprecation of the cryptography.encryption_algorithm property

This release of the Security Plugins deprecates the plugin-specific cryptography.encryption_algorithm property. Instead, you should set the dds.sec.crypto.symmetric_cipher_algorithm property defined in the OMG ‘DDS Security’ specification, version 1.2. The behavior of the deprecated and the standard property is the same: they are both optional properties that configure the algorithm used for protecting data and metadata.

2.1.2.2.5.3. Changes to the cryptography.rtps_protection_preshared_key property

This release of the Security Plugins removes the plugin-specific cryptography.rtps_protection_preshared_key property. Instead, you should set the dds.sec.crypto.rtps_psk_secret_passphrase property defined in the OMG ‘DDS Security’ specification, version 1.2. The behavior of the removed and the standard property is the same: they are both properties that must be set when Pre-Shared Key Protection is enabled, and they contain the seed used to derive the key for protecting RTPS messages.

The acceptable formats for dds.sec.crypto.rtps_psk_secret_passphrase have changed. The property supports two formats:

  • data:,<ID>:<SEED> allows you to provide the PSK seed explicitly in the property value.

    • <ID> is an integer [0, 254] identifying the provided seed within the system.

    • <SEED> is a string used to derive (in combination with publicly available data) the key used for encoding RTPS messages.

  • file:<FILENAME> allows you to provide the seed in a supplemental file. The file can be optionally tracked by both Builtin Security Plugins and Lightweight Builtin Security Plugins (via the files_poll_interval property, enabled by default) for changes that are automatically incorporated into present operations.

    • <FILENAME> is the path to a file containing the PSK seed. The content of the file must use the <ID>:<SEED> format.

2.1.2.2.5.4. Removal of the cryptography.rtps_protection_preshared_key_algorithm property

This release of the Security Plugins removes the plugin-specific cryptography.rtps_protection_preshared_key_algorithm property. Instead, you should set the dds.sec.crypto.rtps_psk_symmetric_cipher_algorithm property defined in the OMG ‘DDS Security’ specification, version 1.2.

Just as the removed property, the new one controls the algorithm used for protecting RTPS messages when Pre-Shared Key Protection is enabled. However, its possible values are limited to: AUTO (same as AES256+GCM), AES128+GCM, and AES256+GCM. The decision of whether to protect only integrity, or to protect confidentiality as well, depends on the value of the rtps_psk_protection_kind XML tag in the Governance Document. In the case of Lightweight Builtin Security Plugins (which does not support the Governance Document), it is configured through the new dds.sec.access.rtps_psk_protection_kind property.

2.1.2.2.5.5. Removal of authentication.crl_file_poll_period.millisec and com.rti.serv.secure.authentication.identity_certificate_file_poll_period.millisec properties

The authentication.crl_file_poll_period.millisec and authentication.identity_certificate_file_poll_period.millisec properties have been replaced with a single property files_poll_interval.

The new property controls the polling interval for all files tracked by the Builtin Security Plugins. File tracking is enabled when the files_poll_interval value is a non-zero, positive number. When enabled, the Builtin Security Plugins will create a dedicated thread and allocate memory for file-tracking purposes regardless of whether there are any files to track. When files_poll_interval has a value of 0, all file tracking within Builtin Security Plugins is disabled.

Note that this property specifies time in seconds (previously, milliseconds) and acceptable values are in a narrower interval [0, 4294967]. The default value is now 5 (previously, 0), which means file tracking is enabled by default.

2.1.2.2.6. Changes to the Governance Document

This release of the Security Plugins removes the Governance Document rtps_preshared_secret_protection_kind XML tag in favor of the one defined in the OMG ‘DDS Security’ specification, version 1.2: rtps_psk_protection_kind. You must switch to the new rtps_psk_protection_kind XML tag. The new tag behaves exactly the same as the old one. It configures the kind of protection (ENCRYPT, SIGN, or NONE) that the Builtin Security Plugins apply to RTPS messages when using Pre-Shared keys.