[Off topic] Difference between wpa: tkip & aes

[Bryan Kadzban]

Jar wrote:
> OK, I am not a specialist, but the sniffer shows the data-packet as
> below when the WPA-TKIP is selected. How the sniffer know that this
> data is WEP data?
> 
> 802.11 MAC Header
>   Version:              0
>   Type:                 %10  Data
>   Subtype:              %0000  Data Only
> Frame Control Flags:    %01000011
>                         0... .... Non-strict order
>                         .1.. .... WEP Enabled

If this bit is what's making you think it's WEP, that's not entirely
right.  This bit is set whenever the data is encrypted using any
algorithm at all (...well, at least WEP, TKIP, and AES all set it).

> 802.11 TKIP Data
>   WEP IV:               0x00201A
>   RC4Key[0]:            0x00
>   RC4Key[1]:            0x20
>   RC4Key[2]:            0x1A
> 
>   TKIP Key Index:       0x20
>   Reserved:             %00100
>   Ext IV:               %0
>   Key ID:               %00  Key ID=1
> 
>   TKIP SC:              0x00000000
>   TKIP Data:
>   ...||+.......V..  D5 04 B8 7C 7C 2B 84 1D 15 B5 0E D8 E2 56 A3 AF
>   ....
>   ....

I'm not quite sure what most of this means...

> And like this when WPA-AES is selected:
> 
> 802.11 MAC Header
>   Version:              0
>   Type:                 %10  Data
>   Subtype:              %0000  Data Only
> Frame Control Flags:    %01000011
>                         0... .... Non-strict order
>                         .1.. .... WEP Enabled

Again, this is the same bit -- it should really be called the "privacy"
bit IMO (and some packet dissectors do call it that), not the "WEP
Enabled" bit.

> 802.11 TKIP Data
>   WEP IV:               0x0C0000

That's a common CCMP IV value -- I see it fairly often when running the
Windows port of AirSnort against our CCMP network.

But again, I don't know what most of the rest of that info means.

> So this data could be AES encrypted even if this sniffer claims it is
> TKIP/WEP?

Yes -- if the sniffer was written before CCMP was standardized, it might
claim that CCMP packets were TKIP.  (Or, if it was written before TKIP,
it would claim that everything was WEP due to the privacy bit being set.
This is what AirSnort seems to do, for instance -- but I have it log to
a pcap-format file, and then pull that file up in Ethereal, which gives
better results.)

>>That weak key claim is probably valid only if WEP was used (i.e., not
>>for TKIP and certainly not for CCMP). Anyway, even for WEP, there are
>>more efficient ways of cracking the key than weak keys, so reporting
>>weak is kind of pointless for WEP nowadays.. It is weak, no matter what
>>key is used.
> 
> Strange, Kismet complais about weak keys even when the WPA-AES is
> selected from the AP.
> 

Weak keys for WEP (actually, I believe it's talking about weak IVs, not
keys, but I could be wrong there) are not weak if you use a different
encryption system.

The weakness of some IVs was due to the fact that the first bunch of
bytes out of RC4's pseudo-random number generator were not actually
pseudo-random.  RC4 is basically an XOR encryption against a
pseudo-random bitstream, so if you know the original data (e.g. an IP
header), and you have the encrypted data, it's easy to recover the
pseudo-random stream.  And if certain IVs cause a correlation between
the stream and the key bits, you can recover some of the key bits with a
decent probability (much better than brute force).

I don't know the details of the newer attacks on WEP, but this is likely
the attack that Kismet is warning you about.  But TKIP throws away the
first bunch of supposedly pseudo-random bytes before using them to XOR
anything, so even if one of these "weak" IVs is used, the non-randomness
is lost by the time all those bytes are thrown away.

And AES doesn't even involve a bitstream or XORs (its encryption changes
the output bytes depending only on the input bytes, the current counter
value (the IV), and the pairwise temporal key), so it's not vulnerable
to anything like the WEP issues.  (It may be vulnerable to other kinds
of attacks, but so far nothing of import has been found.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20051106/ff899cd5/attachment.pgp