🚧 Documentation is under development

The RidgeRun Platform Security Manual guide is currently under active development. Some sections may be incomplete or change without notice.

Questions? Contact RidgeRun or email to support@ridgerun.com.

RidgeRun Platform Security Manual from RidgeRun

Contents Pin

Trusted Execution Environment (TEE)

A Trusted Execution Environment (TEE) is a separate, hardware-protected environment for security-sensitive operations. On supported NVIDIA Jetson platforms, OP-TEE provides the trusted operating system that runs in the secure world, while Linux runs in the normal world.

The TEE allows Linux applications to request protected services without giving Linux direct control over the secrets, trusted state, or secure-world code that performs those operations. This is useful for features involving device identity, key handling, secure storage, disk-encryption support, firmware TPM services, and other security-sensitive workflows.

This page focuses on the OP-TEE architecture used by NVIDIA Jetson Linux, the secure-world and normal-world boundary, Trusted Applications, secure storage, and the communication model between Linux and OP-TEE.

Secure World and Normal World

Arm TrustZone separates the system into two execution environments:

Environment	Also Called	Typical Components	Trust Model
Secure world	Trusted execution environment	OP-TEE OS, Trusted Applications, secure services	Used for protected operations and trusted state.
Normal world	Non-secure environment	Linux, Linux applications, kernel drivers, filesystems, tee-supplicant	Not trusted by OP-TEE. Inputs from this side must be validated.

Linux can request a service from the secure world, but the request does not make Linux trusted. Linux root processes, Client Applications, tee-supplicant, normal-world filesystems, and shared-memory inputs remain outside the trusted execution boundary.

A Trusted Application must treat command IDs, sizes, pointers, buffers, and data provided by Linux as untrusted input.

OP-TEE on Jetson Platforms

In Jetson Linux, OP-TEE is the trusted operating system used to provide TEE services. OP-TEE runs in the secure world and provides the execution environment for Trusted Applications.

The Jetson bootloader allocates a dedicated TZ-DRAM carveout for OP-TEE or another secure OS. This reserved memory is separate from ordinary Linux memory allocation and is used by the secure-world runtime.

The main layers involved in the OP-TEE path are:

Linux Client Application in the normal world;
GlobalPlatform TEE Client API;
libteec.so;
OP-TEE Linux kernel driver;
Arm Trusted Firmware based secure monitor;
OP-TEE OS;
Trusted Application.

On Jetson Orin, the request path continues from the secure monitor to OP-TEE OS. On Jetson AGX Thor, the request path passes through Hafnium at S-EL2 before reaching OP-TEE OS.

Secure Monitor

The secure monitor is the transition layer between the normal world and the secure world. On Jetson Linux, the monitor implementation is based on Arm Trusted Firmware and provides the S-EL3 transition between security states.

At the Arm architecture level, a Secure Monitor Call (SMC) is the low-level instruction mechanism used to enter the secure monitor. However, Linux applications do not call SMCs directly as their OP-TEE interface. Applications use the GlobalPlatform TEE Client API, and the lower software layers carry the request across the secure-world boundary.

The secure monitor is not OP-TEE OS and is not the Trusted Application. It provides the protected transition into the secure-world path.

Trusted Applications and Client Applications

A Trusted Application (TA) is a secure-world program that provides a protected service. A Client Application (CA) is the Linux-side program that requests that service.

Their interaction follows the GlobalPlatform TEE model:

the CA runs in normal-world Linux;
the TA implements the protected service in the secure world;
the CA uses the TEE Client API to open a session and invoke commands;
the TA uses the TEE Internal Core API to request OP-TEE services.

A TA should be small and focused on the security-sensitive part of the feature. Normal-world code can handle orchestration, user interaction, storage workflow, and kernel integration, while the TA performs the protected operation.

User-Mode TAs and PTAs

OP-TEE distinguishes between user-mode Trusted Applications and Pseudo Trusted Applications (PTAs).

NVIDIA documentation describes:

user-mode TAs as S-EL0 components;
PTAs as S-EL1 components.

Because PTAs have more privilege, a user-mode TA should be preferred unless the required functionality genuinely needs PTA-level access.

A useful design pattern is split responsibility. For example, a normal-world component can manage a disk-encryption workflow, while a TA performs protected passphrase or key operations and, when required, calls a PTA for EKB-backed services.

TA Signing

TA signing is part of the OP-TEE trust boundary. REE filesystem TAs must be signed, and OP-TEE verifies each signature when it loads a TA.

OP-TEE subkeys provide a delegated public-key hierarchy, allowing different authorities to sign different classes of TAs without sharing a single private signing key.

For production systems:

replace development TA keys with controlled production key material;
define which authority may sign each TA class;
verify that every deployed TA is signed by an authorized key;
treat TA replacement as a security-sensitive software update.

Linux-to-TA Request Flow

Communication between Linux and a Trusted Application is layered. It is not a direct Linux-to-TA function call.

A typical request flow is:

A Linux Client Application calls the GlobalPlatform TEE Client API.
The request passes through libteec.so.
The OP-TEE Linux kernel driver receives the request.
The secure monitor performs the world transition.
The platform-specific path reaches OP-TEE OS.
OP-TEE dispatches the command to the selected Trusted Application.
The response returns through the same path in reverse.

The flow can be summarized as:

Linux Client Application
        |
        v
GlobalPlatform TEE Client API
        |
        v
libteec.so
        |
        v
