LAN01 - WPA Security with
Wireless LAN Monitor

Play safe with your private Wireless LAN

Christian Langanke

WLAN Project of netlabs.org

Overview

• Wireless LAN Monitor V3.00 - Features/Bugfixes
• How WEP works, Why WEP is not secure, WEP attacks
• How WPA/WPA2 works,
  Where WPA is more/not secure
• WPA for OS/2 / eComStation
• Why securing private Wireless LANs
• Public Wireless LANs
• Research Sources
• Demo, Q & A

WLAN Monitor V3.00 - Features

• WPA/WPA2 Encryption Support
  • for GenMac driven devices only!
  • requires GenMac V2.00
• configuration of MTU for manual TCP/IP configuration
  • allows configuration for DSL-optimized MTU of 1492
• TCP/IP properties
  • new property Trigger WAN connection on connect
    • will open a dial-up/DSL connection after the TCP/IP connection for the WLAN is established (sends a DNS request)
  • new value Automatic for property Resolve address range conflicts

WLAN Monitor V3.00 - Bugfixes

• Implemented route handling for switching between a wireless and a cabled connection to the same network
  • deletes any route being set for the obsolete interface
  • deletes the obsolete interface
  • reapplies the previously deleted routes for the new interface

• Fixed error in script handling
  • script call on connect was called before DHCP request had completely configured the WLAN TCP/IP interface

• Reworked signal strength calculation for GenMac driven devices

How WEP works

• WEP (Wired Equivalent Privacy) is defined in IEEE 802.11 of 1999
• Encryption by a RC4 generator
  • uses static keys of 40 or 104 bits and
  • a random initialization vector (IV) of 24 bits
• Shared Key Authentication uses the static part of the key (40 or 104 bits)

WEP encryption scheme

• WEP encrypts a network frame as follows:
  • calculates a bitmask from the static key by the RC4 generator, using the 24-bit initialization vector
  • performs a XOR operation on the data with the bitmask
    
    Source: wikipedia.org
  • appends a CRC32 value to the data
  • sends the encrypted data and the IV in clear text to the partner

Why WEP is not secure (1/2)

• the Shared Key Authentication allows cracking of the key and therefore should be disabled
  • choose Open System to disable authentication instead!
• the CRC32 method cannot ensure integrity of encrypted data
  • modified packets can be send to the AP without being discovered/rejected

Why WEP is not secure (2/2)

• RC4 is absolutely safe only if each IV is used only once, but
  • in a WLAN with 50% probability the same IV will repeat after 5000 packets
  • 24 bit width of the IV is insufficient to effectively prevent repetition
• due to the nature of the RC4 algorithm certain IVs are weak
  • when enough packets encrypted with the same weak IV are available, the WEP key can be determined
• packets can be spoofed, if the bitmask can be guessed
  • the key is not required for this, as the bitmask is sufficient to perform the XOR operation

Passive WEP attacks

• Collect packets with the same weak IV to determine the WEP key
  • depends on the amount of traffic generated in the WLAN with the same key and IV
  • Time required for cracking: from several hours to weeks

• Perform an optimized dictionary attack to determine the WEP key
  • Time required for complete dictionary test of 2 Mio words: one hour
  • Succeeds on weak ASCII keys (passwords) only, will fail on random hex keys
  • Approx. success rate: 20%

Active WEP attacks (1/2)

• Resend slightly modified packets to the AP and analyze the response
  • allows to decrypt the packet after enough retries
  • attack can be optimized by modifiying the IV (KoreK attack)
  • Time required for cracking: less than one hour

• Resend one valid, encrypted ARP packet to the AP many times, enforcing responses of the AP
  • dramatically recudes the amount of time required for a passive attak (collection of packets with the same weak IV)
  • Time required for cracking: five to ten minutes

Active WEP attacks (2/2)

• modify an encrypted frame so that it is send by the AP unencrypted to the attacker via Internet
  • one packet of any client in the attacked WLAN needs to be decrypted so far that the target IP address can be modified
  • the packet is sent over the AP, so unencrypted, to the attacker via Internet as many times as required to determine the WEP key
  • Time required for cracking: less than one minute

Summary on WEP weaknesses

• RC4 can be attacked (static keys, weak IVs)
• modified packets (with a properly mocified CRC32 value) are accepted
• replay attacks are possible

How WPA/WPA2 works (1/3)

• WPA/WPA2 is defined in IEEE 802.11i of 2004
• uses better encryption with a 128 bit key and 48 bit IV
  • WPA: RC4 stream cipher (same as WEP ...!)
  • WPA2: CCMP block cipher based on AES
    • AES is successor to DES and 3DES
    • extremely safe and fast
    • used in SSH, IPsec, PGP/GnuPG, Skype
• the MIC (Message Integrity Code) method replaces the CRC32 method and prevents from replay attacks

How WPA/WPA2 works (2/3)

• WPA performs first authentication using an initial key

