Smart Config - the missing manual now available :)

I've cross posted this to the Adafruit forums as well, so sorry for duplicating. After mentioning before that I'd been looking into Smart Config in detail I've finally written it all up and I thought you guys (particularly @zachary, @BDub, @zach and @Dave) would be interested:

So how does the Smart Config technology used to communicate a network name and password to a CC3000 module work?

It seems a little magical (or at least mysterious) at first - a Smart Config setup application must communicate information (the name and password) from a secure wifi network to a CC3000 enabled device that is not yet able to decrypt the traffic on that network.

How this is done is both clever and surprisingly simple. I've written up a set of posts that describe what's going on.

The most technically detailed one covers the heart of Smart Config - how it encodes the SSID and keyphrase and transmits them such that a CC3000 can pick them up:

CC3000 Smart Config - transmitting SSID and keyphrase ~ Depletion Region

Then I have a post that's less technical, more an opinion piece about why you should always use an AES key with Smart Config:

CC3000 Smart Config and AES ~ Depletion Region

There is a technical bit in the middle that does describe briefly how you'd configure a cipher in Java with the necessary AES transformation needed to work as the CC3000 expects.

And finally the proof of the pudding - I wrote an application to emulate the Smart Config related behavior of the CC3000, i.e. it can recover the SSID and keyphrase transmitted by any Smart Config application without needing to be able to decrypt the relevant network traffic. You can find where to download the source and all the details here:

CC3000 Smart Config and keyphrase recovery ~ Depletion Region

This should enable one to test the behavior of any Smart Config application one writes, i.e. one can see what a CC3000 would be able to reconstruct from the data transmitted by the application.

Hope you find it interesting. Sorry I do have a rather TL;DR style so some of the posts are very long.

Any feed back is greatly appreciated,



Those are really awesome explanations! I imagine it must have taken you a lot of effort to have to reverse engineer everything to figure that out. Thanks for sharing.

@kudos - thanks for that :smile:

It actually took way longer to write up the explanations than to work out what was going on!

I wish I could develop a more concise style and not feel the need to cover even tiny things in often overly verbose detail.

But I’m really happy if the posts help you and others :slight_smile:

I’ve added an answer to the long outstanding question “How does TI CC3000 wifi smart config work?” on the StackOverflow sister site I know it’s a not really acceptable to canvas for votes but if you like what I’ve written please consider voting for my answer as I think it’s the most complete one. I’m looking for my 15 seconds of fame!

I hope, since I’ve demonstrated how easy it is to recover the SSID and password transmitted by Smart Config, that the need to use the AES key option has become even more obvious.

I think in a previous post @bdub dismissed the issue involved as one of “termporary insecurity” and I’ve seen other reasonable people argue in a similar vein on the TI forums.

I’ve put together a post where I explain why I think even exposing a password for a few seconds is a real problem for end users rather than just a hypothetical problem for the security paranoid.

And given this I also argue that TI should not even offer the option to use the CC3000 without AES.

I’d be interested to know if my arguments are convincing or if after reading them people think this an extreme or OTT position :slight_smile:

Also now that we know how Smart Config works it would be interesting to see if people can think of improvements.

What are the main problems and what could be done about them? To that end I’ve put together some thoughts here, hearing your ideas would be cool too.

In the end most of it is an exercise in thinking aloud as I come up various ideas and then unfortunately knock most of them down :frowning:

As entering an AES key is inconvenient I also look at what length key is really required in this post.

Apologies if at this stage I seem to be spamming with posts linking to my blog - I’m going to shut up now. The examination of Smart Config has been a bit obsessive compulsive on my part. I think I’ve completely ODed on it - so I plan to go quiet for a while and concentrate on other things! :slight_smile:


I asked a question on a while ago as to whether the idea behind Smart Config was novel, i.e. of encoding information in the packet lengths sent over a secure wireless network such that an outside party could recover this information.

I’ve now got at least one good answer. In a paper from 2007 by P. Martin called “Covert channels in secure wireless networks” you can find section 4.4.2 “UDP Packet Size vs MAC Frame Size Experiment” that essentially describes exactly the process used by Smart Config.

And as another commenter on this question points out - if you know the right search terms (“packet size as a covert channel”) you can find a number of hits around this idea.

I thought people might be interested in this as the question of patents has come up a couple of times and this would all seem to be clear prior art.

1 Like

@ghawkins Thanks for the post regarding Smart Config. I used this code to enable my ESP32 application to easily get onto a new web network with minimal coding. In the ESP32, once you have entered the wifi configuration through the IoS app, it writes the parameters to NVS (non-volatile storage). Upon the next reboot, the app reads NVS to determine if a saved configuration exists. If it finds one, it tries to login using those credentials. If the connection times out, it erases NVS, reboots and starts the Smart Config process again. If the initial NVS read doesn’t find the appropriate keys, the Smart Config process is started.

One good thing about the ESP32 architecture is that it allows for NVS to be encrypted.