1. Overview

One of the key values of RTI Connext and the OMG DDS Security specification is data-centricity. Connext is not just a pipe for exchanging data, it is a databus you can rely on to share your data among your applications in a controlled, effective, and efficient way.

The RTI Connext Databus gives you real control over what information your application is going to access. For instance, you can structure your data in different topics, so applications can select what data they are interested in, or even set up a content filter to make sure your applications only receive data that meets certain criteria. As an example, you could define a topic for patient monitoring, then configure Connext to only deliver updates when a patient heart rate falls below a certain threshold.

Given its data-centricity, traditional security solutions, which mostly focus on securing a pipeline for exchanging data, do not fit OMG DDS well. Moreover, using a secure pipeline requires one-to-one sessions between peers, which doesn’t allow multicast, so scalability is limited.

To address these issues, multiple vendors worked together to create the OMG DDS Security specification . This specification addresses the security aspect of the communication in a one-to-many friendly, data-centric way: instead of securing pipelines, it enables applications to define different security policies based on the nature of the shared data. The OMG DDS Security specification defines a set of builtin plugins for providing interoperable authentication, access control, cryptography, and a logging topic.

In this document we present the Security Plugins, which are the Connext implementation of the OMG DDS Security builtin plugins. As you will see, the Security Plugins offer a DDS Security solution that is interoperable with DDS Security implementations from other vendors.

This document is targeted at Connext users who want to secure their DDS systems with Security Plugins. Therefore, we assume that you have at least intermediate DDS knowledge, and at least a baseline understanding of security concepts. For an introduction to Connext, please refer to the RTI Connext Getting Started Guide. For an introduction to the Security Plugins, please refer to the RTI Security Plugins Getting Started Guide.

RTI provides two implementations of Security Plugins:

  • Builtin Security Plugins: the RTI implementation of the OMG DDS Security builtin plugins.

  • Lightweight Builtin Security Plugins: the RTI implementation of the OMG DDS Security builtin PSK plugins.

Disclaimer

Securing a distributed system is an exercise in user risk management. RTI expressly disclaims all security guarantees and/or warranties based on the names of its products, including Security Plugins and Security Plugins SDK. Visit https://www.rti.com/terms/ for complete product terms and an exclusive list of product warranties.

1.1. Description of DDS System Threats

In a DDS system, we have a set of publishers and subscribers within a data-centric publish-subscribe model. For example, let’s analyze the system depicted in Figure 1.1, where we have the following participants:

  • Alice: a legitimate application publishing to Topic T, allowed to publish these samples.

  • Bob: a legitimate application subscribing to Topic T, allowed to access that information.

  • Eve: an eavesdropper trying to subscribe to Topic T without authorization - to perform unauthorized subscription (1).

  • Trudy: an intruder trying to publish into the databus without authorization - to perform unauthorized publication (2).

  • Mallory: a malicious insider (for instance, authorized to subscribe to data but not to publish) trying to perform tampering and replay (3).

  • Trent: an Infrastructure Service that legitimately subscribes to and publishes data.

Participants communicating through the DDS Databus

Figure 1.1 Understanding Threats to DDS Systems

Since Alice and Bob are legitimate applications, they should be able to communicate as they were designed to. In this case, nothing should prevent them from communicating. The same applies to Trent. However, Trudy, Eve and Mallory should not be able to perform the malicious actions they want to perform. Note that the attackers may be applications outside your DDS system (outsiders), or legitimate applications in your DDS system trying to perform actions they are not authorized to perform (insiders). Let’s analyze each threat independently.

1.1.1. Unauthorized Subscription

Unauthorized subscription (aka, Eavesdropping) implies being able to read sensitive data without authorization.

For example, suppose that we have Eve, a DDS application with a DataReader that is not supposed to subscribe to a Topic T. In a non-secure scenario, Eve and Alice will discover each other, then Alice will start sending data samples to Eve. Since the baseline DDS and RTPS standards do not specifically address security, they do not define any mechanism to verify whether Eve is authorized to subscribe to Topic T.

