Mobil ad hoc hálózatok biztonsági protokolljainak vizsgálata

Budapesti Műszaki és Gazdaságtudományi Egyetem Távközlési és Telematikai Tanszék Nagysebességű Hálózatok Laboratóriuma (HSNLab)

Mobil ad hoc hálózatok biztonsági protokolljainak vizsgálata TDK dolgozat

Gémesi Roland, Ivády Balázs IV. évf. villamosmérnök-hallgatók Konzulens: Zömbik László (Ericsson Magyarország, Kutatólabor)

2

Tartalomjegyzék 1. 2.

Bevezetés............................................................................................................................ 4 Mobil ad hoc hálózatok biztonsági kérdései, feltételei ...................................................... 5 2.1. Biztonságos hálózatok .................................................................................................. 5 2.2. Mobil Ad hoc hálózatok veszélyforrásai ...................................................................... 5 2.3. Útvonal-választó protokollokra irányuló támadások .................................................... 8 3. Biztonsági mechanizmusok.............................................................................................. 10 3.1. Autentikáció nyilvános kulcsú titkosítás segítségével................................................ 10 3.1.1.Küszöb kriptográfia (Thresold cryptography)......................................................... 10 3.1.2.Önszervező PKI (Self Organizing Public Key Infrastructure)................................ 11 3.1.3. Identitás alapú (ID-Based) kriptográfia.................................................................. 11 3.2. Kulcs szétosztási eljárások.......................................................................................... 12 3.2.1.Diffie-Hellman (DH) kulcs csere ............................................................................ 12 3.2.2. GDH.2 (Generalized Diffie Hellman) .................................................................... 12 3.2.3.Hypercube és Octopus............................................................................................. 13 3.2.4.Kulcstranszport nyilvános kulcsú architektúrán ..................................................... 13 3.3. Csoport kulcs menedzsment protokoll (Group Key Management Protocol-GKMP). 13 3.4. Üzenetszórásos hitelesítés - TESLA........................................................................... 14 4. Útvonalválasztási mechanizmusok .................................................................................. 15 4.1. Dynamic Source Routing (DSR) ................................................................................ 15 4.2. AODV ......................................................................................................................... 16 4.3. Zone Routing Protokol (ZRP)..................................................................................... 17 5. Biztonságos útvonalválasztás........................................................................................... 18 5.1. Onion routing .............................................................................................................. 18 5.2. Security-Aware Routing - SAR .................................................................................. 18 5.3. Ariadne........................................................................................................................ 19 5.4. Folyamatos figyelés, büntető mechanizmusok ........................................................... 20 6. CSP – Communicating Seqential Processes..................................................................... 22 6.1. CSP alapok.................................................................................................................. 23 6.2. Biztonsági protokollok modellezése CSP-ben............................................................ 23 6.3. Specifikációk modellezése CSP-ben........................................................................... 25 6.4. FDR2........................................................................................................................... 26 7. A Casper........................................................................................................................... 27 7.1. A Casper bemeneti fájljának felépítése....................................................................... 27 8. Biztonsági vizsgálatok...................................................................................................... 30 8.1. Forrás útvonalválasztás............................................................................................... 31 8.2. ONION routing ........................................................................................................... 32 8.3. TESLA ........................................................................................................................ 34 8.4. Ariadne........................................................................................................................ 35 9. Megoldás biztonságos mobil ad hoc kommunikációra .................................................... 38 10. Összegzés ......................................................................................................................... 39 11. Referenciák....................................................................................................................... 40

3

1. Bevezetés A hagyományos hálózatokkal szemben az ad hoc hálózatok nem igényelnek előre kiépített infrastruktúrát, a kommunikációt az egyenrangú résztvevők együttműködve valósítják meg. Ad hoc hálózatok már a középkorban is léteztek, gondoljunk csak az indiánok füstjelzéseire vagy az őserdőlakókra, akik távolabbra dobok segítségével kommunikáltak. Mai vonatkozásában a mobil ad hoc hálózatokkal a 2. világháború idején kezdtek el foglalkozni. A harcmezőkön nem volt semmiféle előre kiépített infrastruktúra, pedig a kommunikációra ott is szükség volt. Háború esetén egy idegen területen a gyorsaság az elsődleges, a kommunikációs hálózat kiépítésével eltöltött idő komoly veszteséget jelenthet. Így van ez egyébként katasztrófa helyzet esetén is. Itt is sokkal fontosabb feladatok léteznek egy új hálózat kiépítésnél vagy a régi rekonstruálásánál, pedig gyors és biztonságos adatcserére ilyenkor is szükség van. Más jellegű példa lehet egy mai ad hoc hálózatra egy olyan konferencia hálózat, ahol például csak néhány előadás kedvéért kellene kiépíteni a kommunikációs rendszert. Egy ad hoc rendszerben nincsenek kitüntetett szerepű eszközök, melyek központilag irányítanák, vagy ellenőriznék a feladatokat. Ezt a közös célokért küzdő egységeknek (nodeoknak) kell megvalósíthataniuk speciális entitások segítsége nélkül. Például egy ilyen rendszerben nincsenek szerverek, routerek vagy gatewayek. Minden résztvevő routerként is viselkedhet, hogy a csomagtovábbítást biztosítsa, illetve a gateway szerepét is fel kell vállalniuk, ha más hálózathoz szeretnének kapcsolódni. A mobil ad hoc hálózatok speciális tulajdonságokkal rendelkeznek. Dinamikus topológiájuk miatt ezen hálózatok nem statikusak, így a kiépült útvonalak csak korlátozott ideig érvényesek. A résztvevők mozgása vagy eltűnése nem befolyásolhatja a helyes működést. Manapság egyre több elektromos készülékbe építik be a vezeték nélküli kommunikációs képességet. Az egységek rendszerint kisméretű, hordozható, kézi készülékek, melyek maguk után vonják, hogy korlátozott CPU-, memória- és telepkapacitással rendelkeznek. A kommunikáció vezeték nélkül történik, mely kapcsolatok gyakran kisebb sávszélességgel bírnak és e csatorna gyakran megosztott és limitált. Mind a kapcsolatok, mind a készülékek sokkal sebezhetőbbek, mint vezetékes hálózatok esetében. [Perkins] A 2. fejezetben ismertetjük a biztonságos hálózatokkal szemben támasztott követelményeket és az ad hoc hálózatokat fenyegető veszélyforrásokat. Ezután a 3. fejezet ad hoc hálózatokban alkalmazható biztonsági mechanizmusokat mutatja be. A 4. fejezetben kitérünk az ad hoc hálózatok főbb útvonalválasztó mechanizmusaira, majd az 5. fejezetben lehetőségeket mutatunk a biztonságos útvonalválasztásra. A 6. fejezetben mutatjuk be az analízisünk során használt eszközöket, majd a 7. fejezet modelljeink formátumát ismerteti. A 8. fejezetben mutatjuk be a vizsgálatunk tárgyát képező protokollok modellezését, analízisét és azok eredményeit. Az eredmények alapján a 9. fejezetben egy megoldást adunk, mellyel megvalósítható az ad hoc hálózatok biztonságos kommunikációja. A 10. fejezetben összegezzük az eredményeket.

4

2. Mobil ad hoc hálózatok biztonsági kérdései, feltételei 2.1. Biztonságos hálózatok Napjainkra már számos olyan szempont létezik, amely a biztonságos kommunikációs rendszerekkel szemben elvárhatóak. Ezek az igények a hagyományos hálózatok lehetőségeihez lettek formálva. Az ad hoc rendszerek működése gyökeresen más szemléletet rejt, azonban a biztonságos kommunikáció igénye ugyanazon követelményeket támasztja. A következőkben tehát azokat a követelményeket ismertetjük, melyeket egy biztonságos rendszernek nyújtania kell. Információ titkosságának (confidentiality) nevezzük azt, hogy az információ csak azokhoz a résztvevőkhöz jut el, akiknek a küldő szánta. Mivel az információk a hálózatban résztvevők továbbításával jutnak célba, a bizalmas adatok védelme nélkülözhetetlen. A védendő információk nem csak a felhasználók által küldött adatok lehetnek, hanem például a rendszer jelzései is, melyek felhasználásával a támadó hasznos információkhoz juthat (pl. eszköz lokalizálása). Integritás (integrity) az a követelmény, mely biztosítja, hogy az adatok átvitele során történt változásokra fény derüljön. Változást okozhatnak természetes környezeti hatások, mint például az átviteli csatorna gyenge minősége, de egy támadó célja is lehet üzenetek megváltoztatása, új üzenetek beszúrása vagy üzenetek törlése. A hitelesítés (authentication) során az üzenet vagy a küldő személye lesz azonosítva. Biztonságos kommunikáció felépítésekor fontos bizonyosságot nyerni a másik fél személyéről, hogy kizárjuk a megszemélyesítés lehetőségét. Letagadhatatlanságnak (non-repudiation) nevezzük azt a követelményt, mely garantálja hogy a kommunikáció során az üzenetek akár később is meghatározzák a küldő személyét. Ennek segítségével az adott résztvevő és tevékenysége azonosíthatóvá válik, mely utólagos nyomozási vagy bizonyítási eljárásokhoz szükséges lehet. Elérhetőségnek (availability) nevezzük a hálózat elemeinek és a hálózat szolgáltatásainak folyamatos rendelkezésre állását. A rendszer működését veszélyeztetik a meghibásodások, a környezeti hatások és szándékos támadások is. Szükség lehet ezeken kívül egyéb biztonsági szolgáltatásokra is, mint például a hozzáférés védelem (authorization), ami a rendszer erőforrásaihoz való hozzáférést korlátozza. [Seciss] 2.2. Mobil Ad hoc hálózatok veszélyforrásai A mobil ad hoc hálózatok biztonsági szempontból a hagyományos hálózatokhoz képest újabb veszélyeket rejtenek. Ezen veszélyforrásokat foglaljuk össze a következőkben. A mobil ad-hoc hálózatok egységei rendszerint hordozható, kisméretű, kézi készülékek, melyek korlátozott CPU-, memória-, és telepkapacitással rendelkeznek. A telep élettartamának megnövelése céljából minimalizálni kell az erőforrás-igényes algoritmusok

5

futtatását, így kompromisszumokat követel például a kommunikáció során alkalmazott kriptográfiai műveletek megválasztása is. Túl egyszerű algoritmus esetén azonban megnőhet akár a kódtöréses támadások esélye. A telepkímélés egy másik fontos mechanizmusa a rádióadó, illetve akár az egész készülék ki-, vagy készenléti állapotba kapcsolása akkor, amikor nincsen rá szükség. Egy lehetséges támadási forma az olyan szolgáltatásbénító (Denial of Service - DoS) támadás, melynek célja pont a résztvevők energiaforrásainak pazarlása (sleep deprivation). Ekkor a támadó a készüléket folyamatosan aktivált állapotban tartja. Fennáll a CPU elleni DoS támadás veszélye is, például amikor egy támadó nagy számításigényű műveletek elvégzésére kötelezi a másik résztvevőt. Ekkor a számolással elfoglalt egység nem tud válaszolni, elérhetetlen lesz. Nehézségeket okozhat a memória korlátossága is, mivel az gátat szab például a tárolható kulcsok mennyiségének, illetve a nem megbízható egységek listájának hosszára is. Mivel ad hoc rendszerekben a csomagtovábbítás a résztvevők együttműködésén alapszik, ezért felmerülő kérések esetén válaszolni kell. Így támadásnak minősül az ebben való részvétel önző megtagadása is, azaz ha a támadó a hozzá érkező csomagokat nem továbbítja. Hordozható készülék könnyen illetéktelen személy kezébe juthat (pl. lopás), így számítani lehet arra is, hogy egy megbízott résztvevő készüléke egyszerre csak támadóként kezd viselkedni. A készülékek kis méret és súlyigényének következtében csak gyenge fizikai védelemmel látható el, így egy megszerzett készüléken hardver, illetve szoftvermódosítások végezhetőek. A felhasználó tárolt bizalmas információi rossz kezekbe kerülhetnek (pl. titkos kulcs), de a szoftver módosításaival a támadó vírust vagy trójai falovat is telepíthet az eszközbe. A mobil eszközök vezeték nélküli kommunikációja is veszélyeket rejt. A mobilitást manapság rádiós csatorna használatával valósítják meg. A rádiós csatorna olyan osztott médium, mely mindenki számára hozzáférhető. A kisugárzott információ a szükségesnél nagyobb térben is elérhető, érzékeny vevővel az elküldött információ nagyobb távolságból is lehallgatható, így a bizalmas információkat titkosítással kell ellátni. Az intranetek tűzfallal történő védelme sem megvalósítható, mivel a belső és külső hálózatok érintkezési pontjai nem egyértelműek. Mert ha egy épületben valaki rádiós kommunikációt használ, akkor az ő kommunikációja az épületen, a tűzfalon kívül is hallható lehet. Az osztott médium megzavarása DoS támadásként jöhet szóba. A csatorna elzajosításával az átviteli minőség lerontható, de akár teljesen használhatatlanná is tehető. A támadó által sugárzott zavaró jel csak nehezen választható el a csatorna természetes zajától. A csatornához való hozzáférés is együttműködést igényel, vagy szabályainak megsértése egy másik módja a kommunikáció megzavarásának. Az információk integritásának védelmére ezért szükség van. Egy támadó próbálkozhat az információk megváltoztatásával, vagy például új üzenetek beszúrásával az adatfolyamba, utazó csomagok teljes eltávolításával, de akár azok megváltoztatásával is. A biztonságos kommunikáció igénye szükségessé teszi olyan üzenetváltások meglétét, melyek futtatói a kommunikáció befejeztével meghatározott jellemzőkkel kell rendelkeznek. Biztonsági protokollok célja a résztvevő közötti titkos, illetve megfelelően hitelesített kapcsolat felépítése, ezek feladatai körébe tartoznak még például a kapcsolathoz szükséges kulcsok előállításai, illetve kódoltan a megfelelően hitelesített résztvevőkhöz juttatása. Egy támadó az üzenetváltások megfigyelésével és a szerzett információk felhasználásával a protokoll működésébe úgy igyekszik beavatkozni, hogy azzal a futtató résztvevőket megtévessze és így a futtatás befejeztével aláássa a feltételezett biztonságot. Egy ilyen támadó

6

