Home / , , / DDS Security: Using signed governance and permissions documents

DDS Security: Using signed governance and permissions documents

Introduction

The DDS security specification defines five Service Plugin Interfaces (SPIs) that when combined together provide Information Assurance to DDS systems. For access control SPI, an important step is the usage of signed documents to configure the built-in plugin.

Configuration

From specification, the DDS:Access:Permissions plugin is configured with three documents:

  • The Permissions CA certificate
  • The Domain governance signed by the Permissions CA
  • The DomainParticipant permissions signed by the Permissions CA

The DDS application will get the path to the configuration documents  by setting them as a new value in the PropertyQosPolicy of the DomainParticipantQos. So, the DDS Security specification defines three properties names to set the path to each documents:

  • dds.sec.access.permissions_ca: URI to the X509 certificat for the permissions CA which is in PEM format.
  • dds.sec.access.governance: URI to the signed XML goverance document
  • dds.sec.access.permissions: URI to the signed XML permissions document

Step by step guide for configuration

An example of signing steps:

Let’s assume we already have the non-signed XML governance document(governance.xml) and permissions document(permissions.xml). It remains to sign these files with OpenSSL. The following is the command lines in bash.

Generation of Permissions CA private key:

openssl genrsa -out permissions_ca_private_key.pem 2048

Generation of Certificate for the Permissions CA

openssl x509 -req -days 3650 -in permissions_ca.csr \
 -signkey permissions_ca_private_key.pem \
 -out permissions_ca_cert.pem

Signing the governance document

openssl smime -sign -in governance.xml -text -out governance_signed.p7s \
 -signer permissions_ca_cert.pem \
 -inkey permissions_ca_private_key.pem

Signing the permissions documents

openssl smime -sign -in permissions.xml -text -out permissions_signed.p7s \
 -signer permissions_ca_cert.pem \
 -inkey permissions_ca_private_key.pem

Where the permissions_ca.csr comes from ?

In this example, it’s the self-signed certificate request for the permissions CA, an OpenSSL Certificate Authority configuration file (cnf extension) is required to generate this csr file. Please see the OpenSSL documentation for more details about cnf files.

Here is a command line example of csr generation from cnf:

openssl req -config permissions_ca_openssl.cnf \
 -new -key permissions_ca_private_key.pem \
 -out permissions_ca.csr

After running the commands above, we now have all needed documents:

  • permissions_ca_cert.pem: the Permissions CA
  • governance_signed.p7s: the signed XML goverance document
  • permissions_signed.p7s: the signed XML goverance document

The next step is to use them in the code:

Somewhere in your code, you could set the properties described above like this in Java:

PropertyQoS propertyQoS = PolicyFactory.getPolicyFactory(environment).PropertyQoS();

Collection<Property> properties = new ArrayList<Property>();

properties.add(new Property("dds.sec.access.permissions_ca","./permissions_ca_cert.pem"));
properties.add(new Property("dds.sec.access.governance","./governance_signed.p7s"));
properties.add(new Property("dds.sec.access.permissions","./permissions_signed.p7s"));

At the participant creation, you could do as following:

return participant_factory.createParticipant(
   domain_id,
   participant_factory.getDefaultParticipantQos().withPolicy(propertyQoS),
   null,
   (Collection<Class<? extends Status>>)null);