18 CoAP Security: Protection and Application Fit

18.1 Overview

This first route builds the CoAP security boundary and tests where constrained request-response communication fits real applications.

This is part 1 of 2. Continue with CoAP Security: Implementation and Operations for the second focused route.

18.2 Start With the Private Reading

Protect the Whole Exchange, Not Only the Number

Picture a ward sensor sending a medicine temperature to a nurse. The number is private, but the device name, request path, time, and pattern of use can also reveal patient care. The service owner must decide who may read or change the resource and what proof the small device can afford.

Draw one exchange from the sensor to the approved reader. Mark the device identity, the peer it trusts, the key or certificate in use, the protected fields, and the rule that grants access. Record when the proof starts, when it expires, and who can replace it after loss or repair.

Repeat the exchange with a false peer, an old key, a copied message, a delayed reply, a changed address, and a sleeping device. Check that private data stays hidden, changed data is rejected, and a failed check cannot turn into an unsafe command. Save enough detail to explain each refusal.

Keep any urgent safe response near the ward device or local care system. A distant security service can help issue and revoke trust, but loss of that link must not silently grant access or block a required local safeguard.

This opening does not size every packet or settle every legal duty. Practitioner builds the access and recovery test. Under the Hood follows message protection, key exchange, replay checks, constrained memory, and the limits of each security choice.

Use this private exchange check:

• Name the small device.
• Name the right peer.
• Name the allowed read.
• Name the allowed write.
• Mark each trust root.
• Mark the key owner.
• Mark the key age.
• Mark the key end.
• Keep the source name.
• Keep the event time.
• Try the wrong peer.
• Try the old key.
• Try the copied note.
• Try the late reply.
• Try the changed path.
• Try the lost link.
• Try a deep sleep.
• Check each clear refusal.
• Check the safe fallback.
• Save the failed trace.
• Save the passed trace.
• Reopen when trust changes.

Picture a wearable sensor sending a heart-rate value through a hospital gateway. The payload is sensitive, but so are the resource path, timing, identity, and repeated access pattern. CoAP security has to protect the exchange without spending so much energy that the device cannot do its job.

This page follows that practical tension: secure the datagrams, choose credentials, keep sessions alive when possible, and decide where application policy belongs in real deployments.

18.3 Learning Objectives

• Explain how DTLS (Datagram TLS) provides encryption, authentication (PSK or certificates), and integrity protection for CoAP on port 5684
• Distinguish between application-layer payload encryption and DTLS transport encryption, and justify why only DTLS satisfies HIPAA compliance for full metadata protection
• Apply CoAP in real-world deployments including smart energy metering, building automation (HVAC/lighting), and industrial sensor networks
• Select appropriate CoAP message types (CON vs NON) based on message criticality, battery constraints, and reliability requirements, and justify your choice
• Diagnose common CoAP implementation issues including token matching failures, retransmission backoff misconfiguration, MTU size violations, and response code misinterpretation

Phoebe’s Field Notes: What The DTLS Security Tax Really Costs

Phoebe’s Field Notes: From DTLS Bytes to Cell Charge

The mathematical gist. At a fixed 250 kbps and 20 mA transmit current, time is bits divided by bit rate and charge is current multiplied by time. The chapter’s 53-byte secured record therefore takes 1.696 ms and 0.00000942 mAh, while its 20-byte plain message takes 0.640 ms and 0.00000356 mAh: almost exactly the same 2.65x ratio as their byte counts. At 1,440 readings per day, add the 0.064 µAh handshake once, then keep self-discharge and derating separate from the radio ledger.

Math Bridge · guided foundationsHow do 53 secured bytes become a daily battery cost?Let Eddie connect bits, airtime, charge, session reuse, and cell limits. Learn the maths

18.5 Continue: CoAP DTLS and OSCORE Security Contracts

The main chapter below stays focused on CoAP security and application practice. For the deeper contract behind DTLS security modes, proxy termination, OSCORE inner and outer options, and replay protection, continue to CoAP DTLS and OSCORE Security Contracts.

18.6 Security with DTLS

Start with the security boundary. If the deployment needs privacy, the first question is not which CoAP method to call, but which fields must be hidden from the network.

CoAP uses DTLS (Datagram TLS) for security:

Features:

• Encryption of messages
• Authentication (Pre-Shared Keys or Certificates)
• Integrity protection

DTLS vs TLS:

• TLS = for TCP (HTTP)
• DTLS = for UDP (CoAP)

Port:

• CoAP: 5683
• CoAPs (secure): 5684

