Appendix A. Decibel–Watts Conversion Table

(dBm)	(mW)	(dBm)	(mW)	(dBm)	(mW)	(dBm)	(W)	(dBm)	(W)	(dBm)	(W)
-50.0	0.00001	-7.4	0.185	-2.7	0.535	23.0	0.200	36.9	4.90	45.1	32.0
-43.0	0.00005	-7.2	0.190	-2.0	0.635	24.0	0.250	37.0	5.00	45.2	33.0
-40.0	0.00010	-7.1	0.195	-1.3	0.735	24.8	0.300	37.2	5.20	45.3	34.0
-38.2	0.00015	-7.0	0.200	-0.8	0.835	25.4	0.350	37.3	5.40	45.4	35.0
-37.0	0.00020	-6.9	0.205	-0.3	0.935	26.0	0.400	37.5	5.60	45.6	36.0
-36.0	0.00025	-6.8	0.210	0.0	1.000	26.5	0.450	37.6	5.80	45.7	37.0
-33.0	0.00050	-6.7	0.215	3.0	2.000	27.0	0.500	37.8	6.00	45.8	38.0
-31.2	0.00075	-6.6	0.220	4.8	3.000	27.4	0.550	37.9	6.20	45.9	39.0
-30.0	0.00100	-6.5	0.225	6.0	4.000	27.8	0.600	38.1	6.40	46.0	40.0
-29.0	0.00125	-6.4	0.230	7.0	5.000	28.1	0.650	38.2	6.60	46.1	41.0
-28.2	0.00150	-6.3	0.235	7.8	6.000	28.5	0.700	38.3	6.80	46.2	42.0
-27.6	0.00175	-6.2	0.240	8.5	7.000	28.8	0.750	38.5	7.00	46.3	43.0
-27.0	0.00200	-6.1	0.245	9.0	8.000	29.0	0.800	38.6	7.20	46.4	44.0
-26.5	0.00225	-6.0	0.250	9.5	9.000	29.3	0.850	38.7	7.40	46.5	45.0
-26.0	0.00250	-5.9	0.255	10.0	10.00	29.5	0.900	38.8	7.60	46.6	46.0
-25.6	0.00275	-5.9	0.260	10.4	11.00	29.8	0.950	38.9	7.80	46.7	47.0
-25.2	0.00300	-5.8	0.265	10.8	12.00	30.0	1.000	39.0	8.00	46.8	48.0
-24.9	0.00325	-5.7	0.270	11.1	13.00	30.2	1.050	39.1	8.20	46.9	49.0
-24.6	0.00350	-5.6	0.275	11.5	14.00	30.4	1.100	39.2	8.40	47.0	50.0
-24.3	0.00375	-5.5	0.280	11.8	15.00	30.6	1.150	39.3	8.60	47.4	55.0
-24.0	0.00400	-5.5	0.285	12.0	16.00	30.8	1.200	39.4	8.80	47.8	60.0
-23.7	0.00425	-5.4	0.290	12.3	17.00	31.0	1.250	39.5	9.00	48.1	65.0
-23.5	0.00450	-5.3	0.295	12.6	18.00	31.1	1.300	39.6	9.20	48.5	70.0
-23.2	0.00475	-5.2	0.300	12.8	19.00	31.3	1.350	39.7	9.40	48.8	75.0
-23.0	0.00500	-5.2	0.305	13.0	20.00	31.5	1.400	39.8	9.60	49.0	80.0
-22.8	0.00525	-5.1	0.310	13.2	21.00	31.6	1.450	39.9	9.80	49.3	85.0
-22.6	0.00550	-5.0	0.315	13.4	22.00	31.8	1.500	40.0	10.00	49.5	90.0
-22.4	0.00575	-4.9	0.320	13.6	23.00	31.9	1.550	40.2	10.50	49.8	95.0
-22.2	0.00600	-4.9	0.325	13.8	24.00	32.0	1.600	40.4	11.00	50.0	100.0
-22.0	0.00625	-4.8	0.330	14.0	25.00	32.2	1.650	40.6	11.50	51.0	125.0
-21.9	0.00650	-4.7	0.335	14.1	26.00	32.3	1.700	40.8	12.00	51.8	150.0
-21.7	0.00675	-4.7	0.340	14.3	27.00	32.4	1.750	41.0	12.50	52.4	175.0
-21.5	0.00700	-4.6	0.345	14.5	28.00	32.6	1.800	41.1	13.00	53.0	200.0
-21.4	0.00725	-4.6	0.350	14.6	29.00	32.7	1.850	41.3	13.50	53.5	225.0
-21.2	0.00750	-4.5	0.355	14.8	30.00	32.8	1.900	41.5	14.00	54.0	250.0
-21.1	0.00775	-4.4	0.360	14.9	31.00	32.9	1.950	41.6	14.50	54.4	275.0
-21.0	0.00800	-4.4	0.365	15.0	31.50	33.0	2.000	41.8	15.00	54.8	300.0
-20.8	0.00825	-4.3	0.370	15.1	32.00	33.1	2.050	41.9	15.50	55.1	325.0
-20.7	0.00850	-4.3	0.375	15.4	35.00	33.2	2.100	42.0	16.00	55.4	350.0
-20.6	0.00875	-4.2	0.380	16.0	40.00	33.3	2.150	42.2	16.50	55.7	375.0
-20.5	0.00900	-4.1	0.385	16.5	45.00	33.4	2.200	42.3	17.00	56.0	400.0
-20.3	0.00925	-4.1	0.390	17.0	50.00	33.5	2.250	42.4	17.50	56.3	425.0
-20.2	0.00950	-4.0	0.395	17.4	55.00	33.6	2.300	42.6	18.00	56.5	450.0
-20.1	0.00975	-4.0	0.400	17.8	60.00	33.7	2.350	42.7	18.50	56.8	475.0
-20.0	0.0100	-3.9	0.405	18.1	65.00	33.8	2.400	42.8	19.00	57.0	500.0
-17.0	0.0200	-3.9	0.410	18.5	70.00	33.9	2.450	42.9	19.50	57.4	550.0
-15.2	0.0300	-3.8	0.415	18.8	75.00	34.0	2.500	43.0	20.00	57.8	600.0
-14.0	0.0400	-3.8	0.420	19.0	80.00	34.1	2.600	43.1	20.50	58.1	650.0
-13.0	0.0500	-3.7	0.425	19.3	85.00	34.3	2.700	43.2	21.00	58.5	700.0
-12.2	0.0600	-3.7	0.430	19.5	90.00	34.5	2.800	43.3	21.50	58.8	750.0
-11.5	0.0700	-3.6	0.435	19.8	95.00	34.6	2.900	43.4	22.00	59.0	800.0
-11.0	0.0800	-3.6	0.440	20.0	100.0	34.8	3.000	43.5	22.50	59.3	850.0
-10.5	0.0900	-3.5	0.445	20.2	105.0	34.9	3.100	43.6	23.00	59.5	900.0
-10.0	0.1000	-3.5	0.450	20.4	110.0	35.1	3.200	43.7	23.50	59.8	950.0
-9.8	0.1050	-3.4	0.455	20.6	115.0	35.2	3.300	43.8	24.00	60.0	1000.0
-9.6	0.1100	-3.4	0.460	20.8	120.0	35.3	3.400	43.9	24.50	61.8	1500.0
-9.4	0.1150	-3.3	0.465	21.0	125.0	35.4	3.500	44.0	25.00	63.0	2000.0
-9.2	0.1200	-3.3	0.470	21.1	130.0	35.6	3.600	44.1	25.50	64.0	2500.0
-9.0	0.1250	-3.2	0.475	21.3	135.0	35.7	3.700	44.1	26.00	64.8	3000.0
-8.9	0.1300	-3.2	0.480	21.5	140.0	35.8	3.800	44.2	26.50	65.4	3500.0
-8.7	0.1350	-3.1	0.485	21.6	145.0	35.9	3.900	44.3	27.00	66.0	4000.0
-8.5	0.1400	-3.1	0.490	21.8	150.0	36.0	4.000	44.4	27.50	66.5	4500.0
-8.4	0.1450	-3.1	0.495	21.9	155.0	36.1	4.100	44.5	28.00	67.0	5000.0
-8.2	0.1500	-3.0	0.500	22.0	160.0	36.2	4.200	44.5	28.50	67.4	5500.0
-8.1	0.1550	-3.0	0.505	22.2	165.0	36.3	4.300	44.6	29.00	67.8	6000.0
-8.0	0.1600	-2.9	0.510	22.3	170.0	36.4	4.400	44.7	29.50	68.1	6500.0
-7.8	0.1650	-2.9	0.515	22.4	175.0	36.5	4.500	44.8	30.00	68.5	7000.0
-7.7	0.1700	-2.8	0.520	22.6	180.0	36.6	4.600	44.8	30.50	68.8	7500.0
-7.6	0.1750	-2.8	0.525	22.7	185.0	36.7	4.700	44.9	31.00	69.0	8000.0
-7.4	0.1800	-2.8	0.530	22.8	190.0	36.8	4.800	45.0	31.50	70.0	10000.0

