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.

CC3200-LAUNCHXL: dummy certificate/certificate playground

Part Number: CC3200-LAUNCHXL
Other Parts Discussed in Thread: UNIFLASH

Can a device that has been programmed with a firmware image with valid signed certificates be re-programmed with the dummy certificate from the certificate playground for development?

  • Hi Alan,

    I believe I know what you're talking about; you're referring to programming via Uniflash perhaps, and you want to switch from flashing one image secured with your vendor certificates to flashing an image secured with the dummy ones instead?

    If that's the case, can you make sure to switch to using default trusted root-certificate catalog? It should be a "Files" option in Uniflash. 

    Feel free to let me know if you encounter additional issues.

  • Hi,

    Yes, just wanted to check that if the default trusted root-certificate catalog is used it can be reprogrammed over an image that has been programmed using our secure vendor certificate.  If that is true, that answers my question.

    Thanks.

  • Hi Alan,

    Yes, you can pick between default flow (using TI's certificates etc.) or custom flow (using vendor certificates etc.), but once you pick the custom flow, you must sign secure files by vendor chain of trust. You can always switch back and forth between using TI's verification and vendor OTP as you please.

    The only caveat is once you set the vendor OTP, you cannot set it again.

  • Hey BLiu,

    What we are observing is that we are still above to overwrite the firmware image with a dummy trusted cert even after the vendor certificate and OTP have been enabled and programmed. Is this expected behavior?

    Thanks,
    Brian

  • Hi Brian,

    Can you send me a picture to allude to what you are talking about? 

    Are you saying that even with a configuration like this where the default certificates are not a part of the vendor catalog, you are still able to program your device with the dummy trusted certificates?

  • If we have programmed a device with otp set as indicated in the screenshot, then if we go in and create a new project with a different firmware image and utilitze the playground certificate store and the dummy certs with OTP unchecked, will that image be able to be programmed into the device?

  • Hi Alan, yes, but please enable the box for "Use default Trusted Root-Certificate Catalog" unless the dummy certificates are part of your vendor catalog.

  • Yes, correct we did do that.  

  • Hey BLui,

    It sounds like signing with the dummy/playground files is always an option, even after vendor signing and OTP is enabled. Am I understanding correctly? For cybersecurity, we would like to enforce only our firmware can be loaded and a malicious user could not upload a new package.

    Thanks,
    Brian

  • Hi Brian,

    Are you interested in the CC35xx device? It provides the security features you are looking for as once the root of trust is set, it can never be changed ie. if set using vendor credentials, the device can NEVER be programmed TI default credentials. I am still looking into your inquiry regarding this for the CC32xx but I know the CC35xx will definitely fulfill your needs. 

  • BLiu,

    Please let me know what you find on the CC32xx.

    Is the CC35xx a drop-in hardware and firmware replacement?

    Thanks,
    Brian

  • Hi Brian,

    This is the CC32xx information I have for you after an internal discussion. 

    As discussed before, you can either have TI default authentication or using vendor OTP. You can switch between the two authentication methods in Uniflash under development mode but once you set to production mode on the OTP, you cannot go back unless you reprogram the flash (with access to UART and SOP lines). 

    For your CC35xx question, I have the information somewhere but I need to dig it up.

  • Hi Brian,

    No. CC35xx is not a drop in replacement (hw/sw) for CC32xx. It is competently new platform.

    Jan

  • Hi Brian, 

    I found the information; similar to what Jan said, CC35xx is not a drop-in replacement. However, at the very least, the software architecture and APIs are similar. You can see the SDKs available here.