Success-Plan Services
Arul Moondra
OpenSSL is not an option on every embedded target. The constraints vary. Some systems have strict memory and storage limits. Others must meet licensing, platform-support, or certification requirements. One project may already use mbedTLS or wolfSSL, while another may need to use a hardware cryptographic engine through a vendor-provided C driver.
Tying middleware security to a single cryptographic library would exclude many of the embedded systems that Connext Micro is designed to support.
Connext Micro avoids that dependency through its Platform Support Library (PSL). In this post, we examine where the PSL fits within the security architecture, the two levels of its interface contract, and how this design keeps DDS-Security™ independent of the underlying cryptographic provider.
Where the Crypto Boundary Sits
The central design choice is straightforward: the DDS-Security layer does not call a crypto library directly. Instead, calls pass through a common layer that manages object lifetimes, validates parameters, dispatches operations, and propagates errors. The actual cryptographic work is handed to a backend. That backend can use any provider that satisfies the PSL contract.
This approach keeps the integration surface small. Adding a backend does not require changes to the Connext security code or to the application. The new implementation only has to fulfill the contract exposed by the PSL.
There are two levels to that contract.
Two interfaces, with Different Jobs
The first level is the generic transform interface. Connext Micro implements the general security-transformation model. This interface covers mechanics: creating and deleting transform objects, managing bitstreams, passing parameters, starting operations, and collecting results.
It defines three kinds of bitstream:
- Digesters consume data for operations such as hashing.
- Emitters produce data, such as random bytes.
- Manipulators transform data, as required for authenticated encryption and decryption.
The generic interface deliberately does not name AES, HMAC, HKDF, or any other algorithm. Its job is to keep the DDS-Security implementation independent of a particular crypto library.
The second level is specific to Pre-Shared Key security. A generic transform contract alone cannot say which algorithms PSK needs or how those operations should be exposed.
It is a table of function pointers used by the common layer to dispatch crypto calls. The table contains three broad groups:
- memory – allocation, deallocation, and constant-time comparison
- library – crypto-library initialization, cleanup, and error reporting
- algorithm – sha256, hmacsha256, hkdfsha256, rand, aes128gcm, and aes256gcm
The call path is therefore easy to follow: Connext calls the common layer, the common layer dispatches and calls the backend. Connext never needs to know which crypto provider is underneath it.
A Narrow Boundary for Different Targets
The PSK PSL provides a clean boundary between the Connext Micro’s DDS-Security implementation and the crypto provider underneath it. To add a provider, simply implement the backend PSL interface, and add it to the build. The Connext stack does not need to change.
That is the practical value of the design. Teams can use the crypto library that fits their target – software or hardware-backed – without rebuilding the security feature around it.
In Part 2, we will show a successful application of this model: using the PSL SDK to add an mbedTLS backend, map the required operations to PSA Crypto, and verify the implementation with published test vectors and cross-backend interoperability tests.
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.