2. Using Connext DDS Secure¶
2.1. Securing Distributed Systems¶
In a DDS Secure system, a Governance File defines the security requirements for communication. This file contains a mapping between domain IDs and the security policies that all DomainParticipants must follow to interact in that domain. In other words, the Governance File defines what types of protection will be applied to your Secure Domains and how specific Topics will be protected.
All the DomainParticipants in your secure system need to load the same (or compatible) Governance File, either by having a copy of it, or by accessing a single Governance File from a common location. In addition to meeting the security requirements specified in the Governance File, every DomainParticipant joining a Secure Domain must be associated with a Permissions File. This Permissions File contains a set of grants, which determine what the local participant is allowed to do in the secure domain. For example, a publisher application, Alice, should only have permission to publish specific Topics; a subscriber application, Bob, should only have permission to subscribe to specific Topics, but not have permission to publish any Topics.
This step of creating Permissions Files goes beyond many traditional methods of security, where an application that is allowed to communicate within a secure system is generally assumed to be safe, and may be able to access data that it should not. The use of Permissions Files locks down the specific access that trusted applications have, so if one application becomes compromised, the damage to the system is limited.
Key Terms
A Governance File defines how your system is protected, while Permissions Files define who can access what.
Both the Governance and Permissions Files have to be signed by the Permissions Certificate Authority (CA). The Permissions CA must be shared by all DomainParticipants, therefore any DomainParticipant trusting that Permissions CA can verify whether another DomainParticipant has the permissions it claims (see Governance and Permissions).
Governance and Permissions Files allow you to define the security requirements of your system in a data-centric way.
All the DomainParticipants joining your secure domain have to meet the requirements specified in the Governance File in order to communicate. System-wide security requirements are completely defined by the following files:
Permissions CA Certificate:
Shared by all the DomainParticipants in your secure system. The Permissions CA Certificate is used to verify that Permissions and Governance Files are legitimate.Identity CA Certificate:
Shared by all the DomainParticipants in your secure system 1. The Identity CA Certificate is used to authenticate the remote DomainParticipants, by verifying that the Identity Certificates are legitimate.Governance File:
Shared by all the DomainParticipants in your secure system. The Governance File specifies which domains should be secured and how. It is signed by the Permissions CA.
For further details on these files, refer to Elements of a Connext DDS Secure System. Note that the Identity CA and Permissions CA may be the same, depending on your use case.
2.2. Securing a DomainParticipant¶
DomainParticipants in a Secure Domain need to be mutually authenticated. To achieve this, every Secure DomainParticipant has an Identity Certificate and a Private Key 2. These documents are needed to perform mutual authentication and to establish shared secrets in a secure way, by using the Diffie-Hellman public-key protocol.
To prevent attackers from forging identities, all the Identity Certificates in your system have to be signed by an Identity CA. As part of the authentication process, secure DomainParticipants will use the Identity CA certificate to validate the identity of discovered peers.
Authenticated participants claim permissions by exchanging their Permissions Files. To verify that the Permissions File provided by a remote participant is legitimate, Permissions Files have to be signed by the Permissions CA. In addition, the grants in a Permissions File are bound to an Identity Certificate, therefore only the DomainParticipant proving that identity in the Authentication can claim these permissions.
The identity and permissions of a DomainParticipant are completely defined by the following additional files:
Identity Certificate signed by the Identity CA. Other participants will request this certificate to verify the identity of the local participant.
Private key, only known to the local participant. It is needed to complete the authentication process, which provides a way of verifying the identity and setting a shared secret.
Permissions file signed by the Permissions CA. This document specifies what Domains and Partitions the local participant can join and what Topics it can read/write.
![../_images/artifacts.png](../_images/artifacts.png)
Figure 2.1 Minimal security artifacts needed for communication¶
Figure 2.1 depicts two DomainParticipants with the minimal security artifacts they need for communication. In Elements of a Connext DDS Secure System we will explore all of these elements in detail.
- 1
Depending on your use case, different DomainParticipants may trust a different Identity CA, for example, when several intermediate CAs exist in your PKI.
- 2
Private keys need to be securely stored and securely accessed by the local application. The Security Plugins do not provide a secure storage mechanism. You are responsible for storing your private keys in a secure place.