minden előre ismert, megszerezhető, illetve kikövetkeztethető információt felhasználhat, egyetlen korlátja a kriptográfiai algoritmusok által kódolt üzenetek olvasása. Ezzel tehát feltételezzük, hogy titkosítási algoritmusaink jól működők, feltörhetetlenek a támadó számára. Man-in-the-middle támadás Ennél a fajta támadásnál a támadó a két kommunikáló fél közé épül be. Ez a támadás többféleképpen is megnyilvánulhat. Egyik módja például a résztvevők megszemélyesítése. A támadó a lehallgatott üzenetekből meg tudja fejteni a másik fél identitására szolgáló adatokat, és ezeket használva kiadja magát másnak. Reflection – tükrözés A trükk itt az, ami a névből is adódik, vagyis hogy a támadó egy résztvevőnél visszapattintja az üzenetet vagy annak egy részét. Ezzel az üzenet küldőjét lehet becsapni a helyes válasz feltárásával. Ez a támadás gyakran szimmetrikus helyzeteken alapul. Oracle – jóslás Ilyenkor a támadó a résztvevő által véletlenül felfedett információt használja. A támadó ráveszi a szereplőt, hogy a protokollból végrehajtson néhány üzenetváltást, ezáltal a támadó olyan adatokhoz jut hozzá, amihez másképp nem tudott volna. Ezekből az adatokból lehet jósolni az esetleges támadáshoz. Replay – visszajátszás A támadó folyamatosan figyeli a protokoll üzeneteit, és később ugyanazt az üzenetet visszajátssza. Ez akkor fordulhat elő, ha a protokoll nem tud különbséget tenni az üzenetek között, nem tartalmaz az adott üzenetre jellemző egyedi információt. Interleave – összefésülés Ez nagyon intelligens támadási forma, amikor a támadó két vagy több protokoll futás során kitalálja a protokoll átfedéseit. Sok esetben a támadó a jóslás és az összefésülés technikáját kombinálja, mely így sokkal eredményesebb. Failures of forward secrecy Valódi rendszerek működésében számítani kell a rendszer feltörésére. Ha egy támadó megszerez titkos kulcsokat, azzal az összes e kulccsal titkosított üzenethez is hozzájuthat. A rendszer teljes visszaállítása után is lehet a támadónál olyan információ, mely a rendszerre veszélyt jelenthet. Ezért az adatok titkosítására alkalmazott kulcsokat nem szabad újabb kulcsok bizalmas átvitelére használni, hanem erre külön kulcsot kell létrehozni. Algebrai támadás A kriptográfiai eljárások gyakran megfelelnek bizonyos algebrai szabályoknak. Erre példa a kizáró vagy művelettel való (Vernam) titkosítás, amikor is két azonos kulccsal titkosított üzenet kizáró vagy műveletének eredmény azonos lesz a két üzenet kizáró vagy kapcsolatával. Ezek közül így az egyik ismeretében következtetni lehet a másikra, valamint a használt kulcsra is. [Lowe] Az ad hoc hálózatok teljesen elosztott rendszerek, ahol nincsen központi elem. Így nincsen a rendszernek kiemelten érzékeny résztvevője, ám nem támaszkodhatunk központi segítségre sem. Nincsen teljesen megbízható pont a hálózatban, amely hiteles információkat szolgáltatna. A hagyományos rendszerekben elérhető és ezért széles körben alkalmazott hitelesítő központ hiányában a résztvevők megszemélyesítése komoly fenyegetést jelent.

7

Fokozott problémát jelent ez az első találkozáskor történő azonosítása. Végpont megszemélyesítésről beszélünk, amikor egy támadó másnak adja ki magát, mint aki valójában. Nem csak végpontokat lehet megszemélyesíteni, hanem a közbülső résztvevőket is. Man in the Middle támadáskor a támadó az útvonalba épülve a címzettnek adja ki magát, így tévesztve meg a küldőt. 2.3. Útvonal-választó protokollokra irányuló támadások A mobil ad hoc hálózatok nem rendelkeznek fix infrastruktúrával, felépítésük idővel dinamikusan változik. Ennek következtében olyan útvonal-választási megoldásokra van szükség, melyek követni tudják a bekövetkező változásokat. A pillanatnyi architektúra feltérképezése, illetve a csomagok célba juttatása a résztvevők közös információjával és együttműködésével történhet. Így jelentős zavarokat okozhat az, ha egy támadó téves információkkal árasztja el és téveszti meg hálózatot. A mobil ad hoc hálózatokra irányuló támadások jelentős része az útvonalválasztás mechanizmusát támadja, ezek az utazó csomagok eltérítését hivatottak elérni. Egy példa útvonal-manipulálásra, amikor a támadó téves útvonal információk küldésével egy hurkot hoz létre az útvonalban. Az ebbe bekerülő csomagok sohasem érnek célba, körbekörbe utaznak, miközben a rendszer energiáját és sávszélességét pazarolják. Másik egyszerű példa olyan fekete lyuk kialakítása, mely minden csomagot elnyel. A támadó elérheti ezt is meghamisított útvonal információkkal, mindössze minden csomagot saját magára kell irányítania, majd az érkező csomagokat figyelmen kívül hagyni. (2.1.ábra) Fekete lyuk A fekete lyuk speciális esete a szürke lyuk, mely szelektíven válogathat a csomagok között, a támadó tehát szűrést végezhet. Szintén útvonal manipulálással elérhetőek az optimálisnál jóval kedvezőtlenebb utak. Szélsőséges esetben a hálózat akár független tartományokra is darabolható, vagyis a résztvevők 2.1.ábra Fekete lyuk különböző halmazai nem érhetik el egymást. Gratitous detour-nak nevezzük, amikor egy támadó a rajta keresztülvezető, egyébként rövid útvonalat Támadó Támadó támadók magánhálózata virtuális résztvevők beiktatásával hosszabbnak, előnytelenebbnek tüntet fel. Több útvonal-választási mechanizmus is Forrás Célpont használ valamiféle feketelistát a rosszindulatú résztvevőkről. Egy támadó célja lehet a jó résztvevőknek rossz színben való feltüntetése hamis információk terjesztésével. Ezáltal ez is felhasználható támadási célra. 2.2.ábra Wormhole támadás Egy trükkösebb támadás a wormhole támadás. (2.2.ábra) Ennek lényege, hogy két támadó egység egy előre felépített magánhálózaton sokkal gyorsabban átvihet információt, mint az éppen akkor utat kereső többi résztvevő. A támadás során tehát a felépítendő útvonal egy részét magánhálózatukkal áthidalják a támadók, így sokkal gyorsabbnak fog tűnni, a felépülő út tartalmazni fogja a támadókat.

8

Láthattuk, hogy az ad hoc hálózatok nagyon sok veszélynek vannak kitéve. A biztonságos kommunikáció megvalósításához olyan megoldásokat kell alkalmazni, melyek egy támadó ellen sikeresen meg tudják védeni a hálózatot. A következő fejezetben a rendelkezésünkre álló biztonsági mechanizmusokat mutatjuk be.

9

3. Biztonsági mechanizmusok Vezetékes hálózatok esetében kiforrott, jól működő biztonsági megoldásokat alkalmaznak. Ezek a megoldások (pl. autentikáció, digitális aláírás, kódolás, titkosítás, hash alkalmazása) megfelelő biztonságot nyújthatnak, ám legtöbbjük igényel valamiféle menedzsmentszolgáltatást, mely ellátásához legtöbbször központosított entitás szükséges. Ilyen központi, megbízott elemekre ad hoc környezetben nem támaszkodhatunk. Ezeket a feladatokat is elosztva kell végezni, ráadásul a rendszernek redundanciát is hordoznia kell, mivel résztvevők eltűnhetnek, szakadozhat a kapcsolat és a kompromittálódás veszélye is fennáll. Ad hoc hálózatok esetében a résztvevők hitelesítése jelenti a legkomolyabb problémát, ezután a hagyományos titkosítási algoritmusok már jól alkalmazhatóak. 3.1. Autentikáció nyilvános kulcsú titkosítás segítségével Nyilvános kulcsú titkosítás esetén (PKI – Public Key Infrastructure) mindenki rendelkezik egy nyilvános és egy titkos kulccsal. A nyilvános kulcshoz bárki hozzáférhet, míg a privát kulcsot mindenki csak saját maga tudja. A nyilvános kulcs ismeretében a titkos kulcs, illetve fordítva nem állítható elő. A nyilvános kulccsal lekódolt üzenet csak a neki megfelelő titkos kulccsal dekódolható. Nyilvános kulcsú titkosítás segítségével létrehozhatunk olyan központi helyet, mely tanúsítványokat (certificate) állít ki a nyilvános kulcsok és a megfelelő résztvevők összetartozásáról. Az ilyen központokat Certificate Authority-nak nevezünk (CA) A CA-nak elismertnek, hitelesnek és megbízhatónak kell lennie. A CA segítségével ellenőrizni lehet, hogy használójához tényleg a megfelelő kulcs tartozik-e és hogy ez a kulcs érvényes-e még vagy pedig már visszavonták. A CA-nak on-line elérhetőnek kell maradnia, hogy ezen összerendeléseket folyamatosan biztosítani tudja, és egyben követnie kell a kulcsváltozásokat is, valamint még tanúsítványok visszavonására is képesnek kell lennie. Ad hoc hálózatokban nem alkalmazhatunk központosított CA-kat, ezt a feladatot elosztva kell végezni. A következőkben bemutatjuk e feladat elosztásának két lehetséges módját. 3.1.1.Küszöb kriptográfia (Thresold cryptography) A bizalom elosztásának egy lehetséges módja a küszöb kriptográfia. Egy (n, t+1) séma lehetővé teszi egy kriptográfiai feladat n résztvevő közötti szétosztását úgy, hogy azt bármely t+1 tagja sikeresen el tudja végezni, de ennél kevesebb tag már nem birkózhat meg a feladattal. Ez esetben a kulcs menedzsment szolgáltatás n szervere osztja szét egy bizonyítvány aláírásának jogát. A szolgáltatás titkos kulcsát n részre osztja és eljuttatja ezeket az egyes szervereknek. Ezt a szétosztást a k kulcs (n, t+1) szétosztásának nevezzük. Így minden egyes szerver az aláírásnak csak egy részét képes előállítani, melyek még akkor is sikeresen összekombinálhatóak, ha t szerver kompromittálódott. A küszöb kriptográfia egy nagyon hasznos tulajdonsága, hogy képes a résztvevők információ darabjainak frissítésére. Ez a mozgó támadók kivédését teszi lehetővé, melyek egymás után törik fel a szervereket, melyek mennyisége egy bizonyos idő elteltével meghaladhatná a kritikus t mennyiséget. A szétosztás frissítésekor (share refresh) egy új küszöb kriptográfiai séma jön létre, mely kiválóan alkalmas a hálózat változásaihoz való alkalmazkodásra. Mivel e frissítés nem túl bonyolult művelet, egy kialakított konfiguráció hosszabb ideig is képes a hálózat változásait követni. Viszont ha túl sok résztvevő kompromittálódott, új sémát kell kialakítani.

10

A bemutatott megoldás komoly problémája, hogy feltételezi a résztvevők szinkronitását, amely csak a legritkább esetben áll fenn. Egy csomópont kapcsolata bizonyos időre megszűnhet vagy lelassulhat, miközben előfordulhat, hogy a többiek véghezvisznek egy szétosztás frissítést. Ezek után már nem lesz képes visszakapcsolódni a folyamatba, mert azóta egy újabb konfiguráció alakult ki. A rendszer működésének kezdete komoly probléma, ugyanis ekkor még csak néhány résztvevővel rendelkezik a hálózat. Ekkor is el kell tudni dönteni, hogy ki kezdeményezheti egy szétosztott CA létrehozását. Ráadásul később, ha egy kialakult rendszer diszjunkt részekre szakad, ezek külön is folytathatják működésüket, az újbóli egyesülés lehetőségének engedélyezése további problémát jelenthet. [Haas] 3.1.2.Önszervező PKI (Self Organizing Public Key Infrastructure) A tanúsítvány alapú hitelesítés fő problémáját képezi a megbízott harmadik fél szükségessége, melynek központiságát ad-hoc környezetben el kell kerülni és teljesen önszervező struktúrát kell kialakítani. Küszöb kriptográfia egy megoldást kínált az elosztott CA megvalósítására, de léteznek bizonyítvány alapú autentikációs megoldások (pl. PGP - Pretty Good Privacy), melyekben a z u v bizonyítványokat a felhasználók saját maguk készítik el és önszervező terjesztésük is megoldott. Itt nincsenek központosított kulcstárak, vagy CA-k, hanem U tanúsítvány lánca minden felhasználó rendelkezik egy Z tanúsítvány lánca U-tól V-be egy lánc Z-n keresztül kis méretű helyi tanúsítvány3.1. ábra Önszervező PKI tanúsítványlánca tárolóval, melyben korlátozott számú tanúsítványt képes tárolni. Amikor két felhasználó (u és v) azonosítani szeretnék egymást, egyesítik e tárolójukat, melyben u próbál keresni egy megfelelő tanúsítvány láncot v-hez (3.1.ábra). A gráf pontjai a felhasználókat jelentik, a megfelelő irányítottságú élek pedig a tanúsítvány hitelesítéseket. Ilyen lánc jó eséllyel biztosítható még akkor is, ha a tároló mérete kicsi a hálózat résztvevőinek számához képest. Ezen megközelítés jó megoldás lehet a teljes önszerveződés eléréséhez. Problémát a skálázhatóság jelent, mivel a hálózat növekedésével egyre növekszik a valószínűsége annak, hogy nem létezik majd megfelelő tanúsítvány lánc. [Questfor] 3.1.3. Identitás alapú (ID-Based) kriptográfia Az identitás alapú kriptosémák alapötlete, hogy a nyilvános kulcs szerepét az egységek identifikálására szolgáló szintén nyilvános azonosítók töltsék be, és ezzel a CA által biztosított összerendelő feladatkör szükségtelenné válik. Azonban a nyilvános kulcsú titkosítás lényege éppen abból adódik, hogy a nyilvánosból a titkos kulcs (illetve fordítva) nem származtatható. Ez esetben egyetlen központi entitás képes arra, hogy egy publikus kulcsból (identitás) elkészítse annak titkos párját. Ezt a műveletet csak egyszer, a felhasználók regisztrációjakor kell elvégezni. A rendszerben résztvevő, egymást nem ismerő elemek ezután autentikusan lesznek képesek egymással kommunikálni, mégpedig harmadik féllel való interakció nélkül.

11

