3. Securing a DDS Domain¶
In a DDS Secure system, a Governance Document defines the security requirements for communication. This file contains a mapping between Domain IDs and the security policies that DomainParticipants must follow to interact in that Domain. Some examples of those rules are:
Governance rule
Description
Possible values
discovery_protection_kind
The level of protection DomainParticipants must use for discovery
NONE
,SIGN
,SIGN_WITH_ORIGIN_AUTHENTICATION
,ENCRYPT
orENCRYPT_WITH_ORIGIN_AUTHENTICATION
allow_unauthenticated_participants
Whether unauthenticated DomainParticipants may communicate within the Domain
TRUE
orFALSE
data_protection_kind
The level of protection that should be used for data of individual Topics within that Domain
NONE
,SIGN
,SIGN_WITH_ORIGIN_AUTHENTICATION
,ENCRYPT
orENCRYPT_WITH_ORIGIN_AUTHENTICATION
Going back to our example, the hospital can now protect the confidentiality
of Topic T by setting its data_protection_kind
to
ENCRYPT
in the Domains
where it is published. With this, Eve will not be able to guess the vital
signs of the patients, even if she has access to the messages being exchanged
in the Secure Domain.
As you can see, the rules that compose the Governance Document specify how your system is protected. All the DomainParticipants in your secure system need to load the same 2 Governance Document, either by having a copy of it, or by accessing a single Governance Document from a common location.
In addition to meeting the security requirements specified in the Governance Document, every DomainParticipant joining a Secure Domain must be associated with a Permissions Document. This Permissions Document contains a set of grants, which determine what the local participant is allowed to do in the Domain.
For example, Alice should only have permission to publish Topic T, since her only mission is to monitor patient vitals. On the other hand, Bob’s role is to display everything related to patients’ health conditions. Therefore, he should have permission to subscribe to any Topic related to patients’ health, but he should not be allowed to publish any Topics. This step of creating Permissions Documents 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 Documents locks down the specific access that trusted applications have, so if one becomes compromised, the damage to the system is limited. 1
Key Terms
A Governance Document defines how your system is protected, while Permissions Documents define who can access what.
To prevent Mallory from pretending to have permission to both publish and subscribe to Topic T, both Governance and Permissions Documents are signed by the Permissions Certificate Authority (CA). The Permissions CA must be shared by all DomainParticipants 3, therefore any DomainParticipant trusting that Permissions CA can verify whether another DomainParticipant has the permissions it claims.
As you can see, Governance and Permissions Documents allow you to define the security requirements of your system in a data-centric way.
In Hands-On 2: Defining Your System’s Security Requirements, you will define the security requirements of your secure DDS Domain. All the DomainParticipants joining your Secure Domain will have to meet these requirements 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. 3 The Permissions CA certificate is used to verify that Permissions and Governance Documents are legitimate.Identity CA certificate:
Shared by all the DomainParticipants in your secure system. 4 The Identity CA certificate is used to authenticate the remote DomainParticipants, by verifying that the Identity Certificates are legitimate (see Securing a DomainParticipant).Governance Document:
Shared by all the DomainParticipants in your secure system. 2 The Governance Document specifies which Domains should be secured and how. It is signed by the Permissions CA.
Note
The Identity CA and Permissions CA may be the same, depending on your use case.
- 1
This approach is based on the Principle of Least Privilege. For further information, see Applying DDS Protection in the Security Plugins User’s Manual.
- 2(1,2)
If not the same, at least Governance Documents loaded by different DomainParticipants need to be compatible. For further information, see Governance Document in the Security Plugins User’s Manual.
- 3(1,2)
In systems where multiple Permissions Certificate Authorities may exist, you can use the
access_control.alternative_permissions_authority_files
property to specify alternative Permissions CA certificates. For further details, see Governance and Permissions in the Security Plugins User’s Manual.- 4
Depending on your use case, different DomainParticipants may trust a different Identity CA, for example, when several intermediate CAs exist in your PKI. For further details, see Alternative CAs in the Security Plugins User’s Manual.
3.1. Securing a DomainParticipant¶
As introduced in the previous section, the Permissions Document defines what a specific DomainParticipant is allowed to do in a secure DDS Domain. However, Permissions Documents need to be exchanged to claim and verify permissions. This means that Mallory, who will not give up that easily, may intercept some Permissions Documents and pretend to be the legitimate holder of those permissions. To avoid this situation, DomainParticipants in a Secure Domain need to be mutually authenticated. To achieve this, every secure DomainParticipant has an Identity Certificate and a Private Key. 5 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 Mallory from forging her own identity, 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.
If a DomainParticipant cannot be authenticated, it won’t be allowed
to publish or subscribe to protected Topics. Depending on the policies
defined in the Governance Document, it will be restricted to unprotected
Topics or it won’t be allowed to communicate at all (see
allow_unauthenticated_participants
in the
Related Governance Attributes for Authentication,
in the RTI Security Plugins User’s Manual).
Because Mallory cannot forge her own identity, she will fail to authenticate, thus she will not be able to claim any permissions. That guarantees that Mallory will not be able to publish or subscribe to Topic T.
In Hands-On 3: Defining the DomainParticipant Permissions, you will provide an identity to your DomainParticipants and set the permissions for each of them. The steps in this hands-on exercise guarantee that if an attacker is able to compromise a trusted application in the system, the damage they can do is limited. The following files define the identity and permissions of a DomainParticipant entirely:
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 Document signed by the Permissions CA. This document specifies what Domains and Partitions 6 the local participant can join and what Topics it can read/write.
![_images/artifacts.png](_images/artifacts.png)
Figure 3.1 Two DomainParticipants (P1 and P2) using the Security Plugins, along with all the security artifacts needed for communication.¶
- 5
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.
- 6
Partitions are outside the scope of this document. For more information, see Partitions in the Security Plugins User’s Manual and the PARTITION QosPolicy in the Connext DDS Core Libraries User’s Manual.