Although eavesdropping is not always a problem on every Topic or every system, the Topic T may carry very sensitive data (for example, medical data) and should be protected against eavesdropping. The Security Plugins provide mechanisms to protect the confidentiality of data, guaranteeing that only authorized DataReaders are able to subscribe to Topic T and to make sense of data published to it.

1.1.2. Unauthorized Publication

Unauthorized publication means publishing data onto the DDS Databus without authorization.

For example, suppose that we have Trudy, a DDS application with a DataWriter that is not supposed to publish Topic T. In an unsecure scenario, Trudy and Bob will discover each other, then Trudy will start sending data samples to Bob. This could be a major problem since Bob may be receiving legitimate samples from Alice as well as forged samples from Trudy.

The Security Plugins provide mechanisms for authenticating both publisher and subscriber applications, preventing unauthorized publication from outsiders. Also, the Security Plugins put in place access control mechanisms to prevent insiders from publishing without authorization.

1.1.3. Tampering And Replay

Tampering involves intercepting and modifying data before sending it to the legitimate subscriber.

This attack can have severe consequences since the attacker could modify the parts of the message they are interested in. For example, in a bank system a legitimate subscriber Mallory could be receiving data samples for a Topic T. This Topic could have transaction information with sender, receiver and amount. Mallory could modify the receiver of the transaction and publish the modified samples without anyone noticing it.

Mallory could also perform replay attacks by resending the data without modification. In any case, Mallory could create serious problems without security being enabled.

The Security Plugins put in place mechanisms to protect the integrity of data, hence preventing tampering and replay attacks.

1.1.4. Crossing Domains

All the threats described above could cross DDS domains if an infrastructure service, such as RTI Routing Service, joins a domain being attacked by malicious DomainParticipants.

1.2. Applying DDS Protection

There are two major types of protection that you can achieve with the Security Plugins. Domain-Level Protection allows you to protect your entire DDS domains against outsiders, preventing any unauthorized actions by any unauthorized adversaries that are not supposed to participate in the domain. There is also Granular Protection Inside Domains which enables more advanced kinds of protection to prevent unauthorized actions by legitimate participants within the domain. This second approach is based on the Principle of Least Privilege, so DomainParticipants do not get to know more than what they need to, for the tasks they are required to do.

1.2.1. Domain-Level Protection

Domain-level protection assumes that the network is the adversary. In other words, it assumes that adversaries can do anything in the network. To achieve domain-level protection, the network protocol is secured, therefore protecting the system against any types of threats that can live inside the network. The goal of this secured protocol is to prevent any unauthorized actions by any adversaries that are not supposed to participate in the domain. Domain-level protection can provide integrity as well as confidentiality.

1.2.1.1. Domain-Level Protection Threat Model

The domain-level protection threat model assumes that the adversary can do almost anything in the network, such as:

  • the adversary can obtain any message passing through the network

  • the adversary itself could be a legitimate user of the network and thus can initiate and participate in a conversation with any other user

  • the adversary can become the receiver of messages

  • the adversary can send messages to anybody through impersonation

  • any message sent will go through the adversary

  • any message received has gone through the adversary

These assumptions involve serious threats that can come from the network and that can have undesired consequences at the DDS level, for example:

  • unauthorized consumption or production of data

  • tampering with data

  • unauthorized replay of legitimate data

The Security Plugins protect your DDS systems against all those undesired capabilities, by implementing the OMG DDS Security specification’s builtin mechanisms. Note that the OMG DDS Security specification defines a network security model, by securing the network protocol. This implies that from the DDS Security perspective, the local machine is assumed to be trusted.

Important Note

The OMG DDS Security specification assumes that everything that happens inside the machine is trusted. As a user, you have to make sure that you have all the protection mechanisms in place that are not related to the network protocol. For example, make sure you have all the protection mechanisms related to your file system and the physical protection of your local machine, such that it becomes a trusted platform.

The threats that are associated with the platform are outside of the scope of DDS Security (and therefore outside of the scope of Security Plugins).

