WEP, WPA, SKIP, AES – a WIFI biztonság szabványai

  • A WEP – Wired Equivalent Privacy – célja, hogy a vezeték nélküli hálózat legalább olyan biztonságos legyen mint a vezetékes.
  • Nem volt egy kifejezett sikertörténet, a szabvány az összes lehetséges hibát elköveti.
  • 1997-ben mutatták be, 2001-ben már feltörték, 2004-ben érvénytelenítették a szabványt a hiányosságai miatt.
  • Ma már percek alatt feltörhető.
  • Ennek ellenére még sokan használják, mert a routerek ezt a beállítást kínálják fel alapból, s a felhasználók – mivel nem értenek hozzá – nem állítják át.

A WEP működése

Források: WiFi biztonság – Buttyán – Dóra: Wifi biztonság – A jó, a rossz, és a csúf – archiválva: itt. Illetve: EthicalHacking – archiválva: itt. Továbbá: Faigl Zoltán: Az IEEE 802.11 kapcsolat-felépítés vizsgálata.

  • A WEP hitelesít, azaz azonosítja a felhasználót, ill. titkosítja a forgalmat, így az egy értelmetlen jelsorozat lesz annak, aki nem tudja, hogy hogyan kódolja vissza az üzenetet. Felhasználó: STA – (Station), csatlakozópont: AP – Access Point.

“A hitelesítést egy egyszerű kihívás-válasz alapú protokoll végzi, mely négy üzenet cseréjéből áll. Elsőként a STA jelzi, hogy szeretné hitelesíteni magát (authenticate request). Válaszul az AP generál egy véletlen számot, s azt kihívásként elküldi a STAnak (authenticate challenge). Az STA rejtjelezi a kihívást, s az eredményt visszaküldi az AP-nak (authenticate response). A STA a rejtjelezést egy olyan titkos kulccsal végzi, melyet csak a STA és az AP ismer. Ezért ha az AP sikeresen dekódolja a választ (azaz a dekódolás eredményeként visszakapja saját kihívását), akkor elhiszi, hogy a választ az adott STA állította elő, hiszen csak az ismeri a helyes válasz generálásához szükséges titkos kulcsot. Más szavakkal, a válasz sikeres dekódolása esetén az AP hitelesítette a STA-t, és ennek megfelelően dönthet arról, hogy a csatlakozást engedélyezi vagy sem. A döntésről az AP a protokoll negyedik üzenetében tájékoztatja a STA-t (authenticate success vagy failure).” (Buttyán – Dóra)

“Miután a hitelesítés megtörtént, a STA és az AP üzeneteiket rejtjelezve kommunikálnak. A rejtjelezéshez ugyanazt a titkos kulcsot használják, mint a hitelesítéshez. A WEP rejtjelező algoritmusa az RC4 adatfolyam (kulcsfolyam) kódoló. A adatfolyam kódolók úgy működnek, hogy egy kis méretű, néhány bájtos titkos kulcsból egy hosszú álvéletlen bájtsorozatot állítanak elő, és ezen sorozat bájtjait XOR-olják az üzenet bájtjaihoz. Ez történik a WEP esetében is. Az M üzenet küldője (a STA vagy az AP) a titkos kulccsal inizializálja az RC4 kódolót, majd az RC4 által előállított K álvéletlen bájtsorozatot XOR-olja az üzenethez. [Az üzenet és a bájtsorozat egymásnak megfelelő bitjei között kizáró vagy műveletet hajt végre.] Az M ⊕ K rejtjelezett üzenet vevője ugyanazt teszi mint a küldő: a titkos kulccsal inicializálja az RC4 algoritmust, amely így ugyanazt a K álvéletlen bájtsorozatot állítja elő, amit a rejtjelezéshez használt a küldő. Ezt a rejtjelezett üzenethez XOR-olva – az XOR művelet tulajdonságai miatt – a vevő az eredeti üzenetet kapja vissza: (M ⊕ K) ⊕ K = M.” (Buttyán – Dóra)

  • Az RC4 kidolgozója Ron Rivest, így a betűszó feloldása eredetileg ‘Rivest Cipher 4‘, de értelmezik ‘Ron’s Code‘-nak is. Az XOR a kizáró vagy művelete.

“Könnyen látható, hogy ha a rejtjelezés a fentiek szerint működne, akkor minden üzenethez ugyanazt a K álvéletlen bájtsorozatot XORolnánk, hiszen a kódolót minden üzenet elküldése előtt ugyanazzal a titkos kulccsal inicializáljuk. Ez több szempontból is hiba lenne. Tegyük fel például, hogy egy támadó lehallgat két rejtjelezett üzenetet, M1 ⊕ K-t és M2 ⊕ K-t. A két rejtjelezett üzenetet XORolva, a támadó a két nyílt üzenet XOR összegét kapja: (M1 ⊕ K) ⊕ (M2 ⊕ K) = M1 ⊕ M2. Ez olyan, mintha az egyik üzenetet a másik üzenettel, mint kulcsfolyammal rejtjeleztük volna. Ám ebben az esetben M1 és M2 nem álvéletlen bájtsorozatok. Valójában tehát M1⊕M2 egy nagyon gyenge rejtjelezés, és a támadó az üzenetek statisztikai tulajdonságait felhasználva könnyen meg tudja fejteni mindkét üzenetet.” (Buttyán – Dóra)

“Ezen problémák elkerülése érdekében, a WEP nem egyszerűen a titkos kulcsot használja a rejtjelezéshez, hanem azt kiegészíti egy IV-nek (Initialization Vector) nevezett értékkel, mely üzenetenként változik. A rejtjelezés folyamata tehát a következő: az IV-t és a titkos kulcsot összefűzzük, a kapott értékkel inicializáljuk az RC4 kódolót, mely előállítja az álvéletlen bájtsorozatot, amit az üzenethez XOR-olunk. A dekódolás folyamata ezzel analóg. Ebből következik, hogy a vevőnek szüksége van a kódolásnál használt IV-re. Ez a rejtjelezett üzenethez fűzve, nyíltan kerül átvitelre. Ez elvileg nem jelent problémát, mert az üzenet dekódolásához csupán az IV ismerete nem elegendő, ahhoz a titkos kulcsot is ismerni kell. A méreteket illetően megemlítjük – s ennek később még lesz jelentősége – hogy az IV 24 bites, a titkos kulcs pedig (általában) 104 bites. (1 Különböző marketing anyagokban ezt gyakran úgy interpretálják, hogy a WEP „128 bites biztonságot” nyújt. Ez természetesen félrevezető (mint a marketing anyagok általában), hiszen a 128 bitből 24 nyíltan kerül átvitelre.) .. a rejtjelezés előtt, a küldő egy integritás-védő ellenőrző összeggel (Integrity Check Value, vagy röviden ICV) egészíti ki a nyílt üzenetet, melynek célja a szándékos módosítások detektálásának lehetővé tétele a vevő számára.” (Buttyán – Dóra)

WEP keret formátuma

  • Az üzenetet ugyan kódolva küldik át, de mellékelik hozzá a kódolatlan IV-t, amit mindenki kiolvashat.
  • Az inicializációs vektor a keret elején; 3 byte hosszúságú, azaz 24 bit
  • a Key ID # which enables the user to identify which shared key he has to use to decrypt the frame. (more)

Más szavakkal:

  1. A titkos kulcshoz fűzi az IV-t
  2. Az eredményt átadja a RC4-nek, ami egy végtelen hosszú pszeudorandom sorozatot állít elő, a kulcsszekvenciát.
  3. A titkosítandó üzenetre számol egy CRC értéket (ICV) és ezt hozzáfűzi (CRC – Cyclic Redundancy Check – ellenőrző összeg). Ez lesz a kódolás alapja.
  4. Ezt XOR-olja a kulcsszekvenciával és megkaptuk a kódolt üzenetet.
  5. Az IV-t beleteszi a küldendő csomagba, hogy a fogadó dekódolni tudja az üzenetet.

(forrás: 2006.04.20. Matiscsák Anita, Bikki Balázs: WiFi hálózatok biztonsági szempontból1A IEEE 802.11 szabvány szerinti vezeték nélküli hálózatok (WiFi) biztonsága)

“Végezetül a WEP kulcsokról szólunk röviden. A szábvány lehetővé teszi, hogy minden
STA-nak saját titkos kulcsa legyen, amit csak az AP-vel oszt meg. Ez azonban
megnehezíti a kulcsmenedzsmentet az AP oldalán, mivel ekkor az AP-nek minden STA
kulcsát ismernie és gondoznia kell. Ezért a legtöbb implementáció nem támogatja ezt a
lehetőséget. A szabvány előír egy ún. default kulcsot is, amit az AP és a hálózathoz
tartozó minden STA ismer. Eredetileg ezt a kulcsot azon üzenetek védelmére szánták,
melyeket az AP többesszórással (broadcast) minden STA-nak el szeretne küldeni. A
legtöbb WEP implementáció azonban csak ezt a megoldást támogatja. Így a
gyakorlatban, egy adott hálózathoz tartozó eszközök egyetlen közös kulcsot használnak titkos kulcsként
. Ezt a kulcsot manuálisan kell telepíteni a mobil eszközökben és az APben. Nyílvánvaló, hogy ez a megoldás csak egy külső támadó ellen biztosítja a kommunikáció biztonságát; az eszközök (elvileg) dekódolni tudják egymás üzeneteit.” (Buttyán – Dóra)

Integritás védelem problémája

“A WEP-ben az üzenetek integritásának védelmét az üzenetekhez csatolt ellenőrző összeg (ICV) hivatott biztosítani. Az ICV nem más, mint az üzenetre számolt CRC érték, mely az üzenettel együtt rejtjelezésre kerül. Formális jelöléseket használva, a rejtjelezett üzenet a következő módon írható fel: (M || CRC(M)) ⊕ K, ahol M a nyílt üzenet, K az RC4 által az IV-ből és a titkos kulcsból előállított álvéletlen bájtsorozat, CRC(.) jelöli a CRC függvényt, és || jelöli az összefűzés műveletét. Ismeretes, hogy a CRC lineáris művelet az XOR-ra nézve, azaz CRC(X ⊕ Y) = CRC(X) ⊕ CRC(Y). Ezt kihasználva, a támadó a rejtjelezett WEP üzenetek bármely bitjét módosítani tudja (át tudja billenteni), bár magát az üzenetet nem látja. Jelöljük a támadó szándékolt módosításait ∆M-mel. Ekkor a támadó az ((M ⊕ ∆M) || CRC(M ⊕ ∆M)) ⊕ K rejtjelezett üzenetet szeretné előállítani az eredetileg megfigyelt (M || CRC(M)) ⊕ K rejtjelezett üzenetből. Ehhez egyszerűen CRC(∆M)-et kell kiszámolnia, majd a ∆M || CRC(∆M) értéket kell az eredeti rejtjelezett üzenethez XOR-olnia. A következő egyszerű levezetés mutatja, hogy ez miért vezet célra: ((M || CRC(M)) ⊕ K) ⊕ (∆M || CRC(∆M)) = ((M ⊕ ∆M) || (CRC(M) ⊕ CRC(∆M))) ⊕ K = ((M ⊕ ∆M) || CRC(M ⊕ ∆M)) ⊕ K ahol az utolsó lépésben kihasználtuk a CRC linearitását. Mivel CRC(∆M) kiszámolásához nincs szükség a titkos kulcsra, ezért láthatóan a támadó könnyen tudja manipulálni a WEP üzeneteket, az integritás-védelem és a rejtjelezés ellenére.” (Buttyán – Dóra)

xorKicsit részletesebben: az eredeti M üzenethez elkészítünk egy ugyanannyi bitből álló ∆M bájtsorozatot. A kizáró vagy igazságtáblája alapján, ahol át akarjuk billenteni az eredeti M üzenet adott bitjét, oda 1 értéket kell beírni, a többi bit helyére pedig 0-t.

A WEP összeomlását okozó legdurvább hibák

