Future Electronics — How Arm TrustZone Security Technology has Made the Transition from Mobile Phones to Small, Resource-Constrained Embedded Systems

 

By John Robins, EMEA Vertical Segment Manager (Embedded Systems), Future Electronics

Read this article to find out about:

• The security capabilities of Arm’s TrustZone technology
• How the introduction of Arm Cortex-M cores has enabled implementation of TrustZone technology on microcontrollers
• New microcontroller products which support TrustZone technology

TrustZone^® technology for Arm^® CPUs is a successful security system IP which is today used in hundreds of millions of mobile phones. Its adoption by mobile phone manufacturers has been driven by the need to provide an isolated, secure space in which the online financial transactions performed by banks and online payment systems can run. This security IP removes the risk that a user’s secure data may be obtained, allowing a hacker to make unauthorised payments or money transfers.

An online financial transaction is a complex software process, and the value at risk in internet transactions is colossal. That TrustZone technology is approved by giants of the financial world is testament to the high security that it provides to mobile devices.

But the importance of security in the mobile phone and financial ecosystems has tended to overshadow its relevance to the embedded world as well. On mobile phones, the Arm TrustZone technology is implemented in the Cortex^®-A class of larger, high-performance application processors. In the embedded world, devices are more commonly based on a microcontroller platform, which offers a far more constrained computing environment appropriate to the system’s more limited functional requirements and lower power and cost budgets.

Whether in an MCU or a processor, the TrustZone technology provides a secure platform for the execution of software in a Trusted Execution Environment (TEE). Arm has worked with the GlobalPlatform organisation to provide Application Programming Interfaces (APIs), compliance processes and certification for a TEE.

The TEE consists of three parts: hardware-based isolation technology (such as Arm TrustZone), trusted boot, and a small trusted Operating System (OS). The TEE can be used to run multiple, isolated trusted applications which may be provisioned over the air. Compared to other security technologies, a TEE provides higher performance and access to larger amounts of memory. A TEE, which may be home grown or supplied by a third party, provides the important security functions of:

• Trusted boot
• Integrity management
• Authentication
• Payment
• Content protection
• Cryptography
• Mobile device management

Now, following the introduction by Arm of its new Cortex^® M-23 and M-33 cores, microcontroller-based embedded systems can implement software securely in a TEE running on a TrustZone platform, enabling embedded system designers to emulate many of the security capabilities of today’s smartphones.
 

The role of secure software isolation in embedded systems

It is true to say that criminal hackers focus their effort on breaking systems from which they have most to gain. A mobile phone which can make withdrawals from the user’s bank account is clearly a valuable criminal target. It would be easy to assume that an embedded device has much less appeal to hackers.

But imagine a device as simple as a smart home heating thermostat, connected to the internet to provide access to cloud computing applications. A hacking attack might be executed via a spoof Over-The-Air (OTA) firmware update. The result, flashed up on the thermostat’s display screen: ‘Pay 1 Bitcoin now or your heating is permanently disabled.’ Such an attack, played out globally over a population of millions of thermostats, could yield enough to make the hacker’s investment of time and risk worthwhile.

Some embedded systems use a secure authentication device, a typical example is the A1006 from NXP Semiconductors, which provides a unique encrypted identity to protect against attacks via an OTA process. A remote update, for instance, might be required to recognise the device’s identity before the device allows the update to run. Authentication provides some ‘connection security’ and is one of the functions of TrustZone technology.

But TrustZone does more than securely verify the CPU’s identity: it provides system-wide, hardware-level isolation of functions and resources into ‘trusted’ and ‘non-trusted’ elements. As Arm says, ‘TrustZone is a System-on-Chip (SoC) and CPU system-wide approach to security, helping to isolate and protect secure hardware, software and resources. TrustZone is hardware-based security built into SoCs by semiconductor chip designers, then used by software developers.’¹

It goes on: ‘The new TrustZone for Cortex-M [MCU cores] may be used to protect firmware, peripherals and I/Os, as well as to provide isolation for secure boot, trusted update and root-of-trust implementations without compromising the deterministic real-time response expected in embedded systems. The non-secure software is blocked from accessing secure resources directly, and this isolation extends beyond the processor to encompass memory, software, bus transactions, interrupts and peripherals within an SoC.’²

This provides ‘run-time security’ on top of the partial connection security offered by a discrete authentication chip. In a system such as a wireless keypad-enabled smart door lock, for instance, TrustZone technology enables the embedded developer to implement not only the secure elements of the application software running on the CPU in trusted space: operations involving the keypad and camera I/Os can also be executed in trusted space, thus blocking any attack based on spoof keypad inputs, as shown in Figure 1.

 

Fig. 1: On the Microchip SAM L11 microcontroller, a remote keypad I/O may be configured to run in trusted space. (Image credit: Microchip)

 

