Scalable voip mobility intedration and deployment- P18 ppsx

170 Chapter 5
www.newnespress.com
• Outsider Rejection: No wireless device other than a trusted sender can send a message
correctly encrypted.
• Authenticity and Forgery Protection: The recipient can prove who the original composer
of the message is.
• Integrity: The message cannot be modified by a third party without the message being
detected as having been tampered with.
• Replay Protection: A older but valid message cannot be resent by an attacker later, thus
preventing attackers from replaying old transactions.
Some of these properties are contained in how the encryption keys get established or sent
from device to device, and the rest are contained in how the actual encryption or decryption
operates.
5.6.1 Wi-Fi Security Technologies
Let’s start with the earliest security for Wi-Fi. It is useful to read about WEP, the first and
oldest method for Wi-Fi security, to understand the basic terms and concepts for wireless
security in general.
5.6.1.1 WEP
WEP (Wired Equivalent Privacy) was the first attempt to secure 802.11. Unfortunately, the
privacy it provided was neither equivalent to wired nor very good. Its very design does not
protect against replays, meaning that an attacker can record prior valid traffic and replay it
later, getting the network to repeat actions (such as charging credit cards) without detecting
it. Furthermore, WEP uses for encryption RC4, an algorithm that was not designed to be
used in the way WEP uses it, leading to ways of reverse-engineering and cracking the
encryption without the key. Finally, WEP uses a very poor message integrity code.
All of that said, WEP is a good place to look to learn the mechanics of security in 802.11,
as the later and better security additions replaced the broken pieces but did not destroy the
framework.
NOTE: It is the author’s recommendation to not use WEP in existing or new networks,
under any circumstances, because of the known flaws. Please consider the studying of
WEP to be an academic exercise at this point, and do not allow vendors to talk you into

using it.
5.6.1.1.1 Keying
WEP starts off with an encryption key, or a piece of knowledge that is known by the access
point and the client but is sufficiently complicated that outsiders—attackers, that is—
shouldn’t be able to guess it.
Introduction to Wi-Fi 171
www.newnespress.com
There is one and may be two or more WEP keys. These keys are each either 40 bits (WEP-
40) or 104-bits (WEP-104) long, and are usually created usually from text passwords,
although they can be entered directly as hexadecimal numbers. Manually entered keys are
called pre-shared keys (PSK). WEP provides very little signaling to designate that
encryption is in use, and there is no way to denote whether the short or long keys are being
used. If any security, at all, is used in the network, the “Privacy” flag in the network’s
beacons are set. Clients that want to use WEP had to associate to the network and start
sending encrypted traffic. If the keys matched, the network made forward progress and the
user was happy. If the keys did not match, the user would not be able to do much, but
would otherwise not know what the error was. As you can see, this is not an ideal situation,
and is avoided in the modern, post-WEP protocols.
There are some more complicated possibilities, which are not worth going over, except to
note that the origin of the confusing 802.11 term “authentication” for the first phase of a
client’s connection to the network came from an old method of using WEP to verify the key
before association. This security method is completely ignored by post-WEP protocols,
which use a different concept to ensure that clients have the right key. Therefore, the two
Authentication frames are now considered vestigial, and carry no particularly useful
information in them.
5.6.1.1.2 Encryption
The encryption key is not used directly to encrypt each packet. Instead, it is concatenated
with a per-packet number, called the initialization vector (IV), to create the key that RC4
uses to encrypt the data. The initialization vector can be any number. Transmitters would
start at zero, and add one for each frame sent, until it hit the end of the three-byte sequence,

