WEP-Open Key Auth - detection of Decryption Failures???

[Tony Espy]

Dan Williams wrote:
 > On Mon, 2006-02-20 at 13:21 -0500, Tony Espy wrote:

Thanks for your comments!

 >>Is there anyway to detect decryption failures after association with a
 >>WEP Open Key access point other than keeping track of the discarded
 >>undecryptable RX packets via /proc/net/wireless or
 >>/proc/net/hostap/wlanN/stats?
 >
 > Not without driver support, but it's unclear what further information
 > you want here...

Well, it'd be nice if there was a wireless event, but i know that's 
asking a bit much.

 >>We frequently get customers calling in stating that they can't get an IP
 >>address for their Pepper Pad and quite often it can be traced back to an
 >>invalid WEP key entered.
 >>
 >>It seems like Apple has some kind of magic in their laptop WiFi
 >>driver(s) and/or UI that figures out that a WEP key is incorrect and
 >>displays a popup message almost immediately.
 >
 > There is _no_ way to determine whether a key is incorrect with Open
 > System.  If there is, I'd love to hear it.

Understood.  My boss has been asking me how to do this for 2 years and I 
keep telling him there isn't one!  ;)

 > I've talked to the original lead of the Airport software, and asked 
him this exact question.  He
 > said the the Airport drivers will always try to do Shared Key when the
 > AP is WEP encrypted.

Hmmmm...  never thought of that approach.  Linksys APs have a WEP auth 
setting of Auto or Shared.  So, when set to Auto, a client can use 
either auth method.  I wonder what would happen if the AP was set for 
Open and a client tried to associate using Shared Key?   Guess it'd time 
out?  I wonder if the driver would see an authentication failed from the 
firmware?

Unfortunately, I can't use this trick as it looks like there's no 
notification of an authentication failure via a wireless event and/or 
return code from a WE or HostAP ioctl.  Instead, the association ends up 
timing out which could indicate a whole range of possible failure cases...

Also, knowing that WEP in any form is easy to crack these days, it's 
probably not worth debating which form of WEP authentication is easier 
to crack.

 > Beyond that, there's no way to know that your WEP key is wrong in Open
 > System besides not being able to decrypt frames from the AP.  In SK at
 > least, you must prove you know the correct key before you are
 > authenticated/associated, but there's no such thing in Open System.

Again, understood...

 > And with Open System, if you don't have the right WEP key, your 
packets get
 > dropped at the AP and you get no response.  So it pretty much can't be
 > done.

Hmmmmm, the bad rx decrypt count definately seems to increase in this 
case... once associated with an AP, are there management packets that 
it'll send that are encrypted with the WEP key?

 >>The only way I can think of detecting a bad key from user space would be
 >>to modify the driver to reset the 'rx_discards_wep_undecryptable'
 >>counter to 0 on association, and then monitor the counter, displaying a
 >>popup dialog if the counter starts increasing.
 >
 > Except that you're never guaranteed to get traffic from the AP at all,
 > even if your WEP key is correct.  If the AP is dropping badly-encrypted
 > packets, it will never get your traffic for DHCP or whatever.  And you
 > can't rely on traffic coming from the AP, because there might not be
 > any.
 >
 > The long and short of it is that counting badly-encrypted packets from a
 > certain AP to get an idea of whether or not the WEP key is incorrect is
 > an /optimization/, not a solution.  It /might/ give you an idea of
 > whether or not the key is bad, but it might not.  You never know.

I agree it's an 'optimization' not a solution, but if it makes the user 
experience better 50% or more of the time, that's still a win in my 
book.  If we can't detect decryption failures, there are timeouts for 
both association and IP address assignment that generate messages to the 
user.

ciao,
/tony