Factory Secure Key and Expansion Key Provisioning

Factory Secure Key Provisioning (FSKP) is a technique to securely burn fuses on the factory floor. The fuse data contains a sensitive device and encryption keys that establish the root of trust on the target device. FSKP protection is important because the factory floor might not have a high level of security and can pose security risks.

FSKP provides a way to securely transfer fuse data to NVIDIA® Jetson™ using encryption. This encryption is completed with a shared platform key called the FSKP key, and this key is available on the OEM’s hardware security module (HSM) server for encryption and in the chip’s internal ROM (IROM) for decryption.

Jetson devices are programmed with 64 FSKP keys, and these keys are in an array of 64 AES 256-bit symmetric keys, which are stored in internal ROM (IROM) on the chip and are referenced by an index from 0 to 63. Of these keys, 46 can be assigned to OEMs to protect their factory floor, Jetson boot images, and fuse data with a digital signature and encryption. NVIDIA generates and places the keys in the Jetson IROM to make them part of the secure boot chain of trust.

Although 46 FSKP keys are available to the OEMs, this is not enough keys to accommodate the growing number of OEMs. To solve this problem, a Key derivation key uses the Key derivation function (KDF) to generate a derived key from the root key (Key 62 or the Expansion Key). By using KDF, you can generate an unlimited number of derived keys.

Requesting FSKP Expansion Keys

  1. Contact your NVIDIA representative to start the process.

  2. Generate a one-time RSA key pair with a cryptographic tool (we recommend openssl, see section 1.2.2 for detailed instructions).

  3. Send the public_key.cer to NVIDIA.

  4. After the request is approved, the FSKP Expansion Keys will be encrypted with the public_key.cer and sent back to you inside a Results.zip file.

  5. You can use the keys to prepare your encrypted and signed blob.

Generating and Verifying the Self-Signed X.509 Certificate

The self-signed X.509 certificate is the certificate that the FSKP owner emails to the key custodian.

Here are the requirements to generate and verify the certificate:

To generate a self-signed X.509 certificate, use keytool or openssl.

Generating an RSA Key Pair and Creating a Certificate with the Public Key (Option 1 with keytool)

  1. On the Linux system, create a directory to store the private and public key:

    $ mkdir ~/CKMS

  2. Generate a Java keystore and an RSA key pair and place the key pair in the Java keystore.

    A Java keystore (JKS) is a storage area in the Linux file system where the Java key tool utility stores cryptographic keys and certificates. You can use the keytool command to generate the key pair and place it in the Java keystore where <alias> is an alias that keytool uses to identify the key pair. Although the alias is arbitrary, it must be unique in the Java keystore because the alias is used as the basename of the CER (certificate) file.

  3. To access the keystore, enter a password.

  4. To access the RSA key pair, enter a password.

  5. Export the public key to a certificate (CER) file:

    keytool -export -alias <alias> -file ~/CKMS/<alias>.cer \\ -keystore ~/CKMS/mystore.jks

    where <alias> is assigned to the key pair, and the keytool utility creates the CER file with the specified name and stores the certificate in the CER file and the Java keystore.

  6. Email the CER file to the NVIDIA key custodian.

Generating an RSA Key Pair and Creating a Certificate with the Public Key (Option 2 with openssl)

  1. Generate 4096 bits RSA Public and private keys:

    openssl genrsa -aes-256-cbc -out oem_rsa_priv.pem 4096

  2. Generate RSA x509 based Certification:

    openssl req -new -x509 –outform PEM -key oem_rsa_priv.pem -out oem_publickey.cer -days 365

  3. Email the CER file to the NVIDIA key custodian.

Content of the Results.zip File

FSKP Expansion keys, which are wrapped and encrypted with the OEM public_key.cer, will be sent from NVIDIA in a zip file.

Here are the contents of the zip file:

  • fskp_ak.bin.rsa_wrap: The FSKP_AK wrapped with the RSA public key (binary).

  • fskp_ak.bin.rsa_wrap.info: metadata, Label, and String/Context used in KDF, and KCV of FSKP_AK.

  • fskp_ek.bin.rsa_wrap: FSKP_EK wrapped with RSA public key (binary).

  • fskp_ek.bin.rsa_wrap.info: metadata, Label, and String/Context used in KDF, and the KCV of FSKP_EK.

  • fskp_conf.txt: includes the AK and EK strings for fskp_fuseburn.py use.

