aes_ccmp

8/13/2019 AES_CCMP

1/16

[ Team LiB ]

Chapter 12. AESCCMPAESCCMP is the strongest security in development for IEEE 802.11i. This chapter looks at whyAES was chosen and at its credentials as an encryption algorithm. Security systems use AES in

conjunction with an operating mode; some of the simpler and more common modes are coveredhere. We then introduce CCMP, the protocol used with IEEE 802.11, and explain how it isimplemented in practice. This chapter shows how CCMP fits into the IEEE 802.11 framework andprovides state-of-the-art security for the most demanding users.

[ Team LiB ] [ Team LiB ]

Introduction

Chapter 11 looked in detail at TKIP, one of the options for implementing encryption and messageauthentication under RSN. TKIP, which is mandatory to implement for WPA, will be widely used forWi-Fi LAN security due to its ability to be used on older WEP cards. However, it is not the defaultmode for IEEE 802.11i. The default mode is based on a block ciphersuite called the AdvancedEncryption Standard or AES . AES-based security can generally be considered as stronger thanTKIP-based security. This is not to say that TKIP is inadequate. In reality, TKIP is extremely strongand quite suitable for commercial applications. So why was an AES-based solution defined? Andwhat does it mean to say that it is more secure? The answers to these questions and a detailedlook at how AESCCMP works are provided in this chapter.

First, let's clarify what we mean when we talk about RSN using AES. AES is not a security protocol;it is a block cipher. In RSN the security protocol built around AES is called Counter ModeCBC MACProtocol, or CCMP. CCMP defines a set of rules that use the AES block cipher to enable theencryption and protection of IEEE 802.11 frames of data. AES is to CCMP what RC4 is to TKIP.

One reason that CCMP is considered stronger than TKIP is that it was designed from the ground upto provide security for IEEE 802.11. The designers took a clean sheet of paper and created CCMPusing the best-known techniques. By contrast, TKIP is a compromise, designed to accommodateexisting WEP hardware and some aspects of TKIP, notably the Michael integrity protocol, are knownto be vulnerable.[ Team LiB ] [ Team LiB ]

Why AES?When the IEEE 802.11 security task group started work in 2000, its goal was to create a solutionthat was really secure in all the ways discussed in the first section of this book. It was known atthat time that WEP was not very secure, although the really devastating attacks on WEP were onlydiscovered later.

One of the important tasks of the group was to select an encryption algorithm for the new securitystandard. The encryption algorithm is the root of security. It takes known data and converts it intorandom-looking ciphertext. By itself, an encryption algorithm is by no means sufficient forimplementing secure communications: An entire security protocol must be defined for that

Page 1 of 16

6/9/2010file://C:\Documents and Settings\deepak\Local Settings\Temp\~hh883F.htm

8/13/2019 AES_CCMP

2/16

8/13/2019 AES_CCMP

3/16

the choice was high confidence that the method is secure, given the amount of review it hasreceived in the NIST selection process. However, there were other less obvious benefits, too.Encryption technology is subject to export control in the United States and other countries. Byusing a method that is well understood by government agencies, applications for export licensesare more easily processed.

The selection of AES for IEEE 802.11i was made before all the trouble with WEP became well

known. The expectation was that AES-based solutions would gradually replace WEP as the newstandard became deployed. It was not expected that existing Wi-Fi LAN adapters would beupgraded to AES. In most cases, this would not be practical because the hardware needed toimplement AES is different from that needed for RC4. However, when the flaws of WEP becameknown, there was a sudden need to upgrade all the existing hardware and this led to the creationand deployment of TKIP. As a result, we now have three potential solutions: WEP, TKIP, and CCMP.There is a lot in common between WPA/TKIP and RSN/CCMPbased systems. Key management, forexample, is almost entirely the same. The biggest differences occur at the low layers where thedata is encrypted and decrypted. We start by looking at the cipher AES, and how it can be appliedto real data.


AES OverviewAES is a block cipher. Using mathematical and logical operations, the method combines a key anda 128-bit block of data (unencrypted) to produce a block of different data (encrypted). For allpractical purposes, it is impossible perform this transform if you don't know the key. AES isreversible (that is, you can convert back to the original data using decryption), which is useful, butnot essential to all security protocols. The encrypted and unencrypted blocks are exactly the samesize. The conversion of a single block of 128 bits of data is all that AES doesbut it does it quiteefficiently and is extremely secure. It is very unlikely that any fundamental weakness will be

