168
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 21:42, 19 March 2025
, 19 March→Example: NVIDIA Jetson
| Line 44: | Line 44: | ||
[[File:Securebootdiagram.png|450px|frame|center|Fig 1. Boot codes structure on NVIDIA Jetson Orin boards]] | [[File:Securebootdiagram.png|450px|frame|center|Fig 1. Boot codes structure on NVIDIA Jetson Orin boards]] | ||
At first, the BootRom code is executed which is the Root of Trust of the NVIDIA Jetson Orin and Xavier systems. This code loads and starts the PSCROM (Platform Security Controller Read Only Memory) code which is the code that authenticates other boot codes before its execution starts. The codes it authenticates are MB1 (Microboot 1) and its MB1 BCT (Microboot 1 Boot Configuration Table), as well as PSCBL1 (Platform Security Controller Bootloader 1). As reference, MB1, initializes certain parts of the SoC, including the CPU, and performs security configuration. PSCBL1 starts MB2 (Microbootloader 2), which is in control of some more firmware initilizations included loading the UEFI Bootloader, that is where secure boot ends and UEFI secure boot starts. | |||
====UEFI Secure Boot==== | ====UEFI Secure Boot==== | ||
UEFI Secure Boot shares the goal with the | UEFI Secure Boot shares the goal with the initial Secure Boot process previously explained, to avoid the execution of untrusted codes. It uses digital signatures to verify that each code it loads is trusted. Specifically it uses two keys and a database to achieve it. A main key that is used on a platform level and in this case, is used to sign an specific key that is going to be used to sign the database. This database holds the keys to sign the codes to be authenticated. These codes are better known as UEFI payloads. In simpler terms: | ||
* Platform Key (PK) : Top-level key, is used to sign KEK. | * Platform Key (PK) : Top-level key, is used to sign KEK. | ||
| Line 66: | Line 66: | ||
* BOOTAA64.efi: Typically used as part of the boot process when the device is trying to boot from removable media like a USB drive or an SD Card | * BOOTAA64.efi: Typically used as part of the boot process when the device is trying to boot from removable media like a USB drive or an SD Card | ||
These are the codes that are authenticated after they are loaded and before their execution. They have to be correctly signed to be executed. Like the general Secure Boot process, the keys must be stored securely. Unlike the general Secure Boot process, the UEFI secure boot authentication is effective unless there is physical access to the SoC to reflash it, with the UEFI secure boot process disabled. As mentioned before, the two boot code authentication methods could be a good combination, rather than two independent ways to secure the SoC. | These are the codes that are authenticated after they are loaded and before their execution. They have to be correctly signed to be executed. Like the general Secure Boot process, the keys must be stored securely. Unlike the general Secure Boot process, the UEFI secure boot authentication is effective unless there is physical access to the SoC to reflash it, with the UEFI secure boot process disabled. As mentioned before, the two boot code authentication methods could be a good combination, rather than two independent ways to secure the SoC. The general secure boot process will autheticate codes up until the UEFI bootloader is executed, and from there, UEFI secure boot will authenticate the payloads before mentioned. | ||
<be> | <be> | ||
=== Example: NXP === | === Example: NXP === | ||