TrustZone Basics



What are the factors that lend an IoT security tool its prowess?

Most would agree that IoT devices need to be secure or they can easily become a Distributed Denial of Service (DDoS) nuisance at best, or at worst, a gateway to hacking on an internal network. Many also know that an IoT product should integrate layers of security, starting with the silicon design at the component level. Other layers in the IoT chain include communication hops (i.e., device-to-edge-to-cloud), various protocol layers, users, and the application. At the end of the chain, on the edge of the network, we find the IoT devices themselves.

In general, IoT devices include a microprocessor (MPU) or microcontroller (MCU) that carries most of the application’s logic, implemented using firmware. Typical IoT devices perform tasks within the firmware. Such tasks include establishing secure communication channels, storing data, and identifying and performing authentication with other devices or a public cloud. IoT devices also protect data (at rest and in transit), authenticate users, and so forth. Technologies such as digital certificates, cryptographic tools, and keys establish the underlying security that’s needed to run services such as digital data signing and verification, Transport Layer Security/Secure Sockets Layer (TLS/SSL) and encryption or decryption.

OS-only Level Security Limitations

At the hardware level, silicon providers might implement security features in an MPU’s hardware such as a hardware crypto accelerator, a silicon-based true number generator, or offer external components such as the Trusted Platform Module (TPM) and hardware Crypto Authenticators. Open SSL tools are also commonly used in conjunction with the above technologies. Nevertheless, a large number of developers still rely on the primary operating system (OS), such as Linux, to supply baseline security. However, Linux only allows developers to segregate security assets and operations under root access. The OS-only level of security is becoming less than acceptable due to inherent risks in exposing keys and certificates, which in turn leads to compromised systems. Using hardware security technologies implemented by silicon vendors, in conjunction with tools such as OpenSSL, is a much better option. However, this approach also has limited benefits when primary security is derived from reliance on Linux user or kernel mode isolation.

Figure 1: A proven embedded security technology, Arm® TrustZone® makes possible dual-OS systems and employs hardware as well as software isolation.

It’s clear that as the line separating hardware and software blurs, developers need tools that enable easier access to store and manipulate cryptographic keys, certificates, and to perform cryptographic operations. Arm® TrustZone® is one option that adds value to the embedded security picture. TrustZone, as a mature technology, has been used to secure mobile phones, set top boxes, payment terminals, and more. TrustZone has facilitated secure transactions, maintained secure identities, and enabled Digital Rights Management (DRM), among other things. TrustZone enables a system with dual OSes; applications get both software and hardware isolation anchored in a root-of-trust and protected by secure boot techniques.

With the flip of a bit, the code can run in secure mode or non-secure mode. Peripherals, memory, memory controllers, buses, and so forth, can be configured to segregate clearly defined access to certain resources only in secure mode. Terms like “normal world” and “secure world” define a paradigm that offers a powerful tool for IoT security from the silicon on up. A Trusted Execution Environment (TEE) within this paradigm refers to the “secure world” OS and the assets that are needed to facilitate “normal world” applications when they need to execute “secure world” functions.

For example, a Linux implementation that’s running with Open SSL in the normal world can have the Open SSL engine implemented in the TEE. In this case, only the TEE (i.e., the secure world OS) can load drivers and make them accessible for various hardware security functions. Using this approach, cryptographic keys are stored in a secure world keystore. The TEE can also generate keys and certificates, but most important, all cryptographic operations are executed in the secure world. In this example, not even the Linux kernel can access isolated security features or keys. In fact, awareness of the TEE is not necessary for those end users with kernel access and rights, much less for user applications in the normal world.

Able to solve very complex requirements, the TEE can monitor the OS, applications, processes, or memory regions in the normal world. The TEE applies remediation when intrusions or malware are detected. By extending the ability to isolate critical processes from normal world OS and applications, the TEE prevents complete system compromise. When a normal world application is compromised or hacked, a critical process controlling, for example, a connected door lock, is unaffected. The hacker cannot interfere with operations whose critical components reside in the secure world. Most use cases that require strong IoT security fall into one of three categories: communication, storage, and authenticity/integrity verification. A TEE can improve security for all of these use cases.

Easing Adoption

In practical terms, the dual OS paradigm requires developers to build applications with both domains in mind, with critical portions relegated to the secure world. The TEE and TrustZone are still something of a new frontier for many developers. Thus, there are ongoing efforts to ease adoption. Mature TEE-related products and tools can help by providing Application Programming Interfaces (APIs) and software libraries that run from the normal world, abstracting completely the existence of the secure domain. In this way, application development tools can greatly reduce the complexity of the dual OS paradigm, allowing developers to do what they do best.


Adrian Buzescu is VP Product Management at Sequitur Labs, bringing to the team more than 17 years of product engineering experience within the telecom sector with companies such as Vodafone and T-Mobile.

Buzescu has a proven record of simplifying technical complexity by initiating and taking to market multiple mobile services and products—Wi-Fi Calling, Family Finder, Visual VoiceMail, Enhanced Caller ID, MMS, Network Address Book, Remote Phone Unlock, M2M eSIM etc. In his role as director of Product Development in T-Mobile he developed and managed partnerships with infrastructure, handset, SIM card and silicon OEMs driving the technical implementation of technologies such as IMS/GBA and TrustZone/TEE across the entire handset portfolio enabling new lines of business and first-in-the-industry products.

Tags: