Hoe WEP faalde
Het leek een verbonden vat: hoe populairder wifi werd over de hele wereld, hoe meer papers er verschenen die fouten identificeerden in WEP. Al vrij snel werd duidelijk dat WEP hoegenaamd géén CIA kon aanbieden. De meeste fouten die werden gevonden kunnen gegroepeerd worden in volgende vier zaken:
- Het RC4 algoritme wordt verkeerd gebruikt: een streamcipher verdraagt geen sleutelhergebruik.
- De IV is te klein en slecht beschreven in de standaard.
- CRC-32 kan omzeild worden en kan dus geen integriteit van frames garanderen.
- Er is geen sleutel-management systeem.
Er is echter nog een vijfde fout die de voorgaande vier als het ware nog versterkt:
- Er is geen replay protection.
Hierdoor heeft de aanvaller vrij spel en kan hij een draadloos netwerk als een experimenteertuin gebruiken en duizenden pakketjes te pas en te onpas heruitzenden. De replay protection behandelen we niet apart, maar zullen we bij de andere problemen zien opduiken.
Lees dit subhoofdstuk niet als geschiedenisles. De kernfout van WEP (twee keer dezelfde keystream gebruiken) is precies de fout die in 2017 bij WPA2 opnieuw opdook, maar dan in een veel modernere verpakking. Onthoud dus vooral probleem 1 en 2.
Probleem 1: RC4 en sleutelhergebruik
RC4 was destijds een populair streamcipher: sterk genoeg én efficiënt (het verbruikt weinig energie omdat er geen dure vermenigvuldigingsoperaties in voorkomen). Maar streamciphers hebben één eigenschap die je nooit mag vergeten: het is uiterst onveilig om eenzelfde keystream twee keer te gebruiken!
Stel dat je volgende twee plaintext byte sequenties hebt: \(p_1,p_2,p_3,…\) en \(q_1,q_2,q_3,…\). Beiden worden met dezelfde keystream \(k_1,k_2,k_3,…\) geëncrypteerd. Dit geeft ons volgende twee ciphertext sequenties:
\(p_1 \oplus k_1, p_2 \oplus k_2, p_3 \oplus k_3\)
\(q_1 \oplus k_1, q_2 \oplus k_2, q_3 \oplus k_3\)
Als een aanvaller deze twee ciphertexts capteert, dan volgt een grove schending van de confidentialiteit (met dank aan de eigenschappen van de XOR-operatie):
\((p_i \oplus k_i) \oplus (q_i \oplus k_i) = p_i \oplus q_i\)
Of in andere woorden, wanneer we de beide ciphertexts met elkaar XOR’n krijgen we een sequentie die niet afhankelijk is van de gebruikte sleutel! Als één van beide plaintexts gekend is, volstaat een eenvoudige XOR-operatie om ook de andere plaintext te kennen, zonder dat de sleutel geweten moet zijn. En nog erger: wie een plaintext en de bijhorende ciphertext kent, heeft meteen de keystream zelf in handen:
\(c_i = k_i \oplus p_i \Leftrightarrow k_i = c_i \oplus p_i\)
Met die keystream kan de aanvaller vervolgens eigen frames encrypteren en op het netwerk zetten. Het netwerk gaat er namelijk van uit dat wie een geldige keystream gebruikt, de WEP-sleutel kent en dus geauthenticeerd is.
Herinner je de shared-key authentication uit het vorige subhoofdstuk: daar vliegt een challenge in plaintext door de lucht, meteen gevolgd door de geëncrypteerde versie ervan. Wie dat meesnift, heeft dus een stuk keystream in handen en kan zelf voortaan iedere challenge beantwoorden. Dat is de reden waarom open-system authentication veiliger was.
Kortom, streamciphers zijn niet veilig als je niet kan garanderen dat een keystream nooit herbruikt wordt. WEP probeert dat op te lossen met de IV… en daar loopt het mis.
Probleem 2: de IV
IV collisions
Doordat de IV maar 24 bit groot is, treden er veel sneller collisions op dan intuïtief wordt verwacht. Van zodra twee pakketjes met dezelfde IV zijn verstuurd, hebben we een collision: beide pakketjes werden met dezelfde keystream geëncrypteerd. En dat is exact de situatie uit probleem 1.
Een 24-bit IV kan \(2^{24}\) oftewel 16 777 216 mogelijke waarden hebben. Een kleine berekening toont hoe snel ze op zijn:
Gegeven: een eerste generatie AP die aan een miezerige 11 Mbps werkt en continue 1.500-byte frames uitzendt:
- \(\frac{11\;Mbps}{(1500\; bytes/pakket)* 8\;bits/byte} = 916.67\;pakketjes/seconde\)
- \(\frac{16.777.216\;IVs}{916.67\;pakketjes/seconde} \approx 18302 \;seconden\)
Na ongeveer vijf uur zijn alle IV’s opgebruikt en treden er dus gegarandeerd collisions op. En dat is nog de optimistische versie. De standaard gaf enkel aan dat de IV “geregeld” moest veranderen en liet de rest aan de fabrikanten over. Sommigen gebruikten een willekeurige IV (door de verjaardagenparadox heb je dan al na zo’n 5000 pakketjes 50% kans op een collision), anderen een teller die bij iedere herstart opnieuw op 0 begon, en een paar fabrikanten gebruikten zelfs gewoon altijd dezelfde IV.
De verjaardagenparadox: in een groep van amper 23 willekeurig gekozen mensen is de kans al groter dan 50% dat er twee dezelfde verjaardag hebben. Vervang “mensen” door “pakketjes” en “verjaardag” door “IV”, en je snapt waarom 24 bit veel te weinig is.
Deze fout kunnen aanvallers op twee manieren misbruiken:
- Passief: de aanvaller luistert stilletjes mee tot er een IV collision optreedt en XOR’t de twee pakketjes. IP-trafiek is erg voorspelbaar (headers, protocollen, …), waardoor het niet moeilijk is om minstens een deel van één plaintext te raden en zo de rest te ontrafelen.
- Actief: de aanvaller stuurt zelf een gekende plaintext naar het slachtoffer, bijvoorbeeld een ping of e-mail via het Internet. Het AP encrypteert die braaf en stuurt ze de lucht in. De aanvaller vangt de ciphertext op en berekent \(k = c \oplus p\): een geldige keystream, zonder dat hij ook maar iets van de sleutel weet.
Omdat er geen replay protection is, kan de aanvaller zo’n gecapteerde keystream zelfs byte per byte laten groeien: hij stuurt een pakketje dat één byte langer is dan zijn keystream en gokt de laatste byte (1 kans op 256). Krijgt hij een antwoord van het netwerk, dan was de gok juist. Zo bouwt hij stilaan een bibliotheek van bruikbare keystreams op.
Weak keys
Alsof dat nog niet genoeg was, toonden Scott Fluhrer, Itsik Mantin en Adi Shamir in 2001 aan dat de manier waarop WEP de IV gewoon vóór de sleutel plakt, slecht samengaat met RC4. Voor bepaalde IV’s (de zogenaamde weak keys) lekt het begin van de keystream informatie over de WEP-sleutel zelf. En het begin van de plaintext van bijna ieder WEP-pakket is gekend (de LLC-header start quasi altijd met de twee bytes 0xAA 0xAA), dus ook het begin van de keystream. Genoeg pakketjes met zwakke IV’s verzamelen volstaat dan om de volledige WEP-sleutel te berekenen. Dit heet de FMS-aanval, naar de initialen van de drie onderzoekers. Tools zoals AirSnort en WEPCrack maakten de aanval al snel voor iedereen bruikbaar. Latere verbeteringen (zoals de PTW-aanval uit 2007, ingebouwd in aircrack-ng) brachten de benodigde tijd terug tot enkele minuten.
Probleem 3: CRC is geen MAC
WEP gebruikt een CRC-32 checksum als integriteitscheck. Dat was geen wijze keuze: een CRC is bedoeld om toevallige transmissiefouten te detecteren, niet bewuste aanpassingen. Er zit geen sleutel in: iedereen kan een CRC berekenen. Wat je voor integriteit nodig hebt, is een message authentication code (MAC), een checksum die enkel te berekenen is als je een geheime sleutel kent. Niet te verwarren met een MAC-adres: daarom spreekt men in de wifi-wereld van een MIC (message integrity code), zie verder bij WPA1.
Bovendien is CRC-32 een zogenaamde lineaire functie. Zonder in detail te gaan volstaat het te begrijpen dat: de CRC van een boodschap ge-XOR’d met de CRC van een andere boodschap is hetzelfde als de CRC nemen nadat beide boodschappen samen werden ge-XOR’d:
\(CRC (boodschap_1) \oplus CRC (boodschap_2) = CRC (boodschap_1 \oplus boodschap_2)\)
In combinatie met de XOR-encryptie van RC4 kunnen we daardoor gecontroleerd aanpassingen aan geëncrypteerde pakketten doen, zonder de ICV te breken. Welgekomen, bitflip aanval.
Bitflip aanval
- De aanvaller heeft enkel één geldig WEP frame nodig. Hij hoeft zelfs niet te weten wat de inhoud ervan is.
- Vervolgens maakt hij een bitflip masker: een reeks 0’n met enkele bits op 1. Dit masker XOR’t hij met de geëncrypteerde payload. Na decryptie zullen exact die bits in de plaintext geflipt zijn.
- Om een geldige ICV te krijgen, berekent hij de CRC van zijn masker en XOR’t die met de geëncrypteerde originele ICV. Dankzij de lineariteit klopt de ICV na decryptie perfect.
- Het resultaat is een geldig frame met foute data als payload, dat door het AP aanvaard zal worden.
Het AP stuurt dit pakket braaf door naar de volgende laag, want de ICV klopt. Die laag ziet een pakket vol rommel en stuurt een foutboodschap terug. De aanvaller vangt die (geëncrypteerde) foutboodschap op. Maar hij weet wat erin staat, want de standaard van die laag beschrijft precies hoe zo’n foutboodschap eruitziet. Gekende plaintext en bijhorende ciphertext: \(k = c \oplus p\), en hij heeft weer een keystream.
Probleem 4: sleutelmanagement
Het moge duidelijk zijn: constant dezelfde WEP-sleutel gebruiken, op alle apparaten, gedurende maanden, is vragen om problemen. Werknemers die ontslagen worden, nemen de sleutel mee naar huis. Administrators moeten manueel nieuwe sleutels invoeren op ieder toestel. Twee zaken ontbreken volledig:
- Er is geen geautomatiseerd sleutel verversmechanisme: idealiter wordt de sleutel vervangen lang voordat de verzameling van mogelijke IV’s is opgebruikt. Dan maakt die kleine IV veel minder uit.
- Er is geen gecentraliseerd sleutelmanagementsysteem.
Bart Preneel van de KUL/Cosic, één van België’s meest vooraanstaande crypto-experts, zei ooit over WEP dat het het perfecte schoolvoorbeeld is van wat er allemaal kan fout lopen wanneer je beslist om zelf een nieuw crypto-algoritme te ontwikkelen.
Hoe WEP oplossen?
Rond 2001, nog geen twee jaar nadat 802.11b de wereld “het wonder van draadloze netwerken” bracht, werd duidelijk dat er dringend een oplossing moest verschijnen. Wifi was alomtegenwoordig, zowel bij particulieren als in bedrijven, en dus moest er ook een oplossing komen voor de honderdduizenden apparaten die reeds in gebruik waren.
Het IEEE begon aan een nieuwe beveiligingsstandaard, IEEE 802.11i. Maar standaarden schrijven duurt lang, en zo lang kon de markt niet wachten. Daarom kwam de Wifi Alliance (de organisatie van fabrikanten die wifi-producten test en certificeert) tussen met twee pistes:
- WPA1 (2003): een tijdelijke oplossing voor bestaande apparaten, gebaseerd op een voorlopige versie van 802.11i en rekening houdend met enkele duidelijke beperkingen.
- WPA2 (2004): de volledige 802.11i-standaard, met een volledig nieuwe suite aan veiligheidsprotocollen voor toekomstige wifi-producten, die niet compatibel zou zijn met bestaande apparatuur.
WPA staat voor Wi-Fi Protected Access. Het is geen IEEE-standaard, maar een certificering van de Wifi Alliance: enkel producten die hun tests doorstaan, mogen het label dragen. Hetzelfde geldt later voor WPA3.
Voor sleutelmanagement en gebruikersauthenticatie werd de bestaande IEEE 802.1X standaard omarmd. Omdat die 802.1X-infrastructuur redelijk overkill is voor huis-tuin-en-keukengebruikers, kwamen er twee versies van zowel WPA1 als WPA2 (en later WPA3):
- Personal: de thuisversie waarbij iedereen met eenzelfde wachtwoord of passphrase werkt (een zogenaamde PSK oftewel pre-shared key). Hierbij wordt géén 802.1X gebruikt.
- Enterprise: de versie voor bedrijven en scholen waar iedere gebruiker met z’n eigen account inlogt en 802.1X het sleutelbeheer regelt. Dit bekijken we in detail in het laatste subhoofdstuk.
We vatten hier alvast de belangrijkste verschillen samen.
| Standaard | Encryptie | Integrity | Authenticatie & sleutelmanagement |
|---|---|---|---|
| WEP | RC4 | CRC-32 | Geen |
| WPA1-Personal | TKIP (RC4) | Michael | Pre-shared key |
| WPA1-Enterprise | TKIP (RC4) | Michael | 802.1X |
| WPA2-Personal | CCMP (AES) | CBC-MAC | Pre-shared key |
| WPA2-Enterprise | CCMP (AES) | CBC-MAC | 802.1X |
| WPA3-Personal | CCMP (AES) | CBC-MAC | SAE (wachtwoord) + verplichte PMF |
| WPA3-Enterprise | CCMP of GCMP-256 (AES) | CBC-MAC of GMAC | 802.1X + verplichte PMF |
WPA3 (2018) bespreken we op het einde van dit hoofdstuk. WPA1 en WPA2 zijn historisch gezien rechtstreeks gerelateerd aan WEP en daarom bekijken we die eerst.