Skip to the main content.

Did you know?


RTI is the world’s largest DDS supplier and Connext is the most trusted software framework for critical systems.

Success-Plan-Services-DSSuccess-Plan Services

Our Professional Services and Customer Success teams bring extensive experience to train, problem-solve, mentor, and accelerate customer success.

Learn more


From downloads to Hello World, we've got you covered. Find all of the tutorials, documentation, peer conversations and inspiration you need to get started using Connext today.

Try the Connectivity Selection Tool ⇢


RTI provides a broad range of technical and high-level resources designed to assist in understanding industry applications, the RTI Connext product line and its underlying data-centric technology.


RTI is the infrastructure software company for smart-world systems. The company’s RTI Connext product is the world's leading software framework for intelligent distributed systems.

Contact Us

News & Events

5 min read

Become the Keymaster: Why You Should Use TPM with RTI Connext DDS Secure

Become the Keymaster: Why You Should Use TPM with RTI Connext DDS Secure

**Please note that with the April 2024 release of Connext Professional 7.3 LTS, the functionalities formerly comprising Connext Secure are now available as an optional component to Connext Professional, named Security Extensions.
Building secure systems and keeping them safe from increasingly sophisticated cyberattacks is a top challenge for developers. One way to combat this challenge is by using RTI Connext DDS Secure, the proven connectivity framework for building and securing complex distributed systems. Based on the DDS Security™ specification by the Object Management Group®, it provides robust, fine-grained security from device to cloud and everywhere in between. I wanted to share how using a Trusted Platform Module (TPM) device in conjunction with Connext DDS Secure makes a lot of sense for security-conscious developers.

First, a little background: When architecting a distributed system, the private identity of the individual nodes must of course be protected in order to ensure system security. So in configuring the system, developers need to determine the best way to distribute, store and protect the keys used to identify each node. While the common default of storing the keys on the node's persistent storage (hard disk, FLASH memory, etc.) may be convenient, it is certainly not very secure. In addition, many devices store information in an unencrypted manner, which also makes them susceptible to other types of attacks.

A Trusted Execution Environment (TEE) will protect the nodes (see our previous blog post on hardware security). However, TEEs are not widely available or widely used. In the absence of a TEE, the integrity of a DDS-based application cannot be guaranteed, as the same node might run rogue applications that could gain access to all the resources in a machine.

One solution to this problem is to store the identity key outside the node in a secure hardware device, where it cannot be physically accessed. In this approach, every cryptographic operation that requires access to the key must be implemented by the same hardware that protects the key. This is, after all, one of the main purposes of a TPM device.

TPM, also known as ISO/IEC 11889, is an international standard for a secure cryptoprocessor. This dedicated microcontroller authenticates hardware through integrated cryptographic keys. Each TPM chip contains an RSA key pair called the Endorsement Key (EK) that is maintained inside the chip and cannot be accessed by software.

There are two types of TPM chips: older chips that implement the TPM 1.2 specification, and newer versions based on TPM 2.0. While one of these variants is sometimes included on computer motherboards, the manufacturer does not always provide user access to them. So, you would need to do some investigation. TPMs are also available in other form factors, such as daughter cards.

Running a DDS Secure application that relies on the TPM (whether hardware or software) to protect the private keys of a node can significantly increase the security of a DDS-based system.

Putting the pieces together

The default RTI Connext DDS Secure Plug-in uses OpenSSL to perform every cryptographic operation. OpenSSL implements an ENGINE pluggable API in order to delegate some functionality to the appropriate hardware driver.

The following diagram shows how OpenSSL interfaces with a hardware device:


There are a few straight-forward steps required to configure DDS Secure to work with a TPM device:

  1. Ensure the system is able to identify and recognize the hardware TPM (low-level device driver).
  2. An OpenSSL ENGINE plug-in must be created or identified to delegate part of the cryptographic operations to the TPM (through the available driver API). Note: The default OpenSSL distribution does not include any support for TPM.
  3. The DDS Secure plugin must be configured to tell OpenSSL to use the specified engine.

