Enthusiastic promotion for the Internet of Things (IoT) is rising like an all-pervading dawn over the electronics landscape. From home automation to transportation systems to telemedicine, the concept of connecting local devices—or even individual actuators and sensors—to the Internet is illuminating new wonderful possibilities. Manage your home from your smart phone? With the IoT it’s natural. Connect images, vital signs, and blood chemistry of an isolated rural patient to a diagnostic expert-system running on ten-thousand servers? With the IoT, it’s easy, they say.
But some experts warn that a very dark cloud is spreading toward this glorious dawn. Unlimited connectivity, these designers caution, brings unlimited vulnerability. Yet security remains among the least-discussed topics in the public IoT furor.
Early this month, a panel at the IoT Developers’ Conference sought to rebalance the discussion. Experts engaged in initial deployments of the network sought to explore deeper into the growing shadows of risk that mar the IoT dawn.
At first glance, the notion of security on the IoT might seem amusing, or at worst annoying. Do I really care if someone hacks into my toaster? Maybe I care more if a vandal turns off my refrigerator. I certainly care if burglars disable my home security system and unlock my back door.
The risks extend to institutions as well. One recent report claimed that a hacker had launched a denial-of-service attack from a botnet of invaded home appliances. Another exploit circumvented an enterprise firewall by attacking an Internet-connected vending machine in a corporate office.
But these attacks pale beside the possible. “Some scenarios are simply terrifying,” declared Cisco senior technical leader Rodolfo Milito. “We have already seen a demonstration of hacking an insulin pump. Do we want to see a hacked pacemaker, or a successful attack on a moving vehicle?”
But, you might object, malicious people have been attacking Web sites for years. Why is the IoT different? Milito answered that question with several points. Today, he observed, there are less than 20 billion endpoints on the Internet. Each one is an intelligent device, capable of some level of security software. And, crucially, “each device has a person behind it—someone who can observe and say, ‘wait—that doesn’t look right.’” Milito said. Tomorrow, the IoT may have far more than 50 billion endpoints, of many different kinds. The proliferation vastly extends the attack surface. Milito continued: “Worse, the new endpoints will be assembled into systems that can directly change the physical world. And these systems will be assembled by domain experts, not security experts.”
If the danger is real, and potentially dire, what can we do? Panelists began by categorizing the things we need to protect. Freescale Semiconductor senior strategic marketing manager Joe Byrne suggested four categories of security: authentication and non-repudiation, integrity, confidentiality, and availability (Figure 1).
Figure 1. There are four aspects to IoT security, each of which has its own requirements
“Authentication is about verifying who you are,” Byrne explained. “It is the basis for allowing access to a device, and it depends on signatures and keys. Integrity means your data is accurate and stable over time. It requires trusted platforms and solid encryption. Similarly, confidentiality—keeping private data private—relies on encryption, both at rest and in flight. And availability basically means using network security features and anti-malware.”
“The positive news is that there are good, existing solutions for each of these challenges,” asserted Steve Singer, vice president of world-wide field applications engineering at security vendor Inside Secure. “We have certificates and multi-factor authentication. We have secure protocols to ensure confidentiality. To make sure code is genuine, there are hardware-based secure platforms.”
“The issue,” contributed Oracle director of product management Jai Suri, “is putting the pieces together to get end-to-end security.”
Clearly the problem is a compound one. I order to ensure that devices on the IoT perform as intended, all four facets of security are essential. But must we enforce all four at each level in the IoT network? Or can we allow some levels to take over responsibility for others?
For example, does an individual temperature sensor have to have a unique device ID, a trusted platform, and encryption/authentication capabilities? Or can we count on a local WiFi or Zigbee hub to protect the devices attached to it? Answering such questions requires looking deeper into the structure of the IoT.
The first observation about the structure of the IoT is the lack of agreement about it (Figure 2). Everyone agrees that the top level of the network hierarchy will comprise applications, running either on dedicated servers or in cloud data centers. These resources will be connected through the Internet to lower layers. And everyone agrees that the endpoints—the Things—are at the bottom of the hierarchy.
But are the Things self-contained, functional systems, like a home thermostat or an insulin pump? Or are they individual sensors, actuators, and displays, which the applications group together in ad-hoc clusters to perform a function? How you answer that question also influences the next: what kind of network aggregates the Things that work together as a system? Is it a Zigbee network using a dedicated hub or a smart phone to reach an Internet gateway? Is it a WiFi hub, or a local server? The answers today are application-specific—often vendor-specific. But they can profoundly influence the security strategy in their little corner of the IoT.
These two uncertainties—just how capable the endpoints will be and just how they will be connected to the Internet—create uncertainty about just how the IoT will provide security. The panel examined the issue at each level in the network hierarchy, starting at the top, where there are the fewest worries.
Application software gathers the subsystems, sensors, and actuators of the IoT into systems and gives them their intelligence. But where does the application run? The conventional answer would have been to run the application on an embedded processor in a dedicated box. But that is not the IoT way.
IoT apps will generally run either in a cloud or on a dedicated, Internet-connected server, like any Web app. And here, elaborate security measures already exist to protect applications from attack. The measures don’t always succeed, but they prevent casual intrusion, and breaches are sealed soon after they are detected. A whole industry sees to it.
The situation is similar in the Internet network itself. Assorted claims about government agencies and back doors notwithstanding, traffic moving through the switches and links of the internet is arguably on the safest portion of its journey. But once that traffic passes through a gateway, the questions start.
Traffic between the Things and the Internet will have to pass through some sort of gateway. The gateway device may belong to an Internet service provider, a wireless service provider, or possibly the vendor of the IoT system or even the end user. But with ownership comes responsibility. “You have to contain intrusions at each level of the network,” Suri warned. “That effort depends upon secure gateways.”
If the Things in the IoT system are themselves subsystems, they likely will have Internet-Protocol (IP)-based Ethernet connections to the gateway. So traffic in this last leg of the IoT can use normal IP security measures.
But Ethernet and IP are demanding of the systems that terminate them. If the endpoint Things are individual sensors and actuators—devices too compact, inexpensive, and low-energy to support an Ethernet port, there will be another level to the hierarchy. There will typically be a hub that will aggregate a number of short-range, usually wireless connections. And Milito warned the panel that “these wireless connections may be vulnerable.” Often they are optimized for lightness of protocol or for energy efficiency, with little thought to any aspect of security.
“In reality, security protocols in the net already exist,” Singer observed. “Hackers go to the endpoints.” Indeed, the further you move down the IoT hierarchy toward the endpoints, the more vulnerable the whole system appears, and the fewer existing standards seem to apply (Figure 3). IoT aggregation networks that use short-range wireless links, low-energy protocols, and proprietary boxes—or, perhaps worse, smart phones—as hubs present opportunities for attack. But these nets may not be as vulnerable as the endpoint devices themselves.
If the endpoint is itself a complex system—such as an industrial controller or a server, for example—in principle it will have the hardware and software resources to support a unique identity, authentication, and encryption. But as many well-publicized exploits have in recent years shown, many system vendors have not designed-in these security measures. Instead, vendors have either trusted the anonymity of their boxes or the protections of the network to which they were attached.
If the endpoints are simple—wearable or implanted sensors, or actuators built into machinery, for examples—there simply may not be the resources in the endpoint to support much of a secure connection. “Even light-weight encryption would help,” Singer said.
But Kaivan Karimi, Atmel wireless group vice president and general manager, warned “Many edge nodes are run by small microcontrollers (MCUs). To the MCU guys, security means silicon reliability and tamper detection, not authentication and encryption. Edges are the number-one most vulnerable places in the network.”
Knowing that fact and fixing it are two different things. If MCU-based endpoints are incapable of protecting themselves, then some entity higher up the hierarchy must assume the responsibility, somehow shielding both the Thing and the connection to it.
The foundation of such an umbrella, Suri emphasized, is that every device in the IoT must have a unique identity. The identity may be a serial number in non-volatile memory, for example. Higher layers of the IoT will use that identity to authenticate transactions with the endpoint, and to determine what transactions are safe to conduct with it.
Increasingly, security experts are calling for an identity that cannot be stolen or copied. The primary way to achieve this is a physical unclonable function (PUF). A PUF is a piece of hardware, embedded in an endpoint, that will generate the chip’s ID number based on physical processes (such as process variations between individual transistors) that are stable, unique to that particular die, and nearly impossible to reverse-engineer, even if you have the die in your lab. A PUF-based identity, then, could only be stolen by capturing and cracking an authentication transaction in which the ID number appears.
In order to protect the endpoint devices, Suri explained, a branch of the IoT would include a server acting as what Oracle calls an identity manager. This device would maintain tables recording the ID number of each device under its supervision in the IoT. The table would connect the ID number to rules governing who could interrogate the endpoint, how often it could be accessed, and so on.
By controlling the sources of traffic allowed to reach the endpoints, the identity manager can help prevent uninvited access to or damage of data, the triggering of inappropriate actions, or denial of service attacks. But in some cases the identity manager may need to know not just the apparent source of a message—which can be spoofed—but its content as well. In these cases the manager must have rules not just for allowable addresses, but for allowable packet contents. The task begins to look less like filtering and more like deep packet inspection.
It is possible to take security further. When a group of IoT endpoints form a system with the potential to do harm, Karimi said, we need another point of view.
“Approach the group of endpoints as a system—turn the network upside down,” Karimi suggested.
Milito elaborated the same point. “If you think of a cluster of endpoints as a system, the system will usually have a limited, definable set of interactions.” So a security monitor that knows what the system is supposed to do and what it must not do—perhaps with knowledge of the external context as well—can provide a final layer of protection.
For example, such a system would know not to turn the home furnace to full heating on a 35 C day, no matter from where the command appeared to come. Such rules represent a departure from mere traffic inspection: they are not about the network traffic, but about the behavior of the system.
But where in the network should such a safety monitor reside? If the rules are complex, it is tempting to group them with the application software, perhaps in a cloud where the monitor would have access to a far wider range of contextual data. But this risks an attack interposing between the safety monitor and the endpoints. “If the device is critical, you want safety measures inside it, not outside,” Milito insisted.
The panel uncovered an interesting point hidden in this notion of a cluster of endpoints as a system. Responsibility for security and safety rests with the design team that knows how the system is supposed to behave: the original system developer. But system vendors and application developers come and go. And by its nature the IoT is fluid: sensor data from one system may be used later in another application, and several applications may share some actuators or displays.
“One possible outcome,” Karimi suggested, “is that the IoT will evolve a model of security as a service. As today you contract with a company like ADT to secure your home, perhaps tomorrow you will contract with someone to secure the interactions between the endpoints in your possessions with the IoT.” With all the fluidity of the Internet of Things, and facing the unrelenting creativity of hackers, at the end of the day security will be a continuing battle that will be fought between humans.