157
edits
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
, 19 March→Example: NVIDIA Jetson
| Line 42: | Line 42: | ||
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: | 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: | ||
[[File:Securebootdiagram.png| | [[File:Securebootdiagram.png|650px|frame|Fig 1. Boot codes structure on NVIDIA Jetson Orin boards]] | ||