Designing Hardware For Security

By Ed Sperling and Kevin Fogarty

Cyber criminals are beginning to target weaknesses in hardware to take control of devices, rather than using the hardware as a stepping stone to access to the software.

This shift underscores a significant increase in the sophistication of the attackers, as evidenced by the discovery of Spectre and Meltdown by Google Project Zero in 2017 (made public in January 2018). Intel, AMD, IBM and Arm have been scrambling in recent months to figure out just how much performance and power would be required to prevent these attacks.

Industry sources say that for most applications, the impact is negligable. In the cloud, however, closing up this security hole could reduce total performance by as much as 10%. That’s a significant bite because unlike most corporate datacenters, which operate at up to roughly 50% server utilization, the whole goal of cloud is to maximize efficiency through dynamic scaling of compute resources. A loss of 10% performance means additional time and cycles are required to compensate for that loss.

All of the major processor vendors have addressed these security holes, both with patches and a flood of information. Intel has written 18 separate notes on the subject. And in a recent white paper, Arm flagged cache timing side-channels as a source of “information that otherwise would not be accessible to software from processors that are performing as designed.” The company pointed out this is only possible if malware is running locally.

Fig. 1: Hardware targets and solutions. Source: Rambus

Still, the discovery of hardware-specific malware highlights a bigger problem. Chips are supposed to last for extended periods of time—in the case of automotive and industrial applications, as long as 15 years. In many cases, they also are expected to be backward-compatible with previous generations of chips. So if hardware becomes an attack vector, entirely new approaches to security will be required to maintain the integrity of systems.

It doesn’t help that the complexity in designs is skyrocketing. Continued device scaling has forced chipmakers to take extraordinary steps to maximize performance, including the addition of multiple power domains, complex routing, multiple levels of cache, and multiple on-chip accelerators. There also is a sizeable amount of extra circuitry built into chips to offset issues stemming from multiple patternin and process variation. All of that provides more openings for cyberattacks, heightening concerns about security even in places where it was considered good enough.

“The more complex something is, the more difficult it is to make secure,” said Ben Levine, senior director of product management at Rambus Security. “A modern, scalar CPU is designed for performance, not security. And the problem with hardware is it may not be something you can patch in software. You need a different approach, which is designing hardware with security in mind, not optimizing it for something else.”

Safety meets security
This has taken on new relevance in the industrial and automotive markets, where a breach can have safety repercussions. But it’s particularly difficult in both of these markets, because a lot of these systems are one-off, custom-built solutions.

“The concept of ‘proven-in-use’ to ensure reliable operation of IIoT devices will work only partially, since individual sensing, processing and actuating tasks require specific solutions,” said Roland Jancke, head of the department for design methodology at Fraunhofer EAS. “That poses ‘lot size one’ as a key challenge for design, test, and maintenance. IoT platforms are a way to overcome this issue. But still, the production volume will be orders of magnitude smaller than in consumer electronics. Therefore a systematic development process to ensure functional safety according to standards like IEC61508 is mandatory for safety-critical industrial applications. Similar standards with respect to security will have to be developed and bindingly released in the near future.”

There are different approaches being developed, in part based upon the willingness of companies to pay for solutions. That varies greatly from company to company, and from the edge to the cloud. And with no systematic way to compare one device to another from a security standpoint, charging extra for security in one device makes it much harder to compete with a lower-priced device with similar features.

The risk often rises with the volume and value of data generated by a company. “Some of the bigger companies with a lot of data are starting to think of this as the cost of doing business,” said Rajeev Rajan, vice president of IoT business solutions at HERE Technologies. “Cost also depends on the geography you’re in. Europe is imposing a lot more controls than the rest of the world, so it is an essential part of doing business there.”

The same idea applies at the edge when it involves multiple device, but added cost is still a concern for the individual devices. “We believe you need machine learning at the edge,” said Gopal Rahgavan, CEO of Eta Compute. “You have to learn on the edge, and that is unsupervised learning. But you can pick up patterns over time. You may not be able to say what the problem is, but you can at least say something is not natural or what it has been used to. That can be used very efficiently at the edge and scaled.”

So while the devices themselves may be vulnerable, security is implemented one step higher between those devices.

