Secureboot
The NVIDIA® Tegra® Linux Driver Package provides boot security using the Secureboot package. The secure boot 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) stored in write-once-read-multiple fuse devices.
Fuses
Tegra devices contain multiple fuses that control different items for security and boot. Programming a fuse, such as changing the value of a fuse bit from 0 to 1, is non-reversible. Once a fuse bit is programmed (set to 1), you cannot change the fuse value from 1 to 0. For example, a value of 1 (0x01) can be changed to 3 (0x03) or 5 (0x05), but not to 4(0x4) because the 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 Tegra API. However, the odm_reserved and odm_lock fields are still writable (you can change bit 0 to 1).
Although Tegra fuses are writable, you must use the domfuse.sh script to perform the fuse for the following:
• public_key_hash
• secure_boot_key
• odm_production_mode
Note: | Parts with secure fuses programmed are subject to tightened RMA approval since FA cannot be performed. Consequently, you must secure fuse programming to the last step in the manufacturing test flow process. |
Fuses handled by L4T secureboot
The following table shows fuses handled by L4T secureboot:
Bitsize | Name | Default value set by odmfuse.sh |
1 | odm_production_mode | 0x1 |
256 | public_key_hash | RSA Public key HASH |
1 | pkc_disable | PKC - 0x0 NS - 0x0 |
128 | secure_boot_key | Reserved |
32 | device_key | Reserved |
Fuses handled by the user
The following table shows writable fuses:
Bitsize | Name | Default value set by odmfuse.sh |
1 | jtag_disable | 0x1 - disable JTAG |
256 | odm_reserved | Programmable fuses at your discretion. However, 32 MSB is reserved for NVIDIA use. |
4 | odm_lock | Each bit set disables write for corresponding 32 bit odm fuses. For example, 0x2 locks b32-b63 of odm_reserved. |
14 | sec_boot_dev_cfg | Depending on sec_boot_dev_sel, each bit has a different meaning. For more information consult the Jetson TX1 Fuse Programming Guide (DA-08191).. |
8 | sw_reserved | [2-0] sec_boot_dev_sel Valid if ignore_dev_sel_straps is enabled: 0-eMMC 2-SPI [3 ] ignore_dev_sel_straps Ignores boot strap. [4 ] enable_charger_detect [5--] enable_watchdog [7-6] reserved |
Fuse Name Alias for tegraflash
The following table shows fuse name alias recognized by tegraflash:
Name | Tegraflash Alias |
odm_production_mode | SecureMode |
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 |
Overall Fusing and Signing Binaries Process
The following outlines the secure boot process with PKC:
1. Install the L4T secureboot package.
2. If necessary, burn ODM fuses.
3. Generate the RSA key-pair.
4. Burn PKC fuses and set ODM_PRODUCTION_MODE.
5. Sign boot files with PKC.
6. Flash the signed boot files.
Installing Secureboot
This topic provides the steps for installing secureboot.
Prerequisites
• X86 host running Ubuntu 14.04 LTS
• libftdi-dev for USB debug port support
• openssh-server package for OpenSSL
• Full installation of the latest L4T release on the host
• Tegra device is connected to the host with Type-B micro USB cable
• Debug serial port is connected to the host, if necessary
To install secureboot
1. Download partner_supplement.tbz2.
2. Navigate to the path where you installed L4T.
3. Execute the following:
tar xvjf secureboot_<release_version>_<binary_type>.tbz2
Where <release_version> and <binary_type> are identified in the Release Notes.
Generating the RSA Key-pair
This topic describes fuse locking without PKC encryption. L4T secureboot requires 2048 bit RSA key-pair.
To generate a key-pair
1. Execute the following command:
openssl genrsa -out rsa_priv.pem 2048
OpenSSL generates the key file named rsa_priv.pem.
2. Rename and save the key file securely and safely.
The key file is used to burn fuse and sign boot files for Tegra devices. The security of your Tegra device depends on how securely you keep the key file.
3. To ensure the security of the key file, restrict access permission to a minimum number of personnel.
Burning Encryption Key Fuses and Setting ODM_PRODUCTION_MODE
This topic provides the steps for burning encryption key fuses and setting ODM_PRODUCTION_MODE.
1. Navigate to the path to where you installed L4T.
2. Put the Tegra device into Forced Recovery Mode.
3. Burn the fuse using the odmfuse.sh script.
For example:
• To fuse with PKC authentication and JTAG enabled:
sudo ./odmfuse.sh -j -i <chip_id> -c PKC -p -k <keyfile>
• To fuse with PKC authentication and JTAG disabled:
sudo ./odmfuse.sh -i <chip_id> -c PKC -p -k <keyfile>
• To fuse without PKC authentication and JTAG enabled:
sudo ./odmfuse.sh -j -i <chip_id> -c NS -p
• To fuse without PKC authentication and JTAG disabled:
sudo ./odmfuse.sh -i <chip_id> -c NS -p
Note: | Applies to: U-Boot Users: |
• The odmfuse.sh script blocks the JTAG access by default.
• U-Boot initializes the JTAG interface by default; even when the JTAG usage is blocked by not specifying the -j option, and Tegra finds the activity is illegal and quietly halts.
• To enable the U-Boot function properly when the JTAG usage is blocked, rebuild with following workaround applied in the source code:
Extra Options
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 options that blow some ODM fuses are as follows:
Option | Description |
-d 0xXXXX | Sets sec_boot_dev_cfg=<value>&0x3fff. For detail, refer to TRM. |
-j | Sets jtag_disable to 0x0. Unless this option is specified and jtag_disable fuse is set to 0x0, the usage of JTAG debugger is blocked by default. |
-l 0xX | Sets odm_lock=0xX. Setting each bit locks corresponding 32bits in odm_reserved (i.e., setting odmlock=0x1 locks the first 32bit of odm_reserved read only and setting odmlock=0x5 locks the first and third 32bits of odm_reserved field read only and so on). |
-o <value> | Sets odm_reserved=<value>. The value should be quoted series of 8 32bit HEX numbers such as following line: "0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0x00000000" Note the last 32bit HEX number must be 0x00000000 because that fuses are reserved for NVIDIA use. |
-r 0xXX | Sets sw_reserved=0xXX. The name of this fuse field is somewhat confusing but the actual meanings are as follows: bit[7-6] reserved bit[5 ] enable_watchdog bit[4 ] enable_charger_detect bit[3 ] ignore_dev_sel_straps - Ignore "boot strap" bit[2-0] sec_boot_dev_sel - 0:eMMC 2:SPI |
-p | Sets production mode. |
--no-burn | Prepares the fuse blob to be used repeatedly on the factory floor where the private PKC key is not available. This option generates <L4T path>.../Linux_for_Tegra/fuseblob.tbz2 which is downloaded and untarred in <L4T path>.../Linux_for_Tegra directory of a factory host. Once the fuseblob.tbz2 is untarred in Linux_for_Tegra directory, then "fusecmd.sh" in Linux_for_Tegra/booloader directory is used to burn fuses repeatedly instead of the standard "odmfuse.sh". |
Signing Boot Files
The boot file signing process is integrated into the flashing process.
To flash with signed boot file binaries:
1. Navigate to the path to where you installed L4T.
2. Put the Tegra device into Forced Recovery Mode.
• To flash the Tegra device with PKC signed binaries, execute:
sudo ./flash.sh -x <chip_id> -y PKC -u <keyfile> <device_name> mmcblk0p1
• To flash the Tegra device with clear binaries, execute:
sudo ./flash.sh <device_name> mmcblk0p1
Note: | Ensure that you press the RECOVERY and RESET button, and release, even if the Tegra device is still in recovery mode after fusing. |
Secure Factory Support
In general, to ensure a secure factory floor, generate the key pairs at a secure facility and deliver the public key to the factory floor. You are responsible for generating and managing the key for your product.