OP-TEE Linux Kernel Driver
        |
        v
ATF-based Secure Monitor
        |
        +-- Orin ------------> OP-TEE OS
        |
        +-- Thor --> Hafnium -> OP-TEE OS
                              |
                              v
                     Trusted Application

A TA does not initiate arbitrary contact with Linux. The normal-world Client Application initiates the session and command.

Shared Memory

Shared memory is used by the OP-TEE framework to exchange data between a normal-world Client Application and a secure-world Trusted Application. It is a transport mechanism, not secure-world storage.

When designing a CA/TA interface:

pass only the parameters required by the command;
define the size and direction of every value and memory reference;
validate lengths, command identifiers, and buffer contents inside the TA;
do not assume that a buffer supplied by Linux is trusted because the request reached OP-TEE.

The TA must validate normal-world input before using it.

tee-supplicant

tee-supplicant is a normal-world user-space daemon that supports auxiliary OP-TEE features. NVIDIA documents it as providing filesystem access so OP-TEE can load TAs from the normal-world filesystem. OP-TEE can also use normal-world support for REE filesystem secure-storage backing and RPMB-related operations.

tee-supplicant is part of the normal-world dependency surface. It must not be treated as part of the trusted execution boundary.

This distinction is important:

the normal-world filesystem may hold a TA file or secure-storage backing files;
OP-TEE remains responsible for trusted verification and secure-storage operations.

If backing files are missing or tee-supplicant is stopped, an OP-TEE operation may become unavailable, but that dependency remains outside the trusted boundary.

Secure Storage

OP-TEE Secure Storage protects general-purpose data and key material managed by OP-TEE. NVIDIA documents confidentiality, integrity, and atomicity for storage-modifying operations: an operation either completes successfully or no write is performed.

The backing resource does not change the trust model:

with REE FS, Linux provides the filesystem location, while OP-TEE protects the stored objects;
with RPMB, the storage device provides a replay-protected storage area used by OP-TEE.

The OP-TEE secure-storage model commonly uses:

Secure Storage Key (SSK), generated per device and held in secure memory while OP-TEE runs;
TA Storage Key (TSK), derived from the SSK;
File Encryption Key (FEK), used for file-level protection.

The SSK depends on a Hardware Unique Key (HUK). HUK derivation is platform-specific and must be validated against the selected Jetson Linux release and target platform.

Compatibility warning: HUK derivation is part of the persistent Secure Storage compatibility boundary. Changing derivation algorithms, labels, context values, fixed vectors, or related parameters can make existing secure-storage data unreadable.

Linux should request secure-storage operations through a TA or the relevant OP-TEE interface. Linux should not receive or persist the raw root key used to derive secure-storage keys.

Secure Storage and Disk Encryption

OP-TEE Secure Storage and disk encryption protect different assets.

Feature	What It Protects	Boundary
OP-TEE Secure Storage	Objects managed by OP-TEE.	Secure-world service with normal-world backing where applicable.
Disk encryption	A disk or partition, such as a LUKS-encrypted root filesystem.	Normal-world storage workflow with security-sensitive operations delegated to a TA.

In Jetson Linux, the disk-encryption flow may use the luks-srv TA. The normal-world disk-encryption component requests the TA service, and the TA performs the protected passphrase or key operation. Linux orchestrates the storage workflow, while the security-sensitive operation executes in the secure world.

fTPM and OP-TEE

NVIDIA's firmware TPM implementation runs as an fTPM Trusted Application inside OP-TEE. This means Linux userspace can use standard TPM software layers while TPM command processing and fTPM provisioning support remain anchored in the secure world.

The fTPM use case shows how OP-TEE can provide a protected service to normal-world software:

Linux interacts with TPM software tooling in the normal world;
TPM command processing is handled by the fTPM TA in OP-TEE;
device identity, provisioning material, and TPM-managed state are protected by the fTPM security boundary.

The fTPM flow is separate from general OP-TEE Secure Storage. TPM NV storage should not be confused with OP-TEE Secure Storage.

Design Considerations

Before using OP-TEE in a production design, verify the following:

OP-TEE boots as part of the intended trusted boot chain.
Production TAs are signed by controlled production keys, not development keys.
The secure-storage backend is supported on the selected Jetson platform and storage device.
TA UUIDs, command IDs, parameter formats, and interface versions are documented.
TA code validates all Linux-provided input, including shared-memory sizes and directions.
Normal-world failures, including missing tee-supplicant support or unavailable backing files, fail safely.
Updates, rollback behavior, key rotation, and secure-storage compatibility are tested before release.
fTPM provisioning and OP-TEE storage behavior are validated against the Jetson Linux release used by the product.

Common Misconceptions

Misconception	Correction
A Linux root process is equivalent to a TA.	It is not. A root process remains in the normal world.
The secure monitor is the Trusted Application.	It is not. The secure monitor provides the protected transition layer. OP-TEE OS and the TA implement the service.
A TA can call Linux whenever it wants.	The Client Application initiates the documented request. The TA does not initiate arbitrary normal-world contact.
Shared memory is secure-world storage.	It is not. Shared memory is a transport mechanism and must be treated as untrusted input from Linux.
A development TA signing key is suitable for production.	Production TAs should be signed with controlled production keys and a defined signing hierarchy.
TPM NV storage and OP-TEE Secure Storage are the same.	They are separate mechanisms and should not be treated as interchangeable storage models.

❯

Share This Page

Send Email Using