A few months ago we took a look at MQTT, which is a protocol that runs over the TCP/IP network and allows unrelated devices from disparate manufacturers to communicate with each other in a coherent way. In MQTT Part 2, we delve a little deeper into MQTT-based security and automation.
As we discussed, MQTT is a flexible protocol that runs on top of the TCP/IP network and covers BGP, DHCP, DNS, FTP, HTTP, IMAP, LDAP, MGCP, MQTT, NNTP, NTP, POP, ONC/RPC, RTP, RTSP, RIP, SIP, SMTP, SNMP, SSH Telnet, TLS/SSL, XMPP and more. It’s transport layer is just as comprehensive and Internet and Link layers are well catered for. MQTT is compact. The smallest control message might only be 2 bytes in length (the header), though such messages can extend to 256MB.
Operationally, MQTT uses a hierarchy of topics to communicate and it manages this by firing a control message of data to a connected broker or server, which then distributes the data to clients on the network subscribed to that topic. There’s an elegant simplicity to all this that’s just like an RSS feed. Because it was developed as a SCADA protocol, MQTT was created to manage short telemetry data messaging in off-line environments.
MQTT has no standard and it can carry any payload you throw at it, publishing it to all subscribers and that’s great and dangerous at the same time. Before we go further, consider that a given instance of MQTT uses # to represent all levels at its location – if a device is subscribed to /home/familyroom/# it will receive any message published to /home/familyroom/lock or /home/familyroom/light. If a ? symbol is included in the string /home/?/familyroom/lock/# then the device will get all messages relating to locks.
MQTT really powers up with smart home hubs, which subscribe and publish MQTT messages and deliver logic. Such hubs also generate a dashboard from which users can manage their system. MQTT allows the hub to put messages together and automate disparate devices that don’t understand each other’s language. For instance, when the ambient temperature reaches 30 degrees on the verandah, the air conditioning in the living room will turn on.
This central communication capability is where issues can arise with MQTT. The MQTT server is the interpreter between devices, while the smart hub manages devices and delivers system logic, and MQTT-enabled devices are installed in the system and connected to the MQTT server. The stumbling block is that the MQTT server probably doesn’t have a secure config or may be misconfigured and if anyone can access that server, they can read all a system’s MQTT messages relating to any devices in any location by simply subscribing to # on the system.
It gets worse because some MQTT servers are internet facing and don’t have a password. Users who deploy Mosquitto to manage a home hub but have no ACL or don’t actively configure an access control list leave their system open to being subscribed to by network intruders. They will be able to read all communications and can also publish messages that will control MQTT-enabled devices connected to the MQTT server they have breached. In some cases, misconfigured MQTT servers expose the smart hub dashboard to the internet – there are tens of thousands of MQTT servers exposed on the internet.
Things can get trickier still because a lot of MQTT servers feature owntracks/ which is an iOS and Android application that’s fundamentally a GPS tracker used to manage the system based on geo-location. This is problematic because it allows your location to be tracked by showing the GPS co-ordinates and even the altitude of a connected smart device.
Typically, owntracks/ is configured without encryption or authorisation and to set it up, a smart device needs to be exposed to the internet. Then there’s the fact a message is sent to owntracks/ each time a linked phone changes its location. The level of detail is significant and historical with time and date – it even includes the battery level of the smart phone being tracked and this tracking is going on in real time.
Applying security to MQTT-governed devices comes with certain challenges. For instance, IoT devices are constantly looking for an opportunity to fall asleep to preserve battery life and manufacturers are will minimise processing power and memory to reduce current drain. This means cryptography is often beyond them. Further, many IoT devices are self-governing so setup is easier – that means they are likely to be less secure, not more secure. Then there’s the fact MQTT is meant to be lightweight – it’s not designed for the heavy lifting of secure communications.
To secure MQTT enabled systems, you need a physically secure gateway like VPN to carry messages between server and devices. If you don’t want anyone to be able to read your system’s messages, then TLS/SSL will give transport comms encryption that’s relatively easy on processing and quite secure.
At the application level, comms can be encrypted and the identity of parties in the system may be subject to authentication. This may be handled using payload encryption at the application level, which saves the labour of transport encryption. Part of this may be use of whitelists, which only allow connection to trusted applications and URLs rather than attempting to block a list of known threats which must be regularly updated.
#sen.news
