TMS320F280039: TMS320F280039 Security Feature Support Confirmation Application & Development Resource Inquiry

Hello,

f dd said:

1. Secure Boot

• Requirements: Immutable boot chain, non-bypassable signature verification, support for SHA-384+ECDSA signature verification, and a fallback recovery mechanism for boot failures.
• Question: Does the F280039's on-chip boot ROM support an immutable boot chain? Can signature verification (specifically SHA-384+ECDSA) be configured as mandatory and non-bypassable? What is the specific hardware/software mechanism for the boot failure fallback?

This is not supported by the F28003x HW. You will have to implement the feature using a two-stage bootloader in DCSM secured flash. 

f dd said:

2. Anti-Rollback

• Requirements: Secure version control, blocking of lower-version firmware, and logging of version violations and rollback blocks.
• Question: Does the F280039 have a dedicated SVN (Security Version Number) hardware register? How is low-version firmware blocked during updates? Are the violation logs stored in dedicated OTP/Flash regions with hardware protection?

No, F28003x does not have dedicated SVN registers or HW-enforced anti-rollback protection. This would have to be implemented in software leveraging DCSM protected flash. 

f dd said:

3. Encryption Algorithms

• Requirements: SHA-384/ECDSA support, and data at-rest/in-transit encryption.
• Question: The datasheet mentions an AES accelerator. Does the F280039 hardware natively support SHA-384 and ECDSA (P-256/P-384)? If not, are there optimized software libraries or hardware acceleration modules for these algorithms?

F28003x HW does not natively support SHA384 or ECDSA. The AES accelerator only supports the below features. We do offer crypto SW libraries (including SHA384) in C2000Ware in libraries\security\crypto\c28

Source: F28003x TRM

f dd said:

4. Debug Security

• Requirements: JTAG hardware lock/authorized unlock, auto-re-lock on reset, and prohibition on reading keys/sensitive data via debug.
• Question: How is the DCSM (Dual Code Security Module) configured on the F280039 to lock the JTAG? Does it support one-time permanent locking? What is the unlock process? After a reset, does the JTAG automatically revert to the locked state? Can debug access read secure OTP/eFuse key regions?

Please refer to this doc on JTAGLOCK.

F28003x does support permanent JTAGLOCK (if a password of all 0 is configured). Otherwise, users can unlock the JTAG Lock Module (JLM) by entering a symmetric 128-bit password. Yes, after reset JTAGLOCK is automatically enforced by the DCSM. Debug access would only be able to read OTP regions if the DCSM zone is unlocked. 

f dd said:

5. Compliance

• Requirements: Encryption module compliance with FIPS 140 and CNSA standards.
• Question: Is the F280039's security module (or its software implementation) certified or compliant with FIPS 140 or CNSA? If not, what is TI's roadmap or recommendation for achieving this compliance?

I'm not sure about this. I will loop in a colleague to assist further.

Best,
Matt

1. Can we adopt CMAC (Cipher-Based Message Authentication Code) to implement the verification function for secure boot?
2. If CMAC is used for secure boot verification, is it mandatory to configure the boot mode to SECURE LFU FLASH?
3. Does TI provide any reference example or routine related to this implementation for our reference?

Hi ,
Expert currently is OOO , please expect a delay in response.

Hi,

While we wait for the other expert, I can help with your other questions.

f dd said:

Can we adopt CMAC (Cipher-Based Message Authentication Code) to implement the verification function for secure boot?

Yes, this is a valid approach. F28003x devices offer a secure flash boot mode in the Boot ROM, which authenticates the first 16KB after the flash entry point. This boot mode leverages an AES-128 CMAC algorithm. More details are provided in Section 4.8.4 Secure Flash Boot of the TRM.

f dd said:

If CMAC is used for secure boot verification, is it mandatory to configure the boot mode to SECURE LFU FLASH?

It is not mandatory. Secure LFU Flash boot includes bank selection logic based on metadata programmed at fixed offsets in the firmware image. Secure flash boot (non-LFU) would be fine.

f dd said:

Does TI provide any reference example or routine related to this implementation for our reference?

Please refer to the below document. It was written for F2838x devices, but the secure boot flow is the same for F28003x.

https://www.ti.com/lit/an/spract3/spract3.pdf

Best,
Matt

Hi, 

f dd said:

5. Compliance

• Requirements: Encryption module compliance with FIPS 140 and CNSA standards.
• Question: Is the F280039's security module (or its software implementation) certified or compliant with FIPS 140 or CNSA? If not, what is TI's roadmap or recommendation for achieving this compliance?

With regards to CNSA compliance, as of now, it is CNSA 1.0 compliant. We are working on making it CNSA 2.0 compliant, by adding support for ML KEM and ML DSA algorithms.

FIPS 140 is a system-level implementation standard, not a device certification. The F28003x and its associated security solutions have not yet undergone testing by an NVLAP-accredited laboratory. However, the F28003x is "Level 1 ready," meaning it provides the necessary foundation to build FIPS 140 Level 1 compliant security software. The F28003x lacks the physical security features required for FIPS 140 Level 2 and higher certifications.

Thanks,
Naren

Thank you Naren Siddharth M for the assistance. 

Please let me know if anything else needs to be clarified.

Best,
Matt