A 802.11 WLAN biztonsági oldalának bemutatása OMNeT++ szimuláció segítségével

Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Híradástechnikai Tanszék Mobil Távközlési és Informatikai Laboratórium A 802.11 WLAN biztonsági oldalának bemutatása OMNeT++ szimuláció segítségével Faigl Zoltán, V. Vill. szlaj@mcl.hu Konzulensek: Dr. Imre Sándor, BME-HIT Szalay Máté, BME-HIT TDK 2002

Tartalomjegyzék TARTALOMJEGYZÉK... 2 1. BEVEZETÉS... 4 2. BIZTONSÁG... 5 2.1. A biztonság fontossága növekvőben... 5 2.2. Biztonsággal kapcsolatos alapfogalmak... 5 2.3. A biztonsági tulajdonságok biztosítása... 6 2.4. Kulcsmenedzsment... 8 3. 802.11 WLAN... 10 3.1. A 802.11 WLAN bemutatása... 10 3.1.1. Szabvány... 10 3.1.2. Struktúra... 10 3.1.3. 802.11 protokoll-architektúra... 11 3.1.4. Fizikai réteg... 12 3.1.5. MAC réteg... 12 3.1.6. A 802.11 szolgáltatásai... 14 3.2. A 802.11 biztonsága... 15 3.2.1.Authentication... 15 3.2.2. Privacy... 16 3.2.3. Kulcsmenedzsment... 17 3.3 A 802.11 Biztonságának jellemzése... 18 3.4. Lehetséges támadások... 19 3.4.1. Ismert nyílt és titkosított szöveg (known plaintext and ciphertext attack)... 19 3.4.2. Csak a titkosított szöveg ismert (known ciphertext attack)... 19 3.4.3. Denial of Service (DoS) támadás... 19 3.5. Összefoglalás... 19 4.OMNET++... 20 4.1 Mi az OMNeT++?... 20 4.2. Az OMNeT++ általános jellemzése... 20 4.3 OMNeT++ szimuláció elkészítésének általános módja... 21 5. SZIMULÁCIÓ... 22 5.1. A szimulációs program elkészítésének menete... 22 5.2. Szimuláció felépítése... 22 2

5.3. A szabvány feldolgozása... 22 5.3.1. Első fázis: station scanning... 23 5.3.2. Második fázis: Hitelesítés... 24 5.3.3. Harmadik fázis: Association... 25 5.3.4. Negyedik fázis: Üzenetküldés... 25 5.3.5. A felhasznált MIB paraméterek... 26 5.4. A szimuláció... 27 5.4.1. Modulstruktúra... 27 5.4.2. MIB adatbázis kialakítása... 27 5.4.3. OMNeT++... 27 5.5. Szimuláció működésének bemutatása... 28 5.5.1. A szimuláció futása során kiírt üzenetsor bemutatása... 28 5.5.2. 'Run'-ok... 28 5.6. Dos támadás szimulációja... 31 6. KONKLÚZIÓ... 33 7. FÜGGELÉK... 34 7.1. Rövidítések... 34 7.2. Szimuláció működésének menete... 34 7.3. Omnetpp.ini... 39 7.4. Részletek a [Run 1] és [Run 4] futtatása során kiírt üzenetsorból... 40 7.4.1. [Run 1] Shared Key hitelesítéssel... 40 7.4.2.[Run 4] Open Sytem hitelesítéssel... 40 7.5. Denial of Service támadás során kiírt üzenetsor... 42 7.6. A szimulációban szereplő üzenetek célja és paramétereik... 44 7.6.1. Állomás scanning fázis... 44 7.6.2. Hitelesítés fázis... 46 7.6.3. Association fázis... 48 7.6.4. Üzenetküldés fázis... 49 8. IRODALOMJEGYZÉK... 51 3

1. Bevezetés A mobil, vezetéknélküli rendszerek biztonságos adatátvitele gazdasági és politikai szempontból is igen fontos, mert dinamikusan fejlődnek azok a mobil szolgáltatások, amelyek pénzmozgást vagy bizalmas gazdasági (egyéb) információk továbbítását teszik lehetővé. A biztonságos adatátvitel kérdéseivel, fejlesztésével több éve foglalkoznak a BME Híradástechnikai Tanszékén. Ebbe a munkába kapcsolódtam be 2000 tavaszán. Kezdetben dr. Imre Sándor vezetésével tanulmányoztam a 802.11 WLAN hálózatok biztonságát elemző igen gazdag irodalmat. Ebből született a 2002 májusi HTE diákkonferenciára "A 802.11 WLAN biztonsági kérdései" című előadás. Sajnos ekkor még nem állt rendelkezésünkre megfelelő szemléltető eszköz, amellyel a WLAN 802.11 üzenetváltásait, és a lehetséges támadásokat mutatta volna meg. Ezért célul tűztük ki egy olyan szimulációs program elkészítését, amely a 802.11 WLAN szabvány által előírt kapcsolat-felépítési lépéseket szemlélteti infrastruktúrált hálózatban. TDK dolgozatomban ennek a szimulációs programnak a fejlesztéséhez kapcsolódó irodalomkutatási és programozási tevékenységemről, valamint az elkészült modellről számolok be. A fejlesztő munka egyes fázisainak jobb megértésének céljából TDK dolgozatom 2. fejezetében a biztonsággal kapcsolatos alapfogalmakat foglalom össze, 3. fejezetében 802.11 WLAN hálózat bemutatására kerül sor, majd a 4. fejezetben az OMNeT++ szimulációs környezetről írok. Ezután, az 5. fejezetben térek rá a szimulációs modell elkészítési menetének, és magának a szimulációnak a bemutatására. A 7. fejezet (Függelék) a modell működését bemutató szimuláció esetek leírását tartalmazza, és összegyűjti, illetve definiálja a szimulációban alkalmazott összes üzenetet. 4

2. Biztonság 2.1. A biztonság fontossága növekvőben Egy hálózat üzemeltetőjének és a felhasználónak érdekében áll biztosítani azt, hogy csak a jogosult személyek férhessenek hozzá a hálózat szolgáltatásaihoz. Egy támadó ne manipulálhassa, ne használhassa fel saját céljaira a hozzáférésre jogosult személy adatait, üzeneteit. Azáltal, hogy egyre nő az elektronikus úton továbbított bizalmas információk mennyisége, illetve, hogy a távközlésben tapasztalható konvergencia hatására bárki, bármilyen információt, bárhonnan elér, egyre nagyobb szükség van adatbiztonságra. Tény, hogy egyre inkább teret hódítanak azok az internetes, illetve mobil internetes szolgáltatások, amelyek pénzmozgást, bizalmas információk cseréjét tesznek lehetővé. Ilyen szolgáltatások például a mobile trading, -banking, -ticketing, -betting, -shopping [12]. Többek között az ezekhez hasonló, jövőben feltehetően tömegesen használt szolgáltatásoknál merül fel a megfelelő biztonság megteremtésének kérdése. 2.2. Biztonsággal kapcsolatos alapfogalmak A megfelelő biztonság megteremtéséhez először is tisztázni kell, mik azok a tulajdonságok, biztonsági célkitűzések, amelyeknek teljesülnie kell ahhoz, hogy biztonságos kommunikációról beszélhessünk[7-14]. Csak ezt követően érdemes arról beszélni, hogy milyen módon valósítjuk meg azt. Most tehát néhány biztonsággal kapcsolatos fogalom tisztázása következik, ehhez nyújt segítséget a 2.1. ábrán látható illusztráció. 2.1. ábra Biztonsággal kapcsolatos alapfogalmak összefoglalása A biztonságos kommunikációra érvényes tulajdonságok vagy a partnerre vagy az üzenetre, vagy a partner és az üzenet kapcsolatára vonatkoznak. A partnerre, vagy más néven kommunikáló félre érvényes egyik tulajdonság a partnerhitelesség [8, 9, 10, 11, 12]. A partner akkor bizonyul hitelesnek, ha bizonyítja, hogy tényleg az, akinek vallja magát. A partnerhitelesítés tulajdonképpen a személyazonosítással analóg. Jobb esetben a felek kölcsönösen leellenőrzik egymás hitelességét, vagyis kölcsönös partnerhitelesítés [8, 9, 10, 11, 12] történik közöttük. A másik partnerre vonatkozó biztonsági célkitűzés a kommunikáló felek személyére, elhelyezkedésére vonatkozó információknak bizalmas kezelése, kívülállónak ne tudódjanak ki ilyen jellegű információk. Ezt nevezik a partner személye bizalmasságának [8, 9, 10, 11, 12]. A következő két jellemző már az üzenetre vonatkozik. Egyik az üzenet integritása [8], amely az üzenet sértetlenségét jelzi, vagyis azt, hogy kitudódjon az, ha egy harmadik fél manipulálta, átírta a küldött információt. A másik jellemző a titkosság [8, 12, 13]. Titkos az üzenet, ha csak a címzett személy képes azt elolvasni. 5