where it would start over at zero again. Why have a per-packet key, when the original key
was supposedly secret? To answer this, let’s look at the encryption algorithm for WEP,
which is based on RC4.
RC4 is a stream cipher, meaning that it is designed to protect a large quantity of flowing,
uninterrupted data, with minimal overhead. It is used, for example, to protect secure web
traffic (HTTPS), because web traffic goes across in a stream of HTML. RC4 is really a
pseudorandom number generator, with cryptographic properties to ensure that the stream of
bits that comes out is hard to reverse-engineer. When given a key, RC4 generates an infinite
number of bits, all appearing to be random. These bits are then matched up, bit-by-bit, to
the incoming plaintext, or not yet encrypted, data. Each bit of the plaintext is added to each
matching bit of the RC4 stream, without carry. This is also known as taking the exclusive or
of two bits, and the logic goes that the resulting “sum” bit is 1 if either of the incoming bits
are 0, and 0 otherwise. The mathematical operation is represented by the ⊕ symbol, and so
the four possibilities for the exclusive or are as follows: 0 ⊕ 0 = 0, 0 ⊕ 1 = 1, 1 ⊕ 0 = 1,
and 1 ⊕ 1 = 0. When applied to the plaintext and RC4 together, the resulting stream looks
172 Chapter 5
www.newnespress.com
as random as the original RC4 stream, but has the real data in it. Only a receiver with the
right key can recreate the RC4 stream, do the same bitwise exclusive or to the encrypted
data, and recover the original data. (The exclusive or operation has the property that any
number that has any other number added twice provides the same number back: n ⊕ d ⊕ d
= n. Therefore, applying the exclusive or of the RC4 stream twice to the original data, once
by the encryption algorithm and once by the decryption algorithm, gets the plaintext data
back.)
So far, so good. However, an attacker can use the properties of the exclusive or to recover
the plaintext in certain cases, as well. If two frames come using the same per-frame key—
meaning the same IV and WEP key—an eavesdropper can just add the two encrypted
frames together. Both frames have the same per-frame key, so they both have the same RC4
stream, causing the exclusive or of the two encrypted frames to cancel out the identical RC4
stream and leave just the exclusive or of the two original, plaintext frames. The exclusive or

of two plaintext frames isn’t terribly different from having the original plaintext: the
attacker can usually guess at the contents of one of the frames and make quick work
discovering the contents of the other.
This isn’t a flaw with RC4 itself, as it is with using any exclusive or cipher—a type of
linear cipher, because ⊕ is really addition modulo 2—as they are vulnerable to bit-by-bit
attacks unless other algorithms are brought in as well.
Okay, so that explains the per-frame keying and the IV, and why it is not a good solution
for security. In summary, replays are allowed, and the IV wraps and key reuse reveals the
original plaintext. Finally, the per-frame key doesn’t include any information about the
sender or receiver. Thus, an attacker can take the encrypted content from one device and
inject it as if it were from another. With that, three of the problems of WEP are exposed.
But the per-frame keying concept in general is sound.
5.6.1.1.3 Integrity
To attempt to provide integrity, WEP also introduces the integrity check value (ICV). This is
a checksum of the decrypted data—CRC-32, specifically—that is appended to the end of the
data and encrypted with it. The idea is that an attacker might want to capture an encrypted
frame, make possibly trivial modifications to it (flipping bits or setting specific bits to 0 or
1), and then send it on. Why would the attacker want to do this? Most active attacks, or
those that involve an attacker sending its own frames, require some sort of iterative process.
The attacker takes a legitimate frame that someone else sends, makes a slight modification,
and sees if that too produces a valid frame. It discovers if the frame was valid by looking
for some sort of feedback—an encrypted frame in the other direction—from the receiver. As
mentioned earlier, RC4 is especially vulnerable to bit flipping, because a flipped bit in the
encrypted data results in the flipping of the same bit in the decrypted data. The ICV is
Introduction to Wi-Fi 173
www.newnespress.com
charged with detecting when the encrypted data has been modified, because the checksum
should hopefully be different for a modified frame, and the frame could be dropped for not
matching its ICV.
As mentioned before, however, WEP did not get this right, either. CRC-32 is not