“Trusted communication between IoT devices of different vendors has to be ensured,” said Fraunhofer’s Jancke. “At the same time, the authentication of devices must not add too much power consumption overhead if devices are battery powered or using energy harvesting. Moreover, lifetime will be a key design parameter in the future for IIoT devices where the intended usage scenario is a critical input to verify whether reliability targets are met. All these additional requirements prevent IIoT devices from being widely used in industry today but will when solved allow a huge market very soon.”

IIoT concerns
The industrial IoT adds its own set of unique issues because the vast number of hardware platforms and operating environments used for IIoT devices makes interoperability difficult. Many of these implementations are one-off designs, often involving retrofitted systems that have been operating for decades.

“Most are built to one degree or another on Arm Cortex microcontrollers or IP, but are so heavily customized to accomplish the specific task required for the one project they were designed for that there is little resemblance or chance for interoperability among chipsets from different vendors,” said Rob Coombs, director of business development for Arm‘s IoT Device IP business. Nearly all Arm microcontroller IP includes some degree of security – or at least the wiring that would make secure boot, encryption, authentication or fully functional PKI certificate management possible. Arm IP has had a trusted execution environment and security ecosystem since 2002, for both resource-constrained microcontrollers for sensors and other low-power devices and more high-function hardware.

That doesn’t mean the same security works equally everywhere, however. For one thing, not everyone uses the security that exists in these devices, and not everyone that opts to use it will use it equally. For another, not all implementations are identical. A 2018 survey by Barr Group, an embedded-systems consultancy and training firm, pointed to a consistent failure by technology providers to develop a cohesive community or implement good security. But even with more consistent and better security, it still won’t eliminate every potential issue.

Fig. 2: Diversity of embedded systems hardware and software architectures. Source: Barr Group

“I don’t want to put too much blame on the operational technology (OT) side of the house, but networking had a very different meaning if we went back a few years in the OT environment,” said Steve Hanna, senior principal at Infineon Technologies. “Your plant really was a separate environment. It wasn’t connected to much, except maybe headquarters. And it didn’t have the same protocols or cross connections as a business net, which thanks to the IoT, it definitely has now.”

Operational technology staffs often assume no one will use networks or connections so inherently flawed as the Internet. As a result, they often do not realize the holes they’re missing by not assuming the potential for breaches, or the need for end users and technology providers to work together on ways to lock down the potential threats they just introduced.

“Security is a broad thing,” said Gerardo Pardo, CTO at Real-Time Innovations. “Someone on your team wants to monitor the oil rig with an iPad running Javascript on a Wifi network you’re not too sure about? You might as well build a high performance vehicle with steering that doesn’t work, or no transmission. Then you’re not high performance, you’re vulnerable. But sometimes you have to dig down through a few layers to find that out,” Pardo said.

Other issues
There is no shortage of information available about how to improve security. There are guidelines from the Internet Industry Consortium (IIC), NIST, IEC, ISO, Trusted Security Group, Cisco, IBM, the Dell-focused EdgeX Foundry, European Industrie 4.0, the Object Management Group and IEEE. In fact there is so much information that it’s overwhelming.

“My evaluation of security in the IIoT? Zero,” said Richard Soley, executive director of the Industrial Internet Consortium and chairman and CEO of the Object Management Group. “Nearly all implementations of the IIoT I’ve seen assume you’re going to build a wall around them and they won’t need extra security because the perimeter will keep any threats away. That’s nonsense. On the consumer Internet, 80% of breaches involve something inside the perimeter that breaks security, whether it’s malware, or a phishing call, or an insider you shouldn’t have trusted.”

But there does appear to be a limit to what people can, or are willing to absorb, when it comes to security.

“It’s not that we don’t have standards or guidelines,” said Infineon’s Hanna. “We have too many of both. What we don’t have is a way to consolidate on the best ones and get participation from security companies, for example, to help create the kind of integrated standards and support fabric that’s common in other areas.”

That’s easier said than done, particularly with IIoT one-off security implementations.

“One challenge, from a security analysis perspective, is that it’s difficult to verify that security is working as intended because the same architecture that hides security information doesn’t make it easy to verify,” said Atul Prakash, a University of Michigan professor of electrical engineering and computer science who led a team that cracked and then documented weak smart home security in 2016. Prakash wrote an information flow-control system for IoT devices and a contextual permissions app for them. He also figured out how to fool the AI steering an autonomous vehicle by putting stickers on a stop sign. “You obviously don’t want to leave the secure part exposed, but there have been concerns raised on the supply chain side of the chip business that should make us wonder if we know where every complement of chips are coming from, whether they’re running the right code, and whether the firmware has been compromised.”