Counterintelligence: Wireless IDS Systems

"Assess opponents conditions, observe what they do, and you can find out their plans and measures. "

Intrusion detection systems (IDSs) are divided into two major categories: signature-based and knowledge-based.

Signature-based IDSs are the most common and easy to implement, but they are also the easiest to bypass and lack the capability to detect novel attacks. These IDSs compare events on the network to signs of known attacks called attack signatures. If a hacking tool is modified to alter some part of its attack signature, the attack is likely to go unmentioned. Besides, the attack signatures database has to be well secured and frequently updated.

Knowledge-based IDSs monitor the network, collect statistics about standard network behavior, detect possible deviations, and flag them as suspicious. For these reasons, knowledge-based IDSs are also called behavior-based or statistical. Proper network baselining is essential for efficient statistical IDS operations. Although knowledge-based IDSs are not easily fooled, their main problems are false positives and difficulties detecting some covert channel communications. The possibility of false-alarm generation is particularly worrisome on wireless networks due to the unreliable nature of the Layer 1 medium. Also, attacks launched at the early stage of the baselining period can severely interfere with the IDS learning process, making deployment of a knowledge-based IDS on a production network a somewhat risky task. What if the "normal" behavior of the network is already altered by a cracker at the moment of IDS deployment?

We believe that a proper wireless IDS should belong to both categories simultaneously. Few wireless attack tools have specific attack signatures, as discussed in this chapter. The signatures that do exist can be matched against the database of known attack traces to trigger the alarm. However, many wireless attacks do not generate specific signatures, but instead cause a deviation from the standard network operation on lower network layers. This deviation can be as subtle as few wireless frames coming out of sequence or as straightforward as tripled bandwidth consumption on the WLAN. Detecting wireless network behavior abnormalities is not an easy task, because no two wireless networks are the same. A similar principle applies to the wired LANs, but wired networks do not suffer from radio interference, signal refraction, reflection, and scattering issues. They do not have roaming users and stretch CAT 5 cables out of the office window to give access to the potential attackers on streets. Thus, the key to efficient intrusion detection on WLANs is detailed network baselining over a significant time period.

