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

A defining feature of a patent is public disclosure.

What's the patent number? Could you offer a link?

Hi All,

Actually, I'm not sure if Smartconfig is under patent, but the algorithm is proprietary. This is also for security purposes :)

Thanks,

Aaron

Hi,

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.

Regards,

Tomer

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:

http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

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:

http://processors.wiki.ti.com/index.php/CC3000_Smart_Config#Examples_using_IOS.5CAndroid.5CPC_devices

Regards,

/George

George,

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.

Regards,

Tomer

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:

http://processors.wiki.ti.com/index.php/CC3000_First_Time_Configuration#First_Time_Config_Probe_and_Beacon_Definition

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.:

http://www.wi-fiplanet.com/tutorials/article.php/1447501

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).

Regards,

/George

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:

http://processors.wiki.ti.com/index.php/CC3000_Smart_Config

http://processors.wiki.ti.com/index.php/Smart_Config_Application_development_information_-_IOS

Regards,

Tomer

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:

http://technet.microsoft.com/en-us/library/hh994558.aspx

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.

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.

Regards,

Tomer

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.

Regards,

Tomer

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:

http://en.wikipedia.org/wiki/Trusted_client
http://en.wikipedia.org/wiki/Content_Scramble_System
http://en.wikipedia.org/wiki/DeCSS

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:

http://en.wikipedia.org/wiki/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:

http://www.uspto.gov/patents/process/search/

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.

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.

Regards,

Tomer

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?

Regards,

Tomer

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:

http://www.ti.com/tool/smartconfig

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):

http://processors.wiki.ti.com/index.php/CC3000_First_Time_Configuration

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.

Regards,

/George

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:

http://www.youtube.com/watch?v=3GICwLB-5iY&t=9m41s

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

Hi George,

Your points are good and valid. We will study them thoroughly and feedback.

Still, one of the decisions to abandon the "First Time Config" was the limited size to transmit the SSID and Password (up to 32 characters in the name/SSID field).

Also, the complexity for the user (on iOS) to setup a new network, type the SSID with the TTT prefix... These are just two of the advantage by using the smartconfig application.

An option for customers to decrease the complexity for the end users to type the AES password is by using a QR code which will be shipped with every device.

Regards,

Tomer

I think this discussion is getting a bit off track.

What TI has accomplished here is push-button inclusion of a limited-UI device into a wifi network. The problem of getting devices onto a secured network has been one of the last disadvantages of using wifi in the internet of things over options like ZigBee and Z-Wave that have push-button inclusion.

That being said, it is insecure by logical necessity if you don't need to type in any identifying key from the target device. If you're not typing in something like the AES key, there's no way for the algorithm to distinguish between the device you intend to connect and a spy. Even if we never figured out how the password is encoded in the beacon (come on TI, don't insult us), you could still just use another CC3000 to get on the network.

That being said, this is momentary insecurity, and I think it's worth it for the convenience. Take Z-Wave for example: it's an industry leading home automation wireless protocol that people use to lock and unlock doors and open their garage doors, and it has this same insecurity. If someone is packet sniffing your Z-Wave traffic when you connect your door lock, they can compromise your network. But guess what? No one plants Z-Wave sniffers around people's houses to hack their systems.

TI is handling this poorly by not acknowledging that there will always be some insecurity when you're transmitting passwords to something without doing some kind of PIN or key entry to uniquely identify the recipient. It would also be nice if the AES keys were taken care of by TI and the customer was always given the option to use it so they can make their own decision about security vs. convenience.

Hi Duncan --

I think that's probably a fair summary - I think my primary issue is as you say:

TI is handling this poorly by not acknowledging that there will always be some insecurity when you're transmitting passwords to something without doing some kind of PIN or key entry to uniquely identify the recipient. It would also be nice if the AES keys were taken care of by TI and the customer was always given the option to use it so they can make their own decision about security vs. convenience.

I think TI are completely glossing over the whole security issue in their literature and promotional videos and I think many people will assume a level of security that does not exist. When one enters a password one usually assumes that the system accepting it will handle it in a secure manner. I think even device manufacturers may fail to make themselves aware of the issues, and TI is not exactly going out of their way to point them up (as using AES makes the whole thing look less attractive as an easy solution).

I accept that in certain situations momentary insecurity may be acceptable to certain users. And I accept that completely unsecured home networks rarely get hacked. But when they do it's extremely unpleasant for those involved, so on the whole I would argue this kind of thing should be avoided where possible.

No corporate environment is going to install Z-Wave but the idea behind the CC3000 is that it'll be attached to all kinds of little gizmos. For corporations momentary insecurity is not acceptable and here CC3000 devices will be a real problem to police.

