RidgeRun Platform Security Manual - NVIDIA Jetson

🚧 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

NVIDIA Jetson

NVIDIA Jetson platforms are designed for embedded and edge-AI systems that combine high-performance computing, GPU acceleration, camera and multimedia processing, and connectivity in a single platform. These capabilities make Jetson suitable for applications such as robotics, autonomous systems, industrial automation, intelligent cameras, medical devices, and other connected edge products.

These systems may process sensitive information, communicate with external services, control physical devices, and execute software that determines the behavior of the complete product. For this reason, securing a Jetson-based system involves more than protecting the Linux operating system. The platform must establish trust during boot, authenticate the software that is executed, protect sensitive data and cryptographic material, secure software updates, and restrict unauthorized access to the device.

This guide presents a practical path for securing NVIDIA Jetson platforms. It covers security mechanisms such as Secure Boot, Trusted Execution Environments (TEE), disk encryption, Trusted Platform Module (TPM) integration, secure OTA updates, system access restrictions, and the procedures required to bring security configurations into production.

The developer can use this guide to move from a working Jetson software image to a validated security configuration. Each security mechanism should be implemented according to the threats and security requirements of the product and validated before production enforcement.

Unlike platforms where this manual follows a single build environment, NVIDIA Jetson security can be integrated through two different development flows:

JetPack Build Process – Security configuration using NVIDIA Jetson Linux, the Linux for Tegra (L4T) BSP, and NVIDIA's flashing and signing tools.

Yocto Build Process – Security integration as part of a Yocto-based Linux distribution and its reproducible build process.

Both approaches target the security capabilities of the Jetson platform, but the configuration, build, signing, image generation, and deployment procedures differ.

The appropriate path should therefore be selected according to the Linux distribution and build system used by the product.

Security implementation paths

The security requirements of the product should remain independent of the selected build system.

For example, a product may define the following requirement:

Security requirement:
Only authorized software must execute during boot.

The mechanism used to satisfy this requirement may be Secure Boot in both cases, while the integration procedure differs depending on whether the product is built using JetPack/L4T or Yocto.

This separation allows the security architecture to remain focused on what the product must protect while the implementation procedure remains specific to the selected software stack.

JetPack Build Process

The JetPack Build Process describes how security mechanisms are configured, built, flashed, and validated using the NVIDIA Jetson Linux environment and the tools provided as part of the Linux for Tegra BSP.

This path is appropriate for products based directly on NVIDIA Jetson Linux and its standard BSP and flashing infrastructure.

The JetPack security documentation in this manual covers topics such as:

Security flow and platform trust architecture.
Secure Boot.
Trusted Execution Environment (TEE).
Disk encryption.
Over-the-Air (OTA) updates.
Trusted Platform Module (TPM).
Kiosk modes and access restrictions.
Bringing Secure Boot configurations into production.
Integration of signing infrastructure and Hardware Security Modules (HSMs).
Integration of signing workflows with CI/CD.

See NVIDIA Jetson JetPack Build Process for the detailed procedures.

Yocto Build Process

Some Jetson products use Yocto instead of the standard JetPack root filesystem and development workflow.

In these systems, security mechanisms must also be integrated into the reproducible Yocto build process.

The Yocto Build Process section describes how the security configuration participates in image generation and how the required platform mechanisms can be integrated into the product's Yocto configuration.

The Yocto security documentation in this manual covers topics such as:

Secure Boot.
Trusted Execution Environment (TEE).
Disk encryption.

Depending on the security mechanism, implementation may involve Yocto configuration, recipes, classes, signing infrastructure, image generation, and NVIDIA platform-specific tools.

See NVIDIA Jetson Yocto Build Process for the detailed procedures.

Choosing Between JetPack and Yocto

NVIDIA Jetson security features can be implemented through either the standard JetPack / Jetson Linux workflow or a Yocto-based workflow. The security objectives are the same in both cases, but the build model, artifact organization, signing integration, flashing process, and customization points are different.

For this comparison, Jetson Linux R39.2 / JetPack 7.2 is used as the main reference. Beginning with JetPack 7.2, NVIDIA officially supports Yocto on Jetson platforms and aligns this support with the OpenEmbedded for Tegra (OE4T) project.

Software Model

Topic	JetPack / Jetson Linux	Yocto
Base software model	NVIDIA-provided Jetson Linux BSP and Linux for Tegra workspace.	Metadata-driven image generation through BitBake, OpenEmbedded, and Jetson BSP layers.
Main workspace	`Linux_for_Tegra/`	Yocto build directory and layer stack.
BSP integration	Provided directly by NVIDIA Jetson Linux BSP components.	Provided primarily through OE4T `meta-tegra`.
Root filesystem	Prepared inside the BSP workspace and modified as needed.	Generated from recipes, package selections, image configuration, and distribution metadata.
Typical customization	BSP files, rootfs contents, NVIDIA flashing configuration, signing options.	Layers, recipes, classes, machine configuration, distro configuration, image recipes.

