RidgeRun Platform Security Manual/Platform Security/Secure Boot: Difference between revisions

RidgeRun Platform Security Manual/Platform Security/Secure Boot (view source)

Revision as of 19:46, 6 March 2025

224 bytes added , 6 March

→‎Secure Boot

VisualWikitext

Chidalgo

130

edits

❯

@@ Line 37: / Line 37: @@
 ====Secure Boot====
-On NVIDIA Jetson Systems, Secure Boot is activated to block the execution of unauthorized boot codes. Secure Boot process in NVIDIA SoCs, is implemented with Public Key Cryptography (wikipedia link to PKC) where a pair of keys is used, a private and a public one, and the main principle of Public Key Cryptography is that you can generate the public key from the private key pair but not the other way around. This is important to know because the way NVIDIA SoCs implement a secure boot is by storing a public key hash on a device called fuse and signing the boot codes with the private key. The fuse is a device that can only be written once to, and cannot be modified after that. The name comes from the analogy of a real electrical fuse that once is burned, cannot be burned a second time. The Root of Trust (link on this wiki to Root of Trust) authenticates each boot code by generating a public key hash from the private key that the boot codes were signed with, and comparing it to the key hash on the respective fuse.
+On NVIDIA Jetson Systems, Secure Boot is activated to block the execution of unauthorized boot codes. Secure Boot process in NVIDIA SoCs, is implemented with Public Key Cryptography ([https://en.wikipedia.org/wiki/Public-key%20cryptography PKC wikipedia page]) where a pair of keys is used, a private and a public one, and the main principle of Public Key Cryptography is that you can generate the public key from the private key pair but not the other way around. This is important to know because the way NVIDIA SoCs implement a secure boot is by storing a public key hash on a device called fuse and signing the boot codes with the private key. The fuse is a device that can only be written once to, and cannot be modified after that. The name comes from the analogy of a real electrical fuse that once is burned, cannot be burned a second time. The Root of Trust (https://developer.ridgerun.com/wiki/index.php/RidgeRun_Platform_Security_Manual/Platform_Security/Root_of_Trust) authenticates each boot code by generating a public key hash from the private key that the boot codes were signed with, and comparing it to the key hash on the respective fuse.
-Aa a precautionary note, keep in mind the nature of the fuse devices. These are devices that you have only one chance of writing to, so be careful with the process. A mistake on the fuse burning process, could lead to an inoperative unreversible state on the SoC. Also be careful with the keys storage, this method relies on how securely the keys are stored. If the private keys are lost, it will be almost impossible to sign the boot codes to be authenticated.
+As a precautionary note, keep in mind the nature of the fuse devices. These are devices that you have only one chance of writing to, so be careful with the process. A mistake on the fuse burning process, could lead to an inoperative unreversible state on the SoC. Also be careful with the keys storage, this method relies on how securely the keys are stored. If the private keys are lost, it will be almost impossible to sign the boot codes to be authenticated.
-It is important to know that the root-of-trust that uses the NVIDIA SoCs fuses to authenticate boot codes ends at the Bootloader. After this, the current Bootloader (UEFI) will use UEFI’s Security Keys scheme to authenticate its payloads. UEFI Secure Boot process is explained below, but as a point of comparison, it does not use fuse devices. UEFI Secure Boot can be disable by just having physical access to the board and reflashing it. That is a security flaw it has against Secure Boot itself.
+It is important to know that the root-of-trust that uses the NVIDIA SoCs fuses to authenticate boot codes ends at the Bootloader. After this, the current Bootloader (UEFI) will use UEFI’s Security Keys scheme to authenticate its payloads. UEFI Secure Boot process is explained below, but as a point of comparison, it does not use fuse devices. UEFI Secure Boot can be disable by just having physical access to the board and reflashing it. That is a security flaw it has against Secure Boot itself. So they can be viewed as a compliment rather than two different ways of protecting the SoC.
 ====UEFI Secure Boot====