IoT Security

Security of CoAP
Mridul Sankar Barik

Jadavpur University

2024-25
Constrained Application Protocol (CoAP)

▶ A specialized web transfer protocol for use with constrained nodes and
constrained (e.g., low-power, lossy) networks [RFC 7252]
▶ Nodes often have 8-bit microcontrollers with small amounts of ROM and
RAM
▶ Constrained networks such as IPv6 over Low-Power Wireless Personal
Area Networks (6LoWPANs) often have high packet error rates and a
typical throughput of 10s of kbit/s
▶ Features
▶ Web protocol fulfilling M2M requirements in constrained environments
▶ UDP binding with optional reliability supporting unicast and multicast
requests
▶ Asynchronous message exchanges
▶ Low header overhead and parsing complexity
▶ URI and Content-type support
▶ Simple proxy and caching capabilities
▶ Security binding to Datagram Transport Layer Security (DTLS)
CoAP and HTTP

Web architecture with HTTP and CoAP

Figure Source: [Bormann et al., 2012]
CoAP vs. HTTP
Differences between CoAP and HTTP
▶ Transport Protocol:
Similarities between CoAP and HTTP ▶ CoAP uses UDP, HTTP uses TCP

▶ Request-Response Model ▶ Efficiency:

▶ Both CoAP and HTTP follow a ▶ Tokenization feature of CoAP allows lightweight
request-response communication model. state tracking
A client initiates a request, and the ▶ Observe feature reduces the need for frequent polling
server responds with the appropriate ▶ The overhead and connection-oriented nature of
data or action. HTTP can be less efficient for IoT devices and
constrained networks.
▶ URI Structure:
▶ Both protocols use a Uniform Resource ▶ Header Size:
Identifier (URI) structure to identify ▶ CoAP headers are smaller than HTTP.
resources. ▶ HTTP headers are more extensive due to their
▶ This allows clients to specify the target additional metadata and features.
resource in a standardized format.
▶ Reliability:
▶ Header Fields: ▶ CoAP provides optional reliability through
▶ CoAP and HTTP both employ header Confirmable messages.
fields to convey metadata about the ▶ HTTP uses TCP which inherently provides reliable
request or response. communication.
▶ These fields contain information such as
content type, cache control, and more. ▶ Usage and Scope:
▶ CoAP is specifically designed for constrained
networks and devices whereas HTTP is widely used
in traditional computing environments and the web.
 CoAP vs. MQTT
Differences between CoAP and MQTT
▶ Transport Protocol:
▶ CoAP operates over UDP and MQTT operates over TCP

Similarities between CoAP and MQTT ▶ Message Type:

▶ CoAP supports both request-response interactions and
▶ IoT Communication Protocols: asynchronous communication. MQTT is centered around
▶ Both CoAP and MQTT are IoT the publish-subscribe model, making it more suitable for
communication protocols that enable scenarios where devices need to broadcast data to multiple
efficient data exchange and subscribers.
communication between IoT devices and
applications ▶ Resource Interaction:
▶ CoAP is designed for direct interaction with resources and
▶ Lightweight and Minimal Overhead: supports methods similar to HTTP, such as GET, PUT,
▶ Both protocols are designed to be POST, and DELETE. MQTT is primarily focused on the
lightweight and have minimal overhead exchange of messages and doesn’t provide direct resource
manipulation capabilities like CoAP.
▶ Publish-Subscribe Model:
▶ CoAP and MQTT both support a
▶ Usage and Scope:
▶ CoAP is well-suited for scenarios where direct interaction
publish-subscribe communication model
with resources and RESTful principles are important, such
▶ Quality of Service (QoS): as monitoring and controlling IoT devices. MQTT is ideal
for scenarios where devices need to publish data to
▶ Both protocols offer various levels of
multiple subscribers efficiently, such as real-time telemetry,
Quality of Service (QoS) to ensure monitoring, and remote sensing applications.
message delivery reliability
▶ Topic Structure:
▶ CoAP uses the URI structure to identify resources, similar
to HTTP. MQTT uses a topic-based structure to organize
messages, allowing for more flexible and hierarchical
message routing.
How Does CoAP Work? (1)

Figure Source: [Radware, 2025]

