802.11 Security
For authentication 802.11 specifies two modes : OSA(Opens Systems
Authentication) and Shared Key Authentication. The former basically means null
authentication. In this mode, any MT requesting access to a network is granted the
access by the AP without performing any security checks on the identity of the MT.
In the latter, the AP uses a “pre-shared” key based challenge-response system
similar to HIPERLAN to authenticate the MT. The figure below details the process.
In Shared Key Authentication, the AP sends a random number to the MT when it
receives an access request from the MT (usually an 802.11 registration request).
This random number is the challenge that the AP sends to the MT. On receiving this
random number, the MT signs this random number using a “pre-shared ” secret key
and sends the response back to the AP. The AP verifies that the random number has
been signed by the correct key by calculating the signature itself and comparing the
computed and the received values. Once the AP verifies this, it authenticates the MT.
Once the AP has granted access to the MT, data packets exchanged between the AP
and the MT is encrypted and signed using WEP (Wired Equivalent Privacy). WEP is
specified as an option in 802.11 standards, to provide confidentiality and integrity
for wireless traffic. It uses RC4 algorithm based on a 40-bit “pre-shared” secret key
and a 24-bit IV (Initialization Vector). An ICV(Integrity Check Value) is included in
every packet to ensure data integrity.
What’s wrong with 802.11 Security?
The first thing that contrasts 802.11 security with HIPERLAN security is the fact that
unlike HIPERLAN, 802.11 binds itself to a single cryptographic algorithm (RC4). The
second glaring difference is that there is no security support for handoffs. In fact,
the standard does not mention how to maintain a secure session while moving
across cells. The following sub-sections aim to expose other important loopholes in
802.11 security.
Before proceeding, keep in mind that the security of a communication network is
ensured by the use of secret keys which act as seeds into cryptographic algorithms.
Put another way, a network is as secure as the keys it uses, assuming that the
cryptographic algorithms are publicly known.
1) Pre-Shared Keys
Needless to say a network operating in the OSA mode of authentication is wide open
to attacks. However, the onus of lack of security in this case belongs to the
organization operating the network. In the Shared Key Authentication mode,
802.11 uses the challenge-response system for authenticating the end-points.
There is nothing wrong with this scheme.
The loophole lies in the use of “pre-shared” keys. What does pre-shared mean? How
are nodes supposed to pre-share keys with an AP? 802.11 says nothing about how
the AP and a node end up pre-sharing a key? Compare this to HIPERLAN (or even
the much weaker Bluetooth) where the protocol defines exactly how sharing of keys
can be achieved over an insecure medium and you begin to realize why the 802.11
security diagram is much smaller than the other diagrams. HIPERLAN uses Public
Key Cryptography to obtain a link-key over an insecure medium. It then uses this
link-key to exchange session keys which are used in Symmetric Key Cryptography
for applications. In short, 802.11 leaves out the difficult part of key management
over an insecure medium.
In the absence of any key management protocol, real life implementations of
802.11 require manual configuration of keys into all mobiles that wish to
communicate with an AP. In practice, most installations use a single key that is
shared between all mobiles. This means that even when an AP authenticates a
mobile in the SKA mode, all it ensures is that the mobile belongs to a certain group
of mobiles. There is no way for the AP to determine the exact identity of the mobile
that is asking for access. To make matters worse, most 802.11 implementation
share keys across Access Points. This increases the size of the group to which a
mobile can be traced.
Theoretically, more sophisticated key management techniques can be used to make
authentication better. However, since such techniques are not part of the standard,
they raise interoperability issues and therefore service providers tend to avoid them.
2) One way authentication.
There is another issue with 802.11 authentication. It is one-way i.e. it provides a
mechanism for the AP to authenticate the mobile but has no provision for the mobile
to be able to authenticate the network. This means that a rogue node may
masquerade as an AP and establish communication with the mobile. Since, the
mobile can never find out that it is communicating with a rogue node, the rogue
node has access to everything that mobile sends to it.
3) The Infamous WEP
802.11’s WEP has earned a bad name in the industry and rightly so. There are
several reasons why WEP is a bad security solution. In fact, these reasons together
create a multiplicative effect on reducing WEP’s effectiveness.
WEP uses RC4 (a stream-cypher) in synchronous mode for encrypting data packets.
From section 1.3.2, note that a synchronous stream cypher encrypts data bit-wise
(practically byte-wise) using a key-stream which is independent of any feedback
and depends solely on the seed (/ key) provided to the algorithm. This means that
the security of the 802.11 network is completely compromised if the key is
compromised. Also, the two key generators at the two communicating nodes must
be kept synchronized (by some external means) to make this arrangement work.
In synchronous stream cyphers (like RC4 used in 802.11), the loss of a single bit of
a data stream encrypted under the cypher causes the loss of ALL data following the
lost bit (including data in the following packets). This is so because data loss
de-synchronizes the keystream generators at the two end-points. Since data loss is
widespread in the wireless medium, it is infeasible to use a synchronous stream
cypher across 802.11 frame boundaries. This is the basic problem of WEP. It uses a
cypher not suitable for the environment it operates in. Note here that the problem
is not the RC4 algorithm. The problem is that a stream cypher is not suitable for
wireless medium where packet loss is widespread. SSL(Secure Socket Layer) uses
RC4 at the application layer successfully because SSL (and therefore RC4) operates
over a reliable data channel that does not lose any data packets and can therefore
guarantee perfect synchronization between the two end points.
Instead of selecting a block cypher (like AES or DES) suitable for wireless medium,
802.11 tries to solve the synchronization problem of stream cyphers by shifting
synchronization requirement from a session to a packet. Going back to SSLs use of
RC4, SSL uses one key for a complete session. The key does not need to be replaced
on every packet since the end points are synchronized and RC4 can produce the
same keystream at both ends using the session key. In the wireless medium since
the synchronization between the end-points is not perfect (and subject to packet
loss), 802.11 changes keys for every packet. This way each packet can be
encrypted / decrypted irrespective of the previous packets loss. Here is how RC4
works in 802.11:-
How WEP works?
RC4(SharedKey + IV) = KeyStream for a packet. ------- (1)
LengthOf(KeyStream) = LengthOf(DataPacket+CRC) ------- (2)
Step-1 shows that the RC4 cypher uses the combination of the shared key and the
IV to produce a key stream for each packet. Step-2 shows that the length of the key
stream is equal to the length of the packet since the data bits in the packet have to
be XORed with the key stream to generate the cypher text.
Using a separate key for each packet solves the synchronization problem but realize
that one of the most important requirements of RC4 is that the same key should not
be reused EVER. This requirement, combined with the fact 802.11 would need a new
key for every single packet to make the network really secure, means that 802.11
needs a very large key space. Recall now that the shared key referred to in step-1
above is the “pre-shared” key discussed before. Since 802.11 specifies no way to
share a key, most 802.11 implementations use the same key in a BSS (some
implementations use the same key across BSSs to make matters worse). The
bottom line is that for all practical purposes the key being used by RC4 is a
concatenation of a constant (the pre-shared key) and the IV. Therefore, the key
space for the RC4 is 2N where N is the length of the IV. 802.11 specified the IV
length as 24.
To put things in perspective, realize that if we have a 24 bit IV (=> 224 keys in the
key- space), a busy base station which is sending 1500 byte-packets @ 11Mbps will
exhaust all keys in the key space in (1500*8)/(11*106*224) seconds or appx. 5
hours. On the other hand RC4 in SSL would use the same key space for 224 (=107)
sessions. Even if the application has 10,000 sessions per day, the key space would
last for 3 years. In other words, an 802.11 BS using RC4 has to reuse the same key
in appx. 5 hours whereas an application using SSL RC4 can avoid key reuse for appx.
3 years. This shows clearly that the fault lies not in the cypher but in the way it is
being used. Going beyond an example, analyses of WEP [3],[4] has shown that
there is a 50% chance of key-reuse after 4823 packets and there is 99% chance of
collision after 12,430 packets. These are dangerous numbers for a cryptographic
algorithm.
Believe it or not, it gets worse. 802.11 specifies that changing the IV with each
packet is optional. Combine this with the fact that the whole BSS is using a common
shared key and you have a clear violation one of the most important requirements
of RC4 (no key should be reused EVER).
Why is it so important to avoid key reuse in RC4? Reusing the same key means that
802.11 allows different packets to use the same keystream to produce the
respective cypher-text. This is dangerous. Let ki (i = 1,2,3, ….) be the key stream
produced for a specific packet and pi be the packet data in plain-text. Then RC4
produces cypher text ci = pi xor ki. Now, because the medium is wireless, an
intruder has easy access to ci, the cypher-text. If the intruder knows the plain text
part of a certain message, he can calculate the key stream used to encrypt this
certain packet since ki = pi xor ci. Once ki is known, any future packets encrypted
with the same ki can be easily decrypted since pi = ci xor ki. This is the reason why
RC4 warns against key re-use, which unfortunately 802.11 ignores. Note that since
the variable part of the RC4 key (the IV) is attached to each packet in plain-text, it
is trivial to find out that two packets have been encrypted with the same key.
4) Integrity Check
To ensure that a packet has not been modified in transit, 802.11 uses an IC
(Integrity Check) field in the packet. This IC is implemented as a CRC-32 checksum,
which is part of the WEP encrypted payload. The problem with CRC-32 is that it is
linear. This means that it is possible to compute the bit difference of two CRCs based
on bit difference of the message over which they are taken. In other words, flipping
bit x in the message results in a deterministic set of bits in the CRC that must be
flipped to produce the correct checksum of the modified message. Because the
flipping bit carries through after an RC4 decryption, an intruder can flip the desired
bits in the message and then adjust the IC so that the message appears valid to the
receiver.
To summarize, here is the list of things (in decreasing order importance) that is
wrong with 802.11 security:* WEP uses a synchronous stream cypher over a medium, where it is difficult to
ensure synchronization during a complete session. * 802.11 does not provide any
mechanism for sharing keys over an insecure medium leading to key-sharing in a
BSS and sometimes across BSSs. * 802.11 specifies that changing the IV with each
packet is optional. * The IV used in 802.11 is just 24 bits long giving a very limited
key-space specially since each packet needs to have a separate key for the network
to be really secure. * No support for a MT to authenticate the network. * CRC-32
used for message integrity is linear. * WEP concatenates the IV directly to the
pre-shared key to produce a key for RC4, thus exposing the base-key to direct
attack.
Note that the limited size of the IV figures much lower in the list than one would
expect. This emphasizes the fact that simply increasing the IV size would not
improve WEP’s security considerably. The deficiency of the WEP encapsulation
design arises from attempts to adapt RC4 to an environment for which it is poorly
suited.
One of the questions that comes to mind is “Why is IEEE sticking with RC4 even
when it has been shown to be unsuitable for the wireless medium?”. Well, ultimately,
the IEEE is expected to use the Advanced Encryption Standard (AES), a more
appropriate cipher for wireless. Unfortunately, AES requires considerably more
horsepower than most existing 802.11b cards provide today and therefore IEEE is
sticking with RC4 for the time being.
標準
IEEE802.11
HIPERLAN
標準制訂單位
IEEE
ETSI
頻段
2.4-2.4835GHz
5.15-5.3GHz
頻道進階技術
CSMA/CA
CSMA/CA
位元率
1 or 2 Mbps
20Mbps
為了提供資料保密功能，IEEE802.11 標準要求在 MAC 層內有資料加密控制,要讓無線網路的安全
性相等於有線網路一般，這種加密控制稱為 Wired Equivalent Privacy，是一種以 RC4 作為加
密演繹法則，目前使用 RC4 技術的公司有 Microsoft、Netscape、Oracle 等。由於這項技術嚴密，
802.11 委員會曾選用它作 40bits 的加密，再加上原本 DSSS 使用軍方的展頻技術，讓整個系統
安全性更高。