Slashdot Mirror
Researchers Claim to Crack 802.1x WiFi
satsujin writes: "Researchers from the University of Maryland have released a paper on the weaknesses found in the 802.11x protocol. It looks like it might not be as strong as Cisco has contended."
← Back to Stories (view on slashdot.org)
...has alot more info on the security issues concerning this protocol.
The Unofficial 802.11 Security Web Page
Here's the UMD Professor's 802.11 Research page
Because of this, a security administrator, or even a home user, has to assume that every packet sent over a wireless connection is intercepted. Until there is reliable encryption that takes prohibitively long periods to break (remember, WEP is broken, and the break is a relatively quick one), this technology is simply unsecure, particularly for corporate use.
This standard has been extended for wireless use. The problem described in the paper is quite different from the problem of cracking WEP. 802.1x uses a similar method of authentication and encryption that SSL does. It also provides for the possibility of changing WEP keys periodically. Although WEP is quite flawed, that problem can be avoided by changing the key on a per client basis with greater frequency than is required to determine what the key is.
The problems described by the paper could only happen in an exceptionally poorly configured wireless deployment. For these exploits to work you would have to be using 802.1x with WEP encryption disabled. This would be a strange thing to do since one of the main purposes of using 802.1x is to get effective WEP key rotation. For the man in the middle attack, you would need to have an imporperly configured authentication server (usually RADIUS).
I don't want free as in beer. I just want free beer.
The man in the middle attack can be avoided by using mutual authentication which is a part of the EAP-TLS standard usually used to implement 802.1x. The version of the standard being urged by MS and being shipped with Windows XP can be configured to not have this vulnerability. The problem here is that this must be configured on the client and you might not always have control over the clients.
I don't want free as in beer. I just want free beer.
Sorry, no. Many operating systems (and most cards these days) allow you to change the MAC address of the card. Given that you're broadcasting your MAC with all the rest of your traffic, someone could just change their card to your MAC address & be on your network.
That's not entirely true.
Linux (I cannot speak for other Unices) changes your MAC address by setting the card into promiscuous mode, so that it listens to every MAC address. Then in software, it filters out MAC addresses that don't match the MAC address you have specified. It also attaches the specified MAC to outgoing packets, obviously.
At least this is how it was done in the 2.0 series kernels. I can't imagine it has changed much.
Random and weird software I've written.
You can two parties can use Diffie-Hellman key exchange [swcp.com] to agree on a key even when all traffic is being watched.
As long as an attacker can only watch, this is true. An active attacker can mount a man in the middle attack (one of the attacks in the article was exactly this type) against a naive implementation. However, used correctly, DH can provide secure key agreement.
Also, there is plenty of "reliable encryption that takes prohbitibitively long periods to break", such as...
All of this is unnecessary. Why would we want to use a prohibitively slow block cipher like 3DES, or even a moderately slow block cipher like any of the AES finalists, when the stream cipher already used in WEP is perfectly adequate? RC4 is a well-respected cipher and can accomodate ridiculously large key sizes. WEP's problems aren't related to the algorithm, but to the misuse of the algorithm (it's a well-known fact that with RC4 you *must* discard the first few bytes of the keystream to permit the state table to be adequately mixed).
The article commented that they're considering AES for the next generation of wireless security, which makes it clear to me that they still don't get it. The problem *isn't* that RC4 is insecure, in which case using AES would be a nice fix, the problem is that *any* cipher applied in a foolish way by people who don't understand cryptographic protocol design will be weak, no matter how good that underlying cipher is.
I only hope that they're smart enough to publish the new protocol and solicit reviews and comments from people who do know what they're doing. Of course that only helps if they listen to the responses. As Arbaugh and Mishra point out "If anybody breaks [the encryption], they not only break the confidentiality but they also break the access control and the authentication so one break breaks everything. That is not good design. Each security mechanism should stand on its own." What they need is a fundamental redesign, not a new cipher, and they may not want to hear that.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
This is old news. IEEE 802.1x is EAP, which has been used for dialup connections with PPP for years. The problems are well known.
You can run Protected EAP on top of EAP/802.1x and protect the connection from the problems, see:
PEAP draft
Of course, you'd need the WEP fix to solve the privacy and integrity problems of the connection as well.