Facing the Embedded Security Crisis

The internet of things (IoT) has just begun to take shape, with potentially billions of sensor-enabled devices forming a web of connectivity. This technological sea change has spawned a diverse collection of devices, ranging from small to large and simple to complex. Despite their differences, these devices have one thing in common: a woeful vulnerability to cyberthreats.

Recent experiences have caused developers and end users to reframe their view of the threats that confront them, casting security in a new context. In the past, many saw the object of cyberattacks as the misappropriation of personal or proprietary data. Over the past few years, however, technologists, businesses and governments have come to realize that just as dangerous are attacks against the devices themselves—are moves to seize control of systems and operate them in malicious ways.

The design of a secure architecture for an embedded system must go beyond selecting the right processor and software. By adopting a holistic approach, the designer considers all the aspects of the product’s lifecycle. In terms of security, this means protecting data when it is at rest, in use and in transit. Image courtesy of Mentor Graphics, a Siemens business.

At the same time, developers and IT staffs now recognize that they must do more than protect the network to ensure security. Time and again, hackers have penetrated or disabled perimeter defenses. The problem, however, doesn’t stop there. Today’s threats are multifaceted. A close look at cyberattacks shows that 70% of these events originate inside the perimeter. Confronted with these realities, more and more developers believe that cyber defenses must begin with the device.

But even as this realization takes root, moves to secure devices and counter security threats seem painfully slow. This isn’t because of a lack of awareness. It’s because of the great pressure to keep costs down, driven by end users’ unwillingness to foot the bill for security that they think should be part of the product.

Appreciating the Differences

Of all the components playing a key role in the development of the IoT, embedded systems rank near the top of the list. Yet when it comes to the movement to implement better security, these devices have remained in the background, relying on obscurity for defense against cyberthreats. Recent events, however, have shown that this approach will no longer work.

But before developers can incorporate security measures in their embedded designs, they must recognize that these devices are different than standard PCs. Embedded systems usually perform specialized, fixed functions; use a tailored operating system (for example, VxWorks, MQX, or a version of Linux); minimize processing and memory usage; and often operate with very limited resources.

Combined, these factors make standard PC security techniques inappropriate for the challenges confronting embedded devices. The fact is the level of security required for an embedded device often differs dramatically. This means that developers must come up with approaches and techniques tailored for embedded applications.

A Good Place to Start

The best way to develop embedded system security is to adopt a holistic approach. “Planning to incorporate security should begin right from product conception,” says Mike Borza, R&D engineer and principal solutions group at Synopsys. “I often like to say that security should be ‘baked in, not smeared on.’”

Product designers typically have a good functional definition of their product’s features and capabilities. These describe what the product should do when everything is as it should be. The goal of cybersecurity is to keep the product operating that way even when confronted by an attempt to pervert the use of the product. Therefore, a good place to begin security planning is to identify the product’s key functions and associated data. With those identified, the designer can develop a set of security objectives. The objectives, in turn, lay the groundwork for the selection of key elements of the system’s design.

“In the early stages of the system design, developers have to choose a system architecture that fulfills the security goals of that system,” says Arvind Raghuraman, staff engineer, Mentor Embedded Systems Division, a Siemens Business. “Next comes the selection of a hardware platform. Various security requirements—such as secure boot, secure management of secrets in tamper-proof secure storage, persistent separation between secure and nonsecure software contexts and cryptographic acceleration—have implications on the choice of hardware.”

Once the development team has identified the right hardware platform, it can then decide on a software architecture that effectively leverages the hardware-provided capabilities.

Enhancing Existing Designs

These practices work well for developers designing new systems, but there’s a catch. Most IoT products are not new designs. Engineers who are enhancing existing products are constrained by previous design and implementation choices. Many existing designs have hundreds, if not thousands, of potential security vulnerabilities. Therefore, understanding and addressing these is critical, but this first step is often overlooked.

“The first step to securing existing systems is to understand their vulnerabilities,” says Terry Dunlap, co-founder and CEO of ReFirm Labs. “Tools like our Centrifuge Platform, which automatically analyze firmware and provide comprehensive vulnerability reports, are a great place to start. Building in security from the ground up is great for new product designs, but fixing the gaping security holes in existing products is far more relevant for most engineers.”

The Limitations of Encryption

One of the greatest challenges of the entire design process is deciding which technologies to use and how to best implement them. There are, however, some basic security technologies that should be included in any device with the resources to support them.

