F29H850TU: Sec cfg validation

Hi Geetha,

Kunukuntla Geetha said:

Does encryption(with salt value) happens here?

1. The security mechanism relies on X.509 certificate-based authentication and signing using customer keys (CustMpk) rather than encryption (till now). The Seccfg.bin file must be prepended with an X.509 certificate signed with customer keys, and the HSM uses SMPK/SMEK keys for authentication during the validation process.

Kunukuntla Geetha said:

What are the contents of the Seccfg.bin's certificate?

2. The Seccfg.bin file contains an X.509 certificate that includes the following components:

Certificate Structure:

• The certificate always starts with bytes 0x3082 (ROM expects this signature)
• The ROM validates the certificate within the first 4096 bytes
• The certificate is signed with customer keys programmed during HS-KP provisioning

SECCFG Configuration Contents:

The SECCFG encompasses:

• APR (Access Protection Register) configurations
• LINKID assignments
• DISABLE, LOCK, and COMMIT parameters for security policies
• SSU user protection policy settings
• Boot configuration settings

Kunukuntla Geetha said:

How Boot ROM validates this file like de-signing and roll back and others(if applicable, what are they)?

3. The Boot ROM validates the Seccfg.bin file through a comprehensive three-phase process:

Phase 1: Certificate Processing (De-signing/Authentication)

• The HSM ROM determines the currently active SECCFG region
• Validates SECCFG contents against the certificate stored in the HSM CERT0 region
• Authenticates the X.509 certificate using SMPK/SMEK keys 
• Verifies the certificate signature matches the customer keys programmed in HS-KP state

Phase 2: Code Programming

• Programs the validated SECCFG data to the NONMAIN flash region 

Phase 3: Code Verification

• Performs CRC32 validation on the SECCFG sector contents 
• If CRC check fails, the boot process is aborted 
• Verifies the BOOTPIN_CONFIG register key field (bits 31:24 must be 0x5A) 

Rollback Protection: The system implements rollback protection through software revision checks:

• The HSM Client Write SW Revision Service updates software revisions for HSM, SBL, SECCFG, and Application
• SW revision changes are permanent in NVM OTP (One-Time Programmable memory)
• Any revision less than the programmed revision will not be allowed to boot 
• It is mandatory to update SECCFG with a greater SW revision before issuing write SW revision commands 

Kunukuntla Geetha said:

It is said that Seccfg.bin needs to be flashed before changing device type to SE, Can we erase this region later or Do we need to reserve this area?

4. The SECCFG region must be permanently reserved and cannot be erased after device conversion to HS-SE. Here's why:

• Seccfg.bin needs to be flashed before changing device type from HS-KP to HS-SE
• Successfully programming the Security Configuration converts the device to HS-SE after a power-on reset (PORSn) 
• The SECCFG sector is critical for device boot - invalid SECCFG settings may prevent the device from booting and leave it in an unrecoverable state
• Each CPU pair has an associated active SECCFG sector and a reserve SECCFG sector for updates

Important: The device loads the User Protection Policy from the active SECCFG sector into SSU registers at boot time. Erasing this region would brick the device.

Kunukuntla Geetha said:

If I build and load a project(app binary and Seccfg binary are formed), how these files are separately flashed into MAIN and NONMAIN sectors.? Does it get loaded automatically or in manual way?

5. The flashing process differs between MAIN and NONMAIN sectors and depends on the device security mode:

SECCFG Sector Addresses:

In HSFS Mode:

• The example program contains SSU settings as SECCFG sections.
• When the program is loaded via CCS debugger, these sections are automatically programmed into SECCFG sectors provided the 'enable NONMAIN Flash programming' option is ticked in the flash settings for the Flash Plugin in CCS.

In HSSE Mode:

• After loading the example, you must Power Off and On the EVM so that new SSU settings get loaded by BootROM 
• The CPU1/CPU2 and CPU3 SECCFG sections are programmed into SECCFG sectors.