1.2.1.2. Domain-Level Protection From Outsider Adversaries

Domain-level protection is a fairly simple model but it may be good enough for some situations. With domain-level protection, your protected domains are the boundaries. You provide the participants with the ability to join the domain, and once a participant is in the domain, it can do anything. Hence, for legitimate participant, the domain looks like an unsecure DDS Domain, and the same protection applies to every topic in the domain (see Figure 1.2). All participants need to do is to authenticate and prove they have the right to participate, after which they can do anything as if security were disabled.

Figure 1.2 Protecting the DDS Domain at the Boundaries

Using domain-level protection, the Security Plugins can prevent unauthorized RTPS protocol actions by outsider adversaries which should not join the domain. In particular, Security Plugins can:

  • detect the modification or injection of messages (integrity)

  • keep message contents secret (confidentiality)

This is done by including additional information in the RTPS messages sent by your Secure Participants, as explained in Protecting the RTPS Protocol.

Domain-level protection can be achieved with TLS as a transport since it forces authentication between participants. This can be useful in some scenarios, but it presents some drawbacks with respect to using the Security Plugins, as described in Choosing the Right Technology to Protect Your Data.

1.2.2. Granular Protection Inside Domains

Protection inside domains provides more advanced kinds of protection by following the Principle of Least Privilege, which implies that participants do not get to do (or know) more than they need to do (or know) in order to complete their tasks. This Principle of Least Privilege is based on read and write access rules per topic and partition. After you define these access rules, the Security Plugins detect and prevent violations of these access rules.

1.2.2.1. Granular Protection Threat Model

Similarly to the domain-level protection thread model, protection inside domains assumes that the network is the adversary. However, it also considers that there can be malicious insiders in the system, in addition to outsiders. Insiders are legitimate participants that are allowed in the domain, but that perform actions they’re not supposed to do. These actions range from unauthorized subscription and publication to data replay and tampering, as described in Description of DDS System Threats.

1.2.2.2. Applying Granular Protection Inside Domains

In addition to the domain-level protection, where you protect your system from outsiders that are not supposed to participate in the domain, protection inside the domain implies that there are different levels of trust within the domain (between all the participants allowed to participate in the domain). This follows the Principle of Least Privilege per DomainParticipant, meaning that each participant will only be allowed to perform the required actions for its legitimate purpose. You cannot achieve granular protection inside domains with TLS transport security.

To use this model, you have to identify the required publish/subscribe authorizations. You have to answer the question, “what does each participant need to publish or subscribe to, in order to do its job?” This authorization has to happen with the granularity of per Domain, per Topic, or per partition.

Once you identify these required authorizations, you can define access rules accordingly. In other words, once you know what each participant needs to do to accomplish its tasks correctly, you can write access rules on a per-participant basis. Each rule defines which Topics or partitions a DomainParticipant is allowed to publish, and which Topics or partitions it is allowed to subscribe to. The Security Plugins will detect and prevent any violations of these rules. For example, they will keep the data secret for those who do not have a need-to-know; and they will detect unauthorized injection or replay of data by those who are not allowed to modify data.

Figure 1.3 Granular Protection Inside Domains

Figure 1.3 depicts a scenario where three participants (P1, P2, and P3) have permission to both publish and subscribe to the blue Topic, while only P1 has these permissions for the red Topic – P2 can still subscribe to it (single-headed arrow), but P3 does not have access to it. As this scenario suggests, the protection inside domains applies to specific Topics and partitions, and not every DomainParticipant is allowed to publish or subscribe to every Topic or partition. You can protect the confidentiality and integrity of each Topic and partition independently. So, for each of your Domains, you can apply different protections as needed at the granularity of per Topic or per partition.

1.2.3. Protecting the RTPS Protocol

To prevent unauthorized actions in your secure domain, the DDS Security specification adds security enhancements to the RTPS protocol. Since you may face open networks, where anyone could join and start receiving the data, the only protection mechanism available is to protect the RTPS messages themselves.

