A Field Guide to Wireless LANs for Administrators and Power Users

There are multiple types of "evasive maneuvers" that operators of WLANs can take to help shield their networks from attack. In the era when WEP was all that was available and especially once WEP was known to be approximately the same as no protection at all there were certain configuration techniques that did not rely on encryption, but tried to rely on subterfuge.

Non-Cryptographic Security Schemes

One of the earliest schemes by which some vendors tried to enable "security" is by supporting a feature that became known as "Closed WLANs." Normally, the AP includes the SSID in its Beacon MMPDUs, but a suitably modified AP may be configurable to omit the SSID from its Beacons. In order to join a "closed" WLAN, a STA must be pre-configured with the correct SSID…the AP will not reveal this information on a regular basis in its APs. How does this make anything more secure? In reality, it sounds better than it actually is. It is certainly true that the normal mode of operation of an AP includes the SSID in every Beacon, which does, in fact, enable user-friendly software to provide anyone with a dialog box to the effect of "I can hear the following SSIDs…which would you like to join?"

One would initially think that removing the SSID from the Beacon, and forcing the STA to know the SSID in advance, would be a step in the right direction. However, anyone with an ability to eavesdrop on the WM can learn the SSID by simply watching any legitimate STA associate with the AP. Remember, too, that the AP will still be sending Beacons, at a rate usually about 10 per second, so it is easy for an adversary to learn which MAC address on the WM corresponds to an AP. Probe responses from this MAC address will reveal the SSID that was formerly also included in the Beacon MMPDUs.

Another way to limit access to an AP is to restrict the AP to only accept traffic from a pre-defined set of MAC addresses, effectively creating an access-list of MAC addresses. It is easy, however, for an attacker to observe the WM and see which MAC addresses are successfully accessing the AP, so it will be possible for an attacker to spoof the MAC address of a valid STA and access the AP. The authentication and association procedures may not even be based on any credentials at all. In many WLANs, valid users join the WLAN but are effectively anonymous.

Both "closed" WLANs and "access lists" are perhaps useful to deflect an attacker who is looking for an easy target, but in order to repel a determined attacker, one needs to employ a range of techniques. The basis of all the techniques is user-based authentication, using some form of strong credentials. The authentication is the basis for key exchange, and that is what enables the use of encryption.

Cryptographic Security Schemes

If a protocol designer decides that encryption is the best way to protect frames as they transit the WM, then two ancillary decisions must be made. The means by which users are authenticated to the network (and the network to the users) must be defined, as well as the means by which the data is protected (e.g., encryption) both from the user to the network, and vice versa. The combination of the authentication and encryption algorithms that are used to protect data frames is known as a "ciphersuite." This new terminology has been added during the course of the work that is ongoing within TGi.^[18]

^[18] TGi is defining a new set of security options for IEEE 802.11 WLANs; however, this standard is not yet complete and any references to it within this book will clearly state that it is a work-in-progress. The author will make every effort to try to refer only to aspects of IEEE 802.11i that are unlikely to change, but until it is complete, anything is fair game and might be changed at any time.

End-User Authentication