cryptographically secure. The effect of a bit flip on the data for a CRC is known. An
attacker can flip the appropriate bits in the encrypted data, and know which bits also need to
be flipped in the CRC-32 ICV to arrive at another, valid CRC-32, without knowing what
the original CRC-32 was. Therefore, attackers can make modifications pretty much at will
and get away with it, without needing the key. But again, the concept of a per-frame
message integrity code in general is sound.
5.6.1.1.4 Overall
WEP alters the data packet, then, by appending the ICV, then encrypting the data field, then
prepending the unencrypted IV. Thus, the frame body is replaced with what is in Table 5.15.
Table 5.15: 8.02.11 Frame Body with WeP (Compare with Table 5.2)
IV Key ID Data ICV
3 bytes 1 byte
n−8 bytes
4 bytes
The issues described are not unique to RC4, and really applies to how WEP would use any
linear cipher. There are also some problems with RC4 itself that come out with the way
RC4 is used in WEP, which do not come out in RC4’s other applications. All in all, WEP
used some of the right concepts, but a perfect storm of execution errors undermined WEP’s
effectiveness. Researchers and attackers started publishing what became an avalanche of
writings on the vulnerability of WEP. Wi-Fi was at risk of becoming known as hopelessly
broken, and drastic action was needed. Thus, the industry came together and designed
802.11i.
5.6.1.2 RSNA with 802.11i
802.11i addresses the major problems with WEP. The first problem, the inability to establish
per-connection keys, and the inability to use different encryption algorithms, was fixed by a
better protocol.
On top of that, 802.11i introduced two new encryption and integrity algorithms. Wi-Fi
Protected Access (WPA), version one, was created to quickly work around the problems of
WEP without requiring significant changes to the hardware that devices were built out of.
WPA introduced the Temporal Key Integrity Protocol (TKIP), which sits on top of WEP and

fixes many of the problems of WEP without requiring new hardware. TKIP was designed
174 Chapter 5
www.newnespress.com
intentionally as a transition, or stopgap, protocol, with the hopes that devices would be
quickly retired and replaced with those that supported the permanent solution, the second of
the two algorithms.
Wi-Fi Protected Access version 2 (WPA2), as that permanent solution, required completely
new hardware by not worrying about backwards compatibility. WPA2 uses AES to provide
better security and eliminate the problems of using a linear stream cipher. A better integrity
algorithm ensures that the packet has not been altered, and eliminates some of the denial-of-
service weaknesses that needed to be introduced into TKIP to let it ward off some of the
attacks that can’t be directly stopped.
A word, first, on nomenclature. For those of you in the know, you might know that WPA
has both TKIP and AES modes, 802.11i has slightly different TKIP and AES modes, and
that both were harmonized in WPA2. However, practically, there really is no need to know
that. For the remainder of this chapter, I will use WPA to mean TKIP as defined in WPA,
WPA2 to mean AES as defined in the standard, and 802.11i to mean the framework under
which WPA and WPA2 operate. This is actually industry convention—WPA and TKIP go
hand in hand, and WPA2 and AES go hand in hand—so product documentation will most
likely match with this use of the terms, but when there is doubt, ask your vendors whether
they mean TKIP or AES.
802.11i first introduced the idea of a per-connection key negotiation. Each client that comes
into the network must first associate. For WEP, which has no per-connection key, the client
always used the user-entered WEP key, which is the same for every connection. But 802.11i
introduces an additional step, to allow for a fresh set of per-connection keys every time, yet
still based on the same master key.
Networks may still used preshared keys. These are now bumped up to be 128 bits long. For
WPA or WPA2, this mode of security is known as Personal, because the preshared key
method was intended for home use. Enterprises can also use 802.1X and a RADIUS server
to negotiate a unique key per device. This mode of security is known as Enterprise. For

example, “WPA2 Enterprise” refers to using WPA2 with 802.1X. Either way, the overall
key is called the pairwise master key (PMK). This is the analog to the original WEP key.
Now, when the client associates, it has to run a four-message protocol, known as the
four-way handshake, to determine what should be used as the key for the connection,
known as the PTK (the pairwise temporal key or pairwise transient key). This whole
concept of derived keys is known as a key hierarchy.
The four way handshake is made of unencrypted data frames, with Ethernet type of EAPOL
(0x888E), and show up as the specific type of Extensible Authentication Protocol over LAN
(EAPOL) message known as an EAPOL Key message. These four messages can be seen by
wireless capture programs, and mark the opening of the data link between the client and the
Introduction to Wi-Fi 175
www.newnespress.com
access point. Before the four-way handshake, clients and access points cannot exchange any
data besides EAPOL frames. After the handshake, both sides can use the agreed-upon key
to send data.
Message 1 of the four-way handshake is sent by the access point to the client, and signals
the security settings of the access point (as contained in something called the RSN IE,
shown in Table 5.16). The RSN IE contains the selection of encryption and integrity
algorithms. The message also contains something called a nonce, which is a random number
that the access point constructs (more on this shortly) and which will be mixed in with the
PMK to produce the PTK.
Table 5.16: The security settings in the RSN IE
Element
ID
Length Version Group
Cipher
Suite
Pairwise
Cipher
Suite

