MQTT Security: What You Did Not Consider
MQTT Security: What You Did Not Consider
When using connected devices, even one as seemingly benign as a toaster, proper security and authentication measures are invaluable. Read for an overview MQTT and IoT.
Join the DZone community and get the full member experience.Join For Free
So you have decided to use MQTT for your multi-billion dollar IoT product, or you have decided to IoT enable your home toaster. That's great, but have you carefully thought about the complete security requirements for an MQTT solution?
With MQTT comes great opportunities and serious responsibilities.
MQTT is a publish/subscribe (pub/sub) protocol that easily facilitates one-to-many communication, and it does so whether you need it or not. You may have millions of devices connected to a broker, and you may have chosen to use MQTT for only pushing data from these devices to the cloud, but the protocol still allows communication between all devices.
Let's say you have a Gmail account and someone gets hold of your password. That person will have access to your Gmail account only. However, if Gmail had been using MQTT as the protocol for mail, the person would have access to all the millions of Gmail accounts out there. To understand how this is possible, one needs to have a deeper understanding of the publish/subscribe (one to many) paradigm and the wildcard subscription feature provided by MQTT. When using MQTT, it's important to select a broker that also enables you to enforce strict authorization. To harden an MQTT solution, wildcard subscriptions should be disabled in the broker. Make sure your MQTT broker provider supports this feature.
Unfortunately, far too many MQTT deployments fail to take the above seriously. If you plan on using MQTT, you must carefully think about the consequences for failing any of the following security considerations:
Is it safe to use MQTT without authentication?: no.
Is it safe to use MQTT without TLS?: no, password sent in cleartext.
Is it safe to use MQTT without strict authorization?: no.
Should wildcard subscriptions in the MQTT broker be disabled?: yes.
The one-to-many messaging and wildcard subscription features in the MQTT protocol forces the additional requirement of a multilayered defense system. If you have not read my multilayered defense system tutorial that also explains how to use authorization, I recommend reading it now:
The MQTT broker must be configured to require client authentication. However, how do you plan on safeguarding the credentials on the device? You may decide to use X.509 certificates as the client to broker authentication method, but note that an X.509 certificate has a distinct fingerprint and it is very easy to find the certificate inside the firmware. A hacker may extract the certificate from the firmware and use the certificate to log in to your MQTT broker using say a Python MQTT client. If you do not deploy a multilayered defense system, the hacker can compromise all devices connected to the broker should he be able to compromise one device. There are many ways to harden the device and prevent firmware extraction. The following whitepaper (PDF) goes into details on how to safeguard credentials stored in a device:
If you have been following a number of MQTT discussions, you may have heard that small devices, so-called edge nodes, cannot directly use a TLS enabled MQTT protocol stack and that you must use a gateway for communicating with the cloud. This would be true if only OpenSSL had been available as a TLS stack. Fortunately, many small TLS stacks facilitate the use of MQTT in small resource-constrained devices. If you are interested in testing MQTT on a small device, purchase an inexpensive ESP8266 WiFi chip and use the FreeRTOS/lwIP ESP8266 IDE we have put together. The SDK includes a secure MQTT stack and example code that makes it very easy for you to test a TLS enabled MQTT stack.
You may download the ESP8266 Device SDK from: https://realtimelogic.com/downloads/sharkssl/ESP8266/
Note that the MQTT example we provide uses a broker that requires authentication and the communication is encrypted using TLS; however, the example is still not secure since the online MQTT broker does not support authorization. A real solution must use authorization, even if it is used just to control your own toaster.
Additional MQTT related security information you may find interesting:
Opinions expressed by DZone contributors are their own.