CC3220SF-LAUNCHXL: CC3220 Secure Bootloader/Filesystem

Hi Ian,

There is no way to use the CC3220S/CC3220SF without signing the image with a well-known certificate.

Other user files can be used without a signature (i.e. unsecured), but not the application image.

For development - we provide the dummy "playground" cert store that will enable you to use our proprietary certificate chain. For production - it must be a valid certificate.

Br,

Kobi

Hi Kobi,

Thank you for your reply. However, we are concerned that because images are authenticated against publicly trusted CAs, anyone can purchase a certificate and sign their firmware for use with the CC3220. Is there a way to restrict the CC3220 to only run firmware produced by us, and not by anyone with a valid certificate?

Hi Ian,

What exactly is the use case that you are worried about?
The certificate is used to provide file authentication so that an attempt to modify your signed image will fail.

You can rely at some level on the root CA to do their verification on the signed entity (for example you can set a unique domain name to your certificate "common name" field, and verify this domain during an OTA process. the root CA should ensure that your domain is not duplicated).

If there was a method to replace the cert store, it could have been replaced with any content (no just yours).

br,
Kobi

Hi Kobi,

Understood about the OTA process. But, to my knowledge, the bootloader checks for a new image on the serial flash on every boot, and will install it regardless of what certificate signs it. This is our primary concern. We were hoping the bootloader would be able to prevent an attacker from loading malicious firmware onto the on-chip flash.

This also applies to the secure filesystem; we would need to check whether or not we were the ones who had signed the file as well, which might not be possible with the current APIs(?).

Hi Ian,

The file system (on the serial flash) is encrypted using a unique (device-specific) key which should prevent attempts to hack it (i.e. adding/changing specific files).

The boot loader will preform an integrity check by verifying the image against its signature (this is true for any secure file in the system, it is verified against it signature when is opened for reading).

The signature will be created whenever the file is being written (upon sl_Close) after the certificate is verified. As mentioned before, you may use other mechanism (such as verification of the unique "common name") to ensure that only your certificates are used.

This basically makes sure that an image can be installed only through the standard CC3220 interface (Simplelink API), which are controlled by your application.

Again, if you have a specific use case in mind - please specify the details.

br,
Kobi

Hi Kobi,

Ah, okay, the encrypted serial flash part is what I was missing. Thanks. So when the image is flashed via UniFlash to the device, is it placed onto the serial flash in an encrypted format already? I have found section 21.8 in the CC3220SF TRM (SWRU465) but I don't believe it details how programming works in that regard.

Our use case is firmware integrity against somewhat skilled adversaries in physical possession of our devices. I think the encrypted SFlash fixes this, so long as nobody is able to program new images to devices in production mode?

Thanks.