“Mint azt korábban említettük, folyamkódolók használata esetén fontos, hogy minden üzenet más kulccsal legyen rejtjelezve. Ezt a WEP-ben az IV használata biztosítja; sajnos nem teljesen megfelelő módon. A probléma abból adódik, hogy az IV csak 24 bites, ami azt jelenti, hogy kb. 17 millió [2^24] lehetséges IV van. Egy WiFi eszköz kb. 500 teljes hosszúságú keretet tud forgalmazni egy másodperc alatt, így a teljes IV teret kb. 7 óra leforgása alatt kimeríti. Azaz 7 óránként ismétlődnek az IV értékek, s ezzel az RC4 által előállított álvéletlen bájtsorozatok is. A problémát súlyosbítja, hogy a gyakorlatban minden eszköz ugyanazt a titkos kulcsot használja, potenciálisan különböző IV értékekkel, így ha egyszerre n eszköz használja a hálózatot, akkor az IV ütközés várható ideje a 7 óra n-ed részére csökken. Egy másik súlyosbító tényező, hogy sok WEP implementáció az IV-t nem véletlen értékről indítja, hanem nulláról. Ezért beindítás után a különböző eszközök ugyanazt a nullától induló és egyesével növekvő IV sorozatot használják, legtöbbször ugyanazzal a közös titkos kulccsal. Azaz, a támadónak várakoznia sem kell, azonnal IV ütközésekhez jut.” (Buttyán – Dóra)

  • Az IV értékek tehát kódolás nélkül kerülnek az üzenetbe, így tudjuk, hogy mikor kezdődik az ismétlődésük. Amikor megkezdődik az IV értékek ismétlődése, akkor két – azonos IV értékkel inicializálva kódolt – üzenetet egymással XOR-olják, s ekkor egy olyan jelsorozatot kapunk, ahol az egyik értelmes szöveg a másik értelmes szöveggel van rejtjelezve, s ekkor az üzenet a nyelv hangzóelőfordulásának statisztikai szabályai alapján dekódolható, s így megkapjuk az RC4 által használt – adott inicializáló vektorhoz tartozó – álvéletlen bájtsorozatot – ha jól értem.

“A negyedik probléma egy gyöngyszem a protokolltervezési hibák között. Emlékeztetünk arra, hogy a WEP rejtjelezési algoritmusa az RC4 folyamkódoló. Nemcsak az üzeneteket kódolják az RC4 segítségével, hanem a STA ezt használja a hitelesítés során is az AP által küldött kihívás rejtjelezésére. Így a támadó a hitelesítés során küldött üzenetek lehallgatásával könnyen hozzájut a C kihíváshoz és az arra adott R = C ⊕ K válaszhoz, melyből C ⊕ R = K alapján azonnal megkapja az RC4 algoritmus által generált K álvéletlen bájtsorozatot. A játéknak ezzel vége, hiszen K segítségével a támadó bármikor, bármilyen kihívásra helyes választ tud generálni a STA nevében (s ezen az IV használata sem segít, mert az IV-t a rejtjelezett üzenet küldője, jelen esetben a támadó választja). Sőt, mivel a gyakorlatban minden, az adott hálózathoz tartozó eszköz ugyanazt a titkos kulcsot használja, a támadó ezek után bármelyik eszköz nevében csatlakozni tud a hálózathoz. Persze a csatlakozás önmagában még nem elegendő, a támadó használni is szeretné a hálózatot. Ehhez olyan üzeneteket kell fabrikálnia, amit az AP elfogad. A rejtjelezés követelménye miatt ez nem triviális feladat.” (Buttyán – Dóra)

“A WEP teljes összeomlását az RC4 kódoló nem megfelelő használata okozza. Ismeretes, hogy léteznek ún. gyenge RC4 kulcsok, melyekre az a jellemző, hogy belőlük az RC4 algoritmus nem teljesen véletlen bájtsorozatot állít elő. Ha valaki meg tudja figyelni egy gyenge kulcsból előállított bájtsorozat első néhány bájtját, akkor abból következtetni tud a kulcsra. Ezért a szakemberek azt javasolják, hogy az RC4 által előállított bájtsorozat első 256 bájtját mindig dobjuk el, s csak az utána generált bájtokat használjuk a rejtjelezéshez. Ezzel a gyenge kulcsok problémáját meg lehetne oldani. Sajnos a WEP nem így működik. Ráadásul a változó IV érték miatt előbb-utóbb biztosan gyenge kulcsot kap a kódoló, s az IV nyílt átvitele miatt, erről a támadó is tudomást szerezhet. Ezt kihasználva, néhány kriptográfus olyan támadó algoritmust konstruált a WEP ellen, melynek segítségével a teljes 104 bites titkos kulcs néhány millió üzenet lehallgatása után nagy valószínűséggel megfejthető. A WEP minden korábban leírt hibája eltörpül ezen eredmény mellett, ugyanis ezzel a támadással magához a titkos kulcshoz jut hozzá a támadó. Ráadásul a támadás könnyen automatizálható, és néhány „segítőkész” embernek köszönhetően, az Internetről letöltött támadó programok használatával amatőrök által is rutinszerűen végrehajtható.” (Buttyán – Dóra)

– Ütközés:

  • rc4(X) xor rc4(Y) = X
  • Ha több azonos IV-vel kódolt üzenetünk van, statisztikai módszerekkel következtethetünk a tartalmukra.
  • X xorY xorX = Y
  • Ha ismerünk egy üzenetet kódolatlanul és kódolva, akkor az összes ugyanolyan IV-velrendelkezőüzenetet meg tudjuk fejten
  • Ha ismerjük: X, rc4(X) akkor bármilyen helyesen kódolt üzenetet el tudunk küldeni a hálózatra
  • RC4(X) xor X xor Y = RC4(Y)
  • Dekódoló táblát lehet felépíteni, ami tartalmaz minden IV-hez kapcsolódó RC4 kulcssorozatot, így a teljes forgalom dekódolható (Matiscsák-Bikki)

– Gyenge kulcsok

Más megfogalmazásban: “A legfontosabb azonban: az RC4 helytelen használata: léteznek ugyanis ún. gyenge kulcsok, amikből olyan bitsorozatot állít elő az algoritmus, amiknek első néhány bájtjából nagy valószínűséggel következtetni lehet az eredeti, bevitt értékre, tehát a titkos kulcsra! Ráadásul az állandóan változó IV miatt sokkal nagyobb az esély a gyenge kulcs létrejöttére. Valójában ezen alapszik a teljes törési eljárás.” (EthicalHacking)

  • Tehát amikor megkezdődik a IV értékek ismétlődése, akkor hozzá juthatunk az álvéletlen bájtsorozatokhoz, melyek között lesz gyenge sorozat is, melyekből következtethetünk nagy valószínűséggel az esetleges jelszóra. Majd ezekből a nagy valószínűségű jelszavakból egy idő után össze tudjuk rakni az eredeti jelszót.