Only by collecting a large number of statistics about the particular WLAN behavior is it possible to determine what constitutes abnormal behavior and what doesn't, and to distinguish connectivity problems, user errors, and malicious attacks. Multiple 802.1x/LEAP authentication requests might constitute a brute-forcing attempt. At the same time, it could be a user guessing his or her forgotten password, or a badly written supplicant application that attempts to log in until the correct password is entered. An increased number of beacon frames per second might signal a DoS attack or rogue access point presence, but it could also be a faulty or misconfigured access point. Higher layer IDS alarm-triggering events, such as a large number of fragmented packets or abundant TCP SYN requests, can indicate a possible portscan or DoS attack, but might also be a result of a Layer 1 connectivity problem on a WLAN. Fire up your Ethereal or similar protocol analyzer on a wireless interface and subject the network to a high level of RF interference; you will see all kinds of damaged and incomplete packets identified as various obscure protocols by your sniffer (Banyan Vines, anyone?). It is not surprising that some of these malformed packets can accidentally trigger an IDS alarm. After some investigation, the "evil cracker" can turn out to be a Bluetooth dongle or microwave oven creating RF interference in the network area.

Guarding the Airwaves: Deploying Higher-Layer Wireless VPNs

"For an invincible defence, conseal your form."

"Formlessness means being so subtle and secret that no one can spy on you."