A partner-üzenet kapcsolatot hivatott leellenőrizni az üzenet eredetének hitelesítése [8]. Ezáltal azt igazolják, hogy az üzenetet tényleg a ráírt feladó küldte el, és nem egy előzőleg hitelesített partner nevében próbál valaki üzenetet küldeni a címzettnek. A letagadhatatlanság [10, 11] szintén egy olyan tulajdonság, amely a partner-üzenet kapcsolatra vonatkozik. Ez arról ad biztosítékot, hogy utólag egyik fél se legyen képes letagadni, hogy valamilyen üzenetet küldött a másiknak, valamilyen szolgáltatást nyújtott vagy kapott. Ez például a reklamáció lehetőségét biztosítja internetes vásárlás esetén. Nagyrészt ezek tehát azok a tulajdonságok, amelyeknek érvényesnek kell lenniük a biztonságos kommunikációra. 2.3. A biztonsági tulajdonságok biztosítása A következő kérdés az, hogy hogyan lehet ezeket a tulajdonságokat garantálni. A partner személyének bizalmasságát a kapcsolat felépítés során történő ideiglenes előfizetői vagy felhasználó azonosító kiosztásával lehet elérni [9, 10]. Ez azt eredményezi, hogy a küldött üzenetekben a feladó, illetve címzett helyén ideiglenes nevek fognak szerepelni, ezáltal névtelenségbe burkolóznak a felek. A partnerhitelesítés általában kihívásválasz algoritmus segítségével történik [8, 9]. Ilyenkor a 2.2. ábrán látható módon, a hitelesítő fél (A) egy kihívást küld a hitelesítésre váró oldalnak (B-nek), aki, miután vette a kihívást, valamilyen szabványosított algoritmus segítségével, egy csak a kettőjük által ismert közös titok alapján létrehozza rá a megfelelő választ. Ezután visszaküldi a választ A-nak, aki leellenőrzi annak helyességét. Ezt úgy teszi meg, hogy ő is létrehoz egy várt választ, és összeveti a B-től kapottal. Ha a kettő megegyezik, akkor B hitelesnek bizonyult, mivel ismerte a közös titkot. A ezután sikeres hitelesítés üzenetet küld B-nek. Ha a várt válasz nem egyezik a B által küldöttel, akkor nem sikeres a hitelesítés. Ez azt eredményezi, hogy nem épülhet fel biztonságos kapcsolat a felek között. Kölcsönös partnerhitelesítésnél A-t is hitelesíteni kell. Ez egy egyszerű szerepváltással érhető el. Tehát B is létrehoz egy kihívást, amelyre A-nak kell most jól válaszolnia ahhoz, hogy hitelesnek bizonyuljon. 2.2. ábra Kihívás-válasz algoritmus Sikeres kölcsönös hitelesítés után már megbízhat egymásban a két fél. Mindketten biztosak lehetnek afelől, hogy nem a másik nevével élve próbál egy harmadik fél kapcsolatot felépíteni velük. A kölcsönös hitelesítés alapja tehát egy közös titok ismerete [8, 10]. A közös 6

titok a hitelesítő kulcs. Nagyon fontos, hogy biztonságos úton osszák szét és tárolják a hitelesítő kulcsokat. Lehet tanúsítvány felmutatásával is hitelesíteni egymást [8, 13]. Ha mindkét fél megbízik egy harmadik személyben, aki tanúsítja, hogy az adott fél hiteles, akkor ez a módszer is működhet. A tanúsítványon szerepelnie kell a megbízható személy aláírásának, egy nem túl régi dátummal. A következő garantálandó tulajdonság a titkosság, ami az üzenet titkosításával érhető el. A 2.3. ábra a titkosítás és a visszafejtés menetét ábrázolja. Nem maga a titkosító algoritmus titkos. A titkosító algoritmus azokat a titkosítás és dekódolás során elvégzendő matematikai műveleteket fedi, amelyek elvégzése után a nyílt, titkosítatlan szövegből előáll a titkosított szöveg, illetve a titkosított szövegből létrejön a nyílt szöveg [8, 14]. A titkosító algoritmusok szabványban rögzítettek. Elvileg nem hozzáférhetők, de mivel a titkosságot nem ők hordozzák, közzétételük sem okoz különösebb gondot. Amit egyedül a felek ismernek, és ami a titkosságot hordozza, az a titkosításnál és dekódolásnál használt kulcs. A kulcs egy olyan bitsorozat, amely egyértelműen meghatározza egy adott algoritmus transzformációit [8, 14]. A kulcsok alapján kétféle titkosító algoritmust lehet megkülönböztetni: az egyik a szimmetrikus vagy rejtett kulcsú algoritmus, a másik az aszimmetrikus vagy nyílt kulcsú algoritmus. 2.3.ábra Szimmetrikus és aszimmetrikus titkosítás A szimmetrikus titkosítási algoritmus esetében a titkosításnál és a dekódolásnál ugyanazokat a kulcsokat, vagy legalábbis egymásból származtatható kulcsokat alkalmaznak. A küldött üzenet bizalmassága tehát csak azon múlik, hogy úgy egyezzenek meg a felek a titkosító kulcsról, hogy az semmiképpen se tudódhasson ki mások előtt. Ezért hívják rejtett kulcsú titkosításnak is ezt a titkosítást. Előnye az, hogy a szimmetrikus kulcsú algoritmusok gyorsak és egyszerűek [8, 14]. A másik fajta titkosítási algoritmus a nyílt kulcsú vagy aszimmetrikus algoritmus. Ebben az esetben különböző kulcsokat használnak a titkosításhoz és dekódoláshoz. A titkosításhoz használt titkosítási kulcs publikus, a visszafejtéshez szükséges kulcs titkos. Bárki használhatja a publikus kulcsot nyílt üzenet titkosítására, azonban egyedül a privát kulcs birtoklója képes az üzenetet visszafejteni. A címzett publikus kulcsát le lehet kérni egy kulcstárhelyről. Tehát semmiféle előzetes kommunikáció nem szükséges a feladó és a címzett között, hogy megtárgyalják az éppen aktuális titkosító kulcsot. Ez a lekérdezés egyben a legérzékenyebb pontja a rendszernek, mert ha a támadó a tárhely és a kérdező közé áll, kicserélheti a lekért publikus kulcsot a sajátjára, és így másnak szóló bizalmas információt vissza tud majd fejteni. Erősen őrizni kell a publikus kulcsok tárhelyét, és a lekérdezéseket biztonságossá kell tenni. A nyílt kulcsú titkosítási algoritmus hátránya, hogy sokkal számításigényesebb a rejtett 7

