Providing an SSID and password to NETMF-based devices where a button and an LED (if even that) are the only user interface is challenging. Doing it securely and with a minimum of user intervention is even more challenging.
To address this, I’ve developed an ‘onboarding’ protocol that uses Diffie-Hellman key exchange and symmetric encryption to securely tell new devices what the current SSID and password is, and to re-configure all those devices automatically if the SSID and/or password changes. It includes a challenge/response facility for authentication and authorization so that you know only genuine and authorized devices are joining the network and devices are not claimed by rogue networks.
Have folks solved this in other ways? Is there interest in a write-up and nuget for this?
[I’m aware that AllJoyn includes a definition for a wifi onboarding service, but I need something that will work now on 4.3 while we wait for NETMF AllJoyn]
From what I have seen most tinkerers are not thinking about security. But, this is a very important issue for large scale deployments. It brought me back to the days when I played a security expert on TV. The protocol you describe sounds just like what we did for the MN-700 Broadband Networking kit back at the turn of the millennium. Are you planning on having an open network to enable the communication necessary to join the more secure network?
Yup - basically, the onboardee (new node in ‘factory fresh’ or ‘unclaimed’ state) puts the wifi in Access Point mode with a random, but recognizable SSID - for instance, a random prefix and recognizable suffix. The onboarder (existing or ‘hub’ node) periodically scans for these SSIDs and will temporarily join that SSID and begin the onboarding protocol. A mutual key is agreed via Diffie-Hellman and then both nodes co-authenticate each other and the onboardee is given the network credentials. Both nodes then switch over to the primary/secure network.
If the network ever dissappears/fails/has credentials changed, then all non-hub nodes will continue to test the last known network and periodically re-advertise themselves on an onboarding network, but because they are now ‘claimed’ they will only re-associate with the original hub (unless someone hits the factory-reset button).
Many aspects of the co-authentication/co-authorization is pluggable because the policies will be very application-specific : e.g., serial numbers, web service for product registration, etc., but in general authentication is via challenge phrases and SHA2 hashes of various shared secrets.
This works best with an onboarder that either has dual wifi channels, or ethernet+wifi so as to avoid loss of comm with the hub on the primary network when the hub switches to an onboardee’s network. That said, it can work with a single interface if you can tolerate some downtime on the hub during a new onboarding.
From a user’s perspective this transitions quite transparently over to the AllJoyn protocol when that becomes available. The wire interactions change, but the user experience does not.
ah - and for what it’s worth, this is not really just about security. Even for tinkerers, it’s about not having to touch every device with USB every time your wifi infrastructure changes. The security is essential so that you don’t open a hole in your home network in exchange for the convenience, but really for me, it’s about having automation that I can stand to live with. That is the central theme of the whole ‘Molarity’ automation framework that all of my ramblings here are building toward.
@ mcalsyn - yeah, this is an important issue to be sure. I’ve been keeping an eye on this area for a while. There is AP mode, but it’s a hassle to the user. Then there is WPS, but it is not on all routers and some ISPs disabled it when a security problem was encountered instead of fixing it. That ruins WPS. TI uses streams of packets with the ssid and password characters encoded in the wpa encrypted packet length (very clever).
Now, all those have issues and I don’t see and standard being deployed to fix this, so we need a solution that works with existing equipment. And it must be simple. I have seen two solutions I like - optical and audio.
Optical is something would be an optical sensor on the device and a flashing screen to encode the ssid and password. I would put a button on the device to put it I a pairing mode with timeout. I believe Electric Imp does this (maybe).
Audio - a modem! The tablet or phone transmit an audible or ultrasonic sound with the password and ssid encoded in the audio. A microphone on the device receives and decodes the ssid and password. Of course you encode it to make it harder to intercept and decode. Amazons but it now physical button do this, I think.
Both need a physical button to start pairing mode with a timeout. Both should include a checksum to validate real transmissions. The device only needs to include a simple light sensor or microphone.
Those are clever solutions, but they require additional hardware in the client device, which means additional cost. The AP mode I am referred to above on the onboardee device (the newly introduced device) is the ESP2866 soft-AP mode. This mode is akin to wifi ad-hoc and allows the device to be both an AP and client simultaneously. This doesn’t require the user to do any setup. This mode allows the new device to advertise an automatically-generated SSID.
The pairing works like this: One-time:
Set up the master/hub device, which includes telling it your SSID/psw On each new client device:
Use a factory-fresh device, or do a factory reset on a device
Either show the device to your phone camera or web-cam, or enter the code found printed on the device into an app.
Power on the device. It will be onboarded silently and without further user intervention. When your SSID or psw changes:
Update the master device - clients will update automatically
@ mcalsyn - It looks very interesting and I would love to read your write up and follow your progress. This is a problem that needs to be solved and your ideas sound very promising.
@ mcalsyn - Oh I see, so the code printed on the device is the adhoc AP ssid name? That certainly prevents snoopers from hijacking it when it’s in pairing mode. But the wifi client (tablet or smartphone) being used to transmit the home wifi ssid and password has to disconnect from that home wifi, connect to the AP, then the user must go back to the client app and transmit the home wifi details. Then the user must reconnect to their home wifi. Is that right?
Actually, no - the code printed on the device is a serial number and is used as a seed for a cryptographic handshake that is used to make sure that you are pairing with the desired device and that the device is pairing with the desired hub. The device and hub generate HMAC256 hashes based on that serial number plus a shared secret in order to make sure they are talking to the right peer.
The SSID is eight randomly generated characters plus a well-known suffix : “_pdonboard”. The hub uses a wifi scan to search for any device advertising this format of SSID, but it does not need to know the full ssid in advance. Technically, I could generate a well-known ssid based on the serial number, but I didn’t do that so that you could skip the whole serial-number process if you don’t care about that level of security.
It is desirable for the hub to have dual interfaces so that you don’t have the disconnection issue. Generally, I have used dual ESP8266 or an RPi with one Ethernet and one wifi interface. Both methods avoid the disconnect-during-onboarding problem. A hub with a single PHY would not work well. The dual PHY problem with NETMF is avoided by using an ESP8266 for one of the interfaces.
And I should emphasize - the pairing steps are just what I showed above. There are no other steps for the user. No interactions at all with the router or anything else. Just those three steps (and only two steps if you forego serial numbers for hijack-prevention).
Hi Martin,
Have you seen this http://blog.lyj.me/51/ Esp8266 has support for smartconfig, so you might be able to use that or at least some of it…
Look for Esp-touch they have an android and ios app source available as well.
I had not seen that particular example (thanks for the link!). but there are two big problems with this approach: First, the promiscuous mode they are using is not available in the AT protocol (at least as of v1.0.0), so you have to code up their approach using the ESP8266 compiler toolchain and run your code on the ESP8266. You would also have to update the AT protocol so that you could trigger this mode from your NETMF MCU. Not impossible, but I wanted to stay in the NETMF domain and didn’t want to be ESP8266-specific if possible.
Secondly, they are cramming the password into an unencrypted field and doing a transmission targetting the onboardee’s ssid. If you are going to do that, you might as well just send a TCP packet in the open since either way you are broadcasting your password to the world. There’s no doubt that their approach would work - it just drops several of my most cherished design points : security, managed code, and hardware-independent design.
[AirKiss, SmartConfig, and a couple others are all susceptible to device hijacking and/or sniffing of your password and generally don’t work over the AT protocol, so are of limited use to MCU hosts like our NETMF chips. The security I am implementing is way overkill for most one-off projects, but at the urging of a bunch of peers, I have decided to build the security in at the start, not as an afterthought.]
@ mcalsyn - ok, I am missing something. I wish we could just chat at a white board… So there is an additional piece of hardware involved, called a hub, that is already on the network, but is also watching for APs of new devices to send encrypted ssid and password to?
P.S. The Windows Media Center interface is the greatest DVR UI in the world. Thanks for that.
@ Valkyrie-MT - yup - there has to be at least one distinguished device that knows the true current SSID. That can be a unique device playing the role of an automation hub or it could be a process in your existing wireless router (as will probably be the case as more routers support AllJoyn and the AllJoyn onboarding service).
re: Windows Media Center - Thanks! That was a lot of fun - lots of stories from that experience …and one of the cooler Ship-It awards.
…and one of the cooler Ship-It awards.