1439  TLS/DTLS Transport Security for IoT

1439.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Understand TLS Handshake: Explain how TLS establishes secure connections using certificates and key exchange
  • Compare TLS and DTLS: Select the appropriate protocol based on transport layer (TCP vs UDP)
  • Configure IoT-Optimized TLS: Apply session resumption, pre-shared keys, and connection coalescing for constrained devices
  • Implement Certificate Validation: Verify server certificates and handle certificate pinning
TipIn Plain English

TLS (Transport Layer Security) is the “S” in HTTPS - it provides encrypted, authenticated connections. DTLS (Datagram TLS) does the same for UDP-based protocols like CoAP.

Why it matters for IoT: When your smart thermostat connects to the cloud, TLS ensures: (1) data is encrypted so eavesdroppers can’t read it, (2) the server is authenticated so you’re not talking to an imposter, and (3) messages can’t be modified in transit.

1439.2 TLS vs DTLS

Feature TLS 1.3 DTLS 1.3
Transport TCP (reliable, ordered) UDP (unreliable, unordered)
Use Case MQTT, HTTPS, HTTP/2 CoAP, LwM2M, real-time
Handshake Size ~2,500 bytes ~1,800 bytes
Record Overhead 29 bytes/record 21 bytes/record
Retransmission TCP handles it DTLS must handle it
Connection State Persistent Can be stateless after handshake

1439.2.1 When to Use Each

Choose TLS when:

  • Using HTTP/HTTPS, MQTT, or TCP-based protocols
  • Reliability is critical (firmware updates, commands)
  • Network supports persistent connections
  • Device has memory for TCP stack (~10-20 KB)

Choose DTLS when:

  • Using CoAP, LwM2M, or UDP-based protocols
  • Network is lossy or high latency (satellite, LoRaWAN backhaul)
  • Device memory is severely constrained (<32 KB RAM)
  • Real-time data where occasional loss is acceptable
  • Multicast communication needed

1439.3 TLS 1.3 Handshake

%% fig-alt: "TLS 1.3 handshake showing 1-RTT connection establishment"
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
sequenceDiagram
    participant Client as IoT Device
    participant Server as Cloud Server

    Note over Client,Server: TLS 1.3: 1-RTT Handshake

    Client->>Server: ClientHello<br/>+ Key Share (ECDHE)<br/>+ Cipher Suites

    Server->>Client: ServerHello<br/>+ Key Share<br/>+ Certificate<br/>+ CertificateVerify<br/>+ Finished

    Note over Client: Verify Certificate<br/>Compute Shared Secret

    Client->>Server: Finished<br/>+ [Application Data]

    Note over Client,Server: Encrypted Application Data
    Client->>Server: Sensor Data (encrypted)
    Server->>Client: Commands (encrypted)

Figure 1439.1: TLS 1.3 establishes secure connection in one round-trip

1439.3.1 Handshake Components

Step Purpose Size Impact
ClientHello Propose cipher suites, send ECDHE key share ~200 bytes
ServerHello Select cipher, send key share ~100 bytes
Certificate Server’s identity proof 500-2000 bytes
CertificateVerify Signature proving private key ownership 64-256 bytes
Finished MAC of handshake transcript 48 bytes

1439.4 IoT Optimizations

1439.4.1 1. Session Resumption (0-RTT)

After the first handshake, subsequent connections can skip key exchange:

%% fig-alt: "TLS session resumption showing 0-RTT reconnection"
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
sequenceDiagram
    participant Client as IoT Device
    participant Server as Cloud Server

    Note over Client,Server: 0-RTT Resumption

    Client->>Server: ClientHello<br/>+ Pre-Shared Key ID<br/>+ Early Data (encrypted)

    Server->>Client: ServerHello<br/>+ Finished

    Note over Client,Server: Full connection in 0 round-trips!

Figure 1439.2: Session resumption eliminates handshake latency for reconnections

Benefits:

  • Reduces connection time from ~200ms to ~0ms
  • Saves battery on frequent reconnections
  • Critical for sleepy IoT devices

Caution: 0-RTT data can be replayed - don’t use for non-idempotent operations.

1439.4.2 2. Pre-Shared Keys (PSK)

For devices that can’t handle certificates:

Mode Key Exchange Authentication Use Case
Certificate ECDHE X.509 Certificate Standard TLS
PSK PSK Pre-shared key Constrained devices
PSK + ECDHE ECDHE + PSK Both Maximum security 
PSK Benefits:
- No certificate parsing (saves ~5 KB code)
- Faster handshake (no signature verification)
- Works with symmetric-only hardware

PSK Drawbacks:
- Key management complexity
- No perfect forward secrecy (PSK-only mode)
- Must provision keys securely

1439.4.3 3. Certificate Compression

TLS 1.3 supports certificate compression (RFC 8879):

Format Typical Size Compressed
X.509 RSA-2048 1,500 bytes ~800 bytes
X.509 ECDSA-256 500 bytes ~300 bytes

1439.4.4 4. Connection Coalescing

Keep TLS connections alive instead of reconnecting:

Without coalescing:
  Connect -> Handshake (200ms) -> Send -> Disconnect
  Connect -> Handshake (200ms) -> Send -> Disconnect
  Total: 400ms + 2 handshakes

With coalescing:
  Connect -> Handshake (200ms) -> Send -> Keep-alive -> Send
  Total: 200ms + 1 handshake

1439.5 Certificate Validation

