Adding an mbedTLS Backend to Connext Micro Pre-Shared Key Security

Part 2 of a series on Connext Micro Pre-Shared Key Security

Part 1 of this series introduced the Connext Micro Platform Support Library (PSL) model and the two interfaces that separate DDS-Security^™ from the underlying cryptographic provider. The goal was simple: use RTI Connext Micro Lightweight Security to replace one crypto library with another, without modifying the DDS Security implementation.

To see whether that boundary was truly self-contained, we tried a small experiment. Instead of implementing a new backend ourselves, we used AI agents to build one using the mbedTLS PSA Crypto API. Can AI agents act as a proxy for a third-party developer with zero internal knowledge of the Connext Micro stack? The agents were given only the PSL documentation, the existing OpenSSL backend as a reference, and the PSA Crypto documentation.

The result was a working mbedTLS backend that passed the published NIST cryptographic verification vectors and interoperated with the existing OpenSSL implementation in both directions. More importantly, it demonstrated that the remaining implementation effort was focused on adapting provider-specific behavior, rather than filling gaps in the interface itself.

Implementing the Backend

Every PSK backend exports a single instance of the function table. This table defines the operations provided by the crypto library, including memory management, lifecycle functions, hashing, HMAC, HKDF, random number generation, and AES-GCM encryption.

The common PSK layer owns the security protocol and dispatches these operations through the function table. Because every backend implements the same interface, the DDS Security implementation remains unchanged, regardless of the underlying crypto library.

Most mappings from the PSL interface to PSA Crypto were straightforward:

• SHA-256 → psa_hash_operation_t
• HMAC-SHA-256 → psa_mac_operation_t
• AES-GCM → psa_aead_operation_t
• Random generation → psa_generate_random()
• HKDF → psa_key_derivation_operation_t

Building the Backend

Selecting a custom backend requires only a CMake option

export RTIME_MBEDTLS_HOME=/path/to/mbedtls

./resource.1.0/scripts/rtime-make --target <target> \

-DRTIME_CUSTOM_PSKPSL="transform/mbedtls" --build

The backend contributes its include directories and libraries through its own CMakeLists.txt, following the same integration pattern used by the existing OpenSSL implementation.

Documentation Mattered

The implementation relied primarily on the RTI Connext Micro Lightweight Security PSL SDK documentation, which is included with the Connext Micro 4.3.0 LTS download.

The SDK document has a Getting Started guide that defines the algorithm lifecycle, identifies every required entry in the function table, documents the responsibilities shared between the common layer and the backend, and explains the build integration.

The SDK document also has an architecture guide that explains how the generic DDS Security transform interface relates to the PSK-specific layer and how data flows through digesters, emitters, and manipulators.

Together with the OpenSSL backend, these documents provide enough information to implement a new provider without reverse engineering Connext Micro or modifying its internals.

Using AI as a Validation Tool

The AI setup was generic by design: one agent read the documentation and drafted an implementation plan, another wrote the backend, and a third reviewed the code and executed the verification suite.

What made the exercise worthwhile wasn't the generated code – it was what the process revealed about the SDK. If an independent implementation can be planned, built, reviewed, and tested without relying on internal knowledge, then the interface is exposing the right amount of information.

Testing from Algorithms to DDS

We first verified each primitive independently before testing a complete DDS application.

We validated the primitives using a combination of NIST Cryptographic Algorithm Validation Program (CAVP) vectors and RFC 5869 test vectors. The random number generator was verified using statistical distinctness tests.

Tests:

With the algorithms validated, we moved on to end-to-end interoperability.

A publisher and subscriber generated from the standard rtiddsgen PSK example were linked against different PSL backends, while keeping the DDS application unchanged. We exercised four positive configurations:

A Stable Boundary

This wasn't so much an experiment in AI-generated code. Rather, it was an experiment in interface design. If the PSL exposed the right abstractions, an independent implementer – human or AI – should be able to build a conforming backend without relying on undocumented knowledge of the DDS Security internals.

The mbedTLS backend is useful on its own, but the real result is validating the abstraction – narrow enough for independent implementations, flexible enough for different cryptographic libraries. That's the boundary that lets certified systems evolve without destabilizing what's already deployed.

Connext Micro 4.3.0 LTS brings this stability to the next generation of resource-constrained, mission-critical systems. Whether in automotive, avionics, industrial automation, or defense, it gives developers a foundation for building secure, reliable applications on the cryptographic stack their platform requires.

To read Part 1 of this series, please click here.

Ready to explore the capabilities covered here? Download Connext Micro 4.3.0 LTS today. If you don't have a Connext Micro license, please contact RTI to request an evaluation.

About the author:

Arul Moondra is a Staff Software Engineer at RTI specializing in security for embedded and real-time systems. With 10+ years of experience, he develops secure, high-performance middleware (RTI Connext Micro) focusing on systems where security, predictability, and reliability are critical.