TLS for Embedded Systems

Quick Cap

TLS (Transport Layer Security) encrypts communication between embedded devices and cloud services, gateways, and other endpoints. It is not optional for production IoT -- any device transmitting sensor data, receiving commands, or performing OTA updates over a network needs TLS to prevent eavesdropping, tampering, and impersonation. The challenge in embedded systems is that TLS is expensive: a full handshake consumes 20-40 KB of RAM, 50-100 KB of flash, and seconds of CPU time on a Cortex-M. Understanding the handshake mechanics, authentication options, and optimization strategies is essential for any embedded engineer working on connected devices.

Interviewers test whether you understand how TLS works (not just "it encrypts things"), can walk through the handshake, know the difference between certificate and PSK authentication, and can discuss the real resource costs and trade-offs on constrained hardware.

Key Facts:

• TLS 1.3: 1-RTT handshake (vs 2-RTT in TLS 1.2), mandatory forward secrecy, removed insecure ciphers, supports 0-RTT resumption
• RAM cost: 20-40 KB for a TLS session on Cortex-M (mbedTLS); dominated by certificate parsing buffers and crypto state
• Flash cost: 50-100 KB for the TLS library; configurable by stripping unused cipher suites
• Hardware acceleration: Many MCUs include AES, SHA-256, and TRNG peripherals that reduce handshake time by 2-5x
• DTLS: TLS adapted for UDP -- required for CoAP security and some IoT protocols; adds replay protection and retransmission over unreliable transport
• PSK vs certificates: PSK avoids certificate overhead (smaller handshake, less RAM) but does not scale; certificates provide per-device identity and revocation

Deep Dive

At a Glance

TLS 1.2 vs TLS 1.3

TLS 1.3 is not just a version bump -- it is a significant redesign that removes complexity and improves both security and performance. For embedded systems, the differences are material.

Why 1.3 is faster: In TLS 1.2, the client sends ClientHello, waits for ServerHello + certificates + key exchange, then sends its key exchange + Finished -- 2 round trips before application data flows. In TLS 1.3, the client sends its key share (ECDHE public key) in the ClientHello itself. The server can immediately compute the shared secret and respond with encrypted data in one round trip. On a cellular link with 200 ms RTT, this saves 400 ms -- a meaningful reduction in connection time and radio-on duration for battery-powered devices.

Why 1.3 is more secure: By removing RSA key exchange, TLS 1.3 mandates forward secrecy -- even if a device's long-term private key is compromised, past sessions cannot be decrypted. By removing CBC-mode ciphers, it eliminates entire classes of padding oracle attacks (BEAST, POODLE, Lucky13) that plagued TLS 1.2 deployments.

TLS Handshake Walkthrough

Understanding the handshake step by step is one of the most common security-related interview questions for embedded roles. Here is the TLS 1.3 full handshake:

Client                                    Server
    |                                         |
    |  --- ClientHello ---------------------->|   Key share (ECDHE public key),
    |      Supported cipher suites,           |   supported versions, SNI
    |      random nonce                       |
    |                                         |
    |  <-- ServerHello -----------------------|   Selected cipher suite,
    |      Server key share (ECDHE pub key),  |   random nonce
    |      {EncryptedExtensions}              |
    |      {Certificate}                      |   All encrypted from here
    |      {CertificateVerify}                |   (server proves key ownership)
    |      {Finished}                         |   (server handshake MAC)
    |                                         |
    |  --- {Finished} ----------------------->|   Client handshake MAC
    |                                         |
    |  <===  Application Data  ===>           |   Encrypted with session keys

Step by step:

1. ClientHello: The client sends supported TLS versions, cipher suites, a random nonce, and an ECDHE public key (key share). On embedded devices, this is where the TRNG generates the random nonce -- a weak RNG here compromises the entire session.

2. ServerHello: The server selects a cipher suite and TLS version, sends its own random nonce and ECDHE public key. Both sides can now compute the shared secret via ECDHE.

