• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 40 subscribers
  • Views 292 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.

Original question:

CC3220SF-LAUNCHXL: CC3220 Secure Bootloader/Filesystem

CC3220SF-LAUNCHXL: CC3220 Secure Bootloader/Filesystem

Arnaud Moeschwitzer
Intellectual 785 points
Part Number: CC3220SF-LAUNCHXL

Hi Kobi,

you said:

"For development - we provide the dummy "playground" cert store that will enable you to use our proprietary certificate chain. For production - it must be a valid certificate." in https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/582674?CC3220SF-LAUNCHXL-CC3220-Secure-Bootloader-Filesystem

But i have done my own research. I think it is a advice from ti that vendor shouldn't use playground certificate for signing images in production because everybody with access to playground certificates can sign a image which will then be accepted from the bootload or the host mcu. I have tried production mode flashing via spi and with playground certificates it worked in production mode.

But a own certificate one trusted by a well known ca or a complete self certificated chain is only needed if i want to surpress installing and running other images which aren't from me. But what is happening to encryption e.g. secure files i think they won't be affected if somebody is using playground certificates because encryption will be done by the unique id in nwp which isn't public. Are me thoughts correct ?

BR,

Arnaud

  • 0
    TI__Mastermind 40965 points

    Hi Arnaud,

    Yes, the serial flash encryption of secure files is performed on each file marked with the 'secure' flag irrespective of the cert used to authenticate the image. As the serial flash encryption is based on a unique key per CC32xx device, any attacker who tries to read the serial flash directly will not be able to recover the MCU binary. Also, the attacker will not be able to directly tamper or overwrite the MCU binary through the serial flash.

    However, the CC32xx itself can decrypt its own secure files. Having non-playground certificates is critical in ensuring that MCU binaries and other secure files are authenticated correctly for the secure boot process. If you were to use the playground files in production, you would be much more vulnerable to attacks such as malicious OTA updates, where the CC32xx is tricked into overwriting secure content. Normally, the CC32xx will use your cert, stored on serial flash from the production line programming process, to decrypt and verify the MCU binary signature. If the playground files are used, then those authentication checks will always succeed.

    I strongly advise you not use the playground certificates in production for the reasons above. Let me know if you need more clarification or have further questions on the CC32xx secure filesystem.

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Intellectual 785 points

    Hi Michael,

    i am aware of the potential risks by using playground certificates. I don't want to use it i only would say that it is possible, this isn't described well imho in the documents there is no check which will prevent somebody using playground certificates.

    Thank you for your answer.

    BR,

    Arnaud