• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 2 answers
  • Subscribers 41 subscribers
  • Views 634 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.

CC3200: CC3200 Secure Programming

Dennis Wang22
Intellectual 910 points
Part Number: CC3200
Other Parts Discussed in Thread: UNIFLASH, CC3220SF, CC3220R, CC3220S

Hi 
I am looking for a way to create a secure application image for CC3200. While reading Uniflash, I learned that Uniflash (beyond v3.2.0.00123) doesn't support secured application image creation. However, it has been a while, so just wondering if secured image is now supported. 
If not, the article also mentioned that there is a secured version of CC3200 under "CC3200 Support", is the secured version of CC3200 available now? What tool to use to generate secure image?
Another question, although it mentioned the secured image support is deprecated in newer Uniflash verions, can I use an older version of Uniflash (prior to v3.2.0.00123) to generate a secured image? It should still able to generate secured images and the images would still work, right?
 
Thanks,
Dennis

  • 0
    Guru 39650 points

    Hi Dennis,

    Device CC3200 does not support device level security. If you need secured device you should to use CC3220 or CC3235. Secured image for CC3220 or CC3235 devices is generated via Uniflash version 4.x or 5.x.

    I am not aware that device level security was supported at CC3200 devices. Maybe at some very old versions (pre-production versions?). But it need to be many yeas ago because I don't remember this.

    Jan

  • 0 in reply to Hnz
    Intellectual 910 points

    Hi Jan,
    Thanks for the quick reply. Is it possible to get the pre-production version of Uniflash? We are very close to design freeze, so it might cause some delay since we need to evaluate how to port to CC3220 with min impact... so if a pre-production version of Uniflash is available, we can also evaluate to see if it can still work. 

    Speaking of which, do you have tool to verify if an generated image is indeed secured or not?

    Thanks,
    Dennis
     

  • 0 in reply to Dennis Wang22
    Guru 39650 points

    Hi Dennis,

    No. I talk about pre-production silicone of CC3200 chip. Which you will not be able obtain.

    I think device level security (secured files) was never functional at CC3200 silicone, from this reason was removed from later versions of Uniflash and was never stated as supported feature.

    If you need to device level security (secured files, able to lock JTAG, etc.) you need to switch to CC3220 or CC3235. There is no option to use device level security at CC3200. I think it was were bad decision from your side to start new design based on CC3200 instead CC3220.

    In case that you are using QFN CC3200, be aware that CC3220 is not pin-to-pin drop replacement. Some small PCB changes will be required. Also software for CC3220 is not compatible with CC3200. How much effort will porting need, depends on design of your code.

    • Information about required PCB changes you find here (sheet Migration-QFN)
    • Information about porting software you find here

    Jan

  • 0 in reply to Hnz
    Intellectual 910 points

    Hi Jan
    Really appreciate for sharing the change log. That will definitely help to speed up the porting process. 

    I have a few more questions.
    1. Few questions on the variants in CC3220x family. I would like to confirm does CC3220SF come with a 1MB serial flash integrated inside the chip? Or is it like CC3200 connecting to an external serial flash? So CC3220R and CC3220S won't be connecting to 1MB serial flash, right?
      
    2. I was following CC3200 minimum reference design schematic for my application. I assume I should do the same for CC3220. While comparing the datasheets, in addition to the change log you provided, I notice few more differences in the schematics. p.58 of CC3200 datasheet and p.70 of CC3220 datasheet. I have summarized the changes in the attached file. Besides impedance match for antenna, is it necessary to change all of them? 

    2.a Also, if I need to use pin45, can I follow the note in CC3200 and connect pin47 to VBAT? 

    3. Once I switch to CC3220 and generate a secured image. How can I tell if it is secured or not?
    CC3200 vs CC3220 schematics.docx
  • 0 in reply to Dennis Wang22
    Guru 39650 points

    Hi,

    Answers to you questions:

    1. All CC3220 chips requires external SPI flash (sFlash). This is similar as CC3200. Size of sFlash need to be bigger then CC3200. SF variant of chip have on chip XIP flash. This flash is used for code execution. That means you can have bigger code with SF variant and you don't need execute code from RAM like a CC3200, CC3220S or CC3220R. But CC3220SF requires sFlash as well. In case of you need device level security you should not select CC3220R. Because this chip does not support it.

    2. Proper values of antenna matching circuits depends on used antenna, PCB layout and manufacturing of your PCB, used case(cover) of your device, expected position of device. There is many factors which affects antenna design. And there is no difference of RF design for CC3220 or CC3200. At fist step you should calculate impedance of your antenna path. And after that do measurement at real prototype (by using VNA tune matching circuits and antenna radiation characteristic using spectrum analyser). You should also tune center frequency of main click using this article. Some examples of RF design you find at layout guide. This document is very important. Especially thing around DC-DC design. This is nice video which describes why is important properly optimise antenna.

    3. For questions related to design differences please wait for answer from TI. Personally I know all important changes of design, but I don't want to forgot to anything important.

    4. S and SF devices are secured by default. In production mode is firmware image validated by certificate. That means you need buy code signing certificate from supported CA (e.g. DigiCert). Alternate option can be using self signed vendor certificate. This certificate need to be uploaded into OTP part of sFlash. Documents describing security at CC3220S(F) devices:

    Jan

  • 0 in reply to Hnz
    Intellectual 910 points

    Hi Jan,
    Really appreciate for the prompt reply over the weekend!

    Hope TI engineers will also help confirm regarding the schematics changes!

    I just start reading swru547a.pdf, and I notice a constraint, "Factory defaults and gang programming are not supported while using this feature". My goal was to have a secured image so I can pass the secured gang image to a serial flash vendor in production. What would be your suggestions on secured gang image? Or perhaps I misunderstood this document at the first glance...

    Thanks,
    Dennis

  • 0 in reply to Dennis Wang22
    Guru 80045 points

    Hi Dennis,

    Please read this document chapter 6.7.1.

    If you want, you can create encrypted image by Uniflash. This image you can send to you manufacture which will upload this image into sFlash (SPI flash). After returning board to you, you can activate image by inserting your key.

    Document swru547a describes Vendor Device Authentication. This allow to use own self signed certificate. But I expect that you will use way with certificate from CA. Using Vendor Device Authentication have some advantage, but is slightly less flexible at production environment.

    BTW ... maybe you can open new thread covering your question about schematic migration between CC3200 and CC3220. With general questions about CC3220 we can continue here.

    Jan

  • 0 in reply to Jan D
    Intellectual 910 points

    Hi Jan,
    Thanks a lot for the help. I will try out the encryption once I get my hand on a CC3220SF launchpad.

    Regarding vendor authentication, I had an impression that it can be more flexible because a vendor can use their certificate to sign. Maybe I am not seeing the whole picture. May I know why it would be less flexible at the production environment?

    I will create a new thread regarding the schematic migration between CC3200 and CC3220.

    Thanks,
    Dennis

  • 0 in reply to Dennis Wang22
    Guru 39650 points

    Hi Dennis,

    Issue with vendor authentication is that, vendor certificate need to be uploaded into OTP part of serial flash using Uniflash only. In case of using image signed by supported by CA, you can create this image by Uniflash and for uploading you can use Embedded programming. From my point of view it better suits for mass production Embedded Programming than Uniflash (GUI or CLI).

    BTW ... be carefully when you using vendor authentication. Because certificate in inside OTP part of SPI flash. Once you upload wrong certificate, there is no way how to fix is. Only way is exchange SPI flash chip.

    Jan

  • 0 in reply to Hnz
    Intellectual 910 points

    Hi Jan,
    Got it, and in the case of using image signed by supported CA, if wrong certificate is used, is it possible to fix it?

    Thanks,
    Dennis
     

  • 0 in reply to Dennis Wang22
    Guru 80045 points

    Hi Dennis,

    Yes, that is not a problem. In case of using image signed by supported CA and you prepare wrong image, your code does not boot. But you will be able fix this issue and upload new image again.

    Summarization advantages and disadvantage of both solution:

    Signing by certificate from CA:

    - Customer is able run own code at your device. In case of customer upload own image into your device, it is able run own code at your device. But by this way is not able "steal" your image - firmware, because by this operation he destroy your image.

    - You need to buy certificate from CA. It costs up to $500. At your development stage you don't need to buy certificate. Only for a production. Personally I recommand buy this certificate (standard Code Signing Certificate from DigiCert).

    + You can use for production programming Embedded programming, Uniflash of Gang programming.

    + No issue when you upload wrong image, you are able recovery this state without any issue.

    + You can use any SPI flash chip which meets requirements. But still is recommended to use chip which was tested by TI. List of supported flash chips you find here.

    Signing by vendor certificate (stored at OTP party of SPI flash):

    + Customer is not able run own code at your device unless he exchange SPI flash chip.

    + Don't need to buy certificate from supported CA.

    - You need to use for production programming Uniflash software only.

    - In case of issue with uploading into OTP part of SPI flash, you need to exchange SPI flash chip.

    - Limitation to one particular part number of SPI flash chip (MX25R3235FM1IH0).

    List above is only my opinion. In your development and production environment you can have a different needs.

    Jan

  • 0 in reply to Jan D
    Intellectual 910 points

    Hi Jan,
    Thanks a lot for the summary. 
    Signing by certificate from CA does sound better. I think I will have a lot to learn and to get familiar with the whole secured programming process before making the final decision. 
    One more questions:
    1. In the case of signing by vendor certificate, if customers gain access to the vendor certificate, is it possible for them to get the application image or flash their own image?
    2. Since my initial design was based on CC3200, and I was planning to program a gang image onto the serial flash through SPI lines (perhaps even before serial flash is assembled onto the PCB), I was planning the same approach for CC3220SF. However, if I understand the difference above, and if I go with the "signing by certificate from CA" solution, my plan won't be impacted. However, if I go with the "signing by vendor certificate" solution, vendor will be limited to use Uniflash software only so that they can store certificate at the OTP part of the serial flash, right?

    Thanks,
    Dennis

  • 0 in reply to Dennis Wang22
    Guru 80045 points

    Hi Dennis,

    Answers to you question:

    1. This this possible only when you your customer will be able obtain (steal) your private key. This is reason why you need keep your private key at secret. At OTP part of sFlash is stored certificate (=public key) not a private key.

    2. Yes. Your assumptions are correct.

    Jan

  • 0 in reply to Jan D
    Intellectual 910 points

    Got it, really appreciate for all the help!