TDA4VM: J721E: Aadapt secure boot on the GP board for SBL and system firmware

Hi Sarath,

Baby Sarath Sasidharan Nair said:

1, In this case, can the X509 certificate generation in the boot image of SBL and system firmware skipped ?  If not, what is the need for X509 certificate & how the cerificate is processed in booting of SBL and system firmware ?

X509 certificates is required even for GP devices. The ROM code validates the hash of binaries using the X509
certificate structure, even though authentication is not performed.

 X509 certificate serves important purposes:

- Hash validation: ROM validates the hash of binaries on GP devices if RSA degenerate key is used for signing
- Boot metadata: The certificate contains critical boot information (component sizes, load addresses, boot core information)

Baby Sarath Sasidharan Nair said:

2,Please share the format of the X509 certificate with mandatory parameters that need to be encoded?

Please go through "Boot Image Format" section of the TRM for the mandatory extension/parameter needed for bootloader image.

Baby Sarath Sasidharan Nair said:

3,If there is no authentication provided, is it mandatory  to place a key in the certificate?

For GP devices, you should use an RSA degenerate key (dummy key).

Regards
Diwakar

Hi Diwakar,

Thanks for the response

I assume that your clarifications are applicable for both SBL and System Firmware.

Request you to check the below follow up queries for GP device.

1. Please share the path of RSA degenerate key (dummy key) in the PDK.
2. Is the hash validation mandatory or is there an option to skip it ? (We have other project specific options to evaluate the integrity)
3. How the RSA degenerate key (dummy key) is used for SBL and System Firmware in GP device?

Regards,

Sarath

Hi Sarath,

Baby Sarath Sasidharan Nair said:

• Please share the path of RSA degenerate key (dummy key) in the PDK.

Keys can be found out in <RTOS_SDK>/<PDK>/packages/ti/build/makerules.

Baby Sarath Sasidharan Nair said:

Is the hash validation mandatory or is there an option to skip it ? (We have other project specific options to evaluate the integrity)

No, We can not skip this step.Also how we are checking the integrity and doing the verification of the image at the boot loader stage before loading it ?

Baby Sarath Sasidharan Nair said:

How the RSA degenerate key (dummy key) is used for SBL and System Firmware in GP device?

This key is used for signing the bootloader (SBL/SPL) and TIFS certificate on GP device.

Regards
Diwakar

Hi Diwakar,

Thanks for the update.

Is it possible to use customer specific key instead of RSA degenerate key (dummy key) in SBL and System Firmware ?

We uses in house developed System Firmware instead of TI supplied one.

Best regards,
Sarath

Hi Sarath,

If we are using customer key instead of ROM degenerate key then ROM will only be doing integrity check on the image instead of doing cert validation followed by image integrity check.

Regards
Diwakar

Hi Diwakar,

Does it means that the steps 1a,1b, 2a, 2b & 2c marked in below diagram will skipped for both SBL and system firmware and only performs the steps 3a & 3b?

Also are there any change needed in efuse values, to use the customer key or can we keep the default eFuse values shipped by the TI ?

Regards,
Sarath

Hi Diwakar,

When reviewing your recent comment along side the previous clarification (copied below), I am confused regarding the use of the customer key..

In other words, hash validation is skipped for binaries signed with any key except the RSA degenerate (dummy) key.

Could you kindly check this as well.

Regards,

Sarath

Hi Diwakar,

I conducted some tests on this topic today and would like to share the observed behaviors.

Test 1:
SBL Changes:

1. Generated x509 certificate without including the Image Integrity extension (Section 4.5.4.2, OID 1.3.6.1.4.1.294.1.2, as specified in the TRM).
2. Signed the certificate using a customer-specific RSA key (1024 bits).

System Firmware Changes:

1. Generated  the certificate containing both the Boot Info (OID 1.3.6.1.4.1.294.1.1) and Image Integrity (OID 1.3.6.1.4.1.294.1.2) extensions.
2. Signed the certificate using the RSA degenerate (dummy) key.

Observed Result:
The system booted successfully and loaded the application images on the other cores.

Test 2:
SBL Changes:
          Same as in the Test 1
System Firmware Changes:

1. Generated x509 certificate without the Image Integrity extension (Section 4.5.4.2, OID 1.3.6.1.4.1.294.1.2).
2. Signed the certificate using a customer-specific RSA key (1024 bits).

Observed Result:
The system did not boot correctly. While the SBL loaded as expected and attempted to load the system firmware, a timeout in waiting for acknowledgement from System Firmware was reported by the SBL, indicating a failure during system firmware authenication.

Summary:
Hash validation of the binary and certificate signing with a customer key functioned correctly for the SBL.However, the same approach did not work for the system firmware. In this case, both hash validation of the binary and signing with the RSA degenerate (dummy) key appear to be mandatory.

Could you please share your thoughts on the observations.

Regards,
Sarath

Hi Sarath,

As far as i remember you were using HS-PRIME device, why we are talking about GP device here ? Flow will change based on the device type.

Reference thread where we discussed that the device type is prime.

e2e.ti.com/.../tda4vm-firewall-descriptions

Regards
Diwakar

Hi Diwakar,

As mentioned earlier, the project uses in house developed System Firmware and the device type is GP.

This is verifed by checking the DMSC0_SEC_MGR_0_SYS_STATUS register.

Regards,
Sarath

Hi Sarath,

Ok then earlier statement of being prime was not correct. Let me do the similar experiment at my end and based on the result will reach out to our internal ROM team.

Regards
Diwakar

Hi Diwakar,