%% fig-alt: "Certificate chain validation from root CA to server certificate"
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
flowchart TB
    subgraph Trust["Trusted (Pre-installed)"]
        Root[Root CA Certificate<br/>Built into device]
    end

    subgraph Chain["Certificate Chain"]
        Intermediate[Intermediate CA<br/>Signed by Root]
        Server[Server Certificate<br/>Signed by Intermediate]
    end

    subgraph Verify["Validation Steps"]
        V1[1. Check expiration dates]
        V2[2. Verify signatures up chain]
        V3[3. Check hostname matches]
        V4[4. Check revocation status]
    end

    Root -->|Signs| Intermediate
    Intermediate -->|Signs| Server
    Server --> V1 --> V2 --> V3 --> V4

    V4 -->|All pass| Valid[Connection Secure]
    V4 -->|Any fail| Invalid[Reject Connection]

    style Root fill:#27AE60,stroke:#2C3E50,color:#fff
    style Valid fill:#27AE60,stroke:#2C3E50,color:#fff
    style Invalid fill:#E74C3C,stroke:#2C3E50,color:#fff

Figure 1439.3: Certificate chain validation ensures server authenticity

1439.5.1 Certificate Pinning

For high-security IoT, pin specific certificates or public keys:

Pinning Type What’s Pinned Flexibility Security
None Trust any valid certificate High Lower
CA Pin Specific root/intermediate CA Medium Medium
Leaf Pin Server’s exact certificate Low Higher
SPKI Pin Server’s public key Low Highest
WarningCertificate Pinning Risks

Bricking risk: If pinned certificate expires or is rotated, devices can’t connect. Always implement:

  1. Backup pins (next certificate)
  2. Pin update mechanism (OTA)
  3. Pinning bypass for emergencies (with strong authentication)

1439.6 Cipher Suite Selection

TLS 1.3 simplified cipher suites to only secure options:

Cipher Suite Key Exchange Encryption Hash IoT Suitability
TLS_AES_128_GCM_SHA256 ECDHE AES-128-GCM SHA-256 Recommended
TLS_AES_256_GCM_SHA384 ECDHE AES-256-GCM SHA-384 High security
TLS_CHACHA20_POLY1305_SHA256 ECDHE ChaCha20-Poly1305 SHA-256 No AES HW

IoT Recommendation: Use TLS_AES_128_GCM_SHA256 with ECDHE (Curve25519 or P-256) for best balance of security and performance.

1439.7 DTLS for Constrained Devices

DTLS adds reliability features on top of UDP:

1439.7.1 Handshake Retransmission

DTLS handles packet loss:
1. Send handshake message
2. Start retransmit timer (1 second)
3. If no response, retransmit with backoff
4. Max retries: typically 4-6

1439.7.2 Connection ID (RFC 9146)

Allows NAT rebinding without renegotiation:

Traditional: NAT timeout -> Full re-handshake
With CID: NAT timeout -> Continue with same CID

Critical for IoT devices behind NAT with sporadic connectivity.

1439.8 Knowledge Check

Your IoT device sends sensor data every 5 minutes using CoAP over UDP. Network latency is high (500ms) and packet loss is common (5%). Which transport security protocol is most appropriate?

Options:

    1. TLS 1.3 because it’s the latest standard
    1. DTLS 1.3 because it works with UDP and handles packet loss
    1. IPsec because it provides network-layer security
    1. No encryption needed for sensor data

Correct: B

DTLS (Datagram TLS) is designed specifically for UDP-based protocols like CoAP. It handles packet loss through retransmission and supports unreliable/unordered delivery. TLS requires TCP, which would add overhead and latency. IPsec is complex and typically used for VPNs, not application-layer IoT protocols.

A battery-powered sensor connects to the cloud every hour. The initial TLS handshake takes 300ms and drains significant battery. How can you optimize reconnections?

Options:

    1. Disable TLS to save battery
    1. Use TLS session resumption (PSK) to skip full handshake on reconnection
    1. Use a longer keepalive timeout to maintain the connection
    1. Switch to a larger battery

Correct: B

TLS session resumption using pre-shared keys (PSK) allows reconnection in 0-RTT, eliminating the 300ms handshake latency and associated power consumption. The device stores session state from the first connection and reuses it for subsequent connections. Option C (keepalive) wastes battery maintaining idle connections. Never disable security (Option A).

1439.9 Implementation Libraries

Library Platforms Size Features
mbedTLS Embedded, Linux 60-100 KB TLS 1.3, DTLS 1.2, PSK
wolfSSL Embedded, RTOS 20-100 KB TLS 1.3, DTLS 1.3, FIPS
BearSSL Embedded 25-75 KB TLS 1.2, minimal footprint
OpenSSL Linux, desktop 500+ KB Full-featured

IoT Recommendation: Use mbedTLS for most ESP32/STM32 projects. Consider wolfSSL for DTLS 1.3 or FIPS compliance.

1439.10 Summary

  • TLS 1.3 provides encrypted, authenticated connections over TCP (MQTT, HTTPS)
  • DTLS 1.3 provides the same security for UDP-based protocols (CoAP, LwM2M)
  • Session resumption eliminates handshake latency for reconnections (critical for battery life)
  • Certificate validation ensures you’re connecting to the real server, not an imposter
  • Certificate pinning provides additional security but requires careful key rotation planning
  • Cipher suite selection: Use AES-128-GCM with ECDHE for best IoT balance

1439.11 What’s Next

Continue to Key Management for IoT to learn how to securely generate, store, distribute, and rotate cryptographic keys throughout the device lifecycle.