• for SOHO solutions: key calculated out of a static pre-shared key (PSK)
  • passphrase must be min. 8 charcters, max. 63 characters long

• for enterprise solutions: key is provided per user by a 802.1x authentication server
  • widely used solution: Radius Server
  • authentication servers are attached to WPA by the Extensible Authentication Protocol (EAP)

How WPA/WPA2 works (3/3)

• WPA periodically exchanges the key between the authenticator (AP) and the supplicant (client), using the Temporal Key Integrity Protocol
• the supplicant on the client side can be implemented by
  1. the firmware of the Wireless LAN device
  2. the device driver for the Wireless LAN device
  3. a separate process grabbing the frames of the key interchange protocol
     • requires interface to the NDIS driver
     • Example: Linux WPA supplicant of Jouni Malinen

Where WPA is more/not secure

• WPA is safer than WEP
  • collecting encrypted frames useless due to rekeying
  • WPA (using RC4 like WEP) may currently be safe in combination with rekeying
  • WPA2 encryption is safe due to CCMP/AES cipher
  • no replay attack possible due to MIC method instead of CRC32
• WPA can still be attacked when using the PSK authentication, weak passphrases allow a dictionary attack.
  Recommendations:
  • do not use a single word as a passphrase, better a long (nonsense) sentence
  • use as many of the 63 characters as possible
  • where possible, use a free Radius implementation instead
    Several options are available, even as firmware for DSL routers.

WPA for OS/2 / eComStation

• Wireless LAN Monitor requires/uses
  • an OS/2 / eComStation port of the WPA supplicant
    • first port by Willibald Meyer, port now maintained by netlabs.org
  • V2.00 of the GenMac driver of Willibald Meyer
  • the Innotek LIBC 5.1 runtime, already coming with eComStation V1.2 or better
  • See section Requirements of the online help of Wireless LAN Monitor for details
• the WPA supplicant
  • is loaded on first initialization of a WPA encrypted connection
  • executes as an invisible, separate process in the background
  • remains in memory and running, to keep the connection working, when Wireless LAN Monitor is stopped (standalone or e/xCenter)

Why securing private Wireless LANs

• private hotspot provider is responsible for illegal misuse by others over his internet access point
  • downloads of copyrighted music or movies
  • download of illegal contents
• private data in your LAN can be captured
  • passwords and PINs for internet banking
  • other private or business data
• trojans and viruses can be placed on your system

• SECURE YOUR WIRELESS LAN!
  • use WPA encryption where available
  • use WEP encryption where WPA is not available
  • Never run your private WLAN unencrypted

Public Wireless LANs (1/2)

• always remember: everybody can read your internet/WLAN traffic !!!
• stop all (or better never start) network services
  • the Internet Super Deamon (INETD),web servers, telnet deamon, FTP deamon
  • File and Print Client (using NetBIOS or NetBIOS over TCP/IP)
• a safe service could be started on your system, like e.g. OpenSSH and VPN server, where
  • the authentication data is not transferred in clear text
  • all further traffic is encrypted as well

Public Wireless LANs (2/2)

• always use only SSL encrypted web pages (https instead of http) when loggin in to a web frontend providing personal access
  • mail frontend, internet banking, ...
• use SSL secured connection for fetching mail
  • configure your mail program accordingly
  • SSL connection must be supported by your provider
  • if no SSL secured mail fetch possible:
    better use SSL secured web frontend!
• use the firewall of your OS/2 (MCP) or eComStation
  • drawback: requires detailed knowledge about how to setup firewall rules
  • Zampa GUI (available from hobbes) helps writing the rules, but does not come with prepared rules

Research Sources

• See wikipedia.org for the following keywords
  • WEP
  • RC4
  • WPA
  • AES
  • CCMP
  • TKIP
  • WPA supplicant (only in english wikipedia !)

Demo

• Configure WPA on a WLAN router
• Configure a connection profile with WPA on the client
• Show WPA supplicant in the process tree
• Show WPA supplicant visible (rekeying)

Q & A

• Your questions
• Your remarks
• Your problems
• Your suggestions

The Author

• Name: Christian Langanke
• email: cla@clanganke.de
• homepage: http://www.clanganke.de
  • with free programs for OS/2 and eComStation
  • my PGP key
• Member of Team OS/2 Germany
• OS/2 user since 1990 with OS/2 V1.2

My projects and activities

• author/inventor of projects
  • Wireless LAN Monitor
  • Workplace Shell Toolkit
  • Netlabs EPM Distribution
  • Internet Assistant for OS/2 and eComStation
• netlabs.org support activities
  • Generic MAC Wrapper driver (Release Management)
  • Port of WPA supplicant (Maintenance)
  • Everblue (Build System)
  • ISDNPM a.k.a. eCSCoNet (Online Help, REXX scripts)
• planning or supporting events of
  • Team OS/2 Germany local fairs
  • Warpstock Europe events

The End

Thank you very much for your your attention!