2. Using Security Plugins

2.1. Securing Distributed Systems

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 all DomainParticipants must follow to interact in that domain. In other words, the Governance Document 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 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 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 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 application becomes compromised, the damage to the system is limited.

Key Terms

A Governance Document defines how your system is protected, while Permissions Documents define who can access what.

Both the Governance and Permissions Documents 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 Documents 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 Document 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 Documents 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 Document:
  Shared by all the DomainParticipants in your secure system. The Governance Document 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 Security Plugins 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 Documents. To verify that the Permissions Document provided by a remote participant is legitimate, Permissions Documents have to be signed by the Permissions CA. In addition, the grants in a Permissions Document 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 Document signed by the Permissions CA. This document specifies what Domains and Partitions the local participant can join and what Topics it can read/write.

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 Security Plugins 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.