# Security of IoT Application Layer Protocols: Challenges and Findings
## 4 Messaging Protocols
### Mitigations  
To cope with security threats, the MQTT standard lists the mechanisms that should be included in MQTT implementations, namely:  
* Authentication of users and devices;
* Authorization of access to server resources;
* Integrity of MQTT control packets and application data;
* Privacy of MQTT control packets and application data.  
For each of these mechanisms the standard provides some general recommendations (e.g., re-authentication of long sessions, prevention of subscription to all topics, usage of VPNs). Nevertheless, it is often up to the developer to choose the mechanisms most appropriate to the specific application requirements. In addition, as pointed out by [PERSON] et al. (2018), the standard mainly refers to simple scenarios and does not discuss details of complex scenarios, such as broker  
Figure 1: Example of access control vulnerability that allows an attacker to subscribe to all topics and receive all messages being published. The numbers refer to the temporal evolution of the MQTT interactions depicted in the figure.  
interconnections and synchronization mechanisms between brokers. Therefore, these issues require additional research efforts.  
Even though the use of the TLS protocol is strongly recommended by the MQTT standard to ensure secure communication, TLS does not solve all security issues. In fact, it is well known that older versions of TLS, its misconfiguration and the use of weak cipher suites make protocols exposed to security attacks [23; 24]. In addition, the implementation of TLS requires a significant computing power and network bandwidth which might not be available on constrained IoT devices.  
In the literature, many papers focus on TLS with the objective of devising implementations more suitable to MQTT-enabled IoT devices (see, e.g., [25; 26; 27; 28; 29; 30; 31; 32; 33]). For example, to ensure message confidentiality and integrity, [PERSON] et al. [28] propose an approach based on the Blake2 algorithm [34]. This approach--very promising in terms of performance on constrained devices--is particularly appropriate in industrial environments where sensors and controllers exchange predictable data. [PERSON] et al. [32] propose a secure version of MQTT which uses a new control packet, called Spublish, to publish encrypted data and takes advantage of the Cipher-text 232 Policy/Key Policy Attribute Based Encryption using lightweight Elliptic Curve Cryptography [35; 36].  
To introduce an enhanced access control mechanism on constrained devices where TLS is too expensive, [PERSON] et al. [25] developed a lightweight authentication mechanism based on a chaotic algorithm. Similarly, [PERSON] et al. [30] propose an MQTT architecture based on a modified version of the OAuth framework [37] where two sets of credentials are used by the devices to access the broker.  
Access control is also studied in [38; 39]. More precisely, to enforce security policy rules, [PERSON] et al. [38] developed a connector that intercepts the messages exchanged by the broker and generates proper notifications that might lead to the execution of an enforcement action. Similarly, the mechanism proposed in [39] is based on the use of a proxy that monitors the exchanges between clients and servers.  
Another problem addressed in the framework of TLS deals with the proper configuration of TLS-enabled devices. For this purpose, [PERSON] et al. [40] developed an automated software agent based on a state machine model to help the identification of TLS vulnerabilities. In particular, the agent checks possible misconfiguration by means of certificate validation.  
In summary, our analysis has shown that the MQTT protocol supports a good number of security services although these services in general do not cope with all possible security risks affecting the protocol.