The Security Plugins will add information and modify the RTPS messages to protect them. Authentication and key establishment, which are performed by DomainParticipants using the Builtin Security Plugins, use asymmetric cryptography. Conversely, all the protections applied at the RTPS level are based on symmetric cryptography, which is required for highly performant, one-to-many distribution with one-time encryption. Therefore, both the sender and receiver need to know the secret symmetric key.

The OMG DDS Security specification uses three different kinds of symmetric keys:

Note

Unless the documentation indicates differently, the keys (or Key Material) associated with the Secure Entities are considered to be AXK.

Note

Security Plugins’s cryptographic algorithms never use the Key Material directly to protect communications. Security Plugins always derives temporary Session Keys from the Key Material. For more information, please refer to Architecture of Secure Entities.

Note

We refer to “senders” and “receivers” (as opposed to DataWriters and DataReaders). This is because both DataWriters and DataReaders can act as sender and receiver (for example, a DataWriter can send a HEARTBEAT and its matching DataReaders need to respond with an ACKNACK).

The supported cryptographic algorithms that you can use with the Security Plugins are specified in Supported Cryptographic Algorithms.

1.2.3.1. Protecting Bootstrapping

As we covered above, DomainParticipants exchange AXK keys after the authentication process is complete (using the Secure Key Exchange Builtin Topic). As a consequence of this, certain RTPS messages cannot be protected using AXK keys. These include messages used during authentication, messages used to detect initial presence, and lower-level messages used to detect and maintain network connectivity. The OMG DDS Security specification groups all of these kinds of messages as RTPS Bootstrapping messages.

An RTPS message is called a RTPS Bootstrapping message if and only if one or more of the following conditions applies:

  • It contains RTPS submessages for the SPDP Participants Builtin Topic (DCPSParticipant/DCPSParticipants).

  • It contains RTPS submessages for the SPDP2 Bootstrap Builtin Topic (DISCParticipantBootstrap).

  • It contains RTPS submessages for the Authentication Builtin Topic (DCPSParticipantStatelessMessage).

  • It contains RTPS submessages for the Secure Key Exchange Builtin Topic (DCPSParticipantVolatileMessageSecure).

  • It is not intended to be processed by a DomainParticipant (e.g. it is a transport-level keep-alive message).

Since RTPS Bootstrapping messages cannot be protected using AXK keys, Pre-Shared Key Protection is the mechanism the OMG DDS Security specification designates to protect RTPS Bootstrapping messages. To learn more about how Pre-Shared Key Protection works, read the Pre-Shared Key Protection section.

1.2.3.2. Protecting Integrity

Protecting the integrity of the messages is achieved by appending a Message Authentication Code (MAC) to the original message. By default, this code is 16-bytes long. The contents of the MAC depend on the original message’s contents as well as a secret key. You need the secret key to both create and validate a MAC, as depicted in Figure 1.4. Therefore both the sender and receiver need to know the secret key. The same secret key is used by the sender and all its receivers. If there is a failure to validate the MAC on the receiver side, that implies a breach of integrity.

Figure 1.4 Creation and validation of a message by means of a Message Authentication Code

1.2.3.3. Protecting Confidentiality

MACs provide integrity protection, therefore an attacker will not be able to tamper with data, since modifications to data will be detected as a failure to verify the MAC. However, the MAC itself does not protect confidentiality. If you need confidentiality, the data has to be encrypted before it is sent on the wire. The encrypted bytes are generated from the message and a secret key. Therefore, both sender and receiver need to know the same key.

Encryption itself does not guarantee data integrity. Therefore, the Security Plugins compute a MAC over the encrypted data and include it in the resulting message. In practice, the OMG DDS Security specification defines integrity protection and confidentiality plus integrity protection.

Following the philosophy of the OMG Data Distribution Service (DDS) standard the OMG DDS Security specification follows a data-centric model, where everything is distributed. This implies that all legitimate participants joining the DDS Domain will execute the required protection. That is how they can communicate with each other (they execute the same types of protection) while outsiders are prevented from participating (because of that protection). In other words, if a participant does not execute the required protection, it will not be able to communicate with the rest of participants in the Secure Domain.

