• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 334 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2434: Secure Boot: Binding to External SPI Flash and Anti-Rollback Mechanisms

Matej Liska
Prodigy 130 points

Part Number: AM2434

Hello,
I am working with the AM2434 Sitara processor using an external SPI flash. For our cybersecurity compliance, we need to verify the mechanisms that prevent unauthorized hardware or software changes. Specifically:
  1. Memory Chip Binding (Unique ID): Does the AM243x secure boot process support binding the bootloader or application image to a unique hardware ID of the external SPI flash? If so, which services are used to verify this ID before proceeding with authentication?
  2. Authentication Mechanism: In an HS-SE (Security Enforced) device, how does the ROM Bootloader ensure the integrity of the image stored in external flash if the physical chip is replaced with one containing a cloned but validly signed older image?

Thank you for your guidance on meeting these cybersecurity requirements. 

Matej.

  • +1
    TI__Guru* 84401 points

    Hello,

    The ROM or SYSFW authenticates the image independently of the boot media. The boot media only serves as the storage for the image. As long as the image is signed correctly and not corrupted, the authentication would pass.

    To prevent booting an older valid signed image, you would leverage the Software Revision (SWREV). The ROM parses the SWREV from the SBL's certificate and compares it to the one programmed in the efuses. If the SWREV extracted from SBL's certificate is smaller than the SWREV value programmed in the efuses, the image would be rejected even if it is signed with the correct key.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 130 points
    Hello Prashant,

    Thank you for the clarification.
    Based on your response, it seems the standard Secure Boot process ensures the integrity and versioning of the code, but does not inherently provide a hardware-to-hardware bond between the SoC and the specific SPI flash instance.
    In a scenario where a flash chip is desoldered and replaced with another chip containing an identical, validly signed image with the same SWREV, the ROM bootloader would not detect this hardware swap - security risk.

    Is it possible to implement a secondary verification step? For example, could the SBL be configured to read the Unique ID (UID) of the SPI flash and verify it against a value stored in the SoC's UID?

    Regarding the Software Revision, could you provide us more information about incrementing the SWREV value in the eFuses after a successful firmware update? We need to know which TIFS/SYSFW services or API calls should be used by the application or SBL to permanently burn the new revision to the hardware SoC.


    BR,
    Matej.
  • 0 in reply to Matej Liska
    TI__Guru* 84401 points

    Hello,

    Matej Liska said:
    In a scenario where a flash chip is desoldered and replaced with another chip containing an identical, validly signed image with the same SWREV, the ROM bootloader would not detect this hardware swap - security risk.

    Yes, it will not detect. May I know the security risk you envision from this? Even if the flash chip is replaced, it is your valid firmware that would be running on the device.

    Matej Liska said:
    Is it possible to implement a secondary verification step? For example, could the SBL be configured to read the Unique ID (UID) of the SPI flash and verify it against a value stored in the SoC's UID?

    I am not sure what you mean by "a value stored in the SoC's UID".

    There is no onchip non-volatile storage available other than the Extended OTP (384 bits) which could be programmed with any data and read at the runtime for any usages.

    For the SWREV update, please see the following guide

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_02_00_24/exports/docs/api_guide_am64x/EXAMPLES_RUNTIME_SWREV.html

    https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/otp_revision.html

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 130 points

    Hello Prashant, thank you for information,
    based on this information maximum OTP_REV_ID_SEC_BRDCFG is 64 so we could do maximum 64 fw upgrades am i correct?

    Thank you,
    Matej Liska.



  • 0 in reply to Matej Liska
    TI__Guru* 84401 points

    Hello,

    Matej Liska said:
    based on this information maximum OTP_REV_ID_SEC_BRDCFG is 64 so we could do maximum 64 fw upgrades am i correct?

    That is correct. Please note this is the SWREV field for Board Configurations blobs. There are separate SWREV fields for the SBL and the SYSFW.

    Regards,

    Prashant