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

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.

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)