kulcsúnál, hosszabbak a kulcsok, időigényesebb a titkosítás és a visszafejtés. Emiatt mobil rendszereknél szimmetrikus kulcsú titkosítást használnak inkább. [8, 14] Az üzenet integritásának ellenőrzésére szolgálhat az ellenőrző összeg, amit a küldő fél az üzenettel együtt átküld a címzettnek [14]. Ha vételi oldalon más összeget számolnak ki, mint amit átküldött a feladó, akkor sérült az üzenet integritása. Az érték kiszámolásához használt algoritmust a támadó is ismerheti, így ha manipulálta az átvitel során az üzenetet, akkor az ellenőrző összeg változtatásával ki tudja kerülni, hogy a vevő észrevegye a változtatást. Másik lehetőség integritásellenőrzésre a pecsét (MAC kód) használata. [14, 8] Létrehozási módját a 2.4. ábra mutatja. Ez az integritásellenőrzés mellett az üzenet eredetének a hitelességét is garantálja. A pecsét egy fix hosszúságú bitsorozat, ami egy egyirányú hash függvény eredménye. A hash függvény bemeneti paraméterei egyrészt maga az üzenet, másrészt egy szimmetrikus kulcs, amely biztosítja, hogy csak a kulcs ismerője, a megfelelő feladó küldte az üzenetet. A pecsét alkalmas tehát üzenet eredetének hitelesítésére. Csak az képes ellenőrizni érvényességét, aki ismeri a szimmetrikus kulcsot. Nem nyújt letagadhatatlanságot, ugyanis a bemeneti paraméterek alapján nem deríthető ki egyértelműen, hogy melyik fél küldte az üzenetet, mivel mindkét oldal ugyanazt a titkos kulcsot használja a pecsét generálásánál. 2.4.ábra Pecsét létrehozása Harmadik lehetőség a digitális aláírás [8, 12, 13, 14]. A digitális aláírás nemcsak integritásellenőrzésre és üzenet eredetének hitelesítésére jó, hanem partnerhitelesítést is nyújt és ezzel együtt az üzenet letagadhatatlanságát is garantálja. Az aszimmetrikus titkosítás (2.3.ábra) fordítottja. Itt az aláírás képzéséhez (kódolásához) szükséges kulcs privát, és az ellenőrzéséhez szükséges kulcs publikus. Digitális aláírást tehát egyedül a privát kulcs tulajdonosa generálhat, míg azt bárki, bármikor leellenőrizheti a nyilvános kulcs segítségével. 2.4. Kulcsmenedzsment A kulcsmenedzsment jelenti a kriptográfiai kulcsok generálását, tárolását, cseréjét, szétosztását, törlését, stb [7, 8, 10, 13]. Előzőekből kiderült, hogy az összes biztonsági szolgáltatás lelke a kulcsok biztonságos szétosztása, tárolása, kezelése. A kulcsok létrehozása többféleképpen történhet. A kommunikáló felek megbeszélhetik maguk között a kulcsokat, vagy esetleg igényelhetik egy megbízható harmadik fél ellenőrző szerepét. Létezik olyan eset is, amikor az egyik fél, mondjuk a hálózat, a másik fél beleszólása nélkül egyszerűen kiosztja a kulcsokat. Általában nem az történik, hogy minden egyes kapcsolathoz külön megbeszélik a kulcsokat. Egyetlen mester kulcs kerül megállapításra, és ebből előre rögzített algoritmusokkal mindenki saját magának kiszámolja a titkosító, integritásellenőrző, hitelesítéshez használt kulcsokat. A mester kulcs létesítésére használt egyik módszer az ún. Diffie-Hellman protokoll [7, 8, 9]. Ilyenkor az 2.5. ábrán látható módon a két fél egy-egy résztitkot küld át egymásnak (A-t és B-t), amiből egyedül ők képesek létrehozni a 8

mesterkulcsot (K AB ). Más, a küldött résztitkokból nem képes rekonstruálni a közös titkot. A Diffie-Hellman protokoll nem igényel harmadik személyt a közös titok létesítéséhez. 2.5. ábra Diffie-Hellman kulcscsere Egy másik módszert jelent a kihívás-válasz algoritmus során származtatott kulcs, ahogy a 2.2. ábra mutatja [7, 9]. Ebben az esetben nem változtatják a mesterkulcsot. Minden egyes felhasználó kap egy saját mesterkulcsot, amikor előfizet a hálózat valamilyen szolgáltatására. Amikor a felhasználó kapcsolatot létesít valakivel, a hálózat elküld neki egy kihívást. A felhasználói és a hálózati oldal a kihívás és a mesterkulcs segítségével számolja ki a kapcsolatra érvényes kulcsokat. Harmadik módszer lehet, az, hogy manuálisan kiosztják a kulcsokat [1, 3-5]. Ez azzal a veszéllyel jár, hogy nem frissítik kellő gyorsasággal őket. A fent említett módszerek közös vonása, hogy magát a kulcsot nem viszik át a rádiócsatornán. A kulcsmenedzsment egyik fontos kérdése, hogy milyen gyakran kell frissíteni a kulcsokat, ahhoz, hogy azok ne kompromittálódhassanak. Ha könnyen visszafejthetőek a kulcsok, akkor biztos, hogy gyakrabban kell cserélni a kulcsokat, egy kommunikáció lefolyása alatt akár többször is. A gyakori kulcscsere mellett azonban lehet másként is erősíteni a titkosító, integritásellenőrző, hitelesítő algoritmusok biztonságát. Az aktuális időt, mindkét oldalon külön futtatott, összeszinkronizált számláló értékét, a másik fél által küldött kihívást és más az adott kommunikációra érvényes információkat is fel lehet használni a titkosítási és más algoritmusok bemeneti paramétereként [15]. Így például ugyanaz a kulcskészlet eltérő időpontokban más és más titkosított üzenetet eredményez. Ha egy támadó megszerzi a kulcsokat, akkor is tehetetlen marad aktív támadás alkalmazásánál, mivel olyan személyes információkat is felhasználnak a felek, amiről ő nem tudhat. 9

3. 802.11 WLAN 3.1. A 802.11 WLAN bemutatása Az eredeti 802.11 WLAN szabvány egy főleg beltéri környezetben használatos, rövid hatósugarú (100 m), maximum 2 Mbit/s névleges bitsebességű rádiós LAN hálózatot ír le [1]. 3.1.1. Szabvány A szabványt az amerikai IEEE szabványosítási szervezet dolgozta ki, és része annak a szabványcsaládnak, amely LAN és MAN hálózatokat specifikál. A 3.1. ábrán a különböző szabványok egymáshoz képesti viszonya látható. [1] 3.1.ábra 802.11 szabvány helye a 802.X szabványok között 3.1.2. Struktúra A 802.11 vezetéknélküli lokális számítógép-hálózat alapvetően kétféle struktúrát enged meg, központosítottat és ad-hoc-ot [1]. A központosított hálózatban (3.2.ábra) az állomások (station, STA) az ún. hozzáférési ponton (access point, AP) keresztül tudnak egymással kommunikálni és esetleg más hálózatokhoz hozzáférni. A hozzáférési pont (AP) felügyeli, vezérli a kommunikációt, felé irányul és tőle távozik minden forgalom. Ezt a működési módot hívja a szabvány Basic Service Set-nek (BSS). 3.2.ábra - Központosított struktúra (BSS) Ad-hoc struktúra esetén (3.3.ábra) az egymáshoz közel álló állomások közvetlenül összekapcsolódnak. A felügyelő és vezérlő feladatot mindig valamelyik állomás látja el. Ha a kommunikáló felek nem látják egymást, akkor köztük lévő állomások látják el a gateway (csomagtovábbító) szerepet. A szabvány Independent Basic Service Set-nek (IBSS) nevezi ezt a működési módot. 10

