People talk about a coming Internet of Things (IoT), pervasive small cheap headless devices that connect to the internet and do things like keep your plants watered.
When you connect a new device to your home network you have to tell it the name (SSID) of your network and the password (assuming you've setup WPA2 or something similar), but as IoT devices typically have neither screen nor keyboard it's hard to see how to do this easily.
There have been various solutions to this problem - all of them somewhat unsatisfactory in one way or another.
TI's solution to this problem is the CC3000 module, a self-contained wireless network processor, along with their Smart Config technology. Using a Smart Config app on your smartphone, laptop or PC you simply enter your network name and password and these are magically communicated to your new IoT device which then uses them to connect to your network.
When I first saw the CC3000 with Smart Config I really wanted it to be the perfect solution to the initial network setup problem.
And without AES it certainly looks like the solution, with AES I think it's still good but other solutions start to look perhaps as attractive.
So what is AES about? Well here's where the problems start - if you're even a little bit interested in cryptography then it's obvious but if, like much of the world, you feel there are better things to spend your time on than symmetric keys, elliptic curves etc. then it might not be obvious - and TI don't go out of their way to clear things up.
The AES element of the product doesn't get much coverage in their promotional literature etc. This video, produced by TI, is typical - wind forward to the 9 minute mark and listen for about a minute:
There's a pretty unclear explanation of why one might want to use an AES key - I'm getting a strong yadda-yadda feel here, kind of "you might want AES for some obscure use cases." I'm not hearing him clearly state something like "if you don't use the AES option then the device will broadcast the end user's network password to anyone who cares to listen, with no special equipment required to do so - any laptop or desktop computer will do."
It's not even entirely clear from this video whether using a key is a manufacturer or end user issue.
Initially TI did clearly document how the SSID and network password were transmitted to a CC3000 enabled device as shown here via a wifi probe. Now they use a different process which they have chosen not to document, referring to it as a trade secret, despite the mechanism being fairly clear from looking at the wifi traffic any Smart Config application generates or from the example Smart Config applications that they distribute (without NDA or obvious restrictions). TI certainly, at the very least, imply that this new mechanism affords some degree of protection from packet sniffing.
TI do not deny that not using an AES key is the less secure option, but not using AES is the option you see most often in their demonstrations, literature etc. So can it really be that insecure not to use AES?
I've heard smart people dismiss the issue as one of "momentary insecurity" - the idea being that it's not really that big a deal if the password is exposed for just a few seconds. Security without an AES key will be "good enough" for most users and anyone who requires more security should stick to devices that do use an AES key.
I'd argue that "good enough" security rarely turns out to be good enough in practice.
What Smart Config does is different from what people generally think about when they think "lax security." If my neighbor uses a website that features a non-SSL login process it still requires active, and clearly malicious effort, on my part to intercept my neighbor's DSL traffic. With Smart Config my neighbor's network password is actively broadcast, no special hardware or tapping of lines is required to receive that data. And I'd argue that a person's home network password is generally far more important than that of some bulletin board that can't afford an SSL certificate.
I'd equate pulling a password out of the air, that's been broadcast by Smart Config, with bittorrenting an episode of Game of Thrones - to many people it doesn't (despite the best efforts of the MPAA, RIAA etc.) feel terribly illegal - while hacking my neighbors DSL is non-trival, involves "real world" actions and feels more like stealing a Game of Thrones box set from a store, i.e. very clearly illegal to most people.
But the Smart Config setup process is so brief - are people really going to notice and capture such events? Computers are tireless, once they've been set to perform a task the briefness provides no protection. Any cheap laptop can monitor nearby wifi traffic and one can buy cheap small dedicated devices to do this job, such as the WiFi Pineapple for around $100.
In my apartment, even without the large external antennas of the WiFi Pineapple, and despite the poor propagation characteristics of the 2.4GHZ and 5GHz bands, my laptop can still see an amazing 28 wifi networks in the immediate vicinity. Even if I ignore half of them due to low signal strength that still leaves 14 networks.
In their paper from January 2013 - Building Blocks for Smart Networks - the OECD estimates that by 2022 the average household will have around 50 IoT devices (with everything, the toaster included, wired in one way or another).
Even if we pick a far more conservative number at random, e.g. 10, and estimate that such devices will last 3 or 4 years (Apple only supported the first edition iPad for less than 2.5 years) and one monitors 14 nearby networks then on average one would only have to wait 9 days between setup events (though I suspect you'd get serious bunching up of events around Thanks Giving and Christmas).
So with a cheap dedicated device, like the WiFi Pineapple, such events hardly fall into the category of extremely rare. One can imagine anyone looking out for such events - from the local nuisance to sophisticated criminals running botnets where the individual bots monitor for setup events, in addition to their main job (though putting a bot's wifi setup into monitor mode generally makes it unusable for other purposes, e.g. sending spam).
As more and more IoT devices start being used it will become more and more worth while looking out for the setup events, any current acceptability of momentary insecurity will disappear fast.
Most of us are lucky enough not to live within range of someone malicious or criminal, so no mater how insecure our home networks are or how irresponsible the devices we connect are with our passwords we'll never get hacked. Many people still use WEP and despite that experience no unfortunate consequences. However some small percentage of people do get hacked and for them it's a very unpleasant experience.
TI and downstream manufacturers using Smart Config without AES will be complicit in attacks resulting from compromised network passwords. The fact that many people use insecure wifi setups doesn't make it somehow OK to produce fundamentally insecure systems. And producing insecure systems is what TI is encouraging by allowing Smart Config to be used without AES.
I certainly wouldn't want to produce a device in the knowledge that only some of my end users will experience serious negative consequences as a result of using it.
One could claim that it's up to end users to make a decision on whether the risks in using CC3000 enabled devices without AES are acceptable. But I think that's hardly reasonable - end users are not in a position to make informed decisions on complex technical issues - on the whole they have to trust device manufacturers to be responsible. End users assume someone else has thought about security, especially when that someone is asking them for a password that protects something valuable, whether it be access to their online banking or their home network.
Most end users (one hopes) now know not to give their passwords to a random web app or downloaded application but tend to trust hardware and things with a clear real world source, they assume such devices will handle their passwords in a responsible manner. When asking for a password there's an expectation it will be used in a secure manner, with Smart Config without AES this is definitely not the case.
The engineering department for the CC3000 may not want to make a big deal about using AES in their product literature etc. as using it makes the product somewhat less attractive, and as such less likely to succeed. But if it does succeed in a big way and manufacturers do use the non-AES option then I think it will only be a matter of time before TI's legal and liability department has to deal with serious reputational and financial consequences.
If I was an end user, for whom the issues involved hadn't been clear, and who had his or her network compromised (whether personal photos were destroyed or bank details taken) and I found that similar things had happened to various other people I'd certainly be looking at a class action suit and for someone to blame, i.e. TI and the downstream manufacturers.
Fundamentally I don't believe TI should be offering the option to use Smart Config without AES - I simply don't see that there is any real class of end user for whom the security/convenience compromise can be considered acceptable.
If someone like me with only a casual interest in security, who has only occasionally used wireshark and never looked at wifi traffic before can write a small application in a few days that can recover non-AES protected passwords broadcast by Smart Config then I think this option has to be considered completely insecure and should not be offered as an option. Security through obscurity is no real security.
Stories such as this one from the BBC, involving a baby monitoring camera that could be hacked, show the large potential reputational risk for companies producing internet connected devices. I think the story will be far worse when someone eventually gets hacked as a result of using a CC3000 enabled device without AES and find out that corporation X knowing sold them a device that broadcast their network password and that TI mass produced the underlying hardware which supported this behavior. The manufacturers of the first generation of smart wifi enabled embedded devices may have had some excuse for overlooking security but now that the hacking of such devices even comes up as a plot theme in popular culture, e.g. the killing of the vice-president in Homeland by hacking his pacemaker, ignorance of the issue is no longer a reasonable excuse.
Technical details
For more technical details see my other CC300 related blog postings and see these discussions:- On the Spark Core forums - "CC3000 broadcasts network password unencrypted." There's some thoughtful input from the Spark team itself and from their users. The Spark Core is a great little device that uses the CC3000 and I hope that any discussion I've kicked off around Smart Config does not affect the success of their product.
- On the TI support forums for the CC3000 - "How does TI CC3000 wifi smart config work on wpa2 encrypted home network?" This discussion is quite long but brings up all the interesting points, note that in this discussion some remarks by me, and more surprisingly by TI representatives, are incorrect - things only become clearer as the conversation proceeds.
Alternative approaches
Using AES reduces the convenience to end users (they have to type in a long AES key in addition to the name and password for the network they want the device to connect to) and it increases complexity for the manufacturers (they have to program individual AES keys into their devices and deliver the keys in a secure manner to end users). This somewhat reduces the attractiveness of the CC3000 with Smart Config when compared to competing approaches. There are various alternatives, none of which seem perfect either, here are some of them and I'd be interested in comments on any other approaches people have come across:- transferring credentials via USB - this requires manufacturers to include a USB port on their devise, along with cable, for the one off network setup task. While USB is pervasive in the laptop/desktop space it is not so ideal for use with smartphones, one would have to provide adapters (for lightening or the old style 30-pin connector for Apple devices, mini and micro USB for Android etc.) and iOS don't make communicating with arbitrary USB devices easy.
- transferring credentials via light or audio - transferring data to headless devices has been around for a long time, back in 1994 Timex and Microsoft teamed up to produce Datalink watches where data was transferred to the watch from the PC by holding the watch to the the screen, the PC would flash the relevant screen area on and off and the watch would decode the data transmitted to it in this way. There are almost certainly earlier examples. The Electric Imp, a competitor (in some ways) to the CC3000, uses this mechanism to transmit SSID and password to the imp (a device with wifi, antenna and MCU all in one small package). They say there are patents pending (see their product page) on their process, which they call BlinkUp - one hopes only on some obscure aspect of the process given that the basic idea has been around forever. Transferring data by audio (using a headphone jack to jack connection rather than a speaker to microphone setup makes things more reliable and less annoying to the end user) is also possible, see devices such as the SparkFun audio jack modem for iPhone and Android.
- making the device act as an access point (AP) and connecting to that AP and entering the credentials directly via e.g. a web interface. Like the CC3000 approach this doesn't require any additional hardware beyond the already necessary wifi chipset - however switching APs involves a degree of difficulty that many end users are not comfortable with. Devices such as those from GoPro use the AP approach for controlling headless devices (but not for setting them up to connect to one's home network).
- Wi-Fi Protected Setup was supposed to address this issue and was built into many home APs - unfortunately it was broken from the start (in a surprisingly obvious and fundamental way) and since the flaws became well known it has been in many cases disabled in the latest software updates for those APs that once supported it.
Any comments, thoughts etc. on any or all of the above would be much welcomed. Thanks for reading this far.
