CoAP · Study deck
CoAP Security: CON and NON Trade-Offs
A confirmable CoAP message retries after loss; a non-confirmable one does not.
Broker Bex is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: The Error:: Configuring battery-powered IoT devices to establish a DTLS session once, then sleep/wake multiple times expecting the session to remain valid.
- Explain: Hybrid approach:: Many deployments use DTLS from device to gateway (transport security), then OSCORE from gateway to cloud (end-to-end security).
- Explain: DTLS, OSCORE, credentials, gateways, and provisioning all need to be matched to battery budget, multicast needs, and operational update paths.
- Explain: However, DTLS sessions have state (sequence numbers, cipher state) that's lost when the device power-cycles RAM.
Major section
Worked Example: Hospital Wearable Device DTLS Configuration
Each device uses CoAP to report readings every 30 seconds to a centralized gateway.
- HIPAA compliance requires encryption of all patient data in transit.
- Industry standard:: DTLS is the recommended CoAP security mechanism (RFC 7252).
Major section
Decision Framework: CoAP Security Configuration Selection
Hybrid approach:: Many deployments use DTLS from device to gateway (transport security), then OSCORE from gateway to cloud (end-to-end security).
- This balances ease of debugging (DTLS is standard TLS) with proxy security (OSCORE protects against compromised gateways).
Major section
Common Mistake: Reusing DTLS Session Across Deep Sleep Cycles
The Error:: Configuring battery-powered IoT devices to establish a DTLS session once, then sleep/wake multiple times expecting the session to remain valid.
- However, DTLS sessions have state (sequence numbers, cipher state) that's lost when the device power-cycles RAM.
- When ESP32 deep sleeps, RAM is powered off.
Major section
Summary
CoAP security decisions depend on the device, transport, and deployment model.
- DTLS, OSCORE, credentials, gateways, and provisioning all need to be matched to battery budget, multicast needs, and operational update paths.
Deck summary
Key takeaways
Each device uses CoAP to report readings every 30 seconds to a centralized gateway.
- Hybrid approach:: Many deployments use DTLS from device to gateway (transport security), then OSCORE from gateway to cloud (end-to-end security).
- The Error:: Configuring battery-powered IoT devices to establish a DTLS session once, then sleep/wake multiple times expecting the session to remain valid.
- CoAP security decisions depend on the device, transport, and deployment model.
Retrieval practice
Recall check 1 of 2
Broker Bex says: answer from memory, then check your reasoning.
Q1The hospital wearable example compares payload encryption with DTLS. Which protection gap motivates its choice?
Show answer
Answer: C The example’s reasoning favors transport protection including the associated sensitive metadata.
Q2A CoAP design must preserve protected message content through proxies. Which listed mechanism addresses that boundary?
Show answer
Answer: B The comparison identifies object security as surviving proxies for end-to-end protection.
Retrieval practice
Recall check 2 of 2
Broker Bex says: answer from memory, then check your reasoning.
Q3Place each CoAP security mechanism where it lives so you can tell end-to-end protected content from hop protection and the untrusted transport beneath it.
Show answer
Answer: A Place each CoAP security mechanism where it lives so you can tell end-to-end protected content from hop protection and the untrusted transport beneath it.
Print reference
Answers
Answer key.
- C · The example’s reasoning favors transport protection including the associated sensitive metadata.
- B · The comparison identifies object security as surviving proxies for end-to-end protection.
- A · Place each CoAP security mechanism where it lives so you can tell end-to-end protected content from hop protection and the untrusted transport beneath it.