Welcome to FreeUnix.dyndns.org -> Howto Wifi on Linux

If security of your wireless lan is important to you, for example because you're storing sensitive information, and you don't like the idea that someone might capture this precious data, or you are simply somewhat paranoid, then you will want to proactively safeguard your network against security attacks.

WEP (Wired Equivalent Privacy) is IEEE 802.11's optional encryption standard implemented in the MAC Layer that most radio network interface card (NIC) and access point vendors support. When deploying a wireless LAN, be sure to fully understand the ability of WEP to improve security.

WEP in action

When you activate WEP, the NIC encrypts the payload (frame body and CRC) of each 802.11 frame before transmission using an RC4 stream cipher provided by RSA Security. The receiving station, such as an access point or another wireless NIC, performs decryption upon arrival of the frame. As a result, 802.11 WEP only encrypts data between 802.11 stations. Once the frame enters the wired side of the network, such as between access points, WEP no longer applies.

As part of the encryption process, WEP prepares a keyschedule ("seed") by concatenating the shared secret key (the so-called WEP-key) supplied by the user of the sending station with a random-generated 24-bit initialization vector (IV). The IV lengthens the life of the secret key because the station can change the IV for each frame transmission. WEP inputs the resulting "seed" into a pseudo-random number generator that produces a keystream equal to the length of the frame's payload plus a 32-bit integrity check value (ICV).

The ICV is a check sum that the receiving station eventually recalculates and compares to the one sent by the sending station to determine whether the transmitted data underwent any form of tampering while intransient. If the receiving station calculates an ICV that doesn't match the one found in the frame, then the receiving station can reject the frame or flag the user.

WEP specifies a shared secret 40 or 64-bit key (40 + 24 from the IV) to encrypt and decrypt the data. WEP can also use 128 bit keys (actually 104 + 24 from the IV, also know as "WEP2"). With WEP, the receiving station must use the same key for decryption. Each radio NIC and access point, therefore, must be manually configured with the same key.

Before transmission takes place, WEP combines the keystream with the payload/ICV through a bitwise XOR process, which produces ciphertext (encrypted data). WEP includes the IV in the clear (unencrypted) within the first few bytes of the frame body. The receiving station uses this IV along with the shared secret key supplied by the user of the receiving station to decrypt the payload portion of the frame body. In most cases the sending station will use a different IV for each frame (this is not required by the 802.11 standard).
When transmitting messages having a common beginning, such as the "FROM" address in an e-mail, the beginning of each encrypted payload will be equivalent when using the same key. After encrypting the data, the beginnings of these frames would be the same, offering a pattern that can aid hackers in cracking the encryption algorithm. Since the IV is different for most frames, WEP guards against this type of attack. The frequent changing of IVs also improves the ability of WEP to safeguard against someone compromising the data.

But then, what's wrong with WEP?

WEP has been part of the 802.11 standard since initial ratification in September 1999. At that time, the 802.11 committee was aware of some WEP limitations; however, WEP was the best choice to ensure efficient implementations worldwide. Nevertheless, WEP has undergone much scrutiny and criticism over the past couple years. Sometimes, it is even referred to as "Worthless Encryption Protocol".

WEP is vulnerable because of relatively short IVs (only 24 bits) and keys that remain static. The issues with WEP don't really have much to do with the RC4 encryption algorithm. With only 24 bits, WEP eventually uses the same IV for different data packets. For a large busy network, this reoccurrence of IVs can happen within an hour or so. This results in the transmission of frames having keystreams that are too similar. If a hacker collects enough frames based on the same IV, the individual can determine the shared values among them, i.e., the keystream or the shared secret key. This of course leads to the hacker decrypting any of the 802.11 frames.

The static nature of the shared secret keys emphasizes this problem. 802.11 doesn't provide any functions that support the exchange of keys among stations. As a result, system administrators and users generally use the same keys for weeks, months, and even years. This gives crackers plenty of time to monitor and hack into WEP-enabled networks. Some vendors deploy dynamic key distribution solutions based on 802.1X, which definitely improves the security of wireless LANs.

When WEP makes sense to employ

