|
Newsletters
|
|
|
|
|
802.11 Security
A special WirelessDevNet.com feature contribution by Praphul Chandra, May 23, 2002
 Printer Friendly Version
“By the end of 2002, 30 percent of all enterprises will risk security breaches because
they've deployed 802.11b wireless local area networks (WLANs) without proper security.” -
Security Research and Advisory firm, Gartner Inc.
“Today business customers' single objection to deploying wireless technology is the fact
that it's not secure," -- Bill Rossi, vice president and general manager of Cisco's wireless
networking operation.
"We came across a company with one of these wireless networks. All their source code,
everything was available. This network was beaconing, 'log onto me'...It basically had its Rolls-
Royce parked in the driveway, engine running, with a sign saying 'steal me.' -- Thubten
Comberford of White Hat Technologies, a wireless security firm.
Bottom-line : Wireless LANs are broadcasting secrets of enterprises that have spent
millions on Internet security. Wireless security has become a serious business requirement today.
So much so that some companies have blocked wireless deployment till the networking industry
makes the wireless networks as secure as wire-line networks.
Why is wireless security such a big issue? After all wire-line networks never had to cross
the security hurdle to see wide-scale deployment. The answer is inherent in the question. The
wireless medium by its very nature can’t be contained. Wire-line networks could be physically
contained into the network they formed by ensuring that rogue nodes did not have access to the
medium (wires). Companies were willing to deploy wire-line networks by ensuring this. This is
not to say that the wire-line networks did not have to cross the security hurdle. Once the internet
grew and there was a need to send out data over insecure networks, security in wire-line networks
became an absolute must too. However, for wireless networks this requirement has to be met at a
much earlier stage because of the insecure nature of the medium.
The wireless medium is so open to attacks that today’s wireless networks can be accessed
by using a laptop and an empty can of pringles chips (or a coffee can). This is not so surprising
once you think about it. The pringles can acts as an antenna (amazingly it provides a gain of up to
15 dB) providing a “tap” (a wireless network scanner/sniffer) into the medium. Once the laptop
gets access to the packets flowing through the network, it is an open world from there on. Since it
is so much more easier to access the wireless networks, it has given rise to the practice of “war-
driving” which involves driving around in a car with a laptop and some sort of antenna looking
for open networks. Surprisingly, this practice is more widespread than it may seem - specially in
Europe where the wireless market is more widespread than the North American market.
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.
About the Author
Praphul Chandra (PChandra@telogy.com) obtained his B.Tech in Electronics Engineering from IT-BHU and is
currently working as a Software Engineer in Telogy Networks, a Texas
Instruments company. He is also pursuing his MS in Electrical Engineering
(part-time) at Columbia University. This paper "Security in Wireless
Networks", written as a Project Report for MSEE course work, represents
his own thoughts and understanding of the subject matter, and in no way
reflects official or unofficial position of Telogy Networks or its parent
company Texas Instruments.
See Part II Securing 802.11 WLANs
Got comments,feedback? Send it to WirelessDevNet
Articles Home
Does your company have a solution, news, event, or scoop that WDN should know about?
Send details to editors@wirelessdevnet.com
|
|
|
