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

This verification relies on cryptographic keys that are going to be burned into the system. It is very important to correctly configure Secure Boot with the correct desired keys and ensure that these keys are stored safely. If the configuration is done with an incorrect key, this can lead to failures when using the system, as the expected key differs from the key provided by the image being tested. On the other hand, if Secure Boot is correctly configured but the keys are not stored securely, malicious parties can gain access to the keys, which can lead to the creation of malicious software that is signed with the keys expected by the system. In this case, the secure boot process won't fail, and the system could be tampered with, so it is very important to ensure that only authorized developers can access the keys burned on the system.   

As an example of a Secure Boot implementation we can look at NXP's High Assurance Boot or HAB. As a first step of the implementation, an utility is used to generate private and public keys. The private key is used to an encryption of the image that is being build and as a result of this encryption a unique identifier certificate is obtained and attached to the image along with the public key. The hash of the obtained public key is also burned to chip. This process is illustrated in Figure 1 and the process of obtaining the private key certificate is illustrated in Figure 2.

When an image is loaded into the board, the public key is used to decrypt the certificate. After this, the obtained certificate is compared with the image to ensure that they match. If the match is successful, the image can be trusted can the system will boot as normal, but if a match was not obtained the image is deemed unsafe and the system won't boot. A correct certificate can only be obtained if an user has access to the private key. This process is illustrated in Figure 3.