SPRADN0 December   2024 F29H850TU , F29H859TU-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Programming Fundamentals
  5. 2Introduction
    1. 2.1 Hardware Security Module
    2. 2.2 ROM Bootloader
    3. 2.3 Combined Image with X.509 Certificate
  6. 3Flash Kernel Implementation
    1. 3.1 CPU1 Firmware Upgrade (HS-FS)
    2. 3.2 Key Provision (HS-FS to HS-KP)
    3. 3.3 CPU1 Secure Firmware Upgrade (HS-KP/SE to HS-SE)
    4. 3.4 HSM Firmware Upgrade (HS-KP/SE to HS-SE)
    5. 3.5 SECCFG Code Provisioning (HS-KP/SE to HS-SE)
  7. 4Host Application: UART Flash Programmer
    1. 4.1 Overview
    2. 4.2 Build UART Flash Programmer with Visual Studio
    3. 4.3 Build UART Flash Programmer with CMake
    4. 4.4 Packet Format
    5. 4.5 Kernel Commands
  8. 5Example Usage
    1. 5.1 Loading the Flash Kernel onto the Device
      1. 5.1.1 Hardware Setup
      2. 5.1.2 Running the UART Flash Programmer
    2. 5.2 CPU1 Device Firmware Upgrade (HS-FS only)
    3. 5.3 Convert HS-FS to HS-SE
    4. 5.4 Loading a RAM-based HSMRt Image
    5. 5.5 Key Provision (HS-FS to HS-KP)
    6. 5.6 Code Provision (HS-KP/SE to HS-SE)
  9. 6Troubleshooting
    1. 6.1 General
    2. 6.2 UART Boot
    3. 6.3 Application Load
  10. 7Summary
  11. 8References

3.2 Key Provision (HS-FS to HS-KP)

To perform key provisioning on CPU1 of an HS-FS device, compile the KP_APP build configuration of the project. This can be done by right-clicking the project, hovering over Build Configurations, and selecting KP_APP.

Key Provision transitions an HS-FS device to an HS-KP device, and the following events occur:

  1. BootROM in UART boot mode receives the UART flash kernel and boots the kernel.
  2. The kernel in CPU1 receives a command packet to receive the HSMRt image.
  3. The kernel prepares to receive an X.509 certificate as part of the combined image from the host.
  4. The kernel verifies that the incoming certificate is of the proper size and format and derives the size of the incoming image. For now, the certificate is stored in RAM.
  5. The kernel stores HSMRt image in shared LDAx RAM and requested HSM to authenticate.
  6. Upon successful authentication, the HSM begins executing the HSMRt in shared LDAx RAM.
  7. The kernel then receives a command packet to receive HSM key.
  8. The kernel receives key certificate and places in shared LDAx RAM.
  9. The kernel notifies HSM that the keys have been received.
  10. Upon successful authentication of the key certificate, HSMRt programs the key into OTP.
  11. Perform power-on reset to transition the device into HS-KP.
CAUTION: The Keywriter binary image described in Section 2.1 need to be used as the HSMRt.

Refer to Section 5.5 on steps to perform on the host application.

As mentioned inSection 2.1 , the keywriter firmware is used to program customer keys and transition from HS-FS to HS-KP. The keywriter firmware supports the programming of the following key types and fields:

Key

Description

KeyWriter usage notes

Impact on HS-SE Device

SMPKH

Secondary Manufacturer Public Key Hash

SMPKH Length: 512 Bits

BCH Length: 64 Bits

  • Customer primary key set: Public Key Hash

  • SMPK is 4096-bit customer RSA Public key used for verifying RSA signature included in Boot Images.

  • SMPKH Value: 512 bit hash of SMPK generated via SHA512 hashing algo which is split into two parts of 256-bits. That is, SMPKH_P1/SMPKH_P2
  • BCH Value: 32-bit BCH is computed using algorithm (288, 261, 7) for each part of SMPKH_P1 and SMPKH_P2. This algorithm supports 3 bit error correction

  • Checks enforced by KeyWriter: N/A

Secure boot active key to validate Root of Trust for boot Image x.509 certificate when key configuration field KEYREV=1

SMEK

Secondary Manufacturer Encryption Key

SMEK Length: 256 Bits

BCH Length: 32 Bits

  • Customer primary key set: Encryption Key

  • SMEK is 256-bit customer encryption key for Boot Image Encryption

  • SMEK Value: Original 256 Bit Symmetric Key used for AES-CBC Encryption of Boot Images

  • BCH Value: 32-bit BCH is computed using algorithm (288, 261, 7) for 256 bit SMEK. This algorithm supports 3 bit error correction

  • Checks enforced by KeyWriter: N/A