discovered in future.

AES is based on the Rijndael algorithm, invented by Joan Daeman and Vincent Rijmen. Thisalgorithm is very well documented, including the algorithm and implementation details ( Daemanand Rijmen, 2000 , 2001 ). The overview in this book provides a flavor of the method and does notattempt to provide any mathematical justification, although it is necessary to look at some of thequirky arithmetic involved.

The Rijndael algorithm allows for a selection of block sizes and key sizes. The choices are 128, 192,or 256 bits for each. When NIST adopted Rijndael for AES, it specified only one block size, 128 bits,but retained the choice of three key lengths. IEEE 802.11i goes one step further and restricts boththe key size and the block length to 128 bits. This simplifies implementation and relieves the users

of having to make yet another choice during installation.

Modes of Operation

You can use AES to encrypt and decrypt a single fixed length block of data. However, in practicereal messages do not occur as fixed-length blocks. Wi-Fi LAN data, for example, is transmitted inframes of various different lengths, typically between 512 to 12,000 bits in each frame. Therefore,to make use of a block cipher like AES, you need to define a way of converting an arbitrary-lengthmessage into a sequence of fixed-length blocks prior to encryption. Similarly, the method has toenable you to reassemble messages from blocks during decryption. The method used to convert

Page 3 of 16


8/13/2019 AES_CCMP

4/16

between messages and blocks is referred to as the block cipher's mode of operation .

There are quite a few different modes that can be used in conjunction with AES. NIST, for example,has a list of 16 different approaches on its Web site and is open for more proposals. The choice ofthe mode is very important because it has implications both for the complexity of implementationand also for security. Bad modes can create security loopholes even though the underlying AESencryption is so strong.

CCMP uses a mode called CCM, which itself is based on counter mode. Before looking at thesemodes, let's consider the issue of message authenticity. AES provides a method for encryptingdata, obscuring the content so it cannot be read by an attacker. However, and just as important,the receiver needs to know that the message is authenticthat it has not been modified. This isusually accomplished by adding a message integrity code (MIC). [1] For efficiency, we want this MICto be computed using the AES encryption algorithm so it makes sense that the operating modeshould define how to provide both encryption and authenticity.

[1] The term "MAC" is widely used in cryptography, but IEEE 802.11i (and other chapters in this book) use the termMIC instead because the acronym MAC is already used.

To understand modes of operation, we start by reviewing one of the most simple and intuitivemodes: Electronic Code Book (ECB). The mode is generally indicated by being placed after theletters "AES" so a system using Electronic Code Book described as AES/ECB.

Electronic Code Book (ECB)

ECB mode ( Menezes et al., 1996 ; Schneier, 1996 ) simply takes a piece off the input message oneblock at a time and encrypts each block sequentially using the same key until no more pieces areleft. This process is shown in Figure 12.1 , which displays the computation for both serial (one blockat a time) and parallel encryption.

Figure 12.1. ECB Operating Mode

Page 4 of 16


8/13/2019 AES_CCMP

5/16

This approach sounds simple, but it has a couple of problems. The most obvious is that themessage may not be an exact multiple of the block size so you have to pad out any partial block atthe end and remember the real length. However, there is also a security problem: If two blockshave the same data, the encrypted result of the two blocks will also be the same, givinginformation to any onlooker.

Consider a message composed of a string of the same letter repeated 64 times, for example,"AAAAAAA". If the AES block size is 128 bits (16 bytes), then using ECB would break down themessage to four blocks, each with a string of 16 A's. After encryption, the four blocks would eachproduce identical ciphertext, informing an onlooker that this message has a repeating pattern.Because of this weakness (and others), practical systems do not use ECB. It is not, for example, onthe list of NIST-recommended modes. Even the strongest block cipher cannot protect againstweaknesses in the mode.

Counter Mode

Counter mode is more complicated that ECB and operates in quite a different way. It does not usethe AES block cipher directly to encrypt the data. Instead, it encrypts the value of an arbitraryvalue called the counter and then XORs the result with the data to produce ciphertext. Thecounter is generally incremented by 1 for each successive block processedhence the name. Thisprocess is shown in Figure 12.2 .

Figure 12.2. Example of Counter Mode

Page 5 of 16


8/13/2019 AES_CCMP

6/16

In this example the message is divided into blocks, and each block is XORed, with the result ofencrypting the counter value using AES. In Figure 12.2 the counter starts at 1 and increments upto 11. In practice, the counter might start at an arbitrary value and might increment by some othervalue or pattern. The important thing is that the receiving party who wants to decrypt the messagemust know the starting value of the counter and the rules for advancing it.

