There’s been plenty of fretting in the CCTV industry about the cyber security levels of CCTV cameras. Do the same issues apply to some Internet-facing smart home devices and systems? Possibly – it all comes down to the configuration of communications paths and the level of integration applied between network devices and lightweight management controllers.
INTERNET of things is a concept much bandied about inside and outside the electronic security industry but when it comes to most professional security and smart home systems, things tend to be a closed shop. Networks of proprietary devices communicate via wireless, Z-Wave or Wi-Fi comms with a dedicated controller, which in turn communicates with remote smart devices and monitoring stations.
More complex home automation solutions integrating multiple domestic appliances throughout a home for centralised management are a different story. Such a system might incorporate light bulbs, air conditioners, blinds, thermostats, washing machines, irrigation systems and much more. For commercial applications, the demands will be greater still, as will the need for automation to manage the system. In such cases, consumers may want to wrangle all their devices with a single controller – it’s more likely to be a wee PC like Raspberry Pi, than an alarm panel controller. This said, MQTT is often present in smart home automation hubs.
While there are proprietary comms protocols abounding in the electronic security industry, in the wider world network comms is going to be some form of Message Queueing Telemetry Transport (MQTT) protocol. OpenStack, Open Geospatial Consortium Sensor, DeltaRail IECC Scalable, Adafruit, EVRYTHNG IoT, Amazon IoT, Home Assistant, Pimatic for Raspberry Pi, MS Azure IoT hub and more, all use MQTT for device communications.
What is it? Developed by Andy Stanford-Clark of IBM and Arlen Nipper of Cirrus Link on the back of the SCADA protocol back in 1999, Message Queuing Telemetry Transport is an ISO standard publish-subscribe-based messaging protocol which sits on top of the TCP/IP protocol and it designed to facilitate connection with remote locations when bandwidth and power are in very short supply, which is great for wireless-based home automation applications.
MQTT is a flexible protocol. The application layer 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, the Transport layer is just as comprehensive and the Internet and Link layers are well catered for. And it’s 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, which 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.
The publishing of a topic needs no information about subscribers, the subscribers need no information about publishers. Use of a topic to as a filtration system and file path via which to communicate with subscribers means a message gets delivered to the right subscribers. This means MQTT is great at bridging gaps between devices siloed by proprietary comms protocols – it forms a sort of auxiliary machine language – a mechanical Esperanto.
In standard trim, MQTT transmits connection credentials in plain text format – there’s no security or authentication applied – you need to use the TCP transport layer to incorporate end-to-end message protection. Alternatively, you could subscribe your devices to a something like the PubNub Network with MQTT for added security, additional functionality, as well as message storage and playback.
The security issues come into play with MQTT when it comes to configuration of a home automation system around a PC or a mini computer using server software like Mosquitto. If the server security config, such as access control, is muffed, then servers will be exposed on the Internet to basic searches uses programmes like Shodan and if a hacker gains access to the system then it’s not going to be complicated to gain access to the system and gather information on the state of the alarm system, the times residents come and go, as well as being able to deactivate or activate devices, such as sensors and door locks.
As mentioned, MQTT is often included in smart home hubs where it assists with the delivery of automation capabilities. The automation side of such systems resides onboard the hub and facilitates unification of devices, as well as providing a dashboard for the management of connected devices.
If MQTT is not included in the hub, it can be set up separately – in either case, it allows hubs to subscribe and publish messages about system state and operation, as well as to allow devices to communicate between each other to drive logic – for instance, if the soil sensor detects low threshold soil moisture, activate irrigation.
This capability represents the power of MQTT but also the fragility. A messaging protocol capable of driving system function needs to be thoughtfully configured if it is not to introduce vulnerability into a home automation solution if the server config is mishandled during the process of setup.
Part 2 of The IoT of MQTT next month
#sen.news
