CoAP · Study deck

CoAP Security: Protection and Application Fit

This first route builds the CoAP security boundary and tests where constrained request-response communication fits real applications.

Broker Bex is your guide for this deck.

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

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 only DTLS satisfies HIPAA compliance for full metadata protection
  • 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
iotclass.org

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

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

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

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

Major section

Phoebe's Field Notes: 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.

Numbers to remember

20 mA20 mA transmit current, time is bits divided by bit rate
1.696 msThe chapter's 53-byte secured record therefore takes 1.696 ms
0.640 mswhile its 20-byte plain message takes 0.640 ms
iotclass.org

Major section

Security with DTLS

If the deployment needs privacy, the first question is not which CoAP method to call, but which fields must be hidden from the network.

  • Choosing DTLS for CoAP is about adapting security to datagrams, not borrowing TLS unchanged.
  • That boundary matters when the knowledge check asks what payload-only encryption leaves exposed.
DTLS and TLS can provide the same core security goals, but their transport and handshake mechanics differ.
DTLS and TLS can provide the same core security goals, but their transport and handshake mechanics differ.
iotclass.org

Major section

Interactive Security Calculators

DTLS Energy: Handshake is expensive (~0.064 mAh) but amortized over many messages becomes negligible.

  • CON vs NON: Confirmable messages use 2.5× more energy due to ACK requirement - use NON for telemetry.
  • Protocol Overhead: CoAP has 16.7% overhead vs HTTP's 90.9% for small payloads - massive difference for IoT.
  • Security Trade-off: DTLS adds 15-80% overhead depending on message frequency - but required for compliance.

Numbers to remember

15-80%Security Trade-off: DTLS adds 15-80% overhead depending on message frequency -

Try it: Interactive Security Calculators in the chapter

iotclass.org

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

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

Deck summary

Key takeaways

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.
  • DTLS Energy: Handshake is expensive (~0.064 mAh) but amortized over many messages becomes negligible.
iotclass.org

Retrieval practice

Recall check 1 of 3

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

Q1A healthcare company is deploying wearable patient monitors that use CoAP to send vital signs to hospital servers. The HIPAA compliance officer requires end-to-end encryption. The development team proposes using regular CoAP (port 5683) with application-layer encryption of the JSON payload. What security concern does this approach NOT address?

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 Correct!

iotclass.org

Retrieval practice

Recall check 2 of 3

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.

iotclass.org

Retrieval practice

Recall check 3 of 3

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 to guarantee delivery and prevent billing errors
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 Correct!

iotclass.org

Print reference

Answers

Answer key.

  1. B · Correct!
  2. A · CoAP security uses DTLS (Datagram TLS) over UDP.
  3. B · Correct!
iotclass.org