1.2.3.4. Origin Authentication Protection

You can also enforce Data Origin Authentication. For example, if you have a DataWriter that matches with multiple DataReaders, all the readers receive the data from the same writer. Hence, all the readers need to know the same secret key that is used to encrypt and decrypt the data and to compute and validate the MAC. If this secret key is shared between hundreds of readers, then all these readers have the knowledge to reproduce the encryption and the computation of the MAC because the key is the same as the one used by the writer. In other words, a reader could impersonate a writer, producing a breach of the access control mechanism. If readers don’t trust each other, you can put in place the Origin Authentication Protection.

This type of protection requires additional keys to be utilized in the system. More concretely, in addition to the Sender Key, we will have one Receiver-Specific Key per sender-receiver pair. Note that both DataWriters and DataReaders can act as senders and receivers. Also, RTPS messages and submessages will be appended with additional MACs (one per receiver).

In the previous example, the DataWriter will append a list with the additional Receiver-Specific MACs to the Common MAC. Then, after regular Common MAC validation, every DataReader has to find its Receiver-Specific MAC inside that list and verify that the Receiver-Specific MAC was calculated with the secret key it specifically created for use between itself and the DataWriter. By verifying the Common MAC, the DataReader can trust that data was not tampered with by anyone who doesn’t have the Sender Key, since that key is needed to generate the common MAC. And by verifying the Receiver-Specific MAC the DataReader can verify the matching DataWriter sent that data since it is the only entity the Receiver-Specific Key was shared with.

1.3. Introduction to the Security Plugins

Security Plugins allow you to address your databus security requirements in a granular and pluggable way. To support this, Security Plugins defines a plugin-based architecture, where each plugin covers a different aspect of security:

  • Authentication. Provides the means to verify the identity of the application and/or user that invokes operations on DDS. Includes facilities to perform mutual authentication between DomainParticipants and establish a shared secret.

  • Access Control. Provides the means to enforce policy decisions on what DDS-related operations an authenticated entity can perform. For example, which Domains it can join, which Topics it can publish or subscribe to, etc.

  • Cryptography. Implements (or interfaces with libraries that implement) all cryptographic operations including encryption, decryption, hashing, digital signatures, etc. This includes the means to derive keys from a shared secret.

  • Logging. Supports auditing of all DDS security-relevant events, allowing you to increase the system’s visibility, which may help track and improve system’s availability. These security-related events can be propagated securely through DDS.

The OMG DDS Security 1.2 specification defines two sets of builtin plugins for providing interoperable authentication, access control, cryptography, and a secure logging topic. Similarly, Security Plugins provide two different sets of plugins:

  • Builtin Security Plugins: the RTI implementation of the OMG DDS Security builtin plugins (defined in OMG DDS Security 1.1 specification).

  • Lightweight Builtin Security Plugins: the RTI implementation of the OMG DDS Security builtin PSK plugins (defined in OMG DDS Security 1.2 specification). This implementation is meant to support resource-constrained environments that are not capable of running Builtin Security Plugins.

This way, the Security Plugins offer a DDS Security solution that can interoperate with DDS implementations from other vendors.

Figure 1.5 Architecture of an application using Security Plugins. Security Plugins provide two different sets of plugins: Builtin Security Plugins and Lightweight Builtin Security Plugins.

1.3.1. Features of Security Plugins

  • Decoupled plugins to address different security aspects, as defined in the OMG DDS Security specification.

  • The Security Plugins can potentially run over any transport, including the builtin UDP transport with multicast and TCP transport.

  • Secure multicast support enables efficient and scalable distribution of data to many subscribers.

  • You can customize the Security Plugins to accommodate proprietary or FIPS 140-2 compliant cryptography solutions, take advantage of custom security hardware or change the behavior of the plugins in any number of ways. The Security Plugins SDK enables you to customize the Security Plugins to meet your system’s security requirements.

  • The OMG DDS Security specification addresses the security aspect of the communication in a one-to-many, friendly, data-centric way, enabling applications to define different security policies based on the nature of the shared data. This aligns with the decentralized nature of DDS and asserts its benefits:

    • No single point of failure

    • High performance and scalability

