Integrating an HSM into the NVIDIA Jetson Secure Boot Signing Workflow

🚧 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

One of the biggest challenges when deploying Secure Boot in production is protecting the private keys used to sign images.

By default, NVIDIA's Secure Boot tooling expects access to a private key file stored on disk. While this is acceptable for development environments, many organizations prefer to keep production keys inside a Hardware Security Module (HSM).

Fortunately, NVIDIA already provides the necessary hooks and infrastructure to integrate external signing solutions into the Secure Boot workflow.

This section explains how the Secure Boot signing process works, how NVIDIA's HSM architecture is structured, and how you can integrate your own hardware-backed or cloud-backed signing solutions.

What is an HSM?

Before starting, it's important to understand what a Hardware Security Module (HSM) is. It is a dedicated security device designed to protect cryptographic assets. Unlike software-based approaches, private keys can remain inside the HSM and never be exposed to operating systems, users, or applications.

In addition to generating keys, HSMs can perform signing operations directly, allowing organizations to sign software releases, generate FSKP artifacts, and perform other cryptographic operations without exposing the underlying private key material.

HSMs are available in several forms, including dedicated on-premises appliances, USB-based devices, and cloud-managed services offered by major cloud providers.

Understanding the Flashing and Signing Workflow

When Secure Boot signing is enabled, NVIDIA's flashing tools eventually invoke the signing infrastructure responsible for generating the signatures attached to boot components.

The process begins with:

tegra-flash-helper.sh

which launches:

tegraflash.py

The high-level execution flow can be simplified as:

During a standard Secure Boot deployment, NVIDIA uses its default OpenSSL-based signing implementation.

However, NVIDIA also provides an optional HSM mode that allows signing operations to be delegated to external key management systems.

Conceptually, the signing path looks like:

When HSM mode is enabled, NVIDIA's Secure Boot tooling can use one of two HSM backends:

Backend	Description
`tegrasign_v3_softhsm.py`	Backend intended for HSM devices accessible directly from the host system. These devices typically expose a PKCS#11-compliant interface. Common examples include YubiHSM 2, Thales Luna HSM, and Entrust nShield.
`tegrasign_v3_hsm.py`	Backend intended for cloud-based key management systems or custom signing infrastructures that are not directly accessible from the host system. Common examples include AWS KMS, Azure Managed HSM, Google Cloud KMS, HashiCorp Vault, or internally developed signing services.

To enable HSM mode during the flashing process, pass:

--hsm

When this option is used, NVIDIA's flashing workflow automatically follows the PKCS#11-based signing path and loads:

tegrasign_v3_softhsm.py

This is the recommended approach when using a physical HSM connected or accessible from the host system.

If your signing infrastructure uses cloud or non PKCS#11 compliant HSM (will need customization to work), you can instead use:

tegrasign_v3_hsm.py

To do so, modify in tegraflash_impl_t234.py:

def call_tegrasign(..., softhsm=True):

Change softhsm value from True to False

This causes NVIDIA's Secure Boot tooling to load:

tegrasign_v3_hsm.py

where the HSM hooks can be adapted to communicate with cloud-based key management systems, remote signing services, or custom signing infrastructures.

The following sections explain how each backend can be integrated.

How to Customize the Flashing Scripts to Communicate with Your HSM

Using NVIDIA's SoftHSM Implementation

For most Secure Boot deployments, RidgeRun recommends starting with NVIDIA's SoftHSM implementation:

tegrasign_v3_softhsm.py

This is generally the simplest approach because NVIDIA already provides a complete PKCS#11 communication layer. As a result, integrating a supported HSM typically requires only a few configuration changes rather than modifying the Secure Boot signing logic itself.

The most important parameters you will find in that file are:

# HSM connection parameters

hsm_token_label = "HSM"
hsm_lib_path = "/usr/lib/softhsm/libsofthsm2.so"
hsm_user_pin = "1234"

These parameters tell NVIDIA's Secure Boot tooling:

Which PKCS#11 library should be loaded (provided by your HSM vendor)
Which token should be used
Which PIN should be used to authenticate to the HSM

By modifying only those values, you should be ready to go. Connect your HSM to your signing server and test.

⚠️ Consult Your HSM vendor!!!

You should consult your HSM vendor's documentation to determine the correct values for these parameters.

When a Custom Implementation Is Required

Not all signing solutions expose a PKCS#11 interface.

Examples include:

AWS KMS
Azure Managed HSM
Google Cloud KMS
HashiCorp Vault
Internal signing services

In these cases, the Secure Boot hooks must be modified to call the vendor's SDK or API.

Example: AWS KMS

The following example illustrates how the RSA-PSS signing operation could be redirected to AWS KMS:

def do_rsa_pss_hsm(buf, p_key):

    import boto3
    import hashlib

    sha_str = 'SHA_256' if (
        p_key.key.pkckey.Sha == Sha._256
    ) else 'SHA_512'

    if sha_str == 'SHA_256':
        digest = hashlib.sha256(buf).digest()
        algorithm = 'RSASSA_PSS_SHA_256'
    else:
        digest = hashlib.sha512(buf).digest()
        algorithm = 'RSASSA_PSS_SHA_512'

    kms = boto3.client('kms')

    response = kms.sign(
        KeyId='YOUR_KMS_KEY',
        Message=digest,
        MessageType='DIGEST',
        SigningAlgorithm=algorithm
    )

    sig_data = swapbytes(
        bytearray(response['Signature'])
    )

    return sig_data

Summary

NVIDIA provides two mechanisms for integrating HSMs into the Secure Boot workflow:

tegrasign_v3_softhsm.py
tegrasign_v3_hsm.py

If your HSM exposes a PKCS#11 interface, NVIDIA's SoftHSM implementation will typically provide most of the functionality required to perform Secure Boot signing.

In many cases, integrating a new HSM only requires updating:

PKCS#11 library path
Token label
Authentication credentials

Custom implementations are usually only required when integrating cloud-managed signing services or proprietary key management systems that do not expose a PKCS#11 interface.

Need Help Bringing Secure Boot to Production?

Not sure how to integrate your HSM or Secure Boot infrastructure?

RidgeRun's engineering team can help guide you through the integration process and accelerate your path from development to production.

❯

Share This Page

Send Email Using