Signing Scripts

To run these scripts, one needs openssl installed as mentioned here, OpenSSL
Signing scripts are a collection of scripts needed to sign ROM images (image booted by ROM - mostly the SBL) and application images (image booted by the SBL)
The RBL requires the boot image (mostly SBL), to be signed always, even if we are not using secure boot.
We follow a combined boot method for ROM images. Here the ROM Bootloader (RBL) boots the SBL, SYSFW and BOARDCFG together. The boot image would be a binary concatenation of x509 Certificate, SBL, SYSFW, BOARDCFG (and the SYSFW inner certificate in case of HS device) binary blobs. We use a python script to generate this final boot image. This script has a dependency on openssl as mentioned before, so make sure you've installed it. To generate a combined boot image, one can do as below:
For GP devices
cd ${SDK_INSTALL_PATH}/source/security/security_common/tools/boot/signing

${PYTHON} rom_image_gen.py --swrv 1 --sbl-bin <path-to-sbl-binary> --sysfw-bin <path-to-sysfw-binary> --boardcfg-blob <path-to-boardcfg-binary-blob> --sbl-loadaddr ${SBL_RUN_ADDRESS} --sysfw-loadaddr ${SYSFW_LOAD_ADDR} --bcfg-loadaddr ${BOARDCFG_LOAD_ADDR} --key ${BOOTIMAGE_CERT_KEY} --rom-image <path-to-output-image>
For HS devices, we have to pass the HS SYSFW binaries and also the SYSFW inner certificate to the signing script.
cd ${SDK_INSTALL_PATH}/source/security/security_common/tools/boot/signing

${PYTHON} rom_image_gen.py --swrv 1 --sbl-bin <path-to-sbl-binary> --sysfw-bin <path-to-sysfw-binary> --sysfw-inner-cert <path-to-sysfw-inner-cert-binary> --boardcfg-blob <path-to-boardcfg-binary-blob> --sbl-loadaddr ${SBL_RUN_ADDRESS} --sysfw-loadaddr ${SYSFW_LOAD_ADDR} --bcfg-loadaddr ${BOARDCFG_LOAD_ADDR} --key ${BOOTIMAGE_CERT_KEY} --debug DBG_FULL_ENABLE --rom-image <path-to-output-image>
By default SBLs provided in SDK are signed with full debug enable since this is needed for development. You can see from --debug switch used above. Once moved to production please remove this switch from the makefile.
For SBL images or examples which is loaded by SBL, we use a different signing script. This is solely because of the x509 certificate template differences between ROM and SYSFW. In GP devices appimages are not signed. The signing happens only in HS devices. The script usage is:
cd ${SDK_INSTALL_PATH}/source/security/security_common/tools/boot/signing

$(PYTHON) appimage_x509_cert_gen.py --bin <path-to-the-binary> --authtype 1 --key <signing-key-derived-from-devconfig> --output <output-image-name>
In the case of encryption, two extra options are also passed to the script like so:
cd ${SDK_INSTALL_PATH}/source/security/security_common/tools/boot/signing

$(PYTHON) appimage_x509_cert_gen.py --bin <path-to-the-binary> --authtype 1 --key <signing-key-derived-from-devconfig> --enc y --enckey <encryption-key-derived-from-devconfig> --output <output-image-name>
These scripts are invoked in makefiles, and the image generation happens automatically along with the example build. So mostly these scripts need not be manually run.
- Here,
  - SBL_RUN_ADDRESS is 0x70000000
  - In the case of GP device, BOOTIMAGE_CERT_KEY is rom_degenerateKey.pem
  - In the case of HS device, BOOTIMAGE_CERT_KEY is custMpk_am64x_am243x.pem. For more details about this see Enabling Secure Boot

These scripts are invoked in makefiles, and the image generation happens automatically along with the example build. So mostly these scripts need not be manually run. If the user build-system is different from TI's makefile system, it needs to be ensured that the same is followed as part of the post build steps. The devconfig has ENC_SBL_ENABLED=yes and that is why for HS-SE devices, the SBL image is encrypted by default.

The Boot Information Object identifier provides information about the image which is being loaded.

Elements of the extension:

Certificate Type: The certificate type defines the type of the image which is being loaded by the Boot-ROM.

These are the supported values:

0xA5A50000 Application Image

Boot core: This field is reserved and should be assigned with 0.

Core Options: This field is reserved and should be assigned with 0.

Load Address: This field is reserved and should be assigned with 0.

Image Size: This is the size in bytes of the R5 SBL or HSM Runtime Image to which the certificate has been attached.

Image Integrity OID (1.3.6.1.4.1.294.1.2)

imageIntegrity ::= SEQUENCE {
    sha_type:   OID,            -- Identifies the SHA type
    hash:       OCTET STRING    -- The SHA of the boot image
}

If the X.509 certificate provides the image integrity boot extension, the TIFS-MCU will perform the hash calculation on the entire image and will verify the computed hash with the hash provided in the boot extension. In the case of a mismatch the boot will fail.

Elements of the extension:

SHA Type:

The following values are supported:

2.16.840.1.101.3.4.2.1 SHA-256 Object Identifier
2.16.840.1.101.3.4.2.2 SHA-384 Object Identifier
2.16.840.1.101.3.4.2.3 SHA-512 Object Identifier

Amongst these, SDK has been validated against SHA-512 OID.

Hash: This is SHA-512 hash which is calculated over the application image

Software Revision OID (1.3.6.1.4.1.294.1.3)

softwareRevision ::= SEQUENCE {
   revision:    INTEGER -- Software revision
}

The information in the software revision is used to indicate the version of the image which is being loaded.

Elements of the extension:

revision: This is the version number. This will be matched to the EFUSE programmed version to indicate if the image loading should be done or not.

The following fields in efuse ROM help support the above feature:

SWRV_APP- This is used to perform the revision checking while loading the application

For more information, about how to fuse in these values, please refer to OTP Keywriter Documentation available on MySecureSW.

Image Encryption OID (1.3.6.1.4.1.294.1.4)

imageEncryption ::= SEQUENCE {
   iv:      OCTET STRING -- The initialization vector
   rs:      OCTET STRING -- Random string
   iter:    INTEGER      -- Reserved
   salt:    OCTET STRING -- Reserved
}

TIFS-MCU only supports AES-CBC mode with 256bit keys. The information in the image encryption object identifier is used to decrypt the image.

Elements of the extension:

IV: The initialization vector is used during the AES-CBC decryption procedure. The initialization vector needs to be 16bytes.

rs: This is the random string which is 32bytes long and is appended by the script at the end of the image. TIFS-MCU will decrypt the image and will perform a random string comparison to determine if the decryption was successful.

iter: This field is unused and reserved.

salt: This field is unused and reserved.

Keyring Index OID (1.3.6.1.4.1.294.1.12)

keyring_index ::= SEQUENCE {
   sign_key_id:     INTEGER -- index of public key hash in public keyring for authentication
   enc_key_id:      INTEGER -- index of aes key in keyring for decryption
}

TIFS-MCU only supports authentication with keyring. The information in enc_key_id is ignored and decryption is done against root of trust if Image Encryption OID is available in the certificate.

Elements of the extension:

sign_key_id: This is the index used in public keyring for retrieving the public key hash for authentication.

enc_key_id: This is the index used in keyring for retrieving the aes key for decryption of application image.

Boot time calculator tool

Checkout the secure boot time calculator tool here.