A virtual private network (VPN) is a way to use a public telecommunication infrastructure, such as the Internet, to provide remote offices or individual users with secure access to their organization's network. Because 802.11 LANs use unlicensed frequency bands and can be easily accessible to outsiders either accidentally or with malicious intent, wireless networking provides an important area for VPN deployment and maintenance. Whereas the deployment of wired VPNs is usually restricted to specific cases of telecommuters and remote branch offices, the wireless world is entirely different, and deploying a VPN can be applicable to any wireless link if a high level of security is needed. This includes connections between hosts on a WLAN as well as point-to-point links between wireless bridges. Of course, when 802.11i is finally out and widely implemented, the need for wireless VPN deployment will decrease, but not disappear. As reviewed in the Attack chapters, even before the final draft is released, 802.11i standard implementations already have a handful of security problems. We are quite confident that new attacks against the novel standard will appear and spread as time passes. Besides, in a highly secure environment, one cannot completely rely on a single safeguard, or a single network layer safeguard. Also, there would be security-conscious network managers who prefer to trust tested and tried defense mechanisms, such as IPSec. In the case of point-to-point wireless links it is easier and more economical to deploy a network-to-network VPN than 802.11i-based defenses, including the RADIUS server and user credentials database, while using 802.11i with PSK and no 802.1x is not a good security solution for a high throughput network-to-network link. Either way, wireless VPNs are here to stay and surely deserve a place of their own in this book.

A VPN is the opposite of an expensive system of owned or leased lines that can be used by only one organization. The goal of a VPN is to provide the organization with the same capabilities at a much lower cost. Compare it to point-to-point bridged wireless connectivity solutions, which can also substitute expensive leased lines. VPN and wireless technologies do not compete, but complement each other.

A VPN works by using the shared public infrastructure, while maintaining privacy through security procedures and tunneling protocols such as the Layer Two Tunneling Protocol (L2TP). In effect, the protocols, by encrypting data at the sending end and decrypting it at the receiving end, send the data through a "tunnel" that cannot be entered by data that is not properly encrypted. An additional level of security involves encrypting not only the data, but also the originating and receiving network addresses.^[1] A WLAN can be compared to a shared public network infrastructure or, in some cases (hot spots, community nodes), is a shared public network infrastructure.

^[1] www.whatis.com definition

Let's examine the term VPN more closely and try to explain each component in detail, so readers who never encountered VPNs in the real world will have a clear understanding of what we imply here.

The virtual part of the term entails mutually exclusive and peaceful coexistence of two separate networks within single network segments, be it coexistence of IP, IPX, and DDP on the same LAN, or IP, IPSec, and L2TP traffic going through the Internet cloud. The private part acknowledges that the interaction and the underlying network are only understandable to the endpoints of the channel and not to anyone else. Later, you will see that it applies to both secrecy and authenticity of transmitted data. The final network part is pretty much self-explanatory and is a generally accepted definition. Any number of devices that have some common way of communicating with each other, irrespective of their geographic location, constitute a network.

It is a common misconception that a VPN must encrypt the bypassing data, but that is not necessarily true. The VPN is said to comply with three criteria: confidentiality, integrity, and availability. You have to note that no VPN is resistant to DoS or DDoS attacks and cannot guarantee availability on the physical layer due to its virtual nature and reliance on the underlying protocols. Two of the most important VPN features, especially in the wireless communication where you have limited control over the signal spread, are integrity and, most important, confidentiality of the passing data. Take a real-life situation when someone has managed to bypass the WEP encryption and connect to a WLAN. In the non-VPN scenario, he or she will be able to sniff the data and interfere with network operation. However, if the packets are authenticated, man-in-the-middle attacks are nearly impossible to perform, while the data can still be intercepted. Addition of an encryption element to the VPN mitigates the threat presented by data interception.

Therefore, we tend to see VPNs not as strict isolation of communication, but rather a communication that runs in a more controlled environment with exclusively defined groups of permitted participants.

Hash Functions, Their Performance, and HMACs