▶ Request-Response Model:
▶ A client sends a CoAP request to a
server, and the server responds with the
requested data or action
▶ Use of UDP (User Datagram Protocol):
▶ CoAP requests mirror those of HTTP, ▶ UDP is connectionless and requires less overhead
including GET, PUT, POST, and ▶ Offers three levels of reliability (Confirmable,
DELETE Non-Confirmable, and Acknowledgement) to cater to
▶ Simplifies interaction with resources, various use cases
making it suitable for both IoT
device-to-server communication and
machine-to-machine interactions
How Does CoAP Work? (2)

Figure Source: [Radware, 2025]

▶ Multicast Support: ▶ Observe Mechanism:

▶ Enables a single CoAP message to be ▶ Adds a layer of efficiency to resource monitoring
sent to multiple recipients simultaneously ▶ A client may request to “observe” a resource’s state; The
▶ Reduces network traffic and efficiently
server then sends periodic updates to the client whenever
disseminates data, a feature that aligns the resource changes
well with resource-constrained ▶ Eliminates the need for frequent polling
environments
How Does CoAP Work? (3)

Figure Source: [Radware, 2025]

▶ Tokenization and Message ID:

▶ CoAP employs tokenization to track
stateful interactions, allowing clients and
▶ Proxying and Caching:
servers to match requests with responses ▶ Proxying allows intermediary devices to forward requests
▶ CoAP uses a Message ID to identify and between clients and servers
correlate requests and responses, ▶ Caching enhances performance and reduce network traffic
ensuring that the intended
communication is correctly processed
Layers of CoAP: Application Layer

▶ Defines the methods and interactions between clients and

servers
▶ Encompasses the request-response model and methods like
GET, PUT, POST, and DELETE
▶ Handles resource identification, manipulation, and the
exchange of data and control messages
Layers of CoAP: Message Layer

▶ Responsible for constructing and parsing CoAP messages

▶ Encapsulates the necessary information for communication,
such as message type, method, token, and options
▶ Ensures that data is packaged and structured appropriately for
transmission and processing
Layers of CoAP: Transport Layer

▶ Handles the actual movement of CoAP messages across the

network
▶ Primarily uses the User Datagram Protocol (UDP) for its
transport, providing a lightweight and connectionless
mechanism suitable for constrained environments
▶ Ensures reliable delivery of messages based on CoAP’s
optional reliability mechanisms
Layers of CoAP: Observation Layer

▶ Introduces the ability to observe resources

▶ Enables a client to ”subscribe” to a resource and receive
updates whenever that resource changes
▶ Enhances efficiency by eliminating the need for continuous
polling, conserving both energy and network resources
Layers of CoAP: Proxying and Caching Layer

▶ Proxying Layer allows intermediary devices to forward CoAP

messages between clients and servers, enhancing scalability
and accessibility
▶ Caching Layer stores frequently accessed resources to reduce
redundant communication, further optimizing the exchange of
data
▶ Benefits of a CoAP Proxy
▶ Protocol Translation: Enables communication between
CoAP and HTTP.
▶ Security Isolation: Protects constrained devices by placing
them behind a proxy.
▶ Scalability: Offloads processing from constrained devices.
▶ Caching: Some proxies can cache responses to reduce server
load.
CoAP Proxies (1)
▶ A CoAP proxy is an intermediary node in the Constrained Application
Protocol (CoAP) architecture that forwards CoAP requests and responses
between clients and servers. It can also translate between CoAP and other
protocols like HTTP, enabling integration with traditional web systems.
▶ Types of CoAP Proxies
▶ Forward Proxy
▶ Acts on behalf of the client.
▶ Forwards requests to the appropriate CoAP or HTTP server.
▶ Used when the client cannot reach the server directly (e.g., due to network constraints).

▶ Reverse Proxy
▶ Acts on behalf of the server.
▶ Clients send requests to the proxy, and it forwards them to the real server.
▶ Hides the server’s details and can be used for load balancing or firewall traversal.

▶ Cross-Protocol Proxy
▶ Translates between CoAP and another protocol, typically HTTP.
▶ Example: A client sends a CoAP request to a proxy that translates it into an HTTP
request to reach a web server.

▶ Key Use Cases

