By the end of this chapter, you will be able to:
DTLS provides TLS-equivalent encryption, authentication, and integrity for UDP-based IoT protocols such as CoAP. Use DTLS on port 5684 for real-time sensor communication, VoIP, and video streaming where low latency matters. Use TLS over TCP for firmware updates, REST APIs, and MQTT connections where reliability matters more than speed. For deployments under 100 devices use pre-shared keys (PSK, ~1.5 KB RAM); for 100+ devices use certificate-based authentication (~5 KB RAM) with per-device revocation. Always enable session resumption to cut reconnection overhead by ~60%.
This section covers Datagram Transport Layer Security (DTLS), the protocol that brings TLS-equivalent encryption to UDP-based IoT applications like CoAP, video streaming, and real-time telemetry.
Characters: Sammy the Sensor, Lila the LED, Max the Microcontroller, Bella the Battery
Sammy wants to send a secret temperature reading to the cloud, but there are sneaky eavesdroppers on the network!
Max says: “Don’t worry, Sammy! I’ll put your message in a secret lockbox using DTLS. It’s like writing your message in invisible ink that only the cloud can read.”
Sammy: “But what about TLS? My friend uses that!”
Max: “TLS is great, but it needs TCP – that’s like sending a registered letter where you wait for a delivery confirmation every time. DTLS works with UDP – it’s like sending a sealed postcard. Super fast, still secret, and perfect for when you need to send lots of readings quickly!”
Bella adds: “And the best part? With session resumption, I only need to power the lockbox mechanism once. After that, re-locking is quick and saves me 60% of my energy!”
Lila blinks green: “I light up when the handshake is done – that means the secret channel is ready!”
Key idea: DTLS is like a secret code that protects fast messages (UDP) the same way TLS protects slower, reliable messages (TCP). It keeps IoT sensor data safe from spies!
If you’re new to IoT security, here’s what you need to know:
The problem: Many IoT devices use UDP (User Datagram Protocol) to send data quickly – for example, a temperature sensor reporting every 10 seconds. But UDP has no built-in security. Anyone listening on the network can read the data.
The solution: DTLS (Datagram Transport Layer Security) adds encryption and authentication to UDP, just like TLS does for TCP (which is what makes HTTPS secure for websites).
Think of it this way:
Why not just use TLS? TLS requires TCP, which has a three-way handshake and guarantees packet delivery. This adds latency (100-300ms) that real-time IoT applications can’t afford. DTLS gives you security without that overhead.
When to use DTLS:
When to use TLS instead:
This topic is covered in four focused sub-chapters. Read them in the order shown in the Learning Path below, or jump to any sub-chapter that addresses your immediate need:
Learn the basics of DTLS, including:
Understand the handshake process in detail:
Learn about security threats and defenses:
Master practical implementation:
Recommended order:
Prerequisites: Before starting, review:
Next steps: After completing this section, continue to:
The following diagram shows how DTLS fits into the IoT protocol stack alongside TLS, and illustrates the key security services it provides over UDP transport.
When establishing a secure connection, DTLS follows a specific handshake process that adds a cookie exchange step compared to TLS, protecting against UDP-based amplification attacks. The choice between DTLS versions and authentication modes significantly impacts performance on constrained devices.
| Feature | TLS (TCP) | DTLS (UDP) |
|---|---|---|
| Use Case | Web, downloads | CoAP, VoIP, video |
| Latency | 100-300ms | 10-50ms |
| Packet Loss | Retransmits | Tolerates |
| IoT Fit | APIs, firmware | Real-time sensors |
| Mode | Memory | Scalability | Best For |
|---|---|---|---|
| PSK | ~1.5 KB | Poor | < 100 devices |
| Certificates | ~5 KB | Excellent | Enterprise |
Using TLS instead of DTLS for CoAP: CoAP runs over UDP, so standard TLS (which requires TCP) simply will not work. You must use DTLS (port 5684) for securing CoAP traffic. Attempting to tunnel CoAP over TCP+TLS negates CoAP’s low-latency advantages.
Neglecting session resumption: Every full DTLS handshake costs significant energy on battery-powered devices (e.g., ~270ms measured end-to-end on an ESP32 including crypto processing, plus substantial radio-on time). Without session resumption, a device reconnecting every 10 minutes will devote over 23% of its radio energy budget to handshakes alone. Always implement session tickets or cached sessions.
Choosing PSK for large-scale deployments: Pre-shared keys are simple to set up for a handful of devices, but they become a security and management nightmare at scale. If one key is compromised in a shared-PSK setup, all devices using that key are vulnerable. Use certificate-based authentication (PKI) for deployments exceeding ~100 devices.
Ignoring DTLS record size vs. UDP MTU: DTLS adds overhead (13-byte record header + MAC + possible padding). If your application data plus DTLS overhead exceeds the UDP MTU (typically 1280 bytes for IPv6), fragmentation occurs at the IP layer, dramatically increasing packet loss probability in lossy IoT networks. Design your payloads to fit within a single DTLS record.
Test your understanding of DTLS and transport security concepts:
Scenario: A hospital deploys 800 wireless patient monitors (heart rate, SpO2, blood pressure) across 12 floors. Each monitor sends a 48-byte vital signs reading every 10 seconds to a floor gateway via CoAP/UDP. The security team must decide between DTLS with PSK and DTLS with certificates, and evaluate the impact of session resumption on battery life.
Step 1: Assess authentication mode based on scale
| Factor | PSK Mode | Certificate Mode |
|---|---|---|
| RAM per session | ~1.5 KB | ~5 KB |
| Device count | 800 | 800 |
| Total gateway RAM for sessions | 1.2 MB | 4.0 MB |
| Key compromise impact | All devices sharing that key exposed | Only compromised device affected |
| Provisioning | Manual key distribution | PKI infrastructure required |
Decision: With 800 devices, certificates are required. A single compromised PSK would expose patient data across an entire floor. HIPAA compliance also mandates per-device identity and revocation capability.
Step 2: Calculate handshake cost with and without session resumption
Full DTLS 1.2 handshake (3-RTT with cookie):
| Phase | Packets | Bytes TX | Bytes RX | Time |
|---|---|---|---|---|
| ClientHello | 1 | 95 | 0 | - |
| HelloVerifyRequest (cookie) | 1 | 0 | 60 | 50 ms RTT |
| ClientHello + cookie | 1 | 155 | 0 | - |
| ServerHello + Certificate + KeyExchange + Done | 1 | 0 | 1,200 | 50 ms RTT |
| ClientKeyExchange + ChangeCipherSpec + Finished | 1 | 350 | 0 | - |
| ChangeCipherSpec + Finished | 1 | 0 | 80 | 50 ms RTT |
| Total | 6 | 600 bytes | 1,340 bytes | ~150 ms |
Session resumption (abbreviated handshake):
| Phase | Packets | Bytes TX | Bytes RX | Time |
|---|---|---|---|---|
| ClientHello + session ticket | 1 | 130 | 0 | - |
| ServerHello + ChangeCipherSpec + Finished | 1 | 0 | 100 | 50 ms RTT |
| ChangeCipherSpec + Finished | 1 | 0 | 40 | - |
| Total | 3 | 130 bytes | 140 bytes | ~50 ms |
Battery Life Comparison: Full Handshake vs. Session Resumption
Let’s quantify the battery impact over 1 year for a hospital monitor reconnecting every 10 minutes:
\[ \text{Reconnections per year} = \frac{365 \times 24 \times 60}{10} = 52{,}560 \text{ sessions} \]
Energy per full DTLS 1.2 handshake (TX: 600 bytes at 80 mA, RX: 1,340 bytes at 40 mA, 50 kbps). The formula first computes time in seconds, then multiplies by current to get milliampere-seconds (mAs), then divides by 3,600 to convert to mAh:
\[ E_{\text{full}} = \frac{\frac{600 \times 8}{50{,}000} \times 80 + \frac{1{,}340 \times 8}{50{,}000} \times 40}{3{,}600} = \frac{7.68 + 8.58}{3{,}600} \approx 0.0045 \text{ mAh} \]
With session resumption (TX: 130 bytes, RX: 140 bytes):
\[ E_{\text{resume}} = \frac{\frac{130 \times 8}{50{,}000} \times 80 + \frac{140 \times 8}{50{,}000} \times 40}{3{,}600} = \frac{1.66 + 0.90}{3{,}600} \approx 0.00071 \text{ mAh} \]
Over 1 year, cumulative handshake energy savings:
\[ \Delta E = 52{,}560 \times (0.0045 - 0.00071) \approx 199 \text{ mAh} \approx 0.20 \text{ Ah per device per year} \]
With a 3,000 mAh battery recharged daily, session resumption reduces security overhead from 23.5% to 4.5% of total radio budget, delivering a 20% reduction in total radio energy consumption.
Step 3: Calculate battery impact over 24 hours
Assume each monitor uses a 3,000 mAh battery (recharged daily), radio TX at 80 mA, RX at 40 mA, NB-IoT at 50 kbps:
| Metric | Full Handshake Each Time | Session Resumption |
|---|---|---|
| Handshake TX bytes | 600 | 130 |
| Handshake RX bytes | 1,340 | 140 |
| Handshake TX time | 96 ms | 21 ms |
| Handshake RX time | 214 ms | 22 ms |
| Handshake energy | 0.0045 mAh | 0.0007 mAh |
| Data TX per reading (48 + 13 DTLS + 8 UDP) | 69 bytes | 69 bytes |
| Readings per day | 8,640 | 8,640 |
| Handshakes per day (reconnect every 10 min) | 144 | 144 |
| Daily handshake energy | 0.65 mAh | 0.10 mAh |
| Daily data energy | 2.12 mAh | 2.12 mAh |
| Total daily energy | 2.77 mAh | 2.22 mAh |
| Battery % used for security | 23.5% of radio budget | 4.5% of radio budget |
Savings from session resumption: 0.55 mAh/day = 20% reduction in total radio energy consumption.
Step 4: Evaluate DTLS record size vs UDP MTU
| Component | Size |
|---|---|
| Vital signs payload | 48 bytes |
| DTLS record header | 13 bytes |
| DTLS MAC (SHA-256) | 32 bytes |
| DTLS IV (AES-CCM) | 8 bytes |
| CoAP header | 4 bytes |
| UDP header | 8 bytes |
| IPv6 header | 40 bytes |
| Total on wire | 153 bytes |
| IPv6 minimum MTU | 1,280 bytes |
153 bytes is well within the MTU. No fragmentation risk.
Key insight: For this 800-device hospital deployment, the combination of certificate-based DTLS (per-device identity for HIPAA compliance) with session resumption (20% total radio energy savings) provides the right balance. The full handshake costs only 150 ms – acceptable for the initial connection – while resumed sessions at 50 ms keep ongoing overhead minimal. The critical lesson is that session resumption is not optional for devices reconnecting frequently: without it, security handshakes would consume over 23% of the radio energy budget.
DTLS enables secure real-time IoT communication by adapting TLS for UDP transport. Key points:
Choose DTLS for latency-sensitive applications; choose TLS/TCP for reliability-critical data.
| Concept | What to Remember |
|---|---|
| DTLS purpose | TLS-equivalent security for UDP-based protocols (CoAP, VoIP, WebRTC) |
| Port number | CoAP over DTLS uses port 5684 (vs. 5683 for plain CoAP) |
| Cookie exchange | Prevents amplification DoS – server sends stateless cookie before committing resources |
| PSK vs. Certificates | PSK for < 100 devices (1.5 KB RAM); Certificates for enterprise scale (5 KB RAM) |
| DTLS 1.2 vs. 1.3 | 1.2 = 3-RTT handshake (~270ms); 1.3 = 1-RTT (~150ms), 44% faster |
| Session resumption | Reuses negotiated parameters, reduces handshake energy by ~84%; saves ~20% of total radio budget |
| Record size | Keep payload + DTLS overhead within UDP MTU to avoid IP fragmentation |
| Replay protection | Sequence numbers + sliding window prevent replayed packets |
| Topic | Chapter | Description |
|---|---|---|
| DTLS Fundamentals | DTLS Fundamentals and Architecture | Start here to understand why DTLS exists, its protocol stack, and its core security properties |
| DTLS Handshake | DTLS Handshake Protocols | Deep dive into the cookie exchange, 3-RTT vs 1-RTT flows, and 0-RTT session resumption |
| Attacks and Auth | DTLS Attack Scenarios and Authentication | Understand amplification DoS, session hijacking, downgrade attacks, and PSK vs certificate trade-offs |
| Performance | DTLS Performance and Implementation | Benchmarks, Connection ID for mobile devices, replay window tuning, and battery life analysis |
| Transport Layer | Transport Fundamentals | TCP, UDP, and QUIC transport-layer trade-offs and when to choose each |
| Cryptography | Encryption Architecture | AES-GCM, ECDHE, and the cryptographic primitives that DTLS relies on |