CoAP · Study deck

CoAP Security: Protection and Application Fit

This first route tests where CoAP, a compact way to exchange requests and replies, fits real applications.

Broker Bex is your guide for this deck.

security

Broker Bex, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

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 DTLS protects CoAP headers and URI on the transport link while other metadata and compliance duties remain
Select appropriate CoAP message types (CON vs NON) based on message criticality, battery constraints, and reliability requirements, and justify your choice
explain CoAP DTLS security protections

Major section

Overview

This first route tests where CoAP, a compact way to exchange requests and replies, fits real applications.

A constrained device has limited power, memory, or link capacity.
Its security boundary states who may read or change each resource and which parts of the request-response exchange need protection.

Major section

Start With the Private Reading

This opening does not size every packet or settle every legal duty.

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.
Under the Hood follows message protection, key exchange, replay checks, constrained memory, and the limits of each security choice.

Major section

Start With the Private Reading (continued)

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.

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.

Major section

Locking the Door

"Wait -- if CoAP sends data over UDP, can't anyone listen in?" Temperature Terry asked nervously. "My medical sensor readings are private!".

the microcontroller nodded seriously. "That's why we have DTLS -- it's like TLS (the lock on websites) but designed for UDP.
It wraps your CoAP messages in encryption so nobody can read them in transit.
Without encryption, a hacker with a radio could intercept heart rate data.

Major section

Locking the Door (continued)

"But locking costs energy," the battery pointed out. "The DTLS handshake -- where devices exchange keys -- takes several extra messages.

That's why you keep the connection open after the handshake so you don't have to redo it every time.
the LED shared a real example: "In a smart hospital, CoAP with DTLS protects patient data from sensors to the nurse's station.
With DTLS, all they see is scrambled nonsense.

Major section

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.

At 1,440 readings per day, add the 0.064 µAh handshake once, then keep self-discharge and derating separate from the radio ledger.

Major section

Security with DTLS

Compare DTLS datagrams and the TLS stream without treating either handshake as application evidence.

DTLS protects application data over datagrams.Its handshake includes a cookie challenge and extra exchanges, which cost time.
TLS protects application data over an ordered TCP stream.The transport changes which loss and ordering behavior the handshake must accommodate.
A completed handshake is evidence for this channel only.The application still checks credentials, access, freshness, and the accepted result.

DTLS over UDP and TLS over TCP compared by transport behavior, cookie challenge, handshake records, session reuse, and shared confidentiality, integrity, and peer authentication goals. — DTLS and TLS can provide the same core security goals, but their transport and handshake mechanics differ.

Major section

Handshake cost in microamp-hours

Compare transmit airtime and charge with explicit units; the calculation omits receive energy and repeated handshakes.

The 53-byte secured transmission takes 1.696 milliseconds at 250 kilobits per second.This is transmit airtime computed from 424 bits divided by the stated data rate.
At 20 milliamps, transmit charge is about 0.00942 microamp-hours.This is the current multiplied by 1.696 milliseconds and converted to hours.
A 20-byte plain transmission takes 0.640 milliseconds.It carries 160 bits at the same stated 250-kilobit-per-second data rate.
Its transmit charge is about 0.00356 microamp-hours.Receive energy, retries, handshakes, and cell derating require separate accounting.

Try it: Interactive Security Calculators in the chapter

Major section

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.

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.
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.

Major section

Pitfall: An Open CoAP Server Becomes a DDoS Reflector

The Mistake: Leaving a NoSec coap:// endpoint reachable from the public internet, on the assumption that CoAP's security risk starts and ends with eavesdropping on the device's own traffic.

The device is not the target; it becomes an unwitting reflector in a DDoS attack against someone else.

Deck summary

Key takeaways

This first route tests where CoAP, a compact way to exchange requests and replies, fits real applications.

This opening does not size every packet or settle every legal duty.
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.
"Wait -- if CoAP sends data over UDP, can't anyone listen in?" Temperature Terry asked nervously. "My medical sensor readings are private!".
"But locking costs energy," the battery pointed out. "The DTLS handshake -- where devices exchange keys -- takes several extra messages.

Retrieval practice

Recall check 1 of 4

Broker Bex says: answer from memory, then check your reasoning.

Q1A payload is encrypted, but CoAP paths and options remain outside it. Which technical metadata gap should the team test?

AEncrypted payloads alone make the exchange compliant for all metadata

BCoAP metadata remains visible, including patient IDs in URI paths and options

CThe encryption adds too much overhead for constrained devices to handle

DPre-shared keys should be used instead of certificates for better security

Show answer

Answer: B Payload encryption leaves CoAP headers, URI paths (/patient/12345/vitals), options, and message types visible.

Retrieval practice

Recall check 2 of 4

Broker Bex says: answer from memory, then check your reasoning.

Q2Complete the DTLS-secured CoAP client setup:

Acredentials.load_from_dict({'coaps://sensor/*': {'dtls': {'psk': b'psk'}}})

Bcredentials.set_psk('secret_key')

Ccredentials.add_tls('sensor.local', 'secret_key')

Dcredentials = {'psk': 'secret_key'}

Show answer

Answer: A CoAP security uses DTLS (Datagram TLS) over UDP.

Retrieval practice

Recall check 3 of 4

Broker Bex says: answer from memory, then check your reasoning.

Q3A smart energy meter must reliably deliver billing consumption readings to the utility server. Occasional missed readings will result in billing errors. Which CoAP message type should the meter use for these readings, and why?

ANON (Non-confirmable), because meter readings are low-priority background data that can tolerate occasional loss

BCON (Confirmable), because the server must ACK each reading and the meter retransmits if no ACK arrives

CRST (Reset), because the server should reject readings it cannot process immediately

DACK (Acknowledgement), because the meter needs to confirm that each reading was recorded

Show answer

Answer: B CON requests an ACK and retransmits with a randomized initial timeout and binary exponential backoff, up to the configured retry limit.

Retrieval practice

Recall check 4 of 4

Broker Bex says: answer from memory, then check your reasoning.

Q4A lossy radio link has many clients retrying Confirmable messages at a fixed rapid interval. What is the likely fault and fix?

ARapid retries amplify traffic; use bounded exponential backoff.

BToo few retries cause the loss; remove all retry limits.

CToken collision causes the loss; make all messages CON.

DCache expiry causes the loss; increase every Max-Age.

Show answer

Answer: A Spaced retries reduce congestion and give the exchange a clear failure bound.

Print reference

Check protection, delivery, and application boundaries

Answer key.

B · Payload encryption leaves CoAP headers, URI paths (/patient/12345/vitals), options, and message types visible.
A · CoAP security uses DTLS (Datagram TLS) over UDP.
B · CON requests an ACK and retransmits with a randomized initial timeout and binary exponential backoff, up to the configured retry limit.
A · Spaced retries reduce congestion and give the exchange a clear failure bound.

1. B: payload-only encryption can leave CoAP metadata visible. 2. A: load the shown pre-shared key before establishing the protected exchange. 3. B: confirmable delivery can detect a missing protocol acknowledgement; application receipt still needs evidence. 4. A: bounded exponential backoff limits synchronized retry amplification.