We are moving into a world of internet connected things. This is the world where your aging grandmother’s medicine cabinet reminds her when her medication has become due, when the irregular heart beat of your father triggers the scheduling of a cardio checkup, and when the home automation device decides that lowering the temperature of the room will help you drift off to sleep. Some of us are getting on the bandwagon enthusiastically and even, leading the technical charge, and some others reluctantly getting on it, for fear of being branded a Luddite, or worse still, being “left out”.
When the Internet of Things is an internet of playthings, then we do not mind an occasional failure, whether due to a pesky bug in this notoriously hard-to-program system or due to probing by a nosy prankster. But as this is maturing into an internet of serious things, we have to take failure modes seriously. In this article, I look at three aspects:
- Why are these things insecure today
- What can be done as a band-aid
- What needs to be done more fundamentally
Why Are These Things Insecure Today
There are three broad reasons:
- We want to pack as much functionality in these devices, which are constrained to start off with in terms of memory and computation.
- We are used to using them as playthings and not on a serious industrial scale where large monetary factors and worse human wellbeing are at play.
- The software and hardware development practices for these systems have not become mature enough.
Let us look at these three factors in a little more detail now.
We are packing functionality
Functionality in the IoT world sells devices and systems. What started off as primarily unimodal devices get relentless functionality upgrades. For example, what starts off as a heart rate monitor on a fitness tracker has mission creep to include monitoring of sleep patterns, which brings in the need to determine what is REM and what is non-REM sleep. There is also a race to make these systems more accurate and that gets prime play in sales brochures. But what gets no play is how often do these devices fail, either with a hard failure (crash, hang) or with a soft failure (giving wildly inaccurate readings, using up lots of resources to do the digital equivalent of thumb twiddling). The functionality has to be packed into the tens of MBs of memory that is standard on most devices. As Machine Learning models are incorporated into these, the memory that the model takes must also fit within the constraints. So you can see why those dreary exception handling routines or authentication check routines get short shrift. These concerns are nothing new and have been voiced many many times in the traditional computing environments, and those have with time and effort caught on to prioritize the resilience (to varying degrees).
From playthings to serious toys
We were used to these devices as mainly playthings. So what is the big deal if the speed tracker in my shoe conked off, I can just enjoy the run on my treadmill, which by the way already has a speed tracker. But synonymous with wide adoption of these devices is the fact that they will become serious pieces of computing equipment. Industrial control systems will be run based on data sensed by them and will be controlled through actuators included in them. We will “wear” these deeply embedded within us and they will be used to make clinical decisions. We will trust the safety of our homes to these devices, without having to run through the chain of what-if scenarios. So the reason we have not had resilience of these systems rise to the fore is that as of yet there was no pressing need for this. Non-functional attributes (such as, security, reliability, maintainability) traditionally follow with a delay after the functional requirements become clear. I expect that this trend will become more important as IoT systems become part of the ecosystem of serious consumer-grade and industrial-grade uses, and there is already early evidence for this trend, courtesy some well-publicized security attacks that have used IoT devices as launch pads [Mirai, Reaper].
Maturing of hardware and software development pipelines
The hardware and software development pipelines used to create the IoT systems are going through an understandable and expected process of maturing. Some practices that are standard for development of traditional IT systems and that aid in increasing the security and reliability of such systems are still largely absent in this space. In the hardware space, formal verification of systems (expressed in RTL or VHDL logic) is standard practice. In the software space, extensive testing is used, including recent developments like fuzz testing, and stateful fuzzing. Somewhat more on the research side, but still being used for high integrity systems, is formal verification of software, such as for verifying the SSL/TLS implementation used by AWS. These are time consuming and significantly increase the development cost. Additionally, they take some time to develop for any new target platform. IoT systems, with their heterogeneous platforms, therefore still need the development pipelines to mature and make such tools available.
What Can Be Done As Band-Aid
While we wait for new techniques to be developed to fundamentally make IoT systems more secure, there are three broadly applicable measures that can be implemented to improve the current state. These are all what can be called “common sense” but we know common sense is often not common practice.
- Providing an off switch
- Get off the “password” or “123456” bandwagon
- Contactless contact
Providing an off switch
Many devices do not need to be connected to an external network all the time. Sure it is convenient and sure it feels cool as the manager to say that I have an internet-accessible IoT network. But if you as a system owner really thought about it you probably do not need this, or need this all the time. So it will be super useful to include a kill switch on each device and collectively for the network, to remove any network connection or even connection to the network outside the corporation. Thus, in times of a security breach, with relative ease we would be able to prevent the attack spreading out or data from within the system being leaked out.
Getting off the “password” or “123456” bandwagon
We all know that remembering hard passwords is hard. On IoT systems, even typing in passwords is hard. So it is that many IoT systems leave the vendor-supplied default password on, during operation. Long after the device was purchased and put to use. So one can consider that there will be a default forcing of the change of the default password when the device is first switched on. There should be some standard checks for the hardness of the new password. Further, because the small form factor often makes it hard to enter a password, it should be possible to use biometrics for authentication. While fancy schemes, like using retina scans remains firmly the realm of Hollywood, using fingerprint scans and such other less fancy biometrics is very much within today’s reality.
Contactless contact
This is just a cryptic way of saying the more technical term — over-the-air (OTA) updates. This means it should be possible for the vendor to provide updates OTA. Apple does it for consumer devices and Tesla does it for its cars. Updates typically are content updates, but they can also be firmware updates and security updates. Tesla learned how useful this was in patching security vulnerabilities over a vast number of its cars. This should be standard, so that when security vulnerabilities do arise and become known to the vendor, it can send the patch, securely, OTA so that the devices do not have to be recalled. Such updates can be done as needed and without the logistical hassles of end users having to bring them back to a store.
What Needs to be Done More Fundamentally
This is an area where active research is going on. It is speculative which of the research ideas will be applicable in practice and then which of those will win out in the marketplace. Two common themes underlie many of the research solutions.
First, the IoT devices need to be rearchitected in both hardware and software so that security vulnerabilities in any one component do not compromise the entire device. Second, the IoT networks need to be rearchitected so that compromise of a single device does not let the infection spread unfettered through the entire network.
These research directions need moderate to significant changes to the hardware, the software, and the networking development pipelines for IoT. They are distinguished in three dimensions:
- What kinds of attacks they protect against — someone taking control of the system, someone leaking data out of the system, etc.
- What level of adversaries they protect against — someone trying brute force attack or someone who has reverse engineered the software and found say a memory corruption vulnerability.
- What is the cost — this is in terms of the changes to the development pipelines as well as the cost in resources that will be needed at runtime.
There is some fairly technical reading on this front for those who are looking to get into the field, or for those who are brave at heart. [Paper 1-S&P 17, Paper 2-NDSS 18, Paper 3-ARM TrustZone, Paper 4-EuroSys 14, Paper 5-DAC 15].
So it seems to me that IoT systems will increasingly be used in settings where we need to trust that they will function securely. Do we wait for a series of headline-grabbing security catastrophes to learn from our mistakes? Such catastrophes will be costly in monetary terms, and much more worryingly, in terms of human wellbeing. Or, can we leapfrog the technology generation in the IoT world. Can we build in security as a first order principle, as we have done in some (though far from all) domains in the server world? Then the Internet of Things can be the Internet of Secure Things and we can sleep easy. Doubtless our sleep tracker will tell us of that improvement.
Distant Whispers from an Academic Engineer's World 