Understanding hardware security

- [Narrator] Many modern microcontrollers include an area of the chip dedicated to secure processing. In the case of the ARM architecture, this is called the TrustZone, and is intended to be used by device manufacturers to provide hardware backed security capabilities. While some early implementations dedicated a physical process to the security processing, this is no longer necessary. Now each physical processor core in the microcontroller provides two virtual cores, a non-secure and a secure core, and a mechanism to contact switch between them.

The security state is encoded on the system bus as a 33rd bit, and this enables integration of the virtual processors into the overall system security so that the non-secure virtual processor can only access non-secure system resources, but the secure virtual processor can see all resources. The emerging standard for secure development components of embedded systems such as mobile phones and IoT devices, is the GlobalPlatform Trusted Execution Environment standard.

This standard has been developed to provide a common interface specification for the use of hardware security capabilities such as the ARM TrustZone technology. We can look at the TEE from two perspectives. The first is that of the standard application environment which interfaces into the TEE to access hardware services. The second perspective is from inside the TEE in which special services run to service requests from outside. The standard application environment is known as the rich execeution environment, or REE, and it's this environment which enables user applications to run under the control of the mobile device's operating system.

The Trusted Execution Environment, or TEE, is an additional firmware component of the device. This provides an architectural and interface standard by which hardware capabilities, such as ARM's TrustZone, are leveraged to enable a device's operating system to take advantage of the chip's hardware security capabilities in their apps. In simple terms, the Trusted Execution Environment exists as a separate space within the device, running alongside the standard rich execution environment.

It has its own set of Trusted Applications, or TAs, which manage secure areas of the hardware and provide trusted processing. Using the TEE is transparent for a client app. When a client app wants to gain access to secure data or a secure process, it will make a call to an operating system routine. If there's no hardware security trustzone available, an Android system routine will handle the request. If there is a trustzone available, the system routine will make an API call to the TEE to a strictly controlled interface.

Data can be passed between the two environments using shared memory, which because it's exposed on the REE side, is not considered by TAs to be trusted. Building Trusted Applications to run inside the TEE is currently limited to vendors, and these are installed into the chip at manufacturing time. The TEE Internal Core API is used by trusted applications to gain access to resources provided by the trusted core including its interface with the hardware. This is five sections: Core functions such as scheduling, communications, memory management and so on, cryptographic functions, the maths function to support cryptography, secure data stores, and trusted time functions.

There are other APIs in the Trusted Execution Environment which can be used. A trusted application can call the TEE Sockets API to interact directly and securely as a client with other network nodes. The TEE Debug API is used to support deployment and compliance testing, and includes postmortem reporting and log message functions. The TEE Secure Element API is used to connect to secured elements built into the hardware as well as secure connected devices such as SmartGuards.

There's also a TEE Trusted User Interface, which is used for touchpad, screen, and other interactions directly with the user. This is used when the TEE needs to have information such as identifying secrets, which it can trust to have not been interfered with. The TEE must have an immutable ROM code, which is factory built, and which provides trusted boot of the TEE firmware through to booting the trusted runtime code and applications. The term immutable means that the code cannot be changed, and so can be trusted for the life of the device.

After the TEE has booted, the REE will boot. Depending upon the manufacturer, the TEE may validate the integrity of the reboot.