mastermind “Pont olyan, mint az ismert MasterMind játék: minden sorral újabb információ derül ki, és végül meg van a szó. Ezért a WEP-nél nagyjából semmit nem ér a speciális jelszó, mert előbb utóbb úgyis kiderül…Próbaképpen ezt a jelszót állítottam be: ’!5kJ). Ezt szólistából lehetetlen lenne kipörgetni, de nekem mégis sikerült kiderítenem. Hiszen minden csomagból újabb információ derült ki a kulcsról, és végül meg volt az a karaktersor, ami megfelelt az információknak. A bitszám sem segít sokat: 128 bites titkosítás esetén már 60 000 csomagból 60-70% a kiderítés valószínűsége, 100 000 csomagnál 90%. (…) Viszont 60 000 csomag még mindig nagyon sok: ennyit csak akkor generál egymenetben a felhasználó, ha pl. letölt egy filmet. De ki akar erre várni? Hiszen alapszintű kommunikáció szinte mindig van a levegőben. Ha a támadó itt elcsíp egy alkalmas csomagot (olyan csomagot, amire a routernek válaszolnia kell), és átírja a címzett helyére saját magát, majd elkezdi küldeni, folyamatosan visszajátszani? Nyugodtan megteheti, hiszen, mint írtam, a WEP-nél lehetséges csomagok reinjektálása [azaz: ugyanazt a felvett üzenetet játszunk le újra és újra]. A router pedig, szerencsétlenül küldi-küldi a válaszcsomagokat, minden egyes csomaggal hozzáadván egy kis információt a nagy MasterMind-hoz… Egy Intel2200B/G chipsetes kártyával olyan 300 csomag/mp-es sebesség érhető el. Elméletben tehát 200mp szükséges a töréshez. Persze, ha a teljes időt vesszük (megfelelő csomagra kell egy kicsit várni, általában 40-60 mp-et, be kell szerezni KisM*T-tel a megfelelő infókat a hálózatról), úgyhogy összeségében akár 5 percbe is telhet laptop bekapcsolásától a titkos kulcsig.” (EthicalHacking)

  • Új eljárást dolgoznak ki, s a WEP-től való megkülönböztetés érdekében RSN, azaz Robust Security Network lesz a neve. Ez a 802.11i szabvány.
  • A RSN a hitelesítést az 802.1X, szabvány (négyutas kézfogás) alapján végzi.
  • Az RSN az AES, azaz az Advanced Encryption Standard eljárást használja a titkosításra.
  • A már használatban lévő eszközök hardveresen az RC4 használatára lettek kialakítva, azaz az RSN használatához az összes hardvert le kellett volna cserélni, s nem lehetett volna megoldani a problémát csupán szoftverfrissítéssel.
  • Ezért kidolgoztak egy protokollt, amely továbbra is az RC4 kódolást használta, de erősebb volt, mint a WEP. Ez a TKIP, azaz a Temporal Key Integrity Protocol. Ez már egy szoftverfrissítés után futtatható a régi hardvereken. Ezzel tehát a régi WEP-et használó hálózatokat biztonságossá lehetett tenni
  • A gyártók nem várták meg az eredeti specifikáció lassú szabványosítását, hanem kiadták a WPA specifikációt (WiFi Protected Access), ami a TKIP-re épül. A WPA már tartalmazta az RSN egy részhalmazát, amit a hardverek átalakítása nélkül is lehetett használni
  • Ma már a boltokban kapható eszközök képesek RSN-t használni, amit WPA2-nek is neveznek.

TKIP – Temporal Key Integrity Protocol

A TKIP-t, az időszakos kulcs sérthetetlenségi protokoll úgy oldja meg az inicializáló vektor (IV) ismétlődésének a problémáját, hogy annak a hosszát 24 bitről 48 bitre emeli, s ezzel gyakorlatilag megszünteti az ismétlődést. Ugyanis, ha az eszköz 500 keretet forgalmaz 1 másodperc alatt, akkor 2^24 IV kb. 9 óra alatt ismétlődik, míg 2^48 IV esetén az ismétlődés csak nagyságrendileg 150 millió óra után következne be.

A TKIP esetében titkosítás egy 128 bit hosszúságú kulcsot használ, ami a temporal key. A módszer az időszakos kulcsot (temporal key) összekeveri az adó MAC számával és az inicializáló vektorral, s ebből létre hoz egy Per Packet Key kulcsot, ami a WEP állandó titkos kulcsának a szerepét veszi át, s így ez a kulcs minden üzenetnél más-más lesz. Továbbá az időszakos kulcsot rendszeres időközönként megváltoztatja, ill. az üzenet integritását biztosító CRC érték helyett hash-t használ, ami sokkal biztonságosabb. ( forrás: cs.stanford.edu)

“Emlékeztetünk arra, hogy a WEP titkosítás legfôbb hibáját az IV kis mérete és a gyenge RC4 kulcsok használata jelentette. A TKIP-ben ezért az IV méretét 24 bitrôl megnövelték 48 bitre. Ez egyszerû megoldásnak látszik, ám a nehézséget az okozza, hogy a WEP-et támogató hardverek adott hosszúságú (128 bites) értékkel inicializálják az RC4 algoritmust, s így a megnövelt IV-t, a rejtjelezô kulccsal együtt, valamilyen módon „bele kell gyömöszölni” ebbe az adott hosszúságba. A gyenge kulcsok problémáját a TKIP úgy oldja meg, hogy minden üzenet rejtjelezését más kulccsal végzi. Így a támadó nem tud a sikeres támadáshoz szükséges számú, azonos (potenciálisan gyenge) kulccsal kódolt üzenetet megfigyelni. Az üzenetkulcsokat a TKIP a négyutas kézfogás során generált adatrejtjelezô kulcsból állítja elô.” (Buttyán – Dóra)

A következő ábrán (kép: Univ. at Buffalo) a Session Key az adatrejtjelező kulcs.

Az RC4 kulcs előállítása TKIP-ben (kép: Univ. at Buffalo)

