174
edits
RidgeRun Platform Security Manual/Getting Started/Secure Boot: Difference between revisions
RidgeRun Platform Security Manual/Getting Started/Secure Boot (view source)
Revision as of 18:16, 21 March 2025
, 21 March→Secure Boot
| Line 14: | Line 14: | ||
Secure Boot on an NVIDIA Jetson system is activated to block the execution of code coming from untrusted sources. To achieve it, NVIDIA Jetson SoCs use [https://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography] and the Root of Trust. The private key is used to sign the codes that are going to be executed when the board is initially booting and the public key is going to be stored in devices called fuses inside the board. To begin the booting process on an NVIDIA Jetson Xavier/Orin board, first a BootROM code is executed, which is the first element of the [https://developer.ridgerun.com/wiki/index.php/RidgeRun_Platform_Security_Manual/Platform_Security/Root_of_Trust Root of Trust] for these systems. It loads and autheticates the first codes that are going to be executed in the booting process. It authenticates by generating a public key hash from the private key digital signature embedded in each code, and compares it to the public key hash stored in the devices called fuses. If the keys match, the code comes from a trusted source and can be executed, otherwise it is not and the booting process is halted. So then, to activate a secure boot on an NVIDIA Jetson SoC, it is necessary to generate a PKC (Public Key Cryptography) key pair, store the public key hash on the fuses and sign the boot codes with the corresponding private key. As a relevant note, '''a fuse device can only be written once to''', so it is important to do it right. Check out the [[https://developer.ridgerun.com/wiki/index.php/RidgeRun_Platform_Security_Manual/Platform_Security/Secure_Boot Secure boot]] general page in this wiki for more information. In this guide we are going to take a look at how to activate this feature on a Jetson Orin Nano. Below is a general diagram of the process: | Secure Boot on an NVIDIA Jetson system is activated to block the execution of code coming from untrusted sources. To achieve it, NVIDIA Jetson SoCs use [https://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography] and the Root of Trust. The private key is used to sign the codes that are going to be executed when the board is initially booting and the public key is going to be stored in devices called fuses inside the board. To begin the booting process on an NVIDIA Jetson Xavier/Orin board, first a BootROM code is executed, which is the first element of the [https://developer.ridgerun.com/wiki/index.php/RidgeRun_Platform_Security_Manual/Platform_Security/Root_of_Trust Root of Trust] for these systems. It loads and autheticates the first codes that are going to be executed in the booting process. It authenticates by generating a public key hash from the private key digital signature embedded in each code, and compares it to the public key hash stored in the devices called fuses. If the keys match, the code comes from a trusted source and can be executed, otherwise it is not and the booting process is halted. So then, to activate a secure boot on an NVIDIA Jetson SoC, it is necessary to generate a PKC (Public Key Cryptography) key pair, store the public key hash on the fuses and sign the boot codes with the corresponding private key. As a relevant note, '''a fuse device can only be written once to''', so it is important to do it right. Check out the [[https://developer.ridgerun.com/wiki/index.php/RidgeRun_Platform_Security_Manual/Platform_Security/Secure_Boot Secure boot]] general page in this wiki for more information. In this guide we are going to take a look at how to activate this feature on a Jetson Orin Nano. Below is a general diagram of the process: | ||
* This guide was tested using a Jetson Orin Nano Developer Kit, but with slight modifications, can be applied to Jetson Orin NX series, Jetson AGX Orin | * This guide was tested using a Jetson Orin Nano Developer Kit, but with slight modifications, can be applied to Jetson Orin NX series, Jetson AGX Orin series. Specifically, the commands for generating the fuse blob are platform dependent, as well as flash commands. | ||
* This guide was tested using Ubuntu 20.04 LTS on the host(laptop where JetPack is installed used to flash the NVIDIA Jetson Orin/Xavier board). | * This guide was tested using Ubuntu 20.04 LTS on the host(laptop where JetPack is installed used to flash the NVIDIA Jetson Orin/Xavier board). | ||
====Factory Secure Key and Expansion Key Provisioning==== | ====Factory Secure Key and Expansion Key Provisioning==== | ||
| Line 61: | Line 59: | ||
* key oem_rsa_priv.pem: Specifies the private key file to use for signing the certificate. | * key oem_rsa_priv.pem: Specifies the private key file to use for signing the certificate. | ||
* out oem_publickey.cer: Specifies the output file name for the generated certificate. The certificate will be saved to a file named oem_publickey.cer. Although the extension is ".cer" which is common, the -outform PEM option means the file will contain PEM encoded data. | * out oem_publickey.cer: Specifies the output file name for the generated certificate. The certificate will be saved to a file named oem_publickey.cer. Although the extension is ".cer" which is common, the -outform PEM option means the file will contain PEM encoded data. | ||
* days 365: Specifies the validity period of the certificate in days. This value should be set accordingly to the security policies of the OEM. | * days 365: Specifies the validity period of the certificate in days. This value should be set accordingly to the security policies of the OEM. It is also worth noting that this key is only used to encrypt and decrypt the fskp keys. After this, it won't be used anymore so a relatively low time for the certificate should work, but it is up to every OEM neccesities. | ||
* These configuration is the recommended by NVIDIA on its documentation, a self signed certificate and the PEM format works for this case because the OEM is the one creating the private and the PEM format is fit to send via email. | |||
The output is going to ask you for the passphrase to read the private key and generate the certificate. It is going to also ask for information about your organization to add on the certificate: | The output is going to ask you for the passphrase to read the private key and generate the certificate. It is going to also ask for information about your organization to add on the certificate: | ||
| Line 600: | Line 595: | ||
* db_2.crt: This is the input file, which is the X.509 certificate that you want to convert. | * db_2.crt: This is the input file, which is the X.509 certificate that you want to convert. | ||
* db_2.esl: This is the output file, which will be the EFI signature list. The .esl extension is commonly used for EFI signature lists. | * db_2.esl: This is the output file, which will be the EFI signature list. The .esl extension is commonly used for EFI signature lists. | ||
'''NOTE:''' The generated .crt files are self-signed certificates and are used for demonstration purposes only. For production, follow your official certificate generation procedure. | |||
Output should look like the following: | Output should look like the following: | ||