Fine.
Sorry for the confusion. The info mentioned in chapter 9.3 Prime for DMSC firmware  in SPRUIM0C document somewhat wrongly hints that the third party customization of the firmware is only allowed for HS-Prime.

Could you please also check my prevoius questions as well.

Does it means that the steps 1a,1b, 2a, 2b & 2c marked in below diagram will skipped for both SBL and system firmware and only performs the steps 3a & 3b?

Regards,
Sarath

Hi Sarath,

Quick experiment results: I tested after removing all the extension except 1.3.6.1.4.1.294.1.1 from SBL as well as from TIFS and used Custom key to sign the both the image.Could see device is booting.

SBL cert signed with Non ROM degenerate key:

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

[ req_distinguished_name ]
C = US
ST = SC
L = Dallas
O = "Texas Instruments.
OU = PBU
CN = Albert
emailAddress = Albert@ti.com

[ v3_ca ]
basicConstraints = CA:true
1.3.6.1.4.1.294.1.1 = ASN1:SEQUENCE:boot_seq

[ boot_seq ]
certType = INTEGER:1
bootCore = INTEGER:16
bootCoreOpts = INTEGER:2
destAddr = FORMAT:HEX,OCT:41C00100
imageSize = INTEGER:307176

TIFS Cert signed with ROM degenerate key.

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

[ req_distinguished_name ]
C = US
ST = SC
L = Dallas
O = "Texas Instruments.
OU = PBU
CN = Albert
emailAddress = Albert@ti.com

[ v3_ca ]
basicConstraints = CA:true
1.3.6.1.4.1.294.1.1 = ASN1:SEQUENCE:boot_seq

[ boot_seq ]
certType = INTEGER:2
bootCore = INTEGER:0
bootCoreOpts = INTEGER:0
destAddr = FORMAT:HEX,OCT:00040000
imageSize = INTEGER:262112

Boot logs:

Are you seeing same behaviour at your end. Since this was the first device of TDA4 class i need to check how was ROM behaving at that point of time.

Regards
Diwakar

Hi Diwakar,

When I tested by removing all certificate extensions except 1.3.6.1.4.1.294.1.1 from both the SBL and system firmware certificates, and signed both with a custom byte key, the system failed to boot. The SBL reported a timeout while waiting for an acknowledgement after loading the system firmware.

Using the same SBL, I enabled the certificate extensions 1.3.6.1.4.1.294.1.1 and 1.3.6.1.4.1.294.1.2 for the system firmware and signed it with the ROM degenerate key. With this configuration, the device booted successfully.

Regards,
Sarath

Hi Sarath,

Do you have EVM at your end ? I can share you the binary which you can test at your end as well.

I used TI Dummy key to sign the TIFS and SBL binary rather than ROM degenerate key with 1.3.6.1.4.1.294.1.1 extension in the cert.

Regards
Diwakar

Hi Diwakar,

Thanks for the update.

Could you please share the size of the TI Dummy key used ?
Is it a RSA key with 1024 bits ?

Kindly share your certificates and the dummy keys so that i can try them with my binaries .

Regarding the EVM availability, i will check internally and get back.

Regards,
Sarath

Hi Diwakar,

Thanks for the update.

Further debugging today revealed the issue that occurs when the system firmware is signed with a custom key and contains only the 1.3.6.1.4.1.294.1.1 extension in certificate.
The problem was caused by the secure ROM taking longer than expected to send an acknowledgment to the SBL for the system firmware upload request.

The issue is resolved by increasing the waiting time for this acknowledgment in the SBL.
It appears that the ROM code consumes more time to send the acknowledgment, when the system firmware is signed with a custom key.

With the increased waiting time for the acknowledgment in the SBL, the system now boots up properly,
when both the SBL and System Firmware are signed with a custom key and use certificate containing only the 1.3.6.1.4.1.294.1.1 extension.

Could you please check this behavior with your internal ROM team and share the feedback?

Below, I am summarizing the conclusion to avoid any misunderstandings.
Please let me know if any corrections are needed.
Summary:

The ROM code expects the TI-defined image format for both the SBL and System Firmware, even on GP devices. This format always requires an x509 certificate to precede the Bootloader and System Firmware binaries.

The x509 certificate serves important purposes:

• Hash validation: On GP devices, the ROM validates the hash of the binaries if an RSA degenerate key is used for signing.
• Boot metadata: The certificate contains essential boot information, such as binary size, load addresses, and boot core details.

If the image is signed with a custom key instead of the TI-supplied ROM degenerate key, the ROM code skips the integrity check. On GP devices, there are no eFuses or any mechanism to authenticate against any type of key, so no changes are required to the default eFuse values.

Regards,
Sarath

Hi Sarath,

Glad to hear that issue is resolved.

Baby Sarath Sasidharan Nair said:

Could you please check this behavior with your internal ROM team and share the feedback?

Do we have any timing number for this ? I will share with ROM team .

Baby Sarath Sasidharan Nair said:

Please let me know if any corrections are needed.

Your understanding is correct.

Regards
Diwakar

Hi Diwakar,

Please find the timing details below

Do we have any timing number for this ? I will share with ROM team .

When the system firmware is signed with the TI RSA degenerate (dummy) key and uses a certificate containing the extensions 1.3.6.1.4.1.294.1.1 and 1.3.6.1.4.1.294.1.2, the SBL receives an acknowledgment within 5 ms after sending the system firmware upload request.

When the system firmware is signed with a custom key and uses a certificate containing only the 1.3.6.1.4.1.294.1.1 extension, the acknowledgment is received within 20 ms.

Regards,

Sarath

Hi Sarath,

Thanks for sharing the information allow me some time to check on this . We also do the time measurements at our end.

Regards
Diwakar