1. System Support for TPM:

Operating system support for the TPM is dependent on the chip vendor. The modern version of Linux has a built-in kernel module available for several TPM vendors. Some embedded platforms might require additional support from the vendor in order to gain access to the TPM.

In RTI tests, we were able to successfully run DDS Secure applications using TPM (both 1.2 and 2.0) on Linux with a professional-grade laptop PC and a Raspberry PI. For the Raspberry PI, we used the Infineon Optiga SLB 9670 TPM with the device driver provided directly by Infineon. RTI users can access additional application notes that describe how to patch the Raspberry Pi Linux Kernel to add support for the Infineon TPMs.

2. OpenSSL Engines for TPM:

Open source support for TPM 1.2 is becoming quite obsolete. Most of the packages have not been upgraded in the last 5-6 years. Nevertheless, it is possible to build the current TrouSerS library and OpenSSL engine library (see OpenSSL TPM Engine sub-project) without too much effort.

In contrast, the open source support for TPM 2.0 is quite mature, with a rich set of tools and resources. The main TPM 2.0 project, is driven mostly by major hardware vendors. It contains several tools and libraries.

You can easily build tools and an OpenSSL engine for TPM 2.0 on any modern OS. Modern Linux kernels (newer than 4.14) also include a TPM resource management service, so you can easily share access to the physical TPM between multiple applications running on the same hardware. For older Linux versions, the open source community provides an Access Broker and Resource Manager daemon that interface with the dbus system to allow concurrent access to the TPM low-level driver from multiple applications.

3. DDS Secure Configuration:

Once you have a working hardware, driver and OpenSSL engine for the TPM, you can generate the private key used for the node identity through the TPM tools and OpenSSL command-line tool. Now you can generate the Certificate Signing Request (CSR). Have the TPM sign the CSR using the generated private key, and issue the identity certificate as usual. These steps are similar to the ones described in the getting started guide, with the exception of the key creation. Remember to specify the TPM engine through OpenSSL command-line using the -engine option. For example, to sign the CSR, use:

openssl req -engine tpm2tss -keyform engine -new -key
partATpmKey.keyblob -out partATpmCert.csr -config partATpmCert.conf

Note also that the -key parameter does not identify the real key, but instead a keyblob used to identify the internal private key (stored inside the TPM device).

At this point, when you have all the artifact files ready (keyblob, certificates, signed permissions and governance files) you can instruct DDS Secure to use the right OpenSSL engine and to load keys through the engine using the following properties:

  • specify the DDS Secure plug-in library that allows loading keys through the engine (see below)
  • specify the TPM OpenSSL engine to use (tpm2tss for TPM 2.0)
  • = "engine": tells the plugin to load the private key through the TPM and not from the file. The '' now identifies the keyblob
  • points to the file containing the keyblob used to identify the private key
  • [optional] to assign the TCTI to use for the TPM communication (i.e. "tabrmd" or "device:/dev/tpmrm0")
  • [optional] to set the user's TPM password (if the parameters are preset)

The latest version of the RTI Connext DDS Secure plug-in directly supports loading the keys through the OpenSSL engine. Previous Connext versions require additional code changes. Please contact RTI support if you want to use TPM on an older version of RTI DDS Secure.

For additional information on using TPM with RTI Connext DDS Secure, please access my more detailed documentation:


About the author

rti-blog-author-fabrizio-bertocciFabrizio Bertocci is a principal engineer at RTI. He has been with RTI for over 10 years. During his tenure, he has contributed to several parts of the RTI Connext DDS core libraries and products. He is currently with RTI Research, exploring new solutions, technologies and applications for DDS. Before joining RTI, he worked with EDA company Mentor Graphics, embedded silicon vendor VLSI (now NXP), along with technology start-ups. Fabrizio holds a Computer Engineering degree from the University of Pisa (Italy).