Secureboot
Applies to: Jetson Xavier NX, original Jetson Nano, Jetson AGX Xavier series, Jetson TX2 series, and Jetson TX1 only
NVIDIA® Jetson™ Linux Driver Package (L4T) provides boot security using the Secureboot package. Secureboot prevents execution of unauthorized boot codes through chain of trust. The root-of-trust is on-die bootROM code that authenticates boot codes such as BCT, Bootloader, and warmboot vector using Public Key Cryptography (PKC) keys stored in write-once-read-multiple fuse devices. On Jetson platforms that support Secureboot Key (SBK), you can use it to encrypt Bootloader images.
Fuses and Security
NVIDIA SoCs contain multiple fuses that control different items for security and boot. Once a fuse bit is set to 1, you cannot change its value back to 0. For example, a fuse value of 1 (0x01) can be changed to 3 (0x03) or 5 (0x05), but not to 4 (0x4) because bit 0 is already programmed to 1.
Once odm_production_mode is fused with a value of 0x1, all further fuse write requests are blocked and the fused values are available through the provided API. However, the odm_reserved and odm_lock fields are still writable until odm_lock bit is programmed by changing the value of the bit from 0 to 1.
Although SoC fuses are writable, you must use the odmfuse.sh script to program these fuses: public_key_hash, pkc_disable (T210 only), secure_boot_key, and odm_production_mode.
The following two tables describe user-programmable fuses related to Secureboot.
Secureboot fuses for
Jetson Nano and Jetson TX1 (T210 processor) |
Bit size | Name | Default value set by odmfuse.sh |
1 | odm_production_mode | 0x1 |
256 | public_key_hash | RSA public key hash |
Software and configuration fuses related to Secureboot for
Jetson Xavier NX and Jetson AGX Xavier series (T194)
and Jetson TX2 series (T186) |
Bit size | Name | Default value set by odmfuse.sh |
1 | odm_production_mode | 0x1. |
256 | public_key_hash | RSA public key hash. |
128 | secure_boot_key * | Secureboot Key (SBK): AES encryption key for encrypting bootloader. |
128 | KEK0 * | Four 32‑bit registers named KEK00 through KEK03. |
128 | KEK1 * | Four 32‑bit registers named KEK10 through KEK13. |
256 | KEK256 | Not a distinct fuse; addresses KEK0 and KEK1 as a single 256‑bit fuse. |
128 | KEK2 * | Four 32‑bit registers named KEK20 through KEK23. |
* You may use secure_boot_key or the three Key Encryption Keys with different combinations of width as a key seed to encode keys. For example, KEK2 can be used as a key seed to encrypt and decrypted the Encrypted Key Blob (EKB) when TOS is enabled. |
Fuses that are handled by the user are as follows:
Bit size | Name | Default value set by odmfuse.sh |
1 | jtag_disable | 0x0: JTAG is enabled (the default). 0x1: JTAG is disabled. |
256 | odm_reserved | Programmable fuses at the user’s direction. However, 32 MSB are reserved for NVIDIA use. |
4 | odm_lock | Each bit set disables the write for the corresponding 32-bit ODM fuses. For example: 0x2 locks bits 32−63 of odm_reserved. |
14 | sec_boot_dev_cfg | Depending on sec_boot_dev_sel, each bit has a different meaning. |
8 | sw_reserved | A bit map of configuration options. Bits not described here are reserved. Bits 2-0: sec_boot_dev_sel. Meaningful only if ignore_dev_sel_straps is enabled: 0=eMMC, 1=SPI. Bit 3: ignore_dev_sel_straps. 1=Ignore device selection boot strap. Bit 5: enable_watchdog. Bit 23: 1=disable RCM mode (T194 only). |
For details on hardware fuses and fuse names, consult the following documents:
• For NVIDIA Jetson™ Nano and Jetson TX1: NVIDIA Jetson TX1 Fuse Specification Application Note
The following two tables describe the fuse name aliases recognized by tegraflash.
Fuse Name Aliases Recognized by tegraflash for T210 |
|---|
Name | tegraflash Alias & Notes |
|---|
odm_production_mode | SecurityMode |
public_key_hash | PublicKeyHash |
pkc_disable | PkcDisable |
secure_boot_key | SecureBootKey |
device_key | DeviceKey |
jtag_disable | JtagDisable |
odm_reserved | ReservedOdm |
odm_lock | OdmLock |
sec_boot_dev_cfg | SecBootDeviceSelect |
sw_reserved | SwReserved |
Fuse Name Aliases Recognized by tegraflash for T186 and T194 |
|---|
Name | tegraflash Alias & Notes |
|---|
odm_production_mode | SecurityMode |
public_key_hash | PublicKeyHash |
secure_boot_key | SecureBootKey |
Security_info | BootSecurityInfo |
Key_encryption_key_0 | Kek0 |
Key_encryption_key_1 | Kek1 |
Key_encryption_key_256 | Kek256 |
Key_encryption_key_2 | Kek2 |
jtag_disable | JtagDisable |
odm_reserved0, odm_reserved1,… odm_reserved7 | ReservedOdm0, ReservedOdm1,… ReservedOdm7 Customer programmable fuses; remain programmable after FUSE_SECURITY_MODE has been programmed. Default value (when no Reserved ODM fuses have been programmed) is all zeros. One intended application of these fuses is software version revocation. You may use them for other purposes at your discretion. |
odm_reserved8,… odm_reserved11 | ReservedOdm8,… ReservedOdm11 (T194 only) Reserved for use by NVIDIA. Do not use these fuses. Customer programming of these can result in boot failures and unexpected behavior. |
odm_lock | OdmLock Each bit disables further changes to one of the ReservedOdm fuses. Only the first four ReservedOdm fuses can be disabled by this means. • OdmLock[0] disables ReservedOdm0 • OdmLock[1] disables ReservedOdm1 • OdmLock[2] disables ReservedOdm2 • OdmLock[3] disables ReservedOdm3 |
sec_boot_dev_cfg | SecBootDeviceSelect |
sw_reserved | SwReserved |
Overall Fusing and Signing Binaries
The Secureboot process with PKC (and SBK) requires:
• Install the Secureboot package.
• If necessary, prepare the DK(KEK), SBK, and ODM fuse values.
• Generate the RSA key-pair.
• Burn DK(KEK), ODM fuses, the PKC/SBK, Security Info, and odm_production_mode fuses.
• Sign the boot image files with PKC (and SBK).
• Flash the signed boot image files.
Note: | The odm_production_mode fuse is burned to protect the SoC device from erroneous ODM production fuse burning. ODM_RESERVED and ODM_LOCK fuses are still writable until the ODM_LOCK bit is burned. |
Installing the Secureboot Package
Prerequisites
• X86 host running Ubuntu 16.04 or 18.04 LTS
• libftdi-dev for USB debug port support
• openssh-server package for OpenSSL
• Full installation of the latest L4T release on the host
Download the latest release at:
https://developer.nvidia.com/embedded/linux-tegra-archive
• The NVIDIA® Jetson™ platform is connected to the host with a USB cable
• Debug serial port is connected to the host, if necessary
To install Secureboot
1. Download the latest Secureboot package for your platform from the
Jetson Download Center. Search the database of downloads for “secure boot.”
2. Go to the directory that contains the Linux_for_Tegra directory. (This directory is created when the Jetson Board Support Package is installed.)
3. Enter this command to untar the downloaded file:
tar xvjf secureboot_<release_version>.tbz2
This command overlays the contents of the file on the Linux_for_Tegra directory.
Generating the RSA Key Pair
Secureboot requires a 2048-bit RSA key-pair.
To generate a key-pair
1. Execute the command:
$ openssl genrsa -out rsa_priv.pem 2048
Upon successful execution, OpenSSL generates the key file named rsa_priv.pem file.
2. Rename and save the key file securely and safely.
The key file is used to burn fuse and sign boot files for Jetson devices. The security of your device depends on how securely you keep the key file.
To ensure the security of the key file, restrict access permission to a minimum number of personnel.
Note: | To generate a truly random number key, use the Hardware Security Module (HSM). Consult the Hardware Security Module User Guide for output format and private key conversion to PEM format. |
Preparing the SBK Key
Applies to: Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series
If you want to encrypt Bootloader (and TOS), you must prepare the SBK fuse bits.
Note: | You must use the SBK key along with the PKC key. |
The SBK key consists of four 32-bit words stored in a file in big-endian hexadecimal format. Here is an example of an SBK key file:
0x12345678 0x9abcdef0 0xfedcba98 0x76543210
The representation in the fusing XML file is:
0x123456789abcdef0fedcba9876543210
Preparing the User Key
Applies to: Jetson Xavier NX, Jetson AGX Xavier series
If you want to encrypt kernel image files (for the kernel, kernel-dtb, and initrd), you must prepare the user key. You need the user key as well as the SBK key and the PKC key.
The user key is stored in the Encrypted keyblob (EKB) in encrypted form. The Secure Engine (SE) retrieves the user key from the EKB and uses it to decrypt the kernel image files.
For information about how the EKB is generated, see
EKB Generation in the topic
Security.
You must use the same user key in flash.sh to encrypt kernel images. That script flashes the EKB to the target along with the encrypted kernel images. The EKB is flashed to the EKS partition.
The user key must be specified in two different formats for different purposes:
• For use in the ‑‑user_key switch of the flash.sh command, it is a file containing four big-endian 32‑bit words stored as four 8‑digit hexadecimal numbers. (The ‑‑user_key switch specifies the pathname of this file.) Here is an example of a user key in this format:
0x12345678 0x9abcdef0 0xffeeddcc 0xbbaa9988
• For use in generating the EKB, it is a file containing 32 hexadecimal digits that represent the same key, interpreted as a single big-endian 128‑bit value. Here is an example:
123456789abcdef0ffeeddccbbaa9988
Preparing the DK(KEK)/ODM Fuses
If you want to use another security application, you must prepare the DK(KEK) and other ODM fuse bits as described in the documentation for the other security application.
Name | Description |
|---|
DK | A 32-bit number stored in a file in big-endian HEX format. Applies to: Jetson Nano and Jetson TX1 Example: 0xddccbbaa |
KEK0 KEK1 KEK2 | A 128-bit number stored in a file in big-endian HEX format. Applies to: Jetson Xavier NX, Jetson AX Xavier, and Jetson TX2 |
KEK256 | A 256-bit number stored in a file in big-endian HEX format. Applies to: Jetson Xavier NX, Jetson AX Xavier, and Jetson TX2 |
ODM Fuse Bits | To use applications other than Secureboot, additional ODM fuse bits may be required. The specific fuse information differs depending on the application being used. Consult the user guide for the application being used. |
Note: | Hexadecimal numbers must be presented in big-endian format. The leading 0x or 0X may be omitted. The Jetson Secureboot software converts big-endian hexadecimal format to the format that the Jetson device expects. All standard OpenSSL utilities output in big-endian format. |
Burning PKC [DK(KEK), SBK] Fuses
The steps for burning PKC, DK, and SBK fuses using a private key file PEM format are as follows.
To burn PKC fuses
1. Navigate to the directory where you installed L4T.
2. Put the Jetson device into Forced Recovery Mode.
odmfuse.sh Switches
For odmfuse.sh, other than PKC key and odm_production_mode fuses, odmfuse.sh allows you to program ODM fuses that are completely under your discretion. Skip this topic if you do not plan to modify these fuses.
The odmfuse.sh command line switches that blow some ODM fuses are as follows:
Switch | Description |
-d 0xXXXX | Sets sec_boot_dev_cfg=<value>&0x3fff. For detail, refer to TRM. |
-disable-jtag | Disables JTAG. Use this switch to block use of the JTAG debugger. |
-l 0xX | Sets odm_lock to the specified value. Setting each bit locks (makes read-only) the corresponding 32‑bit word in the odm_reserved field. For example, setting odm_lock to 0x1 locks the first 32‑bit word of odm_reserved. Setting odm_lock to 0x5 locks the first and third 32‑bit words of odm_reserved, and so on. |
-o <value> Applies to: Jetson Nano devices and Jetson TX1 only | Sets odm_reserved to the specified value. The value must be a quoted 256‑bit (64‑digit) hexadecimal number in the form "0xnnnn… nnnn". The last 32 bits (eight digits) must be all zero because these bits are reserved for use by NVIDIA. |
--odm_reserved[0–7] Applies to: Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series only | Sets odm_reserved[n] to the specified value. The value must be a quoted 32‑bit (eight-digit) hexadecimal number in the form 0xnnnnnnnn. |
-p | Sets production mode. |
-r 0xXX | Sets sw_reserved=0xXX. The bit definitions are: Bits 7-6: Reserved. Bit 5: Enable_watchdog. Bit 4: Reserved. Bit 3: ignore_dev_sel_straps: Ignore device selection boot strap. Bits 2-0: sec_boot_dev_sel: Boot device: 0=eMMC, 1=SPI. |
-D <DK_file> Applies to: Jetson Nano series and Jetson TX1 | Sets the Device Key to be used by the high-level security application to generate the application encryption keys. The content of <DK_file> must be a single 32-bit big endian HASH in HEX format. |
-S <SBK_file> | Sets the Secureboot Key used to encrypt Bootloader and TOS. The content of <SBK_file> must be four 32‑bit big-endian numbers in hexadecimal format. For Jetson Xavier NX, Jetson AGX Xavier and Jetson TX2, this key must be used along with PKC key. For Jetson TX1 and Jetson Nano, this key must be used along with PKC key and pkc_disable = 0. This key will not be used to encrypt Bootloaders, it can be used by the high-level application as encryption key. |
--noburn | Prepares the fuse blob to be used repeatedly on the factory floor. This switch generates Linux_for_Tegra/fuseblob.tbz2, which can be downloaded and untarred in the Linux_for_Tegra directory of a factory host. After fuseblob.tbz2 is untarred in the Linux_for_Tegra directory, Linux_for_Tegra/bootloader/fusecmd.sh is used to burn fuses repeatedly instead of the standard odmfuse.sh. |
--KEK0 --KEK1 --KEK2 <path> Applies to: Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series | Pathname of the Key Encryption Key file that other security applications are to use to encrypt/decrypt keys. The content of the file must be a single 128-bit big-endian number in hexadecimal format. |
--KEK256 <path> Applies to: Jetson Xavier NX, Jetson AGX Xavier series, Jetson TX2 series | Pathname of the 256-bit Key Encryption Key file that the high-level security application will use to encrypt the application keys. The content of the file must be a single 256-bit big-endian number in hexadecimal format. |
--auth Applies to: Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series | Sets the authentication status of the board. Possible values are: NS (Non-Secure), PKC, and SBKPKC. Use this switch only when running odmfuse.sh in with no boards connected (i.e. in offline mode). To run odmfuse.sh in offline mode: 1. Use --noburn on the command line. 2. Specify the carrier board by setting these environment variables on the command line. You can get the appropriate values from the Jetson module’s EEPROM as described in the topic Jetson Module EEPROM Layout. • BOARDID: Use the value of the “Board number” field. • FAB: Use the value of the “FAB number” field. • BOARDSKU: Use the value of the “SKU number” field. • BOARDREV: Use the values of the “major revision” and “minor revision” fields, separated by a period. For example: sudo FAB=400 BOARDID=2888 BOARDSKU=0006 BOARDREV=B.0 ./odmfuse.sh --noburn -i 0x19 -p -k <pkc> --KEK2 <kek2> -S <sbk> jetson-xavier-8gb |
--test | Prevents the script from actually burning fuses. Pre-burn processing and tests are performed as usual. This switch is normally used for fuse burning tests, since fuse values cannot be changed once they are burned. |
Non-Destructive Testing for Fuse Burning Operations
Fuse burning operations are high-risk because they can’t be reversed. NVIDIA strongly recommends that you use the ‑‑test switch to verify fuse burning operations before you perform them.
When you add ‑‑test to an odmfuse.sh command, the command performs pre-burn processing and verification, but does not actually burn the fuse. If the command reports the results you want, you can re-enter the command without ‑‑test and burn the fuse with greater confidence that you are doing it correctly.
odmfuse.sh Switch Examples
• To burn a secure fuse with PKC only (Jetson Nano devices and Jetson TX1 only):
sudo ./odmfuse.sh -i <chip_id> -c PKC -k <PKC file>
• To fuse PKC HASH from the .pem file with JTAG enabled:
For Jetson Nano devices and Jetson TX1:
$ sudo ./odmfuse.sh -i <chip_id> -c PKC -p -k <key.pem> [-D <DK_file>]
For Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series:
$ sudo ./odmfuse.sh -i <chip_id> -p -k <key.pem> --KEK[0-2] <KEK file> -S <SBK_file> > <device_name>
• To fuse PKC HASH from the .pem file with JTAG disabled:
For Jetson Nano devices and Jetson TX1:
$ sudo ./odmfuse.sh -i <chip_id> -c PKC -p -k <key.pem> [-D <DK_file>] --disable-jtag
For Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series:
$ sudo ./odmfuse.sh -i <chip_id> -p -k <key.pem> --KEK[0-2] <KEK file> -S <SBK_file> --disable-jtag <device_name>
• To burn a secure fuse with PKC, SBK, and KEK2 (Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series only):
sudo ./odmfuse.sh -i <chip_id> -k <PKC file> -S <SBK file> --KEK2 <KEK2 file> <device_name>
• To burn a secure fuse with PKC and KEK2 (Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series only):
sudo ./odmfuse.sh -i <chip_id> -k <PKC file> --KEK2 <KEK2 file> <device_name>
• To burn a secure fuse with PKC and encryption service preparation (Jetson Nano devices and Jetson TX1 only):
sudo ./odmfuse.sh -i <chip_id> -c PKC -k <PKC file> -D <DK_file>
• To protect ODM production fuse with JTAG enabled (T210 only):
$ sudo ./odmfuse.sh -i <chip_id> -c NS -p
• To protect ODM production fuse with JTAG disabled (T210 only):
$ sudo ./odmfuse.sh –disable-jtag -i <chip_id> -c NS -p
Where:
• <chip_id> is:
• For Jetson Xavier NX: 0x19
• For Jetson Nano (production module only): 0x21
• For Jetson Nano (4 GB development module only): 0x21
• For Jetson AGX Xavier series: 0x19
• For Jetson TX2 series: 0x18
• For Jetson TX1: 0x21
• <device_name> is the device name of the Jetson platform you are using, as shown in the
table of device names in the topic
Quick Start Guide. This placeholder is not used for Jetson Nano devices or Jetson TX1.
• For Jetson Xavier NX: jetson-xavier-nx-devkit-emmc
• For Jetson AGX Xavier series: jetson-agx-xavier-devkit
• For Jetson TX2 series: jetson-tx2-devkit
Signing and Flashing Boot Files
You can use the following procedures to sign and flash boot files:
• In one step, using PKC-key only or zero-key signing (signing with a key file that is all 0’s)
• In one step, using both SBK and PKC key signing
• In separate steps
Note: | If no key file is specified, the flashing utility uses zero-key signing. |
To sign and flash in one step using PKC-key or zero-key signing
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter one of these commands:
• To flash the Jetson device with PKC signed binaries:
$ sudo ./flash.sh -u <keyfile> <device_name> mmcblk0p1
• To flash the Jetson device with zero-key signed binaries:
$ sudo ./flash.sh <device_name> mmcblk0p1
Where:
• <keyfile> is an RSA 2k key file.
To sign and flash in one step using SBK and PKC keys
Applies to: Jetson TX2 series
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter the command:
$ sudo ./flash.sh -u <pkc_keyfile> -v <sbk_keyfile> jetson-tx2 mmcblk0p1Where:
• <pkc_keyfile> is an RSA 2K key file.
• <sbk_keyfile> is an SBK key file.
Note: | Neither the PKC key file nor the SBK key file may be placed under the bootloader directory. |
To sign and flash in one step using the user, SBK, and PKC keys
Applies to: Jetson NX and Jetson Xavier series
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter this command:
$ sudo ./flash.sh -u <pkc_keyfile> -v <sbk_keyfile> --user_key <user_keyfile> jetson-xavier mmcblk0p1
Where:
• <pkc_keyfile> is an RSA 2K key file.
• <sbk_keyfile> is an SBK key file.
• <user_keyfile> is a User key file.
To sign and flash in separate steps
1. Sign the boot files.
• Using PKC-key or zero-key signing:
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter one of the commands:
For PKC-key signing (Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series only):
$ sudo ./flash.sh –-no-flash -u <keyfile> <device_name> mmcblk0p1
For zero-key signing:
$ sudo ./flash.sh –-no-flash <device_name> mmcblk0p1
For Jetson Nano (production module) and Jetson TX1:
$ sudo ./flash.sh --no-flash -x 0x21 -y PKC -u <keyfile> <device_name> mmcblk0p1
Where:
• <keyfile> is an RSA 2k key file
• Using SBK and PKC-key signing:
Applies to: Jetson TX2 series
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter the command:
$ sudo./flash.sh –-no-flash -u <pkc_keyfile> -v <sbk_keyfile> jetson-tx2 mmcblk0p1
Where:
• <pkc_keyfile> is an RSA 2K key file.
• <sbk_keyfile> is an SBK key file.
Note: | Neither the PKC key file nor the SBK key file may be placed under the Bootloader directory. |
• Using user, SBK, and PKC-key signing:
Applies to: Jetson Xavier NX and Jetson AGX Xavier series
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter the command:
$ sudo BOARDID=2888 FAB=400 BOARDSKU=0001 BOARDREV=H.0./flash.sh –-no-flash -u <pkc_keyfile> -v <sbk_keyfile> --user_key <user_keyfile> jetson-xavier mmcblk0p1
Where:
• <pkc_keyfile> is an RSA 2K key file.
• <sbk_keyfile> is an SBK key file.
• <user_keyfile> is a user key file.
Note: | None of the PKC key file, SBK key file, and user key file may be placed under the Bootloader directory. |
2. Flash:
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter the commands:
$ cd bootloader
$ sudo bash ./flashcmd.txt
Note: | Be sure to press and reset the recovery button even if the Jetson device is still in recovery mode after fusing. |
To sign and flash from NFS using PKC-key or zero-key signing or both PKC-key and SBK-key
1. Set up an NFS with flashing capability.
4. Navigate to the directory where you installed L4T.
5. Place the Jetson device into Force Recovery mode.
6. Enter the command:
$ sudo ./tools/kernel_flash/l4t_create_flash_image_in_nfs.sh -N <IPaddr>:<nfsroot> -u <pkc_keyfile> [-v <sbk_keyfile>] <board_name> <rootdev>
Where:
• <IPaddr> is the IP address of the NFS root that the target is to use to boot.
• <nfsroot> is the pathname of the NFS root.
• <pkc_keyfile> is a PKC key file.
• <sbk_keyfile> is an SBK key file.
• <rootdev> specifies the device on which the root file system is located, as described in the topic
Basic Flash Script Usage.
2. Copy the flash package into the NFS root filesystem. (The flash package is a tarball that contains all of the files that the target needs to flash from RCM boot to NFS. See the section
Flashing from NFS in the topic
Flashing and Booting the Target Device for more information.)
3. RCM boot the target to NFS.
4. Enter this command on the target's console to flash the target device:
$ sudo /images_to_flash/<board_name>/l4t_flash_from_nfs.sh
Where
<board_name> is the same as in step
1,
above.
Accessing the Fuse from the Target
The Jetson Secureboot package provides means to access fuses from the target board after it boots up.
To access the fuse from the target board
1. Copy the <top>.../Linux_for_Tegra/pkc/tegrafuse.sh script to the ubuntu@<target IP address>.
2. To access the target’s fuses from the target board, login to the target board. To display all fuses, enter the command:
$ sudo ./tegrafuse.sh
To access the fuse from the target board via force recovery mode
Applies to: Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series only
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter the command:
$ sudo ./odmfuseread.sh -i <0x18 or 0x19> [-k <PKC_file>] [-S <SBK_file>] <device_name>
Fusing to Multiple Jetson Devices
NVIDIA provides a tool and instructions for fusing Jetson devices efficiently in a factory environment. This tool is part of the Secureboot package, and is available in the Linux_for_Tegra folder. Instructions for using the tool are in README_Massfuse.txt, located in the same folder.
Building and Flashing a Factory-Signed Firmware Blob
L4T provides two example implementations for flashing factory-signed firmware in a factory environment.
To building the firmware blob in a trusted environment
• See “Building the Massflash Blob in Trusted Environment” in Linux_for_Tegra/README_Massflash.txt.
To flash the firmware blob in a factory environment
• See “Flashing the Massflash Blob in Untrusted Environment” in Linux_for_Tegra/README_Massflash.txt.
Signing and Encrypting Kernel, Kernel-DTB, and Initrd Binary Files
Applies to: Jetson Xavier NX and Jetson AGX Xavier series
To support Secureboot, kernel, kernel-dtb and initrd binary files must be encrypted and signed with keys to generate encrypted binary files and signature files.
The RSA key pair file (<keyfile> in the script command below) is used to generate a signature file for authenticating a binary file.
A 128-bit key (<encrypt_keyfile> in the script command below) is used to encrypt a binary file.
To sign kernel, kernel-dtb, and initrd files
1. Navigate to the Linux_for_Tegra/ directory on the host system,
2. Enter this command:
$ ./l4t_sign_image.sh --file <binary_file> --chip 0x19 --key <keyfile>] --encrypt_key <encrypt_keyfile>
Where:
• <binary_file> is a kernel, kernel-dtb, or initrd binary file to be signed.
The script replaces this file, so save a copy of the old file before you run the script.
The script stores a signature file named <binary_file>.sig in the directory that contains <binary_file>.
For details about the use of signature files to authenticate a kernel, kernel-dtb, or initrd binary file, see the section Kernel Boot Sequence Using extlinux.conf in topic Jetson Xavier NX and Jetson AGX Xavier Series Boot Flow.
• <keyfile> is an RSA key pair file (a .pem file). It provides values to fill key fields in the signature file. If the key switch is not specified, key fields are filled with 0’s.
• <encrypt_keyfile> is the pathname to a file that contains four 32-bit big-endian numbers in hexadecimal format. It is the same file as the <user_keyfile> used to flash the target, and contains the same key as that used to generate the EKB.