In this second in a series, explore Wired Equivalent Privacy and Extensive Authentication Protocol.
, I covered the 802.11 wireless standard and the various options
available for wireless networking.
This time, let’s look at the principles of securing wireless network communications
using Wired Equivalent Privacy (WEP) as laid out in the original 802.11
standard and how the 802.1x standard augments WEP with Extensible Authentication
Protocol (EAP) and secure key exchange using Transport Layer Security
Wireless network adapters have similar privacy issues as their mobile
phone cousins. The spread-spectrum technique used to smear a digital signal
over several channels is well documented, making the reconstruction of
a data stream simply an engineering exercise. Protecting the contents
of the data stream requires some form of encryption. The WEP authentication
mechanism in the 802.11 standard defines a method for exchanging keys
between wireless stations and access points. Once these keys have been
exchanged, they’re used as cipher keys for RC4 streaming encryption.
RC4 uses the exclusive OR or XOR function, in combination with a cipher
key, to encrypt a stream of data. Here’s a truth table for the XOR function:
The contents of any column in the table can be obtained simply by doing
an XOR on the other two columns, making XOR an extremely fast symmetric
key algorithm, well-suited for handling fast data streams. The cipher
key is changed for each frame by feeding the key used in the last frame
into the key production algorithm to produce a new key, a technique called
The RC4 cipher key used in WEP is a combination of a static element and a dynamic element.
The static element, called the secret key, was originally defined in 802.11 as a 40-bit alphanumeric value (10 hex or
5 ASCII characters). In addition, with the relaxation in export restrictions, vendors now typically support a 104-bit value
(26 hex or 13 ASCII characters). The wireless stations and their access point share the same secret key.
The dynamic element, called the Initialization Vector (IV), is a 24-bit alphanumeric value. A new and unique IV is created for each WEP session. The 24-bit IV is concatenated with the 40- or 104-bit static WEP key to yield either a 64- or 128-bit seed value that is then converted into a cipher key by a pseudorandom number generator.
Most wireless vendors offer a confusing mix of “40-bit and 128-bit encryption”
because putting “40-bit and 104-bit encryption” on the box would make
their products appear less secure than the product from a less scrupulous
competitor. Figure 1 shows a typical secret key configuration window.
|Figure 1. A typical WEP secret key configuration.
(Click image to view larger version.)
Here’s how access points and wireless stations use the WEP cipher elements:
When a station first associates with an access point, the access point
notifies the station that WEP is required for authentication. The station
generates a 24-bit IV, concatenates its copy of the secret key and feeds
the result into a pseudorandom number generator to produce a cipher key.
The station then uses RC4 to XOR the cipher key with the data frame to
produce an encrypted frame that is sent, along with the IV, to the access
The access point extracts the IV from the frame and uses it to create
a copy of the same cipher key used by the station. The access point then
decrypts the data sent by the station. If the decrypted contents match
the original contents, based on a 32-bit CRC called an Integrity Check
Value (ICV) placed in the data by the client, the access point opens a
port for the station. In the subsequent data stream, the station and access
point increments the IV by one for each data frame to produce a series
of cipher keys.
The essential problem with WEP is the small IV. With only 24 bits available,
the total possible population of cipher keys is exhausted quickly in a
session. This means that a cipher key is likely to be reused. As soon
as a cipher key is repeated, an attacker can use a simple formula to determine
the plain text in the encrypted packets. From there, the shared key and
IV can be reverse-calculated and the data stream laid bare.
In addition, the CRC algorithm used to produce the ICV is well known,
making it relatively straightforward for an attacker to change the content
of an encrypted frame, then manipulate the ICV to hide the changes. A
variety of tools can exploit these WEP vulnerabilities.
802.1x Port-Based Security
Once the weaknesses in WEP became clear, the industry set to work to produce
an improved method for protecting authentication transactions and securely
exchanging WEP keys. The result was IEEE standard 802.1x, Port-Based Network
The 802.1x protocol augments the standard WEP transaction in two ways. First, it improves the initial authentication by replacing the shared key transaction with a version of the EAP documented in RFC 2284. Second, it protects the WEP key exchange mechanism by using TLS. Let’s start with a look at the EAP over LAN (EAPOL) mechanism defined in 802.1x.
Figure 2 shows a standard EAP transaction, in which a client, called
a peer, negotiates an authentication protocol with a network access device,
called an authenticator. When the peer requests to connect, the authenticator
first sends an EAP-Request/Identity packet. The client responds with its
name and a flag indicating that it’s ready to start an EAP transaction.
The authenticator then sends an EAP Request containing the required authentication
type. (The original EAP RFC defined MD5-Challenge, One-Time Password and
Generic Token Card as authentication types. Many others are now in use.)
The peer responds with the required credentials. The authenticator validates
the credentials then sends an EAP Success message.
|Figure 2. The process through which a wireless
station authenticates to the network.
Authenticating Through RADIUS
Figure 3 shows how the EAPOL mechanism defined by 802.1x modifies the
basic EAP transaction by introducing a third party called a Remote Access
Dial-Up Services (RADIUS) server. The network access point (which can
be a wireless access point, switch, remote access server, and so on) is
the EAP authenticator. The client (a wireless station, in our case) is
called a supplicant. The RADIUS server is called an authentication server.
See RFC 2869 for details
on RADIUS. Here is a typical transaction (the terminology is slightly
different from standard EAP):
1. The wireless station (supplicant) sends a standard 802.11 authentication request to the access point (authenticator).
2. The access point responds with an EAP Request/Identity.
3. The station replies with an EAP Response/Identity that the AP then repackages into a RADIUS Access Request and forwards to a RADIUS server. From this point forward, the access point simply acts as a go-between and can be ignored.
4. The RADIUS server sends the station a RADIUS Access Challenge, essentially a demand for credentials.
5. The station replies with the requested credentials.
6. The RADIUS server validates the credentials and, if they pass muster, returns a RADIUS Access-Accept.
7. The AP repackages this into an EAP Success message that it forwards
to the station. It also acknowledges the RADIUS Access-Accept by placing
the station’s port into an Authenticated status. The station can now begin
communicating with the access point.
|Figure 3. Using a RADIUS server introduces a
new authentication element.
TLS and 802.1x
EAP protects the initial wireless authentication. The next vulnerable
portion of the transaction, the WEP key exchange, is protected using TLS.
The authentication phase of a standard TLS transaction is designed to
exchange a unique cipher key for use in encrypting subsequent data transfers.
As we’ll see, TLS can generate cipher keys of any length, making it ideal
for creating truly random WEP keys. To understand how the next generation
of wireless access points will protect your data, it’s important to know
how TLS authentication operates.
TLS authentication uses public key certificates to validate the identity
of a client and a server. The principals validate each other’s certificates
by comparing the digital signature of the certificate’s issuing authority
to a copy of the certificate issued to the Certification Authority (CA).
Figure 4 shows an example of such a certificate.
|Figure 4. Certificate used in the Transport Layer
Security authentication process. (Click image to view larger version.)
Inside the certificate is the public key of the issuing CA and a chain of CAs that extends right up to the root CA. Every certificate is digitally signed using the private key issued to the issuing CA. When a TLS server sends its certificate to a client, the client validates the certificate by decrypting the digital signature using the public key of the issuing CA. This means the client must have a copy of the issuing CA’s certificate.
The same is true in reverse if the TLS server needs to verify the identity of the client. As you might expect, given the potential for man-in-the-middle attacks in wireless communications, it’s highly desirable to use mutual authentication in wireless deployments of 802.1x. Here lies the rub. To achieve mutual authentication using certificates, the clients and the RADIUS servers must use certificates issued by trusted CAs. Trusted, in this case, means that each machine must have a valid copy of the root CA certificate and any subordinate issuing CA certificates.
Microsoft preloads root CA certificates from a variety of vendors into Windows, but certificates from these third parties don’t come cheap. Prices vary, but you can expect to pay $150 to $300 for a computer certificate and to pay again for each renewal. To avoid this cost, you can deploy your own CAs using Windows servers, but you must arrange to get a copy of the root CA certificate to the clients and RADIUS servers. Next month, we’ll see how to avoid the pain of distributing certificates to every user and computer, but this may require upgrading your access points and wireless adapters.
Master Secret Generation
TLS uses a PseudoRandom Function (PRF) that can generate all manner of
secret keys, including WEP keys. The PRF is a hashing mechanism. A hash
is a fixed-length value derived from a variable-length input in such a
way that the input can’t be deduced from the output, similar to the operation
of inexpensive Chinese restaurants.
The PRF uses two hashing algorithms, MD5 and SHA-1. The input is first divided in half, with one half hashed with MD5 and the other hashed with SHA-1. The results are then XOR’d together to produce a cipher key. If the output is shorter than the required key, the process is repeated again and again with the output of one cycle becoming the input to the next.
To get a unique output from the PRF, the initial inputs must be unique. TLS uses something called a “master secret” as a unique PRF input. The master secret isn’t actually exchanged between the client and server. Instead, the two principals exchange these elements:
A 28-byte random number generated by the client.
A 28-byte random number generated by the server.
A 46-byte pre-master secret generated by the client and delivered to the
server in encrypted form.
The two 28-byte random numbers act as salt to prevent pre-calculating the PRF results and building an attack dictionary. (A “salt value” is defined by Microsoft’s Security Glossary as, “random data that is sometimes included as part of a session key.” The lack of salt in the generation of NTLM password hashes is the reason it’s so simple to mount a dictionary attack on Windows servers.)
To protect the pre-master secret, the client encrypts it with the server’s public key. It obtains this public key from the server via a certificate exchange. The server uses the associated private key to decrypt the pre-master secret. (Strictly speaking, the transaction could use Diffie-Hellman or some other method for generating a shared pre-master secret, but most TLS implementations use RSA certificates.)
Armed with identical copies of the two salt values and the pre-master secret, the client and the server now use the PRF to generate identical copies of a 48-byte master secret. The pre-master secret is discarded once the master secret has been generated.
The master secret isn’t actually a cipher key, though. It just forms one of the inputs into the PRF, which then generates a cipher key. These inputs are:
The master secret.
The fixed text phrase “Key Expansion.”
The 28-byte salt value generated by the client.
The 28-byte salt value generated by the server.
The PRF is capable of generating cipher material of any length. If the
principals (wireless station and access point) negotiate 40-bit encryption,
the PRF generates five bytes of cipher material. For 128-bit encryption,
the PRF generates 16 bytes of cipher material.
a suite of protocols to identify entities and protect
data streams. These protocols are layered, so that a
high-level protocol can make use of a more fundamental
protocol. One of the fundamental TLS protocols is the
Record protocol. This protocol defines how to exchange
information about the TLS participants. 802.1x implementations
such as EAP-TLS use the TLS Handshake protocol, which
is layered on top of the TLS Record protocol. You’ll
see referenced to both protocols in a network trace.
The TLS Handshake protocol is used to exchange the
Client and server identity
Client and server certificates
Client and server cipher keys
The first step in the handshake is a TLS Client_Hello.
When a client wants to connect to a TLS server, it
sends a TLS Client_Hello message (see Figure a). This
message contains the following information:
SSL version (either 3.0 or 3.1)
Session ID (set to NULL in first handshake)
Timestamp (used to prevent replay attacks)
Cipher Suite list (each of the encryption algorithms
supported by the client)
If the client wants to use compression and the compression
A 28-byte random number called a premaster secret (used
a little later on in the handshake to create the TLS
|Figure a. The TLS Client_Hello
message. (Click image to view larger version.)
The server that receives the hello responds with
a TLS Server_Hello message (see Figure b) and a TLS
Certificate message that contain the following information:
SSL version supported by the server
Timestamp (used to prevent replay attacks)
Session ID (used to permit quick reauthentications in
Cipher Suite selection (chosen from list supplied by
client. In the example, the server selected RSA's RC4
streaming encryption with a 128-bit cipher key derived
from an MD5 hash)
Compress method (chosen from list supplied by client)
Random number (used to salt any secret keys generated
by TLS to support the selected cipher suite algorithm—salt
prevents precomputational attacks.)
Public key certificate for the server (as you can see
from the screen shot, the certificate contains the name
of the server and the clear-text portion of the certificate
along with the public key).
|Figure b. The TLS Server_Hello
and TLS Certificate messages. (Click image to view
TLS Client Key Exchange, Change Cipher Spec and
Now that we know how the client and server generate
cipher keys using shared random numbers and premaster
secrets, let's see how that information is exchanged.
As a result of the initial handshake, the client now
has a copy of the server's public key inside a public
key certificate. The client validates this certificate
by comparing the public key of the Certification Authority
that issued the TLS server's certificate with the public
key used to digitally sign the TLS server's certificate.
If the certificate is valid, the client generates a
46-byte premaster secret and encrypts it with the server's
public key obtained from the certificate.
In this example (see Figure c), the client sends three
different TLS messages in the same frame:
Client Key Exchange (contains the premaster secret)
Change Cipher Spec
Client Finished (always sent after a Change Cipher Spec
- note that Ethereal designates a "Finished Message"
as "Encrypted Handshake Message")
|Figure c. TLS Client Key Exchange,
Change Cipher Spec, and Client Finish. (Click image
to view larger version.)
TLS Change Cipher Spec and Server Finish
At this point, the server must acknowledge the client's
Change Cipher Spec with a Change Cipher Spec message
if its own followed by a Server Finish message.
With this handshake completed, the client and server
are now free to exchange data using the TLS Record messages
set aside for data transfers. The data will be encrypted
using the protocol in the Change Cipher Spec message
and the cipher keys generated from the master secret
created from the premaster secret delivered by the client
to the server.
Into the Air at Last
At this point, you've been introduced to each member of the cast
of characters required to set up a secure wireless network. Next month,
I'll address how to set up the various 802.1x configurations necessary
to protect a wireless deployment.