The Temporal key Integrity Protocol (TKIP) was an interim solution developed to fix the key reuse problem of WEP. It later became part of the 802.11i and subsequently part of WPA standards. This meant there were various flavors of TKIP until 802.11i was finalized. One of the first notations about the theory and concepts of TKIP was published in December 20, 2001, by Russ Housley and Doug Whiting, in an article entitled “Temporal Key Hash.” This article described the general principle of TKIP, although it was not enough on which to base a standard. That is where 802.11i came in with a more in-depth creation of TKIP.
TKIP was included in the 802.11i standards for backwards compatibility. The 802.11i standard did not want to use a cipher based RC4, so they chose AES. TKIP was put into 802.11i for the sole reason of helping older devices transition to 802.11i. To do this, 802.11i needed to support a protocol that could easily upgrade WEP to something safe enough to include in 802.11i. One of the main reasons for using TKIP over WEP came from the increased security and increasing number of attacks that were plaguing the WEP protocol. Using TKIP protected against these attacks and reduced the overall risk of operating a wireless network.
The TKIP standard also saw value in the industry because the migration from WEP to TKIP was an easy one. In most cases, moving from WEP to TKIP involved a small firmware change. This meant that no hardware was required to make the change and also that most older, already purchased equipment would be able to upgrade to TKIP.
Another interesting note about TKIP comes from Cisco Systems. Cisco came up with a TKIP solution well before the 802.11i standard defined one. This has led some people to wonder about which version of TKIP is on a certain product. Vendors other than Cisco also created TKIP-based solutions before the standard was ratified. Today, Cisco differentiates its versions of TKIP and the standard one by calling it the Cisco Key Integrity Protocol (CKIP). In Cisco products, one can specify to use TKIP, which is the 802.11i-compliant version, or CKIP, which is the Cisco-created version.
The TKIP encryption portion works in a two-phase process. The first phase generates a session key from a temporal key, TKIP sequence counter (TSC), and the transmitter’s MAC address. The temporal key is made up of a 128-bit value similar to the base WEP key value. The TKIP sequence counter (TSC) is made up of the source address (SA), destination address (DA), priority, and the payload or data. Once this phase is completed, a value called the TKIP-mixed transmit address and key (TTAK) is created. This value is used as a session-based WEP key in the second phase.
In the second phase, the TTAK and the IV are used to produce a key that encrypts the data. This is similar to how WEP is processed. In WEP the first 24 bits of the IV are added in front of the WEP key and then used to create an encryption key that is applied to the data. Then the IV is inserted into the packet header. TKIP extended the IV space, allowing for an extended IV field, which holds an additional 24 bits. In the second phase, the first 24 bits are filled with the first 24 bits of the TTAK. The next 24 bits are filled with the unused portion of the TSC. This is safer than WEP because the key is using a different value, depending on who one is talking to. In WEP, each client or access point creates the same random value. Some products never even created a random value and just incremented the value by one, making it an easy target for hackers.
The basis of TKIP came from the WEP protocol. In the 802.11i standard, TKIP is referred to as a cipher suite enhancing the WEP protocol on pre- RSNA hardware. This is espoused because RC4 is still used as a cipher, although the technique in which it is used has improved greatly.
TKIP Message Integrity Check (MIC)
Similar to TKIP, the Message Integrity Check (MIC) had also many versions before 802.11i defined it as a single standard. Once this was done, MIC became known as Michael although the acronym MIC still remains. Today with 802.11i, ratified MIC is Michael and vice versa. The protocol itself was created to help fight against the many message modification attacks that were prevalent in the WEP protocol. The IEEE 802.11i standard describes the need for MIC in the following quote: “Flaws in the IEEE 802.11 WEP design cause it to fail to meet its goal of protecting data traffic content from casual eavesdroppers. Among the most significant WEP flaws is the lack of a mechanism to defeat message forgeries and other active attacks. To defend against active attacks, TKIP includes a MIC, named Michael.” The MIC was created as a more secure method of handling integrity checking compared to the IVC in WEP.
The MIC is a hash that is calculated on a per-packet basis. This means a single MIC hash could span multiple frames and handle fragmentation. The MIC is also on a per-sender, per-receiver basis. This means that any given conversation has a MIC flowing from sender A to receiver B and a separate MIC flowing from sender B to receiver A.
The MIC is based on seed value, destination MAC, source MAC, priority, and payload. Unlike IC, MIC uses a hashing algorithm to stamp the packet, giving an attacker a much smaller chance to modify a packet and have it still pass the MIC. The seed value is similar to the WEP protocol’s IV. TKIP and MIC use the same IV space, although they have added an additional four octets to it. This was done to make the threat of using the same IV twice in a short time period less likely.
The MIC is also encrypted inside the data portion, which means it is not obtainable through a hacker’s wireless sniffer. To add to this, the TKIP also left the WEP IVC process, which then adds a second, less secure method of integrity checking on the entire frame. To combat message modification attacks, the TKIP and MIC went a step further and introduced the TKIP countermeasures procedures. This is a mechanism designed to protect against modification attacks. It works by having an access point shut down its communications if two MIC failures occur in 60 seconds. In this event, the access point would shut down for 60 seconds. When it comes back up, it would require that all clients trying to reconnect change their keys and undergo a re-keying. Some vendors allow one to define these thresholds, although the MIC standard calls out these values.
To prevent noise from triggering a TKIP countermeasure procedure, the MIC validation process is performed after a number of other validations. The validations performed before the MIC countermeasure validation are the frame check sum (FCS), integrity check sum (ICV), and TKIP sequence counter (TSC). If noise was to interfere with the packet and modify it, one of these other checks would be able to find it first, thus preventing the frame from incrementing the MIC countermeasure counter.