A valóságban viszont gondolni kell a kompromittálódott, és később újra regisztrálni akaró résztvevőkre is, tehát a regisztráló központnak mégis elérhetőnek kell maradnia. További veszélyforrás, hogy e központ ismerni fogja a résztvevők titkos kulcsait is, továbbá e titkos kulcs elkészítése erőforrás-igényes feladat, hosszú időt vehet igénybe. [IDbased] 3.2. Kulcs szétosztási eljárások A korábban megtörtént sikeres azonosítás után az információ védelmére egy biztonságos, kódolt kapcsolat létrehozása szükséges. Ilyenre alkalmas a szimmetrikus kulcsú kódolás (Common Key Architecture). Ehhez a résztvevőknek közös, osztott kulccsal kell rendelkezniük, melyet a kódolás és dekódolás folyamatában is használhatnak. Ezzel a megoldással lehetővé válik a bizalmas üzenetszórás (broadcast) vagy többesküldés (multicast). Korábban már számos kulcs menedzsment protokoll kialakult, de az ad hoc hálózatok más igényeket is támasztanak. A következőkben bemutatunk néhány ilyen protokollt. 3.2.1.Diffie-Hellman (DH) kulcs csere A Diffie-Hellman kulcs csere algoritmus segítségével nyilvános csatornán lehetőség nyílik két résztvevő közötti közös titok kialakítására. Egy harmadik résztvevő azonban teljes egészében hallhatja a kommunikációt, viszont mégsem lesz képes ugyanazon közös kulcs létrehozására. A két résztvevő (A és B) megállapodnak egy q rendű G ciklikus véges csoporton és a csoport α generátor elemén. Ezután mindkét résztvevő véletlenszerűen választ egy titkos kitevőt (A és B). Ezután A kiszámítja αA-t, B αB-t és átküldik egymásnak az így megkapott értékeket. Mivel a kitevők titokban maradtak, az átküldött értékeket erre a hatványra emelve kialakul a αAB közös titok, de a lehallgató nem tudja meg magukat a kitevőket, így képtelen a kulcs létrehozására. A kettőnél több résztvevős esetben is lehetséges a kulcs kialakítása. Ezek közül tekintünk most át néhányat. [Applied] 3.2.2. GDH.2 (Generalized Diffie Hellman) A GDH.2 a Diffie-Hellman kulcs csere algoritmus általánosítása több résztvevő esetére. A résztvevők egy láncot alkotnak, majd r1 r1 r2 α α az első tag indít egy üzenetet, melyet 2 α 1 3 12 a résztvevők kiegészítés után αr1r2 αr1r3 láncszerűen továbbküldenek. Ez αr2r3 r1r2r3 igazából csak az egyik oldala a Diffieα Hellman üzenetnek, az utolsó egység 4 küldi a másikat. A kiegészítések a αr1r2r3 r1r3r4 3.2.ábrán láthatóak. Ez a folyamat a α αr2r3r4 legutolsó elemig folytatódik, ami már 3.2.ábra GDH.2 üzenetváltásai képes lesz a közös titok létrehozására, és minden egyes résztvevőnek eljuttatja a számára hiányzó információt. A titok csak a megfelelő végpontok számára lesz ismert. Ezen eljárás fő problémája, hogy az utolsó entitás kitüntetett szereppel rendelkezik, mivel ő továbbítja minden egyes résztvevőnek a hiányzó információt a közös titok előállításához. Ez a 12

kitüntetett szerep egyben maga után vonja, hogy a célpontja lesz a támadásoknak. Másik probléma, hogy viszonylag nagy mennyiségű adat átvitelére van szükség. [Keyest] 3.2.3.Hypercube és Octopus A

C A

αab

αcd

C ab cd αϕ(α ) ϕ(α )

B B

Egy másik megoldás a Hypercube algoritmus. Az eljárás alapötlete párok kialakítása, melyek Diffie-Hellman kulcs csere algoritmus segítségével létrehozzák közös titkaikat. Ezután a párokat is párokba rendezzük, melyek P2

D

D

P1

P3

3.3.ábra A Hypercube üzenetváltásai

között ismét elvégezhető a kulcs-csere kettesével, és így tovább (3.3.ábra). Az eljárás hátránya, hogy a résztvevők száma csak 2n lehet. Megoldásként adódott az Octopus protokoll (3.4.ábra), mely létrehoz egy Hypercube magot, amit karokkal egészít ki (P1, P2, stb.). Először e karok végeznek DH kulcs cserét a nekik megfelelő központi elemekkel, majd e központ alakít ki Hypercube struktúrát, végül pedig közlik a karokkal a kialakult új kulcsot. Hátránya, hogy a Hypercube mag központi szerepet játszik, valamint bonyolult új résztvevők bevonása a rendszerbe. [Keyest]

P5

A

B

C

D

P6

P4

P7

3.4.ábra Az Octopus üzenetváltásai

3.2.4.Kulcstranszport nyilvános kulcsú architektúrán Nyilvános kulcsú architektúra alkalmazása erőforrásigényes megoldás, ezért nagyobb mennyiségű információ titkosítására csak a legritkább esetben használják. Ezzel szemben a szimmetrikus kulcsú titkosítás hatékony megoldást nyújt. Nyilvános kulcsú titkosítást alkalmazó rendszerekben PB(S) egyszerűen létrehozható szimmetrikus kulcspár. Az új kulcsot B létrehozó fél az ismert nyilvános kulcsok hassználatával A bárkinek eljuttathatja a későbbiekben szimmetrikus titkosításra használandó titkot. Ez a kulcstranszport folyamat 3.5. ábra Kulcstranszport látható a 3.5.ábrán. 3.3. Csoport kulcs menedzsment protokoll (Group Key Management Protocol-GKMP) Ez a protokoll a résztvevők egy csoportjának szimmetrikus kulcs menedzsment funkcióit látja el. A GKMP kulcs kialakítási mechanizmusa két résztvevő közötti kooperatív eljárás. (pl: Diffie-Hellman kulcs csere) A kulcs létrehozása után a GKMP elterjeszti e csoport kulcsot az arra jogosult elemeknek. Lehetővé teszi ezen túl új résztvevő beléptetését, tag törlését és a csoport teljes újrakulcsolását. A GKMP teljes jogosultság-ellenőrző rendszert is tartalmaz, mivel a kulcsolás alkalmával jogosultsági tanúsítványok (Permission Certificate – PC) is létrejönnek. Bármely csomópont bárki jogosultságát leellenőrizheti, de módosítani nem

13

képes azt. GKMP-vel lehetséges a kompromittálódott résztvevők kizárása, mivel a feltört résztvevők listája (CRL – Compromise Recovery List) szétterjesztésre kerül a hálózatban. Ez a protokoll megpróbálja a lehető legtöbb feladatot szétosztani a csoporton belül, tehát igyekszik elkerülni bármiféle központi entitást. Ennek ellenére néhány funkció, mint például a jogosultságok osztása továbbra is központosított feladatkörök maradtak. [Gkmp] Láthattuk az előzőekben, hogy a kommunikáció titkosítottságának biztosítása nem jelent komolyabb problémát, mivel közös titok, vagyis titkos csatorna kialakítására és kulcsainak létrehozására léteznek megoldások (DH, GDH.2, Hypercube, Octopus). A közös kulcs a végpontok között kialakítható, így a köztes csomópontok és más lehallgatók számára a kommunikáció rejtve marad. Sokkal komolyabb kihívás ennél az egyes résztvevők azonosítása, vagyis az autentikáció megvalósítása. Ad-hoc hálózatokban nem támaszkodhatunk központi tanúsítványokat biztosító entitásra (Certificate Authority), bár láttuk, hogy kiküszöbölésére léteznek megoldási lehetőségek (Küszöb kriptográfia, Önszervező PKI, ID-Based PKI). 3.4. Üzenetszórásos hitelesítés - TESLA A forrás hitelesítés alapvetően aszimmetrikus művelet, mivel minden vevő képes a hitelesítő üzenet leellenőrzésére, de nem képes annak meghamisítására. A TESLA ezt az asszimetriát kulcsok késleltetett nyilvánosságra hozásával éri el, ennek következtében az autentikáció is késni fog. A TESLA hatékony és kis erőforrásigényű eljárás, mivel szimmetrikus titkosítást használ. A titkok folyamatos nyilvánosságra hozásának következtében nagy mennyiségű kulcsra van szükség, erre egy őstitokból kiinduló egyirányú hash láncot alkalmazunk. A küldő elkészít egy ilyen láncot, majd visszafelé hozza elemeit nyilvánosságra. Így ha egy kulcsot autentikusnak tekintünk, úgy a későbbi kulcsokat is mind autentikusak tekinthetjük, az egyirányú hash függvény miatt mástól nem származhat. Csomag küldésekor a küldő tippel egy pesszimista korlátot a hálózat késleltetésére. Ezután vesz a hash láncából egy olyan kulcsot, mely még a csomag megérkezésekor is biztosan titok lesz. Ezzel a kulccsal számít egy üzenet autentikációs kódot (Message Authentication Code MAC), melyet az üzenettel együtt átküld. Küldõ Vevõ A vevő a csomag érkezésekor először ellenőrzi, hogy a t ü ze net MAC készítéséhez használt kulcs még mindig titok-e. Ha +M AC már nem, az azt jelenti, hogy a küldő már publikálta a i megfelelő kulcsot, tehát a MAC-ot más is előállíthatta, így ti az autentikáció sikertelen (3.6.ábra). Ha titkos még, a vevő puffereli a csomagot addig, amíg a küldő nem publikálja a megfelelő kulcsot, és így Küldõ Vevõ 3.6. ábra Sikertelen TESLA képes lesz majd t ü ze autentikáció net leellenőrizni azt +M AC i (3.7.ábra). A TESLA alkalmazásakor szükség van a küldő és a vevő között időszinkronizálására, melynek nem szükséges ti pontosnak lennie, de a vevőnek jósolnia kell egy legnagyobb időkorlátot a küldő idejéről. Problémát jelenthet az autentikáció késése, valamint a pufferelés megvalósítása, de ennek kiküszöbölésére léteznek megoldások. [Tesla] 3.7. ábra Sikeres TESLA autentikáció

14

4. Útvonalválasztási mechanizmusok Mobil ad hoc hálózatok általában multi hop hálózatok, ahol a csomagok továbbítását a résztvevők végzik. Hagyományos hálózatokban léteznek kitüntetett szerepű pontok (gateway, router), melyek információval rendelkeznek a hálózat felépítéséről, így képesek az útvonal megbízható megválasztására. Ezzel szemben a mobil ad hoc hálózatokban a rendszer felépítése dinamikusan változhat, nincsen fix infrastruktúra, nincsenek kitüntetett pontok. Ennek következtében a hosszabb útvonalak felderítéséhez elosztott algoritmusra van szükség, a meghatározott útvonalakon történő adattovábbításban minden egységnek részt kell vállalnia. A mobil kommunikációs világ útvonalválasztó protokolljai két nagy csoportba sorolhatóak: a proaktív és a reaktív protokollokra. Egy proaktív protokoll folyamatosan igyekszik figyelemmel kísérni a hálózat változásait, időről időre elvégzi a rendszer pillanatnyi felépítésének feltérképezését. Ehhez folyamatosan felderítő csomagokat küld a hálózatba, mely a rendszer terhelését eredményezi. Az ilyen rendszerek további hátránya, hogy a megszerzett információk tárolása révén a résztvevőknek sok szükségtelen információt kell hordozniuk. Mobil ad hoc hálózatokban előnyösebb útvonalválasztást valósítanak meg a reaktív vagy más néven igény szerinti protokollok. Ezek jellemzője, hogy csak akkor próbálkoznak egy útvonal felderítésével, amikor arra igény mutatkozik. Az ilyen protokollok alkalmazása optimálisabb megoldást nyújthat, de mivel az útkeresés csak az igény megjelenése után kezdődik, így a kommunikáció kezdetekor számottevő késedelem jelentkezhet. Léteznek még e két típust ötvöző hibrid útvonalválasztó protokollok is, melyek a kétféle megoldás előnyeit igyekeznek egyesíteni. [Introute] A továbbiakban bemutatunk néhány útvonalválasztó protokollt, melyek az ad hoc hálózatokban jelentős szereppel bírnak. 4.1. Dynamic Source Routing (DSR) A hagyományos IP hálózatok világában már korábban kidolgozásra került a forrás által meghatározott útvonalválasztás (source routing) lehetősége. Ennek lényege, hogy a küldő fél határozza meg a csomag teljes továbbítási útvonalát, és így a közbülső útválasztók beállításaitól függetlenül vihető át a csomag. A kívánt útvonalat a csomag fejrészébe építve a feladó specifikálja, mellyel a közbülső csomópontok számára egyértelműen adottá válik a továbbítás iránya. A DSR egy egyszerű és hatékony útvonalválasztó protokoll, melyet kimondottan vezeték nélküli ad hoc hálózatokhoz terveztek. Használatával olyan rendszer valósul meg, melyben az útvonalválasztás teljesen önszervező és önbeállító módon valósul meg. A rendszer architektúrájának folyamatos megváltozásait a DSR protokoll dinamikusan kezelni tudja. Az átvitel során minden üzenet fejlécébe belekerül a teljes útvonallista, ezáltal az útvonal hurokmentessége garantált lesz. A rendszer működése során nincsen szükség arra, hogy a közbülső résztvevők bármiféle aktuális információval rendelkezzenek. További előny, hogy az információkat vevő minden résztvevő eltárolhatja az abból kikövetkeztetett útvonal információt. A DSR protokoll legfontosabb mechanizmusa az útvonal felderítése, mely akkor következik be, amikor egy forrás útvonalat szeretne keresni egy bizonyos címzetthez. Ekkor egy útvonalkérő csomagot állít elő a küldő, melyben feltünteti a címzettet és üzenetszórással terjeszteni kezdi. Minden szereplő, mely megkapja e csomagot, saját címével kiegészítve újra továbbküldi a kérést, mely így szétterjed a hálózatban. Amennyiben egy ilyen útvonalkérő

15

csomag eljut a címzetthez, a benne szereplő listából azonnal ismerni fogja a csomag teljes érkezési útvonalát. Ezen útvonalon fordított irányban egy Route reply csomagot indít visszafelé, hogy a küldő tudtára hozza, hogy sikerült útvonalat találni. Egyirányú kapcsolatok esetén lehetőség van a RREP üzenet számára egy másik visszafelé vezető útvonalat keresni. Az útvonalkeresés folyamatának meggyorsítására a résztvevők fenntarthatnak bizonyos méretű gyorsítótárat (cache), melyben működő útvonalak információit rögzítik. Az útvonalfelderítés sebessége így jelentős mértékben lecsökkenhet. A DSR másik fontos mechanizmusa az útvonal karbantartás, mellyel az útvonalban fellépő változások kerülnek lekezelésre. Minden továbbító résztvevő felelős a csomag szomszédai felé való eljuttatásáért. Amennyiben valami következtében sikertelenné válik a csomagok továbbítása, úgy Route Error üzenettel értesíthető erről a többi résztvevő, és így elkezdődhet működő útvonal keresése. Működés közben több útvonal is nyilvántartásban tartható, így esetleges meghibásodások esetén a másik útvonalra való átváltás szinte nem is jár időkieséssel. Nem csak meghibásodás esetén lehet szükség ilyen áttérésre, hanem például egy megjelenő optimálisabb útvonalra való átváltáskor is. Kis mobilitású hálózatban, ahol az útvonal-gyorsítótárakban lévő bejegyzések hosszabb ideig is használhatóak maradnak a DSR protokoll meglehetősen jó választásnak tűnik. Hátránya, hogy minden csomagnak a közbülső résztvevők címeit is tartalmaznia kell, mely hosszabb útvonalak, vagy nagy címek (pl. IPv6) esetén jelentős többletterhelést eredményezhet. [Dsrdraft] 4.2. AODV Az AODV szintén egy reaktív protokoll, mely csak kommunikációs igény esetén próbálkozik útvonal felépítésével. Ellentétben a DSR-el, nem forrás útvonalválasztást használ, hanem a közbülső résztvevők döntik el a továbbítás irányát. Ebből adódóan a közbülső egységek döntései alapján továbbítódnak a csomagok, melyeket saját információik alapján hoznak. Ennek megfelelően minden résztvevő rendelkezik egy útvonalválasztó táblázattal, melynek tartalma időről időre dinamikusan változik. Amikor igény lép fel csomagok egy adott címzetthez való eljuttatására, útvonal felderítő folyamat indul el. Ez hasonló a DSR-ben alkalmazott útvonal-felderítő (route request RREQ) üzenettel, amely a hálózatban szétküldésre kerül. Ebben a felderítő csomagban a feladó és küldő címe, valamint még néhány adminisztratív mező található. Minden résztvevő, aki megkapja a RREQ üzenetet, létrehoz saját útvonalválasztó táblájában egy a feladóra mutató (reverse route) bejegyzést, majd tovább terjeszti a kérést. A helyi útvonalválasztó táblák alapján így a feladó már megtalálható lesz, és amikor végül a címzetthez is eljut a kérés, a visszajelzés (RREP- Route Reply) már ezen az útvonalon egyszerűen visszajuthat a feladóhoz. A visszajelzés során minden közbülső résztvevő útvonalválasztó táblájába bekerül az előre, vagyis a címzetthez vezető irány is. AODV esetében figyelmet kell fordítani az útvonal hurokmentességére is. Ezt az útvonal felderítő üzenetek sorszámozásával érik el, melyet minden résztvevő a megfelelő szabályok szerint növel. Az útvonalválasztó táblák nem használt bejegyzései idővel érvényüket vesztik, azonban használat esetén az útvonalak érvényben maradnak. Használat nélkül is lehetőség van helyi Hello üzenetekkel fenntartani az adott kapcsolatot. Amikor egy útvonalban hiba lép fel, akkor az elérhetetlenné váló résztvevőkről útvonalhiba (route error – RERR) üzenet keletkezik. Az AODV-ben megvan a lehetősége az útvonalhibák helyi javításának, amikor is a feladó, illetve a címzett nem is értesülnek az útvonal hiba miatti változásairól.

