Securing data on connected embedded devices is a top priority among software developers and architects today. It seems with every passing week another major data breach is announced. Embedded software developers are quickly gaining the tools and technology to design safer, more secure connected devices. Developers can use ARM TrustZone technology to secure data in their designs in addition to embedded virtualization via a Type 1 Hypervisor to combine secure data, connectivity, and real-time operation through a real-time operating system (RTOS) and open source software to take full advantage of emerging multicore and heterogeneous system-on-chip (SoC) architectures.

The functionality of connected devices is rapidly increasing as is the value of the information stored on these devices, or information accessible through these devices. Most of the devices we use today are connected to at least one type of network or service. Cars are commonly connected to devices via Bluetooth or mobile data networks; portable medical devices connect to each other, to the hospital network, to the cloud, and beyond; and the smart energy grid connects the power utility to numerous consumer devices inside the home.

Protecting data on multiple fronts

When addressing how to secure an embedded connected device, it's important to first take into account the surface area vulnerable to attacks. The area of attack varies from device to device, but generally, the more sophisticated the device, the greater the area of attack. Second, it's important to understand most of the threats today target data not for the sake of data, but for the ability to manipulate the data. And third, it's critical to design and develop a device that is both robust and secure by layering various secure capabilities.

Manipulating data

An example of manipulating data might be an attack on an algorithm that affects the operation of the very system it depends on for operation, such as a banking application at an ATM terminal or the parameters that govern how a device functions within the automobile. When it comes to protecting data, developers need to be aware of the three critical stages: data at rest, data in use, and data in transit.

Data at rest is best described as when the device is powered down. Considerations in this stage include:

• Where is the bootable image stored?
• Are there anti-tampering methods used to inform the device if it's being tampered with and a means to prevent it from booting into a vulnerable state?
• Have the executables been encrypted, or could anyone who gains access remove EEPROM, dump the memory, or attempt to reverse-engineer the application?

Data at use is when a device is operating normally and data is being generated and processed. A few considerations include:

• Have obfuscation methodologies been used for sensitive data?
• Is the device executing in a validated state? Has a chain of trust been established?

Data in transit describes data entering or leaving the device. A good design should address these concerns:

• How is data being protected if it is hijacked?
• Are encryptions or tunneling protocols in place?
• Have firewalls been deployed and what are the strategies for denial-of-service attacks?

Creating layers of security

When it comes to protecting layers within your device, you might hear "defense in depth" or "layered security." Regardless of the terminology, it boils down to creating layers of security that can defend against attacks, or, at the very least, delay the attack from penetrating subsequent layers. The layered security model might include:

• Policies and procedures – rules governing access and usage of a device
• Physical – literally, a physical barrier such as a fence, guard, or locked door
• Network – securing the connectivity to the outside world
• Application – ensuring malicious applications cannot compromise the system
• Data – ensuring the integrity of data that is used or stored in the system

ARM TrustZone technology implemented in a system-on-chip (SoC) can be leveraged to address the network, application, and data aspects of the layered security model.

ARM TrustZone technology

ARM TrustZone architecture provides a solution that is able to carve out or segregate a hardware subset of the full SoC. It does this by defining processors, peripherals, memory addresses, and even areas of L2 cache to run as "secure" or "non-secure" hardware. A SoC that utilizes TrustZone technology has the ability to dynamically expose the full SoC to secure software, or to expose a subset of that SoC to normal software (Figure 1).

The normal world (non-secure world) created and enforced by TrustZone is typically a defined hardware subset of the SoC. TrustZone ensures that a non-secure processor can access only non-secure resources and receive only non-secure interrupts. For example, a normal world hardware subset might include the UART, Ethernet, and USB interface, but exclude controller area network (CAN) access. The CAN might instead be dedicated to the secure world where a separate RTOS or application runs for the sole purpose of managing CAN traffic, independent of the normal world software stack.

Unlike the hardware subset in which normal world software runs, software running within the secure world has complete access to all of the SoC hardware. Thus, from the perspective of the secure software's execution, the system looks and acts nearly identical to what would be seen on a processor that does not have TrustZone. This means that secure software has access to all resources associated with both the secure and normal worlds.

A Trusted Execution Environment (TEE) refers to a software stack running within the secure world and the communications that allow secure software to interact with normal world software. TEE software typically consists of a small microkernel and applications, and APIs that allow secure software to communicate with the larger, user-centric software (e.g., Android). One of these specifications defines a TEE offering that some might call "typical RTOS" APIs and functionality, as well as additional capabilities and APIs that are well suited to the TEE use cases.

Many of us regularly use secure world and normal world processing without realizing it. For example, online shopping typically requires a username and password. When prompted to enter this authentication information, the mobile device (Android phone, Apple iPad, etc.) will switch into secure world mode where the data is entered on a secure keyboard and securely processed before anything else is allowed to occur. The banking application may itself run entirely in the secure world, but the device can also switch out of the secure world into the normal world to access other applications such as a browser, email, or to perform other non-secure tasks.

Securing SoCs in multicore architectures

A single ARM-based core can execute normal world context or secure world context, but what happens in a SoC with multiple cores? Developers can potentially run into situations where more than one core is accessing the same secure application, which not only extends the surface of the attack, but potentially exposes the code to the nasty timing issues that are difficult to debug. To correct this, developers can configure their device as described in the Figure 2, where only one core is allowed to execute the secure world content. In this design, when an application running on any one core needs to launch a secure application, it would have to reach out to core 0, where the transition to the secure world happens. This would make multicore designs simpler and more robust.

Running one application in the normal world and hiding secure keys and algorithms in the secure world does make a lot of sense, but, unfortunately, it's not very practical. A recent trend has developed in which silicon manufacturers are shipping more of the multicore parts. In many designs, more than one operating system (OS) is used and this is where hypervisor mode and virtualization extensions in the SoC become useful. A more complete architecture can be built on top of a hypervisor that incorporates support for ARM TrustZone technology. Designers can then partition applications and peripherals between virtual machines while at the same time secure keys and proprietary algorithms inside the secure world.

Putting it all together

A design deployed on an ARM Cortex-A15 device, for example, would look like the diagram in Figure 3. In the normal world we have the hypervisor executing with two virtual machines. Two instances of Linux running virtual machines within the normal world space are set up to have kernel and drivers to execute in the kernel mode context, while user applications are mapped to the user mode. TEE and secure applications are mapped to the secure world space. There are currently many ARM-based SoC processors built around the Cortex-A15 architecture that can support this type of configuration; TI OMAP5 and Jacinto6 reference platforms are two examples.

Securing connected devices

Connected embedded devices are becoming more functionally rich not only in capabilities, but in the data they generate and transmit. As these devices blend seamlessly into our daily lives, it's incumbent upon software developers to design each new device with security as a paramount concern. Through the use of ARM's TrustZone technology, together with a Type 1 hypervisor, developers can provide a strong, robust, and secure base for SoC designs that meet the demands of our ever-expanding connected world.

Warren Kurisu is the Director of Product Management in the Mentor Graphics Embedded Systems Division.

Felix Baum is working in the Product Management team of the Mentor Graphics Embedded Systems Division.

Mentor Graphics

www.mentor.com