• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 7 answers
  • Subscribers 40 subscribers
  • Views 606 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.

CC3220SF: Firmware Upgrade Specifics

Trevor Parsh
Intellectual 660 points
Part Number: CC3220SF
Other Parts Discussed in Thread: UNIFLASH

I am working with a system that requires that I deviate from the already written OTA process that TI provides. So, I've been scouring code and documentation trying to figure out how to make a process that makes the TI part and the product needs.

For the most part I am comfortable with a solution that has been worked up, but there are a few topics I'm held up on:

  1. Is it possible to update user files, service pack, M4 image, and certificate catalog all in one upgrade?  Based on our current upgrade definition, we need a way to do this. If we cannot, then the system becomes much more complicated, which I want to avoid if at all possible.  The method does not have to be a pre-canned TI library or anything (like the OTA lib), just need to know if there is any way at all to do this.
  2. I am curious as to how the M4 MCU image transition occurs during an update.  Reading through TI provided code, it seems like the MCU image must be a part of a bundle, the MCU must be soft restarted (through hibernate method or power recycle), the new M4 image is loaded into XiP flash, the new image runs, the M4 image being executed must then commit or rollback to the old image (or power recycle/reset forces a rollback).  Is my uinderstanding correct? Is there a document/description somewhere that lays this out? One last thing on this topic, if I'm right about a reset being the mechanism for the image switching over, I'm curious how the M4 and NWP negotiate and are brought up to have the M4 image loaded with a new image. Any information on this? This is not a huge deal, but I have to imagine there's information out there on this process.