The concept of hardware-separated trusted and non-trusted worlds is at the heart of the TrustZone approach. Non-trusted software is blocked from accessing trusted resources directly. Instead, access to trusted resources is via Application Programming Interfaces (APIs) provided by trusted software, as shown in Figure 2. These APIs implement authentication processes to decide whether access to the trusted service is permitted. This means that, even if there are vulnerabilities in the non-trusted applications, hackers cannot compromise the whole chip.

 

Fig. 2: APIs provided by trusted software allow non-trusted software to access trusted resources – but only if properly authenticated. (Image credit: Arm)

 

The reason that the TrustZone technology’s security is so highly rated by third parties is that it is built into the hardware architecture of the chip: the trusted and non-trusted resources are physically isolated from one another in the silicon.

Developers of embedded systems might worry that this dual architecture creates a complex environment in which to implement applications, particularly those that require real-time, deterministic responses. In fact, the physical separation of trusted and non-trusted resources in the silicon is masked in the programming environment. A system developer working with a Cortex-M33 or M23 core – the first Cortex-M cores to support TrustZone technology – will see the same programming interface in a familiar tool such as Arm’s Keil^® Integrated Development Environment (IDE) as for any other Cortex-M core. The main difference is that the IDE adds a configuration setting for the developer to dictate whether a process or resource should be allocated to trusted or non-trusted space.

The IDE will also provide a means for the developer to generate the authentication process by which a trusted-world API gives permission to non-trusted software to access trusted resources. In either the Cortex-M23 or M33, this will be backed by security keys stored in trusted memory, and by dedicated hardware, such as an encryption engine, which also run in trusted space.

To support the need for real-time operation, the TrustZone implementation in the Cortex-M processors is different from that of the Cortex-A class processors in one important respect: it uses a hardware Secure Attribution Unit (SAU) to switch almost instantaneously between the trusted and non-trusted states, in contrast to the Secure Monitor Call software instruction in A-class processors.
 

Microcontroller products with TrustZone technology

This development ecosystem can now be used in new system designs including TrustZone technology following the launch of compatible microcontroller products, including the SAM L11 from Microchip and the LPC5500 family from NXP Semiconductors.

The SAM L11 and the SAM L10, launched at the same time, are based on the Arm Cortex-M23 core: of the two Cortex-M cores which support TrustZone technology, the Cortex-M23 is 75% smaller than the Cortex-M33 core, and uses around half as much power.

NXP has based its LPC5500 MCUs on the Cortex-M33 core to provide a wider range of security features: these include SRAM Physically Unclonable Function (PUF)-based root-of-trust and provisioning, real-time execution from encrypted files, and asset protection.

As a rough guide, it is fair to say that the processing capability and the power consumption of the Cortex-M23 core are on a par with those of the popular Cortex-M0+ core. This means that users can now embed a proven hardware and software platform for high security into even very small and resource-constrained embedded systems. And they can do so without in any way compromising the real-time and deterministic characteristics of the typical embedded product.

Both the SAM L10 and SAM L11 include chip-level tamper resistance, secure boot and secure key storage. When combined with TrustZone technology, these capabilities enable the OEM to establish a hardware root-of-trust, and provide protection from both remote and physical attacks, as shown in Figure 3.

 

Fig. 3: The SAM L11 MCU’s comprehensive security features protect against various forms of attack. (Image credit: Microchip)

 

The SAM L11 MCU also embeds Trustonic’s root-of-trust during silicon manufacturing to work with Kinibi-M software, as shown in Figure 4. The Kinibi-M abstracts away the lower-level details of the SAM L11’s hardware security to provide a modular approach through a Graphical User Interface.

Partnerships with Secure Thingz and Data I/O Corporation offer secure key-provisioning services for customers that have a proven security framework. These processors are fully supported in both Arm’s Keil^® development platform and the IAR Embedded Workbench IDE.

 

Fig. 4: The security architecture of the SAM L11 MCU includes Arm’s TrustZone technology and the Kinibi-M GUI. (Image credit: Microchip)

 

No impediment to embedding security in embedded systems

Smartphones are today thought to set the gold standard in online security, because billions of users safely use them to make contactless payments at stores and in public transit systems, and to transfer money online via banking apps. Arm’s TrustZone technology embedded in the smartphone’s Arm Cortex-A-based application processor provides the hardware basis for this very high security.

Now the same hardware security technology is available in the Cortex-M33 and M23 MCU cores, enabling designers of embedded devices for the Internet of Things to provide a proven hardware basis which is secure against many kinds of online and physical attack.

 

Appendix: references

^1. From www.arm.com/solutions/security

^2. From www.arm.com/why-arm/technologies/trustzone-for-cortex-m