Perhaps the most fundamental of these is encryption, which is simply the process of converting data into a code to prevent unauthorized access. Designers use this technology to protect the confidentiality of data carried in transmissions to another system over an insecure network like the internet.

To this end, embedded systems have traditionally used encryption-enabled communication protocols, such as TLS (transport layer security), SSH (secure shell) and IPSec (internet protocol security). Today, most embedded platforms include these protocols as standard components. Current security standards, however, require more of encryption. Today, developers use the technology to ensure secure data storage, validate code for secure boot and secure firmware updates and implement strong device identity.

Icon Labs’ Floodgate Security Framework includes a secure boot facility, which uses signed, validated code to create a cryptographically signed image to load on the device. A secure boot process integrated into the bootloader on the device validates the image. This ensures that only authenticated code signed by the OEM is allowed to run on the device. Image courtesy of Icon Labs.

There are, however, limits to what encryption can do. “In my view, these techniques are ineffective when they are viewed as silver bullet solutions without careful consideration of how they fit into the overall security posture for the device,” says Alan Grau, co-founder & CTO of Icon Labs. “For example, we have seen systems in which a secure web interface was implemented using TLS (transport layer security), but an unprotected telnet port was still enabled.”

Another common flaw involves the management of encryption keys. “All encryption depends on a secret key, and that key must remain secret for the encrypted data to remain confidential,” says Borza. “That seems obvious to anybody with even passing familiarity with encryption. But it’s not unusual for secret keys to be found written in disk files or embedded in programs, where they can be found by adversaries fairly easily.”

As a result of these issues, encryption has a role to play in securing embedded systems, but it must be viewed as one of several layers of defense.

Controlling Access

Another security building-block technology is authentication. Using this process, a system verifies a user’s identity or the origin and integrity of sensitive data before granting access to system resources.

This is one of the most important elements in the embedded system’s cyber defense. “A key component of secure communication involves validating the other party in the communication is who they claim to be,” says Grau. “Without this assurance, systems are vulnerable to spoofed identities and man-in-the-middle attacks. Certificate-based authentication provides cryptographically strong authentication and is critical to this process.”

Authentication often begins with the use of a cryptographic hash function. When a system conveys data, the hash function computes a fixed length called a “digest.” This value is unique to the data and can indicate when a change has been made to the message. It prompts the receiving system to identify the modification, as well as the source of the change. A single bit change in the data produces a different result. So a hash function provides a means of computing a unique representative of any data.

Next, the system encrypts the hash value with a private key, using an asymmetric algorithm that creates a digital signature.

The overall process looks something like this: The system transmitting the data calculates a hash value, or digest, for the data and then encrypts the hash value using the system’s private key. This message is called a digital signature. The transmitting system then sends a file containing the data and the message containing the encrypted hash. The receiving system can verify the message by computing the hash and decrypting the accompanying message. If the decrypted message matches the hash, the receiving system knows that the message came from the identified sender.

When enhancing existing products, design engineers must contend with previous design and implementation choices, which may involve numerous potential security vulnerabilities. The designer’s first step in securing the existing system is to understand the vulnerabilities. Tools like ReFirm Labs’ Centrifuge platform help with this by automatically vetting and validating firmware for vulnerabilities. Image courtesy of ReFirm Labs.

This type of authentication requires that IoT devices have sufficient resources to handle the cryptographic operations. With increased processor speeds and the availability of lower cost security co-processors, this is now possible at a much lower cost than even a few years ago.

“Digital signing infrastructure implemented using a public key-based authentication is a great tool to fulfill the authentication needs of a system,” says Raghuraman. “Hardware crypto-acceleration units provide hardware acceleration that enables software to implement hashing and the authentication of functions in an optimal fashion.”

Designers also have another option for implementing authentication, using a shared secret key that both systems know. This approach requires less computation than using public key cryptography. Therefore, it’s more efficient when large amounts of data must be authenticated.

Whatever the approach, authentication comes into play in a number of ways. For example, an embedded device may have to authenticate system firmware and associated configuration data at system boot, or applications running on embedded devices may have to authenticate and verify the origin of software and security updates delivered to the system before they can be used.

There are also use cases where the embedded device itself has to prove its origin to an infrastructure with which it is interacting. Take for example an IoT-enabled embedded device trying to interact with a back-end system. Here, the embedded device must present its credentials to the back-end system so that it can be authenticated with its identity via a registry maintained on a cloud infrastructure.

