DOS attack on WPA 802.11?

[Niels Ferguson]

At 12:03 11/11/02 -0500, Arnold G. Reinhold wrote:
[...]
>One of the tenets 
>of cryptography is that new security systems deserve to be beaten on 
>mercilessly without deference to their creator.

I quite agree. 

>And I would argue 
>that the Michael countermeasure is no ordinary design tradeoff. It is 
>rather like a doctor prescribing a drug with severe side effects on 
>the theory that it is the only way to save the patient's life, 
>something that should be done only with the greatest caution:

Here I disagree. The Michael countermeasures do not introduce any danger
that does not already exist in the system. Therefore, removing the
countermeasures has no benneficial effects.

[...]
>about it.  All they have to do is write some code that sends a couple 
>of bad packets every minute or so to any network it finds.  This 
>won't even be noticed by 802.11 nets that aren't using WPA, but those 
>that are will be severely disrupted. Guess what will happen? The 
>network administrators attacked will turn WPA off.  As word spreads, 
>other net admins won't even bother turning it on.  They are 
>overburdened anyway and installing WPA won't be a picnic.
[...]
>I would argue that the Michael countermeasure DOS attack breaks WPA 
>security as effectively as a cryptographic attack. It's simple, it's 
>practical, it's specific to WPA, and could even be spread by virus. 
>And if such an attack occurs, it will generate as much bad press as a 
>cryptographic attack. How will the WiFi Alliance respond? Issue a 
>press release pointing out that other DOS possibilities exist in 
>ordinary 802.11? And how much credibility will be left when 802.11i 
>is finally ready?

As I mentioned before, there are generic DOS attacks against 802.11 that
require very few transmissions. These can be used to mount the same attack
against WEP, WPA, the future AES-based security protocols, or any other
security protocol on top of 802.11. It is thus not specific to Michael or
the Michael countermeasures. It is a very valid criticism of the system,
just not of Michael.


>o Second, the doctor should be certain of the diagnosis.
>Is the patient's life really in danger? In this case that means 
>asking how easy it really is to break Michael. Normally, 
>cryptographers should be extremely conservative in assessing the 
>strength of an algorithm.  But when the response to perceived 
>weakness is to add a different vulnerability,  I would argue that the 
>test should be what is realistic, not the ultra conservative worst 
>case.  The Intel article said the best known attack is a 29-bit 
>differential cryptanalysis. How practical is that? Does it require 
>vast amounts of chosen plain text?

That is the currently best-known attack on Michael. It means that an
attacker can forge a packet with probability around 2^-29. That is the
probability of success for each attempted forgery. If you let him try 1000
packets per second, then we expect the first successful forgery within a
week. 

I only spent a limited amount of time searching for the best possible
attack. We have to assume that the attack will be improved somehow. Before
you know it you are down to a timescale of hours or seconds. Currently we
have a factor of 2^9 between the design strength of Michael and the best
known attack. That is a _very_ small factor for a newly invented
cryptographic function. We cut it as close as we dared, and much closer
than I feel happy with.


>If there is no practical Michael busting attack on the horizon, than 
>the objection to allowing users to turn the countermeasure off, 
>perhaps with a warning that doing so risks security, seems harder to 
>understand.

Attacking Michael without countermeasures is practical right now. Giving
the user the option to destroy security is not a good idea. The article you
quoted points out that the vast majority of networks are misconfigured. The
obvious lesson is _not_ to provide configuration options that result in
insecure networks. If you want an insecure network that is not vulnerable
to the countermeasures DOS attack, you can switch to WEP or switch of all
security. This goes back to the TGi mantra: "We have enough efficient
insecure protocols. We don't need another one."


>o Third, the doctor should be certain that no other treatments are available.
>The question of whether a significantly stronger MIC can be created 
>within the limited computational budget available is still an 
>interesting one. I hope more details about the algorithm and the 
>constraints, both in time and space for object code, will be 
>available very soon, if they are not already.  If something markedly 
>better were developed in the next few months, perhaps the WiFi 
>Alliance could be persuaded to drop it in before release.  At worst, 
>work in this area could be a useful backup in case AES-based 
>solutions prove too cumbersome to retrofit.  I have some preliminary 
>ideas based on what I read in the Intel paper, but I will put them in 
>a separate message.

Michael was the best I could come up with given the parameters that I was
given. If you want more security, the simplest thing is to add one or two
rounds to the Michael block function, but this comes at a significant
computational cost. The feedback from TGi was that if Michael is too slow
then people will simply not use it because of the reduced throughput. This
is a tradeoff: If you make Michael slower and more secure, then fewer
networks will use it. Like any tradeoff you can argue whether the right
point on the curve was chosen. 


