Securing the Internet of Things

By Ronald Wilson -- EDN, May 23, 2011

The interconnectedness of embedded systems-the UBM embedded.com study this year reports that over half of embedded designs included networking capability and nearly a third had wireless interfaces-has quietly opened another dimension in design requirements. Along with functionality, performance, efficiency, reliability, and cost, designers must now take security seriously. But they will not, argued one prominent cryptography expert last week. And there will be tears. Yet a hardware-based methodology is emerging that can address the challenge systematically.

"We see change coming for embedded designers," warned Cryptography Research President and Chief Scientist Paul Kocher. "In the embedded world, designers have mostly relied on the assumption that no one will disturb their systems. But hope doesn't work in a world of connected devices and malicious users."

Kocher suggested that there are several reasons for this state of denial. One is the rapid growth of the problem. When embedded devices were electromechanical, or when they contained small amounts of firmware on an isolated processor, tampering was detectable simply by inspection. "The problem today is too much computation-even experts can't always understand everything that is in there," Kocher said.

Another set of issues involves ignorance: both design teams' ignorance of the problem and the primitive state of the infrastructure that addresses embedded security. "There's a similarity to the state of medicine in the 1840s," Kocher suggested. At that time many individuals knew little of hygiene. There was no accepted and accurate theory of disease, and secrecy between compounders and practitioners meant that there was no systematic way of designing and conducting experiments or sharing results. It was an open field for snake-oil sales.

Not unsimilarly, Kocher said, today embedded designers' ignorance of security is matched by a lack of underlying theory, inconsistency of diagnosis and treatment and a veil of corporate secrecy that hinders the flow of knowledge. Once again ineffective techniques are free to thrive in the market.

Perhaps this lack of infrastructure has created an unhealthy skepticism. Kocher said that until they actually experience "a horrible breach," systems developers are generally unwilling to spend either system cost or schedule time on security. Similarly, end users are not willing to pay extra for security, even when the result of a breach may impact them directly.

The result of all these factors, Kocher said, is one huge difference between 1840s medicine and embedded security today. In the 1840s an accurate theory of germs was forming, and the giant strides of Pasteur and others were already looming on the horizon. Today in contrast, "we see exponential growth in attacks but no increase in security," Kocher lamented.

Yet there are successes. Kocher pointed to the SmartCard, for example. It costs less than a dollar, but secures many of the world's retail transactions. And the evolution of the SmartCard-with its simplicity, strong partitioning, and hardware hardening-has suggested the outline of a methodology for securing other embedded devices.

The process begins with identifying the transactions and objects that must be secured. In a SmartCard, this step is fairly obvious-the card does one thing, and it must be secure. But in a mobile platform like a tablet computer, things get more complex. The device may perform many different types of transactions-movie viewing, retail shopping, on-line banking, or applications through a corporate VPN. In each case the content owner-the movie studio, retail store, bank, or small company-may have a very different idea of adequate security. So there will be many different secure paths through the device, each with its own authentication and protection. Each may require a separate hardware implementation, Kocher said.

This notion runs rather against current architectural practice, which consolidates all security-critical code, from authentication to encryption, in a trusted zone within a CPU core. Kocher voiced several concerns about this approach. If the zone is shared, all the secure area is accessible via the least secure authentication route. "We saw this issue with the SSL [Secure Socket Layer] design, which employs a common secure zone," Kocher said. "You have to include certificates for all the entities who should have access for any purpose. So do you include a certificate for, say, the Chinese government?"

Another concern about a unified zone is the problem of physical attack: manipulating voltages or signals, optical probing, measuring timing, or measuring differential supply current to obtain keys. Is the CPU core implementation sufficiently hardened against such exploits? Whose responsibility is that? The core provider? The chip implementer? The foundry? If the core is not physically secure, everything that relies on the protected zone is vulnerable.

As an alternative, Kocher recommended keeping each owner's secure transactions in separate hardware, in physically isolated regions on an SOC or in separate chips. He offered four guidelines for the design of these compartments. Keep each compartment in the design simple enough that everyone on the security team understands what goes on inside it. Similarly, understand the operation of the compartments in the overall system exactly. Pay particular attention to boundary crossings. And be certain that no single component can bring down the security of the whole system. "Most security breaches result from human error," Kocher said. "Redundancy is how you tolerate human error."

Interestingly, Kocher emphasizes openness in the design process, not secrecy. "We make sure that understanding of what goes on inside a compartment is widespread across the team," he said. Kocher claimed that human understanding of the design, by humans who have hands-on knowledge of the exploits that break systems, is the only real tool for building security.

"There are people who do formal proofs, and there are people who understand the fistfights that break out in the trenches," Kocher said. Without making a value judgment about one style versus the other, Kocher added: "We have broken formally proven systems before."

Thus embedded designers find themselves in a difficult position. They confront the unfamiliar challenge of secure design without either training or tools for the task. The entire industry is working without an established body of theory or a developed infrastructure. And the level of threats to embedded systems, be they obvious targets like transportation systems, power grids and personal mobile devices; or be they seemingly pointless targets like automobile drive trains, machine controllers, or home appliances, is increasing exponentially. The technology is ripe for change.