The protocol designer must define how the user of a STA should prove his or her identity (so that the AP can decide if that user's STA should have access to the WLAN), a process known is "authentication." The simplest authentication scheme is to allow anyone in, without making them present any sort of credentials. The most rigorous scheme is to require that users be identified in a way that uses cryptographically strong techniques to prove that they are whom they claim to be. In fact, the best schemes not only authenticate the user to the network, but also authenticate the network to the user, a result known as "mutual authentication." Strong authentication schemes are almost certain to involve cryptographically protected exchanges, since the user's (and network's) credentials must be kept private so that an eavesdropper cannot listen to the authentication exchange and use those credentials later to impersonate that user (or to impersonate the network to an unwitting user).

In between the two extremes (i.e., no authentication to strong mutual authentication) are varying degrees of authentication strength, with one of the weakest being a simple static configuration of a "key" or set of keys that are used by the two parties to communicate (i.e., using the keys for encryption). The "user authentication" in this case is the simple-minded assumption that if the user has configured the correct key(s) into the STA, then he or she must be a valid user. This is a naïve approach, since there is nothing to confirm the users' identity other than their knowledge of these keys, meaning that anyone who discovers the keys can access the network, impersonate another user's STA, impersonate an AP, and so forth. There may be limited circumstances where a naive scheme like this would be appropriate, but in practice this level of "authentication" is not strong, and is easily spoofed by attackers.

There are other authentication schemes that are stronger than the "I know the key, so I must be a legitimate user" approach, and these may even use cryptographic techniques, without providing for mutual authentication. Such schemes are a step in the right direction, but the exposure to man-in-the-middle attacks is a significant weakness.

User authentication is the means for a STA to gain access to the network, based on the STA's user presenting the proper credentials or demonstrating knowledge of the keys. The user authentication algorithms are only employed when a user's STA is first joining a secure WLAN. This type of authentication happens once per association (at a maximum; the STA may be able to roam to APs other than the one that it originally authenticated to, and have the AP transparently hand off its connection to the next AP in such a way that the security of the user is preserved without the user needing to re-certify himself or herself at every hop). After that, a different form of authentication is used to protect the frames that are sent to and from the user's STA.

Message Authentication

In designing a ciphersuite, one must decide whether any cryptographic "message digest" will be applied to the message before it is encrypted and sent. The message digest is typically a hash function that is computed over certain fields in the frame header, plus the frame data, plus a key that only the sender and receiver know. A message digest serves as an ICV, since finding two sets of input data that have the same digest is computationally infeasible and highly improbable. This digest is used by the receiver to prove to itself that the results of its decryption are valid.

When a ciphersuite contains a message digest component, the message digest carries much of the burden of maintaining the security of the connection. It might appear that an encrypted message alone would be sufficient to ensure that the connection was secure, but the fact is that encrypted messages can be replayed or modified and then replayed. If the message were not protected by a digest, it is possible that it could have been modified in such a way that it can be successfully decrypted, without the attacker needing to know the encryption key. Besides maintaining the security of the system, keyed message digests also provide an essential tool in verifying that the received message was not modified or corrupted.

Message Verification

To a human, verifying that a message is correct upon decryption might seem like an easy test. Imagine that one has a message, such as "The quick brown fox jumped over the lazy dog." If one appends a message digest to the data, such as 0x3478619AB30CF781220AFE0E"^[19], then the receiver can decrypt the data and re-compute the message digest, and know that if the result of its own calculation matches the value in the frame, that the chances are excellent that the frame is exactly what the sender intended for it to receive. In the preceding example, a human could tell that there was a problem if the sentence read "T%d qv0ch b#RUu fiC$hoiM3a avo1 i8R Eli4 Czy#." This is clearly nonsense…a human can tell that this "sentence" is not meaningful, but computers lack the intuition necessary to make such judgments, and moreover, most data is not ASCII human-language data.

^[19] That was a completely made up digest value, only accurate in its length, since 16 octets is the length of output from a popular one-way hash function known as Message Digest 5 (MD-5), which is used in this case for purely expository purposes.

To try to validate decrypted data without a message digest, computers could conceivably determine if the decrypted data consisted of ASCII text, and could even spell-check and/or grammar-check the text to see if it matched a known language. However, as can be seen in this next case, the computer would have no way of knowing whether the message was correct, even if it had no spelling or grammar errors. The following two sentences are equally correct. 1) "Transfer $1200 to account number 16372819." 2) "Transfer $9999 to account number 76293971." The first sentence may have been what the sender intended, but the receiver would have no way to detect a forgery that would redirect a much larger amount of the sender's money to a different account. The forged sentence is syntactically correct, contains no spelling errors, and even has the same number of characters in the sentence. Despite the fact that it is not the message that the sender intended to convey, the receiver has no way of knowing that the message is invalid, and will happily process any directive that it can understand provided that sufficient funds are available in the account from which the money is being transferred.

In the typical case, wherein a frame contains non-ASCII, non-human-language binary data, a receiver needs to have some sort of ICV that it can use to determine if a string of hexadecimal (binary) data was correctly decrypted. Any useful ICV will do its job properly regardless of whether the frame contains binary data or ASCII data. Depending on the level of certainty desired, the integrity check could be anything from a Cyclic Redundancy Check (CRC) code to a cryptographic keyed message digest based on a cryptographically strong one-way keyed hash function, the latter being the strongest known type^[20] of ICV. Again, the validation of the message digest is what enables the receiver to be sure that it has the correct data. Without this check, the receiver would have absolutely no clue that it was being tricked.

^[20] Emerging technologies such as quantum cryptography have been demonstrated in the laboratory, and may someday offer non-mathematical ways to transmit messages securely, and implicitly prove that a message hasn't been tampered with, but practical applications of such technology are not imminent.

In many ciphersuites, the message digest is computed from a keyed hash function, which means that the data to be signed is combined with a secret key, and then the resulting data is fed into a cryptographically strong one-way hash function. The result is a fixed-length output that depends very strongly on the inputs to the function.

