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.

CC3135: Secure SPI interface between Host MCU and Wifi chip

Part Number: CC3135
Other Parts Discussed in Thread: CC3235S, CC3235SF, CC3301, CC3300

Hi,

We're working on CC3135 wifi chip that communicates with our host MCU using SPI interface.

We're now looking for solution to secure/encrypt the SPI interface, as sensitive information can be transmitted, such as WIFI passwords.

I didn't see any feature on the datasheet. One way to do it would be to modify the CC3135 firmware and TI simplelink lib  to implement encryption feature.

Can you confirm this is a solution and are there any other possibilities to secure SPI interface with host MCU ?

Please note that this is a very critical topic in our project. We are working for Bosch company and the number of pieces involved is significant. 

A quick answer would be very much appreciated.

Thanks in advance for your help.

Olivier Coutureau

  • Hi Olivier,

    I don't think that is easy way with CC3135 device. I thinks best way will be use CC3235 with user application and implementing own encryption.

    Jan

  • Hi Jan,

    Thanks for your quick answer.

    Moreover, is there TI Wifi chip reference that supports encryption of external interface ?

    Are CC3135 and CC3235 hardware/software compatible ?

    Looking at the CC3235 family, there are two options with CC3235S and CC3235SF.

    According to datasheet, they both have 256KB of SRAM (data + code) but  only CC3235SF has on chip flash for user application code. 

    Which one would best fit our needs on implementing a encryption of the external SPI interface ?

    Thanks,

    Olivier

  • Hi Olivier,

    Selection of device depends on needs of your application. CC3135 does not have encryption between WiFi chip and host MCU. But if your main processor is running at Linux WiLink 8 devices may be good choice. Because WiFi supplicant is running at driver inside processor and from this reason your concerns related to encryption are not applicable.

    I think both CC3235S and CC3235SF should be enough for your application. But if you want to use TLS 1.3 in the future, I will recommend CC3235SF. You will move your socket code and WiFi control code from your MCU into CC3235. You will implement your own stream cipher for encrypting of SPI communication between main MCU and CC3235.

    One question. Do you need to use WPA2-Enterprise security (802.1x)?

    Jan

  • Hi Jan,

    We don't need to use WPA2-Enterprise security. Our main processor is an ARM cortex-M33 core running Azure RTOS.

    Is there code example of SPI encrypted interface for CC3235, or anything related ?

    Moreover, is porting existing CC3135 chip to CC3235 smooth ?

    Thanks,

    Olivier

  • Hi Olivier,

    I am not aware of such example which shows encryption at SPI in interface at CC3235. For encryption of communication via SPI interface fits better stream cipher, but according your protocol which you will design for communication in can be used block cipher like AES. CC3235 have hardware accelerator for AES and DES (3DES). Only question is how store symmetric keys at your MCU and CC3235. From security stand point will be better to have key exchange before encryption like a Diffie–Hellman.

    Porting sl_ API code from your M33 to CC3235 should not be a big deal. Likely you will need to do:

    1. Move your sl_ API code from your M33 into CC3235
    2. Design your own protocol for data exchange between M33 application and CC3235 application. From my point of view will be better use for communication UART not a SPI (less wires less problematic)
    3. Design encryption on top your physical communication (SPI or UART). Maybe you don't need to encrypt whole physical communication but only sensitive data.

    I suppose that you are using TCP/IP stack from CC3135 (CC3235) not from your M33 (e.g. NetX Duo).

    Jan

  • Hi Jan,

    Thanks for your answer.


    Actually we are using TCP/IP stack from NetX Duo as the application that we are developing needs it for other purposes.

    We use a limited part of the SimpleLink SDK with just the wifi drivers.

    It means the TCP/IP stack will remain in M33 MCU and that the encryption would probably be on top of this.

    Also, we would like to keep SPI not to decrease the speed rate of the interface.

    Regards,

    Olivier

  • Hi Thomas,

    We have a new part CC3301 that implements secure host interface with SPI. And you can still use NetX Duo on your M33 MCU provided you have enough remaining flash and RAM space for the driver. 

    I would encourage you to check out the CC3301 WiFi 6 transceiver. It is also more affordable than CC3135. Find the datasheet in the link below. Be sure to also request more information to understand what we can currently offer: 

    https://www.ti.com/product/CC3301

    https://www.ti.com/licreg/docs/swlicexportcontrol.tsp?form_id=338887&prod_no=CC33XX-DESIGN&ref_url=epd_connect_wcs_CC3301 

  • Hi Sabeeh,

    Thanks for your answer.


    I see that the CC3301 is currently not in production. Is that compatible with a production phase that would start end of this year ?

    Also, I see that CC3300 from the same family that looks quite the same but doesn't handle BLE. I think it would be best in our case as we don't need BLE support on this chip but maybe there's a reason why you didn't mention CC3300.

    Our current CC3135 is compatible with SimpleLink SDK and it would be easier if the new reference that we use is also compatible. I didn't see CC330X in the compatibility list of SimpleLink SDK. Is it because it's not yet in production or is it just not compatible ? 

    Last point, can you confirm that the CC3135 that we currently use can't have a custom firmware (unlike CC3235) ?

    Regards,


    Olivier

  • Hi Thomas,

    Let's discuss this in direct messages.