CoAP · Study deck

CoAP DTLS/OSCORE Security

Picture a clinic sensor sending a room reading through a small relay to a care service.

Broker Bex is your guide for this deck.

securitydtlsoscore

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

After studying this chapter

Learning objectives

You will be able to:

Compare NoSec, PreSharedKey, RawPublicKey, Certificate, and OSCORE security modes for constrained CoAP deployments.
Explain what DTLS protects on a CoAP hop and where that protection terminates.
Describe why OSCORE can preserve end-to-end object security across CoAP proxies.
Specify credential, handshake, session, replay, and proxy-trust evidence for a CoAP security review.

Major section

Start With the Proxy Boundary

The relay may need to route or cache the message, but it should not gain more access than its job needs.

A protocol is a shared set of rules for exchanging data.
The Constrained Application Protocol, or CoAP, gives small devices a web-style method.
Transport Layer Security means protection for a network connection.

Major section

Start With the Proxy Boundary (continued)

Object Security for Constrained RESTful Environments, or OSCORE, protects the message content so it can remain protected across a relay.

A successful secure session is not enough if an old command can be accepted again or no one can explain which relay saw plain text.
This opening does not select one security mode for every device.
Under the Hood examines handshakes, replay windows, proxy behavior, group cases, and proof records.

Major section

Overview: Four Security Modes, and What DTLS Actually Protects

RFC 7252 defines four security modes for CoAP.

For a closed hospital ward, a monitor might be provisioned with identity bed-042 and a 128-bit PSK, then send coaps://gateway/patient/12345/vitals over a long-lived DTLS session.
Security must come from the link or network layer.

Secure CoAP architecture: an IoT device stack running CoAP over DTLS on UDP port 5684 above 6LoWPAN and IEEE 802.15.4, a CoAP proxy bridging DTLS to TLS, and a cloud REST server over TLS, alongside the four RFC 7252 security modes NoSec, PreSharedKey, RawPublicKey, and Certificate.

Major section

Practitioner: DTLS Is Point-to-Point and Terminates at Proxies

Choosing a DTLS mode is a resource decision.

PreSharedKey has the lightest handshake and no certificate parsing, so it suits tightly managed fleets.
RawPublicKey gives asymmetric-key strength without the cost and operational burden of a certificate authority.
A sizing example makes the trade visible.
No (uses a shared master secret).

Major section

Practitioner: DTLS Is Point-to-Point and Terminates at Proxies (continued)

Certificate mode fits open ecosystems where devices from many vendors must be validated to a common trust anchor.

If a meter sends one reading every 30 seconds, it sends 2,880 CoAP reports per day.
A CoAP proxy that caches responses or translates CoAP to HTTP must terminate the DTLS session, decrypt, and re-encrypt on the far side — which means the proxy sees plaintext.
If you do not fully trust that middlebox, DTLS alone does not give you end-to-end confidentiality.

Major section

Under the Hood: OSCORE Protects the Message Object End-to-End

It uses COSE (CBOR Object Signing and Encryption) with an AEAD algorithm (default AES-CCM-16-64-128) and derives its keys with HKDF-SHA-256 from a shared Master Secret.

The clever part is which options stay visible.
So a forwarding or caching proxy can still route and cache the outer message, yet it cannot read the protected content.
OSCORE option (9) Marks a message as OSCORE-protected and carries the key ID and partial IV a recipient needs.
Sequence-number replay guard A per-sender counter forms the AEAD nonce and is checked against a replay window.

Deck summary

Key takeaways

The relay may need to route or cache the message, but it should not gain more access than its job needs.

Object Security for Constrained RESTful Environments, or OSCORE, protects the message content so it can remain protected across a relay.
RFC 7252 defines four security modes for CoAP.
Choosing a DTLS mode is a resource decision.
Certificate mode fits open ecosystems where devices from many vendors must be validated to a common trust anchor.

Retrieval practice

Recall check 1 of 3

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

Q1A hospital worries that a CoAP path like /patient/12345/vitals reveals sensitive information even when the reading is encrypted. Which protection actually hides that URI on the wire?

ADTLS on coaps://, because it encrypts path/options as well as payload.

BPayload-only JSON encryption while keeping plain coap:// metadata.

CPlain coap:// on port 5683 with a trusted local network.

DA POST method change while leaving Uri-Path visible.

Show answer

Answer: A DTLS protects the complete CoAP message between its endpoints, so Uri-Path, options, method, and payload are concealed on that hop.

Retrieval practice

Recall check 2 of 3

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

Q2A caching CoAP proxy sits between constrained sensors and a cloud service, and the operator does not fully trust the proxy host. Why is DTLS alone insufficient for confidentiality here?

ADTLS uses weak ciphers that the proxy can trivially break.

BDTLS protects one hop, so the proxy decrypts before caching or translating.

CDTLS cannot run over UDP, so the proxy must convert it to TCP and expose it.

DDTLS only encrypts the payload, leaving everything else visible to the proxy.

Show answer

Answer: B DTLS secures a single hop; a caching or cross-protocol proxy terminates that hop and handles plaintext, so end-to-end object security is needed.

Retrieval practice

Recall check 3 of 3

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

Q3How does OSCORE (RFC 8613) provide confidentiality that survives an untrusted caching proxy, which DTLS cannot?

AIt forces the proxy to run its own DTLS session with stronger ciphers.

BIt encrypts every option including Proxy-Uri, so the proxy cannot route at all.

CIt encrypts the CoAP object end-to-end while leaving routing options readable.

DIt disables proxies entirely and requires a direct connection.

Show answer

Answer: C Object security travels with the message rather than the hop, protecting method, payload, and inner options while leaving required outer routing options readable.

Print reference

Answers

Answer key.

A · DTLS protects the complete CoAP message between its endpoints, so Uri-Path, options, method, and payload are concealed on that hop.
B · DTLS secures a single hop; a caching or cross-protocol proxy terminates that hop and handles plaintext, so end-to-end object security is needed.
C · Object security travels with the message rather than the hop, protecting method, payload, and inner options while leaving required outer routing options readable.