Active key for secure boot to decrypt the boot Image if encrypted and enabled via x509 certificate when key configuration field KEYREV=1

BMPKH

Backup Manufacturer Public Key Hash

BMPKH Length: 512 Bits

BCH Length: 64 Bits

  • Customer backup key set: Public Key Hash

  • Note: Device supports Backup key pair which must be provisioned by keywriter and can be activated once product is deployed in field by incremental programming of KEVREV field in field. Note that if backup key pair is not provisioned by keywriter on HS-FS device then this is not possible to program backup key pair later once device transitions to HS-SE.

  • BMPK is 4096-bit customer RSA Public key used for verifying RSA signature included in Boot Images.

  • BMPKH Value: 512 bit hash of BMPK generated by SHA512 hashing algo which is split into two parts of 256-bits. That is, BMPKH_P1/BMPKH_P2

  • BCH Value: 32-bit BCH is computed using algorithm (288, 261, 7) for each part of BMPKH_P1 and BMPKH_P2. This algorithm supports 3 bit error correction

  • Checks enforced by KeyWriter: N/A

Secure boot active key to validate Root of Trust for boot Image x.509 certificate when key configuration field KEYREV=2

BMEK

Backup Manufacturer Encryption Key

BMEK Length: 256 Bits

BCH Length: 32 Bits

  • Customer backup key set: Encryption Key

  • BMEK is 256-bit customer encryption key for Boot Image Encryption

  • BMEK Value: Original 256 Bit Symmetric Key used for AES-CBC Encryption of Boot Images

  • BCH Value: 32-bit BCH is computed using algorithm (288, 261, 7) for 256 bit BMEK. This algorithm supports 3 bit error correction

  • Checks enforced by KeyWriter: N/A

Active key for secure boot to decrypt the boot Image if encrypted and enabled via x.509 certificate when key configuration field KEYREV=2

KEYCNT

Key count configuration field

Length: 16 bits

  • Active Key Sets provisioned in the device, and supports following values

  • If only Primary Key Set is Plan of Record for device (SMPKH /SMEK)

  • If both Primary Key Set and Backup Key Set is Plan of Record for device (SMPKH /SMEK) and (BMPKH /BMEK)

  • Note: This field controls the active Key sets in the device. If the user wants to enable backup Key set, then a mandatory issue is to provision backup key pair and set KEYCNT as 2 by Keywriter. If this field is programmed as 1, then device can only support primary Key set for Secure boot and this field can not be updated later.

  • Checks enforced by KeyWriter: N/A

Active Key Sets provisioned in the device for Key Manager to decode and setup the Keys.

KEYREV

Key revision configuration field

Length: 16 bits

  • Current active key revision in the device for Root of Trust and supports following values

  • For Primary Key Set (SMPK/SMEK) used for Secure Boot (Recommended config for KeyWriter)
  • For Backup Key Set (BMPK/BMEK) used for Secure Boot

  • Checks enforced by KeyWriter: N/A

Current active key revision for Secure Boot

MSV

Model specific value

Length: 24 bits

BCH: 8 bits
  • 24 bit Model Specific Value, Customers can program 24 bit values to differentiate product variants using same SoC either in production flow Or in boot flow of the device.
  • BCH Value: 8-bit BCH is computed using algorithm (32, 24, 8) for 24 bit MSV. This algorithm supports 2 bit error correction

No Impact for Boot ROM, SW needs to comprehend the usage of this field

SWREV-SBL

SBL software revision

Length: 64 bits

  • Supports 32 values (1 to 32 states with double redundancy)

  • Recommended to set initial value of 0x1

Enables Anti Roll back feature for SBL Image x.509 Certificate via SWRV extension

SWREV-HSM

TIFS-MCU software revision

Length: 64 bits

  • Supports 32 values (1 to 32 states with double redundancy)

  • Recommended to set initial value of 0x1

Enables Anti Roll back feature for TIFS-MCU Image x.509 Certificate via SWRV extension

SWREV-APP

Application Image software revision

Length: 192 bits

  • Supports 64 values (1 to 64 states with double redundancy)

  • Recommended to set initial value of 0x1

No Impact for Boot ROM, TIFS-MCU needs to comprehend the usage of this fields

EXTENDED OTP

Extended OTP array Length: 1664 bits

1664 bit extended otp array for customer usage

No Impact for Boot ROM