Encryption Protocols
With the changes in 802.11i, the 802.11 standard has three encryption protocols: WEP, TKIP, and CCMP. These protocols serve multiple purposes. They primarily are used for confidentiality but also include message integrity. TKIP and CCMP also include replay protection. WEP does not provide robust message integrity or replay protection.
WEP
Wired Equivalent Privacy (WEP) is an algorithm that was specified in the original IEEE 802.11 specification. It had three main design goals:
-
To prevent disclosure of packets in transit
-
To prevent modification of packets in transit
-
To provide access control for use of the network
The net effect of these mechanisms was supposed to make the wireless medium as secure as wired Ethernet, hence the term "Wired Equivalent Privacy." The designers accepted the fact that there were potential flaws, but they thought they had made attacks as difficult as physically getting onto the wired network. It turns out they were wrong, and attackers have written tools to make attacking WEP easy.
WEP Key and WEP SeedThe WEP key is the 40- or 104-bit key that is used as the base key for each packet. When combined with the 24-bit initialization vector, it is known as the WEP seed. WEP seeds are 64 or 128 bits. Many manufacturers refer to the 104-bit WEP keys as 128-bit keys for this reason. Misleading as this is, it has become part of the industry terminology. |
WEP uses the RC4 algorithm from RSA Security to prevent disclosure of packets. However, RC4 is a stream cipher and is not supposed to be reused with the same key. Therefore, the designers added the initialization vector (IV), which is a value that changes for each packet. The IV is concatenated with the WEP key to form something called the WEP seed. The WEP seed is actually used as the RC4 key, which allows a fresh RC4 key to be used for every packet. However, the designers should have required the IV to be unique and nonrepeating for every packet. Failure to prevent repeats means that an attacker can replay packets or choose a convenient IV for an attack. Inadvertent IV collisions are possible, as are attacks on the RC4 keystream. These attacks are documented in Chapter 6. For the recipient to successfully decrypt the packet, he has to know what the IV is, so the IV is transmitted in the clear.
To prevent modification of packets in transit, the designers used the integrity check vector (ICV). The ICV is a four-octet linear checksum calculated over the packet's plaintext payload and included in the encrypted payload. It uses the 32-bit cyclic redundancy check (CRC-32) algorithm. The idea of the ICV is that if an attacker modifies a portion of the packet, the checksum will not match. The recipient can then detect the damage.
The ICV should not be confused with the frame check sequence (FCS), which is another 32-bit CRC designed to allow detection of errors in packet transmission. The FCS is attached to the end of the frame before transit. The key difference is that the ICV is encrypted to hide it from attackers. However, CRC-32 was not designed as a data integrity algorithm. Chapter 6 shows how the design choice of a linear checksum (CRC-32) combined with a stream cipher (RC4) was a poor one. Stream ciphers allow the modification of any individual bit without affecting the rest of the message. Linear checksums depend in a predictable way on the contents of the message. Changing any portion of the message results in a predictable change to the checksum. This property allows an attacker to know exactly which bits he needs to modify to keep the ICV correct. He does not have to know what the ICV is, just which bits to flip in the encrypted ICV. Thus, an attacker can modify the message and simply flip the appropriate bits in the encrypted checksum to defeat the integrity protection. Therefore, the ICV failed in its goal.
To achieve the goal of access control, the designers chose a challenge-response mechanism based on knowledge of the WEP key. This is called shared-key authentication, and it is documented in Chapter 5, "WLAN Basic Authentication and Privacy Methods." The idea was that a station needed to prove its knowledge of the WEP key to gain access to the network. Chapter 6 showed that this method not only is flawed, but it also compromises bits of the keystream. Thus, shared-key authentication fails in its goal, too.
RC4
RC4 is the basic encryption algorithm that WEP employs. As mentioned previously, the algorithm is a trade secret of RSA Security that has been leaked to the general public in the form of a compatible (and likely identical) algorithm called Arcfour. This section describes the Arcfour algorithm but refers to it as RC4 to avoid confusing the reader. RC4 is considered a secure algorithm when used according to proper guidelines, including never reusing the same key and not disclosing any portion of the key.
RC4 is a symmetric stream cipher, so it produces a keystream of the same length as the data. The symmetry refers to each party having a copy of the same key, which is used both to encrypt and decrypt the message. In WEP, this keystream is combined with the data using the exclusive OR (XOR) operation to produce the ciphertext. Chapter 5 shows how the key is formed from the 40- or 104-bit WEP key and the 24-bit initialization vector to produce a 64- or 128-bit RC4 key.
RC4 employs an S-box, which is nothing more than an array of values. These values are scrambled inside the array via a series of swapping operations; they form the basis of the pseudorandom output. The two phases in RC4 are the Key Scheduling Algorithm (KSA) and the Pseudorandom Generation Algorithm (PRGA). The purpose of the KSA is to initially scramble the S-box using the RC4 key. The PRGA then generates the bits of the keystream while continuing to scramble the S-box for each bit generated.
In the pseudocode descriptions that follow in Examples 8-1 and 8-2, all lengths are in bytes. The RC4 key is K, which has length L. The S-box is S and has 256 entries, which is the number of entries used by WEP. The generated keystream is as long as the portion of the packet that needs encryption. The swap operation refers to a simple swapping of two values within the S-box. The # symbol indicates that a comment follows.
Example 8-1 describes the RC4 Key Scheduling Algorithm.
Example 8-1. Key Scheduling Algorithm
Key Scheduling Algorithm (Key, Length)
Key: array[Length] of int8
Length: int8 # length of the key
# Fill the S-box with values 0 to 255
for i := 0 to 255
S[i] := i
end for
# Scramble the S-box using the Key
j := 0
for i := 0 to 255
j := ( j + S[i] + Key[i mod Length] ) mod 256
swap (S[i], S[j])
end for
end Key Scheduling Algorithm
Example 8-2 describes the RC4 Pseudorandom Generation Algorithm.
Example 8-2. Pseudorandom Generation Algorithm
Pseudorandom Generation Algorithm (Length)
Length: integer # length of the Keystream needed
Keystream[]: array of int8
i := 0
j := 0
for k := 0 to Length - 1
i := (i + 1) mod 256
j := (j + S[i]) mod 256
swap (S[i], S[j])
# Generate one byte of the keystream
Keystream[k] := S [ (S[i] + S[j] ) mod 256 ]
end for
return Keystream
end Pseudorandom Generation Algorithm
The resulting array returned is the keystream.
Table 8-1 defines the various symbols used in the pseudocode examples in this chapter.
Operator |
Description |
|---|---|
:= |
Assignment |
<< |
Left rotate (bit shift with the leftmost bits being appended from the right) |
>> |
Right rotate (opposite of left rotate) |
MOD |
Modulo division |
XOR |
A bitwise XOR operator |
XSWAP |
Swap octets 3 and 4 with each other and octets 1 and 2 with each other |
+ |
Simple 32-bit addition |
# |
Defines the beginning of a comment |
WEP Encapsulation
Encapsulation is the process of transforming data from one network layer for use by a lower network layer. In the case of the algorithms in this chapter, this involves encryption, integrity check calculation, possible fragmentation, and attachment of headers. Decapsulation is the opposite. It undoes the encapsulation process so that a received packet can be passed up to a higher network layer. It involves processes such as removing headers, decryption, reassembling packets, and verifying integrity checks.
WEP encapsulation is the process of encrypting and constructing the WEP packet. Figure 8-1 illustrates the WEP packet format.
Figure 8-1. WEP Packet Format
Following the MAC header are the three octets of the initialization vector. The next octet (the KeyID octet) uses 2 bits to specify which of the four stored WEP keys was used to encrypt the message. WEP allows for the storage of four different WEP keys to be used to encrypt a packet. Vendors generally implement this as a configuration option and allow the user to specify which WEP key to use at any one time.
Figure 8-2 illustrates the process of encapsulation of the WEP packet.
Figure 8-2. WEP Encapsulation
The basic WEP algorithm is as follows. (You can do some of these steps in parallel, so do not interpret the order strictly.)
First, the initialization vector is chosen. The standard does not specify how to do this. Some vendors choose the IV randomly, whereas others start at 0 and increase it by 1 with each packet transmitted. Ideally, you would want to avoid reusing IVs, which is called an IV collision. The easiest way to do this would be to start at 0 and count upward, with the proviso that you remember the last IV used when the card loses power. Some vendors use this model but start from 0 with each power cycle, resulting in IV reuse every time the card loses power. With card removal and reinsertion or laptop sleep modes, power loss can happen many times a day. An alternative implementation is to use random IVs, which requires a lot of memory to store all the IVs used. That is why vendors do not store them and avoid collisions. Therefore, this implementation might use a larger number space that results in fewer IV collisions, but over time collisions will still happen. (Chapter 6 discussed IV collisions in more detail.)
Next, the IV is appended to the beginning of whichever WEP key is being used to form the WEP seed. The WEP seed, in turn, is used as the key in RC4's Key Scheduling Algorithm to scramble the initial S-box. Then the RC4 Pseudorandom Generation Algorithm is run for as long as needed to produce as many bits of keystream as the data portion of the packet plus four octets.
At the same time, the CRC-32 is calculated over the data to produce a four-octet ICV. This ICV is appended to the packet. Now the data plus ICV is combined with the keystream, via the XOR operation, to produce the ciphertext. The IV and the KeyID Octet are appended to the beginning of the ciphertext. The MAC layer header is attached, and it is ready for transmission.
XORXOR is a bitwise logical operator that has the following properties when used to combine two bits:
One result of this is that a number XORed with itself is 0. This is because each 0 bit in the number combines with another 0, and each 1 combines with another 1. So all bits of the result are 0. Thus, in encryption, a piece of plaintext can be XORed with a key to encrypt it and XORed a second time with the key to remove the key and revert to the original plaintext data. The following algebra illustrates this: Given that: Ciphertext = Data XOR Key We can see that: Ciphertext XOR Key
|
WEP Decapsulation
The process of WEP decapsulation is more or less the opposite of encapsulation. It is illustrated in Figure 8-3.
Figure 8-3. WEP Decapsulation
After the MAC header is stripped off, the IV and KeyID are extracted from the unencrypted header of the packet. The KeyID is used to retrieve the proper WEP key, and the IV is appended to the beginning of the WEP key to form the WEP seed. The WEP seed is used as the RC4 key for decryption. RC4 is run in the same manner as during encapsulation, which produces the identical keystream as the sender used.
When this keystream is XORed with the ciphertext, it extracts the plaintext. From this, the receiver can calculate the ICV over the data and compare it to the ICV in the received message. If they are equal, the recipient assumes the message was unmodified. Otherwise, it assumes modification has occurred and discards the message.
TKIP (802.11i/WPA)
WEP has its flaws, so the 802.11i Task Group developed TKIP and CCMP. TKIP had two main design goals. It not only had to fix the problems with WEP, but it also had to work with legacy hardware. Because many of the WEP encryption algorithms were implemented in hardware, TKIP had to stick with the basic mechanisms of WEP, including the initialization vector, RC4 encryption, and integrity check vector. Although superior encryption schemes existed, the designers had to find a method that would not obsolete the millions of legacy network interface cards (NICs) and access points (APs) already deployed.
Many of the problems in WEP stemmed from the reuse of the RC4 key and from the use of certain weak RC4 keys. The best solution for the encryption portion was to change the base WEP key with every packet.
TKIP consists of three protocols: a cryptographic message integrity algorithm, a key mixing algorithm, and an enhancement to the initialization vector. TKIP protects against capture of the WEP key by generating a different key for each packet. A cryptographic hash prevents modification of packets. TKIP also replaces the flawed IV with a longer packet counter and enforcement of replay protection. In addition, the packet counter is constructed in a manner designed to avoid known weak RC4 keys. Together, these overcome the existing attacks against WEP.
MSDU and MPDUA MAC Service Data Unit (MSDU) is a basic packet of information that is to be transmitted to the other station. The format for transmission is called a MAC Protocol Data Unit (MPDU) and is what is actually transmitted via the 802.11. If an MSDU is large, it might be fragmented into more than one MPDU. At the other end, the MPDUs will be reassembled into an MSDU before being passed further up the stack. A fragmentation threshold is the maximum size that an MSDU can be before it is fragmented. |
Michael MIC (802.11i/WPA)
The first of the TKIP algorithms is the Message Integrity Check (MIC), which prevents message modification. Chapter 6 shows that an attacker can easily modify messages because of the linear nature of the checksum that WEP uses in its ICV. This bit-flipping capability enables other attacks such as the reaction attack, which allows further compromise of the keystream.
The two problems with the ICV are that it depends entirely on information in the message and that it is linear, so it can be recalculated even in an encrypted stream. TKIP uses a cryptographic hash in place of a linear checksum. A hash is a mathematical calculation that uses a chunk of data with the goal of creating as unique a result as possible for each piece of data. A cryptographic hash is one that depends on something the attacker does not know: a key. It is also nonlinear in that an attacker cannot modify parts of the message and predict which parts of the hash will change as a result. Ideally, changing one bit of the message should change about half the bits of the hash.
A hashing algorithm, such as the Secure Hash Algorithm (SHA1), is usually used for cryptographic integrity checks. In the case of 802.11i, the designers felt that SHA1 was too computation-intensive to calculate on legacy hardware, so they agreed on a simpler algorithm called Michael. Like many hash algorithms, Michael is calculated over the length of the packet, but all of the scrambling it does is based on shift operations and XOR additions, which are quick to calculate. Michael uses a key called the Michael key, the derivation of which is covered in the "Pairwise Key Hierarchy" section later in this chapter. The details of Michael are covered in the "Michael Algorithm" section, also later in this chapter.
Michael Countermeasures
The output of a cryptographic hash should be long enough to make it extremely difficult to create a second piece of data that, when run through the hash algorithm, outputs the same result. Thus, without knowing the key, an attacker will have a hard time generating a packet with the correct MIC. He must take a blind guess at the correct bits of the MIC. He is unlikely to succeed.
According to the 802.11i specification, the Michael algorithm "provides only weak protection against active attack." This is a downside of making Michael easier to calculate. Thus, the specification requires additional countermeasures to safeguard against these attacks. The packet replay protections discussed in the "Preventing Replay Attacks" section are part of this defense. In addition, TKIP employs two countermeasures for the Michael algorithm:
-
Logging
-
Disable and deauthenticate
The first countermeasure is a suggestion that Michael failures be logged as an indication of attack. In addition, the ICV is checked before the Michael value is checked to make it harder for an attacker to create packets that will intentionally cause a Michael failure. The second countermeasure states that if two Michael failures occur within one minute, both ends should disable all packet reception and transmission. In addition, the AP should deauthenticate all stations and delete all security associations. This will result in the station having to negotiate new keys. The AP will not allow new key negotiation for 60 seconds. Key negotiation is described later in this chapter in the "Key Management" section. Stations also report MIC failures to their AP, which counts them as active attacks.
Michael Algorithm
Michael is calculated over something called the padded MSDU. This padded MSDU is never transmitted. It is used only as input to Michael. The padded MSDU is the real MSDU plus some extra fields that go into the calculation. The reason for adding these fields is that it protects them against modification when the MIC is checked on the other end. These extra, protected fields include the source and destination MAC addresses, some reserved octets, and a priority octet. A stop octet, with the hexadecimal value 0x5A, is added. Finally, there is a pad of between 4 and 7 zero octets so that the total length of the entity is divisible by four octets. Figure 8-4 illustrates this padded MSDU.
Figure 8-4. Michael Padded MSDU
Michael uses a 64-bit key formatted as two 32-bit words, K[0] and K[1]. The padded MSDU and the key words are passed as input to Michael. The output of Michael is two 32-bit words, which make a 64-bit hash. The pseudocode in Example 8-3 describes the Michael algorithm, using the symbols described earlier in Table 8-1.
Example 8-3. Michael Algorithm
Michael (Key, MSDU) Key: array[2] of int32 MSDU: array [Length] of int32 Length: integer # length of the padded MSDU in 32-bit words left := Key[0]; right := Key[1] for i := 0 to (n-1): left := left XOR MSDU[i] (left, right) := Block (left, right) end for return (left, right) end Michael Block() is defined as: Block (left, right) left, right: int32 right := right XOR (left << 17) left := (left + right) MOD 232 right := right XOR (XSWAP(left)) left := (left + right) MOD 232 right := right XOR (left << 3) left := (left + right) MOD 232 right := right XOR (left >> 2) left := (left + right) MOD 232 return (left, right) end Block
Preventing Replay Attacks
The second TKIP mechanism is the TKIP Sequence Counter (TSC), which is designed to prevent replay attacks. The WEP specification fails to require that implementers use unique IVs, so it is easy for an attacker to replay packets. Furthermore, the reuse of IVs enables an attacker to reuse a keystream after he has cracked it. The lack of replay prevention in WEP is related to the lack of key management in the original specification. Because no key management is specified, a WEP key was designed to be long lived. Therefore, forbidding reuse of an IV would have lead to an eventual exhaustion of available IVs, which is likely why the designers chose not to require it.
TKIP solves these problems with the TSC. The TSC is a 48-bit counter that starts at 0 and increases by 1 for each packet. TSCs must be remembered because they must never repeat for a given key. Each receiver keeps track of the highest value it has received from each MAC address. If it receives a packet that has a TSC value lower than or equal to one it has already received, it assumes it is a rebroadcast and drops it. Thus, packets can only arrive in sequence.
The ICV and MIC also prevent an attacker from changing the TSC and using it to rebroadcast a packet. Because the TSC in the packet is used in the decryption algorithm, it causes the modified packet to decrypt differently. This results in both the ICV and the MIC not matching the packet. Thus, the decapsulation fails, and the packet is dropped. As mentioned already, the ICV is checked first to make it harder for an attacker to intentionally cause MIC failures and a denial of service (DoS).
This mechanism also prevents a similar attack, which the designers recognized. An attacker could attempt a DoS attack, in which he sends or modifies packets so that they have a future value of the TSC. If the receiver were to update his counter to this new value, the sender would have no knowledge of this jump. He would continue to send packets with proper TSC values, which would look like replayed packets. The specification prevents this threat by specifying that the receiver not update his incoming TSC counter until he successfully verifies the MIC for each packet. As mentioned in the preceding paragraph, an attacker will be unable to get either the ICV or the MIC to decrypt correctly, and this attack will fail.
The TSC is broadcast in the clear in a TKIP packet. The six octets of the TSC (referred to as TSC0 through TSC5) are split up for broadcast, as you can see in Figure 8-5.
Figure 8-5. TKIP Packet Format
Two octets of the TSC (TSC0 and TSC1) are transmitted in octets 3 and 1 of the IV field, which is sent unencrypted. The other four octets are transmitted immediately after the KeyID octet and are also sent unencrypted. This allows the receiver to read the TSC in plaintext and apply it to the decryption algorithm. The TSC is reset to 0 when a new key is negotiated. Therefore, although TSCs are reused, they are never reused with the same key, thus avoiding the reuse problems from which WEP suffers.
Key Mixing Algorithm
The third TKIP algorithm is a key mixing algorithm that is designed to protect the Temporal Encryption Key (TEK). The TEK is a temporary key that can be changed using key management algorithms, as described in the section "Key Management" later in this chapter. It serves as the base key for creating unique per-packet keys. The key mixing algorithm starts with the TEK, which is shared by the sender and the recipient of the message. It combines this TEK with the TSC and the Transmitter Address (TA) to create a unique per-packet, 128-bit WEP seed, which it uses with the WEP algorithm. Because the TSC increases with each packet, the WEP seed changes with each packet. This change includes not only the first 24 bits as in legacy WEP but also the 104-bit WEP key portion. Thus, the attacks that rely on gathering a certain number of packets transmitted with the same WEP key are foiled. In addition, the algorithm specifically avoids certain known-to-be-weak RC4 keys.
The algorithm is depicted in Figure 8-6.
Figure 8-6. TKIP Key Mixing Algorithm
Briefly, the key mixing algorithm works as follows:
-
Phase 1? The high-order 32 bits of the TSC are combined with the TA and the first 80 bits of the TEK. This phase of the key mixing is an iteration involving inexpensive addition, XOR, and AND operations, plus an S-box lookup reminiscent of the RC4 algorithm. These were chosen for their ease of computation on low-end devices such as APs. Phase 1 produces an 80-bit value called TKIP mixed Transmit Address and Key (TTAK). Note that the only input of this phase that changes between packets is the TSC. Because it uses the high-order bits, it only changes every 64K packets. Phase 1 can thus be run infrequently and use a stored TTAK to speed up processing. The inclusion of the transmitter's MAC address is important to allow a pair of stations to use the same TEK and TSC values and not repeat RC4 keys.
-
Phase 2? Now the TTAK from phase 1 is combined with the full TEK and the full TSC. This phase again uses inexpensive operations, including addition, XOR, AND, OR, bit-shifting, and an S-box. The output is a 128-bit WEP seed that will be used as the RC4 key in the same manner as traditional WEP. In the phase 2 algorithm, the first 24 bits of the WEP seed are constructed from the TSC in a way that avoids certain classes of weak RC4 keys. The next section describes this construction. In the "TKIP Encapsulation" section later in this chapter, you will see how the per-packet WEP seed is employed in the encryption of the packet.
TKIP Packet Construction
TKIP adds three fields to the standard WEP packet format: the MIC, the Extended IV field, and the Extended IV bit in the KeyID octet.
The six-octet TSC is split into two sections. The least significant two octets, TSC0 and TSC1, are placed in the original IV field in positions 3 and 1, respectively. This swapping is done to avoid known weak keys noted in the Fluhrer-Mantin-Shamir paper. Position 2 is filled with a specially crafted octet ([TSC1 | 0x20] & 0x7f) that is also designed to avoid weak key attacks. (These attacks are described in Chapter 6.) The most significant four octets, TSC2 through TSC5, are placed in a new field called the Extended IV field. This field immediately follows the KeyID octet. In the KeyID octet, an additional flag?the Extended IV bit?is set to 1 if the Extended IV field is in use. This indicates to the receiver to extract the six TSC octets from their various locations. Figure 8-5 illustrates the result of this construction. Note that the effect is that the TSC is transmitted in little-endian order, except for octets 0 and 1, which are swapped (as just mentioned). In WEP, the entire IV was in plaintext so that the recipient could read it to know how to decrypt the packet. Similarly, the entire TSC is transmitted in plaintext so that the recipient can use it for decryption.
TKIP Encapsulation
Now that you have seen the format of the TKIP packet, this section describes the process of constructing the packets. TKIP encapsulation is the process of encrypting, fragmenting, calculating integrity checks for, and building the packet. Figure 8-7 illustrates this process.
Figure 8-7. TKIP Encapsulation
The data to transmit starts as an MSDU. The sender uses the Michael algorithm to calculate the eight-octet MIC over the MSDU and appends it to the MSDU. This process uses the Michael MIC transmit key. If the MSDU plus MIC combination is too large to fit in a single packet, the sender must fragment it. Note that this can split the MIC from the bulk of the MSDU and can even split the MIC across two packets. The result of the fragmentation is one or more MPDUs.
The sender takes each MPDU through the rest of the process. It updates the TSC to get a fresh value and calculates the 128-bit WEP seed using the TKIP key mixing algorithm. In this case, the WEP seed includes the IV, which is calculated (as previously mentioned) from two octets of the TSC. It then performs WEP encryption on the MPDU using the WEP seed. First it calculates a four-octet ICV and appends it to the MPDU. Then it feeds the WEP seed to RC4 and encrypts the MPDU plus ICV to form the ciphertext. Next the sender assembles the packet with the IV, Key ID octet, Extended IV, and ciphertext, as shown in Figure 8-5. The packet is encapsulated in a MAC frame and transmitted.
TKIP Decapsulation
As shown in Figure 8-8, decapsulation is the opposite of encapsulation, with the addition of some integrity checks.
Figure 8-8. TKIP Decapsulation
The recipient must recover the plaintext TSC from the IV and Extended IV fields. It verifies that the TSC is greater than the TSC in the previous valid packet it received. It passes the TSC, the transmitter's MAC address, and the TEK through the TKIP key mixing algorithm to compute the same WEP seed that the sender used. The recipient uses this WEP seed as the key to decrypt the packet via RC4. It now has the MPDU plus ICV. The recipient calculates the ICV over the MPDU and verifies that it matches the received ICV. If not, the recipient discards the packet. Next, if more than one MPDU came from a fragmented MSDU, they must be reassembled. At this stage, the recipient can calculate the MIC over the MSDU and compare it to the received MIC. If verification fails, the recipient registers a MIC failure, discards the packet, and takes appropriate countermeasures. If verification succeeds, the recipient has decrypted and verified the integrity of the MSDU and thus has successfully received the data it contains.
CCMP
The other encryption suite protocol introduced in 802.11i is the Counter Mode/CBC-MAC Protocol (CCMP). CCMP is the heart of the Robust Security Network (RSN) portion of 802.11i. It is a stronger set of algorithms than TKIP and also provides confidentiality, integrity, and replay protection. CCMP is based on the Advanced Encryption Standard (AES), which is the current state-of-the-art encryption algorithm. AES is the result of an international competition to produce a strong encryption algorithm. The U.S. government has accepted it as its standard encryption suite. AES has received wide international scrutiny by cryptographic experts and is currently considered to be very secure. It is expressly not patented; therefore, anyone can use it without royalty payments.
Acronym SoupThe name of CCMP comes from acronyms based on other acronyms, including the following: AES: Advanced Encryption Standard. A standard, strong encryption method. CTR: Counter mode. Another AES mode, typically used for confidentiality. CBC-MAC: Cipher Block Chaining Message Authentication Code. This is one of the modes of AES, used for message integrity. CCM: Short for CTR/CBC-MAC, a mode of AES that combines CTR and CBC-MAC. This mode achieves both confidentiality and integrity. CCMP: CCM Protocol, or Counter Mode/CBC-MAC Protocol. The security algorithm in 802.11i that uses CCM. |
AES has several modes, and CCMP gets its name from their names. CCMP uses the Counter mode for confidentiality and the CBC-MAC mode for integrity. AES also allows for a choice of key and block lengths. CCMP chooses 128 bits for each of these. CCMP chooses an eight-octet MIC and a two-octet length field for use with CCM.
CCMP uses a 48-bit packet number (PN), which is similar to the TSC that TKIP uses. The MPDU is similar to the one that TKIP uses. Figure 8-9 illustrates the MPDU format.
Figure 8-9. CCMP Packet (MPDU) Format
The length of the CCMP header is eight octets, which is four octets longer than the WEP IV/KeyID header. Like TKIP, it uses a "1" in the Extended IV bit to indicate that there are four extra unencrypted octets in the header. The CCMP header breaks the PN into two parts and puts the two least significant octets at the beginning of the header. It then pads with a reserved octet of zeros. The KeyID octet contains the Extended IV bit and the two KeyID bits. Finally, it follows this with the four most significant octets of the PN. Thus, the PN is transmitted in the clear, in little-endian order, and in two sections. The header is followed by the encrypted section, which contains the data and MIC. The source of these is described in the "CCM Algorithm" section later in this chapter.
CCMP Encapsulation
CCMP encapsulation is the process of encrypting data and wrapping it with appropriate headers for transmission. CCMP encapsulation provides confidentiality, integrity, and replay prevention.
Confidentiality
CCM encryption ensures the confidentiality of data. The block cipher encryption process prevents anyone without the key from reading the message that is in transit. The strength of the AES CTR mode and the protection of the key are the guarantees of this confidentiality.
Integrity
CCM encryption includes the calculation of a Message Integrity Check (MIC) that ensures the integrity of data. This includes protection from replay attacks. CCMP uses a different algorithm than TKIP does: the AES CBC-MAC mode. The MIC is calculated over the data plus some portions of the MAC header, called the Additional Authentication Data (AAD). Although these portions are not encrypted, their inclusion in the integrity check prevents their modification in transit. The AAD includes the entire MAC header except portions that could be changed during retransmission. Thus, it excludes the Duration field and masks to 0 or 1 certain bits of the Frame Control and Sequence Control fields. The protected portions include some Frame Control bits, some Sequence Control bits, QoS control, and the MAC addresses. The AAD contents are illustrated in Figure 8-10.
Figure 8-10. CCMP Additional Authentication Data Construction
The bits of the Frame Control and Sequence Control fields that are labeled with 0 are the ones zeroed out in the AAD.
Replay Prevention
CCMP employs an incrementing packet counter, called the PN, to prevent packet replay. Along with the destination address (Address 2 from the MAC header) and the Priority field from the MAC header, the PN is part of a nonce. This nonce is included in the CCM encryption algorithm, and it helps ensure that the inputs to CCM are different with every packet. Reuse of a PN with the same Temporal Key would compromise the security of the CCM algorithm.
Encapsulation Process
Figure 8-11 illustrates the CCMP encapsulation process.
Figure 8-11. CCMP Encapsulation
In this figure, you can see how all these processes described previously are put together. The MAC header information is used to build the AAD. Information from the MAC header and the PN are used to build the nonce. The Temporal Key, the MPDU plaintext data payload, the nonce, and the AAD are the inputs to the CCM algorithm. The outputs are the encrypted data and the encrypted MIC. The sender then constructs the CCMP header from the PN and attaches it to the encrypted data plus MIC. The sender appends the MAC to the front of the packet, and it is ready for transmission.
CCMP Decapsulation
CCMP decapsulation is essentially the opposite of encapsulation, as illustrated in Figure 8-12.
Figure 8-12. CCMP Decapsulation
The recipient can extract the PN from the CCMP header and the MAC header from the packet. It can verify that the PN has indeed increased and that this is not a replayed packet. It can then calculate the nonce and the AAD. It already has the same Temporal Key that the sender used. From these, it uses the CCM algorithm to decrypt the encrypted data and MIC. It can then recalculate the MIC using the decrypted data and the AAD it has calculated. If they match the MIC from the decryption, the packet and the MAC header have not been modified. It can now be assured that the packet is intact and has arrived securely.
CCM Algorithm
The details of the CCM algorithm are quite complex and are beyond the scope of this book. But it is worth describing the basic concepts to give a feel of the algorithm and how it differs from WEP and TKIP. Chapter 2, "Basic Security Mechanics and Mechanisms," introduced some of the basic concepts of cryptography that are mentioned in this section.
AES is a block cipher, which means it takes a chunk of data and returns a chunk of encrypted data. In CCM, AES takes a 128-bit chunk of data and returns a 128-bit chunk of encrypted data, when provided with a 128-bit key. As previously mentioned, CCM uses two AES modes of operation: Counter mode (CTR) for encryption and Cipher Block Chaining (CBC-MAC) to create the MIC.
CTR is relatively simple. The message is broken into blocks of 128 bits. An arbitrary value, called a counter, is encrypted via AES and then XORed with the first block of message to produce the first block of ciphertext. The counter increases by one for each subsequent block of the message, and the encryption is repeated until the whole message is encrypted. The encrypted blocks are concatenated, and you have your ciphertext. This process is illustrated in Figure 8-13.
Figure 8-13. AES Counter Mode
It is important to ensure that identical messages do not look the same when encrypted. If they do, an attacker can gain valuable information if he guesses the nature of the message. CCMP ensures that the counter is different for each packet by using the packet number to start the counter for each packet. Using a different counter each time ensures that the encrypted counter is different each time. This, in turn, ensures that the final ciphertext is different regardless of the contents of the message.
Decryption is the same process. The recipient has to know what the counter value was to start, and both sides use the same algorithm to derive it. The same set of encrypted counters is produced. Because of the properties of XOR, when an encrypted block is XORed with the same encrypted counter a second time, it results in a decrypted message. Thus, both the encryption and decryption processes actually involve using AES to encrypt the counters. This simplifies the implementation and means that the devices only need to implement AES encryption, not AES decryption. This was, in fact, a key motivation of the TGi committee in choosing CTR mode.
Cipher Block Chaining (CBC) is a mode in which each block is encrypted in turn and then fed back into the algorithm. The first block is encrypted first. It is XORed with the second block, and the result is encrypted again. This is XORed with the third block and encrypted again. The process continues until the whole message has been processed. Figure 8-14 illustrates CBC mode.
Figure 8-14. AES CBC-MAC Mode
You can see that information is lost in this process. But the goal is not to obtain something reversible, just to obtain something unique and repeatable. This unique result is the MIC, and it can be re-created on the other end by the recipient to verify that the message has not been modified. Again, this process requires only AES encryption, simplifying implementation.
