• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 42 subscribers
  • Views 349 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC3220SF: Custom Factory Default Process

Trevor Parsh
Intellectual 660 points
Part Number: CC3220SF

Hola,

Many months ago it was decided that using the TI provided factory default would not work for an application I am working on.  The reason being that we load security and calibration related files that must never change on each unit coming off the production line.

So, we have implemented a custom factory default process.  As one might expect, the sflash stores an encrypted file that holds all relevant information and files required to perform a factory default. This all works fine right now and we have no issues with the process working currently.

However, we will have issues in the future when the root CA in the TI certificate catalog expires years from now and now the factory default image can no longer be used.  There are two possible solutions to this:

  1. Make sure that we always force an update of the factory default file at the same time as an update of the TI certificate catalog occurs. We'd also need to make sure that on the back end that an old factory default image is never pushed to the device.
  2. We force the TI certificate catalog to downgrade to a version that has the root CA that is the root of trust for the code signing cert used to sign the mcuflashimg.bin file.

From what I currently know, there is no way to downgrade the TI certificate catalog.  This is true, correct? if so, we are forced to go with option 1.

Also, I believe the only way that the TI-base factory default can work is by loading the TI cert catalog that existed at time of factory default image creation.  To my knowledge, the only way to do this is to wipe SPI flash, which would make sense as I know all user files are wiped out on factory default (which is why we cannot use it).  So, I imagine in this case the cert catalog is not 'downgraded' in the traditional sense, it is loaded into a file system that does not have the cert catalog before the file open/create operation is performed inside the NWP.  Is this correct? If not, what am I missing and/or not understanding?

Cheers,
Trevor

  • 0
    TI__Mastermind 28285 points

    Trevor,

    Let me look into this and get back to you.

    Best,

    Vince 

  • 0 in reply to Vincent Rodriguez
    TI__Mastermind 28285 points

    Trevor,

    To make sure I am on the same page, your asking the following the question: when a Root CA in the TI cert catalog eventually expires, what should you do to update this cert catalog without having to wipe the entire file system?

  • 0 in reply to Vincent Rodriguez
    Intellectual 660 points

    Not upgrade necessarily. Sorry for the delayed response btw.

    The short of it is that we want to know if there is a better way than what we are currently proposing to implement factory default capability outside of the TI provided capability as it does not fit the needs of the product. The main concern is the following situation:

    1. Product off the line has a factory default image that has an mcuflashimg.bin signed with some code signing cert with a root of trust in the cert catalog of the CC3220 at that point in time.
    2. Some time later, we update the certificate catalog because cert expire and new ones are added to the catalog.
    3. Some time after that a user factory defaults the device.

    I proposed a solution, but it is not fantastic as we are heavily sflash space limited.  So, we have trade offs around reserving space for future mcuflashimg.bin file updates and factory default file (on the sflash) updates.  Ideally we can downgrade the certificate catalog without wiping flash out so that we never have to change the factory default file and can have the max size set to the size of the factory default image put on a device on the production line.

  • 0 in reply to Trevor Parsh
    TI__Guru 63006 points

    Hi Trevor,

    I'm not sure I understood where the original factory reset method fails for you. 

    Your solution (of updating the factory image whenever the catalog gets updated) will solve the problem.

    The catalog cannot be downgraded (other than by using the original factory default method).

    There are couple or other methods that might work for you (especially if flash space is a concern:

    1. Use a vendor-specific catalog (see http://www.ti.com/lit/ug/swru547a/swru547a.pdf) - where you can control the content of the catalog so you'll never remove the certificate that signed the factory image (note that the device never verifies the validity date of code signing certificate). Note that currently, this method doesn't support gang programming.

    2. Use the original factory image but make it just an extension to the bootloader that is responsible to load the functional image.

    i.e. the factory image will load other file from the file system (i.e. your current image) and this just make sure the original catalog is in place.

    Such factory image can also be used to trigger an OTA to bring the functional image over the network.

    Br,

    Kobi