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

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

Revision as of 17:01, 19 March 2025

81 bytes removed , Yesterday at 17:01

→‎Example: NVIDIA Jetson

Chidalgo

153

edits

❯

@@ Line 38: / Line 38: @@
 each boot code that is going to be executed 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.
-{{review|ok, we jumped from fuses to Root of Trust. Please, connect the ideas|lleon}}
+As a '''precautionary note''', remember the nature of the fuse devices. '''You have only one chance of writing to these devices, so be careful with the process.''' A mistake in the fuse burning process could lead to an inoperative, unreversible state on the SoC. Also, be careful with the key storage. '''This method relies on how securely the keys are stored'''. If the private keys are lost, signing the boot codes to be authenticated will be almost impossible.
-{{review|use bold letters to emphasise the warnings|lleon}}
+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 disabled 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. Below is a diagram of how the boot codes are authenticated:
-As a '''precautionary note''', remember the nature of the fuse devices. '''You have only one chance of writing to these devices, so be careful with the process.''' A mistake in the fuse burning process could lead to an inoperative, unreversible state on the SoC. Also, be careful with the key storage. '''This method relies on how securely the keys are stored'''. If the private keys are lost, signing the boot codes to be authenticated will be almost impossible.
+[[File:Securebootdiagram.png|450px|thumb|Fig 1. Boot codes structure on NVIDIA Jetson Orin boards]]
-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 disabled 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.
-{{review|a diagram of how to connect Secure Boot and UEFI is compulsory at this point.|lleon}}
 ====UEFI Secure Boot====