Cheers,
Trevor

  • 0
    TI__Guru 63006 points

    Hi Trevor,

    1. If you are using the auto-generated tar files (Uniflash OTA image), you'll need to have a dedicated tarball for updating the Certificate Catalog. All the rest of the files (MCU image, SP and user files) can be handled within a single bundle (i.e. updated together within a single tarball).

    The code that parses (and installs) the tarball is available in OtaArchive.c. It includes the authentication and integrity verification of the full OTA content. 

    2. You are basically right about the procedure. It is required that you call sl_Stop (and wait until it completes) before performing the MCU reset. Stopping the NWP (with the sl_Stop call) will mark the new bundle in "Test" mode. Once the MCU bootloader is triggered following the reset, it will detect the "Test" mode and will copy the new image to the the internal XiP flash. The bundle state will then be updated to "Pending Commit" and a watchdog timer will be set. If the bootloader detects the "Pending Commit"  state - it will trigger the bundle reversion.

    For details, please refer to the  "<SDK>/docs/simplelink_mcu_sdk/Over_The_Air_Update_Guide.html".

    Br,

    Kobi

     

     

  • 0 in reply to Kobi Leibovitch
    Intellectual 660 points
    Thanks Kobi. I'm good on question 2.

    For question 1, the following is stated in the document that you reference:
    NOTE: In case the certificate catalog is needed to be part of the ota tar files, two step ota is required. The first tar file should include only the certificate catalog .lst file and its signature under directory 1. The second one should include the mcu image, service pack and any other file which are required under directory 2.

    What drives this requirement?

    Like I said, we cannot use the TI provided OTA library as is. I am in the process of writing a different process that plugs nicely into a different infrastructure. If would be good if we could have a single bundle file that contains all files (certificate catalog included). If not, the upgrade system becomes more complicated, which I want to avoid.

    One more related question:
    3. What does the process look like for updating the digital signing certificate used to sign the M4 image? If the certificate catalog is updated first before the M4 image and digital code signing cert + chain, then is M4 image invalidated causing the system to brick? The code signing cert will need to be updated before end of life of some products and will need to be field updatable since the root CAs that serve as the root of trust will not last forever.
  • 0 in reply to Trevor Parsh
    TI__Guru 63006 points

    Hi Trevor,

    After the new certificate catalog is installed it requires an MCU reset so the device will reload the new content in order to use it with files installed later (this breaks the OTA procedure).

    The updated catalog is supposed to include all the previous supported root CA certificates (that are not revoked). So the existing root of trust is expected to work on the updated one (again, unless the certificate was revoked).

    If you deal with a revocation, then you'll need first to replace the revoked certificate with a valid one that is supported by the existing catalog. Then switch to the new catalog. Only once the new catalog is installed, you'll be able to switch to one of the new root CA certificates that were added.

    The certificate catalog includes ~100 root CA so you should be able to find an alternate valid root of trust in case your current one expires.

    We are not expecting that the catalog will be updated frequently.

    Note that you can also use the vendor specific catalog (see http://www.ti.com/lit/ug/swru547a/swru547a.pdf) and manage the catalog yourself. This MCU reset will still be required after an update is installed,

    Br,

    Kobi

      

  • 0 in reply to Kobi Leibovitch
    Intellectual 660 points

    Certificates may either be revoked intentionally or be invalid after their expiration date.  For example, one of the code signing certs that I currently have access to will expire in 4 years. The intermediate cert expires in 6 years. So, most systems would have it such that a signature on a piece of data would fail to verify after 4 years pass.

    As I understand it, the NWP disables the expiry date when validating the MCU image on boot because there is no way for the NWP to have the current date-time.  So, this being true, if any cert in the chain from the vendor's code signing cert up to the root CA has expired a code signing verification will pass in the NWP anyhow.

    However, if the root CA is not in the TI cert catalog because it has expired and been replaced by a new serial number (therefore has a hash in the cert catalog that will not match the old CA's hash), then I need to be able to account for this in our code signing cert process.

    I could manage our own certificate catalog, but really do not want to if at all possible.

    WRT updating the certificate catalog:
    The new cert catalog takes effect after a reset correct?  The signature verification on the M4 MCU image occurs as soon as the file is closed (so, before a reset may occur) and every time the power is recycled?

    If the last two questions' answers are "yes", then it would be true that the only way that an entire bundle could be brought down, cert catalog included, would be to store files that require CA certs that are only in the new cert catalog in a temporary file. Meaning, at the very least I'd have to have an extra 1 MByte of NVM available to store the M4 image temporarily.  This make sense?  I'd really like to have a way to put all files into the system where they either need to go without either having a path for getting the latest cert catalog and one for everything else or need to have this extra space for temp storage (which I can't do on the platform I'm working with.

  • 0 in reply to Trevor Parsh
    TI__Guru 63006 points
    The code signing verification happens only when the image is written to the file system (an internal integrity check will then be used during every boot).
    The expiry time (which as you mentioned won't be checked by the NWP) can be referred as another source of revocation.
    Again, once you use expired or revoked root certificate - you should replace it with a valid certificate that is already available in the existing catalog (there will always be many options to choose from). If the certificate is still valid when TI publish an updated catalog - it will still be supported by the new update.
    Once a new catalog will be published by TI (and installed by you), you'll have more options of root certificates to choose from.
    I'm not sure i completely understood your method using the temporary file. Supporting one OTA image that includes the certificate catalog is possible but the solution will be complicated. I'm not sure it is required for such an edge case.

    br,
    Kobi
  • 0 in reply to Kobi Leibovitch
    Intellectual 660 points
    I do think it's relevant though. Not really an edge case. Every single device that gets unleashed into the wild will need to have it's code signing cert and cert chain updated in a sufficiently short amount of time, <20 years from now. If someone comes up with some asymmetric key solution that allows the keys/cert live got 200 years I no longer care about what I'm talking about.
    I'll break down the temporary file scenario. But first, based on what you said in the last post, I think I've just got two options:
    1. Use a temporary file
    2. Upgrade the cert catalog and then all other files (the way the TI implemented OTA process currently works)

    To clarify the temporary file concept, this is what the flow looks like:
    1. Grab upgrade bundle (TAR formatted) from a remote source. Includes files, including cert catalog.
    2. As the bundle comes in, store off secure-signed files (e.g. M4 image) to a temporary file. All other files are written to the file that they're supposed to be.
    3. Reset the processor. The cert catalog will be committed and therefore updated at this point.
    4. Move all secure-signed files to where they're supposed to go (e.g. M4 image goes to sys/mcuflashimg.bin from whatever temporary file/location it was stored in prior to cert catalog upgrading)
    5. Restart system then commit the the new M4 image
  • 0 in reply to Trevor Parsh
    TI__Guru 63006 points
    Your method can work. It is too complicated in my mind.
    By "edge-case" i meant to the case you need to update your root of trust and must (?) use a root certificate which is available only in a new catalog that was just published (this is the only case that will require updating the catalog and certificate together). In such case you will need to either use a temporary root certificate (that is supported by both old and new catalog) or use something like your temporary file concept.

    In the standard case, when your certificate is revoked or expired, you will choose a valid one (with couple of years till expiration) from the exiting catalog list. When a new catalog is published, you simply update it which wouldn't impact your root-of-trust (if it is valid - it will still be part of the new update). The new catalog will enable more options for root certificates, that you may use the next time you'll need to update your root of trust.
  • 0 in reply to Kobi Leibovitch
    Intellectual 660 points
    so, to make sure I understand correctly:
    I can update all files in the system (including the certificate catalog) so long as the old cert catalog has the code signing certificate's root CA's hash in the old cert catalog?

    The file updating process, the order the files are pulled from the upgrade bundle and loaded into the CC3220's file system, would be this?
    1. (things related to manifest)
    2. Code signing cert and cert chain
    3. M4 mcu image
    4. NWP Service Pack
    5. Other files
    6. Certificate catalog

    Items 3, 4, and 5 should be able to be ordered in any way.
  • 0 in reply to Trevor Parsh
    TI__Guru 63006 points

    Certificate Catalog is signed by TI private key - its installation is not related to the existing cert catalog.

    It can be updated, but it must be installed in a dedicated OTA procedure.

    All the other file can be updated in one bundle.

  • 0 in reply to Kobi Leibovitch
    Intellectual 660 points
    Why does the cert catalog have to be a dedicated update procedure? So, we are forced to essentially go through two upgrade cycles when the cert catalog needs updated and other files need updated? Can you please explain why, specifically? I am not concerned if application level TI code does not support a single upgrade path, I just want to know what restrictions and requirements drive what possible upgrade paths are available to any CC3220 application.
  • 0 in reply to Trevor Parsh
    TI__Guru 63006 points

    Hi Trevor, 

    Everything was explained before. The main issue with the update of the certificate catalog is the MCU-reset it requires.

    Br,

    Kobi    

  • 0 in reply to Kobi Leibovitch
    TI__Guru 63006 points
    A small correction...
    If the certificate you use for the verification of the secure files and/or the MCU image was signed by a root CA that is part of the old catalog - you may add a new catalog as part of a standard bundle (i.e. everything can be updated in one standard process).
    The secure file (and/or MCU image) will be verified against the old catalog and the new catalog will be activated (with the rest of the updated files) only after the reset.
    In such case the only limitation is the way Uniflash prepares the tar image. If you add the catalog manually or create your own OTA image, this should work.

    Br,
    Kobi
  • 0 in reply to Kobi Leibovitch
    Intellectual 660 points

    Thank Kobi. That's exactly what I need to know!

    One last thing before I close this thread down, want to be sure the following is true.

    We talked about how a secure-signed file is checked on file close and then every time there is a power/hibernate cycle (I assume these are all 'boot' cases that you mentioned).  From the below snippit from section 5 of the document  , It seems like file verification on read (on boot) uses a hash that is encrypted by an AES key or something. Meaning, after file close, the validity of the file is only checked (on boot or file read) by checking a hash that is encrypted, and not checking against the signature that was originally passed in during file write.  Want to make sure this is true, because if not and the original signature is used, then after a cert catalog update, the M4 core would be disabled from running I imagine, unless the M4 image was updated (using a new code signing cert) before updating the catalog.

    1. Authenticate a file cryptography based on PKI during programming and updating of a file.
    2. If this step passes, calculate a digest for the file and store it encrypted.
    3. Verify the integrity of the file every boot based on the calculated encrypted digest.

  • 0 in reply to Trevor Parsh
    TI__Guru 63006 points

    Yes, this is true.

    A secure file (including MCU image) is authenticated (i.e. its signature is verified against the certificate chain) only when it is being written to the FS (during OTA).

    Upon power/hibernate cycle, only the file integrity is verified (using the digest as you mentioned).

    Br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Intellectual 660 points
    Thank you very much for all your help Kobi. You and TI have been and continue to be very helpful.

    Trevor