16

Az AODV kis számítás- és memóriaigényű protokoll, mely elosztott módon valósítja meg az útvonalválasztást. Képes nagyobb mobilitású hálózatok esetén is megfelelően működni, jó skálázhatósági paraméterekkel rendelkezik. [Aodvdraft] 4.3. Zone Routing Protokol (ZRP) A mobil ad hoc hálózatok útvonal-választási protokolljainak a hálózat topológiájának dinamikus változásával, a nem szimmetrikus linkekkel és az alacsony átviteli sebességgel is szembe kell nézniük. Mind a reaktív, mind proaktív protokollok nem bizonyultak teljesen tökéletesnek ebben a környezetben. A Zone Routing Protokoll (ZRP) egyesíti a proaktív és reaktív megoldások előnyeit. Ez folyamatos topológiai térképet tart fenn az egyes zónákba rendelt egységekről. A zónán belüli útvonalak mindig elérhetőek. A zónán kívüliekhez útvonal felderítési mechanizmust használ, melyet egyesít a zónán belüli információkkal. Egy korlátozott területen (zónában) az útvonalakról az aktuális információkat sokkal könnyebb folyamatosan fenntartani, mint az egész hálózatban. Ezáltal a nem használt távolabbi elérési útvonalak száma minimálisra csökkenthető. A zónák közti útvonalakat pedig reaktív módon térképezi fel a protokoll. Mivel minden egység a helyi útvonalakat proaktív módon tárolja ezért egy esetleges útvonal-felderítés sokkal hatékonyabb ezen tárolók felhasználásával. Egy zóna nagyságát ugrások (hop) számában határozzák meg. Például 2 ugrás esetére mutat példát a 4.1.ábra. Ezen látható, hogy az S résztvevőhöz képest a K-n kívül minden résztvevő 2 hop-on belül van. Egy esetleges útvonal-felderítés esetén H először ellenőrzi a forrás, hogy a célpont az adott zónán belül van-e, ha igen, akkor proaktív módon történik a felderítés. Ha nem C B az adott zónán belül, akkor a zónán belüli egység a periférikus résztvevőknek küldi a D route request üzenetet. Mivel a periférikus G S egységek két zónában vannak, azok már a A következő zónákban is ellenőrizni tudják, hogy E ott található-e a célpont. Ha ott sem, akkor I F tovább folytatódik ez a felderítés. Eközben minden szereplő, akin keresztülment a J K felderítés, csatolja a saját elérhetőségét. Ha a felderítő üzenetet hallgató egység tudja a 4.1.ábra A ZRP egy zónája célállomás helyét, akkor az route replay üzenettel felel a forrás felé. Ez az üzenet pedig fordított sorrendben tartalmazza a route request-től kapott résztvevők listáját, így jut vissza a válasz a forráshoz. A ZPR lecsökkenti a forgalmat a tiszta reaktív vagy proaktív protokollhoz képest. A zónák optimális nagysága a résztvevők számától függő érték, ezáltal a ZRP egy jól skálázható protokoll. [Zrpdraft]

17

5. Biztonságos útvonalválasztás Mobil ad-hoc hálózatok biztonságossá tételében jelentős szereppel bír a biztonságos útvonalválasztás megvalósítása. Az ismertetett útvonal-választási protokollok biztonsági szempontokat nem vesznek figyelembe. A veszélyek az útvonalválasztás folyamatának elosztottságából adódnak, feltételezik minden résztvevő együttműködési szándékát. A valóságban sajnos nem ez a helyzet, nem tekinthetünk megbízhatónak olyan rendszert, melynek működését bárki könnyen megtévesztheti. Olyan megoldásra van szükség, mely lehetővé teszi, hogy az útvonalkeresés során a lehetséges útvonalak közül meghatározott szempontok szerint válogassunk. Ezen felül fontos még bizonyosságot nyernünk afelől, hogy a továbbított adatok valóban a kiválasztott úton haladnak végig. 5.1. Onion routing Az Onion routing egy olyan útvonal-választási megoldás, mely lehetőséget nyújt annak biztosítására, hogy az elküldött üzenet csakis egy meghatározott útvonalon utazhasson végig. PB(PC(PD(msg)))

A

B

PC(PD(msg))

PB

C PC

PD(msg)

D

PD

5.1.ábra Onion routing

Ennek megvalósításához az Onion routing nyilvános kulcsú titkosítást használ. Működésének lényege, hogy a küldő az útvonalban előforduló minden egyes továbbító nyilvános kulcsával mintegy héjszerűen betitkosítja az üzenetet. A nyilvános kulcsok védelmét csak a megfelelő titkos kulccsal rendelkező egységek tudják eltávolítani, így a címzetthez eljutó adat csakis abban az esetben lehet feldolgozható, amennyiben végigutazott a meghatározott útvonalon. (5.1.ábra) A csomagküldés elindításához a küldőnek először össze kell gyűjtenie a közbülső továbbítók nyilvános kulcsait, majd az útvonaléval ellenkező sorrendben elvégezni a csomagok titkosítását. Onion routing csak olyan esetekben alkalmazható, amikor a küldő már pontosan tudja, hogy csomagjának milyen útvonalon kell végighaladnia a hálózaton, amely a forrás útvonalválasztások sajátossága (pl. DSR). [Onion] 5.2. Security-Aware Routing - SAR A hagyományos útvonalválasztó megoldások a lehető legoptimálisabb útvonal (például legkevesebb a hop-ok száma vagy a legrövidebb idő) megtalálását tűzik ki célul. Az optimális döntéshez olyan szempontokat vesznek figyelembe, mint például a lehetséges legrövidebb, vagy leggyorsabb útvonal keresése. A SAR a döntés során különféle biztonsági szempontok teljesülését is szem előtt tartja. Egy útvonal biztonságának meghatározására többféle jellemző is megadható. Ilyen lehet például az útvonal megbízhatóságának (trust level) vagy biztonságosságának szintje (security

18

level). A SAR lényege, hogy az útvonalválasztás során ezeket is figyelembe veszi, és csak a megfelelő biztonsági előírásoknak megfelelő útvonal épül ki. A kialakuló útban csak olyan résztvevők vehetnek részt, melyek rendelkeznek a megfelelő, fenti paraméterekkel. (5.2.ábra) Továbbá e szinteknek autentikusnak kell lenniük ahhoz, hogy sem a csomópontok szintjei, sem az igényelt szint ne kompromittálódhasson. SAR alkalmazásakor a küldő, aki útvonal felderítést kér, az igényelt SAR útvonal biztonsági szintet is meghatározza a kérésben. A közbülső résztvevők csak akkor továbbítják a kérést, amennyiben megfelelnek a biztonsági előírásoknak. Ha a kérés eljut a címzetthez, akkor B legrövidebb útvonal kialakulhat a megfelelő biztonsági előírású A útvonal. A SAR kiegészítés szinte bármely igény szerinti (on-demand) útvonalválasztó protokollhoz implementálható. 5.2. ábra A SAR segítségével meghatározott útvonal A SAR megoldások egy komoly nehézsége az, hogy az egyes szinteket autentikálni kell, semmiképpen sem lehet a résztvevők felelőssége saját szintjükről nyilatkozni. Láttuk korábban, hogy ad-hoc hálózatokban az autentikáció kérdéskörének megoldása nem triviális feladat, úgymint az sem, hogy megakadályozzuk a nem megfelelő biztonságú (és esetleg támadó) csomópontok beépülését az útvonalba. Mindezek tetejére már az is támadást jelenthet, ha egy résztvevő biztonsági paraméterei kiolvashatóak, mivel ezek általában szoros összefüggésben vannak annak fontosságával. [Secaware] 5.3. Ariadne Az Ariadne egy olyan igény szerinti útvonalválasztó protokoll, mely képes aktív támadók esetén is megfelelő működést biztosítani. Lehetőséget nyújt autentikus útvonalválasztás véghezvitelére, így még rosszindulatú résztvevők jelenléte esetén is képes megfelelő útvonal kiépítésére. Működése a DSR működésén alapuló forrás útvonalválasztás, de az útvonalválasztó üzenetek hitelesítő mechanizmussal vannak kiegészítve. Ez teszi lehetővé azt, hogy csak meghatározott entitások legyenek képesek az útvonalválasztás folyamatában részt venni. Nagy előnye, hogy működése során csak szimmetrikus kriptográfiai megoldásokra és egyirányú (hash) függvény használatára támaszkodik, így működése telepkímélő. A végpontok közötti hitelesítés megvalósítására az üzenethez, előzőleg osztott titok segítségével, üzenet autentikációs kódot (MAC) csatol. Az üzenetszórással terjesztett üzenetek (pl. RREQ) hitelesítéséhez ez nem megfelelő. Ez az üzenetszórásos hitelesítés a TESLA protokoll segítségével került megoldásra. A folyamat lényegi működését az útvonalkérés (RREQ) folyamatára mutatjuk be, hasonló elvek alapján minden DSR üzenet kiegészíthető hitelesítéssel.

19

A végpontok tehát A rendelkeznek osztott 8. RREP(A,B,C,D,E) titokkal, melynek 1. RREQ(A, E) MACb, MACc, MACd, MACe, Ktd, Ktc, Ktb ha=MACad felhasználásával a kommunikációt B kezdeményező fél az 2. RREQ(A,B,E) 7. RREP(A,B,C,D,E) útvonalkérő csomag MACb, MACc, MACd, MACe, Ktd, Ktc hb=h(MACad, B), MACb hitelesítésére előállítja annak MAC C azonosítóját, melyet a 3. RREQ(A,B,C,E) 6. RREP(A,B,C,D,E) kéréssel együtt hc=h(hb), MACb, MACc MACb, MACc, MACd, MACe, Ktd terjeszteni kezd. A kérést vevő résztvevők D a DSR működésének 4. RREQ(A,B,C,D,E) 5. RREQ(A,B,C,D,E) megfelelően hd=h(hc), MACb, MACc, MACd MACb, MACc, MACd, MACe továbbítás előtt az E útvonallistába illesztik saját azonosítójukat. A 5.3.ábra Az Ariadne mechanizmusa továbbított csomag újabb MAC azonosítóval kerül hitelesítésre. Ezen azonosító előállításához a résztvevők TESLA kulcsot választanak, mely egészen a RREP üzenetig titokban marad. Ezen túl átvitelre kerül még az eredeti üzenet MAC kódjának továbbító címével együtt vett hash kódja. A vevőhöz érkező kérés MAC kódja az osztott kulcs révén ellenőrizhető. A RREP üzenet a kiadódott útvonalon indul vissza kiegészítve a kéréskor összegyűjtött Tesla kulcsos MAC kódokkal. A továbbítás során a Tesla kulcsok sorra leleplezésre kerülnek, és így a továbbítók is autentikusak lesznek. Ez az üzenetváltás látható az 5.3.ábrán. [Ariadne]; [Worksess] 5.4. Folyamatos figyelés, büntető mechanizmusok A watchdog metódus a résztvevők megbízhatóságának folyamatos nyomon követését teszi lehetővé. A rádiós csatorna osztottsága révén minden résztvevő figyelemmel kísérheti közvetlen szomszédainak viselkedését, így könnyen leleplezhet egy megbízhatatlan elemet. Ez a passzív figyelés a hálózatra nézve nem okoz plussz terhelést, de sajnos tévedhet (pl. gyakran elhaló, rossz link, ütközés), illetve megtéveszthető. Megtévesztése történhet például irányított antennával, mert ilyenkor az előző résztvevő a továbbítást nem érzékeli. A támadó résztvevők leleplezésén túl további cél azok kirekesztése a felépülő kommunikációból. Ezt a pathrater eljárás úgy valósítja meg, hogy az egyes utakhoz működésük során felállított statisztikák alapján jósági értékeket rendel. Az egyes utak jósági mutatóját megfelelő működés esetén folyamatosan növeli, míg hiba esetén csökkenti. Ilyen adatok ismeretében az útvonalválasztás során lehetőség van egy megfelelő út kiválasztásra. A legtöbb útvonalválasztó mechanizmus arra törekszik, hogy a kialakuló biztonságos utakban ne szerepelhessenek megbízhatatlan résztvevők. Ezzel a támadó semmiféle hátrányba nem kerül, kevesebben fogják csomagtovábbításra kérni. Az ilyenfajta önző viselkedésminta igen csábító lehet például a telep kímélése céljából, de tömeges méretekben a hálózat működésének megszűnését is eredményezheti. Kiküszöbölése egyfajta virtuális fizetőeszköz, a nuglet alkalmazásával történhet. Ezzel a fizetőeszközzel vásárolják meg a résztvevők egymás szolgáltatását a hálózatban, így az önző egyedek nuglet-jei idővel elfogynak.

20

Az előzőekben megismertünk néhány megoldást, mely lehetővé teszi ad hoc hálózatokban biztonságos útvonalválasztás és üzenettovábbítás megvalósítását. A továbbiakban ezen eljárások formális analízisét fogjuk végezni. Az ehhez használt keretrendszert mutatjuk be a következőkben. [Mitigating]; [Grudges]

21

