• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 40 subscribers
  • Views 305 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: Minimum Key Size for Code Signing Certificates Increase to 3072 Bits

Mark Johnson25
Intellectual 755 points
Part Number: CC3220SF
Other Parts Discussed in Thread: UNIFLASH, CC3120

The CA/B Forum has mandated that the minimum Code Signing Key size increase to 3072 bits as of 06/01/2021.  The CC3220SF boot ROM only supports 2048 bits.

Can you provide some guidance for how to use the CC3220SF under these circumstances?  An FAQ and an appnote would be helpful.  I have been searching the forum and have found these links:

1. This forum post says to just find another code signing certificate provider. 

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1042210/launchcc3220modasf-operation-failed-image-creation-failure-error-signature-file-size-exceeded-the-actual-size-is-384-bytes-while-the-max-supported-signature-size-is-256-bytes

Can TI suggest a provider?  Or become a provider for it's customers?

Vendor

Notes

comodosslstore.com     

3072 bits only

www.ssl.com

3072 bits only

digicert.com

3072 bits only

Thawte

Now DigiCert

Symantec

Now DigiCert

globalsign.com

Waiting for response

2.  This post mentions creating a private catalog: https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1045696/cc3235modsf-code-signing-certificate?tisearch=e2e-sitesearch&keymatch=code%25252520signing%25252520key

using Vendor Device Authentication With SimpleLink WiFi® Devices

I need some time to digest this information.  Will it support public encrypted sites?  The Playground catalog does not.  My current understanding is that the catalog needs to be signed by the CC3220 or CC3235 private key (which is why they have different catalogs).

3.  This post says that it doesn't matter for my product because an expired Code Signing Cert is fine since the device doesn't know the current time when it's booting.  The expiration date is ignored.

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/878184/cc3220sf-obtaining-certificates-for-production-for-secure-boot

That would be an issue for new customers and might raise questions in security audits.

Thank you,

Mark

  • 0
    TI__Guru 56345 points

    Hi,

    1. TI is not a provider so we cannot offer this service. I am not aware of specific authority that can still offer a 2048 key but in case there is one, you can definitely use it.
    2. you can use a private catalog using the OTP in the serial flash. All it does is to replace the catalog certificate that is offered by TI and enables the customer to have a full control of what root CA certificates are introduced into the catalog. In this case, the  customer needs to generate a public key and private key and store the public key in OTP (this key is used instead of TI public key that is in ROM). This option still allows connecting to secured sites and has all the benefits of using TI catalog (so it is seamless). The solution in this case would be to store the new root CAs (that support a key that is greater than 2K) but also keep a self signed root CA that uses a 2K key just for the mcu image that can bypass the limitation during production. Please note that the NWP has the 4K key support during OTA for example. The limitation is only during production since the boot loader does not support 4K keys.
    3. the device does not check expiry time for certificates that are used for file system operations (only for connecting to secured sites). It may raise questions but it is not a real security breach since the certificates used for the file system are in full control of the user who stored these and there is no server that sends a certificates chain for authentication as the chain is already on the file system.

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Guru 73205 points

    Hi,

    Just a quick comment to point 2. Usage of OTP catalogue have one big disadvantage. OTP catalogue can be written by Uniflash software only (via UART). That means production programming via Embedded programming or Gang programming does not work in this case. And this can complicate mass production.

    Jan

  • 0 in reply to Jan D
    Intellectual 755 points

    Please confirm, option 3, allowing the code signing certificate to expire will not impact device programming or OTA updates after expiration.  If so, this seems like the best option for those of us with existing code signing certificates.

    For option 2, would it be possible to update the OTP for deployed devices?  Where is OTP programming documented?  We currently refer to  SWPA230A, "CC3120 and CC3220 SimpleLinkTm Wi-Fi® Embedded Programming" for device programming.

    Thank you,

    Mark

  • +1 in reply to Mark Johnson25
    TI__Guru 56345 points

    Hi,

    I see that my manager opened a private channel over Email but just to complete your queries to the broad audience:

    1. I confirm. Even when it expires, for file system authentication purposes, the date is not checked.
    2. you can read through the vendor catalog certificate document, https://www.ti.com/lit/ug/swru547a/swru547a.pdf?ts=1642661114802&ref_url=https%253A%252F%252Fwww.ti.com%252Fsitesearch%252Fdocs%252Funiversalsearch.tsp%253FlangPref%253Den-US%2526searchTerm%253DVendor%2BDevice%2BAuthentication%2526nr%253D637
      Embedded Programming is not relevant in this case.

    The only way to use the vendor catalog option is via Uniflash programming so deployed devices cannot get updated. Only new ones.

    But, if you go for the option where TI signs the custom trusted catalog for the customer, you can use the usual OTA procedure as today (i.e. not going for the OTP approach).

    Regards,

    Shlomi