An Example: Preparing the Encrypted and Signed Blob at HSM

Here are the software requirements:

  • Ubuntu 18.04, 20.04, or 22.04

  • JetPack public release package:

  • Jetson_Linux_R3x.x.0_aarch64.tbz2

  • Tegra_Linux_Sample-Root-Filesystem_R3x.x.0_aarch64.tbz2

  • FSKP tool package: fskp_partner_t234_R3x.x.0_aarch64.tbz2

  • Results.zip: Obtained from NVIDIA.

  • Openssl: https://www.openssl.org/

  1. Untar the JetPack release and the fskp_partner_t234_R3x.x.0_aarch64.tbz2 file:

    $ tar xpfv ${L4T_RELEASE_PACKAGE}
$ sudo tar xpf ${SAMPLE_FS_PACKAGE} -C Linux_for_Tegra/rootfs/

# Copy fskp_partner_t234_R3x.x.0_aarch64.tbz2 to the same directory

$ cd Linux_for_Tegra/
$ tar xvjf ../fskp_partner_t234_R3x.x.0_aarch64.tbz2
$ sudo ./apply_binaries.sh
$ sudo ./tools/l4t_flash_prerequisites.sh
$ cd l4t/tools/flashtools/fuseburn

  2. Copy the Results.zip file to the l4t/tools/flashtools/fuseburn folder and unzip it:

    $ unzip Results.zip

  3. Decrypt the *.rsa_warp files (Encrypted keys).

  4. Navigate to the fuseburn scripts directory.

  5. To restore keys, run the openssl command:

    $ cd l4t/tools/flashtools/fuseburn/Results

openssl rsautl -decrypt -inkey oem_rsa_priv.pem -in fskp_ak.bin.rsa_wrap > fskp_ak.bin

openssl rsautl -decrypt -inkey oem_rsa_priv.pem -in fskp_ek.bin.rsa_wrap > fskp_ek.bin

  6. Copy these files from the Results directory to the fuseburn directory (one level above):

    $ mv fskp_ak.bin ..
$ mv fskp_ek.bin ..
$ mv fskp_conf.txt ..

Preparing the Encrypted and Signed Blob

  1. Make sure the board specifications files and the board configuration files have the correct information. The board specification file contains a non-exhaustive list of environment variables to pass to the NVIDIA-provided board specifications file to generate a list of files to use for the FSKP process. We recommend that you provide the following variables for the board specification. Refer to the official Jetson documentations on how to retrieve these values:

    • BOARDID

    • CHIP_SKU

    • BOARDSKU

    • RAMCODE_ID

    • FAB

    • BOARDREV

    Note

    All these variables can be retrieved by flash.sh with the --read-info command option.

  2. Run the following command:

    cd <top>/l4t/tools/flashtools/fuseburn

  3. Depending on your device, run the following command:

    • NVIDIA Orin AGX:

      sudo ./fskp_fuseburn.py --board-spec orin-agx-board-spec.txt -f fuseblob.xml -i 62 --test --key-exp fskp_ak.bin fskp_ek.bin --fskpcfg fskp_conf.txt -g out/ -c 0x23 -B <top>/jetson-agx-orin-devkit.conf

*fuseblob.xml is the fuse blob data to burn.

    • NVIDIA Orin Nano:

      sudo ./fskp_fuseburn.py --board-spec orinnano-board-spec.txt -f fuseblob.xml -i 62 --test --key-exp fskp_ak.bin fskp_ek.bin --fskpcfg fskp_conf.txt -g out/ -c 0x23 -B <top>/jetson-orin-nano-devkit.conf

*fuseblob.xml is the fuse blob data to burn.*

    Note

    This example uses the –test argument that will not burn the fuses. To burn the fuses, users need to change it to -b.

  4. When prompted whether to continue testing the fuses, enter No:

    WARNING!! Testing Fuses option is selected

do you want to continue testing the fuses (Yes/No) **No**

The out.tar file will be generated, and it will contain the encrypted
and signed blob files that can be delivered to the factory floor.

An Example: Using the Encrypted and Signed Blob at the Factory