1.3.2. Supported Cryptographic Algorithms

A cryptographic algorithm is a well-defined computational procedure that takes variable inputs, including a cryptographic key and produces an output.

The Security Plugins implement a variety of cryptographic algorithms to support different aspects of security. In particular, the Security Plugins implement all of the cryptographic algorithms specified by the OMG OMG DDS Security specification. In this section we will list all of the algorithms the Security Plugins use.

1.3.2.1. Cryptographic Algorithms Used for Data Flow Protection with Pre-Shared Key Protection

  • Data integrity and confidentiality:

    • Algorithms: AES-GMAC (integrity) or AES-GCM (integrity + confidentiality)

    • Key sizes: 128 or 256 bits

  • Data source authentication:

    • None

1.3.2.2. Cryptographic Algorithms Used for Data Flow Protection

  • Data integrity:

    • Algorithms: AES-GCM, used in GMAC mode (not configurable)

    • Key sizes: 128, 192 or 256 bits (selectable via configuration). The OMG DDS Security 1.1 specification does not support AES-192 algorithm. AES-192 is a deprecated option and may be removed in a future release.

  • Data confidentiality, which includes integrity:

    • Algorithm: AES-GCM (not configurable)

    • Key sizes: 128, 192 or 256 bits (selectable via configuration). The OMG DDS Security 1.1 specification does not support AES-192 algorithm. AES-192 is a deprecated option and may be removed in a future release.

  • Data source authentication:

    • Algorithms: AES-GCM, used in GMAC mode (not configurable)

    • Key size: 256 (not configurable)

By default, the Cryptography Plugin uses AES-256-GCM for protecting the confidentiality and integrity of the messages and AES-256-GMAC when only protecting the integrity is required. This implies that the symmetric keys will be 256-bit long, but you can also use 128- and (deprecated) 192-bit keys (see the dds.sec.crypto.symmetric_cipher_algorithm property in Table 6.8).

As stated by the OMG DDS Security specification, the use of (Galois) counter mode allows authenticated decryption of blocks in arbitrary order. This is very important for DDS because a DataReader may not receive all the samples written by a matched DataWriter. The use of DDS ContentFilteredTopics as well as DDS QoS policies such as History (with KEEP_LAST kind), Reliability (with BEST_EFFORT kind), Lifespan, and TimeBasedFilter, among others, can result in a DataReader receiving a subset of the samples written by a DataWriter.

The AES-GCM transformation produces both the ciphertext and a message authentication code (MAC) using the same secret key. This is sufficient to protect the plaintext and ensure integrity. However there are situations where multiple MACs are required. For example when a DataWriter shares the same key with multiple DataReader and, in spite of this, the DataWriter needs to ensure message-origin authentication. In this situation the DataWriter should create a separate “reader-specific key” used only for authentication and append additional reader-specific MACs, each computed with one of the reader-specific keys.

