Wireshark makes mistake; Calls CCMP encrypted wireless data frames as TKIP !

Have you ever been bugged by Wireshark protocol analyzer tool? If yes, what was the last anomaly you found in it? For me, it seems to be wireless data frame dissector making mistake in decoding wireless data frame encryption type.

Wireshark, earlier known as Ethereal, is one of the most popular open source protocol analysis tool and frequently used by network and security analysts all over the world to analyze the performance or security of a protocol/network.

Figure 1: WPA2-CCMP Enabled APs

Just a few days back, I was analyzing an IEEE 802.11i enabled Wi-Fi network and found an anomaly in the behavior of the wireless network operation as shown by the Wireshark version 1.4.0. Wireless data frames exchanged between a WPA2-AES configured wireless client and an access point was marked as CCMP encrypted, which was obvious but a few data frames were marked as TKIP encrypted which raised the suspicion. 

Figure 2

How could WPA2-AES (and Mixed mode) configured wireless client or AP transmit TKIP encrypted data frames?

So, I decided to investigate it further. This blog post is about my findings on this issue.

As we all know, there are three types of data frame encryption algorithms used in Wi-Fi networks depending upon the type of security configured for example WEP secured WiFi network uses WEP encryption technique while WPA and WPA2 secured WiFi network use TKIP and CCMP respectively.

Can we accurately identify the encryption type just by analyzing the information present in the wireless data frame encryption header? And the answer is Yes.  How? Let’s first take a close look of encrypted data frames and see how it appears in the air.

1.    WEP Encrypted Data Frame Format

Figure 3: WEP Frame Format

WEP encrypted data frames contain only 4 bytes of encryption header. First three bytes are Initialization Vector (IV) which is used in the WEP encryption/decryption process.  Two most significant bits of the fourth byte are used to indicate the encryption key number to be used in the data frame encryption/decryption. Least significant six bits are always kept zero. 

2.   TKIP Encrypted Data Frame Format

Figure 4: TKIP Frame Format

TKIP encrypted data frame contains eight bytes of encryption header. Third and first bytes along with the last four bytes of the header are used in the TKIP encryption/decryption process.  Second byte is called WEPSeed. WEPSeed is not used in TKIP encryption but it is set to (TSC1 | 0x20 ) & 0x7F.

Three most significant bits of the fourth byte are used to indicate the key number and the presence of extra four bytes in the encryption header. Least significant three bits are always kept zero.

3.   CCMP Encrypted Data Frame Format

Figure 5: CCMP Frame Format

CCMP encrypted data frame contains eight bytes of encryption header (shown as CCM header in Figure 4). First and second bytes along with the last four bytes of the header are used in the CCMP encryption/decryption process.  Third byte is reserved and always kept as zero.

Three most significant bits of the fourth byte are used to indicate the key ID and presence of extra four bytes in the CCMP header. Least significant three bits are always kept zero.

Now one can easily identify WEP encrypted data frames as it contains only four bytes of encryption header and six least significant bits of the fourth byte are always zero while TKIP and CCMP encrypted data frames have only five least significant bits of the fourth byte as zero.

Distinguishing between a TKIP encrypted data frame and a CCMP encrypted data frame is bit tricky. We can make use of the difference in first three bytes of encryption header of TKIP and CCMP.

Test1: All TKIP encrypted data frames should have WEPSeed byte (2nd byte of eight bytes encryption header) set to (TSC1 | 0x20) & 0x7F.

Test2: All CCMP encrypted data frames should have third byte of eight bytes CCMP header set to zero.

Let's examine the packet trace in the light of above two tests. Let's assume that selected data frame shown in Figure 2 is correctly identified by Wireshark as TKIP encrypted data frame. So, TSC1 is 0x91, WEPSeed is 0xAB and TSC0 is 0x00. According to Test 1,

WEPSeed = (TSC1 | 0x20) & 0x7F

              = (0x91 | 0x20) & 0x7F
              = 0xB1 & 0x7F
              = 0x31

But the actual WEPSeed present in the data frame is 0xAB.

Hence the condition to be a TKIP encrypted data frame is not satisfied by the selected frame shown in Figure 2.

According to Test 2, CCMP encrypted data frames have third byte zero. Third byte of the selected frame in Figure 2 is actually 0 which confirms that it is CCMP encrypted data frame.

So we have confirmed that frame shown in Figure 2 is not TKIP encrypted but CCMP encrypted data frame and there is some problem with the Wireshark dissector.

Few CCMP encrypted data frames may have encryption header such that third byte is zero but second byte is equivalent to (First Byte | 0x20) & 0x7F. Under these conditions it would be difficult to find out encryption type just by seeing encrypted data frames.

It would be difficult to build a perfect detector but few other conditions can be taken into account in order to predict encryption type. For example in TKIP encrypted data frames, third byte of the encryption header is LSB of Transmit Sequence Counter (TSC) while in CCMP encrypted data frames, first byte of the encryption header is LSB of Packet Number (PN). This means in two consecutive transmitted frames, third byte will increment if the frame is TKIP encrypted else first byte will increment if the frame is CCMP encrypted.

Though, the difficulty of building perfect Wireshark detector to detect encryption type of data frame can be understood, why the designers of the standard chose to assign different name and meaning to individual octet of encryption header is vague.

If you know any reasons of the dissimilarity of TKIP and CCMP encryption header, kindly do share with us.