3. EncryptedExtensions + Certificate + CertificateVerify + Finished: The server sends its X.509 certificate chain (so the client can verify identity), a signature proving it owns the private key corresponding to the certificate, and a Finished message that is a MAC over the entire handshake transcript. Everything from this point is encrypted with keys derived from the shared secret.

4. Client Finished: The client verifies the server's certificate against a trusted CA root, verifies the CertificateVerify signature, and sends its own Finished MAC. If mutual TLS (mTLS) is used, the client also sends its own certificate and CertificateVerify in this flight.

5. Application data: Both sides now have symmetric session keys (derived from the ECDHE shared secret) and exchange encrypted application data (MQTT, HTTP, CoAP payloads).

The TLS 1.2 handshake adds an extra round trip: the client does not send its key share in the ClientHello. Instead, the server sends its certificate and key exchange parameters first, and the client responds with its key exchange in a separate flight. This means the handshake takes 2 RTT instead of 1.

Certificate Authentication vs Pre-Shared Key (PSK)

Embedded deployments face a fundamental choice in how devices authenticate to servers (and vice versa).

When to use certificates: Any device connecting to a cloud IoT platform (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) must use X.509 certificates -- these platforms require mutual TLS. Certificates also provide per-device identity, which is essential for access control (device A cannot impersonate device B) and revocation (if device A is compromised, revoke its certificate without affecting device B).

When to use PSK: Devices too constrained for certificate parsing (8-bit MCUs with 2 KB RAM), or local networks where devices are pre-provisioned during manufacturing and never connect to the public internet. Thread and Matter use PSK-based commissioning for device onboarding. PSK is also useful during development and prototyping when certificate infrastructure is not yet set up.

RAM and Flash Cost on Cortex-M

TLS is the single largest consumer of RAM and flash on constrained IoT devices. Here is a realistic breakdown for a Cortex-M4 running mbedTLS with ECDHE-ECDSA-AES128-GCM-SHA256:

RAM breakdown (per TLS session):

Flash breakdown:

Strategies to reduce TLS footprint:

• Use ECC instead of RSA -- ECDSA P-256 keys are 32 bytes vs RSA-2048's 256 bytes; ECC math uses less code and RAM
• Strip unused cipher suites -- mbedTLS's mbedtls_config.h lets you disable everything except the one suite you need
• Reduce record buffer sizes -- Default is 16 KB per direction; 2-4 KB is enough for MQTT and CoAP payloads
• Use hardware crypto -- Offloads AES and SHA to hardware, freeing CPU and sometimes reducing code size
• Use PSK instead of certificates -- Eliminates the X.509 parser (saves 8-15 KB flash, 6-10 KB RAM)
• Enable session resumption -- Avoids full handshake on reconnection, reducing peak RAM and CPU time

Hardware Crypto Acceleration

Many modern MCUs include dedicated hardware peripherals for cryptographic operations. Using them is not just an optimization -- it can be the difference between TLS being feasible or infeasible on a given device.

TRNG is non-negotiable. TLS security depends on unpredictable random numbers for nonces, key generation, and ECDHE parameters. Software PRNGs (like rand()) are predictable and must never be used. If your MCU lacks a TRNG, you must use an external entropy source (noise from an ADC channel, timing jitter) and feed it into a CSPRNG (cryptographically secure PRNG). mbedTLS provides mbedtls_entropy and mbedtls_ctr_drbg for this purpose.

Integration with TLS libraries: mbedTLS, wolfSSL, and BearSSL all support hardware crypto via platform abstraction layers. For mbedTLS, you implement mbedtls_aes_alt.c and mbedtls_sha256_alt.c that call your MCU's hardware accelerator instead of the software implementation. STM32CubeMX generates these alternative implementations automatically for STM32 MCUs.

Real impact: On an STM32F4 at 168 MHz, a full TLS 1.2 handshake with ECDHE-ECDSA-AES128-GCM takes approximately 1.5 seconds in software. With hardware AES and SHA-256 acceleration, it drops to approximately 0.6 seconds. With full hardware PKA (ECC acceleration), it drops to approximately 0.3 seconds. For a battery-powered device that reconnects periodically, this 5x reduction in handshake time translates directly to lower power consumption.

