WEP problems with ndis and ath drivers

Kenneth D. Merry ken at kdm.org
Tue Mar 23 21:52:13 PST 2004


On Wed, Mar 24, 2004 at 14:36:22 +0900, Motonori Shindo wrote:
> Gary,
> 
> From: Gary Corcoran <garycor at comcast.net>
> Subject: Re: WEP problems with ndis and ath drivers
> Date: Tue, 23 Mar 2004 23:05:11 -0500
> 
> > Sam Leffler wrote:
> > 
> > > It appears your AP requires shared-key authentication to associate when  
> > > WEP is enabled.  The current code in the tree does not support  
> > > shared-key authentication (it's actually a bad idea security-wise).
> >
> > Hence I'm curious why, if "open" equates to "no" authentication,
> > you suggest that shared-key authentication is a worse option?
> > Perhaps it is - I'm just trying to learn a bit more...
> 
> Shared-key authentication is in fact a worse option than open
> authentication. Basic idea how shared-key authentication works is as
> follows:
> 
> 
>       Station                Access Point
>                   Auth Req           .... (1)
>           ----------------------->
>                  Challenge           .... (2)
>           <----------------------
>             WEP(IV+Key, Challenge)   .... (3)
>           ----------------------->
>                   Auth OK            .... (4)
>           <----------------------
> 
> 
> Access Point challenges the Station with random number (128
> octets). Station then encrypts it using WEP with a key shared by both
> Station and Access Point, and send it back to the Access Point. Access
> Point validates the reply by first decrypting the packet and then
> calculating the ICV. If ICV tells it is OK, then Access Point grants
> the access.
> 
> Suppose that malicious user sniffs this authentication sequence.
> 
> 
>      Malicious
>       Station                Access Point
>                   Auth Req
>           ----------------------->   .... (a)
>                  Challenge
>           <----------------------    .... (b)
>                    ?????
>           ----------------------->   .... (c)
>                  Auth OK !!
>           <----------------------    .... (d)
> 
> The first two steps (step (a) and (b)) is just like the legitimate
> case (step (1) and (2)). Because malicious user doesn't know the WEP
> key, it may look that (s)he has no way to send a correct challenge
> response in step (c). In fact, this is exactly where this
> authentication scheme is broken!! Because WEP is based on RC4 stream
> cipher, XORing the messages in step (2) and (3) recovers the "key
> stream" associated with a given IV (note that this is not the WEP
> key). Malicious user then computes "(2) XOR (3) XOR (b)" to come up
> with a challenge response and sends it back to the Access Point with
> IV observed in step (3). This challenge response will be accepted the
> Access Point as valid even if malicious user doesn't know the WEP
> key!! Well, I intentionally omitted a few minor points
> (e.g. authentication frame format, linearity of CRC32 and XOR, etc.)
> in this explanation for brevity, but this attack can still be mounted
> anyway.
> 
> You can easily see that this authentication scheme is in fact worse
> than nothing (open authentication). Access Points leaks key stream of
> first 128 octets every time this authentication is performed just for
> free to everybody (including malicious users).
> 
> Considering all this, Access Point should always reject shared-key
> authentication even if Station requests it. 

Yikes!!

That is bad.  So what's the point of WEP then?  I knew it was insecure, but
that is pretty lame.  Is there any other authentication scheme for WEP that
won't reveal the key to a malicious 3rd party?

I suppose, at least with my router, the best thing to do would be to use
WEP for data transmission and control access via MAC address.  The next
step would probably be to put a firewall on the inside of the router and
only allow through traffic that is encrypted with IPSec...

Ken
-- 
Kenneth Merry
ken at kdm.org


More information about the freebsd-mobile mailing list