Choosing DTLS for CoAP is about adapting security to datagrams, not borrowing TLS unchanged. Inspect Figure 18.1 to compare the transport assumptions first and the shared security outcomes second.

In Figure 18.1, read the DTLS side through UDP loss, reordering, and the cookie check, then contrast it with TLS running over TCP’s ordered byte stream. Both can provide confidentiality, integrity, and peer authentication, but DTLS must handle datagram behavior explicitly and does not make UDP reliable. That boundary matters when the knowledge check asks what payload-only encryption leaves exposed.

18.7 DTLS Setup: Pre-Shared Key Example

Setting up secure CoAP (CoAPs) with DTLS-PSK authentication using Python:

# pip install aiocoap[dtls]
# Requires: tinydtls library (pip install DTLSSocket)
import asyncio
import aiocoap
import aiocoap.credentials

# --- Server side: CoAPs on port 5684 ---
async def create_secure_server():
    """Start a CoAP server with DTLS-PSK on port 5684."""
    root = aiocoap.resource.Site()
    root.add_resource(['temperature'],
                      TemperatureResource())

    # Define server credentials: map client identities to PSKs
    server_credentials = aiocoap.credentials.CredentialsMap()
    server_credentials.load_from_dict({
        # Identity "sensor-042" uses this 16-byte pre-shared key
        ':dtls-psk': {
            'sensor-042': b'MySecret16ByteK!',
            'sensor-043': b'AnotherKey16Byt!',
        }
    })

    context = await aiocoap.Context.create_server_context(
        root,
        bind=('::', 5684),  # Secure CoAP port
    )
    context.client_credentials = server_credentials
    return context

# --- Client side: connect with PSK identity ---
async def secure_get_temperature():
    """GET coaps://server/temperature with DTLS-PSK."""
    context = await aiocoap.Context.create_client_context()

    # Set client identity and PSK
    context.client_credentials.load_from_dict({
        'coaps://server/*': {
            'dtls': {
                'psk': b'MySecret16ByteK!',
                'client-identity': b'sensor-042'
            }
        }
    })

    request = aiocoap.Message(
        code=aiocoap.GET,
        uri='coaps://server/temperature'  # Note: coaps:// not coap://
    )
    response = await context.request(request).response
    print(f"Secure response: {response.payload.decode()}")

# What to observe:
# - URI scheme is coaps:// (port 5684) vs coap:// (port 5683)
# - DTLS handshake adds ~200ms on first request (key exchange)
# - Subsequent requests reuse session (~5ms overhead)
# - If PSK doesn't match: handshake fails, no data exchanged

Testing DTLS with CLI tools:

# Generate a PSK identity file for coap-client
# coap-client supports DTLS-PSK natively

# Secure GET request
coap-client -m get coaps://localhost/temperature \
  -k "MySecret16ByteK!" \
  -u "sensor-042"

# Verify encryption with Wireshark:
# Filter: dtls && udp.port == 5684
# You should see:
#   ClientHello -> ServerHello -> ChangeCipherSpec
#   Then encrypted ApplicationData (CoAP payload not readable)

DTLS overhead comparison:

Plain CoAP (UDP port 5683):
  Request:  4-byte header + payload
  Response: 4-byte header + payload
  Latency:  1 RTT (~20ms LAN)

Secure CoAP (DTLS port 5684):
  First request:  DTLS handshake (4-6 messages) + encrypted payload
  Latency:  3 RTTs for handshake + 1 RTT for data = ~80ms first request
  Overhead: 13 bytes DTLS record header per message

  Subsequent requests (session reuse):
  Latency:  1 RTT + ~5ms DTLS overhead = ~25ms
  Overhead: 13 bytes header + 8-16 bytes MAC (integrity)

Energy cost of DTLS handshake (one-time per session):
  6 messages x 100 bytes avg x 10 mA TX = 0.6 mAs
  Amortized over 1000 messages: 0.0006 mAs each (negligible)
  Keep DTLS sessions alive to avoid repeated handshakes.

Checkpoint: Secure Transport

You now know:

• Plain CoAP uses port 5683, while CoAPs uses DTLS on port 5684.
• DTLS protects headers, URIs, options, payload, integrity, and authentication; application-layer encryption protects only the payload.
• Session reuse matters: the chapter’s DTLS example amortizes a 0.064 µAh handshake over 1,440 messages/day, while each protected 20-byte reading grows to 53 bytes.

18.8 Interactive Security Calculators

Explore the energy costs and trade-offs of CoAP security options with these interactive calculators:

