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.

CC3220S: Vendor Specific Certificate, OTP Write Error

Part Number: CC3220S
Other Parts Discussed in Thread: CC3235S, UNIFLASH

We want to use our own certificate.Hence followed the below document.
Vendor Device Authentication With SimpleLinkTm WiFi® Devices 

Part Number is CC3220S.

Able to create image using new certificate. While programming give below error.

What is the cause of it?

  • Hi,

    What chip are you using? the IC or module?

    If this is IC, what serial flash part are you using?

    Shlomi

  • CC3220S, our own board. 
    Serial Flash chip is GD25Q32C

  • Hi,

    You cannot use other serial flash than the one used in the module (which is macronix part).

    The OTP part of each serial flash may be different (size, commands, etc) so we support only this specific one.

    It is also highlighted under the 'minimum requirements' chapter (Serial Flash device: Macronix MX25R3235FM1IH0).

    Regards,

    Shlomi

  • Good info. Thanks Shlomi.

  • Thanks for your help above, still nesting the questions to have the context.
    If I understood correctly, secured way of OTA  update CC3220S chips in consumer products are following:

    1. Purchase the Certificates from Right CA ex. digicert etc.

    2. Use the Vendor specific Certificates. No cost. but it needs macronix serial flash for OTP.

    3. TI Dummy Certificates. But shared across, and hacker can be able to OTA the product.

    Am I missing any alternative for secure OTA?

    Also, if TI has any recommendation or partnership with CA.

    Which one to go for and how much it costs and work?

  • Hi,

    First option is not possible at CC3220S. Because you will not find CA which will able to issue compatible certificate. CC3220 devices does not support SHA-384 or SHA-512 for secured boot. If you want to use code signing certificate from CA, you should to use CC3235S where is SHA-384 or SHA-512 supported.

    Jan

  • and to add, not sure what you mean by dummy certificates. Can you elaborate?

    Once you have your root CA (or TI root Ca for that matter), there is no need for the dummy certificates anymore.

    You should use a "real" certificates that ends up with one of the root CAs in the catalog.

    Regards,

    Shlomi

  • dummy certificates are one which comes with TI.

    And about real certificates, Jan D is saying, we can't use it as it doesn't support the SHA-384 or SHA-512. 

  • THANKS for response. If that's the case, then how are we suppose to secure the OTA process of CC3220S?

  • let me check internally but if you are just in design stages, we strongly recommend to go for the CC3235 part.

  • Unfortunately, We already passed design stage. This is the big change to introduce now.

  • I see, no problem.

  • Hi Lokesh,

    If you have some older expired code signing certificate (like DigiCert SHA2 Assured ID Code Signing CA with SHA256RSA) you can use them for secure boot for your CC3220S devices. Bootlaoder at CC3220S does not validate expiration certificate. And if you not lost your private key for certificate, usage of expired certificate is fine from security stand point.

    Jan

  • Thanks for that. I will try to find the old certificates. But wouldn't that be vulnerable?

  • Hi,

    No. But it need to be your (your company certificate) and you need to keep private key in secret. If you will obtain somehow certificate and private key (e.g. downloaded from internet), this will be security risk.

    Jan

  • will check anyway if we can have a way to use newer certificates and let you know.

  • Also just to confirm.

    Can we use our own generated certificates without OTP Part?

    Can we directly put our own generated certificates to serial flash and use them?

  • OTP is not mandatory of course and it is used if you want to use your own root-of-trust (and catalog) to verify authenticity.

    As I mentioned above, it works with Macronix specific part only.

    If you use the TI root-of-trust (and catalog), you need to verify that the root CA is programmed to the file system and that it is a valid root CA in the catalog. Of course you would need to sign it in one of the authorized root CA vendors.

    The only part here that still requires investigation is the size of the digest which may be 384/512 with the new signings that CC3220 boot loader does not support. 

  • Hi,

    Answers to your questions:

    • Can we use our own generated certificates without OTP Part? -> Not for secured boot and signing firmware iamge. But you can use self-signed certificates for socket connection (TLS).
    • Can we directly put our own generated certificates to serial flash and use them? -> No. You need to program OTP part of sFlash using Uniflash (UART line). GANG programming of OTP part of flash is not supported. Certificates used for TLS connection can be programmed using sl_ filesystem API.

    Jan

  • CA vendors.

    Any update on size of digest? TI has the catalog it supports but don't have recommendation, that supports seamless integration with TI framework.
    Any recommendation of CA by TI?
    How smoothly we can use them?
    it's all confusing, as CA like digicert/globalsign, list's hardware token. what is that for?

  • Hi,

    There is no specific recommendation on a root CA by TI. You may pick any one from the list in the catalog (the ones that are not expired of course). 

    I am still exploring how to update the catalog.

    Just to clarify, the only lack of support that I know of for digest size larger than 256 is during boot (secured boot of the mcu image application). This is because it is done during boot loader mode that is ROM based. During runtime, there are patches to cover 384 and 512 so you should be fine (for example during SSL connection).

    Regards,

    Shlomi