DOS attack on WPA 802.11?

[Niels Ferguson]

At 21:58 18/11/02 -0500, Arnold G Reinhold wrote:
>Modularization is a poor excuse for shipping a cryptographically weak
>product. 

The current alternative would be to ship _no_ 802.11a products. That might
be intellectually preferable, but that's not how the real world works.

>Second in this case the PHY layer does affect a MAC layer
>feature. 802.11a is much faster than 11b. That makes Michael
>even more vulnerable to attack.  If Michael is subject to one forged
>packet per year on 11b, it is vulnerable to one every 10 weeks or so in
>11a. 

Well, no. The time it takes for an attacker to forge a Michael packet
consists mostly of the 1-minute delays of the countermeasures. Using a
faster PHY protocol doesn't speed up the attack, so Michael has the same
strength for 802.11a and 802.11b.

>Third, a stronger variant of WPA designed for 11a could also run on
>11b hardware if  there is enough processing power, so modularization is
>not broken.

But there _isn't_ enough processing power to run a super-Michael. If there
were, I'd have designed Michael to be stronger. 

Maybe you are suggesting is to add yet another cryptographic function; the
current Michael for existing hardware and a super-Michael for newer 802.11a
hardware. Developing super-Michael would cost a couple of month and a lot
of money. I would consider that a waste of effort that should have been
spent on the AES-based security protocols. That is where we are going, and
we need to get there ASAP. It is perfectly possible to design 802.11a
hardware today that will be able to implement the future AES-based security
protocols. That is what software updates are for.


>As for shipped hardware, does anyone know that it couldnot run with a
>stronger version of Michael? And a few shipped units, is far less
>justification than the 10's of millions of 802.11b units out there.

There are millions of 802.11b chips out there. I don't know how many
802.11a chips there are in the field, but certainly a few orders of
magnitude fewer. Creating a significant slow-down for millions of fielded
units is unacceptable. The whole point of WPA is to work well on fielded
units. New hardware should implement the AES-stuff.


[...]
>A marginal improvement on a marginal algorithm can be worthwhile. It does
>break up one attack mode at negligible cost. 

Aah, but the cost isn't negligible. The per-packet overhead is significant
for small packets, and adding more computations for each packet will reduce
the system throughput even further. 

> It might prevent other
>attacks that have not been envisioned.

For a performance-critical design this is a non-argument. We could apply an
FFT, and it may prevent certain attacks, but we won't.

>
>> Rotating the output in a key-dependent way is dangerous. You expose the
>> rotation constants to discovery using a differential attack.
>
>If the rotation constants are derived from the MIC key using a strong hash
>(e.g. SHA1) there is little risk of recovering key bits. Since this only
>needs to be done when the MIC key changes, the computation time should be
>afordable.

But you'd need to implement SHA1 in software. I don't know whether there is
enough code and memory space on each of the fielded chip sets. Do you? And
do we have a cost estimate for implementing SHA1 on all fielded chip sets?
And how does that cost estimate compare to security improvement? Is this
worthwhile? 

Those are standard design questions. I looked at better mixing at the end
of the Michael function and decided against it. It would slow things down
and the attack that changes the last message word and the MIC value had
much the same security bound as the differential attack that does not
change the MIC value. There is no point in strengthening one link of the
chain if there is another weak link as well. Of course, this isn't how I
normally design cryptographic functions, but Michael is a severely
performance-limited design. 

[...]
>Another cheap varient would be to derive the rotation constants from the
>hash of the last two MIC keys. This eliminates even this minute risk.

No, that doesn't work. It would mean that doing a re-key protocol does not
ensure that the keys on both sides agree. It would be easier just to ask
for 128 key bits from the key management system. It has a PRF and should be
able to do it.

>> Additional integrety checks would require extra cycles, which we could also
>> have spent on a more secure Michael version.
>>
>
>I wasn't suggesting they be done by 802.11, but by  higher layers.

If you are suggesting to run IPsec over 802.11, I'm all for it. That is the
configuration that I would suggest. IPsec over 802.11, with the best 802.11
crypto switched on of course. But the higher layers are outside the scope
of our discussion. We are providing 802.11 security and can't count on the
higher layers.

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