• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 39 subscribers
  • Views 734 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:

CC3220: How to make my own certificate is known by cc3220 when creating and programming image?

CC3220SF: CC3220SF self signed root certificate stored in OTP (one time programming) flash area.

Steve Kranz
Intellectual 620 points
Part Number: CC3220SF
Other Parts Discussed in Thread: UNIFLASH, CC3100

With regard to public security certificates that I'll need to store on the [CC3220SF] device (and along with it the associated device Certificate Catalog), I've been seeing some conflicting information that makes me want to double check that I can indeed create my own company specific private key (using openssl tools) and my own company specific self signed [der format] root-ca certificate (using openssl tools) that I then store into the CC3220SF's OTP (One Time Programming) portion of flash (using UniFlash GUI tool or the UniFlash dslite.sh command line tool). And along with this to create my own company specific device Certificate Catalog (using TI UniFlash tools). In this arrangement my company specific self-signed root-ca can then be used by the TI system (under the hood) infrastructure to authenticate an MCU image retrieved from a DropBox folder (or Git Server) using the TI supplied example OTA (Over The Air) programming logic that's been integrated to my company specific CC3220SF application? If my only intent is to authenticate MCU images delivered via OTA can I get by with just the single public certificate (root-ca) stored in the OTP or do I need to also store an additional company specific public certificate on the device (trusted-ca) that resides in normal flash (top level directory) and which itself is signed by the private key associated with the company specific public root-ca stored in OTP? If this [two certificate chain] is needed, then I assume the MCU is authenticated by the trusted-ca and the certificate filename of the trusted-ca is itemized in the ota.cmd file as part of the block of lines describing the MCU image. But if it's actually ok to skip the second certificate in the chain (e.g. skip the the trusted-ca) and instead have the MCU authenticated via the single OTP based root-ca then how is that certificate itemized in the ota.cmd file? Is there a special filename for the certificate located in OTP? I want the minimal configuration required to authenticate MCU images received via OTA and I don't want a public root-ca purchased (and signed) from a well-known CA. Our product will not implement an HTTPS server so I'm thinking that we can do the self-signed company specific root-ca stored in OTP -- the only HTTPS operations our product will be doing is as a client connecting to a remote HTTPS server for reaching out to the DropBox server during OTA retrievals of a new MCU image; for that we'll have the DropBox public certificate copied over (as either a *.der for a *.pem) and installed on the device filesystem (top level directory) with the same filename as referenced by the OTA_SERVER_ROOT_CA_CERT define of otauser.h. I've really tried hard to search through all the documents and study things before asking this question but for some reason I'm still missing something and will appreciate some clarification. Thanks in advance!

I have studied the following documents:

SWPU332A SimpleLink™ Wi-Fi®CertificatesHandling
www.ti.com/.../swpu332a.pdf

SWRU547A VendorDeviceAuthenticationWithSimpleLink™ WiFi®Devices
www.ti.com/.../swru547a.pdf

SWRU558 SimpleLink™ Wi-Fi®CC3100,CC3200UniFlash
www.ti.com/.../swru558.pdf

SWRU469G UniFlashCC3x20,CC3x35SimpleLink™ Wi-Fi®and Internet-on-achip™ SolutionImageCreatorandProgrammingTool
www.ti.com/.../swru469h.pdf

  • 0
    TI__Guru 64455 points

    Hello,

    The concept is to provide the customer with an equivalent root-of-trust certificate as TI has in ROM which resides in the OTP section (and thus behaves as ROM).

    The servicepack is still signed with TI root-of-trust but the catalog is now a vendor catalog that is signed by the vendor root-of-trust.

    Any new file, as well as the mcu image is signed with at least one certificate that should end up in the catalog. So in your example you can sign the mcy image with a self signed root CA that appears on the vendor catalog but not directly to the root-of-trust certificate in the OTP (it does not have a filename that you can add in Uniflash).

    Also dropbox that you use for OTP has some real chain of certificates that need to appear on the vendor catalog so you would need to create the catalog and add all the root CA fingerprints as appears on the guide.

    Hope it is clearer now.

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Intellectual 620 points

    Thank you for responding. I believe that I am learning more as I go and the comments you made are helpful. I am a little confused on your last statement about the dropbox certificate(s) I’ll need to install on the filesystem to support the TI OTA feature. You mentioned a full chain but it is my understanding that I only need to acquire dropbox’s “DigiCert High Assurance EV Root CA” certificate and install it at the top of the CC3220SF filesystem and make sure the name of that file matches TI’s  #define OTA_SERVER_ROOT_CA_CERT located in otauser.h. Additionally, I gather that when I use the TI tools to construct my vendor certificate catalog that I’ll need to point the tool at a directory on my development machine that contains that single dropbox certificate as well as any other root ca vendor certificates my company might need for other features such as the authentication of MCU images, etc. Is that correct? I just need the one dropbox certificate installed on the CC3220SF filesystem and it’s the only dropbox certificate whose fingerprint needs to be built into the CC3220SF vendor certificate catalog, right? And the vendor certificate catalog will be signed using our company’s secret private key and then our associated public key will be part of what the TI tools build into the content of the CC3220SF OTP section of flash. I hope I have the concept correct. Thanks in advance!