How does TLS work on a resource-constrained embedded device?

TLS (Transport Layer Security) encrypts and authenticates network connections. On a resource-constrained device, the same TLS handshake and record protocol run as on a desktop — the protocol itself does not change — but the implementation and configuration choices differ significantly to accommodate limited CPU, RAM, and flash.

Embedded devices use lightweight TLS libraries instead of OpenSSL (which requires 1-2 MB of flash and is complex to configure). The primary options are mbedTLS (ARM, widely used, ~100 KB flash), wolfSSL (~100 KB flash, FIPS 140-2 certified variant), and BearSSL (extremely small, ~25 KB flash, designed for minimal RAM). These libraries support the same cipher suites and protocol versions but are optimized for static memory allocation, small code size, and hardware crypto acceleration.

The TLS handshake is the most expensive operation — it involves asymmetric cryptography (RSA or ECDHE key exchange) that can take 1-5 seconds on a low-end Cortex-M4 without hardware acceleration. To mitigate this: use ECDHE with ECDSA certificates instead of RSA (256-bit ECC is equivalent to 3072-bit RSA but much faster on ARM), enable TLS session resumption (the client caches session parameters and resumes without a full handshake on reconnection — reducing the handshake to one round-trip with symmetric crypto only), and use hardware crypto accelerators if available (many SoCs include AES, SHA-256, and sometimes ECC engines). After the handshake, the record protocol uses symmetric encryption (AES-128-GCM is the standard choice) which is fast even on small MCUs, especially with hardware AES.