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."

Comments

but I still love the wireless

[stego]

I have a wireless setup at home and absolutely love it. I also assume that everything I do on the network is transparent and so take appropriate steps when the situation is called for. Props to all the developers of GPG and OpenSSH.

And - this type of thing will only eventually lead to us having a more secure wireless networking protocol. Aren't you glad that these guys have the freedom to this kind of research?

Just curious...

[siliconwafer]

Would authentication using Mac Addresses take care of this problem? Or at least mac-address checking... Each wireless client has a Mac Address, after all....

Is this protected by DMC

[monkeyserver.com]

Maybe this is a question of understanding, if some corporation was sponsering or developed these standards could they sue these dudes under the DMC?

Secure wireless

[mrneutron]

I'm trying to design a secure wireless architecture for a multi-site, multi-floor deployment (with roaming). I have to deploy soon: within a month or so, and can't afford to wait until IEEE fixes the standards.

I see possible 2 ways to attempt this (with 802.11b or 802.11a when it's available):

- VPN over wireless
- 802.1x authentication with TKIP

Both have their pros and cons.

I demoed Bluesocket (VPN concentrator/firewall for building wireless DMZ networks), which works. I found it difficult to administer, lacking reporting, and wonder how many VPN tunnels it will handle.

I'd prefer to go with the new industry standard (TKIP and 802.1x auth), and segregate wireless traffic onto DMZs, protected by a custom machine running iptables/sport, to provide firewalling, routing, IDS, arpwatch, etc.

I can't use 802.1x if it's insecure, and I'm having a difficult time determing how insecure 802.1x is based on the articles I've read.

Assuming I used 128 bit WEP, TKIP with fast key rotation, EAP auth via 802.1x, and segregate traffic on a WDMZ with a firewall and IDS, what vulnerabilities are left to exploit?

If it's the MiM attack, VPN over wireless may have the same issue, unless I roll out strong mutual authentication via certificates. Doable, but very unwieldy.

I'd appreciate anyone's throughts on this matter.

- Eric

What does this have to do with Cisco?

[singapour_dude]

Cisco uses LEAP for its secure wireless. Cisco supports WEP only for non-cisco product support. LEAP provides unique authentication to prevent session hijacking and man-in-the-middle. You also get to pay at least three times as much for Cisco. If you really don't care about security that much then you can go buy Linksys or some other commodity brand. This article was pretty crappy anyway. Some guy said he found some weaknesses in wireless security. Some other guy said he was not surprised. If you are using wireless in a hotspot, you should be using a VPN client to encrypt your data, just like if you were connecting from your hotel room. One time passwords and digital certs prevent highjacking of corporate data. Obviously this ass clown never thought of that. Here is an article on LEAP http://www.nwfusion.com/reviews/2001/1217revside3. html

AES too slow and not yet available?

[rkit]

Longer term, the IEEE Standards body intends to adopt AES [Advanced Encryption Standard], the same security protocol sponsored by the National Institute of Standards. "AES is state of the art encryption technology," said WECA chairman Eaton. But AES requires hardware acceleration using a co-processor to off-load the encryption and decryption or it would slow the throughput down to an unacceptable level, according to Eaton as well as Instat's Paulo. It also requires new Wi-Fi cards in the client devices. AES will be available in the first quarter of 2003.

Am I missing something here? AES is an approved standard, implementations have been available for years.

Concerning Speed: the Rijndael AES proposal gives 70.5 Mbits/s for a VisualC++ Implemetation of Rijndael on a P200. This should be fast enough for the clients. Can anyone provide accurate figures, e.g. for the current implementation used in gpg?

Above all: AES is a symmetric block cipher, so this has nothing to do with the security problems adressed, as these seem to be flaws in the protocol. (session hijacking, man in the middle, etc.) These are questions of key managment, not of the block cipher used.

Seems that the chairman is not exactly an expert in crypto...

Re:AES too slow and not yet available?

[eggboard]

You're not incorrect, it's just that the chipmakers want to offload host processing to the chipsets instead of relying on host processing. This assures more symmetric performance across all machines and in network intensive situations in which you might be running 802.11a (54 Mbps raw), sucking host computational power may not be appropriate. For smaller devices that are Compact Flash based and use ARM processors or similar devices, host processing would be in appropriate and require a separate chipmaking development track.

The OEMs, likewise, don't want to pay and support driver development for host-based processing. They want to feed data into an onboard MAC that offloads it to the on-board encryption which sends it off to the PHY and radio.

You're absolutely right on all the other fronts, of course: AES is a piece of the puzzle and there's not a specific reason to not use host processing; it's a gestalt.

As for the rest, the industry hasn't yet taken that deep breath and said, we have to rethink the problem end-to-end.

Re:Let's get the "Inherrent Problems" out in the o

[Adam J. Richter]

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.

You can two parties can use Diffie-Hellman key exchange to agree on a key even when all traffic is being watched.

Also, there is plenty of "reliable encryption that takes prohbitibitively long periods to break", such as triple DES (Data Encryption Standard), and any of the the Advanced Encryption Standard finalists, at least in the sense that a lot of very qualified people have tried hard to break them for a long time in a very open process and so far failed. (Rijndael won the AES endorsement, but, not to my knowledge, because of a vulnerability discovered in any of the other finalists.) Granted, these algorithms are not mathematically proven to require a substantial number of cycles to break or even to be as difficult as some other famous problem (like Michael Rabin's public key algorithm), but, if that is your standard of security, then you also should not be sending even your encrypted traffic over any internet backbone links that are not known to you to be physically secure.

Oh come on....security 101

[Anonymous Coward]

Why on earth use a symetric cipher (rc4), and publish the private key?. Why not simply an asymetric system (rsa/dh/dsa)?

Isn't this all rather over the top? all the hard work has beem done already, why don't we learn?
All the popular operating systems now have built in public key, proved/tested technologies.

This all seems like madness, re-inventing the wheel.

VPN's to everywhere, hub and spoke, meshed, sureley its not that hard! We run 1000+ users, on a mixed wireless/hardwire network. All users are authnticated using SecureID onetime passwords (yes I've read the L0pht stuff, utter fantasy), so we have Authentication and Accountability! ONE POINT.

Then guarantee (as best as possible) confidentiality! easy use public key encryption, built into IPSEC. TWO POINTS.

And the lucky winner of 3 points, and I'm not a french judge! is, well availbility, retrict who
can access the network/data/entity.

What what!, no hacks yet!, I don't trust anyone, users are the worst, second external attackers, and then me and my staff.

SCORE:3 Insightfull.

Client availability is the problem

[sjhwilkes]

I'm responsible for security for a 20 acre wireless net. The biggest problem I have is that I inherited the net and it's multivendor.
Cisco LEAP is great on 1/3 of it - and with WEP and 4 hour keys I feel it's as secure as I'd like it - running a VPN seems overkill and not user friendly. The Avaya (Lucent/Orinoco) bits are a pain because the client devices don't support any advanced security (they're cash registers) and on the Symbol bit the clients are handheld bar code scanners - which don't even support WEP.

The solution, firewalls - each wireless net is a VLAN which only has limited connectivity to the rest of the net. Some cracker can spend the time to get onto the LAN if they want to but they're not going to find anything interesting. The couple of servers that are available are hardened as if they were on the DMZ - I suspect this is the answer for alot of firms until multi-vendor wireless security is sorted out, which I think will be in a year when the clients/APs are replaced with 802.11a or 802.11g devices (we'll wait for 802.11g 'cos the range on 802.11a is unworkable)