Manual Flashing Methods:

Method 1: JTAG-Based Programming

Method 2: UART-Based Programming

Programming Sequence:

1. Load RAM-based SBL after power-on reset
2. Load HSM RAM Image (CP services)
3. Program Sec Cfg first (recommended before other flash applications)
4. Program CPU1, CPU3, and HSM flash applications as needed
5. Perform final device reset

Important Notes:

• It is recommended to flash the Sec Cfg first, followed by HSM flash, then CPU flash

Kunukuntla Geetha said:

It is given as The HSM ROM determines the currently active SECCFG region, and validates the SECCFG contents against the certificate stored in the HSM CERT0 region. How CERT0 contained the certificate initially?

6. The CERT0 region is initially populated during the key provisioning process when converting from HS-FS to HS-KP. Here's the sequence:

Key Provisioning Process:

1. Device starts in HS-FS (Field Securable) state
2. Customer generates key pairs (SMPK/SMEK - Secure Manufacturing Public/Encryption Keys)
3. During HS-FS to HS-KP conversion, customer keys are programmed into the device
4. These keys are stored in the HSM CERT0 region in NVM OTP (One-Time Programmable memory)
5. The CERT0 region then serves as the root of trust for all subsequent SECCFG validations

Validation Reference: After CERT0 is populated, the HSM ROM uses it as the reference for validating all SECCFG images. The X.509 certificate in each Seccfg.bin must be signed with keys that match or chain to the keys stored in CERT0.

Kunukuntla Geetha said:

It is said that any new update need to be done in SECCFG alternative region. But if I'm updating in inactive bank(MAIN and NON MAIN regions are inactive too). Here SECCFG is also inactive, Should I write new SECCFG values in active region or alternative region?

7. You should ALWAYS write new SECCFG values to the alternative (reserve) region, not the active region. The system handles this automatically:

Update Mechanism:

• Each CPU has two SECCFG sectors: one active and one reserve 
• The SECVALID register specifies which sector is active 
• When updating SSU configuration, always program to the reserve (B2/B3) SECCFG sector address 
• The SSU automatically routes the reserve address to the current inactive sector when a Flash program or erase command is performed

Important: Even when updating the inactive bank (where MAIN and NONMAIN regions are inactive), you still write to the alternative SECCFG region address. The hardware automatically manages which physical sector receives the data based on the current BANKMODE and SECVALID settings

Kunukuntla Geetha said:

If I have currently running software, and I have update in FOTA, new Seccfg.bin need to be flashed into the SECCFG alternative region of another inactive bank by HSM. Now I have done POR, the values in CERT0 and this new Seccfg,bin's certificate are completely different. How HSM validates this now?

8. During FOTA updates on F29H85X devices, the HSM validates a new Seccfg.bin certificate by authenticating it against the Root of Trust keys (SMPKH) that were provisioned during Key Provisioning. The new certificate must be signed with the same private key whose public key hash was provisioned as SMPKH, and after successful validation and programming, the new certificate replaces the old one to enable successful boot on subsequent power cycles.

If you use a HSM service for SecCfg update, then it will ensure the correct seccfg bin and counter is programmed.

Failure Handling: If validation fails (certificate mismatch or rollback detected), the boot process is aborted, and the device remains in a safe state with the previous valid configuration.

Thanks and Regards,
Aditya Singal

Hi Geetha,

Kunukuntla Geetha said:

So CERT0 region contains nothing but the Cust keys which are required for the validating the Seccfg.bin file, right?

Apologies for the confusion, CERT0 will contain the X.509 certificate of SECCFG and not the Cust Keys.

Kunukuntla Geetha said:

The certificate contains SW version, public key, signature. Are there any values embedded in the certificate like load address, hash value, magic number?

Yes, the SECCFG certificate follows the standard template of X.509 certificate.

Thanks and Regards,
Aditya Singal