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

Major section

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

Sensor ↔ proxy: DTLS hop; proxy sees plaintext; proxy ↔ service: new protected hop.

DTLS protects one hop between its two endpoints.A caching proxy ends that session and can read the CoAP contents.
A forwarding proxy must terminate the DTLS session.It can begin a separate protected session on the proxy-to-service hop.
A proxy boundary does not provide end-to-end confidentiality.Use OSCORE when inner CoAP content must remain protected across the proxy.

Major section

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

Protected inner content travels across proxy; required outer routing fields stay visible; sender sequence and replay window reject old copies.

OSCORE protects selected inner CoAP content.The protected object can cross a proxy without exposing those fields.
Required outer routing fields stay visible.A proxy needs them to forward the message toward the right endpoint.
The sender advances a sequence value for each message.A receiver checks its replay window and rejects old copies.
The OSCORE option carries key and message context.The recipient uses its key identifier and partial IV when present.

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 4

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 4

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 4

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.

Retrieval practice

Recall check 4 of 4

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

Q4A protected CoAP device reboots and begins sending messages again. What must a security review verify before trusting them?

ACheck restored credentials, sequence state, replay defence, and incident evidence.

BCheck reachability alone and assume credentials and replay state survived.

CCheck only URI length, ignoring rebooted security sequence state.

DCheck Wi-Fi rejoin alone as proof of message replay safety.

Show answer

Answer: A Reboot can affect replay state; the review must prove old protected messages cannot be accepted as fresh.

Print reference

Answers 1 of 2

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.

With the answer frame visible, join three boundaries. D-T-L-S hides the CoAP message within one protected hop. A proxy that ends that hop sees plain content. O-S-C-O-R-E can protect inner fields across the proxy while leaving routing fields visible. Name the endpoint that owns each key and sees each field.

Print reference

Answers 2 of 2

Answer key.

A · Reboot can affect replay state; the review must prove old protected messages cannot be accepted as fresh.

With the final answer frame visible, check reboot recovery. The sender must resume its protected-message sequence safely, and the receiver must reject old copies. Show one accepted fresh reading and one refused replay. Repeat the check after a key, relay, or sleep-state change.