1.3.2.3. Cryptographic Algorithms Used for Key Exchange

  • Key establishment:

    • Support for Diffie-Hellman in ephemeral mode (DHE), with 2048-bit MODP Group parameters as specified in RFC 3526 (not configurable).

    • Support for EC Diffie-Hellman in ephemeral mode (ECDHE), with secp256r1 as specified in FIPS PUB 186-4 [1] as its curve.

    • Support for EC Diffie-Hellman in ephemeral mode (ECDHE), with secp384r1 as specified in FIPS PUB 186-4 [1] as its curve.

    • << EXPERIMENTAL >> Support for EC Diffie-Hellman in ephemeral mode (ECDHE), using X25519 as specified in RFC7748 (https://datatracker.ietf.org/doc/html/rfc7748). Only supported in the Security Plugins for OpenSSL, disabled by default (see the authentication.enable_custom_algorithms property in Table 4.2).

    • << EXPERIMENTAL >> Support for EC Diffie-Hellman in ephemeral mode (ECDHE), using X448 as specified in RFC7748 (https://datatracker.ietf.org/doc/html/rfc7748). Only supported in the Security Plugins for OpenSSL, disabled by default (see the authentication.enable_custom_algorithms property in Table 4.2).

    • Selection of the key establishment algorithm happens via configuration.

  • Key derivation:

    • HMAC-based Key Derivation Function (HKDF) with SHA-256 as specified in RFC5869 (not configurable).

  • Key exchange confidentiality, which includes integrity:

    • AES-GCM with 256 bits key (not configurable).

1.3.2.4. Cryptographic Algorithms Used for Digital Signatures

  • Builtin support for 2048-bit RSA key pairs with SHA-256

    • Support for RSASSA-PSS as specified in PKCS #1 (RFC 3447), using MGF1 with SHA-256 as a mask generation function.

    • Support for RSASSA-PKCS1-v1_5 as specified in PKCS #1 (RFC 3447). The OMG DDS Security 1.1 specification does not support this algorithm.

    • Selection between RSASSA-PSS and RSASSA-PKCS1-v1_5 happens via configuration (see the authentication.rsa_pss_pad property in Table 4.2).

  • Builtin support for ECDSA secp256r1 key pairs with SHA-256

    • The curve is as specified in FIPS PUB 186-4 [1], and the digest algorithm is SHA-256.

  • Builtin support for ECDSA secp384r1 key pairs with SHA-384

  • << EXPERIMENTAL >> Builtin support for EDDSA Ed25519 key pairs.

  • << EXPERIMENTAL >> Builtin support for EDDSA Ed448 key pairs.

    • The algorithm used is PureEdDSA and the curve Ed448 as specified in RFC8032 (https://datatracker.ietf.org/doc/html/rfc8032) with the context parameter set to zero. Only supported in the Security Plugins for OpenSSL, disabled by default (see the authentication.enable_custom_algorithms property in Table 4.2).

    • The OMG DDS Security 1.1 specification does not include this curve.

    • This curve is not supported in the context of signing Governance or Permissions documents.

  • Selection of the key pairs happens via configuration

1.3.3. Choosing the Right Technology to Protect Your Data

If your main goal is domain-level protection, you may want to protect your transport by using TLS instead of using the Security Plugins. This transport layer is well known and well documented, and the protection level that you will have is identical to that of the Security Plugins unless you need fine-grained control. However, there are some differences between securing the transport and using the Security Plugins.

DDS Security is a standard from the OMG, while the TLS transport is a component provided by RTI, but not standardized. Consequently, a Connext application using a TLS transport will not interoperate with other vendor’s implementations.

TLS applies at the transport layer, so it secures the pipe. On the other hand, DDS Security provides finer control, as described in Granular Protection Inside Domains. With TLS you can protect the information that goes on the wire between two DDS applications, but you cannot, for instance, give different permissions to different applications. All of your applications must have the same level of access control, only the pipe is secured. With Builtin Security Plugins, you have finer control, so you can, for instance, give an application permission to publish or subscribe to data on a DDS Domain but only for a subset of the topics. This is possible in the Builtin Security Plugins, but not in the Lightweight Builtin Security Plugins. For more information about choosing one library or the other, see Pre-Shared Key Protection in Lightweight Builtin Security Plugins vs. Pre-Shared Key Protection in Builtin Security Plugins.

There are also performance implications. TLS does not support multicast, therefore your data will be re-encrypted as many times as the number of destinations, which seriously constrains your system’s scalability. One of the nice features of Security Plugins is that it supports secure multicast communications, so you can scale your one to multi-end communications. See Interaction Between the Security Plugins and Multicast.

Finally, there is the aspect of pluggability. You cannot adapt the TLS transport easily. With the Security Plugins, you can for instance plug in your own encryption, or your own signing algorithms. With TLS, you can only use what the transport has to offer.