It isn’t enough to simply secure your system. You also need to plan for when system elements are compromised, whether through accident or by the actions of a malicious actor. When this happens (and it will), it is necessary to be able to quarantine those system elements until the problem is resolved.
For critical applications that cannot be brought down due to a security issue, you need to be able to perform this action dynamically, without reconfiguring and restarting the entire system. Simply revoking certificates of compromised elements isn’t enough. You need to make sure that all communication channels created using those certificates are closed down as well.
Multiple parts of your system have to work together to do this well, from threat detection to certificate management to the actual communication between devices. This type of integration can be challenging and it is important to do it right, as mistakes here can keep security issues from being handled on time and properly.
What This Example Does
This example shows how to configure a Connext® Secure application to banish and ignore participants that have been compromised, while keeping the system as a whole from shutting down. We will show how to remove participants from a live system after their certificate has expired or been revoked. And, how to go through the process of connecting or reconnecting elements after the problem has been resolved.
This Case+Code consists of the following elements:
- Configuration scripts for the generation of certificates and using those certificates to sign Connext Secure configuration files for use in a Connext Secure System
- An example Shapes-publishing application that can banish participants with revoked or expired certificates
- Instructions for running the demo
Running the Example
Download the Example
Make sure that you have the newest versions of RTI Connext and RTI Connext Secure installed and configured. The example has been tested on Windows 10 64-bit and Ubuntu 20.04 64-bit, but should be able to run on any system that can use RTI Connext Secure.
For Windows, you will need to have a bash shell installed, such as Git for Windows.
The example can be found on the RTI Community GitHub Repository. To run the example you need cmake and openssl installed.
The first step in running the example is to run the configuration script. The configuration script uses openssl to do the following:
- Generate an Identity CA Certificate
- Generate a Permissions CA Certificate
- Generate Identity Certificates for all participants
- Sign the Governance file
- Sign all Permissions files
The script can be found at CertificateRevocation/demo/. Run SetupSecurityFiles.sh.
The next step is to build the ShapePublisher application. Full instructions for building the example can be found in the RTI Community GitHub Repository.
Configuring Shapes Demo
For the demo you will need to configure two instances of the Shapes demo to act as ShapesDemoA and ShapesDemoB.
Open two instances of the ShapesDemo from the same directory as your ShapePublisher application. If your path variables are set up correctly you should just be able to run rtiShapesDemo.sh or rtiShapesDemo.bat
Once the demos are open, you will need to add the Quality of Service (QOS) file and select the appropriate profiles for both demo instances. You can do this by:
- Goto Controls»Configuration…
- Click Stop.
- Deselect Enable Distributed Logger.
- In the Choose the profile pull-down, choose
- Then click Start.
Shape Demo A allows for Publish and Subscribe, while Shape Demo B can only Subscribe.
Run the Custom Publisher
Full instructions for running the custom publisher can be found in the RTI Community GitHub Repository.
There are 3 types of configuration files used in Connext Secure applications. The QOS (Quality of Service) file, the Governance file and Permissions files. Here we will discuss QOS settings necessary for Connext Secure operation and specifically new settings necessary for lifecycle management. Discussion of Governance and Permissions files are found in the next section.
Domain Participant Configuration
Security configuration within the QOS file begins and ends with Domain Participant configuration. Security settings for topics datareaders and datawriters are handled in the configuration files detailed in the next section.
Below is an overview of the elements needed to configure a Connext Secure application. The QOS file described below can be found within the GitHub repository for this example here.
Note that even though many of these configurations are pointing at files, this is not strictly necessary. It is possible to include the information as text within the configuration file itself. Instead of specifying a file, specify data like this:
"data:,-----BEGIN CERTIFICATE-----\nabcdef\n-----END CERTIFICATE-----"
Although this isn’t recommended for most applications, it is an option.
Within Connext Secure applications, it is best to use a nested structure, with a base profile that handles root configuration, and inherited profiles that handle endpoint-specific details. This helps to create a cohesive configuration for the system, reducing QOS mismatch and making things work correctly the first time.
For the root configuration, we have this:
<qos_profile name="pmiRootSecure" base_name="BuiltinQosLib::Generic.StrictReliable">
Note that we are starting with the Generic.StrictReliable profile and adding two QOS snippets. We could have just as easily started with Best Effort, or some other base profile. The first QOS snippet, Optimization.Discovery.Endpoint.Fast, was chosen to help speed up discovery and is recommended for Connext Secure applications. The second snippet handles some basic configuration of the Domain Participant to enable our default Secure libraries.
Root Domain Participant Configuration
This setting is what enables key revisions – the mechanism that Connext Secure uses to banish participants from an active system. The value of 7 is somewhat arbitrary, with the important point being that it is not the value of 0. Note that setting this property to a non-zero value will make connecting to participants that do not have key revisions enabled impossible, breaking compatibility with applications running older versions of Connext Secure.
More information on this property can be found in Section 22.214.171.124 of the RTI Security Plugins User’s Manual.
Identify CA and Permission CA
This configures the location of the Public Certificates for certifying identity and permissions. Since these are different security considerations, configuration allows for different certificates for each, although many times the same certificate is used for both.
More information on these properties can be found in Section 3.2.1 of the RTI Security Plugins User’s Manual, including information on identity certificate chaining.
This configures the location of the governance file signed by the Permissions CA. Details about this file are found below.
Individual Participant Configuration
For individual participants, some settings should be unique for each participant.
By giving each datawriter, datareader and participant a unique name, we can make debugging easier and help differentiate each participant. Each of these settings can also be specified in code, and is in many cases. It is done in the configuration here because these names should match up with names within the configured Permissions files.
This setting points to an identity certificate, which should be unique for each device, if not for each participant. It must be derived from the Identity CA (or an intermediate CA), specified above. During discovery this certificate is sent over the wire in order to prove identity to other participants.
More information about this property can be found in Section 3.2.1 of the RTI Security Plugins User’s Manual, including information on identity certificate chaining.
The private identity key is used by Connext Secure for PKI communication. This should be the private key to the identity certificate configured above. It is this reason that identity certificates should be device- and/or participant-exclusive. Using common identity certificates across your system allows potentially compromised endpoints to pretend to be a different participant. It also makes certificate lifecycle management more difficult.
For options and different ways this property can be configured, refer to Table 4.1 of the RTI Security Plugins User’s Manual.
Signed permissions files, in addition to signed identity files, are sent over the wire during discovery to allow for proper connections between participants. This file must be signed by the Permissions CA, just like the governance file. Detailed information about this file can be found below.
Connext Secure Configuration
Configuration of a Connext Secure application begins with the QOS file detailed above. But is continued with the correct configuration of the Governance and Permissions files. These define security configuration for the system as a whole, where each participant fits into the system, respectively.
This is the basic structure of the security elements within each participant and the system as a whole.
The governance file used in this application can be found on GitHub here. For detailed information on all of the configuration of a governance file in Connext Secure see Section 3.3 of the RTI Security Plugins User’s Manual. It is highly recommended that you read this section of the User’s Manual before configuring your system.
For this example we are using the settings described in detail in the user manual.
The governance file is signed by the Permissions CA.
The permissions files used in this application can be found on GitHub here. For detailed information on all of the configuration of a governance file in Connext Secure see Section 3.4 of the RTI Security Plugins User’s Manual. Please read this section of the User’s Manual before continuing.
You should note that each of the permissions files uses this rule. This tag means that any action not explicitly allowed is prohibited, making this a white list based system, which although safer, is much more restrictive (which is what makes it safer). Depending on your system, you may configure your permissions with Allow Rules, Deny Rules, or a mixture of both. Please be aware of the security considerations for these decisions.
Each Permissions File is signed by the Permissions CA.
Note that Shape Demo A is configured to publish and subscribe to all topics. Also note that we are explicit in defining what is meant by all topics. If an additional shape and topic (such as Hexagon) was added to the system, this application would not be able to publish or subscribe to it.
Although similar to Shape Demo A, this application will only be able to subscribe to the shapes topics. Publishing to these topics by this application will be ignored by other participants.
Each Shape Publisher is restricted to publishing a single topic. This is about as restrictive as you can get within a Permissions configuration.
A great deal more information is available in the RTI Security Plugins User’s Manual. This resource goes into detail on all of the configuration elements described in this use case. It is highly recommended that you become familiar with the manual and use it when designing and configuring your system and applications.
Join the Community
Post questions on the RTI Community Forum.
Contribute to our Case + Code examples on RTI Community GitHub using these instructions.
Explore More with Connext
Check out more of the RTI Connext product suite and learn how Connext products can help you build your distributed systems. If you haven't already, download the free trial.