6. CSP – Communicating Seqential Processes A CSP (Communicating Sequential Processes) egy konkurens rendszerek modellezésére alkalmas nyelv. Segítségével modellezhetővé és analizálhatóvá válnak a párhuzamos rendszerek és a bennük fellépő jelenségek. A CSP megalkotását a párhuzamos számítógépek megjelenése tette indokolttá, melyek a gyors technológiai fejlődés következtében napjainkra már hétköznapossá válnak. Ma már egyetlen áramkörbe integrált, de akár kontinensnyi kiterjedésű számítógép hálózatok formájában is léteznek konkurens rendszerek. Ezen rendszerek közös jellemzője, hogy különálló komponensekből épülnek fel, melyek többé-kevésbé függetlenül, párhuzamosan végzik feladatukat. Egymással üzenetek közvetítésével kommunikálhatnak, így érhető el közöttük adatcsere, így biztosítható sorrendiség vagy szinkronizáció. A konkurens rendszerek működésének megértése általában jóval bonyolultabb feladat, mint szekvenciális rendszereknél volt. Egy konkurens rendszer minden komponense külön állapotban lehet, így az egész rendszer állapotainak alakulása a futás során csak nagyon nehezen követhető. [Sneider] A CSP megalkotását az is indokolttá tette, hogy konkurens rendszerek nem megfelelő tervezéséből adódóan létezik néhány olyan nehezen kideríthető hibalehetőség, mely legtöbbször csak a rendszer egészének formális analízisével fedezhető fel. A következőkben röviden három ilyen jelenséget mutatunk be. A rendszer nem determinisztikus viselkedése Egy rendszert akkor nevezünk nem determinisztikusnak, ha előfordulhat, hogy két külön példánya ugyanazon bemenetek esetén különbözőképpen viselkedik. Rendszerek nem determinisztikus viselkedése gyakran vezethető vissza versenyhelyzetekhez. Erre példa az olyan, két komponens között kialakuló versengés, melynek tétje, hogy melyikük kommunikáljon előbb egy harmadik komponenssel. A teljes determinisztikusság teszteléssel nem bizonyítható tulajdonság, hiszen bármennyiszer is bizonyult már megfelelőnek egy rendszer, sosem zárható ki, hogy a körülmények megváltozása esetén a döntés kimenetele megváltozhat, nem determinisztikussá fajulhat. A nem determinisztikusság kiszűrése fontos feladat, eldöntése azonban a rendszer formális analízisét igényli. Deadlock állapot kialakulása Egy konkurens rendszer akkor van deadlock állapotban, ha egyik komponense sem képes további folyamatokat végezni, általában azért, mert mindegyik komponens a többiekkel való kommunikációra várakozik. Egy ilyen szituációra hétköznapi példa, amikor két telefonáló egymást próbálja felhívni, miközben mindketten foglalt jelzést kapnak. Valós rendszerekben tipikus példa közös erőforrások rosszul megtervezett osztott használata. Az ilyen szituációk párhuzamos rendszerek leállásához vezethetnek, ezért kiszűrésük fontos feladat. Livelock állapot kialakulása A szekvenciális rendszerekben ismert végtelen hurkoknak megfelelően párhuzamos rendszerekben livelock állapot alakulhat ki. Ez akkor következik be, ha egy rendszer bizonyos komponensei végtelen belső kommunikációt folytatnak úgy, hogy eközben egyikük sem kommunikál e csoportból kifelé. Külső vizsgálat szempontjából nagyon hasonlít ez a deadlock állapothoz, ám sokkal nehezebben felfedezhető, mivel a komponensek között van belső tevékenység. Egy rendszer futásának vizsgálata során csak nehezen állapítható meg, hogy a belső elfoglaltság sosem fog véget érni, vagyis livelock állapotban van a rendszer.

22

Most már láthatjuk, miért is van szükség konkurens rendszerek leírására és formális analízisére alkalmas eszközökre. A CSP leírónyelv egy jól használható matematikai keretrendszert nyújt a modellezés leegyszerűsítéséhez. A leíráson túl hatékony eszközök teszik lehetővé ezen modellek analizálását és így a kritikus jelenségek felderítését. 6.1. CSP alapok Párhuzamos rendszerek CSP modellezése során a különféle állapotokat egy-egy processz reprezentálja. Ezen processzek nevesített csatornákon kommunikálnak egymással, különféle eseményekben (event) vesznek részt. Az aÆP jelölés egy olyan processzt jelent, mely az a eseményben való részvétel után P processzként fog viselkedni. A STOP névre hallgató speciális processz nem végezhet semmilyen további kommunikációt. Egy processz működését befolyásolhatják a fellépő események. Ilyen választásra példa az (aÆP | bÆQ) processz, mely a fellépő esemény függvényében kerül P, illetve Q állapotba. Másik választási lehetőség a külső választás, amikor a processz a külső környezet döntésének megfelelően viselkedik. Ennek jelölésére szolgál a P†Q jelölés, mely azt jelenti, hogy a processz a környezet döntése alapján fog P-ként vagy Q-ként viselkedni. Két processz között nem determinisztikus választásra is lehetőség van, ezt jelöli a P∏Q processz. A CHAOS névre hallgató speciális processz teljesen kaotikus működést képvisel, nem determinisztikus viselkedésű, bármilyen eseményekben részt vehet. Processzek párhuzamos kompozíciója újabb processzt reprezentál, P||Q jelöli a P és Q processzek párhuzamos működését. A P||xQ olyan párhuzamos kompozíció, ahol a párhuzamosan futó P és Q processzeknek az X halmaz eseményeire szinkronban kell állniuk. Lehetőség van arra, hogy bizonyos események egy processzen kívülről rejtve maradjanak. Ezt valósítja meg az elrejtő operátor, a P\X processz P-ként viselkedik, ám az X eseményhalmaz csak belső működéséhez szükséges, kívülről nem érhető el. Lehetőség van látható események átnevezésére. Ennek jelölésére szolgál a P[[a<-b]], mely olyan P processzt jelöl, melynek b eseménye a-ra van átnevezve. Többszörös átnevezés is használható, mely jelentősen megkönnyítheti a modellezést. [Sneider] 6.2. Biztonsági protokollok modellezése CSP-ben A továbbiakban biztonsági protokollok CSP modellel való leírásának alapgondolatait ismertetjük. A protokoll résztvevői egymástól független eszközök, ezért ezek külön CSP processzként modellezhetőek. E résztvevők kommunikációja a protokoll által előírt üzenetek, mint események segítségével történik. Ezeket az üzeneteket a valóságban a médium juttatja el küldőtől feladóig, a CSP modellben kommunikációs csatornákon történhet adatcsere. Az így modellezett kommunikációs rendszert fenyegető támadó célja az üzenetek figyelemmel kísérése, majd a megszerzett információk segítségével a résztvevők megtévesztése. A rendszerben csak egyetlen támadó kerül modellezésre, ez nem gyengíti a modellt, sőt mivel több támadó összes megszerzett információit egyetlen pontba helyezve a legkedvezőbb támadási lehetőségeket biztosítjuk és a támadó bárhol elhelyezkedhet. A támadó a rendszerben rendelkezik olyan kommunikációs csatornákkal, melyek lehetővé teszik számára üzenetek lehallgatását (take), teljes eltávolítását (kill), vagy új üzenetek beszúrását (fake). A fenti alapelemeken kívül a konkrét modellezéstől függően még számos egyéb processz, csatorna és esemény is definiált. Léteznek például a szimulációs környezet és a résztvevők

23

közötti adatcserét megvalósító csatornák, ilyenen jelzi a támadó is egy lényeges információ kiszivárgását (leak). A vizsgálat hatékonyságának növelése céljából egyéb modellezési megoldások is alkalmazásra kerülnek. Ezért például minden megszerezhető adattag egy-egy kétállapotú processzként kerül reprezentálásra, melynek állapota arról árulkodik, hogy a támadó birtokába került-e már az információ. Megoldásra került az is, hogy a támadó megszerzett információkból következtetéssel is újabbakhoz juthat, ennek megvalósítására alkalmas például az infer csatorna. A protokoll specifikációi is megadhatóak CSP-ben. Az ellenőrzés lényege, hogy specifikálunk biztonságos állapothalmazokat (pl. támadó nem ismeri meg a titkot), majd a protokoll állapotterének vizsgálatával arról kell megbizonyosodni, hogy ennek ellentmondó állapotok semmiképpen sem fordulhatnak elő. Az ellenőrzés alapelve a finomítás ellenőrzés. Ha egy rendszer komponenseire értelmezhetünk arra vonatkozó relációt, hogy az egyik legalább annyi feltételnek megfelel, mint egy másik, akkor bármely komponenst kicserélhetünk olyan másikra, mely legalább annyi feltételnek eleget tesz, mint a régi. Ha a finomítás szempontjául a rendszer valóban fontos jellemzőit választottuk, akkor a teljes rendszer tulajdonságai a finomítás során biztosan nem romlanak. A következőkben ismertetünk három, konkurens rendszerek jellemzésére alkalmas módot, melyek finomítási szempontul is szolgálhatnak. [Lowe] Traces finomítás Az egyik legszélesebb körben alkalmazott vizsgálati módszer az eseménysorozatok (traceek) vizsgálata. Elve, hogy processzeket az általuk végrehajtható eseménysorozatokkal jellemzünk. Egy Q processz traces finomítottja egy P processznek, ha a P által elvégezhető összes eseménysorozat elvégezhető Q által is, és a P⊆TQ jelöléssel fejezhető ki, vagyis: P⊆T Q = traces(P) ⊆ traces(Q) Ha egy S specifikáció leírja egy rendszer megfelelő állapotait, akkor az összes olyan I implementáció, melyre teljesül, hogy I⊆TS, megfelelő implementáció, mert biztosan nem szerepelnek benne a specifikációnak nem megfelelő események. A STOP processznek, mivel az semmilyen esemény elvégzésére sem képes, minden processz finomítottja. Ezáltal bármely rendszer specifikációja lehet. Failures finomítás Pontosabb eredményt kapunk, ha nem csak a végrehajtható, hanem a nem végrehajtható eseményeket is számba vesszük. A failure egy (s, X) összerendelés, ahol s a processz egy trace-e, míg X az események egy olyan halmaza, melyek végrehajtását a processz az adott állapotban visszautasíthatja. A failures finomítás azt jelenti, hogy a traces finomításon túl a finomított processz failure-jei a finomított processz failure-jeinek részhalmaza legyen. P⊆FQ = failures(Q) ⊆ failures(P) A failures modell deadlock állapot analízisére is alkalmas. Egy processz deadlock állapota azt jelenti, hogy a processz az adott állapotban megtagadhatja minden esemény végrehajtását. A legegyszerűbb deadlock processz ezért a STOP. Failures-Divergences refinement A failures modell még mindig nem elgendő livelock detektálásra, amely állapotban a processz sosem vesz részt látható eseményben. Formálisan a divergencia egy kaotikus állapothoz vezet, melyben minden elvégezhető, de meg is tagadható. A failures-divergences model a divergencia koncepcióját is számba veszi. Egy processz divergenciája az események egy olyan sorát jelenti, melyek elvégzésével a 24

processz livelock állapotába kerül. Ezáltal analizálhatunk olyan rendszereket is, melyekben meg van a lehetősége, hogy soha többé nem végeznek látható eseményt. Divergence használható még olyan szituációk esetében is, amikor a következményekről semmi biztosan nem tudunk. A failures-divergence reláció a következőket jelenti: P⊆FDQ = failures(Q) ⊆ failures(P) divergences(Q) ⊆ divergences(P) [Lowe] 6.3. Specifikációk modellezése CSP-ben. Biztonsági protokollok ellenőrzése a traces finomítási modell alapján történik, ugyanis ebben az esetben minden, a biztonságos állapotoknak megfelelő lehetőség meg lesz vizsgálva, ellentétben a failures, illetve failures-divergences finomítással. Az analízis során arról akarunk megbizonyosodni, hogy a protokoll működése során a specifikált biztonságos állapotokból nem léphet ki. Az ellenőrzés specifikálásához szükségünk van a biztonsági követelmények formális definiálására. A követelmények sokszor csak intuitív módon léteznek, ám precíz matematikai leírásuk nem triviális feladat. A következőkben a használt elvárások CSP definícióit ismertetjük. Titkosság A titkosság alkalmazási körülményektől függően többféleképpen érthető. Nagyon szigorú körülmények esetén definiálható úgy is, hogy egy megfigyelő a résztvevők tevékenységéről semmit se legyen képes megtudni, tehát még a hálózat forgalmának analizálását se tudja végezni. A legtöbb alkalmazáshoz elegendő az elküldött információ tartalmának titkosságára koncentrálni, mely úgy értendő, hogy az átküldött információ ne juthasson a támadó birtokába. Vegyük a felhasználók kommunikációját képező bizalmas üzenetek M halmazát. Arról akarunk megbizonyosodni, hogy egy támadó bármiféle beavatkozás révén sem tud ezen információkat megszerezni. Ha a modellben a támadó a leak csatornán jelezheti üzenetek megszerzését, akkor egy m üzenet megszerzését a támadó a leak!m eseménnyel jelzi. Tehát az m∈M üzenet titkosságát specifikálhatjuk úgy, hogy leak!m esemény biztosan nem fordul elő. Vagyis: SYSTEM||leak!mSTOP ⊆T SYSTEM A STOP és a SYSTEM processzek leak!m eseménnyel szinkronizált párhuzamos kompozíciója egy olyan rendszert jelent, amely a leak!m esemény bekövetkezése esetén leáll. Állításunk tehát az, hogy a vizsgálatunkat képező rendszer, ennek finomítottja. Tehát e specifikáció szerint a leak!m esemény bekövetkezésével biztosan sérül a finomítás. Autentikáció A hitelesség azt jelenti, hogy egy üzenet a valódi feladójától, és eredeti alakjában, tehát módosítás nélkül érkezik meg. Ha modellünkben a receive.i.j.m, illetve send.i.j.m jelöli az i feladótól j-hez irányuló m üzenet vételét (receive), illetve küldését (send), akkor a specifikációt a következőképpen fogalmazhatjuk meg. Ha egy receive.i.j.m esemény bekövetkezik, akkor azt megelőzően kellett történnie egy send.i.j.m üzenetnek is, vagyis egy üzenet elküldésének mindig meg kell előznie annak vételét. CSP-ben megfogalmazva: SYS||a,bSTOP ⊆T SYS||aSTOP, ahol a=receive.i.j.m és b=send.i.j.m.

25

Olyan esetekben tehát, ahol a beérkező üzenet nem annak eredeti feladójától érkezett, a traces finomítás ellenőrzés hibát jelez. [Lowe] 6.4. FDR2 A CSP leírás attól válhatott a gyakorlatban is hasznos eszközzé, hogy léteznek olyan eszközök, melyek segítségével elvégezhető a modellezett rendszerek hatékonyan analízise. Az FDR (Failures-Divergence Refinement), és újabb változata az FDR2 olyan eszközök, melyek lehetővé teszik véges állapotú rendszerek hatékony ellenőrzését. Így lehetőség nyílik nemdeterminisztikusság, deadlock és livelock állapotok ellenőrzésére, valamint rendszerek finomítás ellenőrzését (refinement check) is képes elvégezni. Az FDR ezáltal alkalmas két modell összehasonlításának elvégzésére, vagyis ellenőrizni tudja, hogy adott specifikációnak megfelel-e egy implementáció. Amennyiben az ellenőrzés megdől, úgy az FDR ellenpéldát hoz. Az FDR jelentős hátránya, hogy csak kis méretű, véges rendszerek modell ellenőrzését képes elvégezni. Ez azt is jelenti, hogy rendszereinket leleményesen minél kompaktabb formában és jelentősen leegyszerűsítve kell modelleznünk. Eközben nem hanyagolhatunk el a vizsgálat szempontjából fontos dolgokat, mert az a teljes ellenőrzés eredményét hamisítaná meg. A CSP modelljeinkben a protokoll működésén túl a vizsgálandó rendszer konkrét résztvevői is leírásra kerülnek. [Lowe]

