Attacks against protocols using a pre-shared key for authentication keep getting published. First there was the base attack against WPA(2)-PSK way back in the early 2000s. Then it got enhanced and sped-up by throwing hardware at the problem. Then rainbow tables of the million most popular passwords with the thousand most popular SSIDs were created to more quickly determine the pre-shared secret. Recently the Amazon cloud service was employed to bring password cracking to the masses: check approximately 24 million passwords in one minute for less than 30 cents! What's the problem and how do we go about addressing it?
Well the problem is that the protocol is susceptible to a dictionary attack. That's where a protocol "leaks" information about the secret every time it's run. In the case of WPA(2)-PSK it leaks enough information to run through a large file that comprises all possible passwords-- called "the dictionary", even though its contents aren't limited to words-- trying candidates until the real pre-shared key is found. And, as I mentioned, people can try 192,000,000 of them for about the price of a small black coffee!
The typical way of addressing this problem is to use strong passwords, and then if there's an attack the person giving that "sage" advice say, "not my problem, you should've used strong passwords." This is flawed on a numerous levels, but the two most obvious are:
- moore's law makes this a losing battle. Passwords must continually be lengthened and enriched to deal with faster hardware and that just isn't going to happen.
- it's advice that everyone knows cannot and will not be employed because humans have a hard time entering a simple 20 character string repeatedly without error. Add in numbers, capitalization, and multiply by the number of passwords to remember and we all know that passwords won't be "strong".
So what do we do then? Well the answer is to use a protocol that does not "leak" information about the secret. One that is resistant to dictionary attack. One that will retain its security no matter how fast hardware can search password files.
A couple of years ago such a protocol was developed at Aruba. We've been spending the last couple years trying to advance it in standards bodies. The protocol is called dragonfly and it's the basis of several standards, both published and soon-to-be-published.
- 802.11: dragonfly has been incorporated into the 802.11 standard as something called SAE. This is a true peer-to-peer protocol that allows mesh or ad hoc networks to form securely. It can also be used in the standard station to AP model as a drop-in and secure replacement for WPA(2)-PSK
- EAP: dragonfly is now an EAP method called EAP-pwd, as defined in RFC 5931. It can be used in any wi-fi network to perform mutual authentication based solely on a password-- no certificates required!
- TLS: dragonfly is being proposed as a new TLS ciphersuite to perform secure authentication using only a password. The spec can be found here: tls-pwd (click on "html" off on the right to see the whole thing)
- IPsec/IKE: dragonfly will soon be part of a new RFC specifying secure PSK authentication for IKE and IPsec. The spec can be found here: spsk-auth (again, click on "html" off on the right to see the whole thing).
Where else can dragonfly be used? It could be a replacement for the broken WPS (Wi-Fi Protected Setup) protocol that came out of Wi-Fi Alliance (more on that in a later blog post!). It can be used anywhere passwords are being used today but dragonfly will bring security to that protocol.
The only way to attack a protocol using dragonfly is through repeated active attack: the attacker must perform 1 run of the protocol to learn whether a single guess of the password is incorrect or not. This is easily detectable and allows for passwords to be relatively weak. For example, four lower-case characters means nearly 500,000 possible passwords. It would take an attacker over 200,000 active attacks before she got a reasonable probability of finding out the right password, and that is trivial to detect. In fact, after 50 successive failures it's probably an attacker.
EAP-pwd will be released shortly in AOS to perform EAP offload. It's currently in the top-of-the-tree of FreeRADIUS, hostapd, and WPA supplicant. It has found its way to the Android source tree and will hopefully be in subsequent releases of "Ice Cream Sandwich", the latest release of the Android operating system. And, Aruba has developed a Windows client for EAP-pwd. Wanna give it a try?