Other widely used hash functions include 128-bit MD5 from RSA Data Security, Inc., which is a very fast and commonly implemented hash. MD5 is traditionally used to encrypt Linux user passwords (hashes start with the "$1$" character), authenticate routing protocols like RIPv2 and OSPF, create checksums of binaries in RPMs, and verify the integrity of Free/OpenBSD ports files. The specifications of MD5 are available in RFC 1321. Host intrusion detection tools like Tripwire (http://www.tripwire.com) use MD5 to take snapshots of a system's files and preserve them in a database (which must be encrypted) to determine if any of the system's files were modified by crackers. A poor man's Tripwire is the md5sum command available on many UNIX-like systems. A predecessor of MD5, MD4 is very fast, but it was broken in October 1995. Unfortunately, MS-CHAP still uses MD4 hashes even in its second version, and protocols such as 802.1x EAP-LEAP that rely on MS-CHAP can be vulnerable to attacks against MD4. Since 1995, there have been serious doubts about the security of MD5 and other 128-bit cryptographic hash ciphers, and the use of at least 160-bit hashes is recommended. You can check the security of your MD5 hashes using the MD5Crack tool, available for download from http://www.checksum.org/download/MD5Crack (this is the compiled Windows version of the tool; UNIX source code can be downloaded from http://www.packetstormsecurity.org).

Apart from SHA-1 and higher, there are other reasonably secure cryptographic hash ciphers to use, including HAVAL (variable-length hash values), RIPEMD, and Tiger. RIPEMD from the EU project Race Integrity Primitives Evaluation (RIPE) consists of two parallel MD5 processes running for five rounds and producing a 160-bit hash. RIPEMD is considered as secure as SHA-1 and is used by Nessus in conjunction with Twofish. Tiger was designed by the Serpent development team and is optimized to run on 64-bit chips, on which it is approximately 2.8 times faster than RIPEMD and 2.5 times faster than SHA-1. Tiger produces a 192-bit hash, although less-secure 128- and 160-bit variants of this cipher do exist.

Common block symmetric ciphers can also be used as the one-way hashes with few exceptions (e.g., Blowfish). In fact, being able to implement a symmetric cipher as a cryptographic hash was one of the conditions an AES candidate had to meet. Knowing how cryptographic hashes work, it is easy to see that there is nothing supernatural about using a block symmetric cipher in such a role: Supply a constant, use the input data to generate subkeys, and run. However, there is no reason to use AES or MARS, and so on, as a one-way hash when well-designed specific cryptographic hash algorithms like SHA exist.

Cryptographic hash ciphers are designed to quickly process large quantities of data; for example, to hash data and append hashes to packet headers on the fly as the packets are sent over the network. The processing rate of cryptographic hash ciphers in MB/sec is generally comparable to the processing rate of stream ciphers such as RC4 and is 1.5 to 2 times above the processing rate of AES. Obviously, there is a performance penalty for using more secure, larger hashes, and MD5 would have a higher data throughput than Tiger (on 32-bit CPUs) or SHA-1.

Cryptographic hashes are fine to sustain data integrity via data fingerprinting or to identify users against databases of hashed passwords. However, by themselves they do not authenticate the data itself; the attacker can alter the original data before hashing takes place. One possible solution for this problem is using a HMAC, also called a keyed message digest. A HMAC is nothing more than a cryptographic hash and shared secret key combined. Thus, the data gets encrypted before it is hashed, and the attacker would have to break the symmetric cipher key after generating the original message from the hash or break the symmetric cipher key if he or she has access to data before hashing takes place. An example of message authentication code specifically designed for improving wireless security is Michael (MIC).

MIC: Weaker But Faster

The main problem encountered in the design of MIC was developing a HMAC that would run on legacy hardware without imposing significant penalties on network throughput and latency. The client hosts can offload the HMAC computation to the sufficiently powerful laptop or even PDA CPU, even though it is still undesirable! What if a company decides to design and manufacture a tiny 802.11-enabled mobile phone? Besides, many access points do not boast high processing power. Yet, the AP or a wireless bridge should be able to verify both integrity and authenticity of the bypassing packets. Recall the structure of SHA with its 80 iteration rounds and imagine generating such a hash for every packet sent over the wireless network. Would a common access point or a PDA be able to implement that process without significant resource exhaustion? Not very likely!

Thus, an entirely new algorithm called MIC was designed by Niels Ferguson to provide packet integrity checking and forgery detection on TKIP-enabled WLANs. It was designed as a third attempt, after two previous designs called Mickey and Michelle. MIC is a trade-off between security and resource consumption and implementation capability. It runs on older wireless access points and client hardware without imposing a significant performance penalty, but the security level it provides is only 20 bits. As you should understand by now, in modern cryptographic terms this is not a lot.

Before discussing the trade-off and its practical outcome possibilities, learning how MIC works is helpful. The MIC secret key consists of 64 bits and is represented as an 8-byte sequence k₀...k₇. This sequence is converted to two 32-bit little-Endian words, K₀ and K₁. Throughout the MIC design, all conversions between bytes and 32-bit words use the Little-Endian conventions, because the cipher is expected to run on Little-Endian CPUs. In fact, the majority of access points now manufactured use older Intel line chips such as i386 or i486.

MIC operates on the data field, as well as source and destination address fields of the wireless frame. The integrity of IVs is not protected and the data field is not interpreted. Before the cipher runs, the frame is padded at the end with a single byte (value 0x5a), followed by 4 to 7 zero bytes. The number of zero bytes is selected to ensure that the overall length of the padded frame is always a multiple of four. The padding is never transmitted with the frame; it is used only to simplify the computation over the final block. After the padding, the frame is converted into a sequence of 32-bit words M₀...M_N-1, where N = [(n+5)/4]. By design, M_N-1 = 0 and M_N-2 != 0.

The MIC value is computed starting with the key value and applying a block function b for every message word. The cipher loop runs a total of N times (i includes 0 to N-1 values), where N is the number of 32-bit words making up the padded frame. The algorithm produces two words (l,r), which are converted into a sequence of eight Little-Endian octets, the MIC value:

Input: Key (K0, K1) and padded frame (represented as 32-bit words) M0...MN Output: MIC

 value (V0, V1)



MIC <= ((K 0, K1) , (M0,...,MN))

   (l,r) <=(K0, K1)

   for i = 0 to N-1 do

         l <= l ^= Mi

         (l,r) <= b(l,r)

return (l,r)

The MIC value is appended to the frame as data to be sent.

The block function b used by MIC is a tiny Feistel algorithm that employs alternating additions and XORing. The <<<>>> indicates right rotation of 32-bit values, and XSWAP is a function that exchanges the position of the two least significant bytes with the position of the two most significant bytes in a word:

Input: (l,r)

Output: (l,r)

b(L,R) 35



r <= r ^= (l <<< 17)

l <= (l + r) mod 232

r <= r ^= XSWAP(l)

l <= (l + r) mod 232

r <= r ^= (l <<< 3)

l <= (l + r) mod 232

r <= r ^= (l >>> 2)

l <= (l + r) mod 232

return (l, r)

As you can see, the cipher is neither sophisticated nor strong. It was estimated that an attacker has one chance in a million of sneaking in a frame with a compromised payload but correct MIC. One might argue that significant damage can be done by inserting a single modified frame after 1 million frames sent. However, the old WEP ICV (CRC-32) is still used as well, and has to be faked together with MIC. Thus, such attacks are neither easy nor have a high probability of success. Nevertheless, to mitigate their success the so-called TKIP countermeasures were introduced. When more than a single forgery attempt in a second has been detected, the host deletes the groupwise or pairwise key (depending on whenever a unicast or multicast frame was affected), deassociates, and waits for a minute before the reassociation. Thus, the possibility of an evil Joe Cracker sending a few million modified frames to sneak in a few of them undetected is eliminated.

However, the same Joe Cracker might turn desperate and try to send forged frames to trigger the countermeasures and cause a DoS attack, employing not a bug, but a feature. The possibility of such DoS attacks introduced by a new security feature was widely argued. The best example of such discussion is a thread at the Cryptography mail list (http://www.mail-archive.com/cryptography@wasabisystems.com/msg03070.html is the first message in a thread). In this thread Niels Ferguson, the creator of MIC, answers questions considering the possibility of a DoS attack abusing MIC countermeasures. Despite the hullabaloo around the likelihood of this DoS attack and the countermeasures' imperfections, such an attack might not be as realistic and easy to launch as many would think. Remember that the TSC will drop all out-of-sequence frames; the attacker thus has to send a frame with a "future," yet unused, IV. However, recall that the IV is actively used by the TKIP per-packet key generation function. If the IV is changed, the frame will not be decrypted correctly. Because the CRC-32 is still there, it would not give a proper value, leading to the forged frame being eventually dropped. Thus, the attacker has to sniff out valid frames, delete them to prevent them from reaching the receiver, corrupt the MIC, recalculate the CRC-32 to reflect the changes in MIC, and only then forward the "MIC-of-Death" frames to the target (desirably every 59 seconds). Although possible, it is by no means an easy task.

Because the final 802.11i release-compatible hardware will have to be optimized for running AES, using a CBC-MAC HMAC implementing AES as a one-way hash would be more practical and secure than employing some form of MIC or a well-known message digest like SHA. It will also remove all possible problems with MIC just discussed. Thus, in some specific cases, it could be preferable to use symmetric block ciphers for data integrity preservation as well as for data encryption and message authentication.

Dissecting an Example Standard One-Way Hash Function

How does one "encrypt" messages of different length to the hash, which is always x bits long, without even using a key? To answer the first part of the question, you XOR the data with a fixed initial value x bits long. To answer the second part of the question, the hashed data itself becomes a key; subkeys for every round are derived from the data input to the hash. We illustrate how such an algorithm can work using an example of the Secure Hashing Algorithm (SHA) designed by the NSA. A full description of the SHA standard is available at the NIST Web page at http://www.itl.nist.gov/fipspubs/fip180-1.htm. In fact, there are four SHA standards: SHA-1 (160-bit hash), SHA-256, SHA-384, and SHA-512, with hashes of name-corresponding length.

Essentially, SHA-1 is a block cipher that encrypts a 160-bit block (the initial constant) with a "key" (data hashed) of variable length (less than 2⁶⁴ bits) using 80 32-bit subkeys in 80 rounds.

Both SHA-1 and SHA-2 begin by converting the input to their unique representation as a multiple of 512 bits in length, keeping track of the input's original length in bits. To do it, append one to the input message. Then add as many zeros as necessary to reach the needed length, which would be the next possible length that is 64 bits less than a whole multiple of 512 bits. Finally, use these preserved 64 bits to append the original length of the message in bits.

Expand each block of 512 bits into a source of 80 32-bit subkeys using the block itself as the first 16 subkeys. All remaining subkeys are generated as follows: subkey N is the XOR of subkeys N-3, N-8, N-14, and N-16, subjected to a circular left shift of one position.

The initial 160-bit block constant value happened to be 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 (perhaps in ASCII it would make the name of the SHA author's cat). Use it as an input for processing 512-bit blocks of the modified hashed data.

For every message block, encipher this starting value using 80 subkeys for the current message block. Add each of the 32-bit pieces of the ciphertext result to the starting value modulo 2³² and use that result as the starting value for handling the next message block. The starting value created at the end of handling the last block is the actual hash value, which is 160 bits long.

Because we feed a 160-bit input value into SHA rounds, each block of data is divided into five pieces, instead of two halves, as in DES. An F function is run on four of the five pieces, although it is actually the XOR of a function of three of the input pieces and a circular left shift of a fourth, which is XORed with another piece. That piece is modified by being XORed with the current round's subkey and a constant. The very same constant is used over each group of 20 rounds. One of the other blocks is also altered by undergoing a circular left shift, and then the (160-bit) blocks are rotated.

The F function, as well as the constant, is changed every 20 rounds. Calling the five pieces of input a, b, c, d, and e, the rounds of the SHA block cipher component proceed as follows:

• Change a by adding the current constant to it.

• These constants are:

  
  

  For rounds 1 to 20: 5A827999
  
  
  
  For rounds 21 to 40: 6ED9EBA1
  
  
  
  For rounds 41 to 60: 8F1BBCDC
  
  
  
  For rounds 61 to 80: CA62C1D6
  
  

  
  

• Change a by adding the appropriate subkey for this round to it.

• Change a by adding e, circular left-shifted 5 places, to it.

• Change a by adding the main F function of b, c, and d to it. The F function is calculated as follows:

  
  

  For rounds 1 to 20, it is (b && c) || ((!= b) && d).
  
  
  
  For rounds 21 to 40, it is b ^= c ^= d.
  
  
  
  For rounds 41 to 60, it is (b && c) || (b && d) || (c && d).
  
  
  
  For rounds 61 to 80, it is again b ^= c ^= d.
  
  

  
  

• Change d by giving it a circular shift of 2 positions.

• Swap the pieces,by moving each piece to the next earlier one, except that the old a value ends up being moved to e.