How much security is necessary?
So what kind of security is best for a particular application? “When you’re deciding what to put in a chip that you might produce in the billions, a penny difference is a big deal so you have to be very careful about what you put into it – not whether to add security or whether to do it now, but how much security,” said Asaf Ashkenazi, vice president of IoT Security Products at Rambus. “But the hardware is different for every vendor. Even if you only look at the root of trust, each has a different way of doing that, different memory restrictions in the device, maybe not all the software is in there or it’s not implemented completely.”

To even get started, a security service needs three things, according to Ashkenazi:

• The ability to access and activate security embedded by the silicon vendor;
• An API or other method to allow a PaaS or other cloud service to link to and control the device;
• A database with data outlining how to handle the other two steps – covering as wide a swathe as possible of the chaotic horde of devices and chipsets making up the IoT.

The cloud service – or whatever application is providing the control, has to be able to communicate with the devices it controls, keep those devices from communicating with unauthorized devices to reduce the chance of contracting Mirai or another strain of malware, and build up a database of common behaviors to use as a template and quash any unusual activity.

“They’re very basic operations—wake up, measure something, send it to the cloud, go to sleep,” Ashnkenazi said. “You have to know what to expect so you can recognize when something is happening that’s a problem,” Ashkenazi said. “It’s not magic. It’s a lot of hard work. Without some kind of service, some companies have no way to know where their devices are or what is connected. We had a company come to us that had deployed 1,000 devices, but 3,000 had connected to the service. That’s why you need strong authentication and to know which device is connecting and that it hasn’t been compromised.”

But how much security is really required? There are no clear guidelines for this, and certainly no consistency in implementations. Microsoft’s announcement in April of Azure Sphere described a microcontroller built to its specifications by a number of development partners. On the inside is a single-core Arm Cortex-A7, a pair of Arm MCUs, an Andes core for WiFi, and another core that is part of the Pluton security functions designed by Microsoft. The chip is capable of full PKI certificate-based management and authentication, as well as direct connections to Azure using a tailored version of Linux.

Most IoT/IIoT devices run much more modest silicon, however, trending heavily toward single-core Cortex M microcontrollers that already qualify as high-functioning IoT processors even without the additional resources that would make it possible to run a higher-level operating system, said Mike Demler, senior analyst at the Linley Group. Given the right APIs and software, customers could get the same level of security using Arm’s PSA, Demler said, and the connection with Azure would be optional rather than required.

Arm’s mbed IoT Device Platform operating system supports a wider range of chips, supports the OS, gateway, device management connections and APIs to allow integration with third parties such as Centri, which announced in October its IoT Advanced Security would run on mbed. It also connects to the Google Cloud IoT Core, the Google Cloud Platform version of Microsoft’s Azure Sphere; it was announced in September, 2017, with support already in place from Arm, Intel, Marvell, NXP, Realtek, Sierra Wireless and other chip makers.

Conclusion
The idea that security needs to be architected into devices from the start makes a lot of sense. The problem is that it isn’t always possible in many applications, such as retrofitted industrial operations, or in applications where there are too many use cases, a growing level of complexity that is compounded by third-party parts and a far-flung supply chain, or where security adds to the cost or performance of a device.

But what’s also clear is that security is now a systemic problem that goes beyond just the software or firmware. The hardware is now part of the attack surface, as well, and that will make it much harder to design chips that can withstand attacks years after they are initially designed. The attackers are getting smarter, and at this point anything appears to be a possible target.

Related Stories
Imperfect Silicon, Near-Perfect Security
Physically unclonable functions (PUF) seem tailor-made for IoT security.
Tech Talk: HW Security
How to minimize the risk of hardware attacks in the shadow of Meltdown and Spectre.
Who’s Responsible For Security?
Experts at the Table, part 3: How to manage the cost of security; the value of passwords; insignificant versus real threats.
IIoT Security Threat Rising
Rising value of data and growing complexity driving sense or urgency.
Who’s Responsible For Security?
Experts at the Table, part 2: Cheap components contaminating the supply chain, the need for platforms and certifications, and the futility of trying to future-proof devices.
Tech Talk: HW Security
How to minimize the risk of hardware attacks in the shadow of Meltdown and Spectre.
How To Secure The Network Edge
The risk of breaches is growing, and so is the potential damage.