▶ Interoperability: Enable CoAP clients to talk to HTTP servers.
▶ Access control and security: Act as gateways for secure networks.
▶ Resource optimization: Reduce load on constrained nodes through
caching.
▶ Network abstraction: Allow clients to access remote or
differently-addressed devices.
CoAP Proxies (2)

▶ CoAP Proxy Use Case Example

▶ A CoAP client wants to access temperature data on a regular HTTP
server.
▶ The client sends a request to a CoAP-to-HTTP proxy.
▶ The proxy translates the CoAP request into an HTTP GET request.
▶ The server responds with HTTP data.
▶ The proxy translates the response back into CoAP and sends it to the
client.
▶ Security Consideration
▶ CoAP proxies must be trusted, especially when handling sensitive data.
▶ DTLS or OSCORE may be used for secure communication, but
end-to-end security is harder when proxies are involved.
Security Challenges with CoAP Proxies

▶ End-to-End Security Breaks at the Proxy

▶ When a proxy forwards messages, end-to-end encryption (e.g.,
DTLS) between client and server is not possible.
▶ This means the proxy must decrypt and re-encrypt messages,
introducing a trust boundary.
▶ The proxy can inspect or modify the content, which creates
privacy and integrity risks.
▶ Man-in-the-Middle (MitM) Risk
▶ If the proxy is compromised or malicious, it can: (i) Read/alter
data, (ii) Impersonate clients or servers, (iii) Log traffic or
inject malicious content
▶ Authentication and Authorization
▶ Proxies need mechanisms to authenticate clients and authorize
requests.
▶ However, CoAP itself does not define a built-in proxy
authorization framework.
Security Mechanisms and Solutions

▶ Object Security for Constrained RESTful Environments

(OSCORE)
▶ Encrypts the payload and certain options in a CoAP message.
▶ Works end-to-end even through untrusted proxies.
▶ Proxy can see the outer message (for routing) but not the
protected content.
▶ Proxy Authorization (RFC 8613 - OSCORE Proxy)
▶ Optionally, proxies can be configured to accept requests only
from trusted clients.
▶ May use access tokens or pre-shared keys for limited
authentication.
Message Formats in CoAP

▶ CON (Confirmable) Message:

▶ Sender expects an acknowledgment
(ACK) from the recipient and retransmits
the message until the ACK is received

▶ NON (Non-Confirmable) Message:

▶ Suitable for scenarios where real-time
Confirmable Message Communication
communication is prioritized over
Figure Source: [Payatu, 2025]
reliability

▶ ACK (Acknowledgment) Message:

▶ Sent in response to CON messages to
acknowledge their receipt

▶ RST (Reset) Message:

▶ Sent to cancel a pending CON message
that hasn’t yet been acknowledged
▶ Used when a receiver cannot or chooses
not to process a pending message

Each message contains a 16-bit message

Non-Confirmable Message Communication ID to uniquely identify a message and map
Figure Source: [Payatu, 2025] its corresponding ACK if any

Figure 1
CoAP Request/Response (1)

CON Message Request with Piggybacked Response

Figure Source: [Payatu, 2025]
Separate CON Messages for Request and Response
Figure Source: [Payatu, 2025]
CoAP Request/Response (2)

CoAP Ping Communication

NON Message Request and Response Figure Source: [Payatu, 2025]
Figure Source: [Payatu, 2025]
Role of Methods in CoAP
Methods indicate the type of interaction a client wants to have
with a resource on the server. CoAP supports four methods,
similar to HTTP:
▶ GET: The GET method is used to retrieve the current state or
value of a resource from the server. It is a safe method that
doesn’t cause any modification on the server.
▶ POST: The POST method is used to submit data to the
server for processing. It can be used to create a new resource
or trigger a specific action on the server.
▶ PUT: The PUT method is used to update or create a resource
on the server with the provided data. It replaces the current
state of the resource with the new data.
▶ DELETE: The DELETE method is used to request the
removal of a resource from the server. It signifies the intent to
remove the specified resource.
Real-life Applications of CoAP

▶ Smart Home Automation:

