**3.2 CoAP: constrained application protocol**

The Constrained Application Protocol (CoAP), created by the Internet Engineering Task Force (IETF) working group called restricted RESTful environments (CoRE), has been adapted from HTTP, being optimized for devices with limited processing power and capacity, generally applied to intelligent objects in IoT environments [9]. CoAP acts on the UDP transport layer, specifying a minimum set of restrictions such as POST, GET, PUT and DELETE, with some support for resource storage and discovery of embedded resources.

According to [10], CoAP is a transfer protocol aimed at nodes and restricted networks, being designed for M2M applications, such as home automation. CoAP has four types of messages: Confirmable, Non-confirmable, Acknowledgmente and Reset.


The COAP uses the request/response model, where devices act as a client or as a server, supporting service discovery and include Web services such as the Uniform Resources Identifiers (URIs) [9].

The following are the main features of the COAP:


messages exchanged between broker and clients, using predefined topic identifiers

According to [8], the PDU of the MQTT protocol is encapsulated by the TCP

(**Figure 5**). In this way the MQTT protocol messages have a fixed header (**Figure 5**) composed of two bytes, where the first byte contains the field that identifies the type of the message, as well as the markers (DUP, QoS level and RETAIN). There is a version of MQTT, called MQTT-SN (MQTT Sensor Network), where your PDU is encapsulated by the UDP protocol, which, in turn, is encapsulated by the IP or the 6LowPAN protocol. One of the main differences between two standards, in addition to the network layer they focus on, is the simplification of messages exchanged between broker and clients, using predefined topic identifiers and short names of

• DUP (Duplicate delivery): Marker that occupies bit 4 and is activated when the server tries to resend messages of type PUBLISH, PUBREL, SUBSCRIBE or

• QoS: This marker represents the reliability of message delivery, indicating the level of guarantee of delivery of a PUBLISH message. You can have up to three levels of guarantee (**Figure 6**). Level 0 is used by those who publish/send the message at most once and does not check whether the message has reached its destination. This lower level is called "fire-and-forget" and the message can be lost depending on network conditions. In Level 1, called the recognized delivery, who publishes/sends a message at least once and check the delivery status using a status check message. However, if this verification message loses, the server broker can possibly send the same message twice, since there was no confirmation that the message has been delivered. Finally we have the QoS2, called guaranteed delivery due to its complicated process, there may be delays

and short names of topics in addition to a short message format [7].

topics in addition to a short message format [5].

UNSUBSCRIBE (**Figure 5**).

**Figure 5.**

**Figure 6.** *QoS levels.*

**160**

*Fixed header of an MQTT message.*

*Robotics Software Design and Engineering*

protocol, that is, the MQTT header and data are sent in the TCP data area

As can be seen in **Figure 5**, "byte 1" is responsible for four fields:

• PreSharedKey: used with devices that are already pre-programmed with the necessary key switches, where each key has a list of nodes that can

• RawPublicKey: the device has a pair of asymmetric keys without using a

According to [12], MQTT security as well as CoAP security (**Table 1**) is performed by Transport Layer Security (TLS). In [13] a safe application model for MQTT is proposed, namely SMQTT. This model is based on a lightweight attribute that provides encryption by broadcast, on elliptical curcas. According to the authors, SMQTT was resistant to attacks from known plaintext, known ciphertex

**Table 2** provides a summary of the security modes of the MQTT and CoAP

Proxyinge Caching The proxy is, in itself, a man-in-the-middle, breaking all the security of

Amplification Risk Responses in CoAP are generally larger than requests, which can facilitate

IP Spoofing Attacks Since there is no handshake for UDP, the final node that has network

Restriction with Nodes Whether energetic, memory or processing, make it difficult that devices

entropy, such as calculating keys, do it externally

**Protocol Security Modes AAA e Integrity Confidentiality**

List of Trusted Roots Uses DTLS

MQTT Uses DTLS Field for name and password uses DTLS Uses DTLS

spoofing of multicast requests; etc Cross-Protocol Atacks They involve using CoAP to send attacks to other protocols, to pass through the firewall, for example

It is possible to exploit vulnerabilities in the parsing process (process that analyzes an input sequence), to, for example, generate a denial of service attack by inserting text which will result in parser very extensive.

IPsec and DTLS. Threats are amplified when proxies allow to cache data.

access can perform spoofing to send messages from ACK instead of CON, preventing from retransmission; spoo pretend the entire payload;

have good entropy. Therefore, it is assumed, that the processes that need

AES-CCM

protocols. In the AAA and Integrity field, it refers to Authorization and

amplification attacks

• Certificate: the protocol makes use of the DTLS with an X.509 certificate, the

certificate, which is validated by an out-of-band mechanism;

device also has a list of known roots.

*Interaction Protocols for Multi-Robot Systems in Industry 4.0*

*DOI: http://dx.doi.org/10.5772/intechopen.97481*

communicate;

and man-in-the-middle.

Protocol Parsing and Processing of URIs

*Source: [11].*

*Source: [11].*

**Table 2.**

**163**

*Threats to the CoAP – RFC 7252 protocol.*

PreSharedKey Raw Public Key Certificate

*Summary of the security modes of the MQTT and CoAP protocols.*

COAP No Sec

**Table 1.**

**Atack Type Description**

**Figure 7.** *CoAP message format.*