3.3.ábra - Ad-hoc struktúra (IBSS) Minden állomásnak mindkét struktúrát támogatnia kell. Ha kapcsolat-felépítés során az állomás nem talál hozzáférési pontot, amihez csatlakozzon, akkor ő maga kezdeményezheti egy IBSS létrehozását [1]. Ilyenkor hozzáférési pontként kezd működni, egy saját BSS létrehozásába kezd. A központosított módban működő hálózatokat (BSS) össze lehet fogni egy nagyobb struktúrába, amit Extended Service Set-nek (ESS) hív a szabvány (3.4.ábra). Erre azért van szükség, mert egy állomás által belátott terület mérete nem mindig elegendő ahhoz, hogy két távoli állomás kommunikáljon egymással. Wireless Medium-nak (WM) nevezi a szabvány azt a médiumot, amin keresztül két állomás képes a fizikai rétegük között PDU-t átvinni. 3.4.ábra - Extended Service Set (ESS) ESS esetén a BSS-eket az ún. Distribution System (DS) kapcsolja össze. A DS különböző WM-okban elhelyezkedő állomások között képes MAC SDU-k átvitelét szolgáltatására. Egy ESS akkor képes mobilitás szolgáltatást nyújtani, ha a DS követni tudja az állomások tartózkodási helyének változását, és mindig megfelelő hozzáférési ponthoz irányítja a helyét változtató állomás címére küldött üzenetet. A hozzáférési pontoknak folyamatosan követniük kell, milyen állomások tartózkodnak körzetükben. A hozzáférési pont (AP) egy olyan speciális állomás, amelyen keresztül a többi állomás hozzáférhet a DS-hez, vagyis, azon kívül, hogy állomásként működik, Distributig System szolgálatot is nyújt [1]. 3.1.3. 802.11 protokoll-architektúra A 802.11 szabvány háromféle fizikai réteget és egy MAC réteget definiál. Protokollarchitektúráját a 3.5. ábra mutatja [1]. 11

3.5.ábra 802.11 által definiált protokoll-architektúra 3.1.4. Fizikai réteg 2 Mbit/s-os névleges adatátviteli sebességet képes nyújtani mind a három fajta fizikai rétegével. Az újabb (802.11b) WLAN kártyák névleges 11 Mbit/s adatátviteli sebességre képesek. A fizikai réteg tovább bontható két alrétegre, és a felhasználói síkon kívül még egy síkra [1]: A PMD (Physical Medium Dependent) alrétegből háromféle létezik, külön az FHSS (Frequency Hopping Spread Spectrum), DSSS (Direct Sequence Spread Spectrum ) és IR (Baseband Infrared) átviteli módra. Feladata a jel kódolása, modulálása, demodulálása. A PLCP (Physical Layer Convergence Protocol) alréteg az aktuális jelátviteli módnak megfelelően keretezi és adja át a MAC SDU-kat (MAC Sevice Data Unit) a PMD alrétegnek. PHY menedzsment a fizikai réteg menedzsment síkja. Feladata a másik két alréteg menedzselése, paraméterek szolgáltatása a különböző primitíveknek. Ilyen feladatok például a fizikai csatorna állítása, adatok szolgáltatása a MIB adatbázisból (Management Information Base). 3.1.5. MAC réteg Manegement-sík: A MAC Management sík feladata minden MAC rétegen futó szolgálat kezdeményezése, azok eredményének begyűjtése, a különböző MAC primitívekhez paraméterek szolgáltatása. Itt található a MAC MIB adatbázis, amely az állomás működését befolyásoló paramétereket tartalmazza. Adatsík: A MAC réteg egyik fő feladata a küldött MAC SDU-k ütemezése oly módon, hogy az egy WM-ben található állomások üzenetei ne ütközzenek, egy állomás ne kezdjen akkor adni, amikor egy másik még éppen adásban van. Ezt a feladatot a 802.11 rendszerben alapértelmezettként CSMA/CA közeghozzáférési móddal oldották meg. A MAC réteg másik fő feladata a különböző 802.11 szolgálatok biztosítása. Ezek vagy a MAC SDU-k szomszédos MAC réteghez történő eljuttatását szolgálják, vagy a 802.11 LANhoz való hozzáférést szabályozzák. 3.1.5.1. CSMA/CA A 802.11 MAC rétegének alapvető közegférési módja a DCF (Distibuted Coordination Function) vagy ismertebb nevén Carries Sense Multiple Access / Collision Avoidance, ami 12

vivőérzékeléses többszörös hozzáférést jelent, ütközés megelőzéssel [1]. Ez a következőket jelenti. Mielőtt egy állomás adásba kezd, fizikai rétege segítségével leellenőrzi a rádiós közeg foglaltságát. Ezt hívják fizikai vivőérzékelésnek. Ha nincs adás, akkor véletlen idő múlva adni kezd, de nem rögtön a hasznos adatot (a MAC SDU fragment-et). Először egy Request to Send (RTS) üzenetet küld a címzettnek, aki ha képes fogadni az adatot, egy Clear to Send (CTS) üzenettel válaszol. Ezután küldi el a feladó a hasznos adatot a címzettnek. Ha a címzett vette az adatot, azonnal pozitív nyugtát (ACK üzenet) küld vissza. Az RTS, CTS, ACK üzenetet mindenki látja a WM-ben. Ezek hordoznak adás idejére vonatkozó információt is. Más állomás addig nem kezd adni, amíg a megjelölt idő le nem telik. Ennek az időnek a figyelését - és az adás visszatartását eddig az ideig - hívják virtuális vivő érzékelésnek. A virtuális és fizikai vivőérzékelés ellenére történhet ütközés, miután egy állomás befejezte adását. Ezért kell véletlen hosszú ideig várni az adással az előző adás befejezését követően. CSMA/CA-val best effort átvitel valósul meg az állomások között. [1] Központosított struktúrájú hálózatnál lehet választani PCF (Point Coordinated Function) közeghozzáférési módot is [1]. Ebben az esetben az AP ütemezi, hogy melyik STA üzenhet. Ehhez azonban kell az állomás bizonyos fokú támogatása. PCF esetén, ha egy állomás adásjogot kap, akkor biztos lehet abban, hogy üzenetei nem fognak ütközni máséval. Fontos kérdés az állomások esetében a power-saving, azaz az energiával való takarékoskodás [1]. Egy állomás lehet aktív módban, ilyenkor DCF és PCF esetén is teljes energiafogyasztással működik az állomás, minden hozzá érkező üzenetre figyel. A másik esetben, passzív módban, minden x. Beacon üzenetet (BSS-re vonatkozó információkat szállít) figyeli csak az állomás. A Beacon üzenet tartalmaz egy TIM (Traffic Indication Map) mezőt, amiben a hozzáférési pont jelzi az állomásnak, ha pufferelt üzenetet tartogat számára. Ezután attól függően, hogy az állomás DCF vagy PCF hozzáférési módot használ, vagy lekéri, vagy megvárja, hogy a hozzáférési pont elküldje neki az adatot. 3.1.5.2. 802.11 MAC rétegének lehetséges állapotai A 802.11 MAC rétege véges automata, amelynek három állapota lehetséges [1, 3, 5]. Az első állapot az, amikor az állomás még nem csatlakozott más állomáshoz és nem történt hitelesítés köztük. Ez a 'non authenticated and non associated' állapot. A második az 'authenticated and non associated' állapot, amelybe akkor jut egy állomás, amikor megtörtént a hitelesítés a kapcsolat másik oldalán álló féllel. BSS esetén a hitelesítés egyoldalú, csak az állomás hitelesíti magát a hozzáférési pontnál. A harmadik az 'authenticated and associated' állapot. Ebbe az állapotba akkor jut az állomás, ha csatlakozott a másik félhez, és megkezdődhet a hasznos adatok küldése. Megbeszéltek minden adatátvitelre vonatkozó fizikai és MAC rétegnek szóló paramétert. Ez alapján nézzük meg egy állomás hozzáférési ponttal történő kapcsolat-felépítésének lépéseit és MAC rétegének állapotváltozását. [1, 3, 5] Kapcsolat-felépítési lépések 1. Az állomás végigpásztáz, hogy megtudja milyen BSS-ek vannak látókörzetében. Ez történhet passzív módon, amikor csak belehallgat a médiumba és Beacon üzeneteket figyel. Beacon-t minden AP köteles kibocsátani bizonyos időközönként. Ez tartalmazza a BSS paramétereit. A szabvány passive scanning-nek nevezi ezt a pásztázási módot. 13