Because the counter changes value for each block, the problem seen in ECB with repeating blocksis avoided. Even if two blocks of data were identical, they would be combined with a differentcounter value to produce different ciphertext. However, as presented, this method would stillencrypt two identical, but separate, messages to the same result. This is why, in practice, thecounter does not start at 1. Typically, it is initialized from a nonce value that changes for eachsuccessive message.

Counter mode has some interesting properties. Decryption is exactly the same process asencryption because XORing the same value twice takes you back to the original value. [2] Thismeans that implementations only need to implement the AES encryption block (and not thedecryption block). The other useful feature, for some applications, is that the encryption can bedone completely in parallel. Because all the counter values are known at the start, you could havea bank of AES encryption devices and encrypt an entire message in a single parallel operation. Thisis not the case for many of the other modes. The last useful property is that there is no problem ifthe message doesn't break into an exact number of blocks. You simply take the last (short) blockand XOR it with the encrypted counter output using only the number of bits you need. Therefore,

the length of the ciphertext can be exactly the same as the length of the input message. Becauseeach block operation depends on the state of the counter from the previous block, counter mode isessentially stream cipher.

[2] This is an example in which the underlying cipher does not need to be reversible.

Counter mode has been used for more than twenty years and is well known and trusted by thecryptographic community. Its simplicity and maturity make it an attractive option for RSN.However, basic counter mode does not provide any message authentication, only encryption.Therefore, for RSN, additional capability must be added.

Counter Mode + CBC MAC : CCM

CCM mode was created especially for use in IEEE 802.11i RSN, but it is applicable to other systemsas well and has been submitted to NIST as a general mode for use with AES. It has also beensubmitted to the IETF for use in IP security. CCM was invented by three of the cryptographersparticipating in the IEEE 802.11i standards group: Doug Whiting, Russ Housley, and NielsFerguson. It builds on top of counter mode.

CCM uses counter mode in conjunction with a message authentication method called cipher blockchaining (CBC). CBC is used to produce a message integrity code (MIC). The MIC is called amessage authentication code by the cryptographic community, leading to the name CBC-MAC.

Page 6 of 16


8/13/2019 AES_CCMP

7/16

CBC-MAC is another technique that has been used for many years and has been standardizedinternationally. For more information, see Bellare et al. (2000) . It is really simple in concept:

1. Take the first block in the message and encrypt it using AES (or any block cipher).

2. XOR the result with the second block and then encrypt the result.

3. XOR the result with the next block and encrypt thatand so on.

The result is a single block (128 bits in our case) that combines all the data in the message. If oneor more bits were to change in the message, the result would be completely different (okay, sothere is a 2 -128 chance it will be the same). CBC-MAC is simple but cannot be parallelized; theencryption operations must be done sequentially. Furthermore, it should be noted that, by itself,CBC-MAC can only be used on messages that are an exact number of blocks. CCMP provides asolution based on padding, as described later; however, the padding method has raised concernsamong some cryptographers.

CCM mode pulls together two well-known approaches, counter mode and CBC-MAC. It adds somefeatures that are very useful for certain applications such as RSN. The features it adds are:

Specification of a nonce so successive messages are separated cryptographically.

Linking together the encryption and authentication (message integrity) under a single key.

Extension of the authentication to cover data that is not to be encrypted.

The last item needs further explanation and is important for RSN. In most existing methods thatperform both encryption and authentication, an assumption is made that the entire message will beencrypted. However, in IEEE 802.11, only part of the message needs to be encrypted. The headerportion of the IEEE 802.11 frame contains the MAC addresses used to deliver the frame as well asother information relevant to operation of the Wi-Fi LAN. These fields must be sent "in the clear" soother wireless devices can operate. Therefore, only the data portion of the frame is encrypted.However, although the header is not encrypted, the receiver would still like assurance that it hasnot been modified. For example, you don't want an attacker to change the source address so youaccidentally reply to him instead of to the original sender. To achieve this, CCM mode allows theencryption to be performed on a subpart of the message that is authenticated by CBC-MAC.

As a general rule, using the same key for two separate cryptographic functions is not wise. Thisrule appears to be broken here because the same key is used for both encryption andauthentication. However, although the same key is used, it is in each case used in conjunction withan initialization vector (IV). The construction of the IV is different for the counter mode and CBC-MAC portions, thus leading, in effect, to two separate keys. The effectiveness of this separation hasbeen shown by cryptographers ( Jonsson, 2002 ).