DTLS: TLS for UDP-Based Protocols

DTLS (Datagram TLS) adapts TLS to work over UDP, which is inherently unreliable and unordered. It is required for securing CoAP, some IoT device management protocols, and any UDP-based application that needs encryption.

Why not just use TLS? TLS assumes a reliable, ordered transport (TCP). Its record layer depends on sequence numbers being contiguous and records arriving in order. UDP provides neither guarantee -- packets can arrive out of order, be duplicated, or be lost entirely. DTLS adds mechanisms to handle this.

DTLS handshake additions over TLS:

• Cookie exchange: Prevents DoS amplification attacks. The server sends a stateless cookie (HelloVerifyRequest) that the client must echo back before the server allocates any state. This is analogous to TCP's SYN cookie mechanism.
• Message fragmentation: X.509 certificate chains (1-5 KB) may exceed the UDP MTU. DTLS fragments handshake messages across multiple datagrams and reassembles them.
• Retransmission timers: Since UDP does not retransmit, DTLS uses its own exponential backoff timers for handshake messages.

DTLS and CoAP: CoAP over DTLS is the standard security model for constrained IoT devices on 6LoWPAN/Thread networks. The combination is designed to work within the tight constraints of IEEE 802.15.4 (127-byte frames after 6LoWPAN compression). DTLS PSK mode is commonly used here because the certificate-based handshake is too large for these constrained links.

Certificate Management Challenges in the Field

Deploying TLS with X.509 certificates on embedded devices creates operational challenges that do not exist in web server environments where certificates are managed by DevOps teams with automated tooling.

Storage: Each device needs its own private key (32 bytes for ECC P-256), its own certificate (500-1500 bytes), and one or more CA root certificates for server verification (500-2000 bytes). On devices with no filesystem, these must be stored in flash or a secure element. Updating the CA root certificate requires a firmware update or a dedicated certificate update mechanism.

Expiration: Certificates have expiration dates. A certificate issued with a 1-year validity will expire, and the device must obtain a new one. For devices deployed for 10+ years (smart meters, industrial sensors), this requires a certificate renewal protocol -- either EST (Enrollment over Secure Transport), SCEP, or a proprietary mechanism over MQTT or HTTP. If renewal fails (device offline during renewal window, server unreachable), the device cannot establish TLS connections and becomes a brick until manually re-provisioned.

Revocation: If a device is compromised, its certificate must be revoked. Traditional revocation (CRL, OCSP) requires the verifying device to fetch revocation lists from the internet -- impractical for constrained devices behind NATs. Alternatives include short-lived certificates (force frequent renewal so compromised certs expire quickly) and server-side revocation lists (the cloud server maintains a blocklist and rejects connections from revoked devices).

Clock dependency: Certificate validation requires an accurate real-time clock to check the validity period (not-before, not-after). Many MCUs lack a battery-backed RTC, and after power loss, the clock resets to epoch (January 1, 1970). If the device tries to establish TLS before obtaining the current time via NTP, certificate validation fails because the system clock says the certificate is "not yet valid." The solution is to either trust the first NTP response without TLS (chicken-and-egg problem) or use a TOFU (Trust On First Use) approach for the initial time sync.

Embedded TLS Libraries Comparison

mbedTLS (now maintained by the TrustedFirmware project, originally by ARM) is the de facto standard for Cortex-M. It integrates directly with FreeRTOS and is used by AWS IoT Device SDK, Azure IoT SDK, and ESP-IDF. Configuration via mbedtls_config.h gives fine-grained control over which features are compiled in. The main downside is that it does not have FIPS 140-2 certification (wolfSSL does).

wolfSSL is the main alternative for commercial products, especially those requiring FIPS 140-2 validation (government, defense, healthcare). It supports more hardware crypto platforms than mbedTLS and includes wolfCrypt as its crypto engine. The dual license (GPLv2 or commercial) means you need a paid license for proprietary firmware.

BearSSL is the smallest option -- designed from scratch for minimal footprint. It uses no dynamic memory allocation (all state is in caller-provided buffers) and has a particularly small code size. The trade-off is limited cipher suite support and slower development cadence than mbedTLS or wolfSSL.