tkipPontosan mi is a temporal key? “After the 4-way handshake is completed, a 256-bit temporal key will be given to the TKIP algorithm. The first 128 bits will be used as the temporal key for encryption. The remaining 128 bits will be split into two 64-bit MIC keys. The first key signs and checks data from the AP to the client, and the second signs and checks data from the client to the AP. – The decryption process is basically the reversal of this process with extra checks. After receiving the MPDU, the station reconstructs the TSC (TKIP Sequence Number) value from the IV and extended IV. It then generates the RC4 key using the TSC values, the transmitter MAC and the temporal key.” (Forrás – Kevin Benton: The Evolution of 802.11 Wireless Security) – Úgy tűnik, itt a IV (Initialization Vector) neve most TSC (TKIP Sequence Number) lesz.

Azaz a 128 bites kulcsban csak az IV alsó 16 bitje szerepel a kulcs elején a következő sorrendben: 8 bit IV + 8 bit dummy byte + 8 bit IV. A dummy byte egy fix értékű bájt, aminek az a feladata, hogy elkerüljék a gyenge kulcsok generálását. Ez a 24 bit megfelel a WEP eredeti IV-ának. Azt viszont nem egy állandó titkos kulcs követi, hanem az IV felső 32 bitjéből, a MAC numberből és a Temporal Key-ből előállított 104 bites titkos kulcs, a Per Packet Key. Azaz így gyömöszölik be 128 bitbe a 48 bites IV-t, a 256 bites Temporal Key-t és a 48 bites MAC numbert.

TKIP keret – forrás: darksoulstory.tistory.com

“a WEP-ben egyáltalán nincs semmilyen mechanizmus mely az üzenetek visszajátszásának detektálását lehetővé tenné. A tervezők nemes egyszerűséggel erről a biztonsági követelményről megfeledkeztek. A támadó tehát bármely eszköz korábban rögzített üzenetét vissza tudja játszani egy későbbi időpontban, s ezt a WEP nem detektálja.” Ezzel szemben “a TKIP az IV-t használja sorozatszámként. Ennek megfelelően, a TKIP előírja, hogy az IV értékét minden üzenetben eggyel növelni kell (a WEP-ben ez nem volt kötelező). A vevő nyílvántartja az utolsó néhány vett IV értéket. Ha egy frissen érkezett üzenet IV-je kisebb, mint a legkisebb nyílvántartott IV, akkor a vevő eldobja az üzenetet, míg ha az üzenet IV-je hagyobb, mint a legnagyobb nyílvántartott IV, akkor a vevő megtartja az üzenetet és módosítja a nyílvántartását. Ha egy vett üzenet IV-je a legkisebb és a legnagyobb nyílvántartott IV közé esik, akkor a vevő ellenőrzi, hogy az adott IV szerepel-e a nyílvántartásában. Ha igen, akkor eldobja az üzenetet, ha nem, akkor megtartja azt és módosítja a nyílvántartását.” (Buttyán – Dóra)

kulcshierarchia“A 802.11i szabvány bevezetéséig mindössze egyetlen titkos kulcs létezett a hitelesítésre és az adattitkosításra. Az új eljárásokban kulcskezelési és generálási hierarchiát vezettek be, hogy megoldható legyen a kulcsok rendszeres időközönkénti cseréje, ami ellehetetleníti a lexikonépítő és egyéb, a hálózati forgalom lehallgatása és utána abból a kulcs kinyerésére irányuló támadási lehetőségeket.

Az 1. ábrán látható hierarchia képezi az új szabvány biztonságának alapját. A MK (Master Key) a legfelső titok, melyet mind a kliensnek, mind pedig a hitelesítést végző eszköznek ismernie kell. A PMK-t (Pairwise Master Key) a mobil állomás és a hitelesítő szerver (AS) minden egyes bejelentkezésnél a Master kulcsból generálja. A hitelesítő szerver ezt a kulcsot elküldi a klienssel kapcsolatban lévő AP-nak, mely ezután engedélyezi a csatornán a kommunikációt. A PMK-ból 4-utas-kézfogással generál a kliens és az AP ideiglenes kulcsot (PTK).

Az ideiglenes kulcs (PTK Pairwise Transient Key) a PMK-ból származik, minden bejelentkezéskor illetve minden frissítési kérelemnél újra generálódik. A PTK generálásához a kliens és az AP MAC címét, valamint az általuk generált két álvéletlen számot ( nonce ) használják. A PTK egy kulcs csomag, mely tovább bontható kisebb csoportokra. Az első 128 (0-127) biten elhelyezkedő ún. kulcs ellenőrző kulcs (KCK Key Confirmation Key) azt a célt szolgálja, hogy az AP és a kliens leellenőrizze, valóban ugyanazzal a PMK-val rendelkezik. Célja a kulcs meghamisításának megakadályozása. A kulcskódoló kulcs (KEK Key Encryption Key) célja csoportos átmeneti kulcs (GTK Group Transienk Key) titkosított kiosztása, melyet az AP küld a kliens felé.

A csoportos kulcsot multicast és broadcast üzenetek titkosítására használhatják az egy csoportban lévő állomások és az AP. A GTK kulcsot az AP generálja le és osztja szét. A GTK nem tartozik a Pairwise hierarchiába. A Pairwise kulcshierarchia a unicast kommunikációhoz tartozó kulcsok képzésére vonatkozik. Az ideiglenes kódoló kulcs (Temporal Key) szolgálja az adatok kódolását, mely kódolás történhet RC4 vagy CCMP (AES-CCM Advanced Encryption Standard Counter Mode Encryption) algoritmusokkal.” ( Faigl)

  • Az IV vektor értékét tehát felemelik 24-ről 48 bitere, így nem lép fel IV ütközés (ismétlés).
  • Minden kulcskiosztás után újra 0-ról indul, ui. megváltozott a kulcs, így nem probléma az IV ütközésd.
  • A IV vektor értékét minden üzenetben 1-gyel növelik, így az IV egyben az üzenet sorszámaként is funkcionál, s ez nyújt védelmet az üzenet-visszajátszással szemben.
  • Dummy byte használatával elkerülik a gyenge kulcsok generálását.

Hitelesítés 802.1X szabvánnyal – a kulcsmanagement