A másik lehetőség, hogy az állomás Probe Request üzenetet küld, amelyre adott vagy minden környékén lévő hozzáférési pont köteles válaszolni Probe Response üzenettel. A Probe Response tatalmazza az összes BSS-re vonatkozó paramétert. Ezt a fajta felderítési módot nevezik active scanningnek. Ezután az állomás rászinkronizálódik a számára megfelelő BSS hozzáférési pontjának órajelére. Ezalatt végig 'non authenticated and non associated' állapotban van. 2. Hitelesítés (Authentication Process). Sikeres hitelesítés után átmegy 'authenticated and non associated' állapotba. 3. Összekapcsolódás (Association Process). Sikeres kapcsolat-felépítés után átmegy 'authenticated and associated állapotba' Az állomás MAC rétegének állapot-diagrammját mutatja a 3.6. ábra [1]. 3.6.ábra - 802.11 állomás MAC rétegének llapot-diagrammja 3.1.6. A 802.11 szolgáltatásai Az ESS struktúrában működő 802.11 hálózat az alábbiakban felsorolt szolgálatokat képes nyújtani [1]. A szolgálatok megvalósítása lehet miden állomás MAC rétegének feladata, legyen az AP vagy STA, illetve alkothatja a Distribution System feladatkörét, vagyis csak a hozzáférési pont funkcióihoz írandók. Ez utóbbi szolgálatokat az állomások a hozzáférési ponton keresztül érik el. A DS szolgálatok közé a következő 5 szolgálat tartozik: Distribution: A szolgálat a nem ugyanabban a BSS-ben tartózkodó állomások közti útvonal megtalálásáért felelős. A DS-en belül biztosítja a megfelelő routingot. Integration: A distribution szolgálathoz hasonlít, azzal a különbséggel, hogy állomás és külső hálózat közti útvonal megtalálását biztosítja a DS-ben. Az állomás üzeneteinek megfelelő portalra való irányítását jelenti. Association: Ha az állomás és a hozzáférési pont között felépült a kapcsolat, akkor a hozzáférési pontban létrejön egy STA <-> AP hozzárendelés, amely a distribution és integration szolgálatokhoz nyújt útvonalválasztási információt. 14

Disassociation: Ha egy állomás lecsatlakozik a hozzáférési pontról, a hozzáférési pontban ki kell törölni a STA <-> AP bejegyzést a routing táblából. Ez jelzésértékű a kérvényező állomás oldaláról, a másik félnek el kell azt fogadnia. Reassociation: A BSS-ek közti mobilitás biztosításáért felelős egy ESS-en belül. Ha az állomás egy másik hozzáférési pont körzetébe érkezik, akkor kezdeményezheti a régi AP-val meglévő kapcsolat bontását és az újjal a kapcsolat felépítését. Minden állomásnak ismernie kell a következő 4 szolgálatot: Authentication: Az állomás kérvényezheti a másik féltől, hogy hitelesítse őt. A rádiós összeköttetés szintjén történik hitelesítés. BSS esetén csak az AP hitelesíti az állomást. Deauthentication: Az állomás jelezheti a másik félnek a hitelesített viszony bontását kéri. Jelzés értékű a másik fél számára, el kell fogadnia. Privacy: Titkosságot nyújt a rádiós összeköttetésen, két állomás között a felhasználói adatok szintjén. Bizonyos hitelesítési algoritmusoknál is szükség van rá. MSDU delivery: LLC rétegből érkező felhasználói adatok, illetve a MAC Management sikja által kezdeményezett üzenetek átvitele eljuttatása a másik fél MAC rétegéhez. 3.2. A 802.11 biztonsága A 802.11 két biztonsági szolgálata a hitelesítés (authentication) és a titkosság (privacy). Ezek bevezetésére azért került sor, mert a rádiós közegen történő átvitel a vezetékes LAN hálózatokhoz képest jóval nagyobb kockázattal jár [1, 9, 10]. A különbségek a következők: a médiumnak nincsenek fix határai, külső jelektől nincs védve, vezetékes kommunikációhoz képest a rádiós közeg lehallgathatóbb, dinamikus topológiája van. Most a hitelesítés és titkosság szolgálatokat nézzük meg részletesebben. 3.2.1.Authentication Az IEEE 802.11 szabványként hitelesítési algoritmust támogat, az Open System és a Shared Key hitelesítést [1, 3]. Az első üzenetből derül ki, hogy éppen melyiket használják a felek. A következőkben bemutatjuk, hogy milyen üzenetváltás zajlik le a felek között: 3.2.1.1. Open System Authentication: Az Open System authentication egy null hitelesítési algoritmus [1], tehát bármilyen állomás kezdeményez, ha a címzett állomásban a hitelesítési algoritmus típusa erre van állítva, akkor sikeres hitelesítés választ fog küldeni (3.7.ábra). 3.7. ábra - Open System hitelesítési algoitmus 15

3.2.1.2. Shared Key Authentication A Shared Key hitelesítési algoritmus esetében a kihívás-válasz módszer kerül alkalmazásra. Az állomás kérvényezi a hozzáférési pontot, hogy hitelesítse őt Shared Key algoritmussal. Ezután az AP küld egy 'challenge' kihívást az állomásnak. Az állomás ezután visszaküldi titkosítva a kihívást. Ha az AP a dekódolásnál ugyanazt kapja, amit előbb küldött, akkor az állomás hitelesnek bizonyult. Ehhez mindkét félnél implementálni kell a titkosító algoritmust. A megfelelés azon múlik, hogy az állomás és a hozzáférési pont rendelkezik-e ugyanazzal a titkos kulccsal. A 3.8.ábra a Shared Key algoritmus üzenetváltásait szemlélteti. 3.8.ábra - Shared Key hitelesítési algoritmus 3.2.2. Privacy A 802.11 a titkosításhoz az ún. Wired Equivalent Protocol-t (WEP) használja. A WEP célja egy olyan fokú biztonság nyújtása, amely a vezetékes LAN-oknál a fizikai behatároltság miatt eleve adott [1]. A titkosítás és dekódolás menetét mutatja a 3.9. és 3.10. ábrán látható blokkdiagramm [1]. 3.9.ábra - A WEP titkosítása A WEP titkosítási algoritmusa szimmetrikus. A nyílt (titkosítatlan) adatot (plain text) és az ICV-t (Integrity check value) - egy 32-bites ellenőrző összeget - titkosítja úgy, hogy ezeket egy azonos méretű kulcssorozattal (key sequence) XOR-olja. A kulcssorozat előállítása RC4 algoritmussal történik [1, 6]. Ez található a WEP PRNG blokkban. Az RC4 algoritmus adott bemeneti érték hatására adott, véletlennek látszó számsorozatot eredményez a kimenetén.[1, 6, 8]. Elvileg a bemeneti érték nem fejthető vissza a kimeneti értékből. A bemeneti paramétert 'seed'-nek nevezi a szabvány [1]. A seed egy 40 bites kulcs (Secret key) és egy 24 bites inicializáló érték, az ún. Initialization Vector összefűzésével állítható elő. A feladó nyíltan elküldi az Initialisation Vectort a címzettnek. Ha a címzett ismeri a titkosító kulcsot, akkor az 16

