I recently came across an article in TechTarget’s Internet of Things (IoT) Agenda that described the value of MQTT (Message Queuing Telemetry Transport) as a viable transport layer for wireless networks.
MQTT was designed for light-weight communications between resource-starved devices (such as mobile phones) and servers. Even though security was not designed into the protocol, there are some security safeguards it provides.
The protocol allows for client authentication which enables a two-way hand shake. This mechanism allows for encryption of data in the message if SSL/TLS is available on the resource-starved device. Since the user name and password that authenticate the client are in the clear in instances when SSL/TLS is not available, this two-way handshake is susceptible to hijacking and man-in-the-middle (MITM) attacks. Both mutual authentication and encryption are required to prevent hijacking and MITM attacks.
The challenges of using MQTT for the Internet of Things
As the article points out, because MQTT was not designed with security in mind, the protocol has traditionally been used in secure, back-end networks for application-specific purposes. Other negative aspects of MQTT is its lack of interoperability and minimal authentication features built into the protocol.
In spite of these considerations, many experts believe that MQTT will play an important role in the Internet of Things, facilitating such things as inventory tracking, automotive telematics, resource monitoring and medical body area networks (MBANs).
In order to overcome these obstacles, MQTT must look to a Software Defined Perimeter or “Black Cloud” to insure total security and protection.
By using the Software Defined Perimeter (SDP), the username/password login can be replaced with Single-Packet Authorization (SPA) and the receiving device can be “blackened” so that it can’t be seen by hackers. The blackening is an added layer of security and is beneficial with or without SSL/TLS. In cases where a device cannot employ encryption, having an SDP can at least allow cloaking of devices and prevent a hacker from stealing the username or password off the wire.
Because SPA packets contain a random, one-time-use field, no two SPA packets are ever alike. Also, all SPA packets are encrypted and authenticated with an HMAC signature, meaning malicious actors cannot spoof a SPA packet without first stealing all associated SDP credentials. This combined with the fact that the SDP Gateway logs all fully validated SPA packets, makes the broker immune to both faked and replayed SPA packets.
The SDP combined with clear text data messages will not guarantee total security for MQTT. Even if the SPA message can be trusted, nothing that followed would be safe from exploits such as snooping, spoofing, MITM, etc.
To ensure that MQTT is totally secure what will be required is the combination of SPA, SSL/TLS, and an MQTT messaging scheme that continuously updates cryptographic keys, all of which is the basis for SDP. Security can be greatly enhanced with minimal performance penalty using SDP. For many micro-devices where resources are constrained, encryption may not be possible but, SDP employs a Single-Packet Authorization (SPA) scheme. A connection recipient such as a data broker in an MQTT system can employ a drop-all firewall scheme, making it impervious to DDoS, port scans, and exploitation of vulnerabilities in the services being protected.
Modern networks and hardware are built to optimize encrypted communications and the penalty to processors rarely exceeds 2%. The benefits of encrypted communications far outweigh this negligible performance hit.
Watch the blog for more info about Software Defined Perimeters and Digital Risk Management Solutions.