Offset Codebook Mode (OCB)

OCB mode was invented by Phil Rogaway of the University of California, Davis, following on fromwork done at IBM Research Labs. It is an authenticated encryption scheme, which means itachieves both message encryption and authentication in a single computation. OCB has someadvantages:

OCB is parallelizable so it can be done faster using multiple hardware blocks.

Page 7 of 16


8/13/2019 AES_CCMP

8/16

OCB is very efficient, taking only slightly more than the theoretical minimum encryptionoperations possible.

OCB is provably secure, which means it can be "proved" that it is as secure as the underlyingblock cipher (AES).

Because of its advantages, OCB was the first mode selected by the IEEE 802.11i working groupand was given the name WRAP. However, concern was raised over intellectual property rights. Thestandards group was concerned about mandating a method that might, in the future, result in theneed to make license payments. Therefore, CCMP was adopted as mandatory and OCB waseventually dropped. It is mentioned here because a few vendors have implemented WRAP, and it ispossible you might encounter it as a proprietary mode in some early implementations.

If you want more details of OCB, visit Rogaway's Web site www.cs.ucdavis.edu/~rogaway or readthe conference paper ( Rogaway et al., 2001 ).


How CCMP Is Used in RSNThis section describes how Wi-Fi LAN packets are encrypted using CCMP. The first important pointis that CCMP encrypts data at the MPDU level. The difference between MPDU and MSDU isdiscussed in Chapter 11 ; but to recap, the MPDU corresponds to the frames that actually gettransmitted over the radio link. There is one MPDU for each frame transmitted, and the MPDU itselfmight be the result of fragmenting larger packets passed from a higher layer, called MSDUs.

Steps in Encrypting a Transmission

Figure 12.3 shows the flow of data from MSDU to MPDU and eventually out to the radio link.

Figure 12.3. Flow of Frames Through CCMP

Page 8 of 16


8/13/2019 AES_CCMP

9/16

The data arrives as an MSDU and may be broken into fragments. Each fragment is formed into anMPDU and assigned its own IEEE 802.11 header containing source and destination addresses andother information. At this point, each MPDU is processed by the CCMP algorithm to generate a newencrypted MPDU. Only the data part is encrypted, not the header. However, CCMP does more than

just encrypt portions of the MPDU. It also inserts extra fields, causing the resulting encryptedMPDU to be 16 bytes longer than the original.

An overview of the steps in encrypting an MPDU are shown in Figure 12.4 and described below:

1. We start with an unencrypted MPDU, complete with IEEE 802.11 MAC header. The headerincludes the source and destination address, but the values of some fields will not be knownuntil later and are set to 0 for now.

2. The MAC header is separated from the MPDU and put aside. Information from the header isextracted and used while creating the 8-byte MIC value. At this stage the 8-byte CCMPheader is constructed for later inclusion into the MPDU

3. The MIC value is now computed so as to protect the CCMP header, the data, and parts of theIEEE 802.11 header. Liveness is ensured by the inclusion of a nonce value. The MIC isappended to the data.

4. The combination of data and MIC is encrypted. After encryption the CCMP header isprepended.

5. Finally the MAC header is restored onto the front of the new MPDU and the MPDU is ready tothe queued for transmission. The transmission logic need have no knowledge of the CCMPheader. From here until transmission, only the MAC header will be updated.

Figure 12.4. Steps in Processing an MPDU

Page 9 of 16


8/13/2019 AES_CCMP

10/16

The encrypted MPDUs are placed on a queue prior to transmission. There might be several queueswaiting their turn based on some priority policy. This allows for later extension to accommodatedifferent traffic classes under IEEE 802.11e. Immediately prior to transmission, some of the fieldsof the IEEE 802.11 header are updated to meet transmission rules. Those fields that are subject tosuch changes are called mutable fields and are excluded from the MIC computation.

CCMP Header

The CCMP header must be prepended to the encrypted data and transmitted in the clear (that isunencrypted). The CCMP header has two purposes. First, it provides the 48-bit packet number (PN)that provides replay protection and enables the receiver to derive the value of the nonce that wasused in the encryption. Second, in the case of multicasts, it tells the receiver which group key hasbeen used (see Chapter 10 ). The format of the CCMP header is very similar to that used for theTKIP header. This is intentional to simplify implementation for access points that need to receivetransmissions from a mixed group of TKIP and CCMP mobile devices. The format is shown in Figure12.5 .