Initialization Vector segítségével ő is elő tudja állítani ugyanazt a kulcssorozatot, amit a feladó használt titkosításnál, és dekódolni tudja majd a titkosított szöveget. 3.10. ábra - A WEP dekódolása Dekódolás során a vételi oldalon a MAC rétegben előállítják a kulcssorozatot, amelyet ezután XOR-olnak a titkosított szöveggel. Az így kapott eredmény a nyílt adatot és a túloldalon kiszámolt ICV ellenőrző értéket foglalja magában. Az ICV értéket a célállomás is kiszámolja az adatra. Ha ez megegyezik a kapott ICV-vel, akkor sértetlennek bizonyul az adat. Lehet az adatot továbbküldeni a felsőbb rétegeknek (LLC-nek). 3.2.3. Kulcsmenedzsment A 802.11 statikus kulcskiosztást használ [1, 3, 4, 5, 6], ami ahhoz vezet, hogy nem cserélik elég gyakran a kulcsokat ahhoz, hogy ne kompromittálódhassanak. Alapjában véve négy titkosító kulcs (default key) közül lehet választani titkosításnál. Ezt jelezni kell a dekódoló oldalon, ezért a titkosított adat mellett nemcsak az Initialisation Vectort, hanem egy kulcs azonosítót (key ID) is el kell küldeni a vevő MAC réteg számára. A key ID a BSS-en belül mindenkinél ugyanazt a titkosító kulcsot azonosítja. A "default" (alapértelmezett) kulcsokat és a hozzájuk tartozó ID-t a 3.11. ábrán lévő táblázat szemlélteti. Egy BSS-en belül minden állomásban azonosak ezek a kulcsok. Default WEP Key Default WEP Key ID 1000 1 2000 2 3000 3 4000 4 3.11.ábra - Alapértelmezett titkosító kulcsok (default secret keys) A 802.11 lehetőséget ad állomás páronként egyedi titkosító kulcs definiálásra. Ehhez mindkét állomásban kell lennie egy ún. key mapping táblázatnak (3.12. ábra) [1, 3, 5]. Ebben a táblázatban szerepelnie kell egy olyan sornak, ami tartalmazza a másik fél MAC címét, a titkosító kulcsot, és egy WepOn nevű boolean típusú változót. Titkosítás és dekódolás előtt minden állomásnak végig kell néznie ezt a táblázatot, hogy nem szerepel-e benne annak az állomásnak a címe, akivel éppen kapcsolatban áll. Ha van ilyen sor, akkor az ott lévő titkosító kulcsot kell alkalmaznia. Azonban csak akkor titkosíthat illetve dekódolhat egy állomás ezzel a kulccsal, ha a WepOn paraméter értéke IGAZ. A WepOn default értéke HAMIS, azonban kapcsolat-felépítés során, sikeres hitelesítés eredményeként mindkét fél IGAZ értékre állítja ezt az értéket. 17

Transmitter WEP On Mapped Key MAC Address 89456 FALSE 5000 89365 FALSE 6000 89012 TRUE 5555 3.12.ábra - Key Mapping táblázat 3.3 A 802.11 Biztonságának jellemzése A 802.11 alapjában nem nyújt megfelelő biztonságot [3, 4, 5, 6], ezért általában felsőbb szintű biztonsági megoldásokat szoktak alkalmazni, ha bizalmas információk cseréjéről van szó. Problémát jelent, hogy a WEP nem oldja meg automatikusan a kulcsfrissítést. Igaz, hogy négy default kulcs közül lehet választani és key mapping-ra is van lehetőség, titkosításnál azonban ez nem eléggé sokféle. Nem lehet manuálisan olyan gyorsan frissíteni a kulcsokat, hogy azok ne kompromittálódhassanak [4]. A WEP használata opcionális, ezért nem kerül minden esetben alkalmazásra [1, 3]. Ilyenkor teljesen nyíltan mennek át az adatok, a támadónak csak annyi a dolga, hogy lehallgatja a kommunikáló felek adását. Ha implementálják és használják is, a WEP akkor sem nyújt elegendő biztonságot. Ez két dolognak köszönhető. Egyrészt a kulcssorozat előállításához használt RC4 algoritmust nem rádiós környezetre találták ki, ahol nagy a bithiba-arány [4, 6]. Emiatt minden elküldött keretnél inicializálják az algoritmust, hogy keretvesztés esetén ne legyen probléma a kulcssorozat és a titkosított adat elcsúszásából a dekódoló oldalon. Ez ahhoz vezet, hogy hamar eljut oda a rendszer, hogy kétszer ugyanazt az Initialization Vectort használja egy BSS-en belül. Ha többször használják ugyanazt az Initalization Vectort az egyben azt is jelenti, hogy többször használják ugyanazt a kulcssorozatot. Ezt egy támadó könnyen ki tudja használni. [4, 6] Másrészt nagyon egyszerű módon áll elő a seed az Initialisation Vector-ból és a titkos kulcsból (egymáshoz fűzik őket). Ezért konkrétan ismert az RC4 algoritmus bemeneti paraméterének, a 64 bit hosszú seed-nek az utolsó 24 bitje. Az első 40 bitje pedig gyakorlatilag konstansnak tekinthető a kevés statikus kulcs miatt. Ez segíti a kulcs kulcssorozatból történő visszafejtését. [4, 6] Milyen gyakran kellene kulcsot cserélni a tökéletes biztonsághoz? [4] Mivel nagyon nehéz megfelelően kiosztani egy dinamikusan változó hálózatban, hogy melyik állomás milyen Initialization Vector értéket használhat, mindenki véletlenszerűen választ IV-t, amikor adatkeretet küld. Első ránézésre a 2 24 db érték közül történő véletlenszerű választás jó megoldásnak tűnik a véletlenszerűnek tűnéshez. Azonban az ún. születésnap paradoxon szerint n=2 24 db Initialization Vector érték esetén már 12340 keret adása után 99% annak az esélye, hogy legalább egy esetben ugyanazt az Initialization Vectort-t használja valamelyik két állomás. A tökéletes biztonság, vagyis a már elfogadható 0.000001%-os duplikálási esély akkor lenne elérhető, ha minden 6. keret adása után sor kerülne kulcsfrissítésre.[4] 18