18.9 Real-World Applications

With the transport and battery costs in mind, the next step is matching message type and security mode to the application domain.

coap://meter.home/consumption
coap://meter.home/tariff
coap://meter.home/switch

18.9.3 Industrial IoT

Industrial CoAP designs should separate observation from control. A sensor network may poll values frequently with replaceable NON traffic, but a sampling-rate change needs an authenticated, authorized, confirmable write and a traceable 2.04 Changed outcome. Firmware update metadata and blocks add integrity, rollback, and power requirements beyond delivery alone. Asset tracking follows the same consequence test: a periodic location or status update may tolerate loss, whereas an alert notification can require confirmable delivery, deduplication, and escalation evidence. The protocol choice stays connected to the operational risk of each resource.

Try It: CoAP Application Scenario Builder

Select a real-world IoT application domain and configure CoAP parameters. The tool recommends optimal message types, security modes, and observe patterns based on your deployment requirements.

Checkpoint: Application Fit

You now know:

• Smart energy readings need CON when missed billing data would cause financial errors.
• Building automation can mix NON readings with CON setpoint changes, while industrial firmware blocks need CON with Block2.
• The scenario builder keeps the same deployment questions visible: device count, messages per day, security mode, observe pattern, and battery estimate.

18.10 Lab Exercise

Goal: Build CoAP temperature monitoring system

Hardware (or simulate):

Read these points as one connected sequence: start with ESP32 board; and finish with DHT22 sensor.

• ESP32 board
• DHT22 sensor

Tasks:

Read these points as one connected sequence: start with Setup CoAP Server (on Raspberry Pi or PC):; then Install aiocoap; then Create temperature resource; then Add humidity resource; and finish with Implement GET and PUT methods.

1. Setup CoAP Server (on Raspberry Pi or PC):
   • Install aiocoap
   • Create temperature resource
   • Add humidity resource
   • Implement GET and PUT methods

Read these points as one connected sequence: start with Create ESP32 CoAP Client:; then Connect to Wi-Fi; then Send GET requests every 30s; and finish with Display responses on Serial Monitor.

2. Create ESP32 CoAP Client:
   • Connect to Wi-Fi
   • Send GET requests every 30s
   • Display responses on Serial Monitor

Read these points as one connected sequence: start with Add Observe Pattern:; then Server notifies on temperature change; then Client receives push updates; and finish with No polling needed.

3. Add Observe Pattern:
   • Server notifies on temperature change
   • Client receives push updates
   • No polling needed

Read these points as one connected sequence: start with Implement Multicast Discovery:; then Client broadcasts to find servers; and finish with Servers respond with capabilities.

4. Implement Multicast Discovery:
   • Client broadcasts to find servers
   • Servers respond with capabilities

Challenge: Add CoAP-to-MQTT bridge for cloud integration

18.11 When to Use CoAP

18.12 Common Implementation Pitfalls

Once the protocol choice is made, reliability depends on small implementation details that UDP will not fix for you.

# BAD: Ignoring tokens
def on_notification(response):
    print(f"Got value: {response.payload}")  # Which resource?

# GOOD: Token-based dispatch
observations = {}  # token -> resource_uri mapping

def observe_resource(uri):
    token = generate_unique_token()
    observations[token] = uri
    send_observe_request(uri, token)

def on_notification(response):
    uri = observations.get(response.token)
    if uri:
        print(f"Resource {uri} = {response.payload}")
    else:
        print(f"Unknown token, sending RST")
        send_reset(response.mid)

# BAD: Fixed interval retry (network flooding)
RETRY_INTERVAL = 2.0  # seconds
for attempt in range(MAX_RETRIES):
    send_message(msg)
    if wait_for_ack(RETRY_INTERVAL):
        break

# GOOD: Exponential backoff per RFC 7252
ACK_TIMEOUT = 2.0      # Initial timeout (2 seconds)
ACK_RANDOM_FACTOR = 1.5  # Randomization factor
MAX_RETRANSMIT = 4      # Maximum retries

def coap_transmit(msg):
    timeout = ACK_TIMEOUT * (1 + random.random() * (ACK_RANDOM_FACTOR - 1))
    for attempt in range(MAX_RETRANSMIT + 1):
        send_message(msg)
        if wait_for_ack(timeout):
            return True
        timeout *= 2  # Double timeout each retry: 2s, 4s, 8s, 16s
    return False  # Give up after ~45 seconds total

18.13 Continue to Part 2

Continue with CoAP Security: Implementation and Operations.