Fundamentals

Here we introduce the basic concepts and building blocks of the system. This includes the ARM TrustZone technology, OP-TEE, the PKCS#11 Trusted Application, FIT and partition verification and encryption.

TrustZone creates separate new execution states in the processor, where secure states can not be inspected by normal states. In conjunction with memory protection controllers such as the TrustZone Address Space Controller (TZASC), the secure state can be used to run a lightweight Trusted Execution Environment (TEE). The secure state is usually called "Secure World" and the normal state "Normal World".

OP-TEE is a BSD-3 clause licensed open source implementation of the GPD TEE specification. The TEE specification describes an API that should be used to provide cross-TEE compatibility for Trusted Applications (TAs). Trusted Applications are meant to implement the security-sensitive part of an application and, since they are executed within OP-TEE, run in the secure world.

The PKCS#11 Trusted Application implements a software HSM (in the Secure World) which is used with a shared library (in the Normal World) which implements the PKCS#11 API. Using the OpenSSL pkcs11 engine, it is also possible to use this as the secret store for certificates. This way client authentication using certificates on a TLS connection is possible, without the private key ever leaving the device.

Flattened Image Trees (FIT) are a storage format used to assemble the different pieces required for a Linux boot into a single piece of data. They also allow signing and authentication, enabling the build of a verified boot process.

To minimize influences on the operating system, the root partition of the system should be mounted in read-only mode. Using read-only mode also enables the use of dm-verity for partition verification, which calculates the checksums of each file during creation and lets the kernel ensure that none of the operating system files have been modified.

To protect data generated and saved at runtime such as persistent logs and other information, the data should be put into an encrypted partition. This is done by using dm-crypt achieving partition encryption.

Secure Boot Mechanism

To ensure a verified system, the bootloader needs to be verified during bootup. This is a vendor-specific implementation, each vendor has its own implementation and tools to sign the bootloader. For the NXP i.MX6UL system, for example, this mechanism is called High Assurance Boot (HAB).

After the introduction to the different technologies and security parts of the used stack, lets start by looking at the security overview of the system. HAB ROM code (ROM in the picture) starts in the secure world, indicated by the green background. It loads and verifies the bootloader, which contains our secure operating system, and passes execution to the bootloader. The first part of the bootloader runs in the secure world, which does the initial setup of the system and subsequently starts the secure world operating system in the form of OP-TEE. OP-TEE returns the execution back to the bootloader, which now runs in the normal world. The bootloader subsequently loads the FIT image, which contains the kernel and device tree. During bootup the kernel will verify the integrity of files on the filesystem, ensuring that none have been tampered with.

PKCS#11 HSM Trusted Application

The PKCS#11 Trusted Application provides a software Hardware Secure Module (HSM). This allows the generation and storage of trusted data within OP-TEE and enforces that the trusted data can be used to sign or encrypt, but never be extracted from OP-TEE. This effectively allows binding an identity to the device, which is guaranteed to never leave the device. This can be used to e.g. encrypt updates for a specific device or allow the device to authenticate itself cryptographically to a cloud service.

As shown in the picture above, the user application in the normal world uses the PKCS#11 API to communicate with the TA. The API is implemented by a shipped library which in turn communicates with the kernel API to send requests to OP-TEE. OP-TEE than routes these requests to the correct TA. The PKCS#11 TA was originally written by Etienne Carriere and is currently in the process of being integrated into the main OP-TEE repository.

Securing OP-TEE on i.MX6

Availability of the TA and setup of the secure boot mechanisms are steps which are mostly solved today. However, securing OP-TEE for the individual SoCs is an important step which has not been done for a lot of SoC families. The SoCs usually differ in the following points:

• Access control to the RAM or availability of SRAM
• Access permissions for components on the SoC (GPU, Audio, I2C, SPI,…)
• Generation/Availability of a per-CPU secret which can be used to derive keys for storage encryption

For i.MX6UL a lot of the work has been done by Pengutronix and is included in the latest OP-TEE 3.9 release. Due to SoC-specific constraints, real secure storage is only available if HAB is enabled. Access permissions for the SoC components should be correctly configured within the Central Security Unit (CSU) and RAM access is also enforced. The remaining problems are that the device key derivation can not be enabled by default due to concurrent access problems with the Linux kernel. Additionally, the RAM access control component needs to be enabled by the bootloader, which can not be solved by OP-TEE.

References

• Talk on securing OP-TEE on SoCs: https://fosdem.org/2020/schedule/event/optee/
• Talk on authenticated and encrypted storage: https://www.youtube.com/watch?v=z_y84v9076c
• Talk on OP-TEE for i.MX6 SoCs: https://www.youtube.com/watch?v=I9C-8FCfgaE