2.2.2. RTI Security Plugins
2.2.2.1. Wire Compatibility
2.2.2.1.1. GUID consistency enforcement
Release 7.7.0 of the Security Plugins introduces an Access Control mechanism to
enforce consistency between
SampleInfo::publication_handle,
SampleInfo::original_publication_virtual_guid,
SampleInfo::source_guid,
DDS_PublicationBuiltinTopicData::virtual_guid,
and DDS_SubscriptionBuiltinTopicData::virtual_guid.
If your Permissions Document grant has <default>DENY</default>, then this
mechanism is enabled by default. If you are using
Collaborative DataWriters,
Persistence Service, Routing Service, or other Infrastructure Services built on
top of Routing Service, or
write_w_params
with WriteParams::identity.writer_guid or WriteParams::source_guid,
then you may experience communication failure along with this error:
does not match DDS_SampleInfo::publication_handle
In that case, you may need to adjust the proxy permissions in your
Permissions Document. Alternatively, you may set
<enforce_proxy_permissions>false</enforce_proxy_permissions> in your
Governance Document <domain_rule>, but this option is generally discouraged and
should only be used when integrating with legacy systems where domain insider
integrity and availability threats are not a concern.
Refer to DataWriters Acting as a Proxy for other DataWriters in the RTI Security Plugins User’s Manual for more details.
2.2.2.2. Changes to Building an Application
2.2.2.2.1. OpenSSL 3 upgrade
Release 7.7.0 of the Security Plugins upgrades the version of OpenSSL® from 3.5.1 to 3.5.5. The Security Plugins bundles are API-compatible with OpenSSL version 3.5.5, not with versions earlier than OpenSSL 3.5.5. Note that Security Plugins 7.7.0 has only been tested by RTI using OpenSSL 3.5.5. If you need Security Plugins 7.7.0 to run against older versions of OpenSSL, please contact support@rti.com.
2.2.2.2.2. wolfSSL 5 upgrade
Release 7.7.0 of the Security Plugins upgrades the version of wolfSSL® from
5.5.1 to 5.8.2. The Security Plugins bundles have been renamed from 5.5
(e.g., rti_security_plugins-7.6.0-target-wolfssl-5.5-<architecture>.rtipkg)
to 5.8 (e.g., rti_security_plugins-7.7.0-target-wolfssl-5.8-<architecture>.rtipkg).
These bundles are API-compatible with wolfSSL version 5.8.2, not with versions
earlier than wolfSSL version 5.8.2. Note that Security Plugins 7.7.0 has only
been tested by RTI using wolfSSL version 5.8.2. If you need Security Plugins
7.7.0 to run against older versions of wolfSSL, please contact support@rti.com.
Note
The rti_security_plugins-<version>-host-wolfssl-<version>-<host platform>.rtipkg
packages are available on demand only. If you
do not see them in the Customer Portal, contact support@rti.com.
wolfSSL 5.8.2 requires your X.509 Identity CA certificate (root and
intermediates) to have the basicConstraints = CA:true extension. Refer to
The basicConstraints X.509 v3 extension
in the RTI Security Plugins User’s Manual for more details. If you are migrating from wolfSSL 5.5.1 to
5.8.2, make sure your Identity CA certificates have this extension. In the
.cnf configuration file, verify that the x509_extensions = v3_ca
line is not commented out.
2.2.2.2.3. Removal of the deprecated SecurityPluginSuite_create entry point
Release 7.7.0 of the Security Plugins removes the
SecurityPluginSuite_create entry point. If you had set the
com.rti.serv.secure.create_function or
com.rti.serv.secure.create_function_ptr property with the deprecated entry
point, you must update it to use RTI_Security_PluginSuite_create
(function name or address, depending on property and linking mode). Refer to
Building and Running Security Plugins-Based Applications
in the RTI Security Plugins User’s Manual for more details.
2.2.2.2.4. Linking against the Security Plugins for wolfSSL
Release 7.7.0 of the Security Plugins no longer ships the Security Plugins for
wolfSSL libraries in the <NDDSHOME>/lib/<architecture>/ directory (where
<NDDSHOME> refers to the root directory of your RTI Connext installation).
The libraries (both Lightweight Builtin Security Plugins and Builtin Security Plugins) are now located in the
<NDDSHOME>/lib/<architecture>/wolfssl-5.8/ directory.
As a consequence, if you are linking dynamically against the Security Plugins
for wolfSSL, you need to run your applications with the updated library path
that includes <NDDSHOME>/lib/<architecture>/wolfssl-5.8/. For example, on
Linux, you can set the LD_LIBRARY_PATH environment variable to:
export LD_LIBRARY_PATH=\
$NDDSHOME/lib/x64Linux4gcc8.5.0/wolfssl-5.8:\
$NDDSHOME/lib/x64Linux4gcc8.5.0:\
$NDDSHOME/third_party/wolfssl-5.8.2/x64Linux4gcc8.5.0/debug/lib
Make sure to add the path to the Security Plugins for wolfSSL before the path to the general libraries. Otherwise, your application may attempt to load the default Security Plugins for OpenSSL library.
If you are linking statically against the Security Plugins for wolfSSL, you need
to indicate the new library path to the linker in your build system. You can
find an example makefile in the example secure hello world applications provided
in the rti_workspace directory.
2.2.2.3. Changes to Supported Cryptographic Algorithms
2.2.2.3.1. Removal of the AES-192-GCM symmetric cipher algorithm
Following the deprecation of AES-192-GCM in release 7.3.0, release 7.7.0 now completely removes this cryptographic algorithm from the list of available symmetric cipher algorithms. If you are still using AES-192-GCM in your system, please transition to AES-256-GCM or AES-128-GCM.
For more information about symmetric cipher algorithms, see Algorithms Involved in Protecting Secure Entities Traffic in the RTI Security Plugins User’s Manual.
2.2.2.4. Configuration Changes
2.2.2.4.2. Removal of cryptography.max_receiver_specific_macs as a requirement for RTPS origin authentication
This release of the Security Plugins removes the
cryptography.max_receiver_specific_macs
property as a requirement for setting the Governance tag
<rtps_protection_kind> to a value that ends in
_WITH_ORIGIN_AUTHENTICATION. If you are setting
max_receiver_specific_macs only because it was a requirement and not
because you are trying to reduce the performance impact of origin
authentication, then you are encouraged to remove this setting in favor of the
new default value of AUTO.
2.2.2.5. Logging Changes
2.2.2.5.1. New logging topic for the Lightweight Security Plugins library
Release 7.7.0 of the Lightweight Builtin Security Plugins introduces a new logging topic,
DDS:Security:PSK:LogTopic. Previously, the Lightweight Builtin Security Plugins logged
messages to the same topic as the Builtin Security Plugins, DDS:Security:LogTopicV2.
However, according to the DDS Security Specification, this topic must enable
metadata and data protection. Therefore, the Lightweight Builtin Security Plugins should not log
to it.
Applications using the Lightweight Builtin Security Plugins and subscribing to the
DDS:Security:LogTopicV2 topic will no longer receive log messages from the
Lightweight Builtin Security Plugins. Instead, they should subscribe to the new
DDS:Security:PSK:LogTopic.
2.2.2.6. Security Plugins SDK
This release of the Security Plugins introduces changes in the Service Plugin
Interface (SPI). If you have implemented custom plugins, you may need to update
them for compatibility. See the Service Plugin Interface (SPI) Notes section
of the Security Plugins SDK documentation for more information. In your
Connext installation, find the documentation inside the
security-buildsrc/doc folder.