Debugging Story: The 4 AM Certificate Expiry

A fleet of 10,000 smart water meters connected to a cloud broker via MQTT over TLS with mutual authentication. Each meter had a unique X.509 certificate provisioned during manufacturing. At 4 AM on a Sunday, 2,000 meters simultaneously lost connectivity. The monitoring dashboard showed a wave of TLS handshake failures starting at exactly midnight UTC.

The root cause: the certificates for the first production batch had been issued with a 2-year validity period, all on the same day. At midnight UTC, 2,000 certificates expired simultaneously. The meters attempted to reconnect, but every TLS handshake failed with a "certificate expired" error on the server side. The meters entered their reconnection loop with exponential backoff, and the fleet management team was not alerted until 4 AM when the monitoring system's threshold for offline devices was finally breached.

The fix had three parts: (1) stagger certificate expiration dates across the fleet so mass expiry cannot happen; (2) implement certificate renewal via EST (Enrollment over Secure Transport) so meters obtain new certificates automatically 30 days before expiry; (3) add a pre-expiry alert in the fleet management system that warns 60 days before any batch of certificates expires.

Lesson: Certificate lifecycle management is as important as the TLS implementation itself. Certificates expire, CAs rotate, and devices that cannot renew their credentials become permanently offline. Always design for certificate renewal from day one -- retrofitting it into a deployed fleet is vastly harder than building it in from the start.

What interviewers want to hear: You understand TLS at the protocol level (handshake steps, key exchange, certificate verification), not just "it encrypts data." You can compare TLS 1.2 and 1.3 with specific improvements (1-RTT, mandatory forward secrecy, removed insecure ciphers). You know the real RAM and flash costs on Cortex-M and can describe strategies to reduce them (ECC, strip ciphers, reduce buffers, hardware crypto). You understand the difference between certificate and PSK authentication and know when each is appropriate. You are aware of DTLS for UDP protocols and can explain why it exists. You have thought about certificate lifecycle (expiration, renewal, revocation) in the context of long-lived field devices.

Interview Focus

Classic TLS Interview Questions

Q1: "Walk me through a TLS handshake. What happens at each step?"

Model Answer Starter: "In TLS 1.3, the client sends a ClientHello with supported cipher suites, a random nonce, and an ECDHE key share -- the client's ephemeral public key. The server responds with ServerHello containing its ECDHE key share, then sends its certificate, a CertificateVerify signature proving it owns the private key, and a Finished MAC -- all encrypted because both sides can now derive the shared secret from the ECDHE exchange. The client verifies the certificate against a trusted CA root, checks the CertificateVerify signature, sends its own Finished MAC, and encrypted application data can begin. The entire handshake is 1 round trip, compared to 2 in TLS 1.2, because the client sends its key share proactively in the ClientHello."

Q2: "What is the difference between TLS 1.2 and TLS 1.3, and why does it matter for embedded systems?"

Model Answer Starter: "TLS 1.3 reduces the handshake from 2 round trips to 1 by having the client send its ECDHE key share in the ClientHello. On a cellular link with 200 ms RTT, this saves 400 ms of handshake time and radio-on duration. TLS 1.3 also mandates forward secrecy by removing RSA key exchange, eliminates insecure cipher suites like CBC-mode and RC4, and encrypts certificates for privacy. For embedded systems, the reduced handshake latency directly translates to lower power consumption on battery-powered devices. The simplified cipher suite list also means less code -- fewer code paths for the state machine and fewer crypto implementations to include in flash."

Q3: "When would you use PSK instead of certificates for TLS authentication?"

Model Answer Starter: "I use PSK on devices too constrained for X.509 certificate parsing -- the certificate parser alone is 8-15 KB of flash and needs 6-10 KB of RAM during the handshake. PSK eliminates both. I also use PSK during prototyping before certificate infrastructure is set up, and in local-only deployments where devices never connect to the public internet. Thread and Matter use PSK-based commissioning for device onboarding. For production devices connecting to cloud platforms like AWS IoT Core, I use certificates because they provide per-device identity, support revocation of compromised devices, and are required by these platforms."

