CoAP Security for Constrained IoT Devices

Assessing CoAP security on a constrained IoT device, from discovery to judging exposure

CoAP is the constrained-device answer to HTTP: a compact request/response protocol over UDP for sensors and actuators too small for a full web stack. It supports security through DTLS, and a striking number of deployments turn it off. Here is how I assess a CoAP device and what tends to be exposed.

Why CoAP Needs a Hard Look

CoAP resources map directly to device functions: a temperature reading, a relay, a lock state. When the protocol runs without DTLS, those resources are reachable by any host that can send a UDP packet, with no encryption and no authentication. Reading is bad; writable resources are worse.

Step 1: Discover the Interface

CoAP devices advertise their resources at a standard path. One request enumerates the whole interface:

Anatomy of a CoAP discovery request using coap-client against the .well-known/core resource

coap-client -m get coap://192.168.1.50/.well-known/core

Example output

</sensors/temp>;rt='temperature';if='sensor',
</actuators/lock>;rt='lock';if='actuator',
</config/wifi>;rt='config'

Step 2: Probe the Resources

The discovery output is a map. A writable actuator resource that takes a PUT with no authentication is a direct control channel:

coap-client -m put -e 'open' coap://192.168.1.50/actuators/lock

Example output

2.04 Changed

A 2.04 Changed response to an unauthenticated PUT means the lock actuated on command. That is a critical finding, and it required nothing but a UDP packet.

Three CoAP Pitfalls

The issues that recur on CoAP deployments:

Three CoAP security pitfalls: no DTLS, traffic amplification, and open writable resources

Securing CoAP

Require DTLS with mutual authentication so only enrolled clients can talk to the device, authorize writable resources at the application layer, and rate-limit responses to blunt amplification. As with every IoT protocol, the network link is not access control on its own.

Where This Fits

Enumerating CoAP resources and proving what an unauthenticated client can read and change is part of an IoT penetration test. That testing is the kind of work we do at Berkner Tech.