By Todd Ouska, wolfSSL
The Message Queuing Telemetry Transport protocol, or MQTT, has become a favorite of Internet of Things (IoT) developers, and why not? It’s incredibly lightweight (on the order of a couple Kb for client implementations), has easy-to-use APIs, and is available for free under the Eclipse Public License (EPL). If your connected application is something simple and relatively contained – like remote monitoring the temperature in your living room, for example – that much is probably enough to make you happy.
But what if your application is a little more complex? Say you’re combining multiple sensors, an HVAC system, a little intelligence, and MQTT to automatically adjust the climate in your home based on occupancy, and you’ve also configured remote management into the application so you can manually override instances where your dog tripped the infrared proximity sensor (sorry, Spot). Or maybe after some hard work you’re deploying a similar commercial system and need to update a sensor platform’s firmware to provide more precise measurements. So at what point is “enough” good enough? The answer depends on you and your application.
MQTT is a publish/subscribe protocol, meaning that would-be “clients” in the traditional networking model can act as both publishers of and subscribers to messages related to particular topics. Messages are distributed using the transmission control protocol (TCP), but rather than being indiscriminately broadcast, clients send messages through a central MQTT broker that accepts messages from a publisher and distributes them to the subscriber(s) to that topic at varying quality of service (QoS) levels.
However, in order to keep the protocol as lightweight as possible for resource-constrained IoT edge devices, the MQTT specification offers nothing on top of TCP for security outside of a recommendation that the transport layer security (TLS) protocol be used for applications that require additional levels of authentication. As a result, MQTT communications that rely on TCP alone are unencrypted and susceptible to man-in-the-middle attacks.
To illustrate what this means in more detail, let’s go back to our two “complex” examples from earlier. Say a proximity sensing platform publishes a message to the MQTT broker with the topic “home/occupancy.” The MQTT protocol does allow the use of a username and password for client identification, but these are displayed in text if some form of encryption isn’t used. Therefore, an eavesdropper could potentially impersonate a client subscriber and decrypt a message payload, or even imitate a client publisher and issue fake or modified messages. In terms of the personal home application this could signal to prospective thieves that no one is home, and in the commercial deployment scenario has serious implications on processes like remote firmware updates.
TLS tradeoffs
As mentioned, the MQTT protocol does recommend the use of TLS for more sensitive MQTT implementations, and a network port (port 8883) has even been reserved for this purpose. TLS is the successor of the secure sockets layer (SSL) protocol, and provides an encrypted communication channel over which MQTT messages can be sent. Before the channel is established TLS uses a handshake to pass certificates (or keys) from the publisher to the broker, but also between the broker and subscribers. If successful a secure channel is established, if not, the connection is aborted. Easy enough, right?
Well, maybe not. The downside of using TLS, SSL, and other methods of encryption is that they can add significant overhead, which is probably why you chose to use MQTT in the first place. For example, at wolfSSL we recently released an MQTT client library (wolfMQTT) with a compiled size of 3.6 kB. A TLS handshake alone can consume that much, without accounting for the encryption overhead on the individual packets themselves. For certain resource-constrained embedded devices, particularly those based on small microcontrollers, this added workload can simply consume too much in terms of CPU resources.
Techniques such as session resumption can compensate for some of the connection costs of TLS, and hardware acceleration is also a method for reducing the size penalty for encryption. Another important consideration is selecting an optimized encryption library when securing system communications, and in the case of wolfMQTT, integrating the lightweight wolfSSL embedded SSL/TLS library resulted in a compiled size of 20-30 kB when paired with hardware acceleration.
In the end, the decision when and how to implement security in your MQTT-based IoT system depends on you and your application. If you decide to move forward with transport-layer encryption, some best practices include working with MQTT libraries that are open source and allow you to look under the hood, but also provide documentation and examples of how encryption could be implemented in your application. If you’re a commercial entity using MQTT, make sure to partner with a vendor that has security credentials and also supports the widest range of operating systems and embedded chipsets possible in order to avoid lock-in.
For more, check out our secure firmware update example written in C that demonstrates encrypted communications to and from an MQTT broker using TLS.
For more information about wolfSSL and wolfMQTT, or about some of our other products (wolfSSH, wolfCrypt), contact us at facts@wolfssl.com
Todd Ouska is Co-Founder and CTO of wolfSSL.
wolfSSL
www.wolfssl.com
@wolfSSL
LinkedIn: https://www.linkedin.com/company/wolfssl/
Facebook: www.facebook.com/wolfssl
