• Resolved

How does TI CC3000 wifi smart config work on wpa2 encrypted home network ?

Hi ,

I asked this question in stackoverflow and they suggested me to ask the same here for more details.

Link to the question http://electronics.stackexchange.com/q/61704/1705

Summary :

Since the smart config does not disconnect my smartphone network connection to my home router (which is using wpa2-personal ).

How does the cc3000 chip decrypt the raw packet to extract the information ?

  • In reply to Ian Harris:

    Tomer Kariv says "the question is how a simple link device can connect to a certain AP without knowing the required SSID and password. The answer to that is the algorithm developed by TI, and which can not be shared."

    OK so you're not talking about AES encryption, but the part you are talking about is also well described in one of the pages I mentioned above, see the "First Time Config Probe and Beacon Definition" section:


    As this document states the "network configuration information is transported in an Ad-Hoc Beacon or Probe Request packet that is received by CC3000 device in a first-time configuration state." It then goes on to explain byte for byte how the SSID and password for your network are encoded in such a packet.

    Again wifi beacon and probe request packets are not some non-shareable TI secret, rather they are well defined wifi packet types. For more information just Google for "802.11 probe request", e.g.:


    Basically (as completely described in the TI page above) a number of things happen:

    • Your shiny new CC3000 device starts off unconnected to any wifi network, but can listen for probe requests from any device that sends them.
    • A smartphone basically usually just sends probe requests when it wants to find out what access points are around it but they can also be used to probe for a specific access point, e.g. one could explicitly probe for the access point with SSID "MyHomeNetwork".
    • In your smartphone app you enter the SSID and password for the network you want to connect to - this information is then used to construct a completely dummy SSID name, e.g. "CC3000.MyHomeNetwork.SuperSecretPassword", and the smartphone app then sends a probe looking for a wifi network nearby with that SSID.
    • Of course there is no wifi network with this SSID, but all access points, including your CC3000 enabled device, will see the request.
    • Having seen the request, and recorded the dummy SSID name, the CC3000 enabled device will strip off the prefix (in my example "CC3000") and split the remaining part into the real SSID that it wants to connect to and the password it will need to use (if WEP, WPA or WPA2 has been enabled for the given network).
    • Hopefully it then connects to the real network without problem.

    Note that when sending probe requests the smartphone doesn't even need to be connected to the relevant "real" network, e.g. MyHomeNetwork" in my example. Probes are messages that can be sent out irrespective of whether you're currently connected to a given wifi network. E.g. if you go into a Starbucks and look to see what networks are around you, your phone will show you a list including the Starbucks network (and maybe the SSID of the company on the floor above etc.) - the phone found this all out with probes (and without knowing anything in advance about the local wifi networks). Of course if you want to connect to one of the networks listed you'll probably need a password (which you get from one of the Starbuck's employees).

    AES encryption comes into play in constructing the dummy SSID, i.e. "CC3000.MyHomeNetwork.SuperSecretPassword" in my example. If you're not using AES then the SSID and password will be visible to see just as described in the "Probe and Beacon Definition" section mentioned above.

    If AES is enabled then the real network SSID and password, i.e. the "MyHomeNetwork.SuperSecretPassword" part, will be encrypted using the AES key you entered in the smartphone app, before being included in the dummy SSID name that will be used in the probe request. When the CC3000 enabled device sees the probe it will need to have the same key (AES is a symmetric-key algorithm) and will decrypt this information.

    Anyone else who sees the relevant probe request will not be able to determine the SSID and password unless they too possess the same AES key.

    All this is described in far more detail in the TI documents I referenced in my original post.

    So not using AES looks very insecure, and using it reduces the convenience factor (by requiring manufacturers using the CC3000 to provide a unique AES key with each device they ship and requiring end users to type this in, in addition to the actual SSID and password for the network that they're interested in).



  • In reply to George Hawkins:

    Hi George,

    I think I understand now where the confusion comes from. The algorithm that you were referring to, and also provided the link to is NOT the smartconfig algorithm. That was an old algorithm called "First Time Configuration".

    The smartconfig algorithm DOES NOT share the SSID or password insecurely. This means that if you start the smartconfig application on your smartphone for instance, and sniff the air, even if you don't use the additional AES encryption checkbox, and still use secured connection to the AP, the password of the AP and the SSID will not be shared as is.

    They will be encrypted in a way where only the CC3000 device would be able to interpret. The same goes for connection to an open security AP, the SSID will not be transmitted as is, but in a secured way.

    To summarize, even by knowing either the security key of the AP, or/and the security key of the CC3000 device, that won't be enough to decrypt the SSID and the key as they are encrypted differently. The logic was of course not advertising a security key of a certain AP where any device can listen and detect it.

    You can conduct a simple experiment by sniffing the air while the smartconfig application runs on your phone.

    Some links of the smartconfig process:





  • In reply to Tomer Kariv53:

    Thank you Tomer - what you say does reassure me a lot. I've taken a look at the pages you pointed to.

    Forgive me please if I continue in what may seem like a confrontational tone.

    I just want to get to the bottom of how users (I mean device manufacturers, not device end users) can make a sensible choice to go with CC3000 technology if how it works is not transparent.

    Effectively you're saying "Trust us it's good." But not good enough to withstand eyeballing from the established security community?

    No modern security approach relies on security through obscurity - RSA, AES etc. do not depend on it - I can't believe TI does either.

    Even companies like Microsoft, that are hardly open source fanatics, are very open about how the security in their systems works, e.g. this page that discusses the hashing algorithms etc. used in their password handling:


    I'm really sure you mean it when you say "The smartconfig algorithm DOES NOT share the SSID or password insecurely."

    However I'm simply not in a position to judge your ability to make such a call.

    I can only make a call if the technology is explained in an open and clear manner. To reiterate TI can't ask the world to take it on trust.

    People have a responsibility to their end users - if there turns out to be a flaw in the CC3000 approach they can't just then point the finger at TI and tell their customers "hey it's their fault, nothing to do with us."

    The approach taken by the CC3000 has to be open and seen to be reasonable.

    After the WEP debacle it's clear how difficult it is to get this kind of thing right even when the process is clear and open to review by all.

    Trade secrets and security through obscurity are not feasible approaches when it comes to a security technology that you expect third parties, i.e. people like me, to adopt.

    There are clearly other mechanisms that provide the necessary degree of disclosure while protecting TI's rights.

    I don't believe NDAs with device manufacturers or something like this is the appropriate approach for something security related - an area that typically has complex mathematical aspects that are best reviewed by academia rather than simply in-company.

    Please note that I'm arguing the above not from some kind of idealistic open source perspective but from a realist security oriented perspective.

    Also if the page http://processors.wiki.ti.com/index.php/CC3000_First_Time_Configuration is out of date, and clearly gives the impression that the CC3000 approach is overly simplistic, then it should be clearly marked as such or removed or properly updated.

    It is marked as last updated on "15 March 2013, at 16:02", i.e. it is not some ancient document that one could well expect to be out of date.

    I'm not trying to rubbish the CC3000 - quite the opposite, I want it to be the dream solution to the up till now awkward issue of configuring smart headless devices in the Internet of Things - but I do need to be convinced of this rather than taking on trust.

  • In reply to George Hawkins:

    Hi George,

    Appreciate your detailed answers and descriptions.

    Sharing the algorithm would mean that everyone would be able to "listen", decyrpt, and detect the SSID and password.

    We do provide the ability on top to encrypt it by AES encryption which as you know is published. Would AES encryption be good for you? If that's the case, then I recommend you always use it. That way, you would feel confident, that although you don't know TI's algo, you are familiar with a part of the process (AES), which is the most robust security for wireless devices.

    Regarding the "First Time Configuration" page, I wouldn't say it's out of date. It depends on the service pack that your CC3000 device is programmed.

    Starting from V1.10, the smartconfig algorithm replaces the "First Time Configuration", but for customers/users using former versions, that page is still relevant.



  • In reply to Tomer Kariv53:

    Hi George,

    I would like to clarify it even further, as I might have not been too clear in my previous posts. The reason I used at first "encrypt"/"decrypt" in quotes is because the algorithm is not an encryption/decryption mechanism, but rather an algorithm which is known to both sides (transmitter/application, receiver/CC3000), which means the information transmitted over the air can be received and understood by the CC3000 device. It doesn't contain a key for encryption. For encryption you would need to enable the AES checkbox in the application.

    It is also true that for best security, a customer would have to ship each product with a different key. Please also note, the smartconfig is a short process in time, and once the CC3000 device is connected for the first time, there's no need to repeat the process, as the profile with all details would be stored inside the device.

    The patent process is not completed yet, therefore I can't share its number yet. Once it's finalized, I will be able to share it.




  • In reply to Tomer Kariv53:

    Tomer Kariv says "Sharing the algorithm would mean that everyone would be able to "listen", decyrpt, and detect the SSID and password."

    Thanks for this information Tomer but can you ask someone on the CC3000 team to confirm this because I find it disturbing.

    You seem to be essentially saying that if details of the algorithm become public then it's all over as far as any minimal level of security is concerned regarding CC3000 devices that are not using AES encryption?

    No security mechanism that relies on keeping an implementation feature secret has ever lasted for long in the real world.

    The secret inevitably gets out and then all devices based on that mechanism are compromised.

    E.g. DVD relied on super secret encryption keys, once such a key became public it was basically all over for preventing end users from bypassing DVD encryption. This did not involve anyone leaking the information, it was done by reverse engineering the object code of a software DVD player. Later analysis of the underlying algorithm showed further flaws that meant keys could be brute forced in a reasonable time.

    It seems you are saying the CC3000 will be susceptible to the same kind of attack and that device manufacturers can essentially assume that security for devices not using AES will eventually be compromised. The most likely path for this seems to me to be analysis of the iOS or android client code, this is called the "trusted client problem", for more information see:


    Tomer Kariv also says "Please also note, the smartconfig is a short process in time."

    Are you saying that because the probe is only visible for milliseconds or less that this makes it less likely that it will be intercepted and used to compromise security?

    If one was looking to compromise a given network one would presumably install a device to listen for probes, this device could sit there for days, weeks or years, it will see all probes irrespective of how long or short an amount of time the probe is visible or the whole smartconfig process takes.

    If the non-AES setup process is likely to be compromised in the future then it seems irresponsible of TI to offer it as an option. I can't believe that the people who developed the CC3000 would be irresponsible in this way, and that's why I ask you to confirm with someone on the team that the CC3000 does not rely on security through obscurity:


    I do not have a security background but I am aware of some of the issues. I think it's often common for those of us outside the hard core security establishment to assume "good enough" security will indeed be good enough.

    I.e. that something that relies on a super secret or security information only being visible on the air "briefly" will be good enough for home use and that corporations that require higher security will e.g. in the case of the CC3000 use AES.

    But this never works out - WEP looked "good enough" but wasn't - neither for home use nor for corporate. And relying on end users to behave responsibly (rather than enforcing it as a fundamental part of device design) never works either, it only requires one person on a corporate network to install one non-AES enabled CC3000 device there and, from what you are saying, that network's security is essentially compromised.

    Tomer says "The patent process is not completed yet, therefore I can't share its number yet."

    If the process has begun then the application itself, as opposed to a finally granted patent, should be viewable at the United States Patent and Trademark Office:


    I have searched for the relevant application (and also searched the global patent database) but could find no application that seemed to relate to the CC3000 or the smartconfig process.

    Would it be possible for the CC3000 team to point us at the relevant application? I do not believe it is possible to keep applications secret so either such an application exists or it does not. As the CC3000 has been available since at least 2011 I presume any related patent applications were made long ago.

    Again Tomer I'd like to thank you for following up on my generally very long messages and I hope you don't feel I'm attacking you personally with any of my remarks. I just want to achieve more clarity on this whole issue.

  • In reply to George Hawkins:

    Hi George,

    I'm from the CC3000 team.

    I'm saying that once the patent is share-able, then customers/users must use AES encryption for security. Why shouldn't it be used? or do you see a scenario where this can't be achieved? This doesn't require AES encryption of the connected AP.
    The AES encryption is only for the part when the smartconfig takes place. It does not mean the connection to the AP should be of that kind. Therefore, it doesn't require any special care from the customers, apart from the fact they would need to enable the checkbox in the application.

    Small correction, the packets transmitted over the air in the smartconfig process are not probes, but rather unicast UDP packets. Still, it is true that if someone does not use AES encryption, the password would be detected quite easily if someone knows the algorithm. But as I said previously, the encryption is done by the AES and not by knowing the algorithm of the smartconfig.
    Regarding the application number, I will look for it and send it.



  • In reply to Tomer Kariv53:

    One small addition, the only case I see to not using AES encryption by customers, is if the host's memory is very limited not to include the decryption AES files.

    Were you referring to that problem?



  • In reply to Tomer Kariv53:

    OK - let's be clear here.

    If a manufacturer uses the AES option then I am completely happy that the password will not be revealed in an easy to sniff manner.

    You say "The AES encryption is only for the part when the smartconfig takes place."

    Yes I understand this.

    Then you say "Therefore, it doesn't require any special care from the customers..."

    However using the AES option does seriously increases the complexity for device manufacturers - they must supply unique AES keys in a tamper proof manner with each device shipped, and reduces the convenience for end users as they must type in this long AES key in addition to the SSID and related password.

    My issue is with why TI is providing the option to not use AES.

    While convenient this looks irresponsible - end users may incorrectly assume that their passwords are being handled in a secure manner and manufacturers with limited exposure to security issues may fail to understand the risk they are exposing their end users to by choosing the apparently simpler option of not going with the AES approach.

    You say "that once the patent is share-able, then customers/users must use AES encryption for security."

    So you're saying customers can use the non-AES approach, but once the underlying approach is known (i.e. when a given patent is granted) then they must use AES.

    So why let them use the non-AES mechanism at all in the meantime, i.e. ship devices that will be compromised at some future point?

    I decided to take a look at how SmartConfig works by looking at the SmartConfig Java applet found here:


    This page says that the download includes "SmartConfig library in binary" and "SmartConfig application in source."

    I could not find the source code in the download, however as you probably know Java bytecode is relatively easy to read.

    So I looked at this and it seems to contradict what has been said about there being anything complex or "secret" going on if one is using SmartConfig without AES.

    Here's an description of what I found - the main classes are SmartConfig, FirstTimeConfig and Ftc20.

    SmartConfig is simply the main entry point, it takes an SSID, a password for the network with that SSID, and an AES key (the password and AES key are optional). It then passes these to the FirstTimeConfig class to do the real work.

    FirstTimeConfig basically behaves in a fashion very similar to the behavior described in this document (that we've now been told is out of data):


    If an AES key was provided it encrypts the password (but not the SSID) using this using the standard Java AES implementation (using javax.crypto classes).

    Otherwise no encryption steps are taken for the network password.

    Then using Ftc20 it encodes the SSID and password (either plain, or AES encrypted) in a manner suitable for inclusion in packets.

    This encoding (note I say encoding, not encryption) step involves creating an array of integers built up like so:

    1. A start of SSID marker 0x0577.
    2. The length of the SSID.
    3. The SSID in high-nibble, low-nibble format.
    4. A start of password marker 0x05b3.
    5. The length of the password.
    6. The password in high-nibble, low-nibble format.

    Then back in FirstTimeConfig we can see how this encoded data is split up and broadcast via UDP packets in the send() method, again nothing surprising here.

    So the SmartConfig functionality here seems to be nothing more than a rebranding of the "First Time Config" functionality described in the document linked to above.

    How the data is bundled up is somewhat different but essentially comes down to the same thing, if one is not using AES encryption then the password is visible to anyone who cares to watch for the relevant data.

    Please note I'm not trying to show off by explaining the bytecode and I certainly don't want to be accused of somehow "hacking" it - reading the Java bytecode with the aid of the standard JDK tool javap is something that any reasonably skilled Java developer can do.



  • In reply to George Hawkins:

    Further to my last post - in the promotional videos that I've seen on the TI YouTube channel the AES key is largely glossed over and an AES key is never used when demonstrating SmartConfig.

    This makes me feel that TI is not going out of its way to make manufacturers or end users conscious that unless an AES key is used the network password will be visible to attackers.

    E.g. in this video published 3 months ago on the TI channel we can see the key covered at the 9:41 mark:


    Basically we get some gobbledygook that certainly does not say to me that TI is strongly encouraging customers to use the AES key option.