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.
- Introduction
- General Security Concepts
- Getting Started
- Contact Us
- Sponsor your Favorite Feature
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
The security objective does not change depending on the selected build system. What changes is how the security mechanism is integrated, configured, built, and deployed.
| JetPack / L4T | Yocto | |
|---|---|---|
| Base environment | NVIDIA Jetson Linux / L4T | Yocto-based Linux distribution |
| Build integration | NVIDIA BSP, flashing, and signing workflow | Yocto recipes, classes, configuration, and image generation |
| Security configuration | Integrated using NVIDIA Jetson Linux tools and configuration | Integrated into the Yocto build together with NVIDIA platform mechanisms |
| Image generation | NVIDIA Jetson Linux flashing and image-generation workflow | Reproducible Yocto image-generation workflow |
| Typical use | Products based directly on the NVIDIA Jetson Linux software stack | Products maintaining a customized Yocto-based Linux distribution |
The choice between JetPack and Yocto should therefore be based on the software architecture and product requirements rather than on the security feature itself.