Security in IoT – Security solution for IoT communication protocol

The goal in this post is to give an overview of the security goal in IoT applications (CIA Model) and see if MQTT and CoAP protocols satisfy this goal. Due to rush to the market security in IoT devices often neglected. A small number of IoT devices support some protection and security which most of them are software-based however, hardware aspects are unprotected. Consequently, new attacks raise and as mentioned in [1], non-secure hardware leads non-secure software. In this section, common IoT stack protocols along with their security issues and solutions in each layer are introduced.

Security goal in IoT

Security goal in the Internet of Things is to provide a reliable connection between entities, and proper authentication mechanism together with confidentiality about data. This goal leads to the information security triad which offers CIA or Data Confidentiality, Integrity and Availability as shown in Fig. 1. Any thread in each of these areas can cause serious damage to the system and have a direct impact on the working of the system [2].

Fig. 1: CIA Security Model[3]

Data Confidentiality refers to the ability to provide and ensure privacy for sensitive information of the user. It can be achieved by data encryption such as ciphertext. Data Confidentiality in IoT generally means that the IoT devices don’t connect and transmit data to an unauthorized server or entity.

Data Integrity is the ability to secure data from cybercriminals during communication or external interference during data transit. Cyclic redundancy and checksum are two methods for checking data integrity.

Data Availability aims to provide data for users whenever needed. User should be able to access data not only in normal conditions but also in disastrous conditions. DoS attack can cause denying data availability and can be solved by using Firewalls in the network in order to block the attack. IDS and redundancy methods are other mechanisms to protect data availability.

IoT Protocol Stack

IoT applications are using different protocol stack in order to establish a communication, the following table (Table 1) illustrates a sample of the IoT OSI layer and their corresponding protocol in each layer. Each of the protocols in this stack may bring some security issues during communication and the focus here would be an application layer. In the following sections, common protocols in the application layer along with their security issues and solutions will be introduced and compared.

IoT Protocol Stack Protocols
Application Layer IETFs CoAP, IBMs MQTT, XMPP, AMQP, etc.
Transport Layer UDP, DTLS, TCP
Network Layer IPv4/IPv6, RPL, 6LoWPAN (adaption)
Physical & Data Link Layer IEEE 802.15.4, IEEE 802.11/WiFi, BLE, ZigBee, etc.

Table 1. IoT Protocol Stack

Application Layer

This layer is basically responsible to ensure effective communication between IoT devices which are constrained in resources and insecurity in this part can cause different security issues such as DDoS attack against a server by capturing the server information such as username and password. Application layer uses different protocols such as Message Queue Telemetry Protocol(MQTT), Constrained Application Layer Protocol(CoAP), The advanced message queuing protocol (AMQP), etc. for passing message at the application level. The standard threads in this layer are data leakage, DoS attack, Malicious Code Injection. Among application layer protocols, CoAP and MQTT overcome are well-suited solutions for constrained-resource applications due to their small header size and power consumption [4] and in rest of paper, the three aspects of CIA model in these two protocols will be considered and compared.

Message Queue Telemetry Protocol(MQTT) This protocol is widely used by different cloud providers and uses publish/subscribe method for exchanging data between entities. This simplicity in the model together with open source code makes it suitable for constrained IoT devices and M2M communications. One of the advantages that this model has is supporting multicast communication between devices. IoT devices can subscribe to specific topics and the broker will filter all incoming messages from the publisher and distribute them correctly to subscribers. Moreover, it reduces the transport overhead and protocol exchange and as a result, would be a reduction in network traffic. Basically, It provides three options for to accomplish the Quality of Service (QoS) which are at least one delivery, at most one delivery and exactly one delivery [5]. Having said that it can’t be used in real time applications.

Security in MQTT MQTT protocol by default does not satisfy the CIA model, the reason is that it does not provide any data encryption, consequently, it leads to privacy/confidential issue. In [6], researchers show that whether MQTT broker uses authentication mechanism or not, data can be sniffed easily. Similarly, it does not provide data integrity and therefore, it is possible to filter out the data according to its port, broker IP and topic using applications like Wireshark and Ettercap and change the data. Other key things to remember is that if the broker is using username and password as an authentication mechanism, the attacker can retrieve them by sniffing the network and filtering the ”Connect” packet. One solution for making a secure MQTT communication would be using TSL/SSL in order to provide transport encryption. Therefore, the communication would be secure against eavesdropping which means that it can be a solution for data transit attack [7]. Having said that, it is not only an optimal solution for constrained IoT devices but also the TSL/SSL with certificate and session key management for heterogeneous IoT devices is burdensome [8]. The other solution would be using Secure MQTT (SMQTT) which based on lightweight attribute-based encryption (ABE), over elliptic curves and it not only solves the data transit attack issues but also offers scalable key management and reduce the heavy computation cost of TLS [7].

Constrained Application Layer Protocol(CoAP) is based on HTTP which matches IoT requirement such as constrained node with low capability in RAM or CPU, and constrained network, such as lower power using wireless personal area network. It depends on RESTful which is adapted from HTTP and it consists of two-layer namely message layer and request/response. The first layer controls the message exchange over UDP between two endpoints. In fact, in order to avoid costly TCP handshakes, it uses UDP as transport layer protocol [9] which supports unicast and multicast requests. The second one is responsible for handling requests and responses. Besides, CoAP supports of Machine to Machine (M2M) communication requirements [10].

Security in CoAP Similar to MQTT, CoAP also require additional encryption in underlying layers and due to using UDP as a transport layer, the encryption using in this layer accomplished using Datagram Transport Layer Security (DTLS) and sometimes IPSec [10]. By using DTLS along with fundamental advanced encryption standard counter mode & CBC-MAC (AES/CCM) will provide confidentiality and integrity of data. Basically, CoAP defines four security modes which are no security, pre-shared key, raw public key, and certificates. In pre-shared key mode, devices are programmed with symmetric cryptographic keys which is the proper solution for devices that can’t employ public key cryptographic. However, in raw public key mode is for devices that require authentication based on the public key. In this mode, devices can initiate a DTLS session without certificate and in certificate mode, by assuming the availability of security infrastructure, authentication is based on public key for devices that include asymmetric key and have unknown X.509 certificates.


In comparison with CoAP, MQTT provides higher throughput and lower latency [11]. Table 2 represents briefly the similarities and differences between these application layer protocols.

Parameter MQTT CoAP
Mode of message exchange Synchronous & Asynchronous [12] Asynchronous
Transport Layer TCP UDP
Reliability Through different QoS levels Built-in reliable mechanism
CIA model Doen’t fullfil alone Doen’t fullfil alone
Security Solution SSL/TLS [12], SMQTT [8], SecKit [13] & [14] DTLS [12], IPSec [10]
Header Size 2 Bytes [2] & [4] 4 Bytes [2]

Table 2. IoT Protocol Stack


To summarize, we covered some basics and important aspects of security for IoT devices. It is important to consider that security issue in one layer can cause security issues in other layers as well, for instance, security issue in the physical layer of IoT model can cause issues in the application layer as well. In the next post, the goal would be analyzing the security aspect of Mongoose OS and considerations that we should have in mind when we want to connect a device to AWS IoT.

Continue Reading: Insecure physical layer cause insecure application layer

Last post: Distributed Danial of Service (DDoS) II

Add a Comment

Your email address will not be published. Required fields are marked *