Message Queuing Telemetry Transport, or as it is widely known, MQTT, is a standards-based messaging protocol, or set of rules, used for machine-to-machine communication. It 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, with the broker as the hub and clients as the spokes.
The protocol’s lightweight client software and minimal overhead, combined with its quarter-century track record in industries such as Energy, Automotive, and Transportation, have solidified its position as an industry standard for IoT messaging.
However, there are still some improvements to be made in the architecture:
- You have to trust the broker. It gets all the messages in the clear and there is no easy way to have end-to-end encrypted communication between clients.
- Authentication of clients is difficult. It used to be simple - usernames and passwords - but we all know the issues associated with that model. Certificates are a popular workaround. While somewhat better, they are notoriously painful to manage, especially at scale. Even if you're not trying to keep up with thousands of certificates, some of them only have a lifespan of a few months, and must be renewed often.
- You have a built-in security liability. There is an underlying problem with 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 for any connection requests. An open port is an open door for attackers. If your broker is on the Internet, that’s an open door from the Internet directly to your broker software. Many decide that they do not want to have to manage that, so they use cloud-based brokers, but the problem persists - there is still an open door - even if not directly to your environment.
Let's look at these issues in reverse order when using Atsign’s technology stack:
- You have built-in security. NoPorts from Atsign makes it possible to have no open doors to the Internet and still provide access to authenticated connections to the broker software.
- Using NoPorts removes the need to manage certificates on the clients. Instead, clients cut their own cryptographic keys (phew!).
- There’s no need to trust the broker. Atsign provides a mechanism to clients to privately share cryptographic keys. This means MQTT messages can be encrypted, sent, received, and then decrypted. 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 NoPorts to distribute the keys makes life simpler.
A couple of last bonus features:
- If you use MQTT to manage something, then Atsign also makes all those problems with network address translation, firewall rules, and dynamic DNS a thing of the past.
- The MQTT TCP/IP traffic is end-to-end encrypted with a new key for each connection, negating the need for TLS and certificates.
If you use MQTT and want to solve these issues, visit our MQTT Use Case to learn more.