One definition of a cryptographically strong hash function is a function that takes an arbitrary amount of input data and distills it to a fixed-length output value, with the additional property that changing just a single bit of the input will change, on average, half of the bits of the computed hash value. The fact that the sender and receiver agree on a secret key, which is used as part of the input to the one-way hash function, enables the receiver to be virtually certain that only the sender (or someone who has compromised the sender's authentication key) could have computed the hash that was appended to the data.

To summarize, a message digest is frequently computed by using a keyed one-way hash function, that can take an arbitrary amount of input data and render it into a fixed-length output (the "hash" value). The most common hash functions in use today are Message Digest 5 (MD-5), which outputs 128 bits of hash, or NIST's Secure Hash Algorithm number 1 (SHA-1), which outputs 160 bits (i.e., 20 octets) of hash value. SHA-1 was defined in the Federal Information Processing Standard (FIPS) publication 180-1, which was standardized on April 17, 1995.

The description of SHA-1 has been carried forward into FIPS publication 180-2, which was approved as a standard on 26 August 2002 and came into force effective February 1, 2003. In addition to SHA-1, FIPS publication 180-2 defines three new hash algorithms that have larger output sizes: SHA-256, SHA-384, and SHA-512. SHA-256 outputs 256 bits (32 octets), SHA-384 outputs 384 bits (48 octets), and SHA-512 outputs 512 bits (64 octets).

Message Encryption

To complete the definition of a ciphersuite, a protocol designer must define what cryptographic encryption algorithms will be used, and exactly what mode of operation must be used (if more than one mode is possible). The complete transformation of the data, including appending the keyed hash result and encrypting all or part of the data and ICV (with a different keys for encryption and authentication), probably including the hash, is known as "encapsulation." Encryption algorithms that are commonly used in network security are block-oriented ciphers, including the Data Encryption Standard (DES), Triple DES, and the increasingly popular Advanced Encryption Standard (AES).

Many other ciphers have also been defined, including RC4, which is a stream-oriented cipher. Other block-oriented ciphers include IDEA, Blowfish, CAST, RC-2, RC-5, and RC-6; there are not many stream ciphers that are commonly used in the context of network security (RC4, in its use within IEEE 802.11 WEP, and in TLS/SSL, is an exception). An exhaustive list of encryption algorithms is not warranted here, but readers interested in encryption should read Bruce Schneier's book entitled Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Edition.

For a given ciphersuite, the length of the authentication and encryption keys will be chosen appropriately for the constituent authentication and encryption algorithms. For example, AES may use encryption keys of 128, 192, or 256 bits. The choice of key length is related to the issue of key derivation, since keys of the appropriate length must be derived for the use of the encryption and/or authentication algorithms.

Derivation of Encryption and Authentication Keys

There are at least two reasons why one might need a key. One is to use in a keyed hash function, to create a cryptographic digest of the data (so that the device that decrypts the data can verify that the receiver can verify that the decrypted data is exactly what the sender had encrypted). Another is to encrypt the frame for transmission. To enable the proper operation of the selected authentication and encryption algorithms, a set of mechanisms must be defined to allow both of the communicating entities to derive the same keys. The key derivation mechanisms must derive keys of the appropriate length for the chosen hash or encryption algorithm.

As was previously implied, the "algorithm" for key derivation could be as simple as having all users statically define the relevant keys into their WLAN configurations using the configuration tools that are provided with the WLAN card. For more sophisticated approaches, keys can be chosen dynamically. At one extreme, keys pertain to only a single connection. At the other extreme, keys could be dynamically defined for an entire set of stations, with the disadvantage that they would all re-key at the same time. In the latter case, each new participant in the encryption scheme would need to be told the key in such a way that he or she would end up knowing the key that all the other stations were using, without revealing the key to any eavesdropper. Figure 7-1 shows the classification of key derivation schemes.

To limit the knowledge of the keys to only the intended parties, the key exchange must not reveal enough information to allow an eavesdropper to determine the resulting key(s). Luckily, techniques exist to allow two parties to exchange a secret over a public channel, in such a way that eavesdroppers can extract no information, even if they have a copy of the entire exchange. One of the better-known examples of such an algorithm is the Diffie-Hellman protocol, but there are many other functionally similar algorithms. The message authentication and encryption keys could be derived in one pass, from a single exchange, or there could be separate exchanges to derive each key.

Once the keys are known to both parties, the keys are used to both transform the data from plaintext into ciphertext (a process known as "encapsulation") and transform the ciphertext into plaintext (a process known as "decapsulation"). If the chosen ciphersuite indicates that a message digest function is to be used in addition to an encryption algorithm, then keys for both will need to be derived. When both message authentication and encryption are used together, the message is typically authenticated before being encrypted. Figure 7-2 shows the encapsulation and decapsulation processes with encryption only.

Figure 7-3 shows the encapsulation and decapsulation processes when message authentication is also included. Note that the ICV may not be computed over all of the original data, since certain header elements may be expected to change in transit, and thus should not be part of the ICV computation. The exact fields over which the ICV is calculated would be specified by the message authentication protocol rules.

Note that in both cases, the encryption (indicated by the gray shading) cannot cover all of the original frame's data, since the header must remain visible for the data to be delivered. However, the ICV calculation can include (or "cover") parts of the header that cannot be encrypted, so that the receiver can tell if the packet has been altered in transit.

Ciphersuite Selection

To provide flexibility for implementers, a protocol designer may, at his or her discretion, also provide a way for a STA and AP to select a ciphersuite from a list of mutually supported ciphersuites. When multiple ciphersuites are defined, one of them is typically designated as "mandatory-to-implement." This is to ensure that any two implementations that want to use security services can find at least one common set of authentication and/or encryption protocols.