SPRAD04 January   2022 TDA4VH-Q1 , TDA4VM , TDA4VM-Q1

 

  1.   Trademarks
  2. 1Introduction
  3. 2TIDK Device Verification
    1. 2.1 Sign and Encrypt Second BootLoader (SBL)
    2. 2.2 Sign and Encrypt System Image
  4. 3Keys Programming
    1. 3.1 Install Keywriter
    2. 3.2 Keys Generation
    3. 3.3 Build Keywriter Application
    4. 3.4 Program Keys in HS-FS Device
  5. 4Key Programming Verification
  6. 5Building and Booting on HS Devices Using Linux SDK
  7. 6Summary

Keys Generation

After installing the SDK, the Keywriter package should include the keys to generate the x509 certificate before building the Keywriter application, then append this x509 certificate to the final keywriter binary, as shown in Figure 3-2.
Figure 3-2 X509 Certificate Generation Procedure
  • The RNG (Random Numeral Generator) in the customer HSM generates the random aes-256 key. This aes-256 key is temporary and used to encrypt each field. For each field, the aes-256 key is the same but called with a different IV (initialization vector). This aes-256 key also is encrypted by the TI FEK public key and included in the x509 extension.
  • The SMPKH, SMEK, BMPKH, and BMEK keys are encrypted by the aes-256 key and included in a different x509 extension. These keys will be programmed into eFuses in plain text.
  • The x509 configuration is signed by the SMPK private key and the BMPK private key (optional), then append these filed to the original x509 extension.

The process is irreversible once the eFuse is programmed by customer keys. In order to make sure the correctness of the operation and process, before the customer starts to program their customer keys into HS-FS device, it is a good choice to first use the TI dummy keys or random dummy keys as test keys; however, this step is not mandatory.

The Keywriter package provides one script that can generate random dummy keys to help the customer to test. The TI dummy keys are public, while the customer keys should be kept securely in the customer HSM so the customer can choose to use this random dummy keys for test before production. To generate the random dummy key, follow these steps:

# cd ${PSDKRA_PATH} /pdk/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts
# ./gen_keywr_cert.sh -g
# cp ${PSDKRA_PATH} /pdk/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts/ti_fek_public.pem
${PSDKRA_PATH} /pdk/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts/keys/tifekpub.pem
# ls ${PSDKRA_PATH} /pdk/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts/keys
aes256.key bmek.key bmpk.pem smek.key smpk.pem tifekpub.pem

Also, the TI dummy keys are published in the TI SDK. Once the customer uses the TI dummy keys to complete the key programming, the device would convert to an HS-SE-TIDK device. So, the customer can use the method in Section 2 to sign and encrypt their system image, then verify these binaries in the device programmed by the TI dummy keys.

# cd ${PSDKRA_PATH}/pdk/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts
# ./gen_keywr_cert.sh -g
# rm ${PSDKRA_PATH}/pdk/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts/keys/bmek.key bmpk.pem
smek.key smpk.pem
# cp ${PSDKRA_PATH}/pdk/packages/ti/build/makerules/k3_dev_mpk.pem
${PSDKRA_PATH}/pdk/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts/keys/smpk.pem
# xxd -p -r ${PSDKRA_PATH}/pdk/packages/ti/build/makerules/k3_dev_mek.txt ${PSDKRA_PATH}/pdk
/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts/keys/smek.key
# cp ${PSDKRA_PATH} /pdk/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts/ti_fek_public.pem
${PSDKRA_PATH} /pdk/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts/keys/tifekpub.pem
# ls ${PSDKRA_PATH} /pdk/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts/keys
aes256.key smek.key smpk.pem tifekpub.pem

The k3_dev_mek.txt is a 32-byte data file, which is used to encrypt the binary as a symmetric key, as shown in Section 2. The corresponding decryption key needs to be programmed into eFuse by Keywriter, but the keywriter requires the file to be in binary form. So the “xxd” command used to convert the format is shown below. Also, the k3_dev_mpk.pem is a secret key of the asymmetric key used to sign the binary, and the corresponding public key calculates the hash value and programmed into eFuse by Keywriter.

It is more reliable to check the smek.key using the following command. Before moving to the next step, make sure these two results are totally the same.
# cat ${PSDKRA_PATH}/pdk/packages/ti/build/makerules/k3_dev_mek.txt
c143f03568798964d4a5769bd5a27d3adc0d6bdd8f3cc47b84229e50a54ab043
# xxd -p /home/wangli/ti-processor-sdk-rtos-j721e-evm-
07_01_00_11/pdk_jacinto_07_01_00_45/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts/keys/smek.key
c143f03568798964d4a5769bd5a27d3adc0d6bdd8f3cc47b84229e50a54ab043

If the customer decides to use their customer keys, they also need to copy their keys to the following folder:
${PSDKRA_PATH}/pdk/packages/ti/boot/sbl/example/k3MulticoreApp/keywriter/scripts/keys.