Despite the flaws, WEP is still better than nothing, and you should enable WEP as a minimum level of security. Many people have taken to the streets to discover wireless LANs in neighborhoods, business areas, and schools using protocol analyzers. Most of these people are capable of detecting wireless LANs where WEP is not in use and then use a laptop to gain access to resources located on the associated network. By at least activating WEP, however, you significantly minimize this from happening, especially if you have a home or small business network. WEP does a good job of keeping most people out, at least those that are honest. Beware, though, there are people around who can exploit the weaknesses of WEP and access WEP-enabled networks, especially those with high utilization. But if that ever happens to you, you probably also have other problems to deal with.

Using WEP on a Slackware system

WEP keys are defined in /etc/rc.d/rc.wireless.conf for PCI adapters or in /etc/pcmcia/wireless.opts for PCMCIA (but NOT Cardbus) adapters. Enabling WEP is very simple :

in the respective config file, define your WEP key(s), as in the next example :

. . .
 #64(40) bit key
 KEY="restricted B2EAC0F64D"          
. . .

40(64)-bit WEP takes a 10-char string of hex characters, for 104(128)-bit WEP you need 26 hex characters. It is possible to define up to 4 keys.

If you want to use multiple WEP keys, use the following example:

. . .
 # define multiple 64 bit keys and use key number 3
 KEY="A4DC81BD2E [1] key F3CA42FC6B [2] key 38BA74E75F [3] key [3]"
. . .

in your wireless acces point, enable WEP end supply it exactly the same WEP key(s) as defined in the config file. Your AP will most likely need to reboot after these changes. When the AP is up again, reassociate your wifi adapter with the AP. If nothing went wrong, you can check the use of WEP, as root, with iwconfig :

eth1      IEEE 802.11b/g ESSID:"wbr254"  Nickname:"lappy"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:04:2F:26:5D:3E   
          Bit Rate=54 Mb/s   Tx-Power:32 dBm   
          RTS thr=2347 B   Fragment thr=2346 B   
          Encryption key:B2EA-C036-D4   Security mode:restricted
          Power Management:off
          Link Quality:100/100  Signal level:-28 dBm  Noise level:-256 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:650  Invalid misc:1963   Missed beacon:0

You can also get specific information about the available keys by using iwlist, as root :

[root@lappy ~]# iwlist eth1 key 
eth1      2 key sizes : 40, 104bits
          4 keys available :
                [1]: B2EA-C036-D4 (40 bits)
                [2]: off
                [3]: off
                [4]: off
          Current Transmit Key: [1]
          Security mode:restricted

The original security mechanism of IEEE 802.11 standard was not designed to be strong and has proved to be insufficient for most networks that require some kind of strong security. Task group I (Security) of IEEE 802.11 working group has worked to address the flaws of the base standard and has in practice completed its work in May 2004. The IEEE 802.11i amendment to the IEEE 802.11 standard was approved in June 2004 and this amendment is likely to be published in July 2004.

The Wi-Fi Alliance used a draft version of the IEEE 802.11i work (draft 3.0) to define a subset of the security enhancements that can be implemented with existing wlan hardware. This is called Wi-Fi Protected Access (WPA). This has now become a mandatory component of interoperability testing and certification done by Wi-Fi Alliance. Wi-Fi has information about WPA at its web site.

The IEEE 802.11 standard defined the Wired Equivalent Privacy (WEP) algorithm for protecting wireless networks. WEP uses RC4 with 40-bit keys, 24-bit initialization vector (IV), and CRC32 to protect against packet forgery. All these choice have proved to be insufficient: key space is too small against current attacks, RC4 key scheduling is insufficient (beginning of the pseudorandom stream should be skipped), IV space is too small and IV reuse makes attacks easier, there is no replay protection, and non-keyed authentication does not protect against bit flipping packet data.

WPA is an intermediate solution for the security issues. It uses Temporal Key Integrity Protocol (TKIP) to replace WEP. TKIP is a compromise on strong security and possibility to use existing hardware. It still uses RC4 for the encryption like WEP, but with per-packet RC4 keys. In addition, it implements replay protection, keyed packet authentication mechanism (Michael MIC). Keys can be managed using two different mechanisms.

