We have reached the stage in the evolution of the Internet of Things (IoT) where two independent processes have become self-sustaining. The first—the creative process—has begun to uncover genuinely compelling applications. Beyond $40 internet lightbulbs, in-refrigerator Webcams, and toothbrushes with smartphone apps, systems developers are starting to see—and to prototype—applications at the convergence of smart sensing, cloud-based analytics, and distributed control. These applications promise unprecedented returns for their users.
But at the same time a second process—a more skeptical one—is gathering momentum. In this process, hackers, security experts, and safety engineers are watching with growing alarm as control systems with the potential to do great harm are drawn out across connected hubs, the Internet, and public clouds, creating an enormous attack surface (Figure 1). Exploits that can seize control of cars, incinerate houses, or bypass the safety interlocks of nuclear reactors can in theory be staged against any vulnerable link in these newly distributed systems.
Elements of both these processes were evident last month at the Internet of Things Developers’ Conference in Santa Clara, California. From the rollcall of vendor presentations to the keynotes, the event blended growing excitement with growing apprehension.
Analytics are Central
You can do many amusing things by allowing a swarm of sensors, controllers, and actuators to exchange messages over the Internet. But in enterprises, the big gains seem to come when the cloud captures all the data and performs big-data analytics to find hidden, predictive patterns. Analytics change the game from a struggle to understand what has happened to the ability to predict what will happen.
The conference’s first keynote, from Renesas Electronics America General-Purpose Products Unite vice president Vin D’Agostino, illustrated this point. “To exploit the IoT,” D’Agostino counseled, “you have to change your thinking about solutions. Solutions happen in the cloud.”
D’Agostino described a system he had worked on for what might seem a thoroughly mundane industrial client: a supplier of commercial deep fryers for restaurants. “There are three aspects to this business,” he explained. “Operations, maintenance, and oil transport.” By instrumenting the deep fryers and storage tanks, the client was able to collect masses of data about the operation of the equipment, the condition of the frying oil, and the amount in the reservoir. By pulling this data back to the cloud, the company was able to predict failures and roll maintenance trucks before the restaurant had anything stop working or catch fire. Just as important, the client was able to optimize transport of oil, ensuring the restaurant had what they needed, waste oil didn’t accumulate or get stolen, and trucks were used efficiently.
But D’Agostino’s team encountered a number of challenges in implementing the system. “Finding stable stacks, assembling a platform of APIs, microcontrollers, and operating software, and establishing a secure link to the cloud all appeared to be problems. The team was able to resolve them in this case by using a predefined platform from Renesas and OS vendor Express Logic.
Still, integrating the embedded system into the cloud was non-trivial. “One thing you learn,” D’Agostino observed, “is that cloud guys and IoT guys don’t understand each other.”
At the Edge
Nothing could illustrate this misunderstanding more clearly than the disparity of resources between the cloud and the IoT edge. In the cloud, computing, storage, and bandwidth appear to be there for the taking: the only limitation is your budget. Need another 1,000 servers? No problem! But at the edge, things are very different, as Linley Group president Linley Gwennap described in a report on IoT client SoCs.
The IoT edge is forcing the emergence of a new class of microcontroller units (MCUs), Gwennap said. These new devices must still support the I/O and local computing of traditional embedded designs. But they must also support a variety of wireless links, from low-energy Bluetooth dialects to WiFi, to new categories of the 4G cellular LTE specifications. They must be secure. And they must achieve all of this under swinging cost and power constraints.
“Consumer Things are expected to sell for under $50 retail,” Gwennap cautioned. “Industrial prices will follow. That puts a very low ceiling over the cost of the MCU in the system.” Accordingly, the new MCUs are becoming wireless SoCs, adding protocol engines, crypto engines, and wireless baseband processors to the traditional CPU cores, memory, and analog/digital I/O, but without driving costs up too far.
The uncertainties in wireless standards and customer choices make these chips risky business for the vendors, Gwennap warned. Among wireless protocols the chips may face emerging peer networks based on short-range protocols like Bluetooth, new IoT-oriented networks like LoRa or Sigfox, Wi-Fi, and wide-area networks like 802.11ah and new LTE categories, not to mention proprietary industrial networks. Add in the fact that some applications require a TCP/IP stack and some require Precision Time Protocol, and the number of variations becomes huge. So does the range of computing requirements.
The uncertainties over connectivity are more than echoed in discussions of security. Embedded designers, if they consider security at all, may think in terms of the rudimentary authentication and encryption offered by protocols like Transport Layer Security, and often supported adequately by a generic crypto accelerator, as long as public-key transactions are infrequent. But cloud security experts may be expecting data-center-style security measures such as multi-factor authentication and a Hardware Security Module (HSM) to protect keys. More demanding experts may expect the physical tamper resistance of a smart-card chip. As the IoT system’s potential to do harm increases, all of these expectations become entirely rational: compromising the MCU may lead to successfully compromising a huge industrial system or an enterprise data center.
Toward a Secure Cloud
But data center experts must examine their own houses as well. If data analytics are the key unlocking the potential productivity gains of the IoT, security within the cloud becomes a major factor in securing IoT systems. This was the message in a keynote by Reiner Kappenberger, a product manager at HP Enterprise (HPE).
Kappenberger began by sizing the stakes. Even if you ignore the risks of material and financial loss, there are increasing regulatory costs for neglecting security, he warned. In the European Union, for example, an organization can be fined up to 4 percent of its top-line revenue for violating the General Data Protection Regulation (GDPR), a rather detailed mandate on how companies must protect private data. An attack on a relatively minor IoT system that ends up compromising an enterprise’s servers could become a financial catastrophe and the end of a CEO’s tenure.
Accordingly, Kappenberger said, data centers must protect data at rest, in transit, and in use. Along with strong measures to block and detect intrusion, this means strong encryption. But the speaker warned against relying on what he called “old-fashioned” block ciphers. These encryption techniques, commonly used in secure storage systems, can protect data in storage or in the data-center network. But when the data arrives at server memory each block must be decrypted, leaving the information vulnerable to attacks such as SQL injection or memory snooping.
Instead, Kappenberger recommended format-preserving encryption, also known as homomorphic encryption. These techniques, still a very active area of research, preserve the format of data while it is encrypted. They also have the property that if you perform a function on the encrypted data, you will get same result as if you had decrypted the data, performed the function, and then encrypted the result. This property allows big-data analytics to operate directly on the encrypted data without ever having decrypted information in memory. Thus, for example, a smart-highway application could analyze location, speed, operating conditions, and other telemetry from vehicles and reach conclusions for traffic management without ever having access to the actual locations or identities of individual vehicles.
Such ideas offer powerful new protections for data in use—but only if the keys are secure. That bit is non-trivial. One of the easiest attacks on many IoT systems is to find a device in which keys are poorly protected, and simply steal them.
Kappenberger described an HPE idea for making such attacks more difficult. The company calls it stateless key management. Rather than having a vault full of keys in each device in a system, this utility lets a device dynamically generate a key on request, based on the requestor’s authenticated identity and some physical attribute of the device, such as a serial number or the value of a Physically Unclonable Function (PUF) not accessible from outside the device’s secure core.
The Padlock as a Metaphor
Standing back and looking at the whole problem of IoT security, from inexpensive, low-power Things through wireless hubs, gateways, the Internet, and the cloud, one can begin to feel very uneasy. How are we to assess the security of each link in these chains, short of implicitly trusting the claims of individual vendors? And when we put the whole system together, who assesses the safety of its users?
One possible answer lies in one word—safety. One of the most compelling presentations at the conference came not from a vendor or analyst, but from a company long associated with product safety: UL (formerly known as Underwriters’ Laboratories). UL director of innovations Maarten Bron explained that in an IoT world, there can be no safety for users without system security. And this fact places IoT security squarely inside UL’s charter.
But what would a company that pours water on toasters know about SoCs, the Internet, or data-center security? Well, one of the things the IoT needs most is a paradigm for assessing security. Ironically, Bron argued, and excellent framework already exists—in a UL security rating system from the early years of the 20th century. “One of my favorites is UL 437, the standard for key locks,” Bron declared (Figure 2). “It views the lock through three lenses: forced attack, covert entry, and key control. This same framework serves for IoT systems.”
Bron explained that UL 437—like any good security standard—included time and experience in its view of security. The forced-attack specs, for example, don’t require a lock to be invulnerable. They specify how long the lock must resist attack by a skilled person with a particular tool—a claw hammer, say, or a pair of bolt cutters. The covert section similarly specifies how long it should take an expert to pick the lock.
The three lenses of UL 437 align nicely with the three critical security attributes of IoT systems: physical properties, logical properties, and use procedures. Physical properties might include the resistance of ICs to physical disassembly or side-channel attacks, or the resistance of a WiFi hub to disassembly and reprogramming. Logic properties might include the strength of authentication and encryption, or the resistance of code to a stack-overflow attack.
Use procedures are particularly interesting, and particularly neglected in most security analyses. How easy is it, for example, to steal root keys from a vendor—either by bribing an employee or by hacking their systems—or to intercept a user’s password, or to spoof a client? Bron described one exploit in which criminals captured passwords by putting pressure sensors under the little keypads at point-of-sale terminals where customers had to punch in their PIN digits. Often the greatest vulnerabilities lie in human activities or in seemingly harmless side transactions.
Taking this broad view, UL is preparing to release a new standard: UL 2900 Cyber Assurance. As a comprehensive assessment of IoT system security it is certain to trigger controversy—not least, about who should do the assessment. Bron hinted that rather than letting vendors self-assess, UL might turn to social-media-oriented ideas like star ratings and even crowdsourced evaluations of system security, as well as bounties for successful hacks.
But whatever the impact of UL 2900, it is increasingly clear that without a far more serious, end-to-end analysis of security, IoT systems cannot be safe. The industry has to be trying harder than its attackers. Yet without safety—both physical safety from harm and safety for private data—the IoT is likely to go nowhere.