CoAP · Study deck
CoAP Security: CON and NON Trade-Offs
CoAP is a compact request and response protocol.
Broker Bex is your guide for this deck.
After studying this chapter
Learning objectives
Choose delivery and security from the route, endpoints, and device sleep cycle.
- Separate message delivery from confidentiality.
- Map exposure of payload, path, and timing.
- Place DTLS and OSCORE endpoints on the route.
- Include deep-sleep handshake or resumption cost in the energy test.
Major section
Start With the Decision
CoAP is a compact request and response protocol.
- A confirmable CoAP message asks for an acknowledgement and is retransmitted if none arrives before the timeout.
Major section
Worked Example: Hospital Wearable Device DTLS Configuration
Each device uses CoAP to report readings every 30 seconds to a centralized gateway.
- The hospital needs to protect patient data in transit.
- Illustrative message-energy comparison (CR2032 coin cell, 220 mAh, 3 V nominal):: The radio and cipher costs below are model inputs, not standard CoAP or DTLS values.
Major section
Decision Framework: CoAP Security Configuration Selection
Name both security endpoints and identify where the gateway can read content.
- DTLS between device and gateway protects that transport hop.
- The gateway can read the CoAP message on that hop.
- OSCORE protects selected content only between configured endpoints.
- Device-to-cloud OSCORE requires the device and cloud as endpoints.
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
Security protection ends at its configured endpoints.
- DTLS device-to-gateway ends at the gateway; the gateway can read device content.
- Gateway-to-cloud OSCORE protects selected content on that segment.
- Device-to-cloud OSCORE requires device and cloud endpoints.
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.
Q3What protects selected CoAP content end to end across intermediaries?
Show answer
Answer: D OSCORE protects selected CoAP message content end to end across intermediaries.
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.
- D · OSCORE protects selected CoAP message content end to end across intermediaries.