Keeping resource-constrained devices safe isn't an easy task. Chipmakers and cryptography specialists are taking the matter of embedded security for IoT into their own hands.
What furor there has been about IoT security has mostly been couched in terms of the disasters that await us when all the "things" attack our networks because all those devices are so easily compromised and are often ideal platforms for distributed denial-of-service and other attacks. This particular theory of the apocalypse was bolstered almost entirely by reference to last fall's Mirai botnet, which centered on webcams that were pwned in large part because they were on the open internet with default administrator passwords.
If you can build your own botnet by running a scan for open Linux telnet servers, you are clearly still in the era of rookie mistakes. Throw in IoT gateways that close down port 23 and it might seem like the network is a happy place again. But beyond idiot-proofing webcams and stopping attack traffic emanating from lightbulbs and toasters, there is a fundamental security concern: How do IoT vendors stop malicious alteration of the software -- and, thus, the behavior -- of what could well be highly sensitive devices?
The microcontrollers running IoT devices need sufficient smarts to recognize rogue data or instructions before they execute. And depending on how widely the device is connected -- to a virtual LAN? To a physically isolated network? To the web? -- and on the severity of risk, that device requires on-device, embedded security that can verify software authenticity and integrity (read: from the source we think it is and unchanged by others).
Matching chip security investment to risk
The concern of embedded security for IoT is the domain of chipmakers and cryptography specialists, who are trying to come up with technology that make economic sense relative to risk.
If you can have cryptography built into your credit card, how can you not have cryptography built into something that has a radio and sits on a network? You can definitely afford it.
Steve Hannasenior principal, Infineon Technologies
Such offerings have to work under constraints of power consumption and, therefore, processing load. Batteries may seldom be replaced in such things as implanted medical devices, remote weather sensors or in-ground vibration detectors.
Software verification and authentication today largely rely on the public key infrastructure (PKI) encryption and certificate scheme. With a private key, the vendor signs his data or his executable file. Because anyone who steals a private key can sign executable code that would then be successfully verified by the electronic device, that key must remain secure. With a corresponding public key that is trusted because it is signed by a certificate authority we presumably can trust, an end device authenticates that signature against a certificate and, by extension, verifies that file's origin and integrity.
Alan Grau is president of Icon Labs, a chip software company now offering to fit this scheme within extremely resource-constrained microcontrollers. "Really foundational for security is the ability to have some sort of key storage on the device," Grau said. "If you want to provide protection of data, you have to be able to encrypt it. If you want to provide secure boot capability, you have to have storage of your keys and certificates and signatures that can't be tampered with. So, it's less about CPU processing power than it is about some of the hardware security elements."
Hardware security modules are tamper-resistant devices that can securely generate, store and use pairs of keys. A subset of hardware security modules is the Trusted Platform Module (TPM), a hardware-based root of trust that provides fundamental services such as strong identity, secure storage and integrity measurement.
Achieving embedded security for IoT with TPMs
Steve Hanna is senior principal at Infineon Technologies, which includes TPMs among its semiconductor products. As a member of the Internet Engineering Task Force's Security Area Directorate, he took part in establishing TPM standards. "You'll find TPM chips in higher-end industrial or embedded devices," he said. "And because they're standards-based, TPMs with different levels of security will work across the same APIs."
A variety of lower-cost options provide subsets of TPM capabilities in lower-risk applications, Grau said. Cryptography can be done in software or in a supporting crypto chip, or can be integrated into the system on a chip itself.
Even the security chip on a credit card, a very low-resource device (as little as 4,000 bytes of storage, for example), has some built-in hardware security and cryptography. "If you can have cryptography built into your credit card," Hanna asked, "how can you not have cryptography built into something that has a radio and sits on a network? You can definitely afford it."
Under the brand Floodgate, Icon Labs offers a toolkit to achieve embedded security for IoT, including secure boot, encrypted communication, an endpoint firewall and mutual machine-to-machine authentication based on a privately executable PKI certification authority. It also offers its own embeddable PKI client. In its own press release, Icon Labs said it enables even the smallest of IoT devices to generate keys, create certificate signing requests and retrieve signed certificates from the certificate authority.
Embedded security for IoT applications large and small
Icon Labs separates IoT devices into classes, suggesting the heft of the processor and the choice of security tools that make sense for each.
At the low end, for example, you have very small Zigbee, Bluetooth and near-field communication IoT devices often using 8- and 16-bit microcontrollers. Here are your thermostats, wearables, low-bandwidth sensors and devices. Depending on available resources, these may justify an embedded firewall or even application data encryption. At a minimum, all classes call for policy management and event reporting, with capability for management system oversight and updates.
At the high end, in the domain of diagnostic imaging machines and satellite dishes, you're dealing with multicore, 32- and 64-bit microprocessors, with the ability to run Linux or other OSes and every tool in the defense arsenal, including secure boot and intrusion detection.
Infineon's Hanna maintained that any networked device, no matter how trivial, needs some level of embedded security to prevent it from becoming an entry point or a "redoubt" for infection. "For very low-end devices, even the simplest 8-bit processor may not be able to perform any cryptography itself, but if it's paired with a security chip, the security chip can perform that crypto for it," Hanna said. "It can handle all the security protocols for it as well."
Remote-controlled updates
Hanna also pointed out that IoT devices, while verifying the integrity of their code, must still provide for periodic remote updates, because bugs will always emerge after deployment. In low-level devices, you may not need to have much in the way of cryptography, just a way to validate that the update came from the manufacturer by validating a signature. Printers, gaming consoles and TVs include this capability.
As you get into more sophisticated devices and higher stakes -- such as industrial applications and cars -- you'll find a TPM, such as Infineon's Optiga TPM. A standard device implemented on an Infineon 16-bit microcontroller, the TPM provides not only authentication and secure communication, but also the ability to update the chip itself over time with new cryptographic algorithms and features.
A complementary approach to separate hardware modules lies in separating the code that executes boot-up, perhaps core OS and security functions in its own untouchable memory space. These are called Trusted Execution Environments; chip designer Arm Ltd.'s is called TrustZone. (Arm licenses its TrustZone technology to Infineon and other integrated circuit manufacturers.) According to Hanna, higher-end devices use both TrustZone and a hardware security chip.
"TrustZone gives them a good place to run their security code, like a [Transport Layer Security] implementation, some secure communications protocol, and then the cryptography is handled on the security chip; that's where the secure keys are kept," said Hanna, who likens the embedded security chip's role to that of a safe in a house with locked doors and windows.
Examples of such chips include Arm's TrustZone CryptoCell families, which are hardware- and software- embedded security subsystems that are mounted on a system on a chip. CryptoCell modules work in tandem with processors that have TrustZone architectural extensions, but can also be used with processors that don't, such as Arm's Cortex-R. CryptoCell includes efficient hardware cryptographic engines, random number generators, root of trust and key management functions, secure boot, secure debug, lifecycle management, and policy enforcement functions.
Given a hypothetical IoT application that measures, for example, the range of motion in a railroad track switch, Hanna said that industrial TPMs would make sense in each sensor. Although he could not release pricing figures, the cost of TPMs would be easily justified when compared with the cost of manually replacing compromised sensors. It might also be justified by the risks of malfunction or network penetration, particularly if the sensors shared a network with rail signaling traffic.
'Nobody's going to make you pay ransom to keep your lightbulb on'
Now consider the much lower stakes of a smart lightbulb, which might measure ambient light or perhaps sense the number of people in the room. "Nobody's going to make you pay ransom to keep your lightbulb on," Hanna noted, but they might use it as an entry point to reach larger prey. The way to mitigate that risk, he said, is to put that bulb behind a gateway and only let the bulb talk to its own control system. "Now, we can go with a very simple security solution and simply require that the bulb and the control system mutually authenticate themselves."
For this, a lower-end embedded security chip would suffice. You might even get by with TrustZone running in the microcontroller.
Arm used to support TrustZone only on its fairly high-end A-class processors, Grau said, but it has just made it available on its new ARMv8-M, a lower-end 32-bit architecture. Chip vendors including Analog Devices, Microchip Technology, NXP Semiconductors, Nuvoton Technology, Renesas Electronics, Silicon Labs and STMicroelectronics have already announced their licensing of the design. The first chip to be produced with it, the Cortex-M33, is just one-tenth of a square millimeter; the ultra-low-power Cortex-M23, released in October 2016, is 75% smaller than that. Aimed at medical monitoring devices and package tracking tags, it may even operate on harvested energy, without batteries.
