Radically Improving MQTT Security easily

Message Queuing Telemetry Transport or as it is widely known MQTT, has become a staple IoT messaging solution for many industries including Automotive, Transportation and the Energy sector for a quarter of a century.

MQTT provides a publish subscribe model for communications between clients of a centralized broker service running on a server. It's a classic hub and spoke model, the broker being the hub and clients being the spokes.

The model has been highly successful, and the protocol itself has become an industry standard, client software is lightweight, and the protocol has minimal overheads.

However, there are still improvements to be made in the architecture. The first being that you have to trust the broker as it gets all the messages in the clear and there is no easy way to have end to end encrypted communication between clients.?

The second issue is authentication of clients, this used to be simple - usernames and passwords - but we all know the issues associated with them. So many people have migrated to using certificates. Certificates are better but notoriously painful to manage, especially at scale. Imagine having to manage certificates on remote IoT devices with certificates that have a lifespan of a few months.?

The last major challenge is one that is an underlying problem of TCP/IP - the protocol that MQTT uses. TCP/IP, like MQTT, is a client server protocol, which means the broker has to be listening on an open port. An open port is an open door for attackers, and if your broker is on the Internet that’s an open door from the Internet directly to your broker software. At this point many decide that they do not want to have to manage that and use cloud-based brokers, but the problem does persist - there is an open door - even if not directly to your environment.

Let's look at these issues in reverse order using Atsign’s technology stack. By using NoPorts from Atsign it is now possible to have no open doors to the Internet but still provide access to authenticated connections to the broker software. Using NoPorts also removes the need to manage certificates on the clients, instead clients cut their own cryptographic keys (phew!).

The last issue is that of end-to-end encrypted messaging, Atsign provides a mechanism to clients to privately share cryptographic keys and so MQTT messages can be encrypted, sent, received and then decrypted. This means that you can use a broker run by a third party, or perhaps your own IT team, and although they can see the messages, they cannot decrypt them! End-to-end encryption has been available for MQTT for years but not many people (if any?) use it as it is difficult to manage and distribute those keys, using Atsign to distribute the keys makes life simpler.

A couple of last bonus features, if you use MQTT to manage something at home then Atsign also makes all those problems with network address translation, firewall rules, and dynamic DNS a thing of the past. Finally, the MQTT TCP/IP traffic is end-to-end encrypted with a new key for each connection and so negating the need for TLS and certificates.

?If you use MQTT and are seeing these issues and want to solve them, take a look at our MQTT Solutions page.