# T^WaveLAN
# D^Teil 2: Einfuehrung in IEEE 802.11b
# A^Benedikt 'Hunz' Heinz, Frank Zirkelbach
# M^hunz@hunz.org, frank@luga.de
# E^Linuxinfotag 2003
# L^FH-Augsburg
# X^1024
# Y^768

1 802.11b Aufbau
  # Alle Pakete die von und zum Wireless Device gehen, nennt man Frames
 1.1 Frame Aufbau
  + Frame Control (FC)
   + Frametyp (Type und Subtype)
   + From oder To DS
   + WEP ja/nein
  + MAC Adresse(n)
  + Frame Body (nur in Daten Frames)
 1.2 Die wichtigsten Frametypen
  + Management Frames
   + Beacon Frames (alle 100ms)
     AP announced sich und seine Capabilities
     STAs ermitteln aus Beacon Frames die Signalstaerke 
     # aus beacons weil regelmaessig und von ap
   + Probe Request/Response
     Req: STA sendet Request, dieser enthaelt SSID und unterstuetzte Datenraten
     Res: SSID, Capabilities
   + Authentication
     Es gibt Open System und Shared Key
     OS:
     1: STA schickt Auth an AP
     2: AP schickt Bestaetigung an STA
     SK:
     1: STA schickt Auth an AP
     2: AP schickt Challenge Text an STA
     3: STA schickt encrypted Challenge Text zurueck an AP
     4: AP schickt Bestaetigung zurueck
   + Association Request/Response
     Req: STA sendet Capabilities, SSID, unterstuetzte Datenraten
     Res: AP antwortet u.a. mit Status und Association ID
     Nun ist die STA an dem AP angemeldet
     (Ausserdem gibt es noch Re/Dis Association)
  + Control Frames
   + Request/Clear To Send (RTS/CTS)
     Anfrage/Bestaetugung zum Senden von Data/Management Frames
   + Acknowledgement (ACK)
     Empfangsbestaetigung von Daten und Management Frames
    Es gibt noch weitere Control Frames, diese sind aber ziemlich langweilig
  + Data Frames (alle wieder aufwachen ;)
    4 Typen:
    Wireless -> Wireless (  )
    Ethernet -> Wireless (F )
    Wireless -> Ethernet ( T)
    Ethernet -> Ethernet (FT) (WDS)
2 Betriebsmodi auf Paketebene
 2.1 Ad-Hoc
  + Jede STA sendet Beacons
  # Probes?
  + keine Authentications oder Associations
  + kein DS (und damit kein bridging) moeglich
 2.2 Managed
  1: Client erkennt AP via Probe Request / Response
  2: Client authenticatet sich am AP
  3: Client associated sich am AP
  4: AP stellt Verbindung zum DS her
 2.3 Wireless Distribution Systems (WDS)
  + keine Management Frames noetig
  + nur Datenframes
  + verbindet 2 Ethernetsegmente:
    FromDS und ToDS im FC gesetzt (4 MAC Addressen)
  + Beispiel: Koenigsplatz, IHK (CityWave)
3 "Sicherheit"
 3.1 Wardriven im Monitoring Mode
  + Karte wird in passiven Modus geschaltet
  + sie bucht sich nicht mehr ein, etc. 
  + gibt alle empfangenen Pakete ungefiltertert an den Host weiter
 3.2 Hidden SSIDs
  + APs antworten nicht auf Probes mit leerer SSID
  + SSID wird in Beacon nichtt mitgesendet
  + STAs muessen richtige SSID in Probe Requests setzen
   Gegenmassnahmen:
  + Probes oder (Re)Association sniffen
  + STA durch gespoofte Disassociation zum associaten zwingen 
 3.3 Access Control Lists (ACLs)
  + AP laesst nur STAs mit bekannter MAC einbuchen
   Gegenmassnahme:
  + Freigeschaltete MAC uebernehmen
 3.4 WEP (RC4)
  + RC4: Symmetrischer Streamcypher der auf einen PRNG beruht, mit dem der Stream per XOR verknuepft wird
    Symmetrische Stromchiffrierung mit variabler Schluessellaenge
    von Ron Rivest fuer RSA Data Security 1987 entwickelt und patentiert
    7 Jahre lang geheim, dann wurde der Algo publik.
  + 128 bzw. 64 Bit Keys - davon 24 Bit InitVektor, bei jedem Paket um eins erhoeht
  + 40 Bit: in ~2 Tagen mit ~10 Computern gebruteforced
    (1 GHz P3: ~450k Keys/sec)
  + 104 Bit
   + Bestimmte IVs lassen Rueckschluesse auf Key zu
     (neuere Firmwares ueberspringen diese IVs)
   + Manipulation der verschluesselten Payload moeglich
     (wegen Linearitaet von RC4 und CRC32 siehe http://cryptolabs.org/wep/)
   + Bei Kenntniss einer Klartext Payload, lassen sich alle weiteren Pakete des selben IVs berechnen
     (da Key nur IV, nicht aber Payload abhaengig)