3. Securing a DDS Domain

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 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 or ENCRYPT_WITH_ORIGIN_AUTHENTICATION
allow_unauthenticated_participants	Whether unauthenticated DomainParticipants may communicate within the Domain	TRUE or FALSE
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 or ENCRYPT_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 File specify how your system is protected. All the DomainParticipants in your secure system need to load the same 2 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 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 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 becomes compromised, the damage to the system is limited. 1

Key Terms

A Governance File defines how your system is protected, while Permissions Files 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 Files 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 Files 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 Files 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 File:
  Shared by all the DomainParticipants in your secure system. 2 The Governance File 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 Files loaded by different DomainParticipants need to be compatible. For further information, see Governance File 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 File defines what a specific DomainParticipant is allowed to do in a secure DDS Domain. However, Permissions Files need to be exchanged to claim and verify permissions. This means that Mallory, who will not give up that easily, may intercept some Permissions Files 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 File, 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 File 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.

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.