In the JetPack workflow, development normally starts from NVIDIA-provided BSP components and binary artifacts. A typical BSP workspace is organized around:

Linux_for_Tegra/
├── bootloader/
├── kernel/
├── rootfs/
└── nv_tegra/

In the Yocto workflow, the target image is described before it is built. A simplified layer model is:

Product-specific layer
        |
        v
meta-tegra-community       Optional
        |
        v
meta-tegra
        |
        v
meta-openembedded
        |
        v
OpenEmbedded Core / BitBake

Build Workflow

Topic	JetPack / Jetson Linux	Yocto
Target selection	Usually selected when invoking NVIDIA flashing tools.	Selected before the build through `MACHINE` and Yocto configuration.
Build process	Uses prepared BSP files, rootfs content, and NVIDIA tools.	BitBake resolves recipes, layers, machine configuration, dependencies, and image contents.
Example command	`sudo ./flash.sh <board> <rootdev>`	`. ./setup-env --machine jetson-orin-nano-devkit-nvme`
Image generation	Based on the prepared Linux for Tegra workspace.	Generated reproducibly from metadata and source/layer revisions.

In JetPack / Jetson Linux, the BSP workspace remains an important part of both image preparation and deployment. The target configuration is selected through commands such as:

sudo ./flash.sh <board> <rootdev>

or through the initrd-based flashing flow:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh <options> <board> <rootdev>

In Yocto, platform selection normally happens earlier in the workflow. For example:

. ./setup-env --machine jetson-orin-nano-devkit-nvme

A simplified Yocto flow is:

Select MACHINE
      |
      v
Select DISTRO and image recipe
      |
      v
BitBake resolves recipes and dependencies
      |
      v
Build root filesystem and BSP components
      |
      v
Generate deploy artifacts
      |
      v
Generate Jetson flashing package

Build Artifacts

Both workflows must produce the platform components required to boot the Jetson, but they organize those artifacts differently.

Workflow	Artifact Organization
JetPack / Jetson Linux	The `Linux_for_Tegra` directory acts as the BSP workspace containing bootloader, kernel, rootfs, NVIDIA platform content, flashing tools, and partition configuration.
Yocto / `meta-tegra`	BitBake generates machine-specific deploy artifacts and can package the required flashing content as part of the build output.

Important JetPack BSP directories include:

Directory	Role
`bootloader`	Bootloader binaries, Tegra flashing tools, partition configuration, and related boot components.
`kernel`	Linux kernel and related kernel content.
`rootfs`	Target root filesystem.
`nv_tegra`	NVIDIA platform and userspace content used by the BSP.

In Yocto, generated output is stored under the BitBake deployment directory for the selected machine. One important meta-tegra output is the Tegra flashing archive:

<image>-<machine>.tegraflash-tar.zst

This archive packages the machine-specific content required by the OE4T flashing flow.

Security Integration Differences

Security Task	JetPack / Jetson Linux	Yocto
Secure Boot signing	Integrated through NVIDIA Jetson Linux signing and flashing tools.	Integrated through Yocto variables, classes, and `meta-tegra` signing support.
UEFI Secure Boot	Configured through NVIDIA tooling and UEFI key configuration files.	Can be integrated into the image build and deploy artifacts through the Yocto workflow.
Disk encryption	Configured through Jetson Linux security procedures and flashing flow.	Integrated into the Yocto image, initramfs, storage layout, and related recipes.
OTA	Implemented through Jetson-compatible OTA tooling and update framework configuration.	Integrated with Yocto image generation, update artifacts, and release metadata.
Production signing	Often added around the NVIDIA flashing/signing workflow.	Can be integrated with CI/CD, signing services, and Yocto artifact generation.

The security mechanism does not change only because the build system changes. Secure Boot, disk encryption, TEE, TPM, and OTA still protect the same platform assets. What changes is where the configuration lives and how it becomes part of the product release process.

When to Use Each Path

Use JetPack / Jetson Linux when...	Use Yocto when...
The product is based directly on NVIDIA Jetson Linux.	The product already uses a Yocto-based Linux distribution.
The team wants to stay close to NVIDIA's standard BSP and flashing workflow.	The team needs reproducible image generation from layers, recipes, and metadata.
Customization is mostly around BSP configuration, rootfs changes, and deployment scripts.	Customization must be captured as product layers, recipes, image features, and distro policy.
Manual or scripted NVIDIA flashing workflows are acceptable.	CI/CD, release automation, and controlled image reproducibility are major requirements.

The correct path should be selected according to the product's software architecture, release process, maintainability requirements, and manufacturing workflow. The security requirements should be defined independently, then implemented through the build path selected by the product.

❯

Share This Page

Send Email Using