Count
Pairwise
Cipher
Suite
List
AKM
Suite
Count
AKM
Suite
List
RSN
Capabilities
PMKID
Count
PMKID
List
1 bytes 1 byte 2 bytes 4 bytes 2 bytes
n bytes
2 bytes
m bytes
2 bytes 2 bytes
p bytes
Message 2 is sent in response, from the client to the access point, and includes the same
information, but from the client: a client RSN IE, and a client nonce. Once the client has
chosen its nonce, it has enough information to produce the PTK on its end. The PTK is
derived from the two nonces, the addresses of the access point and client, and the PMK. At
this point, it might seem like the protocol is done: the client knows enough to construct a
PTK before sending Message 2, and the access point, once it gets the message, can use the
same information to construct its own PTK. If the two devices share the same PMK—the

master key—then they will pick the same PTK, and packets will flow. This is true, but the
protocol needs to do a little bit more work to handle the case where the PMKs do not agree.
To do this, the client “signs” Message 2 with a message integrity code (MIC). The MIC
used is a cryptographic hash based on both the contents of the message and the key (PTK).
Thus, the access point, once it derives its own PTK from its PMK and the nonces, can
check to see whether the client’s sent MIC matches what it would generate using its own
PTK. If they match, then the access point knows that message 2 is not a forgery and the
client has the right key. If they do not match, then the access point drops the message.
If Message 2 is correct, then Message 3 is sent by the access point, and is similar to
Message 1 except that it too is now “signed” by the MIC. This lets the client know that the
access point has the right key: at Message 2, only the access point could detect an attacker,
but not the client. Also, the client can now verify that the access point is using the same
security algorithms as the client—a mismatch would only occur if an attacker is injecting
false RSN IEs into the network to try to get one side or both to negotiate to a weaker
algorithm (say, TKIP) if a stronger algorithm (say, AES) is available. Finally, for WPA2, the
176 Chapter 5
www.newnespress.com
client learns of the multicast key, the group temporal key (GTK), this way, as it is encrypted
with the PTK and sent as the last part of the message.
Message 4 is a response from the client to the access point, and validates that the client got
Message 3 and installed all of the correct keys.
The nonces exist to prove to each side that the other side is not replaying these messages—
that is, that the other side is alive and is not an attacker. Imagine that the access point sends
its nonce. An attacker trying to replay a previous, valid handshake for the same client could
send an old Message 2, but the MIC on that Message 2 can never be correct, because it
would always be based on the access point nonce recorded previously and was used in that
previous handshake, and not the new one that the access point just created. Thus, the access
point always can tell the difference between a client that is really there, and one that is just
replayed from the past. The client can use its nonce to do the same thing. Also, if either side
has the wrong PMK—which would happen with preshared keys if someone typed one of