“A 802.1X modell három résztvevőt különböztet meg a hitelesítés folyamatában: a hitelesítendő felet (supplicant), a hitelesítőt (authenticator), és a hitelesítő szervert (authentication server). … WiFi hálózatok esetében a hitelesítendő fél a mobil eszköz, mely szeretne a hálózathoz csatlakozni, a hitelesítő pedig az AP, mely a hálózathoz történő hozzáféfést kontrollálja. A hitelesítő szerver egy program, mely kisebb hálózatok esetében akár az AP-ben is futhat, nagyobb hálózatoknál azonban tipikusan egy külön erre a célra dedikált hoszton futó szerver alkalmazás.” A 802.1X szabvány esetén “a hitelesítés során létre kell jöjjön egy titkos kulcs a STA és az AP között, melyet azok a további kommunikáció kriptográfiai védelmére használhatnak. … Maga a hitelesítés az EAP (Extensible Authentication Protocol) segítségével történik” (Buttyán – Dóra)

“a hitelesítés eredményeként nemcsak a hálózathoz való hozzáférést engedélyezi a hitelesítő szerver, hanem egy titkos kulcs is létrejön, mely a mobil eszköz és az AP további kommunikációját hivatott védeni. Mivel a hitelesítés a mobil eszköz és a szerver között folyik, ezért a protokoll futása után ezt a kulcsot csak a mobil eszköz és a hitelesítő szerver birtokolja, és azt még el kell juttatni az AP-hez. A RADIUS protokoll biztosít erre használható mechanismust. … A kulcs rejtjelezett formában kerül átvitelre, ahol a rejtjelezés egy a hitelesítő szerver és az AP között korábban létrehozott (tipikusan manuálisan telepített) kulcs segítségével történik.” (Buttyán – Dóra)

“A hitelesítés során, a mobil eszköz és az AP között létrehozott titkos kulcsot páronkénti mesterkulcsnak (pairwise master key, vagy röviden PMK) nevezik. Azért „páronkénti”, mert csak az adott mobil eszköz és az AP ismeri (na meg a hitelesítő szerver, de az megbízható entitásnak tekinthető), s azért „mester”, mert ezt a kulcsot nem használják közvetlenül rejtjelezésre, hanem további kulcsokat generálnak belőle. Egészen pontosan a PMK-ból mind a mobil eszköz, mind pedig az AP négy további kulcsot generál: egy adat-rejtjelező kulcsot, egy adat-integritás-védő kulcsot, egy kulcs-rejtjelező kulcsot, és egy kulcs-integritás-védő kulcsot. Ezeket együttesen páronkénti ideiglenes kulcsnak (Pairwise Transient Key, vagy röviden PTK) nevezik. … A PTK előállításához a PMK-n kívül felhasználják még a két fél (mobil eszköz és AP) MAC címét, és két véletlenszámot, melyet a felek generálnak.” (Buttyán – Dóra)

kulcsmanagement – (Buttyán – Dóra)

A négyutas kézfogás

A négyutas kézfogás célja, hogy mindkét fél meggyőződjön arról, hogy a másik ismeri a PTK-t, a páronkénti ideiglenes kulcsot. Az előbb említett két véletlenszámot ekkor generálják a felek, amit aztán a PTK előállításához használnak fel.

  1. “Első lépésként az AP elküldi az általa generált véletlenszámot a mobil eszköznek. Mikor a mobil eszköz ezt megkapja, rendelkezésére áll minden információ a PTK előállításához. A mobil eszköz tehát kiszámolja az ideiglenes kulcsokat.
  2. A mobil eszköz is elküldi az általa generált véletlenszámot az AP-nek. Ez az üzenet kriptográfiai integritás-ellenőrző összeggel (Message Integrity Code, vagy röviden MIC) van ellátva, amit a mobil eszköz a frissen kiszámolt kulcsintegritás-védő kulcs segítségével állít elő. Az üzenet vétele után az AP-nek is rendelkezésére áll minden információ a PTK kiszámításához. Kiszámolja az ideiglenes kulcsokat, majd a kulcs-integritás-védő kulcs segítségével ellenőrzi a MIC-et. Ha az ellenőrzés sikeres, akkor elhiszi, hogy a mobil eszköz ismeri a PMK-t.
  3. Az AP is küld egy MIC-et tartalmazó üzenetet a mobil eszköznek, melyben tájékoztatja a mobil eszközt arról, hogy a kulcsokat sikeresen telepítette, és készen áll a további adatforgalom rejtjelezésre. Ez az üzenet tartalmaz továbbá egy kezdeti sorozatszámot. A későbbiekben ettől az értéktől kezdik majd sorszámozni a felek az egymásnak küldött adatcsomagokat, és a sorszámozás segítségével detektálják a visszajátszásos támadásokat. Az üzenet vétele után a mobil eszköz a kulcs-integritás-védő kulccsal ellenőrzi a MIC-et, és ha az ellenőrzés sikeres, akkor elhiszi, hogy az AP ismeri a PMK-t.
  4. Vegül a mobil eszköz nyugtázza az AP előző üzenetét, mely egyben azt is jelenti, hogy a mobil eszköz is készen áll a további adatforgalom rejtjelezésére.” (Buttyán – Dóra)

Egy kicsit részletezve egy másik forrás alapján, hogy a véletlen számok elküldéséből hogyan lesz kulcs. (Faigl).

“Emlékeztetünk arra, hogy a WEP titkosítás legfőbb hibáját az IV kis mérete és a gyenge RC4 kulcsok használata jelentette. A TKIP-ben ezért az IV méretét 24 bitről megnövelték 48 bitre. Ez egyszerű megoldásnak látszik, ám a nehézséget az okozza, hogy a WEP-et támogató hardverek adott hosszúságú (128 bites) értékkel inicializálják az RC4 algoritmust, s így a megnövelt IV-t, a rejtjelező kulccsal együtt, valamilyen módon „bele kell gyömöszölni” ebbe az adott hosszúságba. A gyenge kulcsok problémáját a TKIP úgy oldja meg, hogy minden üzenet rejtjelezését más kulccsal végzi. Így a támadó nem tud a sikeres támadáshoz szükséges számú, azonos (potenciálisan gyenge) kulccsal kódolt üzenetet megfigyelni. Az üzenetkulcsokat a TKIP a négy utas kézfogás során generált adat-rejtjelező kulcsból állítja elő.” (Buttyán – Dóra)

