Application Code Protection

Thanks verymuch, Kaushal for your answer. I can't wait to get my hand on the production version.

Peter,

Minor correction, support for Secure Flash for CC3200 will be introduced with a future revision of CC3200 device and not the current revision of the production device, CC3200R1 available for backorder here: http://www.ti.com/product/CC3200/samplebuy

We will make an annoucement as soon as Secure Flash capability is enabled with CC3200.

Adnan

Wait...  What?

Are you saying that we have to wait for some future device to be able to prevent piracy of our code?  So the parts in production now available in September will not prevent piracy of our code.  Any products produced with those parts can be cloned?  All my hard work is available to anyone that wants it?  Is this simply a FW  patch to the September hardware or do I have to wait for altogether new spin of the chip hardware?

What is the timeline for the part that will be secure?  We have no interest in using the insecure part.

Jason,

All SimpeLink WiFi Devices offer Secure Networking capability which includes

1. Secured protocols including WiFi WPA2 personal & enterprise as well as SSL 3.0 / TLS 1.2

2. On-Chip HW encryption enabling Real-time encryption and Fast TLS connections.

Hi Adnan,

I believe everyone knows that the key for secured link stored in the external flash is safe from piracy as it's clearly stated in the datasheet.

We are concerned about our exhaustive hard work application code being naked in the unsecured place and anyone could easily copy it.

So, is it true - as you said - that the upcoming production version won't offer the encryption/decryption engine to store application code in the external flash?

Best Regards,

Pete

Hi Pete,

Yes, I can confirm that CC3200R1 does not support Encryption/Decryption of MCU Application and User data.

As mentioned above, we will be introducing this capability with a future revision of the device.

In the meantime, CC3100 with an external MCU can be used for MCU Application and user data encryption.

Adnan

Thanks Adnan for the confirmation. Please inform us as soon as the schedule for the secure version is available.

Pete,

Thank you for your persistence.

TI,

Is it possible for developers to add hooks into the existing boot-loader, or to replace it entirely with a new bootloader to decrypt the image using a key stored via the network processor in secure storage?  So even if a cloner knew the boot-loader hook code, he wouldn't have access to the encryption key thus the image.bin would be safe.

So the existing boot-loader would load the decrypting boot-loader which would first ask the network processor for the encryption key (that was safe from prying eyes since it is held in secure storage), then the decrypting boot-loader would load the image using AES decryption (done in software not done in hardware), then launch the image as normal.

Jason,

I also thought about the solution to use key in secured location to prevent the code. I don't know if it's possible.

Does this also apply to the password that is used to connect to the secured network? In other words, with the current version of the hardware, might it be possible for someone to extract the clear-text WiFi password?