135
edits
Line 35: | Line 35: | ||
====Secure Boot==== | ====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 ([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 burned, cannot be burned a second time. As explained in | 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 burned, cannot be burned a second time. As explained in this [https://developer.ridgerun.com/wiki/index.php/RidgeRun_Platform_Security_Manual/Platform_Security/Root_of_Trust section], the root of trust is the part of the system that is always, across time, immutable and tamper-resistant, so the security process starts from a trusted state. In this case, the root of trust is a code on a on-die BootROM that authenticates | ||
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}} | {{review|ok, we jumped from fuses to Root of Trust. Please, connect the ideas|lleon}} | ||
Line 41: | Line 42: | ||
{{review|use bold letters to emphasise the warnings|lleon}} | {{review|use bold letters to emphasise the warnings|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. | 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. | ||
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. | 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. |
edits