26

7. A Casper Az előző fejezetben láthattuk, miként alkalmas a CSP biztonsági protokollok modellezésére. A modell elkészítése azonban nehéz és hosszadalmas feladat, mely során számos hibalehetőség áll fenn. Felfigyeltek azonban arra, hogy a legtöbb protokoll modellezése leegyszerűsíthető. Már korábban kifejlesztésre került a CAPSL (Common Authentication Protocol Specification Language) leírónyelv, melynek célja biztonsági protokollok egységes formában való megadása volt. Azért fejlesztették ki, hogy a különféle bemeneti fájlokkal dolgozó biztonsági protokoll tesztelő eszközökhöz egy közös bemeneti formátumot nyújthasson. Jelölésrendszere nagyon hasonlít a szakirodalomban használt protokoll leírásokhoz, így egy ilyen fájl megírása gyors és egyszerű művelet. [Casper] 7.1. A Casper bemeneti fájljának felépítése A Casper fordító bemeneti fájlja a CAPSL formátumához hasonlító egyszerű nyelv. Mivel a modell ellenőrzők csak véges modelleken képesek dolgozni, ezért a protokoll leíráson túl szükséges a konkrét vizsgálandó rendszert megadó leírásra is. A Casper beolvasva az SPL bemeneti fájlt, ami alapján képes a CSP modell elkészítésére. [Capsl] A következőkben a Casper bemeneti fájljának elemeit ismertetjük. A fájl lényegileg két nagy részre osztható: • Az első rész feladata a protokoll működésének CAPSL nyelvhez hasonló megadása. Itt írhatjuk le a résztvevők közti üzenetváltásokat, az egységek által elvégzendő logikai utasításokat, ellenőrzéseket, feltételeket. Itt kell meghatározni az üzenetváltások során használt adatelemeket, a résztvevők kezdeti tudását, és a protokoll céljának specifikálását. • A második rész a vizsgálandó rendszer leírását tartalmazza, amelyet ellenőrizni szeretnénk. Itt kell megadni a konkrét rendszerben használt adattípusokat, a kommunikációban résztvevő egységeket. A támadó és képességeinek megadása is itt történik. Ez a két fő rész még tovább osztható összesen 8 kisebb részre: • Free variables rész, mely az adatok típusait határozza meg, és a protokollban használt függvényeket. • Processes összetevő, melyben megadhatjuk, hogy milyen szerepek léteznek a protokollban, és ezen szerepű egységek milyen kezdeti információkkal rendelkeznek. • Protocol description fejezet, mely a protokoll üzenetváltásait írja le. • Specification rész a protokollal szemben támasztott követelményeket fogalmazza meg. • Actual variables fejezet a konkrét rendszerben használatos adattípusokat adja meg • Functions rész, mely a használt függvényeket deklarálja. • System összetevő az analizálandó rendszer szereplőit és kezdeti információit adja meg • Intruder Information fejezet adja meg a támadó leírását és kezdeti tudását

27

Minden egyes rész ’#’ jellel kezdődik. A következő részben az egyes fejezeteket részletesebben is bemutatjuk. Az 7.1.ábrán látható egy egyszerű SPL fájl. Free variable rész Ebben a részben határozhatjuk meg a protokoll működéséhez szükséges változók és függvények típusait, neveit. Típusként bármilyen név használható, de általában szabványos neveket adtunk (Agent, Nonce, stb.). A TimeStamp és a HashFunction kulcsszavak kivételt képeznek, mivel azt a Casper másképp kezeli: a TimeStamp „időbélyeget” jelképez, a HashFunction pedig a kriptográfiai módszereknél megismert egyirányú hash függvényt jelenti. Függvényeket is definiálhatunk a ’->’ szimbólummal, mellyel megadható a hozzárendelés szabálya. Az InverseKeys sorban az összetartozó, vagyis egymás hatását kiküszöbölő kulcspárokat adhatjuk meg, így modellezhető nyilvános kulcsú (PublicKey, PrivateKey), vagy szimmetrikus kulcsú (Skey, Skey) titkosítás is.

#Free variables A, B: Agent S : Server na, nb : Nonce kab : SessionKey SKey : Agent -> ServerKey InverseKeys = (SKey, Skey)

Processes fejezet A protokoll futtásához szükséges szerepeket adhatjuk meg. Szinte mindig használt a futást kezdeményező (INITIATOR), illetve a válaszoló (RESPONDER) szerepek, de ezeken túl szabadon hozhatunk ilyeneket létre. A szerepek utáni zárójelben a protokoll futásához szükséges információk adhatóak meg. A zárójelben mindig szerepel saját identitásáról árulkodó adattag, de egyéb információk is (pl. Nonce). A knows kulcsszó után adhatóak meg a hosszabb távon is maradandó függvények.

#Actual variables Anna, Bea, Pongo : Agent Cili : Server Na, Nb, Np : Nonce Kab : SessionKey

#Processes INITIATOR(A,S,kab) knows SKey(A) RESPONDER(B) knows SKey(B) SERVER(S) knows SKey #Protocol description 0. -> A : B [ A!=B] 1. A -> S : {B, kab, na}{SKey(A)} 2. S -> B : {A, kab, nb}{SKey(B)} #Specification Secret(A, kab, [B,S]) Agreement(A, B, [kab])

#Functions symbolic Skey #System INITIATOR(Anna, Cili, Kab) RESPONDER(Bea) SERVER(Cili) #Intruder Information Intruder = Pongo IntruderKnowledge = {Anna, Bea, Cili, Pongo, Np, SKey(Pongo)}

Protocol description rész A protokollban lévő üzenetváltások leírására szolgáló rész, melyből kiderül a résztvevők által 7.1.ábra Az SPL fájl felépítése küldött és vett üzenetek sorrendje és tartalma. Először a küldőt, majd a ’->’ után a célt kell megadni. A ’:’ után következik maga az üzenet. A 0. üzenetben olyan speciális esetet láthatunk, amikor a rendszertől érkezik információ az A résztvevőnek. Az üzenetküldések közé feltétel ellenőrzéseket (pl.: [A!=B] ) is beszúrhatunk. A résztvevők bármilyen rendelkezésükre álló üzenetet átküldhetnek: kulcsokat, azonosítókat… stb. Az üzenetek titkosítása az {m}{k} jelöléssel történhet, amelyben az m az üzenetet, a k pedig a titkosító kulcsot jelenti. A fogadó a kapott üzenetet mindig értelmezni próbálja, kivéve, ha az üzenet után használjuk a % jelölési módot. Ennek alkalmazása a következőképp történik: {m}{k}%var, mely azt jelenti, hogy a fogadó a kapott üzenetet értelmezés nélkül eltárolja a var változóba. Onnan ezt egy következő üzenetnél a var%{m}{k} módon olvashatjuk ki és küldhetjük tovább.

28

Specifications fejezet Ebben fogalmazhatjuk meg a protokollal szemben támasztott követelményünket, melynek két fő fajtája lehet. A titkosság specifikációja a következőképpen használható: Secret(A, kab, [B,S]), mely azt jelenti, hogy amikor az A résztvevő befejezi a protokoll futtatását, a kab adattagot önmagán kívül legfeljebb a B és S tudhatja még. A másik fontos specifikáció az Agreement(A, B, [kab]), mely azt jelenti, hogy amikor B befejezte a protokoll futtatását A-val, előzőleg A is futtatta a protokollt B-vel, megfelelő szerepekben voltak és a kab kulcsban sikeresen megegyeztek. Ezeknek további változatai is léteznek, a StrongSecret specifikáció például nem követeli meg a protokoll sikeres befejezését, csak a titok előírás betartását. A legtöbb előírásnak létezik Timed kulcsszóval kezdődő változata is, ezen specifikációk időzítési feltétellel egészítik ki a specifikációt. Actual variables rész Ez tartalmazza az aktuális protokoll szereplőit, változóit, kulcsait stb. A Free variable fejezettel összhangban kell lennie, de például a protokoll többszöri futásához lehetnek további adattagok. Mi ugyanazon elnevezéseket használtuk mint az általános részben, csak nagy kezdőbetűvel írva őket. Ugyancsak itt lehet megadni a TimeStamp értéktartományát, illetve az egész rendszer időtartományát, a MaxRunTime értéket. Functions fejezet A Free variable részben definiált függvények közül a rendszerben használatosakat itt is meg kell adni. Ezeket symbolic kulcsszóval deklarálhatjuk, így a Casper a függvényt végrehajtva egy értéket rendel hozzá. System rész Itt határozzuk meg a rendszerünkben a protokollt futó résztvevők szerepét és azok információit. Lehetőség van a protokoll többszöri futtatására, de arra is, hogy egy résztvevő például több szerepet is futtathasson. Intruder Information fejezet Ebben a részben határozhatjuk meg a támadó identitását és kiindulási tudásbázisát.

29

8. Biztonsági vizsgálatok Az előző fejezetekben megismertük az ad hoc hálózatokat, ismertettük a veszélyt jelentő támadási formákat. Megvizsgáltuk a rendelkezésünkre álló biztonsági mechanizmusokat, és azon megoldási lehetőségeket, melyek lehetővé tehetik ezeknek ad hoc környezetben való alkalmazását. Megnéztük az alkalmazható útvonal-választási mechanizmusokat és ezek biztonságossá tételének lehetőségeit. Bemutattunk egy, a biztonsági protokollok analizására alkalmazható keretrendszert, melyben a CSP processz algebra segítségével modellezett protokollok biztonsági analízisét az FDR modell ellenőrző hatékonyan képes elvégezni. A Casper fordító segítségével modellek előállításának felgyorsítása válik lehetővé. Munkánk során ezt a keretrendszert alkalmaztuk mobil ad hoc hálózatokban fontosnak bizonyuló protokollok analízisére. Modelljeink elkészítését a Casper fordító tette hatékonyabbá. Az SPL formátumban megírt modellekből a fordító elkészítette a rendszer CSP leírását. Ezt a leírást modell ellenőrző segítségével vetettük tesztelés alá. A mobil ad hoc hálózatok protokolljainak üzenetváltásai modellezési szempontból abban különböznek a hagyományos hálózatokétól, hogy ezekben csak a hatótávolságon belül elhelyezkedő résztvevők képesek egymással kommunikálni. Eközben nem vehetnek igénybe központilag elérhető szervert, a résztvevők pusztán szomszédaikra támaszkodhatnak. A támadó ezzel szemben bárkivel kommunikálhat, mivel feltételezhetjük, hogy ehhez speciális hardverrel rendelkezik (pl. érzékeny rádióvevő). Munkánk során az útvonalválasztás mechanizmusait leírtuk és vizsgáltuk. Ezekben A B C a. mindig egy kezdeményező (INITIATOR) fél indít kommunikációt egy válaszoló (RESPONDER) félhez, akivel közvetlenül nem áll kapcsolatban. b. A B C A kommunikáció megvalósításához csomagtovábbításra van szükség, melyet az c. A B C útvonalban elhelyezkedő resztvevők (FWDER) végeznek. A modellezett protokollokat számos d. A B C rendszerben vizsgáltuk. Először mindig a legegyszerűbb esetet vettük, amikor is miden szerep csak egyszer, és más-más résztvevők által e. A B C futhat le. (8.1.a.ábra) Ezen felül vizsgáltunk olyan esetet, amikor a A B C f. kezdeményező fél válaszoló szerepet is játszhat, a valóságban ugyanis ez gyakran előforduló eset 8.1.ábra A legegyszerűbb modellezett esetek (Pl. kliens és szerver egyben). (8.1.b.ábra) Mivel a továbbító szereplők több résztvevő csomagtovábbításában is részt vehetnek, ezért olyan rendszer-összeállítást is vizsgáltunk, amikor a továbbító szerep többször, akár párhuzamosan is futhat. (8.1.c.ábra) Vizsgáltunk ezen felül olyan összeállítást, amikor a küldő kétszer ugyanazon üzenetet igyekszik eljuttatni egy címzetthez. (8.1.d.ábra) Ennek párja az a rendszer, melynek válaszoló szereplője futtathatja többször a protokollt. (8.1.e.ábra) Minden esetben vizsgáltunk olyan összeállítást is, amikor az üzenetváltás kétszer, ellentétes irányban történt. Ebben az esetben a kezdeményező fél egyben válaszoló is, illetve a válaszoló fél kezdeményező is. (8.1.f.ábra) A vizsgált protokollokat tehát leírtuk és ezen rendszerekben teszteltük, a következőkben analízisünk eredményét ismertetjük.

30