3.4. Lehetséges támadások 3.4.1. Ismert nyílt és titkosított szöveg (known plaintext and ciphertext attack) Ha a támadó tudja, hogy pontosan mit titkosított a feladó, akkor egyszerű XOR művelettel kinyerheti az adott Initialization Vector-hoz tartozó kulcssorozatot (k) [4, 5]. Nyílt szöveg = p (plaintext), titkosított szöveg = c (chipertext). Ezt addig használhatja, amíg nem frissítik a kulcsot. k=p c Nem biztos, hogy a nyílt szöveget ismeri a támadó, azonban sokszor ismerheti annak egy részét. A forgalom elemzéséből könnyen kiderül, hogy milyen típusú (esetleg TCP/IP) forgalomról van szó. A fejlécek mezői könnyen ismertek lehetnek a támadó számára. 3.4.2. Csak a titkosított szöveg ismert (known ciphertext attack) Ha a támadó elkezdi páronként XOR kapcsolatba hozni az ugyanolyan Initialization Vector-hoz tartozó titkosított szövegeket, akkor egyben megkapja a nyílt szövegek XOR eredményét [4]: c c =p k p k=p p Ha ismert két ismeretlen byte XOR-zata, akkor a két byte lehetséges variációinak száma nem 2 16, hanem csak 2 8, ugyanis, ha az egyiket tudjuk, akkor a másik már ismertté válik. Minél több XOR eredményt gyűjtünk össze ugyanahhoz az Initialization Vector-hoz tartozó titkosított szövegpárokra, annál közelebb jutunk a titkosított szövegek megfejtéséhez [4]. Segíti még a támadót az is, hogy általában valamilyen természetes nyelv üzenetét szállítják a keretek, amelyben adott gyakorisággal fordulnak elő a különböző betűk. Vannak ún. mintafelismerő technikák, amelyek megkönnyítik a találgatást. Sőt, amikor már jó részét megfejtette a titkosított szövegnek, akkor az ICV (32 bites checksum) is segíthet a maradék bitek dekódolásában [4]. Minél több Initialization Vector-hoz találta meg a támadó a kulcssorozatot, annál nagyobb esélye nyílik a kulcs visszafejtésére. 3.4.3. Denial of Service (DoS) támadás Mivel nincs üzenet-hitelesítés a 802.11 biztonsági szolgáltatásai között, a támadó már hitelesített állomások nevében bármilyen üzenetet küldhet a hozzáférési pontnak, illetve a hozzáférési pont nevében a legális felhasználóknak [5]. Ez főleg a vezérlő üzenetek esetén érdekes, mert ezzel döntően befolyásolni lehet az adott állomás működését. Denial of service támadás például, ha a támadó bizonyos időközönként disassociation üzenetet küld egy állomás nevében a hozzáférési pontnak. Emiatt az állomás nem tudja a hálózat szolgáltatásait igénybe venni. 3.5. Összefoglalás A 802.11 szabvány biztonsági tekintetben a következő célokat tűzte ki maga elé: Bizalmasság megteremtése (WEP), az adatintegritás ellenőrzése (ICV) és a hozzáférés ellenőrzése (kölcsönös hitelesítés) [1]. Ezeknek a követelményeknek azonban nem tesz eleget. Ennek legfőbb okai a következők: rossz környezetben használja az RC4 algoritmust, túl rövid Initialization Vectort-t használ, amelyből túl egyszerűen állítja elő a seed-et, manuális kulcskiosztást használ [4, 6, 3]. 19

4.OMNet++ 4.1 Mi az OMNeT++? Az OMNeT++ egy objektum-orientált szemléletet követő, moduláris, diszkrét idejű eseményvezérelt szimulátor [2]. Jól használható minden olyan rendszer modellezésére, amelynek működése visszavezethető diszkrét idejű eseményekre. Ilyenek a kommunikációs protokollok, számítógépes hálózatok, multi-processzoros és elosztott rendszerek stb. 4.2. Az OMNeT++ általános jellemzése Egy OMNeT++ modell hierarchikusan egymásba ágyazott modulokból épül fel, a beágyazás mélysége tetszőleges lehet. A modulok üzentekkel kommunikálnak egymással. Üzenetet lehet közvetlenül egy modulnak címezni, illetve a modell felépítésének megfelelő összeköttetéseken és kapukon keresztül eljuttatni a címzetthez. Az üzenetek tetszőlegesen sok paramétert szállíthatnak. Eseményt az üzenet megérkezése jelenti egy modulnál. [2] A modulok paraméterekkel ruházhatók fel. A paraméterek három fő célt szolgálnak: befolyásolhatják a modell topológiáját (pl. hány almodul legyen egy modulban), befolyásolhatják a modul viselkedését, vagy jelenthetnek egy üzeneten túli kommunikációs lehetőséget, ha több modul megoszt egy paramétert (pl. osztott memória). A modulok paramétereit, kapuit, modultopológiát egy saját, könnyen olvasható formátumú nyelvvel, a NED-del (Network Description Language) adhatjuk meg. Emellett grafikusan is lehet szerkeszteni modulokat, definiálni lehet azok paramétereit és egymáshoz való viszonyukat a modulhierarchiában. A grafikus szerkesztés is NED nyelvű leírást eredményez. [2] A modulhierarchia legalsó szintjén lévő ún. egyszerű modulok tartalmazzák a modell működését leíró algoritmusokat [2]. Ezek szimuláció futtatásakor látszólag párhuzamosan, egy időben futnak. Az egyszerű modulok viselkedésének leírásánál kétféle programozói megközelítést lehet alkalmazni [2]. Az egyik módszer az activity függvény alkalmazása. Adott modul activity függvénye a szimuláció alatt folyamatosan fut. Lehet benne üzeneteket küldeni, fogadni, várakozni, de ha egyszer lefutott, akkor a modul befejezte működését. A másik megközelítés szerint a modulok viselkedését az ún. handlemessage függvény szabja meg. A függvény akkor hívódik meg, ha esemény érkezik (üzenet, saját üzenet) az adott modulhoz. A handlemessage függvény az érkező eseményt lekezeli, majd befejezi működését. Ha újabb esemény jön, megint meghívódik. Éppen emiatt értelmetlen ennél a megközelítésnél várakoztatni a processzt, üzenet fogadásával törődni. Lehet üzenetet küldeni, illetve saját magának eseményt ütemezni, hogy adott idő múlva újra meghívódjon a handlemessage függvény. A két szemlélet programozásbeli különbségeket von maga után. A handlemessage esetén minden fontos változót a tagfüggvényen kívül, a modul változójaként kell tárolni. Actvity esetén erre nincs szükség, mert folyton fut a függvény. A futás leállásakor finalize() függvénnyel ki lehet menteni a fontos paraméterek értékeit. 20