▶ IoT devices such as thermostats, smart lights, and door sensors
communicate with a central hub using CoAP
▶ Example: a CoAP-enabled smart thermostat could use GET requests to
retrieve temperature data from the central hub or use PUT requests to
update the desired temperature setting
▶ Industrial IoT (IIoT):
▶ CoAP facilitates communication among sensors, controllers, and
actuators.
▶ CoAP-enabled sensors can send real-time data about machine
performance to a central controller using CoAP POST requests; This data
can then be analyzed for predictive maintenance
▶ Environmental Monitoring:
▶ Sensors deployed in remote locations can use CoAP to send data about
temperature, humidity, air quality, etc., to a central server.
▶ CoAP’s lightweight nature and support for UDP make it suitable for
energy-efficient communication in remote and off-grid scenarios
CoAP Security Modes

▶ NoSec: No protocol level security, DTLS is disabled

▶ PreSharedKey: DTLS is enabled, there is a list of pre-shared
keys, and each key includes a list of which nodes it can be
used to communicate with
▶ RawPublicKey: DTLS is enabled, and the devices use an
asymmetric key pair without a certificate, which is validated
out of band
▶ Certificate: DTLS is enabled, and the devices use X.509
certificates for validation
Requirements of Secure IoT Operations
▶ Availability: services and information must be available when needed
▶ Data-to-data binding: binding of responses to a request or binding of
data fragments to each other
▶ Data-to-space binding: binding of data to an absolute or relative point in
space (i.e., a location) and may in the relative case be referred to as
proximity
▶ Data-to-time binding: binding of data to an absolute or relative point in
time and may in the relative case be referred to as freshness
▶ Freshness:
▶ A measure of when a message was sent on a timescale of the
recipient
▶ What is considered fresh is application dependent
▶ Replay protection:
▶ Most replay protection mechanism use a sequence number
▶ Assuming the client is well-behaving, such a sequence number
that can be used by the server as a relative measure of when a
message was sent on a timescale of the sender
Attacks on CoAP: The Selective Blocking Attack

▶ An on-path attacker can block the delivery of

selectively chosen requests or responses while
letting through others
Blocking a Request ▶ Encryption makes selective blocking of messages
Figure Source: [IETF, 2022]
harder
▶ The IP-addresses, ports, and CoAP message lengths are
available to all on-path attackers, which may be enough to
determine the server, resource, and command
▶ Attack on availability
▶ Remedy: Any IoT deployment of actuators where
synchronized state is important need to use
confirmable messages and the client need to take
appropriate actions when a response is not
received and it therefore loses information about
the server’s status

Blocking a Reply
Figure Source: [IETF, 2022]
Attacks on CoAP: The Request Delay Attack (1)
▶ An on-path attacker may not only block packets,
but can also delay the delivery of a selectively
chosen packet (request or response) by a chosen
amount of time
▶ If CoAP is used over an unreliable and unordered
transport such as UDP with DTLS or OSCORE,
other messages can be delivered before the
delayed message as long as the delayed packet is
delivered inside the replay window
▶ While an attacker selectively delaying a request to
a sensor is often not a security problem, an
attacker selectively delaying a request to an
actuator performing an action is often a serious
problem
▶ A request to an actuator (for example a request
to unlock a lock) is often only meant to be valid
for a short time frame, and if the request does
Delaying a Request not reach the actuator during this short
Figure Source: [IETF, 2022]
timeframe, the request should not be fulfilled.
▶ Using a replay window of length zero does not
solve this problem
 Attacks on CoAP: The Request Delay Attack (2)

▶ If a non-zero replay window is used (the default

when CoAP is used over UDP), the attacker can
let the client interact with the actuator before
delivering the delayed request to the server
▶ Lock example:
▶ Attacker may store the first “unlock” request for later use
▶ Client will likely resend the request with the same token
▶ If DTLS is used, the resent packet will have a different
sequence number and the attacker can forward it
▶ After a while when the client has locked the door again,
the attacker can deliver the delayed “unlock” message to
the door
▶ This attack can be mitigated by using a replay
window of length zero

Delaying Request with Reordering

Figure Source: [IETF, 2022]
Attacks on CoAP: The Request Delay Attack (3)

▶ A solution must enable the server to verify that the request

