Securing DDS with SGX: Building Encrypted Applications Using SCONE & Micro DDS

This is Part 2 in a six‑blog series on this topic. If you missed the Part 1 overview, please read it here.

Why SGX Requires Re‑Architecture

Intel® introduced Software Guard Extensions (SGX) with the promise of isolating sensitive code and data in a protected enclave. The original SDK guidance encouraged developers to redesign their applications from the ground up or to re‑architect existing code so that secrets and the logic that manages them live in a separate partition. This approach keeps the trusted computing base (TCB) as small as possible, directly addressing many of the attack vectors that threaten modern distributed systems.

The Cost of Refactoring Existing Applications

Re‑architecting mature codebases is labor‑intensive. In a joint study between Intel and the United States Air Force Academy, an open‑source PDF viewer was transformed to support fine‑grained access control and digital redaction. A separate open‑source video teleconferencing application was modified to encrypt media streams before they reached the display. Both projects required roughly two man‑years of effort to complete.

Alternative Pathways: SGX‑Protected Containers

Because the refactoring process is expensive—and often impossible when source code is unavailable—several projects have emerged to simplify SGX integration. Notable examples include Graphene and SCONE, which provide SGX‑protected containers and cross‑compilers that work with existing binaries. In this post we focus on SCONE, which can build RTI Connext DDS Micro and its security plugins with only minor adjustments to build scripts or lightweight library tweaks.

SCONE also produces a statically‑linked executable that runs on a vanilla Ubuntu 16.04 installation equipped with the SGX driver and a compatible CPU. Graphene, by contrast, requires adding a new system call (getifaddrs) or modifying DDS to avoid it, as well as several changes to other DDS calls such as nanosleep. Additionally, Graphene applications must run inside a Docker container. For those reasons we start with SCONE in this article.

Preparing Your Build Environment

The SCONE cross‑compiler bundles a musl‑based toolchain that statically links all dependencies. To compile RTI DDS Micro and OpenSSL, you need the following resources:

• RTI DDS Connext Micro 3.0 (source code available by licensing from RTI)
• OpenSSL 1.0.2r source (download here)
• SCONE container images (private; request access at info@scontain.com)

Your host machine should support SGX and run Ubuntu 16.04 LTS. If you have an SGX‑capable CPU, install the driver from GitHub. Familiarity with Docker and Linux is assumed.

Place the two source tarballs in your home directory and unpack them, creating these directories:

openssl-1.0.2r
rti_connext_dds_micro-3.0.0

All subsequent commands are relative to these paths.

Launching the SCONE Cross‑Compiler

cd ~
docker run -it --device=/dev/isgx -v "$PWD":/home sconecuratedimages/crosscompilers:ubuntu

If you do not have an SGX device, omit --device=/dev/isgx. Inside the container, add convenient utilities:

apt update
apt install -y make default-jre cmake nano less
apt install -y perl --reinstall

Building OpenSSL

The re‑installed Perl module resolves missing dependencies in the OpenSSL configuration script. Run:

cd /home/openssl-1.0.2r
./config
make
make test
make install
export OPENSSLHOME=/usr/local/ssl
ln -s /usr/local/ssl/lib/libcrypto.a /usr/local/ssl/lib/libcryptoz.a
ln -s /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libsslz.a

The symlinks accommodate the Makefile used later; they are a pragmatic solution that works reliably.

Compiling RTI DDS Micro 3.0

cp /opt/scone/cross-compiler/x86_64-linux-musl/lib/libpthread.a /opt/scone/cross-compiler/x86_64-linux-musl/lib/libnsl.a
PATH=$PATH:/opt/scone/cross-compiler/libexec/gcc/x86_64-linux-musl/7.3.0/
export RTIMEHOME=/home/rti_connext_dds_micro-3.0.0
export RTIMEARCH=sgxLinux_x64gcc
cd /home/rti_connext_dds_micro-3.0.0/
./resource/scripts/rtime-make -DRTI_NO_SHARED_LIB:bool=true -DOPENSSLHOME=/usr/local/ssl --delete --target self --name $RTIMEARCH -G "Unix Makefiles" --build --config Release

After completion, you’ll have OpenSSL and RTI DDS Micro libraries linked against musl, not glibc.

Building a Sample Application

cd /home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure
rm -rf objs
make

Both a publisher and subscriber executable appear in /home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure/objs/sgxLinux_x64gcc/. Run the publisher to see the runtime environment variables and enclave hash:

SCONE_VERSION=1 SCONE_HEAP=87108864 ./objs/sgxLinux_x64gcc/HelloWorld_publisher

Typical output includes SGX configuration settings and a unique enclave hash. Minor “error” messages about thread priority checks are benign; they stem from musl’s lack of support for certain glibc features and can be silenced by editing posixThread.c if desired.

Running Outside the Docker Container

Because the executable is statically linked, it can run on any Ubuntu 16.04 system with the SGX driver installed. First create a SCONE configuration file:

tee ~/sgx-musl.conf << EOF
Q 4
e -1 0 0
s -1 0 0
e -1 1 0
s -1 1 0
e -1 2 0
s -1 2 0
e -1 3 0
s -1 3 0
EOF

Then launch the publisher and subscriber:

cd ~/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure
SCONE_CONFIG=~/sgx-musl.conf SCONE_VERSION=1 SCONE_HEAP=87108864 ./objs/sgxLinux_x64gcc/HelloWorld_publisher
SCONE_CONFIG=~/sgx-musl.conf SCONE_VERSION=1 SCONE_HEAP=87108864 ./objs/sgxLinux_x64gcc/HelloWorld_subscriber

Successful communication confirms that the application runs inside an SGX enclave, even when executed outside the original Docker environment.

What We’ve Achieved

We’ve demonstrated a complete workflow for turning a standard RTI Connext DDS Micro application into a self‑contained, SGX‑protected binary using SCONE. While this “Hello World” example doesn’t cover persistent storage, remote attestation, or advanced security policies, it establishes a solid foundation for building hardened DDS services in SGX environments.

Stay tuned for Part 3, where we’ll explore how to harden DDS services for production deployments.