Here are the software requirements:

  • Ubuntu 18.04, 20.04, or 22.04

  • JetPack public release package:

    • Jetson_Linux_R3x.x.0_aarch64.tbz2

    • Tegra_Linux_Sample-Root-Filesystem_R3x.x.0_aarch64.tbz2

  • FSKP tool package: fskp_partner_t234_R3x.x.0_aarch64.tbz2

  • Out.tar: Generated in 1.4 and is delivered to the factory floor.

  1. Untar the JetPack release and the fskp_partner_t234.tbz2 file:

    $ tar xpfv ${L4T_RELEASE_PACKAGE}
$ sudo tar xpf ${SAMPLE_FS_PACKAGE} -C Linux_for_Tegra/rootfs/

# Copy fskp_partner_t234_R3x.x.0_aarch64.tbz2 to the same directory

$ cd Linux_for_Tegra/
$ tar xvjf ../fskp_partner_t234_R3x.x.0_aarch64.tbz2
$ sudo ./apply_binaries.sh
$ sudo ./tools/l4t_flash_prerequisites.sh
$cd l4t/tools/flashtools/fuseburn

    Here is the Tegra UART output:

    sudo minicom -D /dev/ttyACM0

    You need to capture the Tegra UART output to determine whether the burn fuse process was successful.

  2. Place the Tegra in Recovery mode:

    cd <top>/Linux_for_Tegra/tools/board_automation
sudo ./boardctl -t topo recovery

  3. Navigate to the fuseburn scripts directory:

    cd <top>/l4t/tools/flashtools/fuseburn

  4. Copy the out.tar file that was delivered to the factory:

    #Untar the out.tar
tar xpfv out.tar

  5. Burn the fuses.

    • NVIDIA Orin AGX:

      sudo ./fskp_fuseburn.py --board-spec orin-agx-board-spec.txt -P ./out -c 0x23 -B <top>/jetson-agx-orin-devkit.conf

    • NVIDIA Orin Nano:

      sudo ./fskp_fuseburn.py --board-spec orinnano-board-spec.txt -P ./out -c 0x23 -B <top>/jetson-orin-nano-devkit.conf

    Note

    The jetson-agx-orin-devkit.conf file is used for NVIDIA Orin AGX, so you need to modify the board spec file with the correct information for your Tegra Hardware.

  6. When prompted about continuing to test the fuses, enter Yes:

    WARNING!! Testing Fuses option is selected
do you want to continue testing the fuses (Yes/No) **Yes**

Burn Status

To determine the burn status:

  1. On the Linux Host, verify that the following message is displayed:

    FSKP execution successful

  2. On the target (Tegra UART output), here is a sample fuseblob.xml result:

    I> Task: Burn fuses (0x500039e4)
I> Index : 1 Kdk0 size: 32
I> Index : 2 OemK1 size: 32
I> Index : 3 PublicKeyHash size: 64
I> Index : 4 SecureBootKey size: 32
I> Index : 5 BootSecurityInfo size: 4
I> Index : 6 OdmId size: 8
I> Index : 7 OdmInfo size: 4
I> Fuse Blob found
I>
I> ...
I> **Successfully burnt fuses as per fuse info**
Table 0‑1. Burn Status Actions

Action

Result

Burned successfully

On the host

Find this text:

FSKP execution successful

On the target (Tegra UART output), find this text:

Successfully burnt fuses as per fuse info.

Failed to Burn

If missing either of the texts from the host or the target.

Using the fskp_fuseburn.py File to Burn Fuses

The FSKP fusing scripts include the following:

  • fskp_fuseburn.py: Provides a high-level script that is invoked by the user. The script prepares encrypted and signed blobs, performs fuse burning, and invokes other tools based on the input parameters.

  • fskp_helper.py, fskp_parser.py, and fskp_shell_helper.py: helper scripts for the fskp_fuseburn.py scripts.

