Is this page helpful?

Trusted Application and Client Application Development#

This section gives a brief overview of the OP-TEE Trusted Application and Client Application (TA/CA) architecture.

The OP-TEE TA/CA is a client-server model that follows the GlobalPlatform TEE API. The Client Application uses the TEE Client API to invoke the Trusted Application service in the secure world. The Trusted Application implements the service using functions defined by TEE Internal Core API Specification.

This diagram shows a simplified working model of the OP-TEE TA/CA and the APIs that the TAs must implement to support the model.

Brief working model of TA/CA with GlobalPlatform TEE API

Note

The Jetson Orin series doesn’t have S-EL2 support, so Hafnium (S-EL2) in the preceding diagram applies only to the Jetson AGX Thor series.

Shared memory is a memory block that the OP-TEE framework uses internally to communicate data between CAs in the non-secure world and TAs in the secure world. For a working example, refer to the hello_world sample application in GitHub.

Cross-Compiling a Trusted Application#

  1. Download the appropriate Jetson Linux toolchain from the Jetson Linux Archive page.

  2. Create a folder and extract the toolchain in this folder:

    mkdir jetson-toolchain
cd jetson-toolchain
tar xf <toolchain package>

  3. Download the appropriate Jetson Linux BSP source package from the Jetson Linux Archive page.

  4. Create a folder, extract the BSP source package in this folder, and extract the nvidia-jetson-optee-source.tbz2 file.

    mkdir jetson-public-srcs
cd jetson-public-srcs
tar xf <public_sources.tbz2>
cd Linux_for_Tegra/source
mkdir jetson-optee-srcs
cd jetson-optee-srcs
tar xf ../nvidia-jetson-optee-source.tbz2

  5. To build the OP-TEE components (including the OP-TEE image, optee_client, and optee_test files), complete the steps in the atf_and_optee_README.txt file. This file is a part of the nvidia-jetson-optee-source.tbz2 file.

    Note

    You need to build the Jetson OP-TEE source package because the user CA and TA building requires the optee_client and optee_os header files and configurations.

  6. Run the following command to build your trusted application.

    make -C <source directory> \
     CROSS_COMPILE="<jetson-toolchain-prefix>" \
     TA_DEV_KIT_DIR="<jetson-optee-srcs>/optee/build/<version>/export-ta_arm64/" \
     OPTEE_CLIENT_EXPORT="<jetson-optee-srcs>/optee/install/<version>/usr" \
     TEEC_EXPORT="<jetson-optee-srcs>/optee/install/<version>/usr" \
     -j"$(nproc)"

Replace the placeholders as follows:

  • <jetson-toolchain-prefix> is the cross-compiling toolchain:

    • For the Jetson Orin and Jetson Thor series, the toolchain is <toolchain root directory>/x-tools/aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-.

  • <version> is the version of the Jetson SoC:

    • For the Jetson Orin series, the version is t234.

    • For the Jetson Thor series, the version is t264.

  1. Copy the CA to the /usr/sbin directory of your Jetson device.

  2. Copy the TA to the /lib/optee_armtz directory of your Jetson device.

  3. You can now run the CA. When the CA requests services from the TA, OP-TEE automatically loads the TA from /lib/optee_armtz.

Implementing or Porting a Trusted Application#

Every TA must conform to a structure determined by the TA/CA model, and when you design a new TA, it must conform too. See the Trusted Applications section of the OP-TEE official documentation for a detailed description with a hello_world example. This section explains useful concepts and shows you how to create and set up a TA step by step from the beginning of the process through TA signing and encryption.

To port an existing TA from another TOS to OP-TEE, you must replace the application’s original API calls with calls to the GlobalPlatform TEE internal core API. For details, see the TEE Internal Core API section of the GlobalPlatform API OP-TEE documentation.

You can use two groups of cryptographic functions. The GlobalPlatform TEE Internal Core API provides procedures for using the cryptographic functions that are provided by optee_os. Alternatively, you can use the MbedTLS library, which is bundled with optee_os. If the original TA already uses one of these groups of functions, no conversion is needed.

Types of Trusted Applications#

The two types of TAs are user mode TAs and pseudo TAs (PTAs). For a more detailed description, refer to the Trusted Applications section in the “Architecture” chapter of the OP-TEE official documentation. Jetson Linux provides secure sample apps for both types.

A user mode TA runs as a secure application at the ARMv8 S-EL0 exception level, which is the user-space layer of the secure world. It gets OS services exclusively by calling the GlobalPlatform TEE Internal Core API. When you implement a new TA or port an existing TA from another TEE, it is of this type.

A pseudo TA runs at the ARMv8 S-EL1 exception level, which is the OS layer of the secure world. Running in this layer, a pseudo TA cannot use the GlobalPlatform TEE Internal Core API. If you need a specific secure function that the API does not provide, you can implement it in a pseudo TA and export it as a function to user mode TAs. For example, you can implement pseudo TAs to provide user mode TAs with access to hardware drivers.

Signing of Trusted Applications#

All REE Filesystem Trusted Applications need to be signed. The signature is verified by optee_os upon loading of the TA. For more details, refer to the OP-TEE documentation about Signing of TAs.

Subkeys#

Subkeys is an implementation specific to OP-TEE that provides a public key hierarchy. Subkeys can be delegated to allow various actors to sign different TAs without sharing a private key.

For more details, refer to the OP-TEE documentation about Subkeys.

Note

In production design, all TAs must be protected by signatures generated with a proper private key. We strongly recommended that you use the OP-TEE subkeys to design a key hierarchy that protects each TA and prevents unsigned or improperly signed TAs from running.