8.1. Forrás útvonalválasztás A mobil ad hoc hálózatok biztonságos variables útvonalválasztása során nagy jelentősége #Free A, B, C : Agent van a forrás útvonalválasztáson alapuló na : Nonce : SecretKey megoldásoknak. A DSR útvonalválasztó skey InverseKeys = (skey, skey) protokoll nem használ titkosítást, ezért nem tekinthető biztonságosnak. Egy útvonal #Processes INITIATOR(A, B, C, na, skey) kiválasztása után végpontok közötti FWDER(B) titkosítás alkalmazásával azonban már RESPONDER(C, skey) használhatjuk a forrás útvonalválasztás #Protocol description 1. A -> B : C, {na}{skey}%enc folyamatát titkos adattovábbításra. 2. B -> C : A, enc%{na}{skey} Elkészítettünk egy forrás útvonalválasztást 3. C -> B : {na}{skey}%enc2 4. B -> A : enc2%{na}{skey} alkalmazó, titkosított adatcserét megvalósító rendszer modelljét. Ezen rendszer SPL #Specification Secret(A, na, [C]) leírása látható a 8.2.ábrán. A végpontok (A Agreement(A, C, [B]) és B) közötti titkosításhoz előzőleg osztott Agreement(A, B, [C]) titok (SecretKey) áll rendelkezésre, mellyel #Actual variables az átküldendő adatelemet (Nonce) Anna, Bea, Cili, Pongo : Agent SKey : SecretKey szeretnénk átjuttatni. Az adattovábbításhoz Na : Nonce mindössze egyetlen (B) résztvevőre van InverseKeys=(SKey, SKey) szükség. Az üzenetek fejlécében elküldött #Functions útvonal kódolatlanul szerepel. Az #System üzenetküldésben (1. lépés) a továbbító (B) a INITIATOR(Anna, Bea, Cili, Na, SKey) titkosító kulcs (skey) hiányában nem tudja FWDER(Bea) RESPONDER(Cili, SKey) elvégezni a dekódolást, ezért azt egy enc Information változóba tárolja el a % jelölési mód #Intruder Intruder = Pongo segítségével, majd a következő protokoll- IntruderKnowledge = {Anna, Bea, Cili, Pongo} lépésben küldi tovább. A protokoll specifikációja három részből 8.2.ábra Forrás útvonalválasztás áll. Az első specifikáció az adatelem (na) titkosságát vizsgálja, melyet az A és C 1. Anna -> I_Bea : Cili, {Na}{SKey} résztvevőkön kívül más nem tudhat meg. A 1. 2. I_Pongo -> Cili : Anna, {Na}{SKey} második feltétel arra vonatkozik, hogy C az 3. Cili -> I_Pongo : {Na}{SKey} A entitással ugyanazon B továbbítót 2. használja a kommunikációra. Az utolsó 1. I_Bea -> Bea : Pongo, Garbage specifikáció a továbbító futására vonatkozó 2. Bea -> I_Pongo : Bea, Garbage 3. I_Pongo -> Bea : Garbage megegyezés, arra vonatkozólag, hogy mely 4. Bea -> I_Bea : Garbage pontok között továbbítja az információt. A támadó előzetes információként ismeri a 8.3.ábra Forrás útvonalválasztás támadásai protokollban résztvevők identitását. Ezen modellt még a legegyszerűbb rendszerben vizsgálva (8.1.a.ábra) is támadási lehetőség adódott. Nézzük meg, hogy milyen üzenetváltások mellett sérül a specifikáció (8.3.ábra). Kétféle támadás jöhet szóba: 1. Anna azt hiszi, hogy kezdeményezőként futatta a protokollt Cilivel, Beán keresztül. Cili a válaszoló szerepét tölti be, viszont hozzá már Pongo-n keresztül jutott el az üzenet. Bea-n keresztül nem folyt kommunikáció. Ez a támadási forma tulajdonképpen egy

31

wormhole támadás, melyben a támadó az optimálisnak felépített útvonalat áthidalva továbbítja a csomagokat. 2. Bea azt gondolja, hogy továbbító szerepében vett részt a protokoll egy szabályos futtatásában. Valójában a támadó értelmetlen üzenetet küldött neki, amit egy másik támadó felé kell továbbítania. Az üzenet kódolt része pedig számára értelmezhetetlen volt, ami helyes protokoll-működés során is így van. Viszont itt ez az üzenet értelmetlen (Garbage) volt, azaz a támadó csak a protokoll felesleges futtatása érdekében szúrta be. Nem játszott szerepet sem Anna, sem Cili. Bea megtéveszthető, és a támadás telepének gyengítését, illetve egyéb limitált erőforrásainak lefoglalását célozhatja. Így ez DoS támadásra használható. Láthattuk, hogy az #Processes egyszerű titkosítást INITIATOR(A, B, C, na) knows Skey(A) FWDER(B) knows Skey(B) alkalmazó forrás- RESPONDER(C) knows Skey útvonalválasztás nem #Protocol description tökéletes, az útvonalat a 1. A -> B : C, {na}{Skey(A)}%enc, f(Skey(A))%henc támadó módosítani tudja. 2. B -> C : A, enc%{na}{Skey(A)}, f(henc%f(Skey(A)), Skey(B)) 3. C -> B : {na}{Skey(A)}%enc2 Ezért kibővítettük az 4. B -> A : enc2%{na}{Skey(A)} előzőekben alkalmazott protokollt úgy, hogy 8.4.ábra Módosított forrás útvonalválasztás résztvevői hitelesítettek legyenek. Ehhez mindenkinek #Free variables B, C : Agent rendelkeznie kell egy, a címzettel A, na : Nonce előzőleg osztott titkos kulccsal. PKey : Agent -> PublicKey : Agent -> SecretKey (Erre jó például az authentikált DH SKey InverseKeys = (SKey, PKey) üzenetváltás.) Az üzenettovábbítások során #Processes INITIATOR(A, B, C, na) knows SKey(A), PKey mindenkinek csatolnia kell titkos FWDER(B) knows SKey(B) kulcsával készített ujjlenyomatát. RESPONDER(C) knows SKey(C), PKey Mivel a célpont mindenkinek #Protocol description A -> B : {({na, A, B}{PKey(C)}%enc), C}{PKey(B)} ismeri a titkos kulcsát, ezért a 1. 2. B -> C : enc%{na, A, B}{PKey(C)} lenyomatok alapján ellenőrizni tudja, hogy az üzenet tényleg #Specification Agreement(A, C, [B]) keresztülhaladt az útvonalban #Actual variables megjelölt résztvevőkön. (8.4.ábra) Anna, Bea, Cili, Pongo : Agent Az általunk kibővített rendszert is Na : Nonce megvizsgáltuk, a vizsgált #Functions rendszerek egyikében sem adódott symbolic PKey symbolic SKey támadási lehetőség. 8.2. ONION routing

#System INITIATOR(Anna, Bea, Cili, Na) FWDER(Bea) RESPONDER(Cili) #Intruder Information

= Pongo A dolgozat első részében Intruder IntruderKnowledge = {Anna, Bea, Cili, Pongo, PKey} ismertetett Onion routing adatok védelme mellett védett 8.5.ábra Onion routing modellezése útvonalirányításra is alkalmazható megoldás. A következőkben ennek modellezését és analízisét végezzük el. E protokoll modellezése során egyetlen továbbító (FWDER) szereplőt alkalmazuk, majd belátjuk, hogy ez nem jár az általánosság vesztésével.

32

Az Onion routing nem szimmetrikus, hanem nyilvános kulcsú titkosítással dolgozik, melyek a Pkey és Skey függvények reprezentálnak. (8.5.ábra) Minden résztvevő ismeri a többiek publikus kulcsát, ám annak titkos megfelelőjét nem. Az Onion routing folyamatában a küldő mindenkinek a publikus kulccsával titkosítja az üzenetet, melyeket minden továbbító résztvevők eltávolít saját privát kulccsával, majd továbbküldi azt. A % jelölési módot itt is be kellett vezetni, mert csak a címzett értelmezheti az üzenetet. A protokoll futásának végén A és C résztvevőknek meg kell egyezni a továbbító személyében. A támadó a résztvevőket, és azok publikus kulcsait ismeri. Ezen protokollt a legegyszerűbb rendszerre (8.1.a.ábra) vizsgálva nem találtunk támadást, A I ám összetettebb protokollok (8.1.e.ábra) esetén kiderültek gyengéi. A 8.6.ábrának megfelelő üzenettovábítás során támadási lehetőséget találtunk. B C A támadás üzeneteit a 8.7.ábrán láthatjuk. Anna azt hiszi, hogy kezdeményezőként futattja a protokollt Cili-vel Bea-n keresztül, Cili pedig azt gondolja, hogy mind a kétszer megkapott üzenetet Anna-tól és Bea-n keresztül származik. D Ez a támadás azért lehetséges, mert a modellben nem alkalmaztunk semmiféle 8.6.ábra Támadás Onion routingra visszajelzést, ezért a lehallgatott üzenet újbóli bejátszását a vevő új kérésnek értelmezheti. A valóságban ez veszélyes lehet, mert C azt hiheti, hogy A egy bizonyos műveletet meg akar ismételni (pl. egy banki tranzakció). Az utolsó továbbítás során már csak a címzett kulcsa védi az üzenetet. 1. Anna -> I_Bea 1. I_Dora -> Bea 2. Bea -> I_Cili 2. I_Bea -> Cili 2. I_Bea -> Cili

: : : : :

{{Na, Anna, Bea}{PKey(Cili)}, Cili}{PKey(Bea)} {{Na, Anna, Bea}{PKey(Cili)}, Cili}{PKey(Bea)} {Na, Anna, Bea}{PKey(Cili)} {Na, Anna, Bea}{PKey(Cili)} {Na, Anna, Bea}{PKey(Cili)}

A következőkben az Onion routing protokoll egy olyan változatának 8.7.ábra Onion támadás üzenetei modelljét készítettük el, melyben a visszajelzés is megoldott. Ehhez a protokoll modelljén is változtattunk, olyan kétirányú üzenetváltást alkalmazunk, mely két, egymást követő és ellentétes irányú Onion routing-ot alkalmazó üzenetváltásból épül fel. A modell SPL fájlja a 8.8.ábrán látható. Ebben a modellben az a célponthoz vezető út (1. és 2. üzenet) az ellőzőhöz hasonlóan történik, melyet a forráshoz visszavezető üzenet követ (3. és 4. üzenet). A protokoll futása végén A-nak és C-nek B-ben, valamint az adattagokban kell megegyezniük. Ezen modell már kiküszöböli az előzőekben ismertetett támadást, minden megvizsgált rendszerre hibátlannak bizonyult. Lássuk most be, hogy az előző modellünk több továbbító alkalmazása esetén esetén is biztonságos marad. Vegyünk először egy olyan rendszert, melyben A-tól B-ig két résztvevő (F1, F2) továbbításával jut el az M üzenet a címzetthez (8.9.a.ábra). Állításunk, hogy e két továbbítót alkalmazó Onion routing ugyanazon specifikációknak megfelel, mint az egy továbbítót használó. Bizonyításként tekintsünk egy olyan három résztvevős rendszert, melyben a kezdeményező (A) az M*=PKB(M) speciális titkosított üzenet továbbítja F2-höz F1-en keresztül (8.9.b.ábra). Ezen M* eljuttatása biztonságos, mivel ez a korábban analizált három résztvevős esettel ekvivalens. Vegyünk most egy olyan másik rendszert, melynek F1 a kezdeményezője, és F2

33

továbbításával juttatja el M üzenetét B-nek (8.9.c.ábra). Ez a rendszer szintén három résztvevős, így megfelel az specifikációnak, a PKB(M) üzenet azonban tekinthető az előző esetben használt M* üzenetnek. Ezáltal beláttuk, hogy az üzenet az AÆF1ÆF2ÆB útvonalon biztonságosan jut el. Ezen állítás alapján az Onion routing biztonságossága kiterjeszthető n továbbító esetére is (8.10.ábra). Minden Fi továbbítóból Fi+2-be biztonságosan eljuttatható Fi üzenete, mely lehet az A küldőtől származó B-nek címzett titkos üzenet is.

#Free variables A, B, C : Agent na, nc : Nonce PKey : Agent -> PublicKey SKey : Agent -> SecretKey Shared : Agent -> SharedKey enc, enc2 : Adat InverseKeys = (SKey, PKey) #Processes INITIATOR(A, B, C, na) knows SKey(A), PKey, Shared(C) FWDER(B) knows SKey(B) RESPONDER(C, nc) knows SKey(C), PKey #Protocol description 1. A -> B : {({na, A, B}{PKey(C)}%enc), C}{PKey(B)} 2. B -> C : enc%{na, A, B}{PKey(C)} 3. C -> B : {({na, nc, C, B}{PKey(A)}%enc2), A}{PKey(B)} 4. B -> A : enc2%{na, nc, C, B}{PKey(A)} #Specification Agreement(C, A, [B, na, nc]) #Actual variables Anna, Bea, Cili, Pongo : Agent Np, Na, Nc, Nd : Nonce Enc, Enc2: Adat #Functions symbolic PKey symbolic SKey symbolic Shared

8.3. TESLA Mobil ad hoc hálózatokban a korábban ismertetett TESLA protokollnak jelentős létjogosultsága lehet, hiszen többesküldéses hitelesítésre többször is szükség van. Elkészítettük ezen protokoll modelljét,melyet a 8.11.ábrán láthatunk. A TESLA hitelesítés titkos kulcsok késleltetett nyilvánosságra hozásán alapszik. Modellünkben két kulcsot használtunk, egy előzőleg egyeztetett őstitkot (rootkey), valamint egy, csak a kezdeményező által ismert új kulcsot (tkey). A első üzenetben a kezdeményező egy, a tkey-re épülő információt küld el a vevőnek, aki ezt nem képes értelmezni, de eltárolja azt, hogy a később érkező tkey-el ellenőrizni tudja. Az üzenetküldésekkor

#System INITIATOR(Anna, Bea, Cili, Na) FWDER(Bea) RESPONDER(Cili, Nc) RESPONDER(Cili, Nd) #Intruder Information Intruder = Pongo IntruderKnowledge = {Anna, Bea, Cili, Pongo, PKey, Np}

8.8.ábra Visszajelzéses Onion P F1(PF2 (PB(M)))

a.

P F2(P B(M))

A

F1

PF1(P F2(M*))

b.

PB(M)

A

F2

B

PF2(M*)

F1

F2

PF2(M*)=P F2(P B(M))

F1

c.

PB(M)

F2

B

8.9.ábra Onion routing kiterjesztése több résztvevőre

M*=Pi(Pi+1(Pi+2(Pn(PB(M))))) A

F1

...

Fi

Fi+1

Fi+2

...

Fn

8.10.ábra Onion routing kiterjesztése n résztvevőre

34

B

mindig küldünk időbélyeget is, mely azt a célt szolgálja, hogy a Tesla kulcs nyilvánosságra #Free variables A, B : Agent ts1,ts2 : TimeStamp na : Nonce rootkey, tkey : TeslaKey InverseKeys = (rootkey, rootkey), (tkey, tkey) #Processes INITIATOR(A, na, rootkey, tkey) RESPONDER(B, rootkey) #Protocol description 0. -> A : B [A!=B] 1. A -> B : {ts1}{rootkey}, {A, B, na}{tkey}%enc [ts1==now or ts1+1==now] 2. A -> B : {tkey, ts2}{rootkey} [ts1
8.11.ábra TESLA leírása

hozása ne előzze meg az ezen alapuló hitelesítő üzenet megérkezését. Az idő és a többi adattag egyezését ezesetben külön feltétellel ellenőrizni kell. Ezt a protokollt is leteszteltük minden vizsgálati rendszerünk összeállítása szerint, de támadási lehetőséget nem találtunk.

8.4. Ariadne Az Ariadne olyan útvonalválasztó protokoll, melyben az üzenetek hitelesítő mechanizmussal vannak kiegészítve. Először is nézzünk meg egy egyszerű Ariadne modellt. Három résztvevős rendszert vizsgálunk, melyben egyetlen továbbító közvetítésével valósul meg két résztvevő kommunikációja. A modell leírása a 8.12. ábrán látható. A kezdeményező (INITIATOR) és a válaszoló (RESPONDER) résztvevők előzőleg osztott titokkal (skey) rendelkeznek, míg az egyetlen továbbító (FWDER) TESLA kulcsot használ az üzenetek autentikálására. Az első üzenetben átküldött f(A, C, skey) jelenti az üzenet autentikációs kódot (MAC). A továbbító tag pedig az f(h0, tkeyb) tagban teszi az üzenetbe ujjlenyomatát. A válaszoló visszafelé indított üzenete során a közbülső résztvevők felfedik TESLA kulcsaikat. Ekkor az hitelesíteni tudja az üzenetváltásokat.

35