was received within a certain time frame after it was sent or
enable the server to securely determine an absolute point in
time when the request is to be executed
▶ Solutions:
▶ Use a challenge-response pattern, by exchanging timestamps
between client and server ⇒ requires synchronized time
between client and server
▶ Only allow requests a short period after client authentication
(TLS/DTLS handshake or an EDHOC key exchange
[RFC9528]) ⇒ requires larger messages and more processing
time
 Attacks on CoAP: The Response Delay and Mismatch
Attack (1)

▶ CoAP uses a client generated token that the

server echoes to match responses to request, but
does not give any guidelines for the use of token
with DTLS and TLS, except that the tokens
currently ”in use” SHOULD (not SHALL) be
unique
▶ The attacker performs the attack by delaying
delivery of a response until the client sends a
request with the same token, the response will be
accepted by the client as a valid response to the
later request
▶ If CoAP is used over an unreliable and unordered
transport such as UDP with DTLS, other
messages can be delivered before the delayed
Delaying and Mismatching Response to PUT message as long as the delayed packet is delivered
Figure Source: [IETF, 2022] inside the replay window
 Attacks on CoAP: The Response Delay and Mismatch
Attack (2)

Delaying and Mismatching Response to GET

Delaying and Mismatching Response from Other Resource
Figure Source: [IETF, 2022]
Figure Source: [IETF, 2022]
Attacks on CoAP: The Request Fragment Rearrangement
Attack (1)

▶ Request Delay and Blocking Attacks can be used against block-wise transfers to
cause unauthorized operations to be performed on the server, and responses to
unauthorized operations to be mistaken for responses to authorized operations
▶ This attack works even if the individual request/response pairs are encrypted,
authenticated and protected against the Response Delay and Mismatch Attack
 Attacks on CoAP: The Request Fragment Rearrangement
Attack (2)

▶ Blocks from two operations on a

POST-accepting resource are
combined to make the server execute
an action that was not intended by
the authorized client
▶ This works only if the client attempts
a second operation after the first
operation failed (due to what the
attacker made appear like a network
outage) within the replay window
▶ Remedy: If a client starts new
block-wise operations on a security
context that has lost packets, it
needs to label the fragments in such
a way that the server will not mix
Completing an Operation with an Earlier Final Block them up
Figure Source: [IETF, 2022]
Attacks on CoAP: The Request Fragment Rearrangement
Attack (3)

▶ If the first block of a request is

withheld by the attacker for later
use, it can be used to have the
server process a different request
body than intended by the client

Injecting a Withheld First Block

Figure Source: [IETF, 2022]
 Attacks on CoAP: The Relay Attack

▶ This type of attack can be performed in

deployments where actuator actions are triggered
automatically based on proximity and without any
user interaction
▶ Example:
▶ A car (the client) constantly polling for the car key (the
server) and unlocking both doors and engine as soon as
the car key responds
▶ The car is using an application specific challenge-response
mechanism transferred as CoAP payloads
▶ An attacker (or pair of attackers) may simply
relay the CoAP messages out-of-band, using, for
example, some other radio technology.
Relay attack (the client is the actuator)
Figure Source: [IETF, 2022] ▶ Remedy: Use stronger mechanisms to establish
proximity
▶ Measuring the round-trip time and calculating the
maximum possible distance based on the speed of light
▶ Using radio with an extremely short range like NFC
(centimeters instead of meters)
▶ Include geographical coordinates (from e.g., GPS) in the
messages and calculate proximity based on these
References I
Bormann, C., Castellani, A. P., and Shelby, Z. (2012).
Coap: An application protocol for billions of tiny internet nodes.
IEEE Internet Computing, 16(2):62–67.
IETF (2022).
Attacks on the Constrained Application Protocol (CoAP).
https://datatracker.ietf.org/doc/draft-ietf-core-attacks-on-coap/.
[Online; accessed 30-May-2025].
Payatu (2025).
IoT Security – Part 11 (Introduction To CoAP Protocol And Security).
https://payatu.com/masterclass/
iot-security-part-11-introduction-to-coap-protocol-and-security/.
[Online; accessed 30-May-2025].
Radware (2025).
What is CoAP? Understanding the Constrained Application Protocol.
https:
//www.radware.com/security/ddos-knowledge-center/ddospedia/coap/.
[Online; accessed 30-May-2025].