Constraints of Internet of Things devices
While the security problems faced by Internet of Things (IoT) devices aren’t new, these devices raise some specific challenges that aren’t present in modern web and mobile development.
Devices aggressively conserve power
When we spoke to IoT manufacturers, preserving battery life was the number one requirement we heard about. Many devices run for months or years on a single battery. Therefore, manufacturers go to great lengths to reduce energy consumption by hibernating devices and minimising the use of high-power radio chips like Wi-Fi.
This particularly influences connectivity: power-conserving devices will periodically connect, send and receive data, then disconnect, shut down the radio interface and put the processor to sleep until later. Where possible, low power, low data-rate protocols like Bluetooth Low Energy and LoRaWAN are used over faster, higher-powered Wi-Fi and GSM.
Security updates can only be delivered when a device is connected. This means there is a battery-life cost associated with doing a security update.
Limited memory, CPU and flash memory
The hardware capabilities of desktop and mobile devices seem to be endlessly increasing. But for IoT devices, there is constant pressure to minimise the cost of all the components.
The current lack of memory and processing power in IoT devices limit the type of computation they can do, in particular running public key cryptography which use large keys.
Flash memory is perhaps the most restrictive element in IoT devices. The devices we heard about had around 1 megabyte of flash memory. All the compiled software, firmware and any other data the device can download needs to fit in this space. In contrast, mobile apps are around 50 megabytes and can also use gigabytes of flash storage on the smartphone.
Flash memory is even further constrained by the need to keep spare memory for downloading firmware updates. The ‘A/B strategy’ is often used in IoT devices, which means a new firmware version is downloaded alongside the existing one in the flash memory. That means the device needs twice as much flash memory as its code size, raising the price of the components.
Devices have slow, intermittent network connections
Minimising the amount of data sent and received from a device is important for limiting the cost of data transfer, as well as conserving battery life.
Cellular networks like GSM are typically charged by the megabyte. In addition, low power radio interfaces tend to have low data-rates too — so the radio needs to be enabled for a long time, which consumes battery. For both these reasons, it becomes important to minimise the amount of data being sent backwards and forwards.
For an organisation operating a small number of devices, the cost is small. But for deployments to thousands of devices, the cost of data can rapidly become significant.
To further maximise the efficiency of data transfer, it’s common to use protocols with low overhead — in other words, as little ‘envelope’ data as possible. An example is Google’s protobuf inside MQTT.
Contrast this with a mobile application receiving JSON over HTTP — both schemes are fairly inefficient in terms of protocol overhead.
Lack of accurate time
Security protocols like TLS rely on having a good idea of the time, in order to verify whether a certificate has expired, for example. PCs and smartphones keep excellent time because they have good internet connections, enough processing power to run Network Time Protocol (NTP) and real-time clock hardware (although it is worth noting that there are security risks with NTP).
IoT devices aren't as accurate at keeping time because they tend to have more intermittent internet connections.
Failed updates are expensive
Perhaps the strongest concern we heard from manufacturers was the importance of recovering from failures in an update procedure.
We heard about a number of ways an update can go wrong:
- The firmware gets corrupted on the network during the download
- A hardware error occurs while writing the flash memory of the device
- The device loses power during an update
- Human error causes a valid but broken firmware update to be issued (for example the firmware is aimed at a different, incompatible device)
- There’s a bug in the firmware which wasn’t apparent on test devices
- The update server gets hacked and the firmware replaced with a bad equivalent
The manufacturers we spoke to were very concerned about bricking multiple devices through a bad update. One person described it as a ‘company killer’, since they would not be able to afford to recall a large number of devices.
Greater complexity — bigger stack
One manufacturer described how product development has become increasingly complex over the last decade.
In addition to the hardware development and embedded software, product teams now need to maintain backend infrastructure, web applications, frontends and potentially native mobile apps.
All of these are significant disciplines in themselves, and understanding the whole stack well enough to make devices secure is impractical for small teams designing and building IoT devices.