>o Then there is the notion (which is never supposed to cross a 
>doctor's mind) that the patient's job isn't vital so why worry?
>I take issue with is the proposition that users can be expected to 
>avoid 802.11 for mission critical applications.  One of the main 
>reasons for the explosive growth of this technology is that it 
>enables non-technically trained people to build networks in a  simple 
>plug-and-play way. These people expect stuff they buy to work and 
>will use this systems in ways we never imagine.

That doesn't change the fact that using a wireless system for
mission-critical tasks is a really dumb idea, and there is _nothing_ we can
do to change that fact. All 802.11 systems are open to a DOS attack. I'm
sure that users will use it anyway for mission-critical applications, and
people will get killed by it. 

[...]
>The economics of WiFi mass adoption mean that other solutions will 
>become too expensive, if any are available at all. Even if a system 
>designer wants to avoid the risks of using 802.11, his boss may axe 
>the extra cost. Then there is the question of the third world, where 
>often no hard wired infrastructure exists. In many impoverished 
>regions, wireless solutions are providing the first and only Internet 
>connectivity. You can be sure mission critical applications will use 
>it.

Yes, and it will be dangerous until some regulator comes along and outlaws
it, or outlaws the inteference. Regulators are why we no longer use lead
pipes for our water, take arsenic as an antibiotic agains syphilis, or
drive without seatbelts.


[...]
>o Some doctors might justify a risky drug because the patient has 
>several other diseases that could be fatal. 
>The argument that wireless solutions don't have to worry about DOS 
>attacks because there are so many of them smacks of this. WiFi is a 
>huge success and with that success comes a responsibility to keep 
>improving the product and eliminate known risks.

As far as I know, nobody has yet proposed any viable solution to DOS
attacks against a wireless network that operates in an unlicensed band.
Maybe we can do it, but I'm fairly sure it will require a complete redesign
of 802.11.


>Take the packet cancelling attack Niels described.  There may well be 
>defenses that could be developed against packet cancelling. The 
>higher level attacks he described could be dealt with by 
>encapsulating over-the-air TCP/IP packets in encrypted envelopes, 
>perhaps padded to standard lengths. Even the low level packet 
>canceling technique itself might be defeated if the receiver cards 
>can be persuaded to report all bad packets.  If we are using 
>military-strength crypto, why not use military strength antijam? 
>There is a lot of AJ technology developed for military use that could 
>be employed. Indeed the spread spectrum underpinnings for 802.11 come 
>from that world.  In my opinion, this attack ought to be on the 
>agenda for 801.11i. And in any case, the packet cancelling attack is 
>a lot more complex than the Michael countermeasure attack I posited.

Yes, we might be able to solve all these problems, but nobody has yet even
proposed a solution. It certainly isn't possible on the time-scale we are
talking about, and it certainly won't work on existing hardware, which is
what Michael is all about.


>The legal obstacles to pursuing DOS attackers also are a poor excuse. 
>I am not a lawyer, but as I understand things, the problem arises in 
>the U.S. because WiFi is authorized under FCC Part 15 rules, and 
>those rules state that users of Part 15 devices have to accept 
>interference from other users.  Still, if the interference is 
>intentional, there may be bases for actions under a variety of 
>federal laws.  For example, 47 USC 333 :
>
>"No person shall willfully or maliciously interfere with or cause 
>interference to any radio communications of any station licensed or 
>authorized by or under this chapter or operated by the United States 
>Government." (1 year in jail per 47 USC 501). If the network is used 
>by a US Government site or someone doing defense work, 18 USC 1362 
>would kick in, with 10 year sentences.

No, the problem is that the 2.4 GHz band in which 802.11 operates is an
unlicensed band. Anyone is allowed to transmit 100 mW in it, I believe.
Standard microwave ovens work on this frequency and can cause interference
with 802.11 networks. As far as I know it isn't illegal to interfere with
an 802.11 network as long as you don't transmit more than 100 mW. Maybe you
need a half-lame excuse for your transmissions, but that could be as simple
as doing your own experiments on microwave communication protocols. (Note:
I'm not an expert on these things, but this is what I've picked up so far.)


>Active attacks, such as the Michael countermeasure DOS attack or 
>packet canceling, would seem to come under the anti-hacking law 18 
>USC 1030a5A:  "knowingly causes the transmission of a program, 
>information, code, or command, and as a result of such conduct, 
>intentionally causes damage without authorization, to a protected 
>computer"  (5 years). The recent anti-terrorism law broadened the 
>definition of "damage."

That's not how I read it. The DOS attacks do not _cause_ the transmission
of a program or command. They _prevent_ it. And it isn't clear that
stopping a computer from doing its work causes damage to the computer.
Anyway, I believe this gets well outside the scope of Michael and should be
left to the lawyers.



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