RidgeRun Platform Security Manual - JetPack Build Process
🚧 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
JetPack Build Process
This section explains how the security features of NVIDIA Jetson platforms fit into the JetPack and Linux for Tegra (L4T) development workflow.
The developer should first prepare a working Jetson Linux installation, confirm that the target device boots and operates correctly, and then apply the security procedures that match the product requirements.
The Security Flow provides the overall path from a development system to a secured platform. The following sections describe how to configure, implement, deploy, and validate individual security mechanisms using the NVIDIA Jetson Linux BSP and its associated tools.
Security Flow
The Security Flow provides an overview of the Jetson security process and the recommended path for moving from a working development system toward a validated security configuration.
It can be used as the starting point before applying the individual security procedures described below.
Security Procedures
The following guides cover the security mechanisms currently documented for the JetPack / L4T development path:
- Secure Boot
- Trusted Execution Environment (TEE)
- Disk Encryption
- Over-the-Air Updates (OTA)
- Trusted Platform Module (TPM)
- Kiosk Modes
Each procedure describes the required setup, tools, configuration, commands, deployment process, validation steps, and relevant limitations for the corresponding security mechanism.
Over-the-Air Updates
Software updates are part of the security lifecycle of a deployed product. An update mechanism must preserve the security properties established during development while allowing authorized software to be deployed throughout the lifetime of the device.
The JetPack / L4T section includes guidance for different OTA frameworks:
The RAUC documentation additionally covers:
- Bring Up and Yocto Integration
- Update Flow and Custom Bootloader
- Advanced Topics and Troubleshooting
Bringing Secure Boot to Production
Enabling Secure Boot during development is only part of the process required to secure a production device.
A production deployment must also consider how signing keys are protected, how images are signed, how devices are provisioned, and how the signing process integrates with the software development and release infrastructure.
The Bringing NVIDIA Jetson Secure Boot To Production section covers the transition from a development Secure Boot configuration to a production-oriented signing infrastructure.
The available guides include:
- Integrate NVIDIA flashing scripts with an HSM
- Setting up a signing server
- Integrating the signing server with CI/CD
- Integrating the signing server with Yocto
These procedures address the infrastructure surrounding Secure Boot, including protected signing keys, automated signing workflows, and the integration of security into production build and deployment processes.
From Development to Production
The security mechanisms described in this section should not be treated as independent features.
For example, Secure Boot can establish trust in the software executed during startup, while disk encryption protects data at rest and secure OTA mechanisms help preserve software authenticity when the product is updated.
A typical development path can therefore be represented as:
The exact combination of security mechanisms depends on the product's assets, threat model, deployment environment, and security requirements.
Before production deployment, the developer should validate both expected and unauthorized scenarios and verify that recovery, update, provisioning, and signing procedures preserve the intended security properties.