#Free variables A, B, C : Agent f : HashFunction skey : SecretKey tkeyb : TimedKey InverseKeys = (skey, skey), (tkeyb, tkeyb) h0, h1, mb, mc : Adat #Processes INITIATOR(A, B, C, skey) FWDER (B, C, tkeyb) RESPONDER(C, skey) #Protocol description 1. A -> B : C, f(A, C, skey)%h0 2. B -> C : A, C, f(h0, tkeyb)%mb, f(h0, B)%h1 3. C -> B : A, B, mb%f(h0, tkeyb), f(mb, skey)%mc 4. B -> A : C, tkeyb, f(h0%f(A, C, skey), tkeyb), mc%f(f(h0%f(A, C, skey), tkeyb), skey) #Specification Agreement(C, A, [B]) #Actual variables Anna, Bea, Cili, Pongo : Agent Skey : SecretKey Tkeyb, Tkeyp : TimedKey H0, H1, Hp, MB, MC, Mp : Adat InverseKeys = (Skey, Skey), (Tkeyb, Tkeyb),(Tkeyp, Tkeyp) #Functions #System INITIATOR(Anna, Bea, Cili, Skey) FWDER (Bea, Cili, Tkeyb) RESPONDER(Cili, Skey) #Intruder Information Intruder = Pongo IntruderKnowledge = {Anna, Bea, Cili, Pongo, Tkeyp, Hp, Mp}

8.12.ábra. Ariadne leírása

A protokoll működése során a kezdeményező és válaszoló egységeknek a továbbító résztvevő identitásában kell megeggyezniük, vagyis a valódi továbbítót használják. Minden vizsgálatunkat képező rendszerre lefuttattuk az ellenőrzést, a tesztelés során semmiféle támadási lehetőségre nem derült fény, az Ariadne protokoll megfelelőnek bizonyult. A következőkben bebizonyítjuk, hogy az Ariadne több résztvevő esetén is ugyanazon biztonsági jellemzőket A F1 F2 B nyújtja, mint az előzőleg vizsgált esetben. M0, M1, M2, MB M0, M1, M2, MB M0, M1, M2 Nézzük meg először, SF1 SF2 MB=h(SB, M2) általánosítható-e a rendszer négy résztvevő esetére 8.13.ábra Ariadne üzenetváltásai (8.13.ábra). A h0, h1, h2 üzenetek célja a forrás (A) autentikálása a vevőben (B). Mivel e hash-sorozat egyetlen titkos tagja (SA) A-tól származik, így a továbbítók számának növelésével e mechanizmus nem gyengül. h0=h(SA, A) M0=h(SA, A)

h1=h(h0, F1) M1=h(SF1, M0)

h2=h(h1, F2) M2=h(SF2, M1)

36

Az M0, M1, M2, MB üzenetek célja B autentikálása A felé, a hitelesítést megvalósító TESLA kulcsok (S1, S2) csak késleltetve, a visszafelé vezető úton kerülnek nyilvánosságra. Tegyük fel, hogy az M2 üzenetet már az M1-el M1, M2 egyidőben nyilvánosságra hozzuk. Ezzel a támadó számára kedvezőbb helyzetet biztosítunk, mert a valódinál hamarabb A F1 F2 B ismerheti meg M2-t, de annak meghamisítására biztosan nem képes, mert az előállításához SF1, SF2 szükséges TESLA kulccsal (S2) ekkor még biztosan nem rendelkezik. A TESLA kulcsok 8.14.ábra M-ek és S-ek nyílvánosságra hozása felfedése csak az MB létrehozása után, a visszafelé vezető lépésekben történik. Fedjük fel #Protocol description 1. A -> B : C, f(A, C, skey)%h0 2. B -> C : A, C, f(h0, tkeyb)%mb, f((h0, tkeyb), tkeyb2)%mb2 3. C -> B : A, B, f(mb2, skey)%mc 4. B -> A : C, tkeyb,tkeyb2, f(h0%f(A, C, skey), tkeyb), (f(h0%f(A,C,skey), tkeyb), tkeyb2), mc%f(f(h0%f(A, C, skey), tkeyb), skey)

8.15. ábra A két összevont továbbító modellje

MB

SF2

SFi

M2

Mi

Mn

MB

mindkét TESLA kulcsot (S1, S2) egyidőben, közvetlenül MB P nyilvánosságra hozását követően Mi Si (8.14.ábra). B Az így kapott rendszert analízisnek vetettük alá, üzenetváltásainak SPL modellje az 8.15.ábrán látható. Fn Támadást ebben a rendszerben sem ... ... találtunk, így a bevezetett gyengítések nem rontották el az Ariadne biztonsági F2 specifikációit. Ezzel beláttuk, hogy az F1, F2 résztvevők összevonása a rendszer egészének biztonsági F1 jellemzőin nem rontott. Nézzük most meg, milyen hatásokkal A jár n továbbító résztvevő összevonása. Az 8.16. ábrán követhető az egyes t információk nyilvánosságra hozása az 8.16. ábra Ariadne üzenetküldései időben eredeti, illetve az összevont esetben. A legrosszabb esetet véve az összes továbbító résztvevő M1..Mn üzeneteit az M1 üzenet időpillanatába, illetve az összes S1..SN TESLA kulcs felfedését az SN időpillanatába sűrítjük össze. Az rendszer összevonásával M 1 ...M n újabb támadási lehetőség nem adódik, ezáltal a rendszer biztonsági jellemzői A F1 B ... F i ... F n nem romlanak. (8.17.ábra) M1

SF2

M0

SF1

S F1 ... S Fn

Vizsgálatunk során tehát az Ariadne útvonalválasztó protokoll megfelelőnek bizonyult.

8.17. M-ek és S-ek elküldése

37

9. Megoldás biztonságos mobil ad hoc kommunikációra Az előzőekben analízis alá vetett protokollok felhasználásával elkészítettünk egy olyan protokoll modellt, mely használatával a mobil ad hoc hálózatok biztonságos kommunikációja megvalósíthatóvá válik. Megoldásunk az ismeretlen továbbító résztvevők, és a végpontok hitelesítésén túl a kulcsosztási feladatok ellátását is megfelelő biztonsággal látja el. A rendszer biztonságos kommunikációt felépítő végpontjai között hitelesítési célokból előzőleg osztott titokra van szükség, ez az egyetlen, rendszerünkben feltételezett előzetes tudás. Ez az osztott titok létrehozható például autentikált DH kulcs-cserével. A rendszer útvonalkeresése az Ariadne protokoll kiegészített változatával történhet. A kiegészítés egyik része, hogy az útvonalkeresés során SAR specifikációt is mellékelünk. Ezáltal az útvonalat felderítő résztvevőnek lehetősége lesz a hitelesített útvonal-lehetőségek közül egy olyan kiválasztására, mely megfelelő biztonsági paraméterekkel rendelkezik. A kiegészítés másik része, hogy a lehetséges útvonalak résztvevőinek listája mellett a közbülső résztvevők hitelesített nyilvános kulcsait is Ariadne + SAR eljuttatjuk a küldőhöz. (9.1.ábra) F1 F2 A kiválasztott útvonalon az összegyűjtött nyilvános kulcsok segítségével már folytatható B Ariadne + SAR + PKi biztonságos kommunikáció. Láttuk az előző A fejezetben, hogy az Onion routing eljárás 9.1. ábra A kiegészített Ariadne megfelelő biztonsági paramétereket nyújt. De mivel a nyilvános kulcsú titkosítás erőforrásigényes művelet, ezért a publikus kulcsú Onion routing alkalmazása helyett megoldásunk következő lépésében kulcstranszportot alkalmazunk. Az adott nyilvános kulcsok felhasználásával szimmetrikus kulcspárokat hozunk létre. Ezzel a nyilvános kulcsú titkosítást minden továbbító résztvevővel mindössze egyetlen üzenetváltásban használjuk. A kommunikáció további folyamatában a résztvevők az Onion routing szimmetrikus kulcsokat alkalmazó változatát használhatják. Megoldásunkban a visszafelé irányuló kommunikáció biztonságossá tételéhez nem szükséges ismét lefuttatni a teljes protokollt. Ehelyett az összegyűjtött szimmetrikus kulcsok listáját eljuttatjuk a vevőnek, melyekkel az visszafelé irányban is képes lesz biztonságosan üzeneteket küldeni. Ezáltal egy megbízható útvonalválasztást megvalósítható rendszer épül fel.

38

10. Összegzés A dolgozat során megismerkedtünk a mobil ad hoc hálózatok jellemzőivel. Számos olyan veszélyforrást mutattunk be, melyeknek az ilyen infrastuktúra nélküli, elosztott rendszerek ki vannak téve. Láthattuk, hogy a hagyományos hálózatokban kialakult biztonságtechnikai mechanizmusok csak különféle módosítások segítségével alkalmazhatóak mobil ad hoc hálózatokban. A mobil ad hoc hálózatok útvonalválasztási protokolljainak jelentős része nem tartalmaz biztonsági mechanizmusokat, holott az útvonalválasztás folyamatát célozva is számos támadás érheti a rendszert. Bemutattunk olyan protokollokat, melyek a biztonságos útvonalválasztást hivatottak megvalósítani. Munkánk során ezen biztonsági megoldásokat vizsgáltuk részletesebben. Analízisünk eszközeként a konkurens rendszerek leírására szolgáló CSP leírónyelvet használtuk. Az ebben felépített modelljeinket az FDR modell ellenőrző segítségével analizáltuk. Modelljeink elkészítésében a Casper fordító segítségét vettük igénybe. Elkészítettük néhány mobil ad hoc hálózatban alkalmazható protokoll modelljét, melyeket ellenőrzésnek vetettünk alá. Vizsgáltaink során kitértünk a forrás útvonalválasztás, illetve a hitelesített útvonalakon történő biztonságos csomagtovábbítás protokolljaira. Láttuk, hogy a védelem nélküli, illetve egyszerű titkosítással ellátott forrás útvonalválasztás könnyen támadások célpontjává válhat. Modelleztük és leellenőriztük a TESLA protokollt, mely az eredmények szerint a támadási lehetőségeket kizárva valósítja meg a többesküldéses autentikációt. Az Ariadne protokoll az útvonal-felderítés folyamatában a résztvevők, és így az útvonalak hitelesítését jól oldotta meg. Láthattuk, hogy biztonsági protokollok CSP modellezésének segítségével könnyen felderíthetőek az esetleges támadási lehetőségek. E megközelítés egyetlen hátránya, hogy modell ellenőrzőink jelenleg csak véges és viszonylag kis rendszerek analízisével képes megbírkózni. Megfelelően leegyszerűsített modellek esetén ez is nagy segítséget jelent. Ezen eredmények alapján összeállítottunk egy protokoll-modellt, mely segítségével megvalósítható a mobil ad hoc hálózatok biztonságos kommunikációja. Hitelesített és titkos adattovábbítás válik lehetővé előzőleg ismeretlen résztvevők továbbításával. Ezen protokoll modell további analízise vizsgálatunk tárgyát képezi.

39

11. Referenciák [Perkins] Charles E. Perkins: Ad-hoc Networking, 2001 [Seciss] Kata Molnár, László Zömbik: Security Issues in Mobile Ad hoc Networks. Evolution in the military communications systems – trends and challenges in the XXI. century, 2001. [Lowe] Peter Ryan, Steve Schneider, Michael Goldsmith, Gavin Lowe, Bill Roscoe: Modelling and analysis of security protocols, 2001 [Haas] Lidong Zhou, Zygmunt J. Haas: Securing Ad Hoc Networks. IEEE Network Magazine, vol. 13, no.6, November/December 1999 [Questfor] Jean-Pierre Hubaux, Levente Buttyán, Srdan Capkun: The Quest for Security in Mobile Ad Hoc Networks. ACM Symposium on Mobile Ad Hoc Networking and Computing, MobiHOC, 2001 [IDbased] Ueli M. Mauer, Yacov Yacobi: A Non-interactive Public-Key Distribution System. Designs, Codes and Cryptography, 1996 [Applied] Bruce Schneier: Applied Cryptography: Protocols, algorithms and Source Code in C, 2nd. Edition, 1995 [Keyest] Maarit Hietalahti: Key Establishment in Ad-hoc Networks. Proceedings of the Helsinki University of Technology, Seminar on Network Security, fall 2000 [Gkmp] H. Harney, C. Muckenhirn: Group Key Management Protocol (GKMP) Architecture. RFC2094. Group Key Management Protocol (GKMP) Specification. RFC2093 [Tesla] Adrian Perrig, Ran Canetti, Dawn Song, J.D.Tygar: Efficient and Secure Source Authentication for Multicast. Proceedings of Network and Distributed System Security Symposium, 2001 [Introute] Földesi András, Homolya György, Horváth Cz. János, Dr. Imre Sándor: Bevezetés a mobil ad hoc útvonalválasztó protokollok világába. Híradástechnika, 2001. május [Dsrdraft] David B. Johnson, David A. Maltz, Yih-Chun Hu, Jorjeta G. Jetcheva: The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR). Draft-ietf-manetdsr-07.txt, February 2002. [Aodvdraft] Charles E. Perkins, Elizabeth M. Belding-Royer, Samir R. Das: Ad hoc OnDemand Distance Vector (AODV) Routing. Draft-ietf-manet-aodv-10.txt, January 2002. [Zrpdraft]Zygmunt J. Haas, Marc R. Pearlman, Prince Samar: The Zone Routing Protocoll (ZRP) for Ad Hoc Networks draft-ietf-manet-zone-zrp-04.txt, 2002 July [Onion] M.Reeds, P.Syversion, D.Goldschlag: Anonymous Connections and Onion Routing. IEEE Journal on Selected Areas in Communications, vol.16 no 4., May 1998 [Secaware] Seung Yi, Prasad Naldurg, Robin Kravets: Security-Aware Ad-Hoc Routing for Wireless Networks. Technical Report UIUCDCS-R-2001-2241(ps/pdf), August 2001 [Ariadne] Yih-Chun Hu, Adrian Perrig, David B. Johnson: Ariadne: A Secure On-Demand Routing Protocol for Ad Hoc Networks, Mobicom 2002 [Mitigating] Sergio Marti, T.J. Giuli, Kevin Lai, Mary Baker: Mitigating Routing Misbehavior in Mobile Ad Hoc Networks. Proceedings of MOBICOM, 2000 [Grudges] Sonja Buchegger, Jean-Yves Le Boudec: Nodes Bearing Grudges: Towards Routing Security, Fairness, and Robustness in Mobile Ad Hoc Networks. Proceedings of the Tenth Euromicro Workshop on Parallel, January, 2002 [Schneider] Steve Schneider: Concurrent and Real-time Systems. The CSP Approach. 2000 [Casper] Gavin Lowe, Philippa Broadfoot, Mei Lin Hui: A Compiler for the Analysis of Security Protocols. User Manual and Tutorial Verison 1.5, December 3., 2001 [Capsl] G. Denker, J. Millen: CAPSL Intermediate Language, 1999 [Worksess] Levente Buttyán, Jean-Pierre Hubaux: Report on a Working Session on Security in Wireless Ad Hoc Networks. 2002

40