On password protected free wifi...

Posted by Takehiro Takahashi and Tom Cross on November 12, 2010 at 5:28 PM EST.

There was an interesting post on the Sophos blog on Tuesday from Chester Wisniewski proposing a way to make public WiFi hotspots more secure by enabling encryption with WPA/WPA2-PSK and a well known passphrase like "FreeWifi" which is shared by all users. Slashdot later cited his post, and there has been a number of discussions around the web about whether this idea would (or would not) serve as a cure to attacks like Firesheep.

We’ve been working on this topic here at IBM X-Force for several years and we'd like to discuss the matter in more depth in hopes of providing some clarity about the security properties of the various approaches that have been proposed.

There are two separate security problems associated with open WiFi hotspots.

1. Lack of encryption

Most open WiFi hotspots use no encryption, which leaves a lot of your personal data open to eavesdropping and manipulation as it traverses the wireless network.

2. Lack of authentication

Since anyone can set up a wireless network with any SSID, there is an inherent problem of rogue access points that pretend that they are operated by a  legitimate service provider. Users have no way of verifying 'coffee shop wifi' is operated by the actual coffee shop he or she is at, or some untrusted party.

It is worth noting that there are some examples of WiFi hotspot services that give users an option to establish secure connections using WPA/WPA2 + 802.1x with a previously established login and password, however, most open wireless networks we encounter offer no encryption and no authentication.

Now, let us think about how Mr. Wisniewski's proposal would help mitigate the problems above. Clearly, it doesn't solve the second issue, since using a shared passphrase does nothing to validate the identity of the service provider. Anyone could still set up a rogue access point with the same SSID using the same password and accept connections from unwitting victims.

What about the first problem? Obviously, WPA/WPA2-PSK offers encryption. The question is whether that encryption is meaningful if used in this way. Unfortunately, because everyone knows the password in Mr. Wisniewski’s proposal, if an attacker can observe the handshake between the client and the access point, he or she can calculate the session key used, and decrypt the session. It’s possible for an attacker to force connected wireless clients to disassociate from a wireless access point and perform a new handshake, so attackers can begin monitoring these connections at any time. Therefore, although Mr. Wisniewski’s proposal provides encryption, this encryption is relatively easy for an attacker to break.

Several years ago George Ou suggested a similar approach, but instead of WPA/WPA2-PSK, Mr. Ou suggested using PEAP. In theory, Mr. Ou’s proposal provides more meaningful data encryption than Mr. Wisniewski’s proposal. Unlike PSK, attackers cannot determine the session keys generated with PEAP by simply observing the handshake, even if they know the password that is being used. In our Appendix below we explain why PSK and PEAP have different security properties. However, like Mr. Wisniewski’s proposal, Mr. Ou’s proposal does not solve our second security problem – it does not provide for authentication of the service provider. Therefore, attackers can still set up rogue access points.  They can still cause connected clients to disassociate from a legitimate access point, and reconnect to a rogue access point. From a technical perspective this process is more complicated than the passive sniffing that takes place with Firesheep, but what Firesheep has demonstrated is that once all that technical detail is automated into a simple point and click tool, people will launch these attacks.

In the end, users’ cleartext communications will be exposed to attackers regardless of whether wifi hotspots adopt Mr. Wisniewski’s proposal or Mr. Ou’s proposal.

So what should we do?

Many people are advocating that more websites adopt HTTPS. We think this is worthwhile, but it doesn’t completely solve the problem either. Let’s imagine that we reached a stage where every single protocol your computer speaks with the Internet is encrypted and authenticated, including web browsing, DNS, email, VOIP, and instant messaging. An eavesdropper could still determine what other computers your computer is speaking to. You still have a privacy interest in the list of endpoints your computer is communicating with even if eavesdroppers cannot see the contents of that communication.

But, we aren’t even at that stage yet. We’re far from it and we may never get there. Your computer is still speaking cleartext protocols with many other computers on the Internet and those cleartext connections are still subject to being manipulated. Convincing high profile websites to adopt HTTPS is helpful but it won’t eliminate this problem. 

We believe that the right way to make wireless networks secure is to build open wireless networks that provide both meaningful encryption as well as authentication of the service provider’s identity. As we previously mentioned on this blog, we have a proposal that would accomplish that, by tying the SSID of the wireless network to the digital certificate used in an EAP/TLS handshake. While this change does require software updates, we believe that it makes sense to work toward protecting wireless networks in this way, even though the wired networks that this traffic is backhauled across aren’t necessarily encrypted. The reason is that endpoint wireless networks provide a far greater opportunity for snooping than exists at the backbone, and we are not optimistic that privacy sensitive cleartext protocols will be eliminated from our networks soon.   

Appendix:

If an attacker knows the password for a wireless network and observes the PSK handshake taking place, he can determine the session key and decrypt the communications. However, the same thing is not true for PEAP. In order to understand why it helps to understand how 802.11 establishes connections differently in WPA-PSK and PEAP.

When a client makes a connection to wireless access point, roughly speaking, the following events occur: (1) association, (2) authentication, and (3) key establishment.

During the association phase, both parties exchange their capabilities such as supported encryption types or authentication methods, and then negotiate what protocols to use.

In the authentication phase, WPA-PSK and PEAP function differently. The WPA-PSK uses knowledge of the pre-shared key to ‘authenticate’ incoming users while PEAP carries out a challenge based authentication inside a TLS tunnel created from the authenticator’s digital certificate. In both cases, a common session key called Pairwise Master Key (PMK) is generated on both sides. This key serves as a seed for computing data encryption keys in the key establishment phase. We must note that WPA-PSK calculates PMKs by hashing the shared passphrase and SSID many times, and its value is always static as a result. PEAP (and other types of TLS protected EAP), on the other hand, derive per-session PMKs in an exchange that is protected from eavesdroppers by the TLS tunnel.

Finally, in the key establishment phase, both sides exchange some session specific data such as nonces through “4-way handshake” as illustrated in Figure 1, and generate data encryption keys.

 
ANonce and SNonce are random numbers generated by communicating parties. MICs are message integrity codes for received nonces. Both the client and AP compute a symmetric data session key by running a keyed hash function on a data blob created from the PMK, nonces, and MAC address of both machines.

Since the 4-way handshake occurs in cleartext, collecting nonces and MAC addresses is a trivial task. As a result, if an attacker can generate the PMKs, he or she can reproduce the same data encryption key. This is exactly the shortcoming of Mr. Wisniewski’s shared passphrase proposal. As we mentioned earlier, in WPA-PSK the PMK is a function of the password and the SSID. As everyone knows both of those pieces of information, everyone can calculate the PMK, and therefore the data encryption keys can also be calculated. PEAP and TLS based EAP variants do not suffer from this problem, because the PMK is unique for each session and its calculation is protected by the TLS tunnel.