Improper Decodes in Wireless Protocol Analyzers
Last Post: February 9, 2008:
-
A problem wireless protocol analyzer vendors are experiencing right now is how to differentiate between data frames encrypted with TKIP versus CCMP. Protocol analyzers capturing data on a purely CCMP network will decode the frames as having used TKIP.
The reason for this is that bit 5 of the Key ID octet is the same for TKIP and CCMP. Bit 5 denotes use of an Extended IV (used both by TKIP and CCMP), and therefore it is difficult (perhaps impossible) to differentiate between the two by ONLY looking at the data frame itself.
The way the receiving station knows how to decode (using TKIP or CCMP) is defined in sections 8.4.2 and 8.4.3 of 802.11ma-d9.0.
Here are my thoughts on how analyzer vendors "may" be able to differentiate these two types of encrypted traffic. I'm not a developer, so don't take this as gospel.
If the analyzer sees a Beacon or Probe Response from an AP that has only CCMP enabled in its RSN IE, it can be assumed that all stations swapping protected data frames with this AP are using CCMP.
If the analyzer sees a Beacon or Probe Response from an AP that has CCMP and TKIP enabled as pairwise ciphers in the RSN IE, then it must look at the (Re)Association Request frames of each station to determine whether TKIP or CCMP is in use. The standard says (grossly paraphrased), "the highest cipher supported by both the AP and STA should be used". If the analyzer sees CCMP and TKIP in the RSN IE in the Beacon (or Probe Response) and then sees a particular STA's (Re)Association Request frames's RSN IE supporting only CCMP, then it should realize that CCMP will be used in this association. The same would apply for TKIP.
I can't see any other way to do it at the moment. I've sent this suggestion to one vendor already, and have asked another vendor to look into it. I'm posting this publicly so that all vendors (and users of protocol analyzers) may benefit.
Anyone want to chime in on this?
Thanks,
Devinator -
Around 99% of data frames can be decoded correctly by using the check :
WEPSeed[1] = ( TSC1 | 0x20 ) & 0x7f
Any comments? -
Holy smokes - I don't even know what that means...
Is this something you put into the source code of an analyzer before compiling or something?
Devinator -
Oops...
If you check the 802.11i standard,
TKIP requires the WEP Seed field (in header) to be set in a particular way as per the formula
WEPSeed[1] = ( TSC1 | 0x20 ) & 0x7f
CCMP has PN numbers there.
Now, if you check at the position of TSC1 and WEPSeed[1] as per the formula and matches, decode it as TKIP else decode it as CCMP!!
- 1