As IoT (The Internet of Things) grows, obviously security risks associated with that are going to grow too. Let’s take a look at some of the wireless protocols that IoT use and see which of them might have security weaknesses. IoT applications transfer data from sensors to the IoT cloud application where that data can can be analyzed and processed. In some applications the IoT app sends instructions in the other way, back down to the IoT device, so that it can send instructions to the machine to which they are attached or do maintenance items like download and install software updates on the IoT computer card. Examples of this are industrial monitoring, vehicle fleet maintenance, and home automation. For example, a fleet monitoring system can monitor a truck’s brake temperature to alert the operator when it is time to replace brakes. As an other example, sensors can monitor a diesel generator for vibration. An increase in vibration would indicate an increased load on the motor thus indicating some kind of maintenance is need on whatever the engine is attached to. If the engine temperature rises too quickly, the IoT application can shutdown the machine directly. If an IoT device is close to an electrical source and thus cabling it can use an ethernet network for communications. But if it is attached to door or window or out in a field, far away from any facility, then it needs some type of wireless communication.
IoT uses radio transmission protocols many of which are designed to consume little battery power by working at slow transmission speeds, sending data at kilobytes per second rather than the high bandwidth of megabytes per second used by the Wi-Fi wireless protocol. Some of the IoT protocols are ZigBee, BLE (Bluetooth 4), and Z-Wave. These are designed to transmit data only a few meters.
So they either transmit data to another IoT device or send their data to some kind of router which then sends it on to the cloud. Another IoT protocol is cellular. That we can say has problems right up front. The GSM encryption standard used to encrypt cellular traffic has known security weaknesses that cannot be fixed simply because there are already a billion cell phones out there that could not be upgraded. But that does not matter as you can encrypt traffic and then send it over GSM thus encrypting it a second time.
Open Security Research in 2013 described some possible attack vectors against Z-Wave. Z-Wave is commonly used in home automation systems like burglar or fire alarms or smart home appliances. One obvious target of that hacking would be to unlock someone’s home, warehouse, office, or garage door. (That kind of hacking gives a whole new dimension to the notion of “backdoor,“ doesn’t it?)
That paper does not illustrate how to attack the Z-Wave protocol per se but rather the difficulties of doing do. For example, the programmer discusses how to brute force attack the Home Id, which is the serial number of the device. That is a 32 bit number, so there are 4.3 billion possibilities. The approach would be to ping the device with a random Home Id and wait for an ACK meaning and acknowledgment when the hacker sent one that was valid. But there are problems there including that you would wear one of the memory chips long before you changed it’s value 4.3 billion times: it seems you need some kind of access to either end to make this attack work, which is not likely. And to snoop and spoof the traffic you would need a 900 mhz high gain antenna and be within 20 feet of the device. Contrast that with, say, the 2.4 ghz radio frequency used by Wi-Fi. There are lots of packet sniffers available for Wi-Fi, but not many and certainly not many affordable ones for Z-Wave.
To attack Zigbee the researchers took advantage of that particular Zigbee implementation, which sends the encryption key in clear text when a new device joins the network. (At least one other protocol has that problem, the PPP protocol used by VPN.) Using this approach, other researchers were able to grab the security key from Philips Hue smart lightbulbs by noting that it sends that out in clear text when the lightbulb is rebooted. (That sounds odd doesn’t it, to “reboot a lightbulb.”)
Researchers concluded the problem is not with Zigbee itself but how it is implemented by certain vendors. So when all those weaknesses are documented one presumes those issues will be fixed by the vendors.
IoT is still new in many sectors. Thus it will take some time to mature. Perhaps that will help fix any issues with security transmission protocols or replace it as has been done with PPP VPN.