Balancing cost vs. security for embedded design

Bernard Cole
(09/05/2005 10:00 AM EDT)

In mainstream computing, it has been accepted that ubiquitous connectivity comes at the cost of constant vigilance and continued investment in security. But users and developers of the embedded microcontrollers that populate industrial, building and home environments are only now buying into the idea that security is a necessary long-term cost of doing business, with benefits that offset the expense of development, installation and long-term maintenance.

What is changing minds is wireless connectivity, in the form of specifications such as ZigBee and a variety of wireless-LAN implementations. "The extraordinary cost reductions and flexibility that wireless brings to many MCU-based applications" is convincing embedded-microcontroller developers that there is enough benefit to offset both the initial and continuing costs of security technology, said Mukesh Lula, president of TeamF1 Inc. in Fremont, Calif.

"Beyond the huge cost savings incurred by eliminating wires are the continuing costs in maintenance that will be eliminated," Lula said. That gives added flexibility to "the manufacturer who wants to reorganize the factory floor, add new systems and eliminate others. Having no wires to connect and disconnect will make the factory floor a much more dynamic environment." But wireless will also make the embedded-control environment a much leakier one, leaving telltale RF signals that make networks more susceptible to snooping, hacking and sabotage.

According to Jacko Wilbrink, ARM-based MCU marketing manager at Atmel Corp. (San Jose, Calif.), such vulnerabilities quickly became apparent to providers and users of the supervisory control and data acquisition network systems used in many manufacturing facilities, power plants, chemical and fuel distribution centers.

"In facilities the government has determined are important to the maintenance of infrastructure services, companies have tread very lightly when it comes to wirelessly connected controllers, placing strict controls and geographical and perimeter protection procedures and protocols on their use," Wilbrink said.

As manufacturing and building automation systems become roboticized and sensorized, the ability to connect to MCU-controlled equipment and gather information will be a compelling argument for integrating such gear into security frameworks. "Once a ZigBee- or Wi-Fi-connected network of sensors in a plant is connected to the enterprise for the purpose of information collection, security issues become more likely," said Rich Swindlehurst, manager of the Security Technology Center at Freescale Semiconductor Inc. (Austin, Texas). "Industrial espionage still occurs, and breaking into such connected enterprises to extract information has considerable benefit."

Among systems vendors, OEMs and VARs, the focus is on the positive aspects of wireless networks; little effort has been made to sell security. But "there are a lot of security and privacy issues even in the home environment," said Lula of TeamF1. "With a wired system, unless someone actually has access to the wires and physical nodes, security breaches are unlikely. But with wireless you are naked to the world. Anyone driving by with the right equipment can listen in on everything."

"The big question is how quickly the embedded designers will implement all the security that is necessary in such a connected and naked environment," said Fani Duvenbarge, rfPIC product manager at Microchip Corp. (Tempe, Ariz.). "As serious as the potential security problems could be, MCU application developers are extraordinarily cost-sensitive, power-sensitive and under severe constraints to service the real-time and deterministic requirements of their designs."

Aware that security will quickly move to the top of the agenda among developers and end users as wireless connectivity becomes ubiquitous, most major providers of MCU silicon are actively involved in industry groups, such as ZigBee and the Trusted Computing Group, to implement the appropriate security standards.

Meanwhile, MCU vendors such as Atmel, Freescale, Microchip Technology, STMicroelectronics and Texas Instruments are providing software, tool support and, in some cases, specialized silicon with a wide range of encryption protocols built in, but the emphasis varies from vendor to vendor.

Texas Instruments Inc. is focusing on supplying general-purpose engines that are low-cost and have the peripheral features designers need to accomplish the needed tasks, said MCU product manager Juan Alvarez. "I think the security needs of the markets that MCUs are used in are so diverse that it often does not make much sense to implement such protocols into the hardware at this point," Alvarez said. "Our job is to meet the requirements of the market in terms of cost, power and performance first and security second."

Microchip Technology Inc., similarly, has kept the focus primarily on general-purpose and application-specific 16- and 20 bit controllers, supporting them with a range of application notes, software tools and sample code that allow developers to add the degree of security that an application requires and that the market will bear.

Freescale Semiconductor Inc. has an underlying platform-independent security architecture that it makes available to its internal customers in the form of software, tools and silicon solutions, said Swindlehurst. "Our charter internally is to develop a range of security and encryption algorithms that we see will be needed as the whole range of computing devices and systems becomes more connected: software, hardware, intellectual-property blocks, tools and architectures. We work with internal customers to develop products with the appropriate level of security," based on cost, performance and the customer's perception of what's needed.

Committed to being a primary ZigBee- and WLAN-enabled MCU vendor, Atmel uses a layered approach for its 8/16- and 32- bit controllers, said Tim Warren, director of business development. The company provides tools that let designers develop software they can use in existing products; provides the appropriate C and assembly language libraries to support them; modifies existing products in the form of hardware DES, AES and RSA encryption coprocesssors added to next-generation controllers; and modifies its existing architectures so that MCUs have sufficient bandwidth to handle both the networking and security responsibilities, as well as their real-time and deterministic control functions.

Most current MCU security solutions are adaptations of standards, architectures and methods found useful in mobile platforms, desktops, laptops and servers, said Mitch Blaser, product manager at security specialist Certicom Corp. These include symmetric algorithms (such as DES, AES and double DES), for encrypting messages between devices for which there is an already established degree of trust, and asymmetric algorithms (such as RSA and elliptic-curve digital signatures), for use in applications where it is necessary to have some mechanism for validating identity and trustworthiness.

"[We start] with standards and algorithms that have worked in other segments of computing and communications and apply them where appropriate in the embedded space," said Swindlehurst of Freescale. "With few exceptions, standards and specifications developed for a much different computing space are working well so far in the deeply embedded environment where MCUs operate."

Wanted: systems approach
But Eric Uner, who works on security issues related to mobile and embedded devices at Motorola Laboratories, is concerned that there is far too much focus on encryption algorithms and not enough on developing a systems-oriented approach to device-level security. "More than other segments of connected computing, embedded MCUs and the sensors and control elements to which they are linked are sensitive to security attacks that do not require trustedness or access to information that has been encrypted," he said.

Uner said he does not rule out the possibility of denial-of-service attacks that would "overwhelm local controllers tied to sensors with spurious input data. And in a wirelessly connected MCU environment, there are at least half a dozen ways to overwhelm a network of MCUs and prevent them not only from communicating but from doing their control functions as well."

In a wireless environment, an intruder need no longer fool a system into authorizing access or break open an encrypted packet to extract useful information. "If you know that a manufacturing facility builds particular items and you want to know when and how much is being produced and on what schedule," said Uner, "you just have to watch the network activity — when it peaks, when it doesn't, where it is occurring — and you have information a competitor would find useful."

Thus embedded developers using MCUs must fundamentally rethink embedded security in three areas, Uner said: the algorithms used to provide security, the proper framework within which to think about the problem and the most appropriate MCU hardware and software.

That is occurring at some companies. For its most recent ARM-based MCU design, said Atmel's Warren, engineers discovered that with ZigBee, "doing symmetric DES and AES encryption in software often requires more than 90 percent of an MCU's resources. . . . That has forced us to rethink the way data is moved to and from on-chip peripherals and memory."