 |
AM64x MCU+ SDK
10.01.00
|
|
|
AM64x MCU+ SDK
10.01.00
|
|
To put it simply, secure boot refers to booting application images in a secure way. Secure boot is a feature/service available in secure devices.
Out of the device types GP and HS, HS device type can do secure boot. In secure devices there are two subtypes:
HS device type have FS and SE subtypes. Out of the two subtypes, FS and SE, this guide talks about secure boot in an HS-SE device. If the secure device received is an HS-FS subtype, it needs to be converted to an HS-SE variant with the customer keys burnt into the device eFUSEs. This is done using a special piece of software called an OTP keywriter. Keywriter documentation is out of scope for this guide.
Secure boot process, like the normal boot, 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 device.
To make the secure/non-secure differences seamless for the user, a configuration file is provided at ${SDK_INSTALL_PATH}/devconfig/devconfig.mak. In this configuration file, you can set certain options like the device type, keys to be used for signing and encryption etc. By default they will point to the dummy customer MPKs and MEKs but if you're using a production device with your own keys, please change the paths here to point to the right key files. Configuration of this file is currently manual, this will be made configurable by a GUI in an upcoming release.
The devconfig.mak file looks something like this:
This file will be included in all example makefiles
For signing the binaries, two different scripts are used:
Application signing script - This is a python script used for signing the application image. The x509 certificate template used in this script is expected by the HSMRt.
For more details on the usage of the script, see Signing Scripts
In AM64x/AM243x devices, a combined boot method is employed, by virtue of which the SBL, SYSFW and the SYSFW-BoardConfig are combined and signed with the same certificate. This is built into the make system of the SBL applications in the SDK - SBL_UART, SBL_OSPI, SBL_SD, SBL_NULL, etc. So whenever an SBL application is built, the loadable *.tiimage will be a concatenation of the x509 certificate, SBL binary, SYSFW binary and the boardcfg binary blob. In case of HS devices, the SYSFW inner certificate will also be concatenated.
SBL and HSMRt are signed via Root of trust Keys i.e. SMPK (if keyrev = 1) or BMPK (if keyrev = 2). MCU+ SDK is only tested with TI-Dummy Keys. Users are expected to generate their own set of keys and use the same for production. This is supposed to be used only with the devices with the same dummy customer MPK burnt into the eFUSEes. If the SDK is supposed to be used with a production/development device with actual customer MPKs burnt into the device, please replace the file at ${SDK_INSTALL_PATH}/tools/boot/signing/custMpk_${SOC}.pem. This is true for also the encryption key used, which can also be found at ${SDK_INSTALL_PATH}/tools/boot/signing/custMek_${SOC}.txt. Whenever any SBL is built, it will be signed with dummy customer MPK, and the signed image generated will have an extension of *.hs.tiimage.
For more information, please refer to the OTP Keywriter Documentation.
There is no extra step required other than making sure that the MPK used is indeed the one burnt into the eFUSEs.
As mentioned above, since we follow a combined boot method, SYSFW and SBL is signed with the same certificate using the same key. In case of a GP device this will be a degenerate key for easy parsing from ROM. In the case of an HS device, SYSFW will be already signed with TI MPK (and encrypted). This is then countersigned again with dummy customer MPK during the combined image generation process.
Depending on the options given in the device configuration file (devconfig.mak mentioned above), appimage is generated for HS devices. If encryption is enabled in the configuration file, the binary will be first encrypted with the key specified and then the certificate will be generated using the customer MPK specified. If the device type is set as HS in the configuration file, nothing extra needs to be done for the appimage generation. The final *.appimage.hs file generated would be signed with customer MPK (and encrypted with customer MEK if that option is selected).
To dig into the details of the process, one can refer to https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/secure_boot_signing.html
The SBL doesn't have innate abilities to do the image integrity check, or verify the SHA512 of the application image. It relies on SYSFW for this. The image is stored in a readable memory and a pointer to the start of the image is passed to the HSMRt with other details like load address, type of authentication etc.
For more information regarding the authentication request, please refer to http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/security/PROC_BOOT.html#proc-boot-authenticate-image-and-configure-processor
If imported aes key is available at index 32 in keyring, the application images can be encrypted with the following flags using auxiliary keys support:
Here is an example of x509 certificate template for application image encrypted with auxiliary key:
1.8.20