Az OMNeT++ sokféle felhasználói interfésszel rendelkezik. Ezek a modell írása során fellépő hibák felderítésére, a modell működésének bemutatására és batch fájlok futtatására használhatók. Van parancssoros és grafikus interfésze is. A grafikus interfész jól szemlélteti a modell felépítését, működését, szabályozni lehet vele a szimuláció futásának sebességét, modell paramétereit futás közben lehet állítani stb. Futás közben üzeneteket lehet kiíratni, akár modulokra bontva, erre valók az ún. inspectorok. A szimuláció során kapott eredményeket különböző output fájlokba lehet kigyűjteni és ezeket később fel lehet dolgozni más programok segítségével. Egy szimulációs program több független modellt képes tárolni, és különböző 'run'-okat lehet létrehozni a modellek bemutatására. Egy modellhez is lehet több 'run'-t létrehozni, mivel elképzelhető többféle paraméter-beállítás, amely változtathat a modell működésén. 4.3 OMNeT++ szimuláció elkészítésének általános módja Létre kell hozni a modulstruktúrát NED nyelven leíró.ned kiterjesztésű fájlt vagy fájlokat. Az egyszerű modul esetén, meg kell határozni annak paramétereit, illetve a be és kimeneti kapuit. Ilyenkor még csak egy egyszerű modul típust hozunk létre. Modulnál az előbbiek mellett meg kell adni, hogy milyen egyszerű és normál modulok tartoznak alá, kik az almoduljai. Ilyenkor kerülnek példányosításra a hierarchiában eggyel alatta elhelyezkedő modultípusok. Ezen kívül definiálni kell az összeköttetéseket az almodulok kapui, és a modul saját kapui között. A hierarchiában legfelül lévő modultípus példányosításával hozzuk létre a modell hálózatot. A modell működését leíró algoritmusokat.h és.cc kiterjesztésű C++ forrás fájlokba kell írni. Az összes egyszerű modultípushoz kell modul osztályt deklarálni. Az osztályhoz tartoznak paraméterek, változók, virtuális tagfüggvények. A virtuális tagfüggvények tartalmazzák a modul működését leíró algoritmust. Ha megvan a modulstruktúrát leíró fájl, akkor azt nedc fordítóval C++ forrásfájllá kell átfordítani. Ezután ezt és a működést leíró forrásfájlt le kell fordítani, és linkelni kell őket a szimulációs rendszer által adott fájlokhoz. A szimulációs rendszer a szimulációs kernelt és a felhasználói interfészt megvalósító fájlokat adja a szimulációhoz. A linkelés után létrejön egy futtatható fájl, amely már független az OMNeT++-tól. [2] 21

5. Szimuláció A szimuláció a kapcsolat-felépítést, az adatküldést és a kapcsolat-bontást szemlélteti központosított struktúrájú 802.11 WLAN hálózatban, az állomás és a hozzáférési pont között. Célja a 802.11 biztonsági szolgáltatásainak bemutatása, ezért az ehhez kapcsolódó üzenetváltások és eljárások kaptak benne hangsúlyt. 5.1. A szimulációs program elkészítésének menete A szimuláció elkészítésének menete két részre bontható, egy elméleti és egy gyakorlati munkára. Elméleti munka: 1. Részletesen áttanulmányoztam a 802.11 MAC rétegét leíró szabványt [], és a szimuláció céljára tekintettel kiválasztottam a bemutatandó eljárásokat és kigyűjtöttem az ezek működését befolyásoló paramétereket. 2. Ennek eredményeként döntöttem a leendő OMNeT++ modell felépítéséről. Gyakorlati munka: 3. A munka gyakorlati része a program megírása volt OMNeT++ szimulációs környezetben. A modulstruktúrát leíró '.ned' fájlokat, az egyszerű modulok működését megadó C++ forrásfájlokat, és a szimuláció paramétereit megadó 'omnetpp.ini' fájlt kellett létrehoznom. Most az érthetőség kedvéért először a 2. pont eredményéről írok. 5.2. Szimuláció felépítése A szimuláció modul-strukturáját a 802.11 protokoll-architektúra és a szimuláció célja figyelembevételével alakítottam ki. Az 802.11 hálózatmodulon belül található egy állomás és egy hozzáférési pont modul. Ezek alá három-három egyszerű modul tartozik. Ezek az LLC (Logical Link Control), MAC (Medium Access Control) és MLME (MAC Layer Management Entity) modulok. A modulok az 5.1. ábrán látható módon kapcsolódnak össze: 5.1 ábra - Modulstruktúra Az egyszerű modulok tartalmazzák a modell viselkedését leíró algoritmusokat. 5.3. A szabvány feldolgozása A modell működése időben négy nagy fázisra bontható. Az első három fázis a 3.1.5.2. részben leírt kapcsolat-felépítési lépéseket tartalmazza, a negyedik fázis az adatküldés. 22

Tekintsük át fázisonként az üzenetváltási eljárásokat. Az üzenetek céljáról, és a bennük szállított paraméterekről a 7.6. függelékben lehet olvasni. Az üzeneteknél elmondható, hogy az "MLME-...request" formájú üzenet mindig MLME MAC irányba megy és egy eljárást kezdeményez, az "MLME-...confirm" ezzel ellentétes irányban halad (MAC MLME), és az eljárás eredményét szállítja. Az "MLME-...indication" típusú üzenet a vételi oldalon jön létre és MAC MLME irányba halad. Célja, hogy jelezze, hogy a másik fél valamilyen változást okozott. 5.3.1. Első fázis: station scanning Ebben a fázisban a hozzáférési pont (AP) inicializálja a BSS-t leíró paramétereket és Beacon üzenetek periodikus küldésébe kezd. Az állomás (STA) a fogadott Beacon üzenetek alapján kiválasztja a neki megfelelő BSS-t. Ezt követően rászinkronizálódik az AP órajelére. Az AP oldal eljárása az 5.2. ábrán, állomásé pedig az 5.3. ábrán látható: 5.2. ábra - Scanning phase, AP oldal 5.3. ábra - Scanning phase, STA oldal 23

5.3.2. Második fázis: Hitelesítés 5.3.2.1. Hitelesítés A hitelesítési eljárást mindig az állomás kezdeményezi. Lehet Open System, vagy Shared Key algoritmust használni az aauthenticationtype paraméter értékétől függően. Mindkét esetben fontos, hogy az Authentication Algorithms paraméter az állomás és a hozzáférési pont oldalán is be legyen állítva az adott algoritmusra. Ezen kívül Shared Key algoritmus esetén fontos, hogy mindkét oldalon implementálva legyen a WEP (aprivacyoptionimplemented = TRUE). Sikeres hitelesítés esetén a hozzáférési pont és az állomás hitelesített viszonyba lép egymással. Mindkét állomás 'Authenticated and non associated' állapotba kerül. A hitelesítési eljárást az 5.4. ábra mutatja. 5.3.2.2. Deauthentication 5.4. ábra - Hitelesítés A hitelesítés körébe tartozik az a kérdés is, hogy miként tudja egy állomás lebontani egy másik állomással létesített hitelesített viszonyát. Ez Deauthentication jelzés küldésével érhető el. Ennek hatására mindkét oldal átmegy 'Non authenticated and non associated' állapotba. Az eljárást az 5.5. ábra szemlélteti. 5.5.ábra - Deauthentication 24

5.3.3. Harmadik fázis: Association 5.3.3.1. Association (csatlakozás) Az association eljárást az állomás kezdeményezi. Célja az, hogy a kapcsolat paramétereit megtárgyalják a felek. Sikeres csatlakozás után mindkét oldal 'Authenticated and associated' állapotba megy át. Az eljárás ugyanaz, mint Open System hitelesítés esetén volt azzal a különbséggel, hogy mások az üzenetek. Az eljárást az 5.6. ábra szemlélteti. 5.3.3.2. Disassociation (lecsatlakozás) 5.6. ábra - Association A csatlakozás kérdésköréhez tartozik a lecsatlakozás vagy disassociation kérdése. Egy állomás úgy tud lecsatlakozni egy másik állomásról, ha Disassociation üzenetet küld. A másik fél számára ez jelzés értékű, köteles teljesíteni a parancsot. Disassociation hatására mindkét fél 'Authenticated and non associated' állapotba megy át. Az eljárás (5.7.ábra) ugyanaz, mint a Deauthentication esetében volt, csak mások az üzenetek. 5.7. ábra - Disassociation 5.3.4. Negyedik fázis: Üzenetküldés Az üzenetküldési eljárást bármelyik fél LLC rétege kezdeményezheti. A MAC rétegben, a titkossággal kapcsolatos paramétereknek megfelelően, vagy fog titkosítás és dekódolás történni vagy nyíltan fogja a MAC átküldeni az adatot. Az üzenetküldési eljárás menetét az 5.8. ábra szemléleti. 25