 |
AM263x MCU+ SDK
09.02.00
|
|
|
AM263x MCU+ SDK
09.02.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.
In secure device types (HS) 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.
The keyring is a set of keys which can be imported by SBL after importing the HSM runtime binary on an HS-SE device. For importing keyring TIFS-MCU expects an X.509 certificate signed by customer active root of trust (MPK). For certificate generation script usage, see Keyring Cert Generation Python Script.
TIFS-MCU supports application authentication using the following algorithms with Keyring.
| Signature Algorithm | Supported Keys | Hash Function |
|---|---|---|
| RSA-PKCS#1 v1.5 | RSA2k, RSA3k, RSA4k | SHA256, SHA384, SHA512 |
| RSASSA-PSS | RSA2k, RSA3k, RSA4k | SHA256, SHA384, SHA512 |
| ECDSA | P-256, P-384, P-521, BrainpoolP512t1 | SHA256, SHA384, SHA512 |
For more information, please refer TIFS-MCU documentation
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
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.
It is recommended to pass a key derivation salt for requesting ROM to not use the Customer MEK directly but generate a derived key to decrypt the SBL/HSMRt images. ROM uses HKDF (HMAC based Key Derivation Function) to derive a key from the S(B)MEK. The Key Derivation Function requires a salt which is a non-secret random value which it uses in a 2 step HKDF-Extract and HKDF-Expand process. For more information, please refer to RFC-5869. With the signing scripts provided as part of MCU+ SDK, this can be done by passing argument kdsalt to the signing script and has been integrated as the default option in the makefiles for SBL.
The salt is supplied to the makefiles via the file tools/boot/signing/kd_salt.txt.
Here is an example certificate for SBL that takes care of the above recommendation:
Note that the salt in encryption extension and key_derivation extension is same. This is designed so that the same derived key can be used for encrypting application images. For more information on the different extensions supported by ROM, please see Signing Scripts.
To build SBL image with certificate for HS-SE devices, one can use the following command:
This will add the appropriate extensions as part of the X509 certificate and will encrypt the image with Customer MEK as well.
ENC_SBL_ENABLED flag in devconfig file (which is set as yes).Keyring can be imported in SBL by using keyring import module in sysconfig.
The sysconfig module auto-generates APIs for keyring import and builds SBL along with keyring certificate. For certificate generation script usage, see Keyring Cert Generation Python Script.
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).
The SBL doesn't have innate abilities to do the image integrity check, or verify the hash of the application image. It relies on HSMRt 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.
Here is an example of x509 certificate template for application images:
The application images can be built with the following flags for appending the X509 certificate for HS-SE devices:
The RSASSA-PSS algorithm can be used instead of the default RSA PKCS#1v1.5 signature algorithm by specifying RSASSAPSS_ENABLED=yes and APP_SIGNING_SALT_LENGTH. Maximum supported salt length value for RSASSA-PSS is 255.
See the command below for reference.
${SDK_INSTALL_PATH}/tools/keyring_cert/aux_keys. The auxiliary keys in the keyring begin at index 32. If the application binary is signed with an auxiliary private key, the corresponding public key hash of which is available in the keyring, the customer must specify the keyring index corresponding to the auxiliary key used for authentication.
If imported public key is available at index 38 in keyring for brainpoolp512r1_private.pem, the application images can be built with the following flags for appending the X509 certificate for HS-SE devices:
Here is an example of x509 certificate template for application images:
Optionally, one can encrypt the application image to meet security goals. This can be accomplished with adding one more flag ENC_ENABLED with the make command:
Here is an example x509 configuration template with apllication authentication and encryption support:
ENC_ENABLED option in the devconfig.mak. But this is not possible when you load the image using SBL QSPI. This is due to the fact that HSM does an in-place authentication and decryption of the image and we load the image directly from the FLASH memory in case of SBL QSPI. FLASH memory, as you would know is most often not directly writable. Due to this limitation not being taken care in the HSM, we can do decryption of images only in the case where the image resides in a volatile RAM-like memory like OCRAM. 
1.8.20