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

4 min read

DDS Security the Hard(ware) Way - SGX Part 3: Hardened DDS Services

DDS Security the Hard(ware) Way - SGX Part 3: Hardened DDS Services

**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. 

This is Part 3 in a six-blog series on this topic. If you’re new to this series, please read the previous blogs here.

In Part 2 of this series, I walked through how to create a hardened endpoint using RTI Connext DDS Micro + Security, SCONE and Intel SGX. While interesting, we haven’t yet examined a practical solution with built-in SGX. In Part 1, I hinted that DDS + SGX is more likely to appear in a server room rather than as a more traditional Industrial Internet of Things (IIoT) endpoint. In this installment, we will look at more practical solutions for an SGX-hardened DDS application through the lens of DDS services.

Many DDS services are prime targets for security hardening. They often subscribe to more topics, and in a DDS secure solution, they therefore have more access to ephemeral keys. These keys are stored by necessity in application memory. With skill and determination, a privileged user or attacker could extract them, or perhaps more effectively, could gather the data from system memory just after the DDS protections have been removed – or even alter data just before protections are added. After all, why bother with encryption when the data is already in plain text?


Figure 1: Attack Surface in DDS Environments

If you’ve been following along in this series, you may recall that in Part 1, I presented an architecture where DDS-protected packets could arrive on the wire and be passed into SGX-protected space before the DDS protection is removed. Once inside the application, SGX protects the data, and the DDS protection could be removed. Since the CPU can see the data in plain text, there is no need for exotic operations on encrypted data. This offers a distinct advantage over other protection methods such as homomorphic encryption.

This design allows for an application to take encrypted data on the wire, move it to a protected space before removing the encryption, operate on the data and add wire protection. If we can build one of these applications, then we can build many. In addition, since DDS is providing protection on the wire, we can have a heterogeneous network when non-SGX applications can communicate with SGX applications; some of those applications could be DDS services.

To illustrate this, let’s look at RTI Routing Service. The Object Management Group® (OMG®) DDS Security specification requires the Routing Service application code to operate on data in the clear, even if momentarily. In addition, Routing Service possesses all of the ephemeral keys from every endpoint from which it has communicated. Some architectures require that Routing Service appear at the edge of the network, increasing the risk of attack. As such, it is a high-value target for a malicious user.

Figure 2: RTI Routing Service Provides a Protected Space for Applications Running in SGX Environments

While we haven’t explored it yet, SCONE has built-in, transparent support for encrypted file stores as well as attestation. With built-in file stores, we can expand the functionality of our application. In the Routing Service example, we can now store the private keys used for identity in a protected space available only to the application; no root + user has access to them.

To take the idea further, we can now store any data to disk in a protected way.


Figure 3: DDS and RTI Routing Service is Protected in SCONE Environments

For instance, we can store DDS communications for authorized replay. SCONE supports native (and transparent) TLS communications with other authorized SCONE containers such as SQLite.

With these tools, we can build an infrastructure where all data is protected at all times, even against a malicious system administrator or attacker. Of course, an application needs to measure itself in a trusted way before it can be trusted to access trusted services, including its stores and network connections. This is the role of the attestation service.

The attestation service, in a nutshell, is a remote method of verifying that the application is unmodified, genuine and is running on a genuine SGX CPU. Essentially, the attestation service is a more trusted system which verifies that a less trusted system has – and can run safely – a trusted application. Originally, this service was exclusively provided by Intel, but things are changing.

Remote attestation may seem like an issue for many closed systems, particularly if the attestation is provided by Intel. However, it is not as difficult as one would imagine since an attestation for an application needs to occur just once, and the attestation survives a reboot. The process verifies the CPU and application through ISA instructions that have cryptographic integrity guarantees. Those values can be sealed to disk and reused as needed. This reuse can include an application that proves to the CPU it is unmodified, a CPU proving to a remote system it is genuine, or an application proving to another application that it is unmodified. These features are particularly useful in a distributed system to ensure that a particular application’s remote partner application is trustworthy.

As we have been using SCONE as our SGX framework, it is useful to point out that SCONE provides an attestation service. This service can be managed locally to your system if you are SCONE Enterprise license holder. SCONE has a global attestation service for non-enterprise users, and we will explore attestation with this global service later in the series.

In my next blog, I will explore the cost of security in DDS-SGX environments.


About the author

rti-blog-author-jason-upchurchDr. Jason Upchurch is a Cyber Security Research Scientist at RTI. Jason came to RTI from Intel Corporation where he was a Platform Security Architect and the Principal Investigator for a joint security laboratory with the US Department of Homeland Security, the United States Air Force Academy, and Intel. In addition to his work at RTI and Intel, Jason's security background includes serving as the most senior technical representative of the Cyber Protection and Digital Forensics Group at General Dynamics AIS and the Chief/General Manager of the Intrusions Group at the Defense Cyber Crime Center (DC3). Jason's operational service highlights include leading the forensic efforts in the early advanced persistent threat (APT) intrusions as well as several multi-million dollar financial intrusion investigations. Jason's research projects have included software similarity, compiled code reuse detection, hardware root of trust security, and hardware assisted attack detection. He received his Ph.D. in Engineering - Security at the University of Colorado, Colorado Springs.