Q4: "How much RAM does TLS require on a Cortex-M, and how would you reduce it?"

Model Answer Starter: "A typical TLS session with mbedTLS on Cortex-M consumes 20-40 KB of RAM. The biggest consumers are certificate parsing buffers (6-10 KB), TLS record buffers (4-8 KB per direction), and ECDHE computation (2-4 KB). To reduce this, I use ECC instead of RSA to shrink key and certificate sizes, reduce TLS record buffers from the 16 KB default to 2-4 KB to match my actual payload size, strip unused cipher suites in mbedtls_config.h, and use hardware crypto accelerators to reduce temporary buffer needs. If the device is extremely constrained, I switch from certificates to PSK to eliminate the X.509 parser entirely, saving 8-15 KB of flash and 6-10 KB of RAM."

Q5: "What is DTLS and why is it needed?"

Model Answer Starter: "DTLS is TLS adapted for UDP. TLS assumes a reliable, ordered transport -- it depends on TCP to deliver records in sequence. UDP provides neither reliability nor ordering, so DTLS adds explicit sequence numbers for replay protection, its own retransmission timers for handshake messages, a cookie exchange to prevent DoS amplification, and message fragmentation for large handshake messages like certificate chains. DTLS is required for securing CoAP, which runs over UDP and is the standard protocol for constrained IoT devices on 6LoWPAN and Thread networks. Without DTLS, CoAP traffic would be unencrypted and vulnerable to eavesdropping and tampering."

Trap Alerts

• Don't say: "TLS encrypts data" without being able to explain HOW -- the handshake, key exchange, and symmetric encryption steps. Surface-level answers signal a lack of real implementation experience.
• Don't forget: The RAM and flash cost of TLS on constrained devices. Saying "just add TLS" without acknowledging the 20-40 KB RAM overhead shows you have not worked on MCU-based IoT.
• Don't ignore: Certificate lifecycle management. In production, certificates expire, CAs rotate, and devices that cannot renew credentials become permanently offline. This operational concern is as important as the technical implementation.

Follow-up Questions

• "How does TLS session resumption work, and why is it important for IoT devices that reconnect frequently?"
• "What is mutual TLS (mTLS) and how is it used by AWS IoT Core?"
• "How would you secure an IoT device that has only 16 KB of RAM -- is TLS feasible?"
• "What is the relationship between TLS and MQTT security?"

Practice

Real-World Tie-In

Smart Meter Fleet with mTLS -- A utility deployed 50,000 smart meters connecting to AWS IoT Core via MQTT over TLS with mutual authentication. Each meter had an ECC P-256 certificate stored in an ATECC608 secure element. Using hardware crypto on the STM32L4 (AES, SHA, PKA), the TLS 1.2 handshake completed in 0.4 seconds over cellular -- fast enough that the radio-on time for reconnection was under 2 seconds total. Without hardware crypto, the handshake took 2.1 seconds, nearly tripling the power cost per reconnection cycle.

Industrial Gateway with Session Resumption -- A factory gateway reconnected to a cloud MQTT broker every time the cellular link dropped (approximately 3-4 times per day). Each full TLS handshake took 1.8 seconds and consumed a burst of 35 KB RAM. Enabling TLS session tickets reduced reconnection handshakes to 0.3 seconds and 18 KB RAM peak -- the gateway reused the session key from the previous connection, skipping certificate exchange and ECDHE entirely. Over a year, this saved an estimated 40% of the cellular modem's power budget.

Thread Sensor Network with DTLS-PSK -- A commercial building deployed 200 Thread-based temperature sensors communicating with a border router via CoAP over DTLS. Certificates were infeasible -- the sensors had only 32 KB RAM, and the 802.15.4 frame size (127 bytes) could not carry certificate chains. DTLS-PSK with AES-128-CCM provided encryption and authentication with under 3 KB of additional RAM per session. The PSK was provisioned during Thread commissioning and rotated quarterly via the Thread management protocol.