the keys wrong—the devices can catch it in the four-way handshake and not pretend to have
a working connection.
Overall, the four-way handshake lets the two sides come together on a fresh connection key
every time. The four way handshake is the same, except for some minor details such as
choice of algorithm, for WPA and WPA2.
By the way, keep in mind that the four-way handshake is only designed to provide a new
PTK every time based on the same PMK, to provide a fresh PTK and eliminate the problem
of old or stale keys that WEP has. The four-way handshake is not designed to hide the PTK
from attackers who have the PMK. This is an important point: if an attacker happens to
know the PMK already—such as a preshared key that he or she stole or remembered—then
every PTK ever generated from that PMK, in the past and in the future, can be broken with
minimal effort. This is known as a lack of forward secrecy and is a major security flaw in
preshared key networks.
In other words, you must keep the PMK secret. Do not share preshared keys, ever—even if
you have stopped using that preshared key and moved to a new one long ago. If an attacker
had been recording your past conversations, when the old preshared key was in use, and
someone leaks the preshared key to this attacker, your old conversations are in jeopardy.
This has serious consequences for voice mobility networks, and will be reiterated in Chapter
8 on security for voice mobility.
5.6.1.3 WPA and TKIP
TKIP was designed to run on WEP hardware without slowing the hardware down
significantly. To do this, TKIP is a preprocessing step before WEP encryption. RC4 is still
the encryption algorithm, and the WEP CRC-32 could not be eliminated. However, TKIP
Introduction to Wi-Fi 177
www.newnespress.com
The first change is to expand the IV and key ID fields to eight bytes total (see Table 5.17).
The expanded fields gives a six-byte IV, now called the TKIP sequence counter (TSC). The
goal is to give plenty of room so that the TSC nearly never needs to wrap. Furthermore, if it
does get close to wrapping, the client is required to renegotiate a new PTK. This prevents key
reuse. Finally, the TSC is used to provide the replay protection missing in WEP. The TSC is

required to go up by one for each message. Each side keeps the current TSC that it is sending
with, and the one it last received successfully from the other side. If a frame comes in out of
order—that is, if it is received with an old TSC—the receiver drops it. An attacker can no
longer replay valid but old frames. And, of course, although it can try to invent new frames,
even with higher TSCs, the receiver won’t update the last good TSC unless the frame is
decryptable, and it will not be because the attacker does not know the key.
The second change is to come up with a better way of producing the per-frame key. The
per-frame key for TKIP uses a new algorithm that takes into account not only the now
larger IV and the PTK, but the transmitter’s address as well. This algorithm uses a
cryptographic device known as an S-box to spread out the per-frame key in a more even,
random-looking pattern. This helps avoid the problems with weak RC4 per-frame keys,
which were specific WEP per-frame keys that caused RC4 to leak information. The result of
this algorithm is a brand new per-frame key for each frame, which avoids many of the
problems with WEP.
Unfortunately, the underlying encryption is still WEP, using a linear cipher vulnerable to bit
flipping. To catch more of the bit flips, a new, cryptographically “better” MIC was needed.
WPA uses Michael, a special MIC designed to help with TKIP without requiring excessive
computation. It is not considered to be cryptographically secure in the same sense as is
WPA2, but is considered to be significantly better than CRC-32, and thus can be used to
build secure networks with some caveats. In this case, the designers were aware of this
limitation up front, and designed Michael to be good enough to provide that transition from
WEP to something more secure down the road (which became AES).
The Michael MIC is not just a function of the data of the packet. It also depends on the
sender’s address, the receiver’s address, and the priority of the packet, as well as the PTK.
Michael is designed to avoid the iterative guessing and bit flipping that WEP is vulnerable
to. Furthermore, it is based on the entire frame, and not just individual fragments, and so
Table 5.17: 8.02.11 Fram Body with WPA (Compare with Table 5.15)
Expanded IV Data MIC ICV
8 bytes
n - 8 bytes

