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.

CC3100MOD: Security updates and SBoM (software bill of materials)

Part Number: CC3100MOD
Other Parts Discussed in Thread: CC3100, CC3135, CC3120

Hello,

We have a hospital customer who asks the following of us:

1) Please provide an SBOM for the 802.11 NIC.

2) When (not if, when) a security flaw is found, how will it be updated? 

My follow-on questions to TI are:

1. We need the full SBOM, including things such as SSL/TLS stack that is embedded in the product.  Is this possible?

2. a  Is monitoring of TI code and products for vulnerabilities part of the product offering? 

2.b. Hypothetically, if a security flaw is found, how will TI roll out the FW release and alert customers?    

2.c. We have not implemented the SW interface to support SW update.  Is there a TI application note for that could provide guidance, please?

Thank you,

Steve

  • I'm not sure what exactly you are expecting by SBOM, but we provide a service pack for the network processor  and a driver for the host as well as few reference examples (the host part are provide in the CC3100 SDK and the SP is another package - both components can be downloaded here: https://www.ti.com/tool/CC3100SDK).

    The service pack (which includes patches for the NWP ROM code) contains the 802.11 mac + supplicant + Network stack + TLS stack. We use 3rd parties stacks but we are not typically providing details on it. TI is responsible for the system level.

    The host driver reference is using MSP432 (we have examples supporting TIRTOS/FreeRTOS and non-OS), but we provide guidance for porting to other platform and OS.

    We are monitoring the product for vulnerabilities (a customer can also point us to one) and typically provide updates in an SDK and/or SP.

    Although the major issue are typically ported to CC3100, we would recommend new designs to use the newer CC3120/CC3135 which have different service pack and SDK which are being updated on a regular basis (release every quarter) and have more option for updates (some issues cannot be handled in the CC3100 device). The CC3100 SDK and SP are only updated when needed.

    We have an examples (and documentation) demonstrating OTA (over the air) updates, but for the CC31xx - this mainly refers to SP update. Host software update highly depends on the host.

    Br,

    Kobi      

     

  • Kobi,

    Thank you for the reply and confirmation of regular updates and monitoring.  Yes, new designs would preferably use CC3120 / 3135, but this is an old design. 

    As for SBOM, my customer requests a list of all the SW/FW modules that execute, so this would include the NWP ROM code (including patches). This is for the purpose of checking the code against the national vulnerabilities database (NVD).  I believe the SDK and SP that can be downloaded do not include the ROM code.  Is that correct?

    My error on "asking a related question" to SW update over WiFi".   Thank you for correcting and pointing out CC3100 would be updated over serial port.  Would you please point me to a document that provides the API and/or examples for updating the CC3100 software over SP?

    Kind regards,
    Steve

  • The NWP/MAC code is in ROM (on the device).

    The Service Pack (SP) contains patches for the ROM code.

    The SDK includes source code and binaries for the host driver, porting layer and simple application.

    The ota_sample_app demonstrates update over-the-air (i.e. using the wi-fi, not over serial port).  If you get the content of the update over serial port, you will need to use this as a reference (for how to install the SP on the file system).

    Br,

    Kobi

  • Kobi,

    Let's assume there have been no patches for a moment.  In this case, there would be no service packs.

    If I understand correctly, the NWP/MAC code (in ROM on the device) + the SDK comprises the full SW image for the radio.  Both of which can have vulnerabilities and both of which TI provides updates to address those vulnerabilities.

    As a medical device manufacturer, if I provide to my customer the SDK to evaluate for vulnerabilities, I am providing them part, but not all of the firmware required to run the radio.   Is that correct?

    Thanks,

    Steve

  • The SDK contains the host driver that is all you need to control the radio. When talking about CC3100, unless if you are using one of the supported host platforms (tiva-C, MSP430 or stm32) - you will need to provide the adaptation layer to the host (and to the OS).

    The SP is mandatory - the ROM code will not be sufficient to enable the radio.

    Once the porting issue is solved, the SP +SDK should enable you/your customer to fully operate the wi-fi.

    br.

    Kobi

      

  • HI,

    Let me re-start. 

    This is not about my customer being able to operate Wi-Fi.  I provide a complete medical device with a functioning WiFi radio to the customer.

    This is about meeting the customer requirement to evaluate the software against known vulnerabilities.  This is accomplished by running all the code that is required to operate the radio through a vulnerability checker.  To meet the customer request, I need to be able to submit one of the following to a vulnerability checker, such as black duck from Synopsis  a) software bill of materials that lists the name and version of every software module  OR b) every line of source code required to run the radio, including the OS (if any), what is in ROM, what is in the SDK, and what is in the SP. OR c) the complete binary image of the code required to run the radio, including the OS (if any), what is in ROM, what is in the SDK, and what is in the SP.

    How can TI help me in meeting this customer security requirement?

    Thank you,

    Steve

  • I think the best option is you take what we currently deliver (i.e. SP +SDK) and use it to enable the vulnerability checker.

    But i will consult internally to see if there is something else we can do to help with this requirement.

  • After checking about it internally, it seems that we don't have anything to add.

    We are based on our internal testing and are open to check and fix vulnerabilities reported by our customers (or by any external publications).