As the designer of Michael and the countermeasures I think I should respond.
At 16:17 07/11/02 -0500, Arnold G. Reinhold wrote: >The new Wi-Fi Protected Access scheme (WPA), designed to replace the >discredited WEP encryption for 802.11b wireless networks, is a major >and welcome improvement. However it seems to have a significant >vulnerability to denial of service attacks. This vulnerability >results from the proposed remedy for the self-admitted weakness of >the Michael message integrity check (MIC) algorithm. > >To be backward compatible with the millions of 802.11b units already >in service, any MIC algorithm must operate within a very small >computing budget. The algorithm chosen, called Michael, is spec'd as >offering only 20 bits of effective security. > >According to an article by Jesse Walker of Intel >http://cedar.intel.com/media/pdf/security/80211_part2.pdf : > >"This level of protection is much too weak to afford much benefit by >itself, so TKIP complements Michael with counter-measures. The design >goal of the counter-measures is to throttle the utility of forgery >attempts, limiting knowledge the attacker gains about the MIC key. If >a TKIP implementation detects two failed forgeries in a second, the >design assumes it is under active attack. In this case, the station >deletes its keys, disassociates, waits a minute, and then >reassociates. While this disrupts communications, it is necessary to >thwart active attack. The countermeasures thus limits the expected >number of undetected forgeries such an adversary might generate to >about one per year per station." > >Unfortunately the countermeasures cure may invite a different >disease. It would appear easy to mount a denial of service attack by >simply submitting two packets with bad MIC tags in quick succession. >The access point then shuts down for a minute or more. When it comes >back up, one repeats the attack. All the attacker needs is a laptop >or hand held computer with an 802.11b card and a little software. >Physically locating the attacker is made much more difficult than for >an ordinary RF jammer by the fact that only a couple of packets per >minute need be transmitted. Also the equipment required has innocent >uses, unlike a jammer, so prosecuting an apprehended suspect would be >more difficult. > Yes, the Michael countermeasures allow a DOS attack. This was widely discussed in 802.11-TGi before the countermeasures were accepted. We cannot make the countermeasures weaker without weakening the entire security. As the security for Michael is already marginal, I strongly advise against weakening the countermeasures, or even configurable countermeasures. If you want a fast and insecure protocol you can use WEP. What we don't want to do is to do all the work to get a secure protocol, and then invite users to destroy critical security properties in the name of efficiency. The Michael-countermeasures based DOS attack is not important for the following reason: there are other, more serious, DOS attacks in the basic 802.11 protocol. If we 'fix' the countermeasures to make the DOS attack more difficult the attacker will simply switch to one of the other DOS attack modes. The net gain is zero, so there is no reason not to use the countermeasures as specified. The crucial observation is that any station can delete a packet whilst it is in transit. Here is how to do it: - Listen for a packet that you want to delete in transit. - Receive the packet (you can store it for future use if you want), and turn on your transmitter just as the final 4 CRC bytes are being transmitted. By transmitting at the same time the last 4 bytes will be jumbled at the proper receiver of the packet. The receiver will find a CRC error and discard the packet. - Now the tricky part: send a MAC-level acknowledgement to the packet transmitter. The receiver didn't get the packet, so it won't send an ACK. But if the packet transmitter receives a properly formatted ACK (which has no cryptographic protection) then it assumes the packet arrived in good order. Some discussions with other engineers showed that it is quite possible to do this attack with existing 802.11b chip sets. Just like airsnort directly drives the chipset, a different attack tool could perform this one. Now for the higher-level attacks. You can create rules about which packets to delete. Even though packet data is encrypted, it is often easy to recognise the packet type just by its size, source, destination, and order w.r.t. other packets. Deleting all TCP ACK packets will take down the TCP functionality. You get a network where NFS and ping work perfectly, but POP and HTTP do not work. Deleting DNS lookups or DNS responses could also be interesting. Deleting ARP packets will prevent computers form logging into the network at all. DHCP is another avenue of attack. The list is quite long. This packet-deletion attack is very effective as a DOS attack. It actually requires less total transmission time than the Michael countermeasures based DOS attack, so it should be even harder to detect. There seems to be no cure for this attack short from completely redesigning 802.11, and I have a feeling there will be little support for that. The bit about prosecuting a jammer is very optimistic. 802.11 operates in an unlicensed band. I'm allowed to transmit as much power in that band as anyone else. Even if you find the jammer, her reaction might simply be: ``yes, so what?''. >The ability to deny service might be very useful to miscreants in >some circumstances. For example, an 802.11b network might be used to >coordinate surveillance systems at some facility or event. With >802.11b exploding in popularity, it is impossible to foresee all the >mission critical uses it might be put to. Anyone using a wireless network for mission critical use is out of his mind, and I consider it to be criminally negligent. Jamming an RF network is just too easy. You can buy a 1 kW jammer right in the supermarket; they are called microwaves. >Here are a couple of suggestions to improve things, one easier, the >other harder. > >The easier approach is to make the WPA response to detected forgeries >more configurable. The amount of time WPA stays down after two >forgeries might be a parameter, for example. It should be possible >to turn the countermeasures off completely. Some users might find the >consequences of forgeries less than that of lost service. For a firm >offering for-fee public access, a successful forgery attack might >merely allow free riding by the attacker, while denied service could >cost much more in lost revenue and reputation. If people don't want security they can switch to WEP or switch off the security altogether. The quote from TGi is: we have enough efficient and insecure protocols already. We don't need to add another one. Making the countermeasures configurable is just a bad idea. What's worse: the next big security story will be how the new improved WPA security can still be broken. >Another way to make WPA's response more configurable would be for the >access point to send a standard message to a configurable IP address >on the wire side when ever it detects an attack. This could alert >security personal to scan the parking lot or switch the access point >to be outside the corporate firewall. The message also might quote >the forged packets, allowing them to be logged. Knowing the time and >content of forged packets could also be useful to automatic radio >frequency direction finding equipment. As long as some basic hooks >are in place, other responses to forgery attack could be developed >without changing the standard. Most networks don't have security personal. If the access point _can_ be switched to be outside the firewall, why wasn't it there to begin with? That is of course where it should have been all along. And if you have automated DF equipment (probably very expensive) than you can find the DOS attacker but not necessarily do anything about him. >The harder approach is to replace Michael with a suitable but >stronger algorithm (Michelle?). I am willing to assume that >Michael's designer, Niels Ferguson, did a fine job within the >constraints he faced. But absent a proof that what he created is >absolutely optimal, improving on it seems a juicy cryptographic >problem. How many bits of protection can you get on a tight budget? >What if you relaxed the budget a little, so it ran on say 80% of >installed access points? A public contest might be in order. There is an algorithm called Michelle. That was my second attempt. Michael is the third attempt. (The first one was called Mickey.) I'd love to see more work done on how good a MIC you can create on these slow CPUs, but the issue is moot. Michael is almost a year old now. It is going to be fielded soon. Any new design would have a lead time of about a year or so. We shouldn't spend our time re-fixing WEP. Instead our efforts should be directed towards getting a good security protocol in place, using AES as the main cipher engine. >Clearly, WPA is needed now and can't wait for investigation and >vetting of a new MIC. But if a significantly improved MIC were >available in a year or so, it could be included as an addendum or as >as part of the 802.11i specification. Some might say that 802.11i's >native security will be much better, so why bother? My answer is that >802.11i will not help much unless WPA compatibility is shut off. And >with so many millions of 802.11 cards in circulation that are not >".11i" ready, that won't happen in most places for a long time. On >the other hand, an upgraded MIC could be adopted by an organization >that wished improved security with modest effort. Backward >compatibility could be maintained, with a countermeasure that simply >turned off access by Michael-based cards when a forgery was detected. I believe most existing cards will be useable with 802.11i by putting a lot of the cryptographic processing onto the laptop. The laptop has enough computing power to keep up with the network. So the switch to an AES-based security system does not require all old cards to be thrown away. Cheers! Niels ============================================================== Niels Ferguson, [EMAIL PROTECTED], phone: +31 20 463 0977 PGP: 3EC2 3304 9B6E 27D9 72E7 E545 C1E0 5D7E --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