Ez tehát azt jelenti, hogy az ideiglenes kulcsok generálásához az állomás és az AP Mac number-ére és két véletlen számra van szükség a master kulcspár (PMK) mellett. Azaz elsőként az AC küldi el a saját MAC number-ét és egy véletlen számot az állomásnak, s az állomás vesz egy másik véletlen számot és a saját MAC numberét, s legenerálja az ideiglenes kulcsokat. Majd elküldi a saját MAC numberét és a saját véletlen számát, s az AC ezekből generálja le ugyanazokat az ideiglenes kulcsokat. Ezután az állomás által küldött véletlen számhoz legenerálja az ellenőrző kódot, amit összehasonlít az állomás által küldött ellenörző kóddal, s így állapítja meg, hogy ugyanazokat a kulcsokat használják.

kép forrása
A WEP evolúciója

WEP feltörése – elv

“Az RC4 több gyenge és támadásra alkalmas ponttal rendelkezik. Az egyik támadási módszer esetén egy egyszerű számjegyes eljárást alkalmaznak a támadók. Az IV csak 24 bites, így csak fix számú olyan permutáció létezik, amit az RC4 az IV-hez fel tud használni. Matematikailag 2^24 lehetséges IV-kombináció létezik. Ebben az esetben a kliens aktivitásától függően néhány óra, esetleg néhány nap a kód feltörése. A lehetséges IV-k száma korlátos, ami oda vezet, hogy az RC4 kénytelen egy idő múlva mindig ugyanazokat a karaktereket alkalmazni egy adott IV-hez. Tehát a támadó egy idő után felismerheti az ismétlődő IV-ket. Elég adat rendelkezésre állása esetén, meg tudja határozni az alkalmazott WEP-kulcsot. Ez egy úgynevezett Brute Force támadás, de ez a módszer időigényes más betörési módszerekhez képest. Ennek az az oka, hogy nemcsak 2^24 csomagot kell jegyzőkönyvezni, hanem ennek többszörösét. Egy másik támadási módszer azon alapszik, hogy léteznek ismert, gyenge IV-k. Ez az RC4 természetéből fakad. Az RC4 algoritmus egyes karakterekkel egyszerűen jobban működik, mint másokkal. Ebből származnak a gyenge 24 bites karakterek, de ezeket is felhasználja. Ha tehát ilyen gyenge karaktereket használnak, akkor a támadó néhány algoritmuson át tudja szűrni a lehallgatott adatokat és így képes meghatározni a WEP-kulcs részeit. Ez az eljárás egyik ismert implementációja 10-15 millió csomagot igényel a WEP-kulcs megtöréséhez. A kód megfejtése itt is hasonló módon néhány óra, esetleg néhány nap. ” (Fáji András: A vezeték nélküli hálózatok és biztonsági rései)

A WEP feltörése – a ChopChop támadás (Tomcsányi – Fóti)

“A WEP-csomag hibátlanságát CRC32-ellenőrzőösszeg állapítja meg. A hálózati forgalomban ugyan mind az adat, mint a CRC titkosítva utazik, de ha módosítunk a titkosított adatokon, a CRC újraírása révén még a megváltoztatott csomagokat is hitelesként fogadja el az AP. Emiatt a titkosítás megfejtése nélkül, vakon felül lehet irkálni a WEP-csomagokat, és addig lehet kalapálni, amíg a titkosított CRC is helyes lesz.

Ezt a „képességünket” felhasználva lehetőség adódik egy találgatós játékra. Fogunk egy csomagot, kiveszünk belőle egy bájtot. Ez lesz a titok számunkra. Vajon mi volt benne eredetileg? 0-tól 255-ig bármi lehetett. Tegyük fel, hogy amit levágtunk, annak tartalma 42. Újraszámítjuk a csonkolt csomag CRC-jét úgy, mint ha tényleg 42-t vágtunk volna le belőle, majd beküldjük őket az AP-nak. Ha a tippünk helyes, a CRC valóban helyes lesz, így a csonka csomagot az AP visszaküldi az éterbe. Ebből tudhatjuk, hogy nyertünk, 42=42! Ha nem, hátravan még 255 próba, és máris megvan az egyik bájt értéke.

Az eljárást megismételjük a csomag többi bájtjára is, így a kulcs ismerete nélkül el tudjuk olvasni a teljes csomagot. De ez még nem minden! Amint megvan egy teljes csomag cleartext változata, ezt össze kell XOR-olni a titkosított változattal, és megkapjuk a WEP kulcsot. Zsír :-)” (Tomcsányi Domonkos és Fóti Marcell – NetAcademia)

WPA feltörése – elv

“Ám, természetesen ez is feltörhető, köszönhetően eszes technikáknak. Ugyanis a WPA-nal, és a WPA2-nél is létezik egy olyan alfaj, amikor az SSID-ből és a jelszóból készít egy hasht az AP, és ezzel titkosít. Ezt az ún. WPA-Handshake-et akkor lehet elkapni, ha egy kliens éppen felcsatlakozik a hálózatra. Ha nincs senki a hálózaton, akkor szívás van, várni kell. Ha azonban valaki fenn van, akkor megfelelő kártyával (Intel pl. nem jó) ledobhatjuk a hálózatról, pontosabban felszólíthatjuk, hogy újra hitelesítse magát (DeAuthentication request). Miközben ezt kiküldtük, folyamatosan sniffeljük az átmenő csomagforgalmat, és elcsípjük a WPA-Handshake-et.” (EthicalHacking).

WPA feltörése ChopChop technikával (Tomcsányi – Fóti)

“A következő lépés a ChopChop-támadás alkalmazása WPA esetére. Ehhez először lássuk, mit változtattak meg a WPA-ban, hogy nekünk nehezebb dolgunk legyen.

Bevezették az MIC (Message Integrity Check) fogalmát: ez egy 64 bites karaktersorozat, amely kiegészíti a szimpla ICV-t (Integrity Check Value – a nyílt üzenetre számolt CRC érték), így nem csak a könnyen megoldható CRC32 áll ellent a támadónak, hanem eme, a Michael-függvénynek nevezett algoritmussal generált összeg is. A másik nagy változás, hogy létrehoztak egy „szekvenciális számolót” és ez vigyáz arra, hogy a csomagok sorrendben érkezzenek a fogadó félhez. A counter működése egyszerű: minden érkező csomag hatására eggyel nagyobb lesz az értéke. Ha aztán később valaki egy rögzített csomagot szeretne visszaküldeni, akkor a nagyobb számlálóérték miatt ez meghiúsul.

