• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 30 subscribers
  • Views 218 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.

MSPM0L1228: Boot and Startup Sequence

Alessandro Di Vincenzo
Prodigy 20 points
Part Number: MSPM0L1228

Tool/software:

Hi, 

In my company we are developing a project having M0L1228 microcontroller. I have a question regarding Secure Boot schema available in the microcontroller chosen, described from TRM chapter 4.1.

As far as I understood, STEP 1 purpose is only to configure protection like Debug Security, Mass Erase or policies for Bank Swap.

In STEP 2 instead, Customer Secure Code is responsible for determining execution bank and secure key initialization. Given that CSC is developed by us, let's consider that it also set the CMAC value of the main application by using one of the key set. It happens only the first time it is executed, the second time the main application is called.

Is my interpretation correct? At which phase main application integrity is verified against its CMAC value using the corresponding key set? Is an additional bootloader needed for this verification or can it be managed by CSC every time execution restart?

Thank you in advance for your response,

ADV

  • 0
    TI__Genius 16000 points

    Hi Alessandro,

    Your interpretation of steps 1 and 2 is generally correct. In sections 4.1.1 and 4.1.2 of the TRM you can see more details of which exact policies are applied during each step.

    For your question, the exact authentication method is up to you, in our example we use ECDSA to authenticate the application image when operating in trusted/privileged mode. Then again in unprivileged / untrusted mode we again check the SHA hash to verify again. 

    I would highly encourage you to take a look at the Customer Secure Code User's guide, located in the SDK in the path: 

    [SDK Install Path]/docs/english/middleware/boot_manager/doc_guide/doc_guide-srcs/customer_secure_users_guide.html

    This actually walks you through our CSC example and code, showing much more detail on the specific steps taken in CSC. I think this will resolve most if not all of your current questions of how this works in our devices.

  • 0 in reply to Dylan OBrien
    Prodigy 20 points

    Hi Dylan,

    Thanks for your reply. I have another question: I know from the TRM that the micro have HW accellerator for AES. Does it also support ECDSA and SHA or an external SW library is needed for those?

  • 0 in reply to Alessandro Di Vincenzo
    TI__Genius 16000 points

    Happy to help.

    The AES accelerator in these devices does not have support for ECDSA and SHA. You need an external SW library to perform these functions. In our CSC example you can see we use an external library for the SHA and ECDSA functions.

  • 0 in reply to Dylan OBrien
    Prodigy 20 points

    Thank you Dylan.

    Last question I have is: is CSC a one-time executable? Is it used only for initialization? 

    What if I need to rewrite the CMAC values after a SW update?

  • 0 in reply to Alessandro Di Vincenzo
    TI__Genius 16000 points

    Hi Alessandro,

    The CSC will execute every time the device starts up. However whether the device is in privileged or unprivileged mode will depend on whether INITDONE is asserted as described in the user's guide. So short answer is no, it is not a one time executable.

    You will need to recalculate the CMAC when a SW update occurs, so that you are able to recalculate the CMAC during runtime and compare to the stored value. If you did not update the saved value then you would always fail to pass the CSC as the failed CMAC comparison would indicate that the SW image is different than the one you originally loaded and is therefor not trustworthy. 

  • 0 in reply to Dylan OBrien
    Prodigy 20 points

    Hi Dylan,

    So the bootloader, that verifies main application integrity against CMAC stored, shall be part of the CSC? 

    Is it anyway possible for the main application to use key set in KEYSTORE? 

  • 0 in reply to Alessandro Di Vincenzo
    TI__Genius 16000 points

    Our CSC example does not contain a bootloader, you may choose to use the ROM bootloader or define a custom bootloader. The CSC example shows the process of starting up and verifying the application image before running it, and it includes the features such as read and write protection to lock down the necessary flash segments after exiting privileged mode. A designer may choose to run the CSC, then have the application image include a custom secure bootloader. The CSC itself is not a bootloader.

    It is possible for the main application to use the keys in KEYSTORE. In the CSC example, the keys are transferred into KEYSTORE then read protected. So the application can't simply grab them from flash and use them. However once they are stored in KEYSTORE they can be used in the AES accelerator and used by the application, but not read out.