4. What’s New in 7.3.0 LTS
Security Plugins 7.3.0 LTS is a long-term support release that is built upon and includes all the features in releases 7.0.0, 7.1.0, and 7.2.0 (see Previous Releases). This section describes new features and improvements in 7.3.0 LTS, compared to 7.2.0.
4.2. New Algorithms
4.2.1. Compliance with DDS Security 1.2 Specification regarding cryptographic algorithms
This release of the Security Plugins introduces several updates to comply with the DDS Security 1.2 Specification.
It includes changes to conform to naming, such as the addition of the
dds.sec.crypto.symmetric_cipher_algorithm
property and the
rtps_psk_protection_kind
Governance Document XML tag. There are
updates to the expected behavior during discovery, such as not
serializing the last algorithms if they have the default values, or only
checking compatibility of the DomainParticipant symmetric cipher
algorithms if they have protection enabled at the RTPS message level.
This release also changes the values that identify several algorithms
(custom ones, like AES192+GCM
, and experimental ones, like
ECDHE-CEUM+X25519
) on the wire.
For more information, see Cryptographic Algorithms, in the RTI Security Plugins User’s Manual.
4.2.2. New mask in Parameter ID indicates the default algorithm that endpoints use to protect data
The Parameter ID of the DomainParticipant’s symmetric cipher algorithm
information (PID_ENDPOINT_SECURITY_SYMMETRIC_CIPHER_ALGO
) used to
have three masks: supported_mask
,
builtin_endpoints_required_mask
, and
builtin_kx_endpoints_required_mask
. This release introduces an
additional one, user_endpoints_default_required_mask
. The value of
this mask indicates the default algorithm that the endpoints of the
DomainParticipant use to protect user data traffic (unless the
endpoint doesn’t specify directly the algorithm to use).
The Security Plugins will not consider this mask when deciding if two DomainParticipants are compatible.
4.2.3. Changes in serialization of cryptographic algorithms
During discovery, DomainParticipants may propagate information about the cryptographic algorithms that they require or support. DomainParticipants propagate this information when they are configured with non-default cryptographic algorithms. Starting in this release, the Security Plugins will skip serialization of the last cryptographic algorithms in a PID (Parameter ID) if they have the default values.
4.3. Extensibility and Usability
4.3.1. Security Plugins now support OpenSSL providers
The OpenSSL default implementations of security algorithms may not meet the needs of every security application. As described in https://www.openssl.org/docs/man3.0/man7/provider.html , OpenSSL providers are a way of loading alternative implementations of algorithms. The Security Plugins now support OpenSSL providers, which are the OpenSSL 3.0 replacement for the OpenSSL 1.1.1 Engine API (see https://www.openssl.org/docs/man3.0/man7/migration_guide.html and search for the ‘Engines and “METHOD” APIs’ section). To use an OpenSSL provider with a Security Plugins application, you must use an OpenSSL configuration file to specify the providers you want to load, as described in https://www.openssl.org/docs/man3.0/man5/config.html, and you must set the appropriate environment variables. Then the Security Plugins will perform the following actions:
Log, at a higher verbosity level, which providers are loaded and activated.
Adjust the DomainParticipant discovery data based on which algorithms your providers support.
Use your providers for security operations.
One example of a provider is the OpenSSL FIPS provider, described in https://www.openssl.org/docs/man3.0/man7/fips_module.html. RTI has tested that the OpenSSL FIPS provider works seamlessly with the Security Plugins, with the only caveat being that the FIPS provider does not support the DHE-MODP+2048+256 Key Establishment Algorithm.
See Support for OpenSSL Providers, in the Security Plugins User’s Manual for more information.
4.3.2. Ability to send security events to logging aggregator backend with RTI Observability Framework
Now you can use RTI Monitoring Library 2.0 to forward security events logged by the Security Plugins’ Logging plugin to RTI Observability Collector Service. The service will store the security events in a logging aggregator backend, such as Grafana® Loki®. Then you can use the message visualization and query functionalities offered by the aggregator backend and Grafana Dashboards.
For more information, see:
4.3.3. Improved format of Security Plugins SDK documentation
The Security Plugins SDK documentation used to be located inside the
RTI_SecurityPlugins_BuildableSourceCode_Instructions.txt
file of the
root directory. This file contained instructions on how to build the SDK
and run the tests, as well as API changes between releases. This
information is now part of the new HTML documentation shipped with the
Security Plugins SDK under doc/html
(start by opening the
index.html
landing page). The new documentation shares the look and
feel of RTI’s other API documentation pages.
4.4. Robustness and Security
4.4.1. Remote Secure DomainParticipants with Incompatible Configurations now Treated as Unauthenticated
If a local DomainParticipant has a Governance Document with the
allow_unauthenticated_participants
XML tag set to TRUE
,
communication will still happen over unsecure topics (those that have
all the topic-level rules set to FALSE
or NONE
) even if the
remote DomainParticipant is not authenticated.
In previous releases, a remote DomainParticipant was considered unauthenticated if it was not using security, or if the authentication process failed. However, if matching failed during discovery, the local and remote DomainParticipants wouldn’t communicate with each other, even over unsecure topics. This behavior has changed.
Starting in this release, local DomainParticipants will also consider
a remote DomainParticipant to be unauthenticated if it has an
incompatible secure configuration or an incompatible set of security
plugins. Communication with them may happen for unsecure topics if
allow_unauthenticated_participants
is TRUE.
4.4.2. Security Plugins now robust against sensitive information leaks when using non-secure Dynamic Memory Managers
To make the Security Plugins robust against potential sensitive information leaks when running on operating systems using non-secure Dynamic Memory Managers, the Security Plugins now sanitize the dynamically allocated buffers used to hold keys and passwords before releasing them.