Figure 12.5. CCMP Header

Six bytes are used for the 48-bit PN value, 1 byte is reserved, and the remaining byte contains the

Page 10 of 16


8/13/2019 AES_CCMP

11/16

KeyID bits, the function of which is described in Chapter 10 . Note that the bit next to the KeyIDbits is set to a value of 1, corresponding to the Extended IV bit in TKIP. This value indicates thatthe frame format is RSN rather than the earlier WEP format.

Overview of Implementation

Implementation of the CCMP block can be viewed as a single process with inputs and outputs, as

shown in Figure 12.6 .

Figure 12.6. Encryption and Decryption with CCMP

Note that the decryption phase has the same inputs as the encryption phase (except that the inputMPDU is encrypted). This is because the header information, including the CCMP header, istransmitted across the link in the clear and can therefore be extracted by the receiver prior todecryption.

The implementation of CCMP (shown in Figure 12.4 as a "block") must keep a sequence countercalled the packet number (PN), which it increments for each packet processed. This prevents anattacker trying to reuse a packet that has previously been sent. The PN is 48 bits long, largeenough to ensure it never overflows. There will never be two packets sent with the same sequencevalue. Of course if you power down the device and restart, the PN will be reset, but this will be witha different key value and hence does not create a threat.

Implementation of the CCMP encryption block is shown in Figure 12.7 .

Figure 12.7. CCMP Encryption Block

Page 11 of 16


8/13/2019 AES_CCMP

12/16

Note how the computation occurs in two stages: first, the MIC is calculated and appended to theMPDU, and then the entire MPDU (including MIC) is encrypted to produce the result. Let's look inmore detail at each step.

An encrypted MPDU contains two more fields than an unencrypted MPDU. It has the CCMP headerand the MIC value. The MIC field is 8 octets (64 bits). Note that the MIC is only half the size of theAES block but is still long enough to reduce the chance of a successful MIC forgery to less than 1 in10 19 .

The order of fields in the encrypted MPDU is shown in Figure 12.8 .

Figure 12.8. MPDU Encrypted under CCMP (CH = CCMP Header)

Steps in Encrypting an MPDU

Page 12 of 16


8/13/2019 AES_CCMP

13/16

8/13/2019 AES_CCMP

14/16

The other two fields that, with the nonce, create the first block for CBC-MAC are also shown inFigure 12.10 . The flag field has a fixed value of 01011001 and indicates, among other things, thatthe MIC is 64 bits. In other (non-RSN) applications of CCM, the Flags field might be different, butthis does not concern us here. The last field, DLen, indicates the length of the plaintext data.

Once the first block has been prepared, the MIC is computed one block at a time by incorporatingthe authenticated data and then incorporating the plaintext data. One of the characteristics of CBC-MAC is that it works only for an exact number of blocks. If the data doesn't divide into an exactnumber, it must be padded. For the purposes of the MIC computation, CCMP requires that both theauthenticated data and the plaintext data be padded to an exact number of blocks. In IEEE 802.11,it is likely that neither the authenticated data nor the plaintext data will be a suitable length, soeach is padded with zeros to meet this requirement, as shown in Figure 12.8C . The MIC iscomputed across the combination of the special first block, the authenticated data, and theplaintext data, including the zero pad bytes. Note that the pad bytes are only inserted for the MICcomputation and are not actually inserted in the MPDU, as illustrated by Figure 12.8d .

Encrypting the MPDU

Once the MIC has been computed and appended to the plaintext data, we are ready to startencrypting the MPDU. The encryption occurs using counter mode and starting with the dataimmediately following the CCMP header in the template. Note that because of the padding duringthe MIC computation, we are guaranteed that the blocks to be encrypted will be aligned with theblocks included in the MIC computation. The encrypted data replaces the original data for theentire data portion and the MIC value, resulting in a complete encrypted MPDU ready to be queuedfor transmission, as shown in Figure 12.8E . It is not necessary to use padding for the encryptionstage because counter mode allows any excess bits in the last block to be discarded.

An essential step in counter mode is to initialize the counter in a way that avoids ever using thesame start value twice. Therefore the counter is constructed from a nonce in an almost identicalway to that for the MIC. In fact the nonce value used is identical to that of the MIC and includesthe sequence counter, source MAC address, and priority fields. This value is then joined with twofields: Flag and Counter ("Ctr"), as shown in Figure 12.11 .