The FSKP tools include the following:

  • tegraparser_v2: Parses a fuse XML configuration file and uses it to generate a blob that contains the fuse data and an FSKP target-binary.

  • tegrarcm_v2: Manages communication between the host and the target and exchanges data and commands over USB with target’s BootROM and bootloader.

  • tegrasign_v3.py: Encrypts and signs an input image with the specified key.

  • tegrabct_v2: Creates BR_BCT, MB1_BCT, and the derivatives key binaries are used to encrypt and sign the fskp_blob.

  • tegrahost_v2: Appends the necessary header and brushes binaries to help sign and encrypt the binary.

  • fskp.bin: This FSKP target-binary is a minimal bootloader that is used to burn fuses and write to storage. Optionally, it also completes RPMB provisioning.

  • Fuse configuration file: An XML file that contains the fuse list that is read by the tegraparser_v2 tool. The fuse list specifies the name, length, and value of each fuse to be burned in the order in which they are listed.

Here is the FSKP fuse flow:

  1. Prepare the fuse data and the fskp binary blob in a secure environment.

  2. Fuse the hardware fuses on the target chip in the factory where the environment might not be secure.

FSKP Fuse Burn Script

Before you can use the fskp_fuseburn.py tool, the Python programming software must be installed on the host system.

The tool completes the following tasks:

  • Parses the fuse configuration file and prepares a blob that contains the fuse data and an FSKP target-binary.

  • Encrypts and signs the blob with the input key.

  • Signs MB1 and optionally creates MB1-BCT.

  • Downloads MB1 to the target and optionally downloads MB1-BCT on the target using USB recovery mode commands.

  • Downloads the blob to the target using USB Recovery Mode commands and performs fuse burning.

  • Optionally completes RPMB provisioning.

Before you begin, create a flashing environment that can be used with this tool. Refer to To Flash the Jetson Developer Kit Operating Software <> for more information.

  1. After you create the flashing environment, verify that the following folder exists:

    ./Linux_for_Tegra

  2. To access the tool, extract fskp_partner_t234.tbz2:

    sudo tar xpfv fskp_partner_t234.tbz2

The script is in the following directory, executes on the host, and
accepts the arguments in Table 2‑1.

l4t/tools/flashtools/fuseburn

Here is an example of how the script is used:

$ sudo <BOARD_SPEC> ./fskp_fuseburn.py --board-spec <board_spec> -f <fuse_config> -i <key_index> -k <FSKP_key> -g <out> -c <chip> -B <board>
Table 2‑1. Accepted Arguments

Argument

Description

–help (or -h)

Displays the help menu.

–burnfuse (or -b)

Performs fuse burning.

–board (or -B)

Board name for which you want to create a fuse blob or program fuses. Check help for the default supported boards.

–chip (or -c) <chip>

Sets tegra chipid, for example, 0x23 for NVIDIA Orin SoC.

–fskpcfg (or -C) <file>

Sets the derivation strings values from a text file instead of using the default values.

–ecid (or -e)

Gets the ECID of the target.

–fusefile (or -f) <file>

Specifies the fuse configuration file.

–outdir (or g) <path>

Generates a blob at <path> and does not perform a burn.

–keyindex (or -j) <index>

SoC FSKP key index allotted to the OEM.

–key (or -k)

FSKP key file provided to OEMs as per keyindex.

–key-exp <AK_keyfile> <EK_keyfile>

FSKP expansion key file pair that is provided to OEMs as per the key index.

–board-spec <file>

A board specification contains the BOARDSKU, FAB, and other board specific values. For examples, default_board_spec.txt contains the following:

  • BOARDID=3701

  • BOARDSKU=0004

  • FAB=000

  • CHIP_SKU=”00:00:00:D0”

–skipconfirmation (or -s)

Skips the confirmation message while burning the fuse.

–test (or -t)

Performs a dummy operation and does not burn fuses.

–skipuid (or -u)

Skips querying the UID of the target.

–verbose (or -v)

Enables verbose logs.

–skipfskpkey (or -K)

Use FSKP without using a FSKP key.

–prebuilt (or -P) <path>

Picks a prebuilt blob from <path> and does not generate a blob.

–version (or -V)

Identifies the version number.

Fuse Configuration File

The fuse configuration file is an XML file that contains the fuse data. The tegraparser_v2 tool parses this file and uses it to generate a blob of fuse configuration data.

Note

Although the fuse configuration file contains XML tags, it does not need the <?xml...?> prolog defined by the XML standard because the fuse configurations might not have a prolog. To run general XML utilities on this file, you might have to add a prolog.

For information about the format of the fuse configuration file, refer to Format of the Fuse Configuration File.

