TI E2E Community
SimpleLink™ WiFi - CC3000 Forum
How does TI CC3000 wifi smart config work on wpa2 encrypted home network ?
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
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 ?
Unfortunately, the configuration algorithm is under patent thus can't be exposed.
A defining feature of a patent is public disclosure.
What's the patent number? Could you offer a link?
Actually, I'm not sure if Smartconfig is under patent, but the algorithm is proprietary. This is also for security purposes :)
*** Please click the Verify Answer button on this post if it answers your question. ***
The comments from TI employees in this post seem rather odd.
First Yael Oz claims "the configuration algorithm is under patent thus can't be exposed".
To which Duncan McKee points out the obvious, i.e. that a "defining feature of a patent is public disclosure."
Then a second TI employee claims "the algorithm is proprietary. This is also for security purposes :)"
I hope this isn't true - the security bit - as I think TI is smart enough to know no one really takes security through obscurity seriously:
I don't think this is true and TI actually do provide a lot of information about what's going on during CC3000 setup:
Reading through this one gets the disturbing impression that without AES enabled your wifi password will be visible during the setup process to anyone who cares to listen out for the relevant probe requests.
This is not so if one uses AES but this rather reduces the whole convenience factor behind the CC3000.
If using AES it seems one somehow has to ship a unique AES key with each device shipped, e.g. printed on a sticker on the side of the device.
This key will need to be long-ish and will need to be typed in, in addition to the actually SSID and password of the wifi network that the user is interested in getting their device connected to.
Using the same key for every models of a given product would of course defeat the point. E.g. if all models of product X used the same key, then I could just buy one of these products, determine the key and then use it to decode the wifi probes sent out during the setup process when someone installed product X anywhere. One could keep the AES key "secret" - hard coded in both the device and the related smartphone app, but this kind of security through obscurity usually doesn't work very well (the key always somehow eventually leaks).
The smart config operation is indeed described in the wik pages listed above, but the algorithm of how the CC3000 decrypts the information of what the application transmits can't be shared.
The application transmits multicast packets with "encrypted" information, which later is "decrypted" by the CC3000 to detect all required information.
small correction, the packets transmitted are not multicast packets.
Tomer Kariv says "but the algorithm of how the CC3000 decrypts the information of what the application transmits can't be shared."
Sorry but the http://processors.wiki.ti.com/index.php/CC3000_Smart_Config page I referred to above clearly states that you can choose between no encryption or use AES-128 encryption.
The AES encryption algorithm is not a non-shareable TI secret, rather it is a well understood algorithm developed by the U.S. National Institute of Standards and Technology.
For clear details of how AES encrypts and decrypts data see:
The security of AES is a property of the mathematics involved and not of keeping its implementation secret.
What has to be kept secret is the key - but it is up to device developers using the CC3000 to choose the key, it is not part of the CC3000 implementation.
See the example screenshot here that shows the field where you enter the AES key if you're using AES encryption:
You misunderstood my intention. The AES encryption is definitely not TI's patent, but is unrelated to how the smartconfig decrypts the data.
The AES encryption, which can be enabled and used in the smartconfig algorithm only gives additional encryption, but even without using it, 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.
I hope this clarifies it better now.
Actually it's more interesting than all that.
The question is not about the AES bit.
The question is how the iphone / andriod / java app gets information to the CC3000 even though the CC3000 has not connected to the given network.
That is, the Iphone (say) is connected via security (WPA2 etc) to the router. Fine. The CC3000 is NOT connected to the same router (that's the problem we need to solve).
Somehow, the CC3000 gets information transferred from the iPhone app. The information can be AES encrypted or not, but either way, the magic is getting it over the wifi connection, for which the CC3000 cannot access at the start of the process.
Now, WPS does the same sort of thing - it transfers information from the router (normally) to a device without anyone having to know what the actual WPA2 security settings are (although there is normally a "pin").
The Smart Config iPhone side needs to know the IP address of the router, so the router must be involved somehow.
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:
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).
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:
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.
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.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.