8 bytes 4 bytes
adds features into the selection of the per-frame key, and introduces a new MIC to sit
beside the CRC-32 and provide better integrity.
178 Chapter 5
www.newnespress.com
avoids some fragmentation attacks that can be used against WEP. The result of Michael is
the eight-byte MIC, which is placed at the end of the frame before it is sent for WEP
encryption.
Because the designers know that Michael isn’t enough, they also built in a provision for
detecting when an attack is under way. Attackers try to modify frames and submit them,
and see if the modified frames get mistaken as being authentic. Most of the time, they fail,
and these modified frames are not decryptable. With WEP, a nondecryptable frame is
silently dropped, with no harm. However, a frame with a bad MIC should never happen in a
properly functioning system, and is a sign that the network is under attack. To help prevent
these attacks from being successful, WPA adds the concept of countermeasures. If two
frames with bad MICs (but good FCSs, so that we know they are not corrupted by radio
effects) are received in a 60-second interval, the access point kicks all of the clients off and
requires them to renegotiate new keys. This drastic step introduces a painful denial-of-
service vulnerability into TKIP, but is necessary to prevent attackers from getting
information easily. Of course, having countermeasures doesn’t increase the robustness of
the underlying algorithms, but kicking off all of the clients ensures that the attacker has to
start from scratch with a new PTK.
Overall, TKIP was an acceptable bridge from WEP to WPA2. The designers rightfully
recognize that TKIP is itself flawed, and is subject to a few vulnerabilities of its own.
Besides the obvious denial-of-service attacks, TKIP also still allows for attacks that attempt
to guess at certain parts of the particular messages and make some minor, but arbitrary,
alterations to the packets successfully. Although workarounds exist for these types of
attacks, TKIP will never be entirely hassle-free.
Therefore, I recommend that you migrate to WPA2 for every device on the network.
5.6.1.4 WPA2 and AES

WPA2 introduces a new encryption algorithm, using the Advanced Encryption Standard
(AES). This cipher was produced to be used as a standard algorithm wherever encryption is
needed.
AES is a block cipher, unlike RC4. A block cipher takes blocks of messages—fixed chunks
of bytes—and encrypts each block, producing a new block of the same size. These are
nonlinear ciphers, and so the bit-flip attacks are significantly harder. AES was specifically
designed and is believed to be practically impervious to those styles of attacks. With block
ciphers, each block starts off independently, a bit of a downside compared to stream
ciphers. To remove that independence, WPA2 also uses what is called Counter mode, a
simple concept where later blocks are made to depend on previous blocks.
The MIC used is also based on AES, but is used as a cryptographic hash. This use is called
cipher block chaining (CBC), and essentially uses the same concept of making later blocks
Introduction to Wi-Fi 179
www.newnespress.com
Table 5.18 shows the frame body used with WPA2. As with WPA, WPA2 has essentially the
same expanded IV. Because WPA2 isn’t using TKIP, the name has been changed to the
packet number (PN), but serves the same purpose, starting at 0 and counting up. The PN is
used for replay detection, as well as ensuring per-frame keying. The MIC is also eight
bytes, but uses CBC-MAC rather than Michael. With new hardware, the last vestige of
WEP can be dropped, and the old ICV is removed.
Because the WPA2 MIC is considered to be cryptographically strong, the designers of
WPA2 eliminated the countermeasures that WPA has. It is still true that no frame should
come in with an invalid MIC; however, the administrator can be alerted to deal with it in
his own time, as there are not any known exploits that can be successfully mounted against
WPA2 using an invalid MIC to date.
5.6.1.5 Wi-Fi Link Security: Summary
To summarize, 802.11 security is provided by three different grades of technology: the
outdated and broken WEP, the transition-providing WPA, and the secure and modern WPA2.
WPA and WPA2 are both built on the same framework of 802.11i, which provides a rich
protocol for 802.11 clients and access points to communicate and negotiate which over-the-

air encryption and integrity algorithms should be used.
Networks start off with a master key—either a preshared key, entered as text by the user
into the access point and mobile device, or generated in real time by enterprise-grade
authentication systems. This master key is then used to derive a per-connection key, called
the PTK. The PTK is then used to encrypt and provide integrity protection for each frame,
using either TKIP for WPA or AES for WPA2.
It bears repeating that preshared keys, for all grades of 802.11 security, have problems that
cause both security and management headaches. The biggest security headache is that the
privacy of the entire network is based on that PSK being kept private for eternity. If a PSK
is ever found out by an attacker—even if that key has been retired or changed a long time
ago—then the attacker can use that key to decrypt any recordings of traffic that were taken
Table 5.18: 8.02.11 Fram Body with WPA2 (Compare with Table 5.15)
PN = IV
Data MIC
8 bytes
n−8 bytes
8 bytes
depend on earlier ones, but only outputting the last block as the result. This small block
(128 bits) is dependent on every bit of the input, and so works as a signature, or hash.
The overall algorithm used is known as Counter Mode with Cipher Block Chaining-
Message Authentication Code (CCMP).