802.11 Shared Key Authentication is bad [was NetworkManager Issues]

Charles R. Anderson cra at WPI.EDU
Fri Nov 5 21:58:55 UTC 2004


On Fri, Nov 05, 2004 at 11:30:26AM -0500, Dan Williams wrote:
> On Fri, 2004-11-05 at 11:08 -0500, Charles R. Anderson wrote:
> > On Fri, Nov 05, 2004 at 05:02:40PM +0100, Ziga Mahkovec wrote:
> > > As for the ipw2100 driver -- versions 0.57+ now actually default to
> > > OPEN.  But NM overrides this so no harm done.  It does make life harder
> > > if you're using ifup scripts with shared key authentication though.  I
> > > had to patch ifup-wireless to force restricted mode.
> > 
> > Shared Key auth is worse than no authentication/encryption at all. 
> > Anyone with a clue will be using Open System.  I don't think we should
> > put too much effort into making Shared Key easy to use.
> 
> Charles,
> 
> Why is it so much worse?

By doing Shared Key Authentication, you are providing potential 
crackers with both the Plaintext and the Ciphertext for the same data.  
This makes is much much easier for a third party to basically figure 
out what the WEP key is.

Here is an excerpt from Jon Edney and William A. Arbaugh's book, Real 
802.11 Security, pp. 91-92:

"During [shared key] authentication the access point sends a random
string of 128 bytes.  The way in which this "random" string is
generated is not defined, but one would hope at least that it was
different for each authentication attempt.  The mobile station
encrypts the string and sends it back.  Sounds good, but hang on a
moment--WEP encryption involves generating a sequence of pseudorandom
bytes called the key stream and XORing it with the plaintext.  So any
one watching this transaction now has the plaintext challenge and the
encrypted response.  Therefore, simply by XORing the two together, the
enemy has a copy of the RC4 random bytes. 
[...]
The attacker is "authenticated" without ever knowing the secret key.  
Hopless!
[...]
So not only does this approach not authenticate, it actually assists
the enemy to attack the encryption keys"

> Also, did you read my explanation of how its much much harder with Open
> System to figure out if the WEP key is wrong?  That's the big sticking
> point here.  If we can't automatically detect whether the WEP key is
> wrong or not (and waiting 30s for a failed DHCP certainly isn't
> "automatic"), then we might as well not even try to improve on the
> current system-config-network.

I agree that that is a problem.  However, there is no good way to fix 
it without compromising the security of the entire system.




More information about the fedora-test-list mailing list