2. Basic Security
3. Above and Beyond
Introduction - Why wireless?
In 1999 the IEEE completed and approved the standard known as 802.11b, and
WLANs were born. Finally, computer networks could achieve connectivity with
a useable amount of bandwidth without being networked via a wall socket. Suddenly
connecting multiple computers in a house to share an Internet connection or
play LAN games no longer required expensive or ugly cabling. Business users
could get up out of their chairs and sit in the sunshine while they worked.
New generations of handheld devices allowed users access to stored data as they
walked down the hall to a meeting. The dawn of networking elegance was upon
us. Users could set their laptops down anywhere and instantly be granted access
to all networking resources. This was, and is, the vision of wireless networks,
and what they are capable of delivering.
Fast forward to today. While wireless networks have seen widespread adoption
in the home user markets, widely reported and easily exploited holes in the
standard security system have stunted wireless' deployment rate in enterprise
environments. While many people don't know exactly what the weaknesses are,
most have accepted the prevailing wisdom that wireless networks are inherently
insecure and nothing can be done about it. Can wireless networks be deployed
securely today? What exactly are the security holes in the current standard,
and how do they work? Where is wireless security headed in the future? This
article attempts to shed light on these questions and others about wireless
networking security in an enterprise environment.
A few technical details
WLAN networks exist in either infrastructure or ad hoc mode. Ad hoc networks
have multiple wireless clients talking to each other as peers to share data
among themselves without the aid of a central Access Point. An infrastructure
WLAN consists of several clients talking to a central device called an Access
Point (AP), which is usually connected to a wired network like the Internet
or a corporate or home LAN. Because the most common implementation requiring
security is infrastructure mode, most security measures center around this design,
so securing an infrastructure mode wireless network will be the focus of this
article. 802.11b specifies that radios talk on the unlicensed 2.4GHz band on
one of 15 specific channels (in the US, we are limited to using only the first
11 of those 15 channels). Wireless network cards automatically search through
these channels to find WLANs, so there is no need to configure client stations
to specific channels. Once the NIC finds the correct channel, it begins talking
to the Access Point. As long as all of the security settings on the client and
AP match, communications across the AP can begin and the user can participate
as part of the network.
Bandwidth on an 802.11b network is limited to 11Mb per access point. This 11Mb
is divided among all users on that access point. If ten people access the same
AP, communication to the wired world will be limited to approximately the equivalent
of a decent DSL line. Because the 802.11b standard does not contain any specifications
for load balancing across multiple access points, devices that strictly adhere
to the standard have no answer if you find your network becoming over populated.
The only way to manage this is to add another AP in the same area, but with
a different network name and radio channel, effectively having more than one
separate network (up to a maximum of three), in the exact same area. Some wireless
vendors have proprietary solutions for load balancing, but discussing these
initiatives falls outside the scope of this article. Interested readers should
look into individual companies' propaganda documentation before they deploy
their wireless network if they feel they will need these services.
Basic security: 802.11b's nod towards
private communications and its weaknesses
From its inception the 802.11b standard was not meant to contain a comprehensive
set of enterprise level security tools. Still, there are some basic security
measures included in the standard which can be employed to help make a network
more secure. With each security feature, the potential for making the network
either more secure or more open to attack exists.
Service Set Identifier
The Service Set Identifier (SSID) is meant to differentiate networks from one
another. Initially, AP's come set to a default depending on the manufacturer.
For example, all Linksys AP's are set to the network name of 'linksys', while
Cisco AP's are initially set to 'tsunami'. Because these default SSID's are
so well known, not changing it makes your network much easier to detect. Another
common mistake regarding the SSID is setting it to something meaningful such
as the AP's location or department, or setting them to something easily guessable.
The SSID should be created with the same rules as any strong password (long,
non-meaningful strings of characters including letters, numbers and symbols).
By default the Access Point broadcasts the SSID every few seconds in what are
known as 'Beacon Frames'. While this makes it easy for authorized users to find
the correct network, it also makes it easy for unauthorized users to find the
network name. This feature is what allows most wireless network detection software
to find networks without having the SSID upfront.
SSID settings on your network should be considered the first level security,
and should be treated as such. In its standards-adherent state, SSID may not
offer any protection to who gains access to your network, but configuring your
SSID to something not easily guessable can make it harder for intruders to know
what exactly they are looking at.
Before any other communications take place between a wireless client and an
AP, they must first begin a dialogue. This process is known as associating.
When 802.11b was designed, the IEEE added a feature to allow networks to require
authentication immediately after a device associates, before it attempts communications
across the AP--supposedly providing an extra layer of keyed security. This feature
can be set to either shared key authentication or open authentication. The simplest
and default setting for this feature is open authentication. Using open authentication
allows anyone to begin a conversation with the access point, and provides no
security whatsoever on who can talk to the AP. When set to shared key mode the
client begins by sending an association request to the AP. The AP then responds
with a string of challenge text, which the client then encrypts using the WEP
key (see below) and returns. If the text is encrypted correctly, the client
is allowed to communicate with the AP, and move on to the next layer of security.
The weakness with this particular method is in the clear text transmission
of the challenge string. By passively listening to the conversation, an attacker
can obtain two of the three variables in the authentication equation; the clear
text challenge string and what the challenge string looks like after it has
been encrypted. By plugging these values into the RC4 equations, the attacker
can easily solve for the shared authentication key. Furthermore, because the
same keys are used for shared key authentication and WEP, when you use shared
key authentication and it is compromised you have had your WEP keys compromised
as well, meaning that an intruder could then decipher all traffic to and from
the AP point and its clients. Ironically, the most secure setting of this feature
is 'open authentication', allowing anyone to associate with your access points,
and relying on other methods to handle security. While removing a layer of security
may seem contradictory to making your network more secure, this particular layer
is flawed and hurts far more than it helps.
Wired Equivalent Privacy (WEP) was intended to give wireless users security
equivalent to being on a wired network. With WEP turned on each packet transmitted
from one radio to another is first encrypted by taking the packet's data payload
and a secret 40 bit number and passing them through a shredding machine called
RC4. The resulting encrypted packet is then transmitted across the air waves.
When the receiving station hears the packet it then uses the same 40 bit number
to pass the encrypted data through RC4 backwards, resulting in the host receiving
good, useable data.
There are several problems with WEP in its 802.11b ratified form that keep
it from begin the definitive answer to wireless security. The main problem with
WEP is that the RC4 stream cipher used to encrypt the data has been proven insecure.
There are multiple attacks on the RC4 cipher revolving around a technological
weakness in its encryption mechanism. RC4 combines the 40 bit WEP key with a
24 bit random number known as an Initialization Vector (IV) to encrypt the data.
The packet sent over the airwaves contains the IV followed by the encrypted
data. Unlike shared key authentication, the attacker does not know the unencrypted
text beforehand, so he does not have enough variables to immediately figure
out the WEP key.
The first attack uses a simple numerical limitation of the IV to figure out
the WEP key. Because the IV is only 24 bits long, there are only so many permutations
of the IV for RC4 to pick from. Mathematically there are only 16,777,216 (2^24)
possible values for the IV. While that may seem like a lot, it takes so many
packets to transmit useful data that 16 million packets can go by in hours on
a heavily used network. Eventually the RC4 mechanism starts picking the same
IVs over and over. By passively listening to the encrypted traffic, and picking
the repeating IVs out of the data stream, an attacker can begin to infer what
the WEP key is. Eventually enough data can be gathered that the WEP key is cracked.
The second attack based on the IV centers around what are known as Weak IVs.
As discussed above, the encryption of a piece of data begins with RC4 choosing
a random 24 bit number, and then combining that number with the WEP key to encrypt
the data. Some numbers in the range of 0 to 16777215 do not work well in the
RC4 encryption mechanism. When the RC4 algorithm picks out these 'Weak IVs',
the resulting encrypted packet can be run through mathematical functions to
reveal part of the WEP key. By capturing massive numbers of packets, an attacker
can pick out enough Weak IVs to reveal the WEP key and compromise the network's
Another problem with WEP is key management. When you enable WEP according to
the 802.11b standard, you have to visit each wireless device you will use and
type in the proper WEP key. While this can initially be rolled into new client
setup, if your key is compromised for any reason (employee leaves, someone gave
it out over the phone, or you detected that someone guessed it) you have to
change that key, or lose all security. This is not a big deal with only a few
users, but what if you have an entire university campus or hundreds of corporate
users on your network? In those scenarios changing the WEP key quickly becomes
a logistical nightmare.
Above and beyond the standard:
What else is available to secure my network?
One of the first attempts to address wireless network insecurity was developed
by Lucent for their Orinoco WaveLAN brand of equipment. They developed what
they called the 'Closed Network'. According to Lucent, their closed networks
differed from standard 802.11b networks by having the AP's simply not periodically
broadcast the SSID beacon frames. Recognizing that this feature turned the SSID
from simply a way to identify networks into a legitimate security tool, many
enterprise wireless AP vendors followed suit. Despite the fact that the SSID
is still transmitted through the air in clear text, turning off the beacon frames
means that finding other people's wireless networks requires a little more network
savvy than simply pressing the Scan button repeatedly on your wireless client.
Even though turning this broadcast SSID feature off requires more management
time (the user has to type the SSID into the client instead of clicking the
Scan button), because most modern clients for 802.11b networks allow the users
to manually type in the SSID, this is a fairly easy security measure to implement.
It requires no special software to be loaded at the client other than what is
already there, and only a little reconfiguration of the existing wireless clients
is necessary. To avoid management nightmares in the future, your SSID should
never change. This means that it will be compromised at some point, but there
are other security measures to handle the intruders who manage to gain your
SSID. While not a deterrent to serious, planned attacks on your wireless infrastructure,
turning off the SSID broadcast can help defend your network against the casual
war driver, preventing a large majority of attacks before they start.
Lucent also pioneered 128 bit WEP (they call it WEP
Plus) . This extends the WEP key from 40 bits to 104 bits for added security.
Using today's computing horsepower, this feature increases the time it takes
to brute force crack a WEP key from a few days to approximately 20 weeks. While
it seems like a good idea, there are several key areas where this security initiative
falls short of the definitive security solution. On top of the management problems
using static WEP keys there are two serious issues that plague 128 bit WEP.
First of all, the attacks on WEP have nothing whatsoever to do with the key
length itself. Whether you are using a 64 bit or 128 bit WEP you still have
the exact same 24 bit IV which is the source of the weaknesses. This increases
security absolutely zero for today's wireless implementations because no one
bothers to brute force a WEP key when it is so easy to use one of the other
attacks. Also, because this feature falls outside the standard for 802.11b,
not all cards support it, and for those that do, the added burden of processing
twice the encryption per frame can potentially drastically shrink useable bandwidth.
It is true, though, that tomorrow's computers will have the capacity to crack
a 40 bit key in a matter of minutes or seconds. Because of this, a move to 104
bit WEP keys will be a good idea in the future as long as you use other technologies
to address WEP's shortcomings.
Broadcast key rotation is another method intended
to help counter the flaws in WEP. In the 802.11b specification, there are two
WEP keys. One key is meant to encrypt the individual stream of data between
the AP and the wireless client, and the other is meant to encrypt broadcast
transmissions such as DHCP or ARP requests. Because this key is usually the
exact same as the static WEP key, this was never mentioned until Cisco introduced
the idea of dynamically generated, short lived broadcast WEP keys in an early
revision of its AP firmware. Although it was introduced by Cisco, other AP vendors
have come to embrace this as a means to make the wireless network more secure.
Like turning off the AP beacon frames, this feature requires no extra installation,
and is easy to implement. The administrator sets a specific time, in seconds,
on the AP, and every time the counter is up, the AP broadcasts a new broadcast
WEP key, encrypting it with the old. Because these timeouts are usually set
to ten minutes or so, there's not enough time for attackers to intercept the
amount of packets needed to crack the key. While effective, this feature is
only meant to secure broadcast communications, and must only be part of the
overall security scheme.
MAC address filtering is another way that people
have tried to secure their networks over and above the 802.11b standards. The
MAC address of a network card is a 12 digit hexadecimal number that is unique
to each and every network card in the world. Because each card has its own individual
address, if you limit access to the AP to only those MAC addresses of authorized
devices, you can easily shut out everyone who should not be on your network.
Or at least that is the idea. There are several problems with MAC address filtering
that prevent it from offering a totally secure network.
The first problem with MAC address filtering is the management aspect of it.
When turned on, the wireless LAN administrator must keep a database of every
device allowed to access the network. This database must be kept either on each
AP individually, or on a special RADIUS server that each AP looks at. Any time
a device is added, lost, stolen, or changed in any way the WLAN administrator
must update the database(s) of allowed devices. While this is not too terrible
of a burden for ten or even twenty people, in an enterprise network with hundreds
or thousands of devices this is simply not a practical solution. It would require
a full time employee just to keep up with the database changes.
The management nightmare might be considered a worthy price if MAC address
filtering were 100% secure. That, however, is not the case. MAC address filtering
is easy to defeat for someone who has the right tools. Using a wireless sniffer
an attacker can watch the wireless traffic of your network and easily pick MAC
addresses of valid users out of the frames floating through the air, even if
they are encrypted. Then they can simply modify the MAC address their OS sends
out to mimic one of the stolen ones and your security is beaten. Once your MAC
address security is compromised you are still forced to deal with the management
nightmare while gaining none of the benefits.
For smaller wireless implementations MAC address filtering might be considered
as a viable option if nothing else is available, since the management aspect
is not as difficult to deal with. For larger wireless networks, however, MAC
address filtering simply does not offer the level of security that might justify
its enormous management overhead.
Alternative Encryption Schemes: Targeting
the weaknesses in static WEP
For a long time, most people considered VPN
as the definitive solution for handling wireless security. The idea behind this
security measure is to consider the wireless network equivalent to the Internet.
Companies use a firewall device at the point where their network connects to
the Internet, and only allow users in via an encrypted, secure channel. The
same idea applies to their wireless networks. Using the VPN solution, all wireless
network traffic is segmented behind a firewall. Each client is then configured
with a VPN client and tunneled over the wireless network to a VPN concentrator
on the wired network. This security setup uses a secure, proven technology to
prevent outsiders from gaining access to your wired network. Also it reuses
a technology many companies have already deployed, so there is very little added
expense in those cases.
There are a few weaknesses with this setup however. The process of gaining
legitimate access to a wireless network begins with the client booting up and
getting an IP. Once the client has an IP, through either static addresses or
more commonly DHCP, the client can then negotiate a tunnel over the wireless
network to begin its communications. Illegitimate users go through the exact
same process, except that they do not gain direct access to the wired network.
Because the attacker has been given an IP, though, there is nothing preventing
him from communicating with other wireless clients on their side of the firewall.
By communicating with other wireless clients the attacker has the possibility
of breaking into an authorized user and gaining access through their client.
It is possible to prevent this by allowing the wireless user to only communicate
with the VPN concentrator point, but that feature is available in only some
of the VPN clients out there. The added burden of having to lock down each client
as well as the wireless-to-wired network connection makes this a more difficult
situation to implement than it might seem on the surface.
Even if you do manage to lock down the clients on your network and prevent
them from accessing the wired network at all, you are still handing out IP's
to anyone who asks. This means that it is possible for unauthorized wireless
users to piggyback your wireless connection to communicate to other non-VPN
clients on the same network segment. This means that Joe Cracker and Suzy Cracker
can communicate with each other across your campus, but not your other internal
networks. Because network bandwidth is shared on a wireless connection and there
is only currently 11Mbits to go around, this type of piggybacking can cause
extreme performance hits on your wireless network, and deny legitimate users
the bandwidth they need for their applications.
VPN solutions can be an effective way of preventing unauthorized users from
gaining entry to your wired network as long as they are implemented correctly.
There are other concerns though which might make a wireless administrator think
twice about implementing it.
802.1X is a standard which was ratified in early April
(2002) by the IEEE regarding port level security. Initially it was intended
to standardize security on wired network ports, but it was found to be very
much applicable to wireless networking as well. This new layer 2 (MAC address
layer) security protocol exists at the authentication stage of the security
process. Using 802.1X, when a device requests access to the AP, the AP demands
a set of credentials. The user then supplies some form of credentials which
the AP then forwards to a standard RADIUS server for authentication and authorization.
RADIUS stands for Remote Authentication Dial-In User Service, and is commonly
used to authenticate dial-in users. The exact method of supplying credentials
is defined in the 802.1X standard EAP (Extensible Authentication Protocol).
EAP is an authentication "bucket" that allows developers to create
their own methods of passing credentials and is the main security measure in
802.1X. There are four commonly used EAP methods in use today. They are EAP-MD5,
EAP-Cisco Wireless (also known as LEAP), EAP-TLS, and EAP-TTLS.
- EAP-MD5 relies on an MD5 hash of a username
and password to pass credentials to the RADIUS server. EAP-MD5 offers no key
management or dynamic key generation, requiring the use of static WEP keys.
This prevents unauthorized users from accessing your wireless network directly,
but offers nothing over the proven insecure static WEP encryption scheme.
Attackers can still sniff your airborne traffic and decrypt the WEP key. Once
the key is decrypted they can easily watch all data running over your wireless
network. Another flaw in EAP-MD5 is that it offers no way for the wireless
client to verify the AP. Because of this, a determined attacker could plant
a rogue AP on your network and fool your wireless clients into thinking that
it is a secure communications point. Because it offers no other features over
the standard 802.1X, EAP-MD5 is considered the least secure of all the common
- EAP-Cisco Wireless, or LEAP, is a standard
developed by Cisco in conjunction with the 802.1X standard, and is the basis
for much of the ratified version of EAP. Like EAP-MD5, LEAP accepts a username
and password from the wireless device and transmits them to the RADIUS server
for authentication. What sets LEAP apart from EAP-MD5 are the extra features
it adds over what is explicitly called for within the 802.1X/EAP specification.
When LEAP authenticates the user, one time WEP keys are dynamically generated
for that session. This means that every user on your wireless network is using
a different WEP key that no one knows, not even the user. Also, you can combine
this with the session timeout feature of RADIUS to have the user re-login
every few minutes (handled behind the scenes, the user doesn't have to type
anything in) and create new dynamic WEP keys that change every few minutes.
Setting your RADIUS server up this way effectively nullifies current attacks
on WEP because the individual keys are not used long enough for an attacker
to crack them. LEAP also stipulates mutual authentication of client-to-AP
and AP-to-client above what 802.1X strictly calls for. This prevents a hacker
from inserting a rogue AP into your network and fooling your wireless clients
into thinking it is a secure connection.
There are presently two drawbacks to running LEAP. First, the mechanism of
passing the logon credentials uses MS-CHAPv1 for both the client and AP authentication.
This version of MS-CHAP has known vulnerabilities, and can be compromised
by a determined enough attacker with the right tools. There are no known instances
of LEAP being compromised by this, but MS-CHAPv1 is a weakness. The second
drawback in implementing LEAP is that LEAP currently only works on Cisco end-to-end
networks, because only Cisco has added LEAP capabilities to their wireless
client. Other vendors, however, are working to add LEAP to their wireless
client software to allow non-Cisco network cards in established LEAP implementations.
- EAP-TLS was developed by Microsoft, and
is outlined in RFC 2716
. Instead of username/password combinations, EAP-TLS uses X.509
certificates to handle authentication. EAP-TLS relies on Transport Layer
Security, the IETF's attempt at standardizing the Secure Sockets Layer (SSL)
to pass PKI information in the EAP bucket. Like LEAP, EAP-TLS offers dynamic
one-time WEP key generation, and authenticates the AP to the wireless client
as well as the client to the AP. EAP-TLS runs on any platform that has a client
written for it. Currently clients for EAP-TLS are implemented through several
vendors for Linux and all flavors of Windows (except CE).
The first hindrance to implementing EAP-TLS is in the burden of PKI. If your
organization does not already have a PKI in place handing out certificates
to trusted parties there is a potentially steep learning curve in figuring
out exactly what PKI is and how to implement it. Once you get the PKI services
installed and implemented, handing out certificates is not too much of a burden.
The main impedance to EAP-TLS right now is the general confusion surrounding
exactly how to do it. The only way to currently easily deploy EAP-TLS is if
you are in an Active Directory (AD) using a Microsoft Certificate Server with
wireless clients that only log into the AD, and all your certificates are
published to the user accounts in the AD. Problems crop up when you want to
change any part of that.
If you are using some other directory service such as Open LDAP or NDS, then
you can't publish the certificates to the user accounts, and the RADIUS server
has no standards-based way to tell if the certificate you are passing it is
a valid one for the account you send it. If you want to use some other certificate
server you run into issues between the EAP-TLS standard as written and the
interpretation of the X.509 standard for certificates. There is an optional
field called "Extended Key Usage" that exists in all Microsoft certificates.
This field is used to determine what the certificate is used for. Either mail
signing, code signing, or user authentication. In a Microsoft Certificate
Services certificate, that field always exists and, if you use the certificate
for all purposes it contains every value. If you are using a Verisign issued
certificate for every purpose that optional field doesn't exist at all. Since
EAP-TLS looks for a specific value in that field, if you have a general Verisign
certificate you can't use it. If your wireless client doesn't log into the
Active Directory, then the Certificate Services will not issue it a certificate
See, confusion. Unless your organization can take The Microsoft Way™
document straight from MS and implement it just how they have it, EAP-TLS
should be considered a work in progress, and not quite ready for primetime.
Currently there are vendors working to address these confusing issues, however,
and in the next few months TLS should be ready for the spotlight.
was pioneered by Funk Software as an alternative to EAP-TLS. The AP
still identifies itself to the client with a server certificate, but the users
now send their credentials in username/password form. EAP-TTLS then passes
the credentials in any number of administrator specified challenge-response
mechanisms (PAP, CHAP, MS-CHAPv1, MS-CHAPv2, PAP/Token Card, or EAP). The
only challenges to EAP-TTLS are the slightly less secure than dual certificates
of EAP-TLS, and the upcoming standard developed by Microsoft and Cisco that
works exactly the same way called Protected EAP (PEAP).
To implement 802.1X in your wireless deployment, you have to do some research
and be prepared to mix and match vendors' offerings depending on what EAP protocol
you plan to use. First you have to pick a RADIUS server to handle the credential
verification. Presently there are four different RADIUS servers which can handle
some or all of the EAP standards:
- Microsoft's Internet
Authentication Service (IAS) is part of Windows 2000, and can
authenticate both EAP-TLS and EAP-MD5. If you own a copy of Windows 2000 Server,
you already have this RADIUS server, and can access it through Add/Remove
Programs from the Control Panel.
- Cisco's Access
Control Software (ACS) was developed for both the UNIX and Windows
platforms. It is a full fledged TACACS+ and RADIUS server and, beginning with
version 2.6a, it handles wireless authentication with EAP-Cisco Wireless and
- Funk Software is generally known for their product called
Steel Belted RADIUS. The have a stripped down version of that platform known
as Odyssey which
handles wireless authentication exclusively. Odyssey handles the widest range
of EAP types by supporting all four of the commonly used protocols, EAP-MD5,
EAP-TLS, EAP-Cisco Wireless, and EAP-TTLS.
- AEGIS from
Meetinghouse Data offers a RADIUS server that runs on the
Linux platform and handles EAP-TTLS and EAP-TLS authentication.
- FreeRadius is an open source project
that runs on the Linux platform. FreeRADIUS supports both EAP-MD5 and EAP-TLS.
The second piece needed to implement 802.1X is an AP capable of passing the
authentication messages. Because the AP acts only as a conduit for the authentication
messages, there are no compatibility issues between certain AP's and different
EAP protocols. As long as the EAP protocol fits the standard, then an 802.1X
enabled AP can use it. Generally all enterprise level AP's are either currently
capable of handling 802.1X requests either out of the box or through a firmware
upgrade for existing equipment. If you have a much smaller environment, or just
don't want to spend the money on enterprise class AP's, there are hacks available
for home user level AP's to support 802.1X authentication. [Editor's Note
- You can find a full walkthrough on hacking an Orinoco RG-1100 to accept 802.1X
in the Networking
Matrix. Azariah did an excellent job writing it up, and it's really a bargain
for a secure wireless setup.]
The final piece of the 802.1X puzzle is the client software. Again, depending
on your OS and preferred EAP standard there are several to choose from.
- Cisco writes its ACU client piece to make its adapters work with EAP-Cisco
Wireless on all flavors of Windows, Apple, and Linux.
- Windows XP has a built-in client for EAP-TLS and EAP-MD5. It only works
properly with Microsoft issued certificates though. This client is supposed
to be released for Windows 2000 and CE.NET as well.
- Funk's Odyssey client currently works on all flavors of Windows except CE.
Linux, CE and Apple versions are all due out in the next few of months. The
Odyssey client handles EAP-MD5, EAP-TLS and EAP-TTLS, and will soon offer
EAP-Cisco Wireless support for non-Cisco hardware.
- The AEGIS client from Meetinghouse Data offers EAP-TLS, EAP-TTLS, and EAP-MD5
support for all flavors of Windows (except CE) and Linux.
- Several open source clients are being worked on currently, most notably
the open1X project.
What exactly do I need to do to secure my network right
- If possible, put the wireless network behind its own routed interface so
you can shut it off if necessary.
- Pick a random SSID that gives nothing about your network away.
- Set your AP to 'Closed Network'
- Set the authentication method to 'Open'
- Have your broadcast keys rotate every ten minutes or less
- Use 802.1X for key management and authentication
Look over the available EAP protocols and decide which is right for your
- Set the session to time out every ten minutes or less.
Where is the future of wireless security headed?
Spurred by the insecurities and management issues exposed with WEP as it was
standardized in 802.11b, the IEEE formed Task Force 802.11i to write a good
standard for wireless security. The 802.11i standard is a work in progress,
but enough has been done to figure out what much of it will be. Wireless implementations
are divided into two groups, legacy and new. Legacy networks are those which
were put in place before the .11i standard was ratified, and new networks are
those put in place after it is ratified. Both groups use 802.1X as the means
of handling credential verification, but the encryption method differs. 802.11i
also specifies that only EAP standards which handle dynamic key generation may
To conform to 802.11i legacy networks will be required to use 104 bit WEP,
and also use Temporal Key Integrity Protocol (TKIP, formerly known as WEP2)
and Message Integrity Check (MIC). Both of these technologies were developed
by Cisco as proprietary means of strengthening WEP. Though they are available
today, these are only available on all Cisco networks, and then not on all platforms.
TKIP addresses the IV attacks on WEP by encrypting everything before it is run
through the WEP machine, essentially adding another layer of encryption to the
packet. MIC adds stronger integrity checking than a simple CRC check to prevent
attackers from changing messages after transmission.
According to 802.11i new wireless networks will be the same as legacy, except
they should replace WEP/TKIP with a new encryption scheme called Advanced Encryption
Standard - Operation Cipher Block (AES-OCB). This new encryption standard is
a version of the AES standard recently adopted by the U.S. government as the
replacement for 3DES. AES-OCB is touted as being much stronger than WEP/TKIP.
- "Your 802.11 Wireless
Network Has no Clothes", William A. Arbaugh, Narendar Shankar, Y.C.
Justing Wan. 2001
Mobile Communications: The Insecurity of 802.11", Nikita Borisov,
Ian Goldberg, David Wagner. 2001
in the Key Scheduling Algorithm of RC4", Scott Fluhrer, Itsik Mantin,
Adi Shamir. 2001
LAN Security: A Short History", Matthew Gast. 2002