Given its effectiveness and widespread applicability, authentication represents a key element in embedded security. “Signing and authenticating messages, data files and executable files is at the heart of ensuring the data has integrity,” says Borza. “If data has integrity, it is possible to know who originated it and that it is exactly the data that was sent.”

Getting off on the Right Foot

One of the best ways of seeing encryption and authentication at work is to examine the secure boot and secure firmware update functions.

In the first case, the market offers several types of secure boot to mitigate the vulnerabilities of the boot process. A common version verifies that the boot loader has been signed with a cryptographic key authorized by a database that resides in the system’s firmware. With adequate signature verification, a secure boot can prevent the substitution and execution of altered boot code. This prevents hackers from introducing malware or security backdoors into a processor once it is initialized.

Another approach limits changeable parameters in the device as it loads. This technique attempts to prevent hackers from substituting false commands or security backdoors into the device setup.

A third technique aims to protect the boot code of the embedded system. The goal here is to prevent hackers from accessing the code to clone the system, insert malware or develop ways to disable the system.

Digitally signed boot files provide an important step toward preventing some of the most widespread boot-loading attacks. But to be clear: Even though secure boot resists some hacks, it’s still susceptible to attacks in the verification procedure if the verifying module is not integrated into the embedded processor.

Code and security updates use many of the same techniques and technologies as secure boot. Public key-based digital signing of updates provides a level of security. When implementing a software update infrastructure, however, the designer must also consider how the system will respond when the update does not go through as expected—perhaps due to a runtime error that surfaces with new firmware. In this situation, the system should be able to roll back to known working firmware.

Compartmentalization of Resources

Another security measure that leverages general access control is privilege separation. Designers implement this cybersecurity principal by assigning a task, process or user only those privileges needed to perform their assigned tasks. This ensures that a hacker that gains access to a subsystem cannot access the rest of the system. Essentially, the hacker is limited by the privileges of the subsystem they hacked.

Cypress’ PSoC 6 MCUs provide three levels of hardware-based isolation. These include an isolated execution environment for trusted applications using a dedicated Arm Cortex-M0+ core; secure-element functionality that hosts root of trust operations and system services; and isolation for each trusted application. These three levels of isolation aim to reduce the attack surface for threats. Image courtesy of Cypress Semiconductor.

Privilege separation can be implemented in one of two ways. Designers can achieve compartmentalization in software, dividing a program into parts limited to the specific privileges they require to perform a specific task. Or they can implement compartmentalization in hardware.

On the software side, most operating systems include some level of control over access rights of the processes running in the system. “Some systems, such as SELinux, allow fine-grain control over security policies,” says Grau. “Regardless of the implementation, privilege separation should be used to limit access to sensitive and security-critical data and processes. This can reduce the attack surfaces available for hackers to exploit and limit the damage should a hacker breach a device.”

Trusted Platforms

Designers can also leverage hardware to implement security. There are, in fact, a number of hardware security approaches that can be incorporated into IoT designs.

One such technique is the trusted platform module (TPM), which is essentially a security coprocessor. Recently, TPMs have taken on a number of new applications, including platform integrity verification using cryptographic hashes of component configuration states; remote attestation about the state of the system in which the TPM is installed and cryptographic key generation and management. These modules have proven to be most useful during the preboot and bootstrap phases of system operation, ensuring the hardware and low-level system software and firmware have integrity.

“In the embedded world, TPMs were traditionally seen only in specialized applications (for example, point-of-sale terminals). But as the need to secure systems becomes greater and the realization [is made] that embedded systems have traditionally done a poor job on security, we’re seeing more and more applications where a TPM is a necessary component,” says Raghuraman.

A Question of Cost

Tasks like choosing the right technologies for a product may seem daunting, but the real challenge often appears on the bottom line. “Product teams need to make cost-vs.-benefit decisions when determining which security measures are required for the embedded systems they are designing,” says Jack Ogawa, senior director of marketing for the MCU business unit at Cypress Semiconductor.

It’s at this point that some developers drop the ball by letting many security considerations fall by the wayside. Designers are often quick to dismiss security as too costly to include in their product. Today, this seems to be embedded security’s biggest hurdle.

“It’s true that there are costs associated with security, though I also consider these as being like insurance,” says Borza. “What’s the value to a business of an attack that didn’t succeed? That’s difficult to measure. But it’s easy to measure the cost of an attack that did succeed, and these costs are often high, far beyond the cost of preventing them in the first place.”

More Info

Cypress Semiconductor

Icon Labs

Mentor Embedded Systems Division, a Siemens business

ReFirm Labs

Synopsys