Bringing NVIDIA Jetson Secure Boot to Production
🚧 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
Bringing NVIDIA Jetson Secure Boot to Production
Security is a critical requirement for modern embedded systems, particularly in industries such as medical, automotive, and industrial applications. NVIDIA Jetson platforms provide several security features, including Secure Boot, which establishes a chain of trust that verifies software components throughout the boot process and prevents the execution of unauthorized code.
While NVIDIA provides extensive documentation on how to enable Secure Boot, there is considerably less guidance on how to deploy and operate it in a production environment. Topics such as key management, manufacturing workflows, infrastructure design, device provisioning, and secure flashing are often left to system integrators to define and implement.
This wiki focuses on those production challenges. Its goal is to provide practical guidance for taking NVIDIA Jetson Secure Boot from development to production, covering the infrastructure, processes, and best practices required to deploy it securely and at scale.
Development vs Production
One of the most common mistakes when deploying Secure Boot is using the same keys and workflows for both development and production.
Development environments prioritize flexibility. Developers often need direct access to keys to sign images, test changes, and recover devices. Since these devices are not intended for customer deployment, the impact of a compromised development key is usually limited.
Production environments have different requirements. Production keys establish the root of trust for deployed devices and should only be accessible through controlled and auditable processes. A compromised production key could affect every device shipped to customers.
For this reason, development and production assets should always be separated. Development devices should use development keys, while production devices should only be provisioned using protected production keys.
The following table summarizes the differences between both environments:
| Aspect | Development | Production |
|---|---|---|
| Keys | Can be shared among developers | Access restricted to authorized personnel and systems |
| Key Storage | Local machine, USB drive, shared storage | HSM, secure vault, or protected infrastructure |
| Signing | Performed by developers as needed | Performed through controlled and auditable services |
| Device Provisioning | Manual and flexible | Standardized and repeatable process |
| Key Backup | Optional | Securely backed up and documented |
| Key Compromise | Usually affects development devices only | May affect all deployed products |
| Access Control | Team-based trust | Principle of least privilege |
JetPack 5 vs JetPack 6: ODM Fuse and FSKP
Before designing a production Secure Boot workflow, it is important to understand the provisioning mechanisms available on Jetson platforms.
Historically, Jetson devices have been provisioned using the ODM Fuse workflow, typically through the odmfuse.sh utility. This approach has been successfully used in production deployments for years and remains a valid option for many products. However, it requires careful handling of sensitive cryptographic material during manufacturing and often relies on additional operational controls to protect production secrets.
JetPack 6 introduces Factory Secure Key Provisioning (FSKP), a provisioning mechanism that allows organizations to generate provisioning artifacts in a controlled environment and use them during device provisioning, reducing the need to expose sensitive cryptographic material on the factory floor.
Why This Guide Uses FSKP
RidgeRun recommends Factory Secure Key Provisioning (FSKP) for all new Secure Boot deployments. Therefore, the remainder of this guide assumes an FSKP-based provisioning workflow and does not cover ODM Fuse provisioning recommendations.
The primary requirement for using FSKP is JetPack 6. If your product is currently based on an earlier JetPack release, we strongly recommend evaluating a migration path before designing your production Secure Boot infrastructure.
Define Your Teams and Access Roles
Before generating production keys or designing your infrastructure, it is important to define who will be responsible for Secure Boot operations and what level of access each team requires.
One of the most common mistakes in production deployments is granting unnecessary access to sensitive cryptographic assets. Not every team involved in the product lifecycle needs access to production keys. In fact, minimizing access is one of the most effective ways to reduce security risks.
A typical Secure Boot deployment involves several teams with different responsibilities:
| Team | Responsibilities | Recommended Size | Access to Production Keys |
|---|---|---|---|
| Secure Boot Team | Production key generation, key management, signing infrastructure and FSKP package generation. This team is typically composed of trusted senior developers, technical leads, or engineering managers responsible for protecting production assets. | 2-3 trusted individuals | Yes |
| Development Team | Software development, testing, validation, development key management. Development teams should maintain their own development keys. | N/A | No |
| CI/CD Team | Build generation, artifact storage, automated testing, release orchestration. | N/A | No |
| Manufacturing Team | Device provisioning, flashing, production validation. | N/A | No |
As a general rule, production keys should only be accessible to the smallest possible group of trusted individuals. Development, CI/CD, and manufacturing workflows teams operate using approved artifacts rather than direct access to production secrets.
Generating and Protecting Production Keys
Production keys establish the root of trust for every device deployed to customers. As a result, the process used to generate, store, and protect these keys is one of the most critical aspects of a Secure Boot deployment.
There is no single approach that fits every organization. Smaller teams may choose to generate and manage keys using software-based tools, while larger organizations often rely on dedicated hardware security solutions. Regardless of the chosen approach, the objective remains the same: ensure that production keys are generated securely, protected from unauthorized access, and available when required for manufacturing and software releases.
The following sections describe the most common approaches used in production environments.
1 - Software-Based Key Generation
Software-based key generation relies on cryptographic tools such as OpenSSL to create production keys. Keys are typically generated from a secured workstation or offline environment and stored using encrypted storage mechanisms.
This approach is often the simplest and most accessible option for organizations adopting Secure Boot. It requires minimal infrastructure and can be successfully deployed in production when combined with strong operational controls, access restrictions, and backup procedures.
See how to generate your keys using OpenSSL at our wiki: [here]
2 - Hardware-Based Key Generation (HSM)
To understand more about HSM's read our wiki What is an HSM?
Hardware-based key generation uses a Hardware Security Module (HSM) to generate, store, and use cryptographic keys.
For production deployments, RidgeRun recommends using an HSM whenever possible. While software-based key management can be sufficient for development and some production environments, it relies heavily on operational controls to protect sensitive key material.
An HSM provides a stronger security model by allowing cryptographic keys to be generated, stored, and used within dedicated security hardware. In many deployments, private keys never leave the HSM, significantly reducing the risk of accidental exposure or unauthorized access.
Please see our wiki on how to integrate your flashing scripts with an HSM [here]
Comparison Summary
| Feature | Software-Managed Keys | HSM-Managed Keys |
|---|---|---|
| Key Protection | Relies on operational controls | Hardware-enforced protection |
| Private Key Exposure | Keys may exist on host systems | Keys can remain inside the HSM |
| Signing Operations | External tooling required | Performed directly by the HSM |
| Access Control & Auditing | Depends on implementation | Typically built-in |
| Backup & Recovery | User-managed | Vendor / infrastructure dependent |
| Operational Complexity | Low | Medium to High |
| Infrastructure Cost | Low | Medium to High |
| Typical Usage | Development, prototypes, small deployments | Production and high-security deployments |
Where to Store Your Production Keys
Generating production keys is only the first step. Once the keys have been created, organizations must decide where they will be stored, how they will be protected, and how they will be recovered if a failure occurs.
Unlike development keys, production keys may be used for many years to provision devices, generate FSKP packages, sign software releases, and support manufacturing operations. As a result, key storage should be treated as a long-term operational decision rather than a one-time setup task.
A good key storage strategy should balance three objectives:
- Protect keys from unauthorized access.
- Ensure keys remain available when needed.
- Allow the organization to scale its manufacturing and release processes over time.
Production Storage vs Backup Storage
When discussing key management, it is important to distinguish between production storage and backup storage.
- Production storage refers to the location where keys are kept for day-to-day operations such as Secure Boot signing, FSKP generation, manufacturing, and software releases.
- Backup storage refers to protected copies of those keys that are retained for disaster recovery purposes. These backups are typically accessed only if the primary key storage system becomes unavailable or is lost.
Hardware Security Modules (HSMs) are generally considered the preferred solution for production key storage because they provide strong protection for cryptographic assets while allowing signing operations to be performed without exposing private keys.
However, HSMs should not be viewed as a complete backup solution. In many deployments, private keys generated inside an HSM are intentionally non-exportable, meaning they cannot be retrieved after creation. While this greatly improves security, it also means organizations must establish a separate recovery strategy.
For this reason, production deployments often combine multiple approaches:
- An HSM or secret management platform for daily operations.
- Encrypted offline backups for disaster recovery and business continuity.
This separation helps organizations achieve both objectives: protecting production keys from unauthorized access while ensuring they can be recovered if a failure occurs.
Common Storage Approaches
Organizations typically use different storage strategies depending on whether keys are needed for daily operations or retained for backup and recovery purposes.
| Storage Method | Description | Examples | Recommended for Production | Suitable for Backup & Recovery |
|---|---|---|---|---|
| Encrypted Files | Keys are stored as encrypted files on secured systems. | OpenSSL-encrypted PEM files, LUKS encrypted disks, BitLocker-protected drives | Not Recommended | Recommended |
| Secret Management Systems | Keys are managed through centralized secret management platforms. | HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager | Depends on deployment requirements | Recommended |
| Hardware Security Modules (HSMs) | Keys are generated, stored, and used inside dedicated hardware. | YubiHSM 2, Nitrokey HSM, Thales Luna HSM, Entrust nShield, AWS CloudHSM | Strongly Recommended | Vendor-dependent |
| Offline Encrypted Storage | Backup copies are stored on encrypted removable media and kept offline. | Encrypted USB drives, encrypted SSDs stored in safes, offline backup media | Not Suitable | Recommended |
Regardless of the chosen storage solution, production keys should be treated as highly sensitive assets.
The following practices are strongly recommended:
- Document ownership and access procedures.
- Periodically review who has access to production assets.
- Ensure that production keys are never distributed through email, messaging platforms, source control repositories, or other systems not specifically designed to protect sensitive information.
Reference Production Architecture
The following diagram illustrates a typical Secure Boot production deployment based on the concepts discussed throughout this guide.
This architecture separates development, key management, and manufacturing operations into independent environments with different security requirements.
End-to-End Production Workflow
The production workflow can be summarized as follows:
- Developers push code changes to the source repository.
- The CI/CD pipeline builds the software and generates the unsigned artifacts required for deployment.
- The unsigned artifacts are sent to the Signing Server.
- The Signing Server requests the required cryptographic operations from the HSM.
- The HSM signs the artifacts using the production keys stored inside the secure environment.
- The signed artifacts are returned to the Signing Server.
- The CI/CD pipeline retrieves the signed artifacts and generates the final flashing artifacts required for deployment.
- NVIDIA signs and generates the corresponding
results.zippackage required for Factory Secure Key Provisioning (FSKP). (IMPORTANT: This is a one time step. See FSKP process to understand about it.) - The flashing artifacts and the
results.zippackage are combined into a factory-ready flashing bundle. - The flashing bundle is distributed to the factory floor using approved distribution mechanisms.
- Factory operators use the bundle to provision and flash production devices.
- The provisioned devices are ready for deployment without requiring factory personnel to access production keys, HSM infrastructure, or signing systems.
RidgeRun Recommendation
This architecture represents RidgeRun's recommended approach for production Secure Boot deployments. However, every organization has different security, manufacturing, and operational requirements.
The final architecture should always be adapted to the specific needs of your product and organization. If you need assistance designing your Secure Boot infrastructure, feel free to contact us.
Secure Environment
The Secure Environment contains the most sensitive assets in the system, including production keys, HSM infrastructure, backup media, and FSKP provisioning artifacts.
A dedicated Signing Server acts as the only system authorized to request cryptographic operations from the HSM. This prevents production keys from being exposed to development systems, CI/CD infrastructure, or manufacturing environments.
A dedicated Signing Server acts as the only system authorized to request cryptographic operations from the HSM. Protecting the Signing Server is as important as protecting the HSM because a compromised server could misuse the HSM's signing capabilities. The server should run in a dedicated, hardened environment isolated from development systems, CI/CD infrastructure, and manufacturing networks, with access restricted to authorized services and personnel.
Production keys are stored inside the HSM for day-to-day signing operations, while encrypted offline backups are maintained separately for disaster recovery purposes.
Development Environment
Developers interact only with the CI/CD infrastructure and never require direct access to production keys.
When signing is required, the CI/CD pipeline submits unsigned artifacts to the Signing Server and receives signed artifacts in return. This separation allows development workflows to remain automated while ensuring production secrets remain isolated.
See the following wiki for a reference implementation: How to integrate your signing server with your CI CD
Why Separate the Signing Server from CI/CD?
One of the most important design decisions is keeping the Signing Server separate from the CI/CD infrastructure.
Build systems typically have a much larger attack surface due to source code access, third-party dependencies, build agents, automation tooling, and user access. By isolating signing operations behind a dedicated Signing Server, organizations can significantly reduce the number of systems that interact with production cryptographic assets.
This design follows the principle of least privilege: development systems can build software, but only trusted signing infrastructure can authorize software for production deployment.
Factory Floor
The factory receives only the final flashing bundle containing the signed artifacts required to provision devices.
Manufacturing personnel do not require access to production keys, HSMs, signing infrastructure, or Secure Boot provisioning systems. This is why we recommend using FSKP, because without it it wouldn't be possible. Their responsibility is limited to flashing approved artifacts onto production devices.