A nagyobbik gond azonban az MIC-vel van: ezt nagyon szigorúan veszi a szabvány: ha 2 db MIC hiba fordul elő egy percen belül, akkor leáll a kapcsolat, és egy 60 másodperces szünet után indítja csak el az AP a kapcsolatújrafelvételi-kérelmet a kliens felé – új kulccsal. Ez eléggé behatárolja a támadót.

Ezek után van még valaki, aki elhiszi, hogy sikeres lehet a támadás? Nos, akik igennel válaszolnának, azoknak lett igazuk: igen, még ezek ellenére is véghez lehet vinni. Mi hát a megoldás? A QoS, azaz a Quality of Service WiFi-be integrált megoldása: egy adott csatorna fel van osztva nyolc különböző alcsatornára, így egy eszköz csatornán belül egy másik alcsatornára válthat a kommunikáció folyamán, hogy jobb átviteli minőséget érjen el. „Szerencsére” minden alcsatornához egyedi counter tartozik, valamint a kliensek szinte mindig csak a nullás alcsatornát használják. Ez azt jelenti, hogy szinte mindig találunk egy olyan alcsatornát, ahol alacsonyabb a counter értéke, így a csomagunkat el fogja fogadni az AP! Mehet a ChopChop!

Sőt, szegény MIC hiába próbál védekezni, kompatibilitási okokból úgy építették fel a WPA-t, hogy először az ICV-ellenőrzés fut le, és ha ez rendben, akkor következik a MIC-ellenőrzés! Tehát a ChopChop által használt, hibás ICV-kre épülő találgatás teljes sebességgel rohanhat egy másik alcsatornán. Még mindig zsír 🙂

Ha az ICV-találgatásunk helyes volt, a feldolgozás végre-valahára eljut a MIC-ig, ami nyilván hibás, mert azt nem tudjuk helyesre pofozni (kapunk egy MIC Failure Reportot). Összegezve: percenkét egy bájtot találhatunk ki, ennyit adott nekünk a szabvány 🙂

Tetszőleges csomagon 8 perc alatt ki tudjuk találgatni a MIC (8 bájt) titkosítatlan értékét, ami később még jól fog jönni. Kellene még egy plaintext, hogy az egészet beletehessük egy megfordított Michael algoritmusba (mivel a függvényt kétirányúnak tervezték) és megkapjuk a titkosításhoz használt MIC kulcsot. Honnan szedjünk plaintextet?

Most jön a csavar. Ha ARP csomagot használunk fel, ami könnyen felismerhető jellegzetes hosszáról (42 bájt), abban már egy csomó adatot eleve ismerünk, hiszen az ARP-ben IP-címek és MAC Addressek utaznak! A MAC Addresseket tudjuk, mert titkosítatlanul repülnek az Ethernet fejlécben (különben nem ismernék fel a csomagot a hálókártyák), általában az IP-címtartományt is ismerjük. Mindössze két bájtot nem ismerünk belőle: a két IP-cím utolsó bájtját!

A két IP-bájtot két ChopChop-pal kitaláljuk (2 perc), és most már kezünkben tartjuk a teljes clear textjét egy WPA-val titkosított csomagnak!” (Tomcsányi Domonkos és Fóti Marcell – NetAcademia)

A szomszéd WiFi-jének a feltörése Linuxon – egyelőre nem sikerült

A sudo airmon-ng start <hálózati interface neve> paranccsal monitor módba helyezem a wlp2s0 nevű WiFi hálózati interfészemet (a wlan interfeszt, nem az ethernet interfészt! a nevük megállapítása ifconfig paranccsal), ami ekkor a wls2s0mon névre vált át. Erre nem minden WiFi hálózati kártya képes. Majd a sudo airodump-ng <hálózati interface neve> paranccsal monitorozom a WiFi forgalmat a környezetemben.

• BSSID: A wifi router ( Access Point / AP ) MAC címe
• PWR (Power): Jelerősség dBm -ben (-50 dBm a legerősebb)
• Beacons: Az AP által küldött ébrenléti csomagok, ezek alapján hírdeti magát
• Data: A wireless router által küldött adat csomagok számát jelöli
• CH (Channel): Az AP csatorna száma
• #/s: Az AP által küldött csomagok száma másodpercenként
• MB: Access Point által támogatott maximális adatátviteli sebesség
• ENC: A titkosítás típusát határozza meg ( WEP / WPA / WPA2 )
• Cipher: A titkosítás algoritmusát határozza meg ( TKIP / CCMP / Mixed )
• ESSID: A vezetéknélküli hálózat neve

A MAC cím kiválastása után az adott access point forgalmát elkezdjük monitozozni és egy ‘eredmeny’ nevű fájlba menteni a sudo airodump-ng -c <csatorna száma> –bssid <kiválasztott AC MAC numbere> -w <fájl neve> <monitorozó wlan kártyánk neve> paranccsal.

A parancssorban látjuk futni a monitorozott adatokat. Akkor eredményes a monitorozás, ha a jobb felső sarokban megjelenik a WPA handsake: <MAC address> felirat, ekkor ugyanis elkaptunk egy handshake-t, s ezt tudjuk feltörni majd a jelszó kinyeréséhez. Ezután a sudo aircrack-ng eredmeny-01.cap paranccsal ellenőrizhetjük, hogy elkaptuk a kézfogást, ami az eredcmeny-01.cap (aktuális szám) fájlban lesz.

Ezután a töréshez szükségünk lesz egy szótárfájlra. Én a rockyou.txt worldlist-et használtam, amit a githubról töltöttem le. A törést a sudo aircrack-ng eredmeny-01.cap -w szotar.txt paranccsal indítjuk el. A rockyou.txt szótárral nekem három óra alatt futott le a program, de nem talált törést a WiFi jelszavára.

Irodalom a töréshez:

www.webelektronika.com/article/20171017Wifi-halozat-teszteles

ethical.inf.elte.hu/wiki/Wifi_elleni_t%C3%A1mad%C3%A1sok