Wi-Fi Protected Setup… A Good Idea Badly Implemented?

This post is a rant about what I think is a pretty decent idea gone pretty badly wrong. The idea is something called “Wi-Fi Protected Setup.”

I have not been able to find any other information on the web that talks about the particular problems I’ve seen (and what I believe to be a not-insignificant security hole), so why not rant about it here a bit? 🙂 Wi-Fi Protected Setup (WPS), as I said, seems to me to be a pretty good idea for solving a valid problem: historically, setting up a secure wireless network is not easy for the average home user. The user has historically been expected to set up a number of security-critical settings when first installing the wireless access point (“AP”, usually a wireless router), such as SSID, security/encryption type, and a passphrase. Once all that is set up, each wireless “client” device must select the correct wireless network (by SSID) and then be given the network’s passphrase in order to connect. For those of us familiar with security and networking, this is pretty simple. For the average home user, it can be quite confusing. My understanding of the idea behind WPS is to help the average user bypass a lot of these steps and still end up with a secure network. In an example WPS setup (described by a whitepaper available from the Wi-Fi Alliance web site), the process might look like this:

  • power up the new AP
  • attempt to connect to the wireless network with a client device
  • verify that the client and AP really should be connecting by:
    • pressing buttons (could be either physical or virtual) on both ends, which starts a limited-time window for allowing the connection, or
    • entering a PIN number provided by the client into the AP

This process would automatically set up an SSID (hopefully unique) and passphrase (hopefully pseudo-random) on the AP and transfer that information to the client. For each new client, the process is simply repeated (with the difference that the SSID and passphrase are not reset for the subsequent added clients). The push-buttons/PIN help verify that only known clients are added to the network, and the user is spared a lot of setup. I quite like the theory. In practice, of course, not all wireless APs and clients support WPS. In particular, the Wireless Zero Configuration utility in Windows XP does not support WPS. My web research also suggests that while Vista supports WPS, it does so in a way that requires a wired Ethernet connection for the initial AP setup. I’m not a Vista user, so I can’t verify this personally. For any AP or client which does not support WPS, the standard “manual” method for connecting to the network must be used: the network’s passphrase must be known and must be provided to the client. My particular rant in this post, however, has to do with the way that Intel chose to implement WPS in their Wi-Fi Configuration Utility (an optional component supplied with their driver which replaces the Windows built-in Wireless Zero Configuration utility) and how it interacts with the WPS implementation in a Linksys wireless router which I have personally used. Intel chose to implement a PIN-based method for authorizing clients on a network. My reading of the WPS descriptions that I’ve seen (including the aforementioned white paper) seems to imply that the PIN method is intended to work by taking a PIN provided by the client and providing it to the AP. That makes sense to me. In that model, the only time a client can join the network (using WPS) is if its PIN is provided to the AP. Access for doing that is presumably restricted to someone who controls the network. However, upon detecting a network which supports WPS, the Intel utility asks the user for a “device ownership password” associated with the AP. Once the user obtains this “password” (which is really a WPS PIN) from the AP and types it into the PC, the connection is established. The Linksys router I used humors this behavior by providing a WPS pin (in addition to having both a physical and a web-based virtual button and a place to type in a client’s PIN). The router’s PIN is provided in the web interface and is printed on a sticker attached to the bottom of the router. Here’s the kicker, though: the Linksys router’s PIN is chosen at the factory and cannot be changed by the end user. I see two security holes here. First, the PIN is a relatively short numeric value. Since all a WPS client needs is that PIN in order to gain access to the network, that effectively creates a very weak “password” (regardless of the size or complexity of the actual WPA/WPA2 passphrase). The bigger problem, however, is that once that PIN has been given out, it can be used again, potentially by a new unauthorized user. Since the PIN cannot be changed, the router’s owner has no way of preventing this from happening. The web interface on the router supposedly gave a way to turn off WPS, but it did not appear to work. I was still able to use the PIN to gain access even after turning that option off. On Intel’s side, there is yet another problem. Not all APs which support WPS provide a PIN. Some can only accept a client PIN (which seems to me to be what was intended in the design of WPS). The Intel utility does not provide a client PIN. It requires a PIN from a WPS-supporting AP. If the AP doesn’t have a PIN, then you’re pretty much stuck. I did not see a way to bypass that prompt and manually connect using the network’s WPA/WPA2 passphrase. The only way I saw around it was to run the Intel setup utility and remove the Wi-Fi Protected Setup feature altogether (which, fortunately, can be removed separately while leaving the rest of the utility intact). At that point, the network can be added manually. This seems like an example of a good idea implemented very badly. I think the whole model of the AP providing the PIN to be used by the clients is backwards. It places control in the hands of the clients instead of the AP. It also reduces security by depending on a relatively short numeric value. I could almost live with that, though, if there was a way to change the PIN or disable WPS on the Linksys router. What really surprises me is that I have not seen anyone else on the net mention this. I may be missing something. The Intel-Linksys WPS interaction I’ve described above is from my own experience, but it’s possible that I’ve done something incorrect. If anyone can see the hole in my description, please comment on this post and explain. If I’m right, though, then this looks like a pretty broken system.