Key Writer

This guide describes the procedure and format to be followed, to populate customer keys in eFuses of the SoC.

Note

This document must be read along side OTP Keywriter TISCI Description

High Security (HS) Device Sub-types

  1. HS-FS (High Security - Field Securable): Device type before customer keys are programmed (the state at which the device leaves TI factory). In this state, device protects the ROM code, TI keys and certain security peripherals. HS-FS devices do not enforce secure boot process.

    • M3 JTAG port is closed, R5 JTAG port is open
    • DMSC Firewalls are closed, SOC Firewalls are open
    • Board configuration need not be signed
    • ROM Boot expects a TI signed binary (encryption is optional)
    • System Firmware binary is signed by the TI Private key (TI MPK). (Refer Signing an unencrypted binary for secure boot for more details)
  2. HS-SE (High Security – Security Enforced): Device type after customer keys are programmed. HS-SE devices enforce secure boot.

    • M3, R5 JTAG ports are both closed
    • DMSC, SOC Firewalls are both closed
    • Board configuration needs to be signed with active customer private key (SMPK/BMPK)
    • ROM Boot expects a dual signed, encrypted system firmware binary
    • System Firmware binary is encrypted by the TI Encryption key (TI MEK), and signed by the TI Private key (TI MPK). Customer has to dual sign it with their private key (SMPK/BMPK). (Refer Signing an encrypted binary for secure boot)

HS-FS to HS-SE Conversion

In order to convert a HS-FS device to HS-SE device, one has to program the customer root key set (optionally backup key set) on the target device, using OTP Keywriter.

Customer key information is encrypted into x509 certificate extension fields. A list of fields that OTP keywriter supports, can be found here

../_images/hsfs_to_hsse_conversion.png

Procedure

Following figure illustrates the procedure to be followed to generate the required x509 certifcate for key writing.

../_images/key_writer_procedure.png
  1. OEM generates a random 256-bit number to be used as an AES encryption key for protecting the OTP extension data.
  2. The AES-256 key from step 1 is used to encrypt all X509 extension fields, which require encryption protection.
  3. Following X509 extensions are created, using TI FEK (public):
    • Encrypting the AES-256 key with TI FEK
    • Signing the AES-256 key with the SMPK, and encrypting that with the TI FEK
    • (optionally, refer step 6) signing the AES-256 key with the BMPK, and encrypting that with the TI FEK
  4. All of the extensions from steps 1-3 are combined into a X.509 configuration which is used to generate and sign a certificate with the SMPK.

Note

SMPK Hash. BMPK Hash are computed using SHA-512 Algorithm, for corresponding Public keys in DER format.

  1. This X509 config is sigend using SMPK (priv).
  2. (Optional) If the OEM chooses to write BMPK/BMEK fields, X509 config from step 5 needs to be signed using BMPK (priv).

Supported fields

Following fields are supported by the Key writer.

Field Flashing Mandatory/Optional Encoding
SMPK-Pub Part of certificate, not flashed Mandatory  
SMPKH Flashed Mandatory  
SMPKH-BCH Flashed Computed on device  
SMEK Flashed Mandatory  
SMEK-BCH Flashed Computed on device  
BMPK-Pub Part of certificate, not flashed Optional  
BMPKH Flashed Optional  
BMPKH-BCH Flashed Computed on device  
BMEK Flashed Optional  
BMEK-BCH Flashed Computed on device  
KEYCNT Flashed Inferred  
KEYREV Flashed Constant Set to 1

X509 Configuration Template

[ req ]
distinguished_name = req_distinguished_name
x509_extensions = v3_ca
prompt = no
dirstring_type = nobmp

# This information will be filled by the end user.
# The current data is only a place holder.
# System firmware does not make decisions based
# on the contents of this distinguished name block.
[ req_distinguished_name ]
C = oR
ST = rx
L = gQE843yQV0sag
O = dqhGYAQ2Y4gFfCq0t1yABCYxex9eAxt71f
OU = a87RB35W
CN = x0FSqGTPWbGpuiV
emailAddress = kFp5uGcgWXxcfxi@vsHs9C9qQWGrBs.com

[ v3_ca ]
basicConstraints = CA:true
1.3.6.1.4.1.294.1.64 = ASN1:SEQUENCE:enc_aes_key
1.3.6.1.4.1.294.1.65 = ASN1:SEQUENCE:enc_smpk_signed_aes_key
1.3.6.1.4.1.294.1.66 = ASN1:SEQUENCE:enc_bmpk_signed_aes_key
1.3.6.1.4.1.294.1.67 = ASN1:SEQUENCE:aesenc_smpkh
1.3.6.1.4.1.294.1.68 = ASN1:SEQUENCE:aesenc_smek
1.3.6.1.4.1.294.1.70 = ASN1:SEQUENCE:aesenc_bmpkh
1.3.6.1.4.1.294.1.71 = ASN1:SEQUENCE:aesenc_bmek


[ enc_aes_key ]
# Replace PUT-ENC-AES-KEY with acutal Encrypted AES Key
val = FORMAT:HEX,OCT:PUT_ENC_AES_KEY
size = INTEGER:PUT_SIZE_ENC_AES

[ enc_bmpk_signed_aes_key ]
# Replace PUT-ENC-BMPK-SIGNED-AES-KEY with acutal Encrypted BMPK signed AES Key
val = FORMAT:HEX,OCT:PUT_ENC_BMPK_SIGNED_AES_KEY
size = INTEGER:PUT_SIZE_ENC_BMPK_SIGNED_AES

[ enc_smpk_signed_aes_key ]
# Replace PUT-ENC-SMPK-SIGNED-AES-KEY with acutal Encrypted SMPK signed AES Key
val = FORMAT:HEX,OCT:PUT_ENC_SMPK_SIGNED_AES_KEY
size = INTEGER:PUT_SIZE_ENC_SMPK_SIGNED_AES

[ aesenc_smpkh ]
# Replace PUT-AESENC-SPMKH with acutal Encrypted AES Key
val = FORMAT:HEX,OCT:PUT_AESENC_SMPKH
iv = FORMAT:HEX,OCT:PUT_IV_AESENC_SMPKH
rs = FORMAT:HEX,OCT:PUT_RS_AESENC_SMPKH
size = INTEGER:PUT_SIZE_AESENC_SMPKH

[ aesenc_smek ]
# Replace PUT-AESENC-SMEK with acutal Encrypted AES Key
val = FORMAT:HEX,OCT:PUT_AESENC_SMEK
iv = FORMAT:HEX,OCT:PUT_IV_AESENC_SMEK
rs = FORMAT:HEX,OCT:PUT_RS_AESENC_SMEK
size = INTEGER:PUT_SIZE_AESENC_SMEK

[ aesenc_bmpkh ]
# Replace PUT-AESENC-BMPKH with acutal Encrypted BMPKH
val = FORMAT:HEX,OCT:PUT_AESENC_BMPKH
iv = FORMAT:HEX,OCT:PUT_IV_AESENC_BMPKH
rs = FORMAT:HEX,OCT:PUT_RS_AESENC_BMPKH
size = INTEGER:PUT_SIZE_AESENC_BMPKH

[ aesenc_bmek ]
# Replace PUT-AESENC-BMEK with acutal Encrypted BMEK
val = FORMAT:HEX,OCT:PUT_AESENC_BMEK
iv = FORMAT:HEX,OCT:PUT_IV_AESENC_BMEK
rs = FORMAT:HEX,OCT:PUT_RS_AESENC_BMEK
size = INTEGER:PUT_SIZE_AESENC_BMEK