Securing Edge IoT devices with iWave expertise on OP-TEE for Linux/Android

This article gives an overview of Trusted Execution Environment (TEE) and how it is achieved through OP-TEE, how ARM Trust-Zone works, i.MX 8 boot flow with OP-TEE and iWave expertise on OP-TEE.

OP-TEE is a secure Operating System (OS) that provides a Trusted Execution Environment (TEE) for Android/Linux. The TEE provides a safe environment within the application processor for developing and executing secure applications. Android/Linux which runs on an application processor is called Rich OS. The OP-TEE runs on the same processor as to where Android/Linux runs but OP-TEE is isolated from the rest of the system by both hardware and software. OP-TEE has access to the full power of a device’s main processor and memory but is completely isolated. OP-TEE OS’s isolation protects it from malicious applications installed by the user and potential threats that may be discovered in Android/Linux.

The Trust-Zone is a system-on-chip security feature available on most ARM Cortex A/M processors. It provides strict hardware isolation between the secure world (TEE) and the normal world (REE/Rich Execution Environment). This technology allows each physical processor core to provide two virtual cores: one for the normal world and one for the secure world.

OP-TEE is an open-source stack of the Trusted Execution Environment. This stack supports ARM-v7 and ARM-v8 architectures. This open-source project includes:

• OP-TEE OS: Trusted side of the TEE
• OP-TEE Client: Normal world client side of the TEE
• OP-TEE Test (or x-test): OP-TEE Test Suite

The main design goals for OP-TEE are:

• Isolation – The TEE provides isolation from the non-secure OS and protects the loaded Trusted Applications (TAs) from each other using underlying hardware support.
• Small footprint – The TEE should remain small enough to reside in a reasonable amount of on-chip memory as found on ARM-based systems.
• Portability – The TEE aims at being easily pluggable to different architectures and available hardware and has to support various setups such as multiple client Operating systems or multiple TEEs.

OP-TEE Architecture:

Figure 1: OP-TEE Architecture

In a system with a TEE, untrusted applications run on a Rich Execution Environment (REE) and trusted applications (TAs) runs on a Trusted Execution Environment (TEE).
Only trusted applications running on a TEE (Secure World) have complete access to the main processor, peripherals, and memory, while hardware isolation protects these from untrusted applications running on the main operating system (Non-Secure World).

In a TEE, all trusted applications (TAs) and associated data is completely isolated from the normal (untrusted) operating system and their applications. Also, trusted applications must run in isolation from other trusted applications and from the TEE itself.

How ARM’s TrustZone works?

The hardware separates Secure World and Non-Secure world under TrustZone Technology.

Trusted software (Trusted OS) needs to be developed to make use of the protected assets/data for implementing a secure state in the System On Chip. Trusted boot, secure world switch monitor, small trusted OS and trusted apps are implemented as trusted software.

ARM’s TrustZone introduces the secure monitor mode.

Secure Monitor Call (SMC) is a dedicated instruction for the transition from the Secure World to the Non-Secure World. The CPU will enter in secure monitor mode and will have access to all hardware, including the protected peripherals and memory regions when SMC instruction is executed. The TEE Firmware/operating system can run at this time. The Trusted applications will run on a TEE in the Secure World.

As an example, consider a normal world (untrusted) application running on Linux that wants a service from a trusted application running on a TEE OS. The untrusted application will use an API which is based on Global Platform API specification to send the request to the Linux kernel (Linux TEE driver) with the help of TEE supplicant, that will use the TrustZone drivers to send the request to the TEE OS via SMC instruction, and the TEE OS will pass along the request to the trusted application.

The figure below shows the main OP-TEE embedded components, namely the OP-TEE OS, OP-TEE Client, Trusted Application on the secure side, and OP-TEE Linux kernel driver on the non-secure side.

Figure 2: OP-TEE on ARM Trust-zone enabled chipset

(Reference link Here )

Boot Flow of OP-TEE and Android/Linux on i.MX 8 (ARM V8):

The below section describes how OP-TEE boots on i.MX 8 platform along with Linux/Android.
Files and binaries required in the boot partition:

• flash.bin: Fit image containing U-Boot and the ATF along with OP-TEE.
• zImage: Kernel image
• zImage-*.dtb: Device tree

Figure 3: OP-TEE and Android/Linux Boot flow on i.MX 8

On ARM V8, ARM has a specified preferred way to boot Secure Component with the ARM Trusted Firmware (ATF). The ATF first loads the OP-TEE OS. The OP-TEE OS initializes the secure world. Then, the ATF loads U-Boot that modifies the DTB on the fly to add a specific node to load Linux TEE drivers. Then, the Linux OS is booted. The detailed software flow is explained in the below diagram:

ARMv8-A comes with ARM Trusted Firmware (ATF).
ATF runs at EL3 (Exception Level 3) and is responsible for

• Trusted Boot
• Power State Coordination Interface (PSCI)
• Secure Monitor Calls (SMC) Calling Convention

OP-TEE OS runs at Secure EL1 (S-EL1: Secure Exception Level 1) and needs to cooperate with ATF. The secure monitor-related implementation is located within ATF. A secure monitor in ATF is called a Dispatcher. The Dispatcher is responsible to act as a Secure Monitor and interface with the OP-TEE OS in the ARMv8 platform. OP-TEE Dispatcher (OP-TEED) needed to interface with OP-TEE OS.

iWave OP-TEE Expertise:

iWave is having rich experience in providing secure software solutions for embedded products.
Below diagram shows a sample of what is implemented by iWave:

• Secure booting of OP-TEE with Android/Linux
• Porting the OP-TEE OS on different platforms like i.MX 8 and i.MX 6 series SOMs
• Porting the drivers to OP-TEE and providing the API’s for accessing driver functionality
• Trusted application for testing the drivers supported in OP-TEE

Figure 4: iWave expertise in OP-TEE

iWave has experience working on OP-TEE and providing a security layer in embedded products. Following are the support provided by iWave with respect to OP-TEE:

• OP-TEE Trusted application Implementation, that is APIs for a Host application, Trusted application, and OP-TEE driver development.
• Porting the interface drivers to OP-TEE
• APIs for secure/non-secure access to different peripheral will be provided using CSU (Central Security Unit)
• Tamper Detection
• Configuring the secure/non-secure regions using TZASC which can only be accessible by OP-TEE/Normal OS
• Secure Storage:
  • REE file system secure storage
  • Reply protected memory block (RPMB) secure storage
  • Key Manager
• Signing the OP-TEE along with other Bootable binaries and verifying through HAB and maintaining the chain of Trust

iWave has provided Secure BSP using OP-TEE on i.MX 6UL platform and is the reference link Here

Summary:

OP-TEE is used as a security layer for edge IoT devices. As OP-TEE is open-source it makes deploying OP-TEE OS and Trusted application easy. iWave has experience in porting the latest OP-TEE to a different platform, porting the drivers to OP-TEE, and writing trusted applications.

Also, iWave offers a Security suite that secures connected devices, enabling them with security functions such as encryption, storage, data transmission, and certificate management. The easy to integrate solution helps address the security challenges creating a safe and secure environment. Security Suite includes secure boot, Wi-Fi security, event logging, OS hardening, access control, software firewall, and secure firmware update to name a few.

More information on the Security Suite can be found here or a quick 1-minute video can be viewed here

For further information or enquiries, you can reach us at mktg@iwavesystems.com or contact our Regional Partners.