If one wished to hack a particular corporate network one might well consider it worth one's while to install a permanent packet sniffer in the vicinity (the great thing about wifi for an attacker is that you don't even need physical access). If the Internet of Things take off and CC3000 devices are a major part of that then this will be a big headache for corporates.

I can't think of any other current technology that presents quite the same issue, e.g. even if a corporate employee takes work home with them on a USB stick despite it being against corporate policy to do so, it's still a big step from there to the data on the stick becoming an issue for the company (most likely the user will use if fairly responsibly and even if it gets lost whoever finds it almost certainly won't do anything with it). The CC3000 is different I think - if someone does set out to attack a corporate network as I've described then it's all over the very first time someone connects whatever cool fun CC3000 widget someone gave them as a present.

Regards,

/George

Hi,

Based on your feedback, we will document clearly (on our wiki) the implications and recommendations to customers to use AES key. We should also make AES the default in the smartconfig application.

We will also explain more clearly that SSID and password are only sent during the smart config process, which is happening over a short period of time, typically once in a product's lifetime (although, as you mentioned, it is true that one could leave a sniffer for long periods, and reveal the password once he knows the algorithm..).

The advantage of not using AES is the ability to configure simultaneously multiple device without the need to sycn the key among all of them. It also gives a better user experience in some product deployments.

For security, users/customers should use AES key (assuming memory is not an issue). TI is not going to change the way the smartconfig algorithm works. For that we have the AES key.

Regards,

Tomer 

In a lot of big organizations when people say "we're going to review your suggestions" it usually actually means "we're going to do nothing."

Thanks Tomer for proving me wrong when it comes to TI :)

What you've outlined above sounds entirely reasonable.

Stupid answer. The moment you patent something - it is in the public domain! :-) Unless it is "Trade Secret".

For all concerned:

This info is available on google if you look hard enough.  I have "decrypted" the non AES-encrypted smart config process and can absolutely verify the process is not encrypted when not using AES key but it is not just thrown out there either.  This is why I said I have "decypted" it, i.e. I figured out the method to their madness with help from a long and tiring google search.  I will not share the exact method here for respect to TI and what they are trying to do even though I may not agree with it.  I do think TI should be much more open about the process as they have an encryption method that is an accepted industry standard also.  I also think TI should give out the complete API, which should include every packet that will be accepted by the cc3000 along with the expected response.  Every other wifi module manufacturer provides this and does not make you figure it out from their software, which I have had to do.  This leads to issues like me doing every thing correctly, but my modules are now stuck sending back disconnect after the smart config process is done and I have no clue why so I have to crack every part of this device to figure out where me or TI went wrong.  The real answer is TI did all of us using this device an injustice by assuming we want them to make the software for us, well some of us appear to better programmers than TI employs and would like more flexibility.  It is a real shame that I will have to learn how to use another wifi module on my next project as I will not continue to use this in the future.  And the biggest shame is that the module is a winner fort the most part but TI is just screwing it up.  And TI just take a look at the documentation for other wifi modules before you respond with more canned nonsense.  Please provide your customers with the documentation they so desperately need in some cases, otherwise we will move on, and we really want to use products from a U.S. company but not at this cost.

I do have a question on the AES key usage though.  Is anything actually decrypted by the CC3000 or is it assumed the user is doing it using functions in security.h.  The reason I ask is the documentation says all info is encrypted not just the password, but in the smart config process function is states only the password is encrypted. I have tried just looking at the data packet contain this info using nvmem read and I cannot figure out how it is being parsed in your software.  It does appear that all the info is encrpyted as I cannot find my SSID in the packet, but weirdly I am seeing different data everytime I do it even though the data being send is not changing, i.e. I am not changing the ssid, key or password.  Can someone please clear up how to parse the 67 bytes containing this info and if everything is encrypted?  If nothing else is encrypted I would like to know if I can omit passing the key to the cc3000 and handle the decryption with my cpu's AES128 module itself since in that scenario the cc3000 is not using the key and only storing it for the user to use, which presents an unnecessary passing of the key over the spi which may be tapped using hardware to then extract the key.

Thanks, 

Chad.

Hi Yael,

Recently i use CC3000. I have a question about the AES. My router(Easy Box) uses always AES, My chip is MSP430f5438a . After smart configuration the cc3000 can not connect to my router. I have always tried it. Now i doubt that my router uses AES(in the option of the router it shows that i am using AES , but if i shut AES down, a new connection is builded and says without AES it is not safe) , but my code dose not support the AES. I have tried shutting down the AES function in my router but it failed.

Could you tell me if my understand right ? Can the connection between cc3000 and router fail because of AES ?

if that is right, then i must buy a new router(without AES) for CC3000.

Thank you for your attention and help,

Best regards,

Han Di