Smart and secure: choosing IoT devices which shouldn’t compromise your home 3

Do you want to welcome the whole world to inspect your smart devices?

In the first article in this series, I laid out some questions which you need to ask when selecting a smart device to put onto your network, and in the second I covered operating systems and their updating. I move on to even more important issues: how the device communicates.

How does it communicate within the local network? Does it only connect with a WiFi base station, or does it operate its own mesh network with other smart devices? What security standards apply to local communications?

We are used to wired network connections, almost all now using Ethernet, WiFi using the IEEE 802.11 family of standards, and Bluetooth using an industry standard which has now reached version 4.2. Smart devices most commonly use the latter two forms of wireless networking, and add their own systems which you will probably not have come across.

IEEE 802.11 is relatively wide area, high speed, and typically used to link to your router, as it is now almost universally supported by consumer (modem-)routers. Because it is so commonplace, it has many accessible tools to sniff out available WiFi networks, which help you increase their security, but also make it a popular target for intruders.

As I have pointed out, although smart devices using WiFi connections should use WPA2 security and all the measures normally expected in a modern wireless network, they may also impose limitations, such as requiring the base station to advertise its SSID, and not supporting Enterprise WPA2 such as RADIUS servers. My introduction to WiFi security may also be helpful guidance.

Bluetooth covers much smaller areas, and although widely supported by computers (for wireless connection of keyboards, other interface devices, and other peripherals), it is not usually found in routers. Tools for sniffing it are much less common, and it is an unusual means of attack unless the intruder has gained access to your premises.

These connections are made many-to-one in a star form: your WiFi network may have many devices connected to the one base station, and your computer may have several Bluetooth peripherals connected to it.

Mesh mess

Smart devices may also operate mesh networks such as Weave, in which each device connects to those devices nearest it, in a mesh. This is considered advantageous as it enables them to connect even further from a single base station, overcoming physical barriers such as walls, and provides redundancy in the network which can counter the effect of individual devices dropping out. However it also opens up opportunities for an intruder to connect a bogus device into the mesh, even if they are in a publicly accessible area outside your building, where they cannot ‘see’ your wireless base station.

Many smart devices use low-rate wireless networking based on the IEEE 802.15.4 family, which includes ZigBee, WirelessHART and MiWi. The family can also be used with 6LoWPAN and standard TCP/IP networking to build a wireless local Internet. Unfortunately the standards and their implementations are very complex, and security and encryption are not mandatory throughout, although a sound framework is provided.

Of these, ZigBee is the widest-used and best-known, and should be secured using 128-bit (AES) symmetric encryption. Just a month ago, Tobias Zillner of Cognosec reported that ZigBee had been exploited. He assessed a home automation system, a smart lighting system, and a smart door lock, finding that an attacker could gain control of these systems, and that there is no means of locking an intruder out. This is in spite of the security features provided in the ZigBee standard being very strong and robust, and reflects weakness in implementation.

Tools to ‘sniff’ ZigBee and other specialist networks are not readily available to users, although they are becoming available to potential intruders.

Worringly, some smart devices communicate locally without effective encryption, allowing an intruder to eavesdrop, and using intercepted communications to mimic a device in order to gain entry to the network. All local communications must be robustly encrypted using keys which cannot be stolen or guessed.

How does it communicate with the Internet? What security standards apply to remote connections? Does its use open up any part of your firewall or other potential point of vulnerability?

I should not have to point out that all communications between smart devices and the Internet (the remote device server) must be securely encrypted, e.g. using SSL, discussed here. Amazingly, one of the baby monitors tested by Rapid7 used insecure streaming, so you should not assume that vendors will follow this.

Various vulnerabilities have been detected, and patched, in implementations of SSL; you should be confident that the version being used is current, and not vulnerable, and that it can be updated rapidly in the event of further security patches.

No smart device should ever require you to open an incoming port in your firewall, but should always find a more secure solution, such as using an outward connection to its remote server. If you wish to see the consequences of opening ports in that way, take a look at Shodan, billed as being the Google of IoT: it looks for open ports in firewalls, documents them, and makes them available for anyone to view via its search engine.

Leave a port open in your firewall, and the whole world can now see it, thanks to Shodan.
Leave a port open in your firewall, and the whole world can now see it, thanks to Shodan.

Potentially secure ways of accepting incoming connections, such as port knocking, are intricate and for the time being should be avoided in consumer systems.

Before you do anything else, look up your current external (Internet) IP address, and type it into Shodan to check whether your network has already been spotted as having open port(s). Hopefully it will return no results for your IP address too.

The next article in this series will focus on the security of the vendor’s server, which is probably going to prove the most contentious issue of them all.