DOS attack on WPA 802.11?

[Niels Ferguson]

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, niels at ferguson.net, phone: +31 20 463 0977
PGP: 3EC2 3304 9B6E 27D9  72E7 E545 C1E0 5D7E

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com