Figure 12.11. Constructing the Counter for CCMP AES Counter Mode

Page 14 of 16


8/13/2019 AES_CCMP

15/16

The ctr value starts at 1 and counts up as counter mode proceeds. Because the nonce is a uniquevalue and the ctr field is 16 bits long, you are guaranteed to have unique counter values for anymessage with fewer than 65536 blocks. This easily accommodates the largest MPDUs allowed inIEEE 802.11.

Well, almost ready. First we need to put back all the fields in the MAC header that were maskedout for the MIC computation. Although these fields are not used for the MIC, they may still beimportant.

Once the counter is initialized, encryption can proceed as described in the previous section"Counter Mode " in this chapter. Each successive value of the counter is encrypted using the secretkey and XORed with the template data to produce the encrypted data.

Decrypting MPDUs

When the encrypted MPDU is delivered to the receiver, the first job is to get the right key fordecryption. The correct pairwise keys are selected based on the source MAC address in the MACheader. There are a number of steps the receiver must take to extract and check the validity of thereceived data. Decryption is only one step and this process is more generally calleddecapsulation .

The packet number (PN) is sent unencrypted in the CCMP header. The first thing the receiver doesis to read the PN and compare to the last frame received. If the sequence number is lower or equalto the last one, it should be discarded as a replay of an old message. In this case the receiver goesno further with the MPDU.

Assuming the PN matches, the next step is to prepare for decryption using AES/counter mode. Thisrequires the computation of the starting value for the counter, which must match that value usedin encryption. All the information is available in the received frame. The sequence number can becombined with the source MAC address and priority to create the nonce. This is then combined withthe known flag value and the start ctr value (also 1) to create the initial counter. Note there is nosecret here: Any attacker can compute the same value. However, it is of no use unless the secretkey is also known. Decryption proceeds as for encryption. Successive values of the counter areencrypted and XORed with the received MPDU to restore the unencrypted data and the MIC value.

The next stage is to verify that the MIC value is correct. The MIC value is recalculated across thesame data (and padding) as the original MPDU at the sender. The mutable fields in the header aremasked out and the computation performed over the whole MPDU, excluding the MIC. Of course, ifthe data is unaltered from when it was sent, and we have the right secret key, the same result willbe obtained. This can be compared to the MIC value sent with the frame: A match means theframe is valid. A mismatch is most likely evidence of an attack and the frame will be discarded.

Interestingly, with CCMP the process of decryption is almost identical to that for encryption, leading

Page 15 of 16


8/13/2019 AES_CCMP

16/16

to a nice simplification for implementation. Once the MPDU is decoded, the MIC and CCMP headercan be removed, and is the remaining data is passed up for reassembly with other receivedfragments to reform the MSDU. You can see how the CCMP process gives protection againstforgery, eavesdropping, and copy/replay attacks. It is very strong.

As we said at the start of the chapter, the most advanced security protocol is of no use if theunderlying cipher mechanism (in this case, AES) has a flaw. AES has no known flaws that might

compromise security. If you are interested, Appendix A describes how AES works. This appendixincludes some mathematics, which may be unfamiliar. It you are prepared to accept AES as a"black box" that encrypts blocks of data, then feel free to skip the appendix![ Team LiB ] [ Team LiB ]

SummaryA large number of Wi-Fi systems have been deployed based on the RC4 encryption algorithm. Thiswas part of the IEEE 802.11 WEP implementation and has been included in the WPA TKIPspecification to allow firmware upgrades possibly in combination with a driver upgrade. However,when the IEEE 802.11 committee started looking for a new security solution to be built from

scratch, they chose instead the cipher AES on which to build. This chapter has explained why thatdecision was made and how it has been incorporated into the RSN solution.

AES is a cipher that can be used in many ways to create security protocols. This chapter has lookedat the various modes that have been designed to use AES in practical situationsin particular, anew mode called CCM that was invented to support IEEE 802.11 TGi RSN and that is now likely tobe adopted by NIST as one of the standard modes for AES. This mode forms the basis of CCMP, theAES-based protocol for IEEE 802.11i. We have now covered, in this book, all the core protocolsneeded to implement WPA and RSN security. The next chapter looks at how the techniques areapplied to IBSS networks and covers additional mechanisms that enable Wi-Fi systems to identifyand safely select other Wi-Fi systems that support the new security provisions.

[ Team LiB ]

Page 16 of 16