We are all familiar with desktop computers, laptops, servers, and smartphones (which I’ll group as “computers” in this article), which require constant updating to accommodate an ever-increasing variety of attacks.
At least they have the storage memory and processing power to accommodate the ever-increasing workload. The lifespan of these computers is on the order of two to five years, meaning that they will be replaced with newer and more powerful computers with the newer software and hardware technology required to keep up.
IoT devices, on the other hand, are being driven in the opposite direction: to be smaller, use less power and last longer (decades even) before they are replaced. It is fruitless to attempt to design these devices with a capability to be updated in some as-of-yet unknown way that would be required to defend against some attack types that won’t be invented for another 8 to 10 years.
Another difference: Computers, when being updated, are often attended to by humans who can intervene if the updating process hangs, has errors, or has other problems. Many IoT devices are deployed in remote areas (high-voltage transmission lines between cities), are widely distributed (a smart electric meter at every home) or difficult to access (built into a building and covered up). Over-the-air (OTA) updates can update those devices, as shown by many successful and unattended OTA updates for smartphones.
In the case of smartphones, if the update fails, the user has hands-on options to resolve the problem. But in the case of IoT OTA updates, if the update fails, it would require substantial effort for a human to go to each affected device to fix the problem. While OTA updates are a way of adding new security support, it is also a way that hackers could hack into to update IoT devices with malicious software.
A weak link is the de facto link used to connect these devices: TCP/IP. Computers and IoT devices of all flavors use this wide-open channel. Many security schemes and protocols are used, but it is still a common avenue for attack.
Guessing at what hardware requirements would be needed 10 years from now is also difficult. This article suggests using FPGAs and sending out hardware patches along with software patches when devices need to be updated. But that would require using larger FPGAs than initially needed, which would drive up cost and power consumption.
I have observed that most updates for apps and OS on my smartphone fall into three categories: new features, bug fixes and security updates. If we can significantly reduce or even eliminate the need for these three types of updates, security of IoT devices would be greatly enhanced.
I have discussed just a few aspects of IoT security. For more on other aspects, see this article.
I generally try not to just throw out lots of issues without proposing some potential solutions. In my next post, I will discuss an alternative approach to IoT design that might address some of these problems.