• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 43 subscribers
  • Views 2202 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 TCP/IP stack is embedded. Security implications ?

Frederic SILVI
Prodigy 50 points
Other Parts Discussed in Thread: CC3200

Hi,

I'm interested in CC3200 development .. but concerned by one point. As I understand, TCP/IP stack is embedded inside the network (co)processor. It's clearly a positive point to ease development from host side .. but I'm wondering if it's involving security implications too :

Q1 : what happens if a security issue is discovered, for instance in SSL/TLS software components (like Heartbleed for OpenSSL as an example). Is it possible to flash/update the TCP/IP stack in our lab ? Is it possible to update remotely deployed objects ?

Q2 : how to be sure that the stack has none "hidden" feature, like redirecting part of data streams to some server/player ?

Regards,

Frederic

  • 0
    TI__Mastermind 27095 points
    Hi Frederic,

    1: If there are any new fixes with respect to TCP/IP stack, then a servicepack will be released. And you update the image remotely using the OTA(Over the Air) update feature. Please take a look at the Over the air update feature (processors.wiki.ti.com/.../CC32xx_Over_The_Air_Update_Application)

    2: You can evaluate it, and hook in an air sniffer and see the traffic.

    Regards,
    Raghavendra
  • 0 in reply to Raghavendra Shenoy
    Prodigy 50 points

    Hi Raghavendra,

    1: In my understanding TCP/IP code is hosted inside WiFi network processor subsystem (and not the application MCU subsystem, which hosts only the driver part). Moreover OTA seems dedicated to application firmware update ... thus not relevant for updating code related to the network subsystem. Am I wrong ? Where is precisely hosted TCP/IP stack binary code ? (cf figure 1-2 of CC3200 datasheet)

    2: do we have access to the source code of this TCP/IP stack ? How do you want to lead a (serious) evaluation of a network/security component without having detailed knowledge about its source code ? As you may know, evaluation as a "blackbox" (thanks to an air sniffer) has significative limitations...

    Regards,

    Frederic

  • 0 in reply to Frederic SILVI
    TI__Mastermind 27095 points
    Hi,

    1. The servicepack would contain the patches for TCP/IP stack portion which is a part of network processor. The mcuimg.bin corresponds to the application image that runs on the apps processor. With OTA you could update both of these files.

    2. No, you would not have access to source code of TCP/IP stack. Apart from the use-case mentioned above, what would you want to evaluate with respect to Network processor? Can you please give more details?

    Regards,
    Raghavendra
  • 0 in reply to Raghavendra Shenoy
    Prodigy 50 points
    Hi,

    2: The (security) concerns are so vast, I am not sure we need to share/express more details. From our side, we would not go onto market with a product embedding a component (the network processor of the CC3200), integrated as a "blackbox" inside our own product.
    What about the quality of the implementation of cypher algorithms or SSL/TLS protocol ? What about the presence of a backdoor (or equivalent) ? What is the source core of this stack ? Has it been created from scratch ? Why the source code is not available (like Oryx Cyclone TCP, FNet, LWIP for instance) ? etc.
    If our teams are not confortable with those questions, we would not engage our brand in these conditions (despite the features and the real quality of the CC3200)

    Regards,
    Frederic
  • 0 in reply to Frederic SILVI
    Intellectual 260 points
    Frederic - I'm with you on this. No way we're putting a full TCP/IP stack, let alone an SSL/TLS stack, of unknown origin and quantity, into our high-security product. It's a joke. This is TI's policy of "security through obscurity", apparently.

    "DON'T LET PEOPLE VIEW THE SOURCE CODE! THEY MIGHT FIND A BUG WHICH RESULTS IN A SECURITY HOLE!!"

    Exactly! Then let's fix it. All software has bugs. TI's reluctance to open the source to its protocol software really indicates to me that's it's not mature, and perhaps a bit ugly in places. Of course I am just speculating at this point.

    It must be an in-house solution, because if it was something like OpenSSL, they'd have to open source it. I would speculate that a few summer interns and/or new grads worked on the TCP/IP and SSL/TLS for a couple years, and that's what's in there.

    If there is anyone at TI reading this who /really/ understands security, I would love to hear a serious, considered response to the question, "What would Mr. Auguste Kerckhoffs think about your policy?".
  • 0 in reply to RF-Explorer
    TI__Guru* 91086 points
    Dear Frederic and RF-Explorer -
    The network processor is updated via service pack, as Ragavendra already said. The ROM coding of the Wi-Fi and TCP/IP stack is done for user convenience of the end customer/developer of accessories , as these stacks generally are not small, and the vast majority of the customers appreciate this already being taken care of for them. As far as bugs or security concerns, we take these seriously, and investigate each one which is reported and work diligently with each customer to explain or resolve. Sometimes this turns out to be the setup of the test environment, other times it results in a service pack update, which is done as soon as possible. To the point of the last question, I think that he would be amazed at the age we live in and appreciate the design and development we offer here in this product. Its easy to poke at us here, it is an open forum - however I could make a friendly suggestion that you keep it on the professional level and report details of actual issues here in this environment for us to then engage and help you with. We truly care about our customers and products and having opinions which are based on theories or guesses which are posted are not productive, IMHO. Thanks for your interest and your opinions.
    BR -
    Josh
  • 0 in reply to Josh Wyatt
    Intellectual 260 points
    Josh,

    First of all, thanks for taking the time to respond (seriously, I really mean that).

    Feedback noted, I don't know that I'd stoop to calling the feedback unprofessional, the reality is that a) security is hard, b) typically the only way you get good at security is through experience and making mistakes. The comment was not indicating that new grads are inferior, it's just that they probably don't have the "time in the trenches" to understand some of the subtle ways that security defects find their way into a system (many experienced engineers also have no real security experience). Enough said I think.

    We understand that TI updates the stack as issues are found. Fair enough. But let's say that the best and brightest within TI are the ones working on the stack. What are the chances that those ~5 people (or 10, or 20, or 2) have the time, energy, experience and expertise to avoid side channel attacks, timing attacks, every variant of protocol downgrade attack, buffer overflows, etc.? I think for those who take security seriously, it's a "devil you know" type of thing. All non-trival software has bugs; the question becomes, "What bugs are in the product I'm shipping, and what are the risks introduced by them?"

    Also, this doesn't even cover the issue that Frederic brought up, which is the possibility of a back door. TI / Raytheon / DoD / 3-letter-agencies... I have absolutely no knowledge of any TI motivation to put in such a back door, but in the security world, audits and "trust but verify" are the standard operating procedures. Since there are probably a dozen open TCP/IP implementations, and another half-dozen, if not more, SSL/TLS stacks, it's just baffling to me why TI wouldn't open the source code to these products.

    I sincerely appreciate you taking the time to reply. And I commend TI for striving to simplify the development of secure connected products.
  • 0 in reply to Josh Wyatt
    Intellectual 320 points

    At the risk of reviving an old (1 week?) thread, I would like to point out that Josh and Frederic are in good company when it comes to people not simply "trusting" the security of the NWP and its TCP/IP and SSL/TLS stacks. With the growing demands for security in "IoT" devices, we need to have the ability to audit the TCP/IP and SSL/TLS stacks.

    I wouldn't consider RF Explorer's comment to be insulting at all. His point was valid, in that obscuring the source from the community actually harms the over all security of the device, despite the number of talented engineers TI has working on CC3200 security features.

    The company I work for does use the CC3200 in some products, but will likely get phased out of any new designs, because of this "black box" issue. I hope TI has the foresight to see that security standards are quickly improving in the "IoT" space, and even small/immature "IoT" companies will soon be required to pass security audits to sell their products with the big retailers.

    Your statement that "the vast majority of the customers appreciate this already being taken care of for them" is true (for now), but I do not see how opening the source of the NWP stacks would make things any less convenient for them? If they do not care about the source, then they can treat it as a black box and just load the service-pack as usual. Futhermore, I speculate that the vast majority of the market *by volume* will soon care a lot more, when they find that retailers will not sell their products without passing security audits.

    Please do not take this thread and these comments as insults, but rather as a plea to help improve security. I have already witnessed the tides of change moving away from the CC3200 within my own organization, and I am sure we are not alone. If TI would simply open up the NWP code, so that we can build and audit the service-packs ourselves, I would happily recommend the CC3200 for new designs. Surely someone at TI can see how failing to do so will have a negative impact on CC3200 revenue, as the market moves away from the CC3200 to more secure devices.

    Best,
    John

  • 0 in reply to JohnB
    Guru 39650 points

    Hi John,

    Can you suggest more secure device in same market area as CC3200? I don't know about any.

    ESP32 ... not, ATSAMW25 (WINC1500) ... not, WICED devices ... not, Bluegiga (Silab) ... not, GainSpan ... not, RTX ... not, SPWF01xx ... not, some obscure China manufacturer ... probably not, NXP ... maybe, devices are not already announced

    Jan

  • 0 in reply to Hnz
    Intellectual 320 points
    I do not want to turn this thread into a list of TI's competitor products, but I can say that Wizard Gecko (subsidiary of Silicon Labs) does in-fact offer low power WiFi enabled MCUs with an open network stack. There are others, but I did not come here to steer people away from TI. I posted here to emphasize that the community is very interested in having the ability to secure the CC3200 network processor.
  • 0 in reply to JohnB
    Guru 39650 points

    Hi,

    Sorry no. Products from Silab (modules which Silab get by acquiring Bluegiga) contains WiFi chipset (MAC+PHY) which runs on own binary blob firmware. It is right that you have control under TCP/IP stack, but this is only a small part of code. Open source TCP/IP stack in this case will not much help you. For security audit you will need also code from WiFi chipset which is not open.

    It sounds good to have WiFi embedded platform with open source, but currently similar platform on the market does not exist (even ESP8266 and ESP32 is not that open how looks).

    Jan

  • 0 in reply to JohnB
    TI__Guru* 91086 points

    John -
    the TCP/IP stack, in the NWP, inside the CC31xx and CC32xx devices is ROM coded. If you have a actual business need which requires an audit (to audit or have something audited by a third party) and need to discuss that - talk to your TI sales person or send me an email, we can set up an NDA and speak freely about it.

    We hear the request and consider it to be a real one - perhaps at some point in the future a new device will be flash based and you can get what you want here - for now though - on this forum - for the purposes of discussion - the NWP portion is ROM coded and considered to be an IP block.