The fuse burn script burns fuses in the order in which they are specified in the fuse configuration file. It does not check for fuse dependencies. You must ensure that the fuse configuration file specifies fuses in an order that does not burn the dependent fuses before the fuses on which they depend.

Format of the Fuse Configuration File

A fuse configuration file contains a <genericfuse>… </genericfuse> tag pair that contains one <fuse/> tag for each fuse that will be burned. The following template shows the format of the file:

<genericfuse MagicId="0x45535546" version="1.0.0">

<fuse name="<name>" size="<size>" value="<value>"/>

<fuse name="<name>" size="<size>" value="<value>"/>

. . .

</genericfuse>

Where:

  • <name> is the name of a fuse and these names are documented in the table under Manufacture Programmable Fuses.

  • <size> is the size of the fuse in bytes.

  • <value> is the value to be burned into the fuse, with two hexadecimal digits per byte.

MagicID is used by the FSKP target-binary and must not be changed.

fskp.bin burns fuses in the order in which they appear in the fuse configuration file. If the value of two or more fuses are interdependent, the independent fuses must be specified before the dependent fuses so that the independent fuses are burned first. That is, if the values that can be burned into fuse Z depend on the value of fuse Y, and the values that might be burned into fuse Y depend on the value of fuse X, the fuse configuration file must specify and burn the fuses in the following order:

  1. Fuse X

  2. Fuse Y

  3. Fuse Z

Caution

The FSKP fuse burning tool does not check for dependencies, so specifying a dependent fuse before the fuse on which it depends, might render the target device inoperable. Check the fuse list’s order carefully before you burn the fuses.

To use RPMB provisioning, the tool supports fusing the RPMB key on eMMC storage. The version field must be 2.0.0 for RPMB. This requires the OEM_K1 key to be present in the fuse configuration file:

<genericfuse MagicId="0x45535546" version="2.0.0">

<rpmb provisioning = "0x1" dev_type = "0x2"/>

<fuse name="<name>" size="<size>" value="<value>"/>

<fuse name="<name>" size="<size>" value="<value>"/>

. . .

</genericfuse>

A Reference Fuse Configuration File

The Jetson Linux platform provides a fuse configuration file for use as a reference, and the file is located here:

<top>/l4t/tools/flashtools/fuseburn

The fuse list for this file is ordered correctly to allow for fuse dependencies.

Some fuse values in the reference configuration file are enclosed in XML comments, as in the following example. To adapt the reference file for your use, uncomment them and replace the 0xFFFF… placeholder values with the actual key index values for your target:

<genericfuse MagicId="0x45535546" version="1.0.0"> <!-- <fuse
name="OdmId" size="8" value="0xFFFFFFFFFFFFFFFF"/> --> <!-- <fuse
name="ReservedOdm0" size="4" value="0xFFFFFFFF"/> --> <!-- <fuse
name="ReservedOdm1" size="4" value="0xFFFFFFFF"/> --> <!-- <fuse
name="ReservedOdm2" size="4" value="0xFFFFFFFF"/> --> <!-- <fuse
name="ReservedOdm3" size="4" value="0xFFFFFFFF"/> --> <!-- <fuse
name="ReservedOdm4" size="4" value="0xFFFFFFFF"/> --> <!-- <fuse
name="ReservedOdm5" size="4" value="0xFFFFFFFF"/> --> <!-- <fuse
name="ReservedOdm6" size="4" value="0xFFFFFFFF"/> --> <!-- <fuse
name="ReservedOdm7" size="4" value="0xFFFFFFFF"/> --> <!-- <fuse
name="OdmInfo" size="4" value="0x0000FFFF"/> --> <!-- <fuse
name="SecureProvisionInfo" size="4" value="0x1"/> --> <!-- <fuse
name="PublicKeyHash" size="64"
value="0x00000000111111112222222233333333444444445555555566666666777777778888888899999999aaaaaaaabbbbbbbbccccccccddddddddeeeeeeeeffffffff"/>
--> <!-- <fuse name="BootSecurityInfo" size="4" value="0x1"/> -->
<!-- <fuse name="SecurityMode" size="4" value="0x1"/>
--></genericfuse>

Note

Although its size is 4, only the last two bytes in the Odminfo are allowed to be programmed.

Preparing an Encrypted and Signed Blob

