An embedded IoT device that transmits sensor data, receives commands, or delivers firmware without encryption is communicating in plain text across networks that may include public internet segments, shared Wi-Fi infrastructure, or cellular carriers. Any observer with access to the network path can read, record, and replay that traffic. Transport Layer Security - TLS for TCP-based protocols, DTLS for UDP-based protocols - is the standard mechanism that closes this attack surface, and implementing it correctly in resource-constrained embedded firmware is both essential and technically challenging.
TLS vs DTLS: Which to Use
TLS and DTLS provide the same security properties - confidentiality, integrity, and mutual authentication - but are designed for different transport protocols. TLS operates over TCP and can rely on TCP's guaranteed ordered delivery to simplify the handshake state machine. DTLS operates over UDP and must handle packet loss, reordering, and duplication that TCP eliminates, adding retransmission and sequence number mechanisms to the handshake and record layers. The protocol choice follows from the application protocol's transport choice: MQTT and HTTP/2 use TLS over TCP; CoAP uses DTLS over UDP. Both are implemented by the same library families - mbedTLS, wolfSSL, and BearSSL all support both variants.
| Dimension | TLS | DTLS |
|---|---|---|
| Transport | TCP | UDP |
| Ordered delivery | Provided by TCP | DTLS manages retransmission |
| Connection overhead | TCP + TLS handshake | DTLS handshake with flight retransmit |
| Typical use | MQTT, HTTP/2, gRPC | CoAP, DTLS-SRTP |
| Handshake complexity | Lower | Higher (retransmission handling) |
| Record layer overhead | ~5 bytes | ~13 bytes (sequence + epoch) |
Cipher Suite Selection for Embedded Platforms
TLS 1.3 eliminates many of the cipher suite combinations that created vulnerabilities in TLS 1.2, but TLS 1.3 support requires more flash and RAM than TLS 1.2 on constrained devices. For Cortex-M0 and Cortex-M3 class devices with limited flash, TLS 1.2 with a carefully selected cipher suite - ECDHE-ECDSA-AES128-GCM-SHA256 is a common choice - provides adequate security with lower resource requirements. For Cortex-M4 and above, TLS 1.3 with ECDHE and AES-128-GCM is preferred for its simplified handshake and improved forward secrecy guarantees.
Certificate Management on Embedded Devices
Certificate-based mutual TLS authentication requires each embedded device to hold a device certificate signed by a trusted CA, the corresponding private key stored securely, and the CA certificate used to validate the server's certificate. Certificate storage on devices with limited non-volatile memory requires careful allocation: a 2 KB device certificate, a 2 KB CA certificate, and a 256-byte ECDSA private key must fit within the device's certificate storage region without reducing flash available for firmware. HSM or secure element storage for the private key is strongly preferred over plain flash storage.
Certificate rotation - updating device certificates before they expire or after a key compromise - requires an update mechanism that can be triggered remotely. Certificate expiry across a large fleet is a common operational failure mode; embedded firmware must check certificate validity dates and proactively signal expiry approaching through the device management interface rather than silently failing TLS connections at the expiry date.
Lightweight TLS Libraries for Embedded Use
mbedTLS (now Mbed TLS under Arm) is the most widely used TLS library in embedded IoT contexts. It supports TLS 1.2 and 1.3, DTLS 1.2, configurable cipher suite selection, and has a well-maintained hardware acceleration interface for MCUs with cryptographic accelerators - AES hardware acceleration on STM32, NXP S32K3, and Renesas RH850 can reduce TLS handshake and record processing time significantly. wolfSSL is an alternative with a smaller flash footprint in minimal configurations and FIPS 140-2 validated builds available for compliance-sensitive applications. BearSSL offers the smallest footprint of the three but lacks DTLS support.
Implementing TLS and DTLS with RAPIDSEA
RAPIDSEA's IoT protocol stacks - MQTT, HTTP/2, gRPC, and CoAP - integrate with mbedTLS and wolfSSL through a common TLS abstraction layer that decouples the protocol stacks from the specific TLS library implementation. This enables TLS library selection based on platform constraints without modifying the protocol stack code. Hardware cryptographic acceleration is surfaced through the HAL's cryptographic abstraction, allowing AES and elliptic curve operations to be accelerated on supported MCU families transparently to the TLS library. Certificate storage integration connects to the RAPIDSEA EEPROM driver layer for secure, wear-levelled certificate storage on external NVM.
Conclusion
TLS and DTLS are non-negotiable security requirements for any embedded IoT device communicating over public or shared network infrastructure. Correct implementation requires cipher suite selection appropriate to the platform's resources and security requirements, certificate management that handles rotation and expiry proactively, and a TLS library integrated efficiently with the MCU's hardware cryptographic accelerators. RAPIDSEA's protocol stacks integrate with production TLS libraries through a hardware-portable abstraction layer - enabling embedded teams to add transport security to their IoT firmware without rebuilding the TLS integration from scratch.
Ready to strengthen your IoT communication security? Contact our team to request an evaluation build or book a technical demo.