MQTT Security : IOT Part 16

Security in IOT cannot be an afterthought. It is an integral part of IOT development. The idea of IoT is not only to connect the normal daily things to the Internet but also to transfer the data securely among various end points so that smart IoT applications are not only efficient and successful in fulfilling various personal and professional requirements but also highly reliable. It be money transfer through online banking or it be online shopping, social or professional networking, maintaining confidentiality and privacy of end users is a must for any web or cloud based service.

To keep IOT systems secure from any attempt of hacking and attack, a general IOT security model has already been discussed. Now moving towards practical IOT development using MQTT application layer protocol, it is important to understand security features available in the protocol stack. These security features must be utilized and employed right from the initial phase of the IOT application development.

MQTT is a lightweight protocol intended for use by IoT devices having constraint resources and communicating over limited network bandwidth. Considering the vulnerabilities of IoT devices and systems due to the scalability of applications as well as deployment of devices and the continuous exposure of the devices to the internet, MQTT has been designed with security features enabled at Network Level, Transport Level as well as Application Level. By enabling security features at different OSI levels, different kind of attacks can be avoided. All these security features are standard mechanisms that have a common acceptability among various vendors and standard organizations.

Network Level – The protocol recommends connecting the devices using a gateway and then connecting the gateway to the broker through a VPN. The devices must be connected to the gateway using secure physical layer protocols like Wi-Fi, Zigbee, Bluetooth etc.

Transport Layer – The protocol uses TLS/SSL at the transport layer for the encryption of data packets. TLS/SSL is a standard transport layer protocol which not only allow encryption of packets but also have provision for client as well as server authentication using client and server certificates respectively.

Application Layer – At application level, MQTT has provision for both client authentication and data encryption. The client authentication is usually done at the broker side with the help of a client identifier and username/password credentials. The same method is used for device authentication as well. There can be either full transport layer encryption or simply payload encryption.

The MQTT protocol has the following security features –

1) Authentication – Authentication is a process to the verify identity of devices when they connect to the broker and communicate with other devices. This is like before boarding a plane, airport security verifies the identity of the passenger with the help of passport and photo ID. By showing the passport, a passenger authenticates himself to the airport authorities. The passport serves as the valid authentication of the passenger’s identity. No other document can serve as valid authentication in this case despite that document correctly states the name and credentials of the passenger. So, for boarding a plane, the passenger must have the specific document that is his passport.

Similarly, MQTT authentication is done with the help of a username and password. When it comes to authentication in MQTT, the protocol itself provides username and password fields in the CONNECT message. Therefore a client has the possibility to send a username and password when connecting to an MQTT broker. By setting the Username and password on the client, it will be sent to the broker in text format. This will allow eavesdropping by the attacker. So, the only way to guarantee a completely secure transmission of username and password is to use transport encryption.

The protocol allows advanced authentication by providing unique client ID to each client. The unique client ID is used by the client in the MQTT CONNECT message.  It is a common practice to use 36 character long UIDs or any other unique information available to the client like the MAC address of the network module or the serial number of the device itself.

2) Authorization – Authorization is a function of specifying access rights to certain resources. Authentication and authorization are different things. For example, If a passenger has to travel through a plane, then he has to show his passport (which serves as a unique ID for boarding any plane) to identify himself. This is called Authentication. After authentication, the passenger has to show the boarding passes for granting access to a particular plane on a particular date. This is called Authorization.

A MQTT client can basically do two things after it has connected to a broker, it can publish messages and it can subscribe to topics. In order to restrict a client to publish or subscribe only to topics it is authorized to, it is necessary to implement topic permissions on the broker side. These permissions need to be configurable and adjustable during the runtime of the broker. Topic permission could for example look like the following:

• Allowed topic (exact topic or wild card topic)

• Allowed operation (publish, subscribe, both)

• Allowed quality of service level (0, 1, 2, all)

This kind of topic permission allows the broker to specify authorization policies for clients and to limit their ability to subscribe topics and publish messages.

3) TLS/SSL Security – TLS provide security on transport layer. TLS is primarily used to provide secure communication channel. By encrypting data packets using TLS, their content cannot be read or altered by third parties. If authentication and authorization mechanism are employed by putting username and password fields in the MQTT connect packet, it is strongly recommended to use TLS. TLS has handshake mechanisms to negotiate various parameters to create a secure connection between clients and server. The Port 8883 is standardized for secure TLS/SSL MQTT connection. Many brokers (like Mosquitto) support TLS security.

As every packet gets encrypted in the MQTT TLS security, it increases the communication or handshake overhead. And this is not feasible for constrained devices. So, only if the IOT devices can bear the communication overhead, the TLS should be used every time. The use of TLS for full transport layer encryption is a choice to the developers. If the broker has provision for TLS encryption, the developer can use or avoid using it.

However, by using session resumption technique, the overhead in TCP connection over TLS can be drastically improved. The session resumption allows reconnecting with the broker without full TLS handshake repeatedly. The session resumption can be done in two manners either by using session IDs or session tickets. In session ID method, the broker stores the secret state together with a Session ID. When the client reconnects with broker, it sends the Session ID with which the session can be resumed. In session ticket method, the secret state is transmitted to the client and is encrypted with a secret key which only the broker knows. The client when reconnects with the broker, it sends this ticket back to it. If the broker can decrypt the contents again, the session is resumed with the state contained in the secret ticket.

The technique of session resumption though is useful only when clients have long living connection with the broker. In case, the client frequently disconnects and reconnects with the broker, this technique is not much useful.

4) Payload Encryption – Payload Encryption provides security at Application layer. Payload Encryption is used when a developer does not use TLS security but still don’t want to send the data as plain text. This gives an additional layer of security because this way also, all the application data is secured and encrypted. Payload encryption allows encryption for the actual application data instead of full transport level encryption. While application metadata (the topic) remains unencrypted, the payload or message still remain encrypted in this manner.

There can be two types of scenarios which are possible for encrypted messages –

a) End-to-End Encryption – This approach allows the application data to be encrypted all the time. The data is encrypted right it is published by the publisher to it is delivered to the subscriber. When broker receives the packet, it gets unencrypted topic (routing and QoS) and encrypted message and it cannot see the encrypted message. Only the trusted clients have access to the key to decrypt the message again.

This type of Encryption is used where a broker cannot use authentication and authorization or a public broker like broker.mqttdashboard.com is used. In this case the application developer can only encrypt the message or the actual application data but there remains no option to provide authentication and authorization.

b) Client to Broker Encryption: A Client-to-Broker approach makes sure that the payload of the message is encrypted in the communication between one client and the broker. The broker is able to decrypt the message before distributing the message, so all subscribers receive the original unencrypted message. This approach needs a broker plugin which decrypts the messages on-the-fly.

It is recommended to use Payload encryption only when TLS/SSL Security Encryption is not available by the broker or is not used despite availability. The Payload encryption prevents the data being hacked or attacked from Eavesdroppers but not from Man in the middle (MITM) attack. MITM can only be prevented if the whole data is sent through a secure channel as is provided in case of TLS encryption.

For more details on MQTT security, check out the following link –

In the next tutorial, learn to connect any PC or smart phone as MQTT clients using HiveMQ broker.