Enabling Secure Boot

Table of Contents

• Secure Boot Process
• Signing tool
• Signing steps in an HS-SE device
  • Including the HS SYSFW and Board configuration
  • Signing the SBL
  • Signing the HSM Runtime binary
  • Signing the application image

Secure Boot Process

Secure boot process in a HS (High Secure) device consists of two stages, ROM loading and SBL loading. ROM loading is when the boot ROM loads the HSM runtime binary onto the HSM core, and the signed SBL binary into the primary boot core, which in most cases is an ARM Cortex R5F. SBL loading is when the SBL reads the signed application image from a boot media, authenticates it, decrypts it, and boots it. Here we describe how the secure process takes place in an HS-SE sample device. In a sample HS-SE (Security Enforced) device, the SBL, appimage and the HSM Runtime binary are signed by a dummy key, which would be replaced by a user/customer key when the HS-SE device used is converted from an HS-FS (Field Secure-able) device by user/customer.

In the scope of this release, we do not demonstrate the authentication and decryption of the appimage from SBL, we only show how the ROM loading is done in a Secure device. The SBL loading is done similar to a GP device. This will be changed in an upcoming release.

Signing tool

A script which is dependent on openssl is used to sign binaries in case of HS device. For more details on the usage of the script, see Signing Scripts

Signing steps in an HS-SE device

Including the HS SYSFW and Board configuration

Currently the SYSFW and the board configuration is loaded by the SBL. Because of this dependency, when switching from GP to HS device, the SBL and hence the bootloader library needs to be rebuilt with the DEVICE_TYPE given as "HS" while invoking the make command. For example, do below to rebuild the libraries for HS device

gmake -s libs DEVICE_TYPE=HS

Once the libraries are rebuilt, rebuild the SBL application which you're interested in. Now the SBL would be loading the HS SYSFW and boardcfg instead of the GP ones.

Signing the SBL

The SBL is signed with a dummy MPK in the SDK. This is supposed to be used only with the sample HS-SE devices with the same dummy MPK burnt into the eFUSEes. If the SDK is supposed to be used with a production device with actual customer MPKs burnt into the device, please replace the file at ${SDK_INSTALL_PATH}/tools/boot/signing/custMpk_${SOC}.pem. Whenever any SBL is built, it will be signed with this key, and the signed image generated will have an extension of *.appimage.signed. There is no extra step required other than making sure that the private key used is indeed the one burnt into the eFUSEs.

Signing the HSM Runtime binary

The HSM binary is usually double signed, first with the TI key and then with the customer key. This signing process will be automatically taken care if the customer key is replaced as mentioned in the previous step.

Signing the application image

Current version of SDK doesn't support signing of appimage for secure boot. But for understanding the process, one can refer to https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/secure_boot_signing.html