• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 315 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.

CC3220SF: Handling Dropbox changing certificates

Charles Fleck1
Intellectual 650 points
Part Number: CC3220SF
Other Parts Discussed in Thread: UNIFLASH

Hey guys,
We are using Dropbox to perform OTA upgrades on our CC3220SF chip, but they keep changing their certificates. They recommended being able to support both certificates in this thread: www.dropboxforum.com/.../490861

How would you recommend implementing that so we don't have to worry about OTA breaking if they swap their certificates?

Another issue is that Dropbox may change to a certificate that we don't have already flashed onto the device. When we create the OTA tar file, can we add new certificates to that? For example, it sounds like Dropbox is trying to move away from EV certificates, if they switch to a certificate we don't have on our devices, will we be able to flash the new certificates on using OTA and a tar file created in Uniflash with the new certificates?

Thanks in advance,
Charles

  • 0
    TI__Mastermind 40965 points

    Hi Charles,

    One thing you can do is provide multiple root CA certs concatenated into one PEM file. When you provide the root CA cert file, the TLS library will actually load every cert it find in the file into memory, and compare the needed root CA cert name of the server cert to the certs it finds in the root CA cert file.

    As such, if you were to include both Digicert root CA cert files needed into one file, you should be able to connect to Dropbox no matter which of the two is actually used by the server. See attached file for an example of how to do this, with 5 common root CA certs concatenated:

    /cfs-file/__key/communityserver-discussions-components-files/968/multi_2D00_root_2D00_ca_2D00_bundle.pem

    That being said, that would not fully help in the case that Dropbox changes its root CA cert used to one that is not included in the root CA cert bundle provided. When you create an OTA bundle, you can add whatever files you want, including new root CA cert files. However, the problem will be if you are unable to connect to their servers to download this new cert in the first place. As a failsafe, you might want to have a secondary OTA flow just in case the primary Dropbox OTA method fails. Some options include:

    1. Interaction with a phone app over local Wi-Fi

    2. Secondary OTA server that can be connected to, with the server certs under your control

    3. Direct TLS connection to a backup server that can be used to download a new root CA cert if needed.

    Let me know if you need more clarification or have further questions on this topic.


    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Intellectual 650 points

    Hey Michael,

    That's very helpful!! We actually have some other options that we are exploring that I have some questions about.

    1) Would it be feasible to modify the TI code to try and update through two different services? For example, we would try to update from Dropbox, but if that doesn't work we instead will update from Github. 

    2) It looks like the TI code is mostly intended to work with Dropbox and Github. Do you know what steps it would take to modify the code to work with Bitbucket or Amazon Web Services? They both seem to be more intended for embedded work than Dropbox has been. I assume we would just have to modify the server "name"/address and the certificates/token. Is it that simple, or would we have to change the basic functionality.

    Thanks in advance!!

    Charles

  • 0 in reply to Charles Fleck1
    TI__Mastermind 40965 points

    Hi Charles,

    To answer your questions:

    1. This will require some extensive modification to the OTA library, as the way it's currently designed assumes that you will only be using one service. That being said, it should be possible to do. An inelegant method to accomplish this would be to make two versions of the library, one for each service, and use them separately in your application though that would roughly double the memory footprint of the OTA library. You could perhaps also use a dynamic library/function loader to replace the CDN functions with the desired service at runtime.

    2. If the service you are using uses an HTTP API to fetch files, then it should be fairly straightforward to add support for a new CDN. See the information at section 10 of the OTA library's user's guide for details: https://www.ti.com/lit/swra510

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Intellectual 650 points

    Hey Michael,

    That was super helpful!! It looks like AWS is a little more reliable than Dropbox and Bitbucket or embedded OTA, so I think we will likely just switch over to that. They actually mention the same CC3220SF chip that we are using in the instructions.

    Thanks again!!

    Charles