WPA can either use an external authentication server (e.g., RADIUS) and EAP just like IEEE 802.1X is using or pre-shared keys, without need for additional servers. Wi-Fi calls these "WPA-Enterprise" (WPA-EAP) and "WPA-Personal" (WPA-PSK), respectively. Home users will mostly use WPA-PSK. Both mechanisms will generate a master session key for the Authenticator (AP) and Supplicant (client station).

WPA implements a new key handshake (4-Way Handshake and Group Key Handshake) for generating and exchanging data encryption keys between the Authenticator and Supplicant. This handshake is also used to verify that both Authenticator and Supplicant know the master session key. These handshakes are identical regardless of the selected key management mechanism (only the method for generating master session key changes).

Using WPA on a Slackware system

To use WPA on Linux, you need to get wpa_supplicant. The latest CVS or later releases may work better. Unpack the tarbal and in the wpa_supplicant directory, create a .config file so it contains driver support for the driver used by your wifi adapter. For ndiswrapper; i.e., add the following line to the .config file :

CONFIG_DRIVER_NDISWRAPPER=y

Now compile it with "make" and copy wpa_supplicant, wpa_passphrase and wpa_cli to some place that is in your $PATH, e.g., /usr/local/bin. Now you need to create the wpa_supplicant configuration , /etc/wpa_supplicant.conf. A simple configuration as shown here, should suffice :

ctrl_interface=/var/run/wpa_supplicant

# Only WPA-PSK is used. Any valid cipher combination is accepted.
network={
        ssid="YourSSID"
        proto=WPA
        key_mgmt=WPA-PSK
        psk="ThisIsaTopSecretPassPhrase"
}

Note that the psk given above can be a plain text (ASCII) passphrase that is used on the AP or 64 hex digits that can be generated with wpa_passphrase from the same ASCII pass phrase. For simplicity, go with ASCII pass phrase.

Configure your AP to use WPA-PSK and supply it the same psk as used in the config file. Your AP will most likely need to reboot after these changes. Next, you need to configure Slackware so that it uses wpa_supplicant. In /etc/rc.d/rc.wirelesss.conf, add this :

WPA ="y"

Then, in /etc/rc.d/rc.wirelesss, add the next few lines at the end :

if [ "$WPA" = "y" -a -x /usr/local/bin/wpa_supplicant ]; then
  /usr/local/bin/wpa_supplicant -Bw -c /etc/wpa_supplicant.conf -i $INTERFACE -D ndiswrapper
fi

It is not clear to me if the calls to iwconfig in rc.wireless are still needed to setup the adapter when using wpa_supplicant. Disabling them didn't seem to make any difference. I did notice however that the card often refused to associate at boot. This could be solved by calling the dhcp client after issuing the next command :

/usr/local/bin/wpa_cli reassociate

I guess that during startup, the dhcp client (dhcpcd) is started too fast after wpa_supplicant. Using a bigger timeout value for dhcpcd or even using a "sleep 4" before starting dhcpcd did not solve the problem.
Anyway, afterwards, you can check the connection status of your adapter with wpa_cli :

[root@lappy ~]# /usr/local/bin/wpa_cli status
Selected interface 'eth1'
bssid=00:03:5f:27:7d:4f
ssid=mywlan
pairwise_cipher=TKIP
group_cipher=TKIP
key_mgmt=WPA-PSK
wpa_state=COMPLETED

Output of iwconfig then looks like this:

eth1  IEEE 802.11b  ESSID:"mywlan"  Nickname:"lappy"
      Mode:Managed  Frequency:2.412 GHz  Access Point: 00:03:5F:27:7D:4F   
      Bit Rate=54 Mb/s   Tx-Power:32 dBm   
      RTS thr=2347 B   Fragment thr=2346 B   
      Encryption key:9DA3-61EC-022F-CF8D-EE85-D23E-4580-1EDA-56A9-A9D1-6999-93F9-0E41-BEEA-5C88-686F
      Power Management:off
      Link Quality:100/100  Signal level:-25 dBm  Noise level:-256 dBm
      Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
      Tx excessive retries:748  Invalid misc:1896   Missed beacon:0

Note that you can also use wpa_supplicant to set WEP keys if you don't want/need to use WPA. This way, you can specify bssid in each network block so you can set different WEP keys for different APs automatically. Don't forget to check the extensive README file provided with wpa_supplicant for more info.