The FSKP blob encryption and signing is completed by using derived keys, and here is the process:

  1. To parse the fuse configuration file and prepare a blob that contains fuse data and an FSKP target-binary, call tegraparser_v2.

  2. To generate the derived string binaries, call tegrabct_v2 to parse the dev_param and the br-bct dts files.

  3. To create BR-BCT, MB1-BCT, and MEM-BCT, call tegrabct_v2.

  4. To append the BCH header and sign the BCT binaries in step 3, call tegrasign_v3.py.

  5. To align the FSKP blob, call tegrahost_v2.

  6. To append the BCH header on FSKP blob, call tegrahost_v2.

  7. To encrypt the FSKP blob with the encryption key and sign it next, call tegrasign_v3.py.

  8. To sign MB1, PSC-BL1 binaries, call tegrasign_v3.py.

  9. To append and fill the signature on the MB1 and PSC-BL1 binaries, call tegrahost_v2.

  10. For the binaries to be included in the blob, cpu-bootloader, MB2, bpmp firmware, bpmp-dtb, spe firmware, mts, and psc firmware, complete the following tasks:

    1. To align, call each one with tegrahost_v2.

    2. To append the BCH header, call each one with tegrahost_v2.

    3. To sign, call tegrasign_v3.py.

    4. To generate the blob, call each one with tegrahost_v2.

Preparing the Encrypted and Signed Blob

The Results.zip file includes a fskp_conf.txt file that can be used as the -fskpcfg fskpcfg argument.

If the fskp_conf.txt file is not provided, users can create this file with the strings from fskp_ak.bin.rsa_wrap.info and fskp_ek.bin.rsa_wrap.info and place them in a configuration file of the following fixed format.

The content of the strings are 32 bytes in hex, and here is an example:

sec_provision_derivation_string1

Encryption Key (EK)

sec_provision_derivation_string2

Authentication Key (AK)

 
sec_provision_derivation_string1 =
"0x0000000000000000000000000000000000000000000000000000000000000001";

sec_provision_derivation_string2 =
"0x0000000000000000000000000000000000000000000000000000000000000002";

  1. Navigate to the fuseburn scripts directory:

    <top>/l4t/tools/flashtools/fuseburn

  2. Run the fuseburn command:

    $ sudo <BOARD_SPEC> ./fskp_fuseburn.py [-b] -f <fuse_config> -i <key_index> -k <FSKP_key> -g <out> -c <chip> --fskpcfg <fskp_cfg> -B <board> [--board-spec <board-spec-file>]

Where:

  • <fuse_config> is the fuse configuration file.

  • <key_index> is the FSKP key index.

  • <FSKP_key> is the FSKP key.

  • <out> is the directory where the command will write the output.

  • <chip> is the chip for which the FSKP blob is generated. For example, 0x23 is for NVIDIA Orin.

  • <fskp_cfg> is optionally generated by the OEM in step 1 to overwrite the default derivation strings. If you want default derivation strings, omit this argument.

  • <board> is the board config file in the Linux_for_Tegra folder. For example, Linux_for_Tegra/jetson-agx-orin-devkit.conf.

  • -g indicates that you need to use burn setting, but fuse burning does not take place.

  • -b indicates that you want to generate the fuse blob that burns the fuses. Without -b, the generated fuse blob will only do a dry run on the target when trying to burn fuses with the -p option.

  • <BOARD_SPEC> is the board information environment variables, such as BOARD_SKU, FAB, and so on.

    This will be provided for NVIDIA developer kits.

  • <board-spec-file> is like <BOARD_SPEC>, you can specify a shell script to define BOARD_SKU, FAB, and so on. NVIDIA provides the default_board_spec.txt file as an example for the AGX specification file.

    This command prepares an encrypted and signed blob and binaries and stores the binaries and the encrypted FSKP blob in the <out> directory. The directory can be used on the factory floor for fuse burning. The tool also conveniently generates a tarball (<out>.tar) so you can move the directory to other machines.

    For example, to generate a test fuse blob for Jetson AGX NVIDIA Orin devkit board, run the following fuse burn command with the debug key use index 63:

    $ sudo ./fskp_fuseburn.py -f fuse.xml -i 63 -k debug.key -g out/ -c 0x23 -B /home/user/Linux_for_Tegra/jetson-agx-orin-devkit.conf --board-spec orin-agx-board-spec.txt

    1. To generate a test fuse blob for Jetson AGX NVIDIA Orin devkit board, run the following fuse burn command with the debug key use index 63 x:

      $ sudo ./fskp_fuseburn.py -f fuse.xml -b -i 63 -k debug.key -g out/ -c 0x23 -B /home/user/Linux_for_Tegra/jetson-agx-orin-devkit.conf --board-spec orin-agx-board-spec.txt

    2. To use the FSKP expansion by using derived key pair AK and EK, run the following commands:

      $ sudo <BOARD_SPEC> ./fskp_fuseburn.py -f <fuse_config> -i <key_index> --key-exp <AK_key> <EK_key> -g <out> -c <chip> --fskpcfg <fskp_cfg> -B <board> [--board-spec <board-spec-file>]

Where:

  • <fuse_config> is the fuse configuration file.

  • <key_index> is the FSKP key index (should be 62).

  • <AK_key> is the FSKP derived authentication key.

  • <EK_key> is the FSKP derived encryption key.

  • <out> is the directory where the command will write the output.

  • <chip> is the chip for which the FSKP blob is generated. For example, 0x23 is for NVIDIA Orin.

  • <fskp_cfg> is mandatory. The fskp_cfg expansion key is provided by NVIDIA, and its content cannot be modified by the OEM.

  • <board> is the board config file in the Linux_for_Tegra folder. For example, Linux_for_Tegra/jetson-agx-orin-devkit.conf.

  • -g`` indicates that you need to use burn setting, but fuse burning does not take place. Do not use -s to skip the fuse burning confirmation.

  • -b indicates that you want to generate the fuse blob that burns the fuses. When trying to burn fuses with the -p option, without the -b option, the generated fuse blob will only complete a dry run on the target.

  • <BOARD_SPEC> is the board information environment variables, such as BOARD_SKU, FAB, and so on. These variables will be provided for NVIDIA developer kits.

  • <board-spec-file> is like <BOARD_SPEC> you can specify a shell script to define BOARD_SKU, FAB, and so on. NVIDIA provides the orin-agx-board-spec.txt file as an example for the AGX specification file.

This command prepares an encrypted and signed blob and binaries as described earlier. It stores the binaries and the encrypted FSKP blob in the <out> directory, and this directory can be used on the factory floor for fuse burning. The tool also conveniently generates a tarball (<out>.tar) so you can move the directory to other machines.

For example, to generate a test fuse blob for the Jetson AGX NVIDIA Orin devkit board:

  1. Run the following fuseburn command with expansion key pair use index 62:

    $ sudo ./fskp_fuseburn.py -f fuse.xml -i 62 –key-exp AK.key EK.key --fskpcfg fskp_conf.txt -g out/ -c 0x23 -B /home/user/Linux_for_Tegra/jetson-agx-orin-devkit.conf --board-spec orin-agx-board-spec.txt

  2. Run the following fuseburn command with expansion key pair use index 62 to generate a real fuse blob for the Jetson AGX NVIDIA Orin devkit board:

    $ sudo ./fskp_fuseburn.py -b -f fuse.xml -i 62 –key-exp AK.key EK.key --fskpcfg fskp_conf.txt -g out/ -c 0x23 -B /home/user/Linux_for_Tegra/jetson-agx-orin-devkit.conf --board-spec default_board_spec.txt

Burning Fuses in the Factory

Use the fskp_fuseburn.py fuse burn script to burn fuses in the factory. The script uses tegrarcm_v2 to communicate with the target over USB and sends the blob to the target.

Preparing a System to Burn Fuses

  1. Download the encrypted and signed blob from the secure facility and store it in the <top>/out directory.

  2. Place the target in the USB Recovery mode.

Burning the Fuses

  1. Navigate to the fuseburn scripts directory:

    <top>/l4t/tools/flashtools/fuseburn

  2. Execute the fuseburn command:

    sudo ./fskp_fuseburn.py --board-spec <board_spec> -P ./out -b -c 0x23 -B <board>

    When the command successfully executes, here is the printout for the fskp_fuseburn.py script:

    • On the host:

      FSKP execution successful

    • On the target (Tegra UART output):

      Successfully Burnt Fuses as per fuse inf