Informatika | Informatikai biztonság » Kocsis Sándor - Hitelesítés az internetes kommunikációban

Eötvös Loránd Tudományegyetem Informatikai Kar Barát vagy ellenség? Hitelesítés az internetes kommunikációban Kocsis Sándor Témavezető: Kincses Zoltán Budapest, 2004. május 21 2 Tartalomjegyzék Tartalomjegyzék .2 1. Bevezető 5 1.1 Azonosítás és bizalom a köznapi életben 5 1.2 Új csatornák, új feladatok 5 2.1 Titkosítási módszerek 7 2.2 Kezdeti titkosítási módszerek8 2.21 Helyettesítő kódolók 8 2.22 Keverő kódolók 8 2.23 Egyszer használatos bitminta 8 2.3 Titkos kulcsú algoritmusok 9 2.31 A DES 10 2.32 Az IDEA 10 2.33 A titkos kulcsú módszerek korlátai 11 2.4 Nyilvános kulcsú algoritmusok 12 2.41 Az RSA algoritmus 13 2.42 Más nyilvános kulcsú eljárások 14 2.5 Hash függvények 14 2.51 Az MD5 üzenetpecsét 15 2.52 Az SHA üzenetpecsét 15 2.6 A titkosítási technikák felhasználási köre 15 2.7 A digitális aláírás 16 3.1 A közbeékelődéses támadás 18 3.2 Hitelesítés digitális tanúsítványokkal 18 3.3

Tanúsítványformátumok19 3.31 Az X509 tanúsítványformátum 19 3.32 A PGP tanúsítványformátum 20 3.33 Különbségek a tanúsítványok között 21 3.34 Bizalmi modellek 22 3.4 Nyilvános kulcsú infrastruktúrák 23 3.41 Fő funkcionális egységek 23 3.42 Irányelvek és integráció a meglévő rendszerekkel 24 3.43 A PKI-t ért kritikák 25 4.1 Kulcskezelés 27 4.11 A kulcscserélő protokollok tulajdonságai 27 4.12 A Diffie – Hellman nyilvános kulcscserélő algoritmus 28 4.2 Hitelesített kulcscserélő algoritmusok az IP rétegen 28 4.21 A SKIP protokoll 28 4.22 A PHOTURIS protokoll 29 4.23 A SKEME protokoll 30 4.24 Az Oakley protokoll31 4.3 Az IPSec protokoll31 4.31 Kapcsolat-alapú kapcsolat nélküli protokoll 32 4.32 Az IPSec csomagok szerkezete 32 4.33 Az IKE protokoll 33 4.331 Módok és fázisok 34 4.332 Az 1 fázis: fő mód és agresszív mód 34 4.333 A 2 fázis: gyors mód 35 4.34 Az IPSec értékelése 35 4.4 Ad hoc hálózatok 36 3 4.41 Az ARAN

protokoll36 4.411 Az ARAN első fázisa 36 4.412 Az ARAN második fázisa 37 4.413 Kulcsvisszavonás az ARAN-ban 38 4.42 A hálózati topológia elrejtése: Az NDM-módszer 38 4.43 Az SRP protokoll39 5.1 Az SSL protokoll 40 5.11 Az SSL kézfogási protokoll 41 5.12 A szerver hitelesítése 42 5.13 A kliens hitelesítése 43 5.14 Az SSL protokoll értékelése 44 5.2 A PCT protokoll 45 5.21 Hasonló vonások 45 5.22 Lényegi különbségek 45 5.3 A TLS protokoll 46 5.4 A WTLS protokoll 47 5.41 A WTLS architektúra 47 5.42 A kézfogási protokoll 47 5.43 A titkosító specifikációkat megváltoztató protokoll 48 5.44 Kriptográfiai módszerek a WTLS-ben 48 5.441 Hitelesítés 48 5.442 Kulcscsere 49 5.45 Biztonsági problémák49 5.5 A DTLS protokoll 49 5.51 Problémák és megoldások 49 6.1 Elektronikus levelezés és dokumentumcsere 51 6.11 A PEM protokoll 51 6.111 A küldő hiteles azonosítása 52 6.112 Az üzenetek titkosítása 52 6.113 Üzenet típusok 52 6.114 PEM üzenetek

létrehozása – a szöveg átalakítása 52 6.115 PEM üzenetek létrehozása – a fejrész kialakítása 53 6.116 A PEM értékelése 53 6.12 Az S/MIME protokoll53 6.13 A PGP protokoll 54 6.131 A PGP története54 6.132 PGP üzenetek létrehozása 55 6.133 A PGP üzenetek szerkezete 55 6.134 A PGP üzenetek elolvasása 56 6.14 Az elektronikus aláírás és jogi vonatkozásai 56 6.141 Az elektronikus aláírásról szóló törvény háttere56 6.142 Elektronikus aláírás a törvény szellemében 57 6.143 Az elektronikus aláírás alkalmazásának szereplői 58 6.144 Minősítés és felügyeleti szervek 58 6.145 Hazai hitelesítés-szolgáltatók 59 6.2 Elektronikus kereskedelem 59 6.21 A SET protokoll 60 6.211 A SET modellje 60 6.212 Kettős aláírások 61 6.213 A SET tanúsítványok 61 6.22 A Payword protokoll 62 6.221 A protokoll megvalósítása 62 4 6.222 A rendszer biztonsági szolgáltatásai 63 6.3 SSO-rendszerek és távoli rendszermenedzselés 63 6.31 A Kerberos

rendszer 64 6.311 A Kerberos alapvető működési modellje64 6.312 TGS és TGT 65 6.313 A Kerberos 5 modellje 65 6.314 A Kerberos hiányosságai 67 6.32 Az SSH protokoll 67 6.321 Az SSH részprotokolljai 68 6.322 A szállítási protokoll68 6.323 A hitelesítési protokoll 69 6.324 Titkosítás és integritásvizsgálat 69 6.325 Ügynökök és ügynöktovábbítás (agent-forwarding) 69 6.4 Hitelesítést alkalmazó protokollok a Világhálón 70 6.41 Az S-HTTP protokoll 70 6.411 Alkalmazott kriptográfiai módszerek 70 6.412 Üzenetformátum 71 6.413 Előnyök és hátrányok 71 6.42 A Surf’n’Sign protokoll 71 6.421 A Surf’n’Sign architektúrája 72 6.422 Megjegyzések a protokollhoz 72 Fogalomtár .76 A felhasznált irodalom és hivatkozások jegyzéke .80 Ajánlott irodalom és honlapok .82 5 1. Bevezető Személyi igazolvány, útlevél, vezetői engedély, bankkártya, adókártya, TBkártya, diákigazolvány – hosszan sorolhatnánk azokat az igazolványokat,

igazolásokat és egyéb bizonylatokat, amelyek közül többel is (általában az összessel) mindannyian rendelkezünk, és az irattárcánkban, a kézitáskánkban vagy a farzsebünkben magunknál hordjuk, esetleg féltve őrizzük a ruhásfiók mélyén. Csak az tudja igazán, hogy mennyire nehéz a hétköznapi ügyek intézése az előbbi dokumentumok nélkül, aki már egyszer elvesztette azokat, vagy más okból volt kénytelen megválni tőlük. Továbbá csak ők tudják, hogy mennyire nehéz pótolni ezen okmányokat, hiszen az őket kiállító hatóságok mindent megtesznek azért, hogy ezek minden kétséget kizáróan a valóságnak megfelelő információt hordozzanak rólunk. Nélkülük sajnos – vagy szerencsére – nem élhetünk „normális” életet. 1.1 Azonosítás és bizalom a köznapi életben A fenti dokumentumok elsődleges célja mindazonáltal ugyanaz: egy hatóság igazolásának felmutatásával bizonyíthatjuk, hogy helyesek azok az információk,

amiket állítunk magunkkal kapcsolatban (például valóban azok vagyunk, akinek mondjuk magunkat). Helyesebben – és ennek a megkülönböztetésnek fontos szerepe lesz a későbbiekben – ezek a papírok azt igazolják, hogy a dokumentum kiállításának idején a velünk kapcsolatban fellelhető információk alapján valóban azok voltunk, akinek állítottuk magunkat, és ezt akkor semmi nem látszott cáfolni. Viszont ezek az igazolások csak abban az esetben érhetik el a céljukat, ha akarva-akaratlanul is, de elfogadjuk, hogy a hatóság értesülései helyesek és pontosak, vagyis ha megbízunk az igazolások által hordozott információban, valamint az azt kiállító hatóságban. A hétköznapi élet számos területén, számos viszonylatban azonban nincs szükség hatósági igazolásokra annak alátámasztására, hogy valóban azok vagyunk, akik, és olyan jogosítványokkal rendelkezünk, amilyenekkel. Sokszor elég az, ha van valaki, aki azt állítja, hogy mi

igazat állítunk magukról. Ily módon „bizalmi hálók” épülhetnek fel, erre számos példát láthat mindenki a saját életében. Ez a megközelítés sokkal nagyobb és erőteljesebb döntési szabadságot ad, mint az előző, valamelyest „centralizált” megközelítés, hiszen itt nem muszáj megbíznunk egy szervezetben vagy hivatalban, hanem a mi belátásunkra van bízva, hogy eldöntsük, hogy valóban elhisszük-e azt, ami állítanak, természetesen vállalva az összes kockázatát és következményét is annak, hogy esetleg rosszul döntöttünk. Ezzel szemben áll a centralizált megközelítés viszonylagos (jogilag is alátámasztott) biztonsága és az általa nyújtott garanciák. 1.2 Új csatornák, új feladatok Közhelyként hat, de az Internet minden kétséget kizáróan egyre nagyobb szerepet játszik a mindennapi életben, és a hagyományos csatornákon keresztül végzett tevékenységeink közül sok áthelyeződött a digitális csatornákra;

ugyanakkor nem szabad elfelejtenünk, hogy az Internet egy speciális közeg, és ezzel együtt nemcsak a hagyományos feladatokat kell átfogalmaznunk, hanem új feladatok bevezetésére is lehetőség nyílik, illetve más jellegű feladatok megoldása válhat szükségessé. Egyszerű példa erre, hogy a biztonságos kommunikáció érdekében nemcsak természetes személyeket, intézményeket és cégeket hitelesíthetünk, de akár IP címeket vagy elektronikus dokumentumokat is. Továbbá választhatunk a nem biztonságos területen küldött adatok egyszerű titkosítása, hitelesítése, illetve a kettő kombinációja között, figyelembe véve persze az ezzel járó költségtényezőket is, mint amilyenek például az idő- és számításigény-jellegű költségek. Megoszlanak a vélemények azzal kapcsolatban is, hogy ezeket a feladatokat a TCP/IP hivatkozási modell mely rétegén lehet, illetve célszerű meg- 6 oldani. Ráadásul – és ez adja az igazi

informatikai/biztonsági nehézségek zömét – ezek a szempontok, illetve a fent említett bizalom minősége és mértéke kölcsönösen függenek egymástól, tehát a „valamit valamiért” elv alapján fontos célkitűzés még a skálázhatóság, külön-külön az előző szempontok mindegyike, és így a rendszer teljes egésze esetében is. Az új csatornával és az új feladatokkal együtt azonban a tevékenységeink hétköznapi értelemben vett körülményeit és vonzatait (például a jogi és gazdasági felelősséget is) át kell ültetnünk erre az elektronikus médiumra. A gazdasági és az államigazgatási szektor (természetesen sok egyéb szektor mellett) korán felismerte az ebben rejlő potenciált, így számos ügyünket intézhetjük már most is, de a jövőben még inkább, az Interneten keresztül. Mivel csak a közvetítő közeg változott, az alapvető irányelvek és szabályozások nem, az ügyintézés törvényi háttere és egyéb

intézményi szabályozásai (legalábbis a célkitűzések és ajánlások) viszonylag gyorsan elkészültek vagy előkészítés alatt állnak, de már egységesnek és kiforrottnak látszanak. A tapasztalat viszont azt mutatja, hogy az oly sokszor és sok helyütt magasztalt villámgyors informatikai fejlődés még nem tudott teljes körűen megfelelni az új elvárásoknak, amennyiben jelenleg még nem létezik egy egységes, átfogó, és minden problémára választ nyújtó informatikai megoldás a hitelesítéssel kapcsolatban. Léteznek azonban részmegoldások, amelyek még vizsgálódás tárgyát képezik; szinte minden nagyobb IT cég és szabványosítással foglalkozó szervezet megjelentette a saját megoldását (általában egy részterületre), ugyanakkor jelen van a fent említett két megközelítés, a centralizált és a decentralizált bizalomra építő megközelítés közötti, nem teljesen elvi síkú ellentét is A jelen dolgozat egyik célkitűzése az,

hogy a jelenleg elérhető megoldások, megvalósítások és ajánlások közül a lényegesebbeket és a legjobban kidolgozottakat bemutassa, továbbá megvilágítson néhány az adott megoldással kapcsolatos megoldatlan problémát és ellenérvet is. A szakirodalomban még a magyar nyelvterületen is gyakran keveredik az azonosságvizsgálat/azonosítás és a hitelességvizsgálat/hitelesítés fogalma (az angolszász szakirodalomban az „authentication” kifejezés használata terjedt el, ami alatt jellemzően az említettek mindegyikét értik, bár néhol találkozni lehet a „certification” kifejezéssel is, amit a hitelesítési mechanizmusok megjelölésére használnak), ezért a jelen dolgozat egy további célkitűzése az is, hogy rávilágítson a fenti kifejezések és fogalmak közötti különbségekre. Mivel a továbbiakban az olyan esetekkel kívánunk foglalkozni, amikor a cél a szereplők hitelt érdemlő módon való azonosítása, az „azonosítás”

kifejezés alatt mindig egy valamilyen (a későbbiekben részletesen bemutatásra kerülő) hitelesítési módszerrel támogatott azonosságvizsgálatot értünk, amit esetenként a „hiteles azonosítás” kifejezéssel fogunk hangsúlyozni. A téma iránt érdeklődő szakemberek és laikusok meglehetősen nehéz feladatra vállalkoznak, ha a szakirodalomban próbálnak kutakodni például egy adott (hitelesítéssel kapcsolatos, vagy ilyen módszerekkel megoldható) probléma megoldási lehetőségei után. Jellemzően két típusú információforrás áll rendelkezésre: Az egyik típus néhány mondatban, nagy általánosságban „mutatja be” az adott protokollt vagy módszert (tehát lényegileg semmit nem mond a nyújtott szolgáltatásokról, magáról a módszerről, illetőleg a megkövetelt előfeltételekről), míg a másik típusú forrás nem ritkán több tíz vagy száz oldalas, a végletekig részletes specifikáció (tehát kimondottan az azt implementáló

szakemberek illetve a kutatók számára készült dokumentum). Ráadásul ezek a munkák meglehetősen nehezen olvashatóak, általában csak egy vagy nagyon kevés megoldást mutatnak be, és ezekben is jellemzően a „népszerű” protokollokat és módszereket ismertetik (nemritkán igen komoly gazdasági és üzleti megfontolások is érezhetőek rajtuk), pedig a témakör igen sokrétű és változatos, néhol igen szellemes megoldásokat is felvonultat. A jelen dolgozat harmadik célkitűzése ezért az előbb említett két típus közötti átmenetet képviselő bemutatás megvalósítása, és a megoldási lehetőségek lehető legszélesebb körű (de természetesen a jelen dolgozat keretei által szabott korlátokon belüli) ismertetése. 7 2. A hitelesítés kriptográfiai háttere Az internetes kommunikáció speciális kommunikáció: egy általánosan elfogadott analógia szerint olyan, mintha anonim személyként küldenénk egy anonim személy számára egy

olyan képeslapot, amit nemcsak bárki elolvashat, hanem akár módosíthat is. Természetesen egyikünk sem szeretné, hogy bizalmas leveleinket vagy banki tranzakciónkat bárki is olvasgassa, módosítsa, visszamenőleg meghamisítsa, vagy esetleg a nevünkben fellépve okozzon nekünk kárt (és persze önmagának hasznot). Egy ideig az volt az általánosan elfogadott nézet, hogy a fenti problémák kiküszöbölhetők azzal, ha egyszerűen csak alkalmas módon titkosítjuk az adatainkat, amelyet aztán a címzett valamilyen módon képes lesz visszafejteni. Egyre bonyolultabb titkosítási módszerek és algoritmusok születtek, amelyek aztán más területeken (többek között a hitelesítések területén) is alkalmazható eredményekre vezettek, mindamellett rádöbbentették a kutatókat, hogy a titkosítás önmagában általában nem elegendő, bár szükséges feltétele az informatikai biztonságnak. A továbbiakban először a jelenleg alkalmazott alapvető

titkosítási módszerek közül mutatunk be néhányat, egyrészt azért, mert történetileg ezek jelentek meg korábban, másrészt pedig a későbbi hivatkozások és az egyöntetű értelmezés végett szükségszerű ezek bemutatása, definiálása. A jelen fejezet elkészítésekor az [1] művet használtuk fel, a téma iránt érdeklődők (többek között) ott, illetve az ajánlott irodalom között felsorolt művekben találhatnak további információkat és részleteket. 2.1 Titkosítási módszerek A titkosítási módszerek alapvető célja, hogy egy P nyílt szövegből (vagyis a titkosítandó szövegből) egy C titkosított szöveget állítsunk elő valamilyen EK titkosító eljárás alkalmazásával. A P szöveg lehet egy hagyományos, karakterekből álló szöveg, de lehet egy általános bitsorozat is. Az EK eljárás viszont tulajdonképpen egy matematikai transzformáció vagy függvény (Indokolt a függvény kifejezés használata, hiszen nem sok értelme

van olyan titkosító alkalmazást készíteni, amely olyan titkosított szöveget készít, ami akár több nyílt szövegnek is lehet a kódolt párja; ekkor nem lehetne egyértelműen visszaállítani az eredeti szöveget a kódolt szövegből, bár vannak esetek, amint azt látni fogjuk, amikor erre nincs is szükség.) Ha formálisan akarjuk megfogalmazni, C = EK(P) Az E eljárás egy kétparaméteres eljárás; ennek egyik paramétere maga P, míg a másik paramétere egy K kulcs. A kulcs a mi esetünkben nem más, mint egy bitsorozat (ami az eljárástól függően reprezentálhat egy egyszerű természetes számot), és azért van rá szükségünk, mert egyrészt így a kulcs megváltoztatásával tulajdonképpen egy új kódoló eljárást kapunk, másrészt viszont a kulcs ismerete nélkül az esetleges támadó még a teljes titkosított szöveg ismeretében sem képes a titkosított üzenet megfejtésére (legalábbis nem elég gyorsan). A kulcs ismeretében a fogadó egy

DK paraméteres eljárás segítségével fejtheti vissza a titkosított üzenetből az eredeti szöveget, azaz P = DK(C). Az előzőekből nyilvánvaló, hogy DK(EK(P)) = P A kódoláselmélet természetesen a leírtaknál sokkal pontosabb definíciókkal szolgál, viszont a jelen dolgozat tárgyához elegendő a fenti, nem teljesen precíz megfogalmazás is. A téma iránt érdeklődők pontosabb ismereteket szerezhetnek például a [2] műből A kulcs meghatározó fontossággal bír az algoritmusok alkalmazhatósága szempontjából: mivel az algoritmusok tesztelése végett maguk az algoritmusok mindig nyilvánosak (sőt, a biztonságos kommunikáció során használt módszerek némelyike kimondottan megköveteli, hogy az alkalmazott algoritmus nyilvános legyen), ezért a támadónak valóban „csak” a kulcsra van szüksége, hogy megszerezze az eredeti üzenetet. Minél nagyobb (hosszabb) a kulcs, annál nehezebbé válik a megtalálása, mivel a kulcstér (a kulcs által

felvehető értékek száma) elképesztően naggyá válhat egy elég nagy kulcs esetén, és ebben a térben nagyon nehéz lehet egyetlen meghatározott kulcs megtalálása például oly módon, hogy az összes lehetséges kulcsot végigpróbáljuk. A 8 későbbiekben látni fogjuk, hogy a titkosítás erőssége nem csak az alkalmazott kulcs méretétől, hanem az algoritmustól is erősen függ. 2.2 Kezdeti titkosítási módszerek A kódolás, ha nem is egyidős az emberiséggel, de mindenesetre a számítógép megjelenését évszázadokkal megelőző tudományág. A dolgozat további részében időrendi sorrendben mutatunk be a megoldások közül néhányat, az egyszerűbbektől a bonyolultabbak felé haladva. Ebben a pontban a legkorábbi, és egyben a legegyszerűbb módszerekkel foglalkozunk 2.21 Helyettesítő kódolók Bizonyára mindenki hallott már a Julius Caesarról elnevezett Caesartitkosítókról; ezek voltak a legelső titkosítási eljárások. A módszer

lényege, hogy a P szövegben előforduló minden betűt vagy betűcsoportot egy előre meghatározott módon egy másik betűre vagy betűcsoportra cserélünk, például oly módon, hogy minden betűnek a lexikografikus sorrendben vett valamilyen mértékű eltolásával kapott betűt feleltetünk meg. Ekkor az eltolás mértéke lehet a K kulcs Picit bonyolultabb az a módszer, amikor az egyes betűknek megfeleltetett betű-párt egy táblázatban adjuk meg, de a párok tagjainak távolsága a rendezésben nem rögzített. Ezt a módszert szokás még egybetű-helyettesítéses titkosításnak is nevezni Bár a módszer viszonylag nagy keresési teret eredményez (az angol ábécé betűit használva 26! ≈ 4 × 1026 lehetséges kulcs adódik), a gyakorlatban mégsem igazán jól alkalmazható, mégpedig a természetes nyelvek statisztikai jellemzői miatt. Tudjuk ugyanis, hogy minden nyelvben bizonyos betűk, betűpárok és betűhármasok gyakrabban fordulnak elő, mint mások,

és ez alapján a kódfejtő a titkosított szövegből vett minta statisztikai jellegű elemzésével és egyszerű logikai következtetésekkel sokkal gyorsabban találhatja meg a betűk egymáshoz rendelésének táblázatát. 2.22 Keverő kódolók A helyettesítő kódolókkal ellentétben, amelyek csak más alakkal ruházzák fel az eredeti karaktereket, de a sorrendjüket megtartják, a keverő kódolók csak a sorrendet változtatják meg, az alakot nem. Kulcsként egy olyan szöveget használunk, amely nem tartalmaz ismétlődő karaktereket. Az eredeti P szöveget sorfolytonosan beírjuk egy olyan táblázatba, amelyet a kód betűivel indexelünk, majd a C titkosított szöveget úgy kapjuk meg, hogy a beírt karaktereket oszlopfolytonosan olvassuk ki a táblázatból, mégpedig a kulcsként használt szöveg karaktereinek lexikografikus sorrendjében. A kódtörőnek viszonylag nehéz dolga van: először is fel kell ismernie, hogy egy ilyen típusú kóddal áll szemben

– erre gyakoriságelemzéssel rájöhet. Ezután meg kell határoznia az oszlopok számát, amihez meg kell „sejtenie” egy a szövegben valószínűleg előforduló szót, és a szöveg két vagy három szabadon választott betűjéből alkotott betűkettősöket vagy -hármasokat kell keresnie, végül szintén a természetes nyelvek statisztikai jellemzői alapján meghatározhatja az oszlopok sorrendjét is. 2.23 Egyszer használatos bitminta Ez a módszer elvileg is feltörhetetlen kódot eredményez, bár a gyakorlatban alkalmazhatatlan. Kulcsnak egy elég hosszú bitsorozatot választunk, és a P kódolandó szöveget is egy hosszú bitsorozatnak tekintjük. A kódolt üzenetet egyszerűen azáltal 9 kapjuk meg, hogy bitenként „kizáró vagy” (XOR) műveletet végzünk el. A C titkosított üzenet azért feltörhetetlen, mert bármelyik adott hosszúságú szöveg ugyanolyan esélylyel lehet az eredeti P szöveg, ráadásul a C kódolt üzenet semmiféle

kiegészítő információt sem nyújt a kódtörő számára, hiszen egy elég hosszú szövegben az egyes betű nesek előfordulási valószínűsége ugyanakkora lesz. A módszer attól lesz a gyakorlatban használhatatlan, hogy a kulcs megjegyezhetetlen (ha elég hosszú), tehát valahol tárolni kell, ami biztonsági szempontból potenciális veszélyt jelent. Ezen kívül ha a kommunikáció során akár egyetlen bit is elveszik vagy megsérül, az üzenet hátralevő része értelmetlen lesz a visszafejtést követően. 2.3 Titkos kulcsú algoritmusok A kezdeti kódolók esetén az algoritmusok viszonylag egyszerűek voltak, a biztonság megvalósítását a kulcsok hosszúságában keresték; minél hosszabb volt a kulcs, annál erősebb lehetett a titkosítás. Az újabb kódolók pont fordított elképzelés mentén haladnak: ugyanúgy helyettesítést és keverést használnak, mint elődeik, azonban a cél olyan bonyolultságú algoritmusok létrehozása, amelyet a

kódtörő még nagy mennyiségű kódolt üzenet ismeretében sem ismerhetnek ki, vagyis a biztonság megvalósítása inkább az algoritmus feladata lesz, mint a kulcsé, legyen az bármilyen hosszú. Természetesen ettől még igaz marad, hogy a kulcs hosszának növelésével nő a titkosítás erőssége is. A keverést úgynevezett P-dobozokkal (permutációs dobozokkal) valósítják meg, amelyek már csak a logikai felépítésük folytán is kifejezetten alkalmasak a fizikai, „huzalozott” megvalósításra, ami jelentősen lerövidíti a kódolásra fordított időt. Az 1 ábrán bemutatott P-dobozok rögzített számú bemeneti vonalon érkező adatokat rögzített (általában a bemeneti vonalak számával megegyező) számú kimenetre továbbítják oly módon, hogy egy adott sorszámú bemeneti vonalon érkező adatot egy különböző sorszámú kimeneti vonalra teszik. A másik fő logikai összetevőt, a helyettesítést S-dobozokkal valósítják meg, amely 3

fokozatból áll (ezt szintén az 1. ábrán mutatjuk) Az első fokozat az m1 számú bemeneti vonala közül valamelyiken érkező adatot egy, az n számú kimeneti vonala közül kiválasztott vonalra teszi (általában m1 < n), vagyis ezen a vonalon 1-et állít be, míg a többin 0-t. A második fokozatban egy P-doboz található, amely az n számú bemeneti vonalának keverését végzi el, ugyancsak n számú kimeneti vonalra A harmadik fokozatban pedig (az első fokozat ellenpárjaként) az n számú bemeneti vonal valamelyikén érkező adatot egy m2 számú kimeneti vonal közül kiválasztott vonalra teszi Kódoló 8-ról 3-ra S-doboz Dekódoló 3-ról 8-ra P-doboz 1. ábra: P-doboz és S-doboz (Forrás: [1]) Önmagukban a fenti dobozok nem lennének kriptográfiailag erősek; azonban a dobozok alkalmas egymás utáni, és elegendően sok fokozatot alkalmazó összekapcsolásával rendkívül erős, úgynevezett szorzat típusú kódolót konstruálhatunk. 2.31 A DES

10 A DES (Data Encryption Standard) az IBM által kifejlesztett, és az amerikai kormányzat által 1977-ben szabványként elfogadott szorzat típusú kódoló. A DES az úgynevezett blokk-kódolók családjába tartozik, vagyis a tetszőleges hosszúságú P szöveget meghatározott hosszúságú (a DES esetében 64 bites) blokkonként kódolja, és szintén 64 bites titkosított üzeneteket eredményez. Az algoritmus 19 fokozatból épül fel, és egy 56 bites kulcs a paramétere. (Itt fontos megjegyeznünk, hogy az algoritmus végrehajtásával kapott C titkosított üzenetet ugyanezzel a kulccsal fejthetjük vissza, vagyis a módszer szimmetrikus a kulcsra nézve.) Az első fokozat egy kulcsfüggetlen keverés a bemeneti 64 biten, az utolsó fokozat pedig az ennek megfelelő inverz keverést végzi. Az utolsó előtti fokozatban az alsó 32 bitet felcseréljük a felső 32 bittel A közbeeső 16 lépésben a kulcs különböző függvényekkel vett értékét használjuk

paraméterként. Mind a 16 közbülső művelet hasonló műveleteket végez; az i-ik fokozatban két 32-bites bemenetből (Li-1 és Ri-1) szintén két 32-bites kimenetet (Li és Ri) hoz létre. A baloldali kimenet a jobboldali bemenet másolata, vagyis Li = Ri-1. A jobboldali kimenetet a baloldali bemenetet, a jobboldali bemenetet, valamint a fokozathoz tartozó Ki kulcsértéket felhasználó függvény alkalmazásával kapjuk meg (Ri = Li-1 XOR f(Ri-1 , Ki)). A függvény négy, egymás után végrehajtott lépésből áll. Az első lépésben egy 48 bites E számot képezünk Ri-1 kiterjesztésével, amit egy rögzített keverés és másolás segítségével kapunk meg. A második lépésben elvégezzük az E XOR Ki műveletet, majd a harmadik lépésben az így kapott eredményt 8 darab 6 bites csoportra osztjuk, amiket különböző S-dobozokba táplálunk be. Az egyes S-dobozok 4 bites kimenetet adnak, és az így kapott 8 × 4 bitet a negyedik lépésben egy P-dobozon

engedjük keresztül. A 16 iterációs lépés mindegyikében különböző Ki kulcsokat használunk. A kezdeti 56 bites keverés végrehajtását követően minden lépésben a kulcsot két 28 bites partícióra osztjuk, mindegyiket az iteráció sorszámának megfelelő számú bittel balra forgatva. Ezekből a szegmensekből Ki-t egy újabb 56 bites keveréssel kapjuk, ezen kívül pedig az 56 bites kulcs egy 48 bites részét minden fokozatban még külön permutáljuk A fenti algoritmus bonyolultsága ellenére a DES nem más, mint egy egybetűhelyettesítéses kódoló, ahol a betűméret 64 bit. Ugyanabból a 64 bites bemeneti blokkból mindig ugyanazt a 64 bites kimeneti blokkot adja. Ezért a DES-t ebben az eredeti formájában mára már csak nagyon ritkán használják; ehelyett a DES láncolásos verziója használatos, amelynél a nyílt szöveg blokkja és az előzőleg kódolt blokk közötti XOR művelet végrehajtásával „rontjuk el” az egybetű-helyettesítési

tulajdonságot, persze ennek is létezik többféle és bonyolultabb megvalósítása. (A hely rövidsége miatt ennek részletes bemutatásától eltekintünk.) Mégis a DES variánsok közül napjainkban talán a 3DES vagy Triple-DES a legelterjedtebb, ahol a kódolandó szövegen egymás után háromszor hajtjuk végre a DES algoritmust, ezt például a [3] mű mutatja be. 2.32 Az IDEA Az IDEA (International Data Encryption Algorithm – nemzetközi adatkódoló algoritmus) a DES utáni blokk-kódolók egyik legjelentősebb és legkiterjedtebben alkalmazott képviselője. Két svájci kutató dolgozta ki, és 128 bites kulcsot használ, ami elég jelentős védelmet biztosít a faltörő típusú támadásokkal szemben. Működése szempontjából hasonlít a DES-re abban, hogy a nyílt szöveget ez is 64 bites blokkonként dolgozza fel egy paraméteres iteráció segítségével, és a kimeneti kódolt blokkok is 64 bitesek. Nyolc fokozat elegendő a keveréshez, mivel minden

iterációs lépésben minden kimeneti bit minden bemeneti bittől függ Egyetlen iterációs lépésen belül háromfajta, 16 bites számokon végzett műveletet használunk, ezek a „kizáró vagy” művelet, a modulo 216 összeadás, valamint a 11 modulo 216 + 1 alapú szorzás; ezek mindegyike könnyen megvalósítható egy 16 bites mikroszámítógépen. A 128 bites kulcs alapján 52 darab 16 bites alkulcsot generálunk, minden iterációs lépés számára hatot, és a végső transzformációhoz négyet. A dekódolás ugyanazt az algoritmust használja, mint a kódolás, csak az alkulcsok lesznek mások A DES-hez hasonlóan az IDEA-nak is léteznek bonyolultabb, például láncolt változatai, amelyekkel ehelyütt szintén nem foglalkozunk 2.33 A titkos kulcsú módszerek korlátai Az előzőekben a két legelterjedtebben használt (mérföldkőnek számító, bár mára elavultnak tekintett) titkos kulcsú algoritmus működését vázoltuk. (Itt megjegyezzük, hogy a

dolgozat hátralevő részében a „titkos kulcs” kifejezés alatt mindig egy szimmetrikus kulcsot értünk, míg a későbbiekben bemutatásra kerülő nyilvános kulcsú módszerek által használt kulcsokra „nyilvános kulcsként” és „magánkulcsként” fogunk hivatkozni.) Ezek az algoritmusok néha valóban bonyolultak, és ennek megfelelően (elég nagy kulcs használata esetén) valódi informatikai biztonságot képviselhetnek További előnyük a szimmetria (ezért szokás ezeket szimmetrikus módszereknek is nevezni), azaz a kódoláshoz felhasznált kulcs azonos a dekódoló kulccsal, vagy legalábbis az egyik előállítható a másikból viszonylag egyszerű transzformációk alkalmazásával. Mielőtt továbbmennénk, célszerű néhány szót ejtenünk a DES (és általában a szimmetrikus kulcsú titkosítók) által nyújtott biztonság „erejéről”. Említettük, hogy a DES 56 bites kulcsokat használ alapértelmezésben (bár más kulcshosszok is

megengedettek). A kriptográfiával foglalkozó szakemberek már régóta sejtették, hogy ez a kulcshosszúság nem sokáig lesz képes elfogadható szintű biztonság nyújtására, már csak a Moore-törvény (a számítógépek feldolgozási teljesítménye 18 havonta megduplázódik) értelmében sem. Már 1995-ben egy Damien Doligez nevű francia hallgatónak sikerült egy (igaz, csak 40 bites) szimmetrikus kulcs feltörése 8 nap alatt, 120 hálózatba kötött UNIX gép felhasználásával [13]. 1996-ban ez az idő egy fejlettebb algoritmus alkalmazásával 4 órára rövidült (a kulcsok feltörését mindkét esetben úgynevezett faltörő (brute force) módszerrel, vagyis a kulcstér összes elemének végigpróbálásával végezték). Az 56 bites DES kulcsok feltörésére a (későbbiekben bemutatandó) nyilvános kulcsú kriptográfia mellett kardoskodó RSA Laboratories írt ki versenyeket, a cél minden esetben egy 56 bites kulccsal titkosított üzenet megfejtése

volt. A „DES Challenge I” elnevezésű első verseny 1997-ben indult, és R. Verser ezt 84 nap alatt teljesítette, az Interneten elhelyezkedő számítógépek ezreinek közös feldolgozási kapacitását kihasználva. 1998-ban, a „DES Challenge II” versenyből kettőt is rendeztek: az elsőben 40 nap alatt sikerült feltörnie a kulcsot a distributed.net nevű szervezetnek, amely a Világhálón elhelyezkedő gépek szabad processzoridejét használja fel elosztott számítási modellű munkavégzésre, jelen esetben a kulcs törésére. A második „DES Challenge II” már csak három napig tartott. 1998 közepén az EFF (Electronic Frontier Foundation) nevű szervezet bejelentette egy olyan hardver megépítését (ezt Deep Crack-nek nevezték el), amely másodpercenként 90 milliárd kulcsot ellenőrizve átlagosan 4,5 nap alatt képes az 56 bites kulcsok törésére (ennek a gépnek az előállítási költsége körülbelül negyedmillió dollár volt, ami azt

jelentette, hogy bármely nagyobb szervezet vagy vállalat megépíthette a saját DES-törőjét, már csak azért is, mert a gép teljes dokumentációja hozzáférhető az EFF-nél). Az 1999-ben indított „DES Challenge III” már egy teljes napig sem tartott, ezt a teljesítményt a Deep Crack és a distributed.net együttműködésével tudták elérni Ekkorra már mindenki számára világossá vált, hogy az 56-bites szimmetrikus kulcsok semmiképpen nem képesek elégséges szintű biztonság megvalósítására, tehát mindenképpen szükségessé vált valamiféle új megoldás találása (vagy a felhasznált kulcsok hosszának növelésével, vagy pedig új titkosítók konstruálásával; ilyen például a DES felváltása céljából létrehozott AES [63] is). Azonban a szimmetrikus kulcsokkal kapcsolatban a kulcs (viszonylag egyszerű) törhetősége nem az egyetlen probléma; már a 70-es évek közepe táján rájöttek, hogy 12 gond van a szimmetriával is. Mint

oly sok más esetben, itt is igaz az, hogy ami egy rendszer előnyét, „szépségét” adja, az egyben a fő korlátozó tényezőt is jelentheti. Egy szemléletes példával élve képzeljük el, hogy az általunk bizalmasként kezelt információkat biztonságos módon szeretnénk eljuttatni valakihez úgy, hogy mások ne láthassák és ne módosíthassák ezeket az információkat. Ennek érdekében a titkainkat egy aktatáskába tesszük, és egy olyan lakattal zárjuk le, ami elméletileg mindenféle nyitási kísérletnek ellenáll, hacsak nincs meg hozzá az alkalmas kulcsunk. Ahhoz, hogy a másik fél hozzáférhessen az információhoz, el kell hozzá juttatni a kulcsot (vagy legalábbis egy másolatát) is. Hogyan tehetjük ezt meg, ha nincs mód személyes találkozóra? Világos, hogy bele kell tennünk a kulcsot egy másik aktatáskába, amit egy másik, de hasonló erősségű lakattal zárunk le, majd az új kulcsot is el kell juttatnunk hozzá. És így tovább Ez a

probléma a szakirodalomban kulcskiosztási problémaként ismeretes, és a nyilvános kulcsú módszerek megjelenéséig megoldhatatlan fejtörőnek tűnt a kriptográfusok számára. 2.4 Nyilvános kulcsú algoritmusok Aztán 1976-ban két stanfordi kutató, Whitfield Diffie és Martin Hellman egy teljesen új kriptográfiai megközelítést javasolt. (A teljesség kedvéért megjegyezzük, hogy a legújabb kutatások szerint nem a szerzőpáros talált rá leghamarabb erre a megoldásra: az angol titkosszolgálatnak dolgozó James Ellis, Clifford Cocks és Malcolm Williamson már 1975-ben megoldotta a kulcskiosztás problémáját, de mivel az hadititoknak minősült, nem publikálhatták az eredményeiket [4].) Az előző példa felhasználásával az új megközelítés lényege a következő: készítsünk rengeteg ugyanolyan lakatot (amely hasonlóan biztonságos, mint az előző megközelítésben), amelyhez ráadásul csak nekünk van kulcsunk, és küldjük ezeket szét a

világon annyi helyre, ahányra csak lehet (legalábbis azokhoz, akiktől várhatóan valaha bizalmasnak minősülő üzenetet kaphatunk). Ezután minden egyes alkalommal, amikor ilyen bizalmas csomagot szeretnének nekünk küldeni, nem kell mást tenniük, mint hogy a csomagot tartalmazó aktatáskára rákattintják a lakatunkat, amit aztán valóban csak mi leszünk képesek kinyitni. A Diffie-Hellman páros megoldásában a lakat és a kulcs szerepét is egy-egy kriptográfiai kulcs játssza (természetesen a megfelelő kódoló és dekódoló algoritmusokkal együtt). A példa kulcsát magánkulcsnak vagy privát kulcsnak hívjuk, mivel ezt csak mi ismerjük (és feltehetően titokban tartjuk egy biztonságos helyen), míg a lakat szerepét a nyilvános kulcs veszi át (ami attól lesz nyilvános, hogy bárki megismerheti, sőt, meg kell ismernie, ha titkosított adatot kíván küldeni a számunkra). A szerzőpáros három feltételt írt elő, amelyet a privát-nyilvános

kulcs-párnak teljesítenie kell (ideértve természetesen egy nulladik feltételt is, miszerint a kulcsoknak különbözőnek kell lennie; innen ered a módszer másik elnevezése: aszimmetrikus titkosítás, vagyis a kódoló és a dekódoló kulcsok különböznek egymástól): - D(E(P)) = P, azaz az E kódoló algoritmussal titkosított szöveg a D dekódoló algoritmus használatával legyen visszafejthető; - D előállítása E alapján legyen nagyon nehéz feladat (legalábbis ne lehessen elég gyorsan megtalálni); és - E legyen feltörhetetlen a választott nyílt szöveg típusú támadással (vagyis amikor a kódtörő rendelkezik általa választott nyílt szöveggel, és annak a titkosított párjával is). A módszer működése viszonylag egyszerű. Ha az A fogadó titkos üzenetet szeretne fogadni, létrehozza a fenti követelményeknek eleget tevő két algoritmust és a hozzájuk tartozó kulcsokat (EA-t és DA-t). Ezek után nyilvánosságra hozza a kódoló

algoritmust, a titkosító kulcsot, és a dekódoló algoritmust; egyedül a dekódoló kulcsot (DA) tartja titokban. Ezt legegyszerűbben úgy teheti meg, hogy egy mindenki által olvasható fájlba teszi egy hálózati helyen 13 Innentől kezdve a biztonságos kommunikációs csatorna felépíthető közöttük, feltéve, hogy a másik fél, B, hasonlóan publikálja az ő nyilvános információit. Ha A egy P titkos üzenetet szeretne elküldeni B-nek, akkor P-t titkosítja B kódoló kulcsával (azaz B nyilvános kulcsával, vagyis EB-vel), és így EB(P)-t küldi el B-nek. B ezt egyszerűen dekódolhatja a saját DB titkos kulcsával, mivel az első feltétel értelmében DB(EB(P)) = P, viszont rajta kívül senki sem lesz képes az üzenet megfejtésére, mivel a második feltétel értelmében DB előállítása EB ismeretében szinte lehetetlen. Ily módon megvalósulhat közöttük a biztonságos kommunikáció. Bár a későbbiekben még foglalkozunk vele, már most

megjegyezzük, hogy az első néhány üzenetváltás általában csak egy szimmetrikus, úgynevezett viszonykulcs egyeztetése céljából alkalmazza a nyilvános kulcsú módszert; ezután a kapcsolat során a kommunikáció a titkos, de szimmetrikus viszonykulccsal titkosítva zajlik [4]. 2.41 Az RSA algoritmus A fenti megközelítés megvalósításának hosszú időn keresztül volt egy lényeges akadálya: 1978-ig nem találtak a fenti három követelménynek eleget tevő eljárásokat. Akkor azonban egy az M.IT-n (Massachusets Institute of Technology) dolgozó csapatnak sikerült kifejlesztenie egy alkalmas módszert, amely a számelmélet tételein és a nagy számok faktorizációján alapult; az algoritmust a csapattagok kezdőbetűi (Rivest, Shamir és Adleman) alapján RSA névre keresztelték. Az algoritmus működésének fő lépéseit a következőkben mutatjuk be; a részletek iránt érdeklődők az [5] honlapon illetve a [2] műben találnak további információkat

és részletesebb leírást. Először meg kell határoznunk a kódoláshoz és dekódoláshoz szükséges paramétereket: - Kiválasztunk két elég nagy prímszámot, p-t és q-t (elég nagy alatt a körülbelül 10100-nál nagyobb számokat értjük); - Kiszámítjuk az n = p × q és a z = (p – 1) × (q – 1) számokat; - Kiválasztunk egy z-hez relatív prímet, amit d-vel jelölünk; és - Keresünk egy olyan e számot, amelyre fennáll az e × d = 1 (mod z) egyenlőség. Ha megkaptuk ezeket a számokat, elkezdhetjük a nyílt szöveg titkosítását. Az RSA algoritmus kódolója tulajdonképpen a blokk-titkosítók családjába tartozik, ezért a bitsorozatnak tekintett szöveget olyan P blokkokra partícionáljuk, amelyekre fennáll, hogy 0 ≤ P < n. Általában ezt oly módon végezzük, hogy az üzenet bitjeit k bit hosszúságú csoportokra osztjuk, ahol k a legnagyobb olyan egész, amelyre 2k < n Ezt követően a titkosítandó P blokk alapján kiszámítjuk a C =

Pe (mod n) értéket (C visszafejtéséhez a P = Cd (mod n) összefüggést alkalmazzuk). Az algoritmus fontos jellemzője, hogy bebizonyítható, hogy minden a fenti tartományba eső P-re a kódoló és a dekódoló függvények egymás inverzei. A kódoláshoz az e és az n számok szükségesek, a dekódoláshoz a d és az n számok; ily módon a nyilvános kulcsot az (e , n) pár, míg a magánkulcsot a (d , n) pár adja. A módszer biztonságát a nagy számok faktorizálásának nehézsége garantálja. Ha a támadó képes lenne a mindenki által ismert n szám faktorizálására, meghatározhatná p-t és q-t, és így kiszámolhatná z-t, amiből viszont az euklideszi algoritmus segítségével megkaphatná e-t és d-t. Szerencsére ez a faktorizálás olyannyira nehéz feladat, hogy Rivest számításai alapján egy 200 bites szám faktorizálása 4 milliárd évet venne igénybe (míg egy 500 bites számé nagyjából 1025 évet) egy olyan számítógépen, amely egy

utasítást 1 ms alatt hajt végre, valamint a Rivest által ismert leghatékonyabb algoritmus-implementációt futtatja [6]. Még ha az informatikai fejlődés üteme a későbbiekben sokszorosan meghaladja is a mait, akkor sem kell aggódnunk a módszer biztonsága miatt: elég, ha a p és q számokat nagyobbnak választjuk. 2.42 Más nyilvános kulcsú eljárások 14 Az informatikai biztonságot megvalósító módszerek között még jelenleg is az RSA az egyik legmegbízhatóbbnak tartott módszer, bár léteznek más megközelítések is. Ezeket alapvetően három csoportba szokás sorolni: a nagy számok faktorizációján alapuló, a diszkrét logaritmus számításon alapuló, illetve a hátizsák tartalmát összsúly alapján meghatározó módszerekre. Ezekről a [7] műben olvashatunk részletesebben Mindhárom csoport algoritmusai közösek abban, hogy olyan problémák megoldására vezeti vissza a titkosítási feladatot, amely algoritmikusan elég bonyolultnak

minősül. A hátizsákos módszert, de annak továbbfejlesztett változatait sem tartják manapság igazán biztonságosnak, ugyanakkor ígéretesnek tűnik egy új keletű módszer, amely ellipszisívek számításán alapszik; ezek bemutatása nem tartozik szorosan a jelen dolgozat tárgykörébe, az érdeklődők a fent említett munkákban találhatnak részletesebb információt. 2.5 Hash függvények Létezik a titkosítási módszereknek egy speciális „elfajuló” csoportja, amelyet a hagyományos, köznapi értelemben nem is igen nevezhetünk kódolási módszernek, hiszen ezek egyrészt valójában kulcs nélküli módszerek, másrészt viszont a nyílt szöveg titkosításakor természetes elvárás lehet, hogy az eredeti szöveg visszaállítható legyen a kódolt párból. Ezek a hash függvényeken alapuló módszerek (más néven üzenetpecsét-függvények1, message digest-módszerek, egyirányú titkosítási módszerek) közösek abban, hogy a titkosítási

folyamat megfordíthatatlan, azaz a C titkosított szöveghez nem létezik a D dekódoló eljárás, amely a P szöveget eredményezné Sok esetben azonban pontosan ez az, amire szükségünk van. A jelen dolgozat tárgykörében a hash függvények legfontosabb felhasználási területe az elektronikus dokumentumok (későbbiekben részletesen tárgyalt) integritásvizsgálata, bár léteznek más alkalmazási területek is, például a jelszóállományok védelménél széles körben alkalmazzák őket. Az eljárás során egy tetszőleges (változó) hosszúságú nyílt szöveg „digitális lenyomatát” készítjük el, azaz a függvény segítségével a szöveget egy másik, rögzített hosszúságú szöveggé transzformáljuk. A hash függvényekkel szemben három fontos elvárást támasztunk: - Adott P-hez könnyen számítható legyen az MD(P) hash érték; - Adott MD(P)-hez gyakorlatilag lehetetlen legyen megtalálni P-t; és - Ne lehessen két különböző üzenetet

generálni, amelyekre a hash függvényt alkalmazva ugyanazt az MD(P) értéket kapnánk (ehhez az üzenetpecsét célszerűen legalább 128 vagy több bitből kell, hogy álljon). Szokás még egy negyedik feltételt is szabni, ez a tárgykörben „lavinahatás” néven ismeretes. A feltétel lényege, hogy a P nyílt üzenet egyetlen bitjének megváltoztatásával az MD(P) érték bitjeinek legalább a fele megváltozzon A következőkben bemutatunk két elterjedt megoldást. Csakúgy, mint más területeken is, az alábbi eljárásoknak számos alternatívája létezik, de ezekre ehelyütt nem térünk ki részletesen. 2.51 Az MD5 üzenetpecsét Ez a módszer egy Rivest által kidolgozott hash függvény-sorozat ötödik tagja. A legutolsó, ötös verzió az előző verzió biztonsági hiányosságait kijavító megoldásokat is tartalmaz, ezért valamelyest lassabb, mint az MD4. Az 1992-ben publikált MD5 algoritmus úgy működik, hogy a bemeneti biteket alkalmasan bonyolult

módon szegmen1 A dolgozatban, ahol csak lehetséges, a fogalmak magyar megfelelőit használjuk, mégpedig abban a formában, ahogyan azt a http://www.ihmhu/kutatasok tanulmanyok/b/it biztonsagi fogalomtarpdf címen elérhető „IT biztonsági fogalomtár” c munka használja Ezzel együtt alkalmanként a tárgykörben elterjedt további megnevezéseket is használunk, feltüntetve a Fogalomtárban alkalmazott megnevezést is. 15 tálja úgy, hogy a kimeneti bitek mindegyike függ minden bemeneti bittől. Kezdetben az eredeti üzenetet feltölti 448 bit hosszúságra (mod 512). Ezután egy 64 bites egészként hozzáfűzi az eredeti szöveg hosszát; ily módon a bemenet hossza 512-vel osztható lesz. Az inicializálás befejező lépéseként egy 128 bites puffert feltöltünk egy meghatározott számmal. Ezt követően minden körben veszünk egy 512 bites szeletet a bemenetből, és összekeverjük a 128 bites puffer tartalmával. Az algoritmus ezen kívül használ egy a

szinusz függvény értékeit tartalmazó táblázatot is; ezt két okból teszi: egyrészt, mert ez valamelyest véletlenszerűbb értékeket tartalmaz, mint egy véletlenszám-generátor, másrészt pedig a szerző ezzel akarta elkerülni annak a látszatát, hogy valamiféle kiskaput épített a módszerbe, amelyet csak ő ismer. Minden bemeneti blokkon négyszer hajtjuk végre a kört. Ezt a folyamatot ismételjük addig, míg minden bemeneti blokkra sor nem kerül. Az eljárás kimenetét végül a 128 bites puffer tartalma adja, ez az érték lesz az üzenetpecsét. Az eljárás 32 bites gépekre írható szoftverekre optimalizált, ezért elképzelhető, hogy a jövőbeli nagysebességű hálózatokhoz is elég gyors lesz. 2.52 Az SHA üzenetpecsét Ezt az üzenetpecsét-függvényt az Egyesült Államok Nemzetbiztonsági Hivatala, az NSA (National Security Agency) fejlesztette ki. Az MD5-höz hasonlóan az SHA (Secure Hash Algorithm) algoritmusa is 512 bites blokkonként

dolgozza fel a bemenetet, de 160 bites pecsétet generál. Szintén azzal kezdi, hogy 448 bitesre tölti fel a bemenetet, és hozzáadja a 64 biten ábrázolt üzenethosszt, majd beállítja a 128 bites puffer kezdeti értékét Minden bemeneti blokknál a kimeneti blokk frissítődik az 512 bemeneti blokk függvényében Nem használ véletlen számokat, viszont minden bemeneti blokkra 80-szor ismétli meg a kört, ezzel egy alapos keverést eredményez. Ezen kívül 20 körönként változik a keverési függvény. Az SHA hash kódja 32 bittel hosszabb, mint az MD5-é, viszont szinte minden másban megegyeznek, ezért nagyjából 232-szer biztonságosabb, mint a másik. Ugyanakkor a működése lassabb, és bizonyos esetekben hátrányt jelenthet, hogy a hash kód nem kettőhatvány hosszúságú. További különbség, hogy az MD5 egy RFC-ben jelent meg, és főleg az Interneten használatos, míg az SHA egy kormányzati szabvány, és jellemzően olyan szervezetek illetve

intézmények használják, amelyeket a kormány kifejezetten utasít erre, vagy szükségük van a különleges biztonságra. Mindamellett elkészítették az SHA szabvány egy olyan változatát is (az SHA-1 algoritmust), amelyet a NIST (National Institute of Standards and Technology, az Egyesült Államok Nemzeti Szabványügyi Hivatala) is jóváhagyott szabványként. 2.6 A titkosítási technikák felhasználási köre A fentiekben vázolt három különböző titkosítási módszer jelentős eltérésekkel rendelkezik, de a lényegi különbség nem a kulcsok számában vagy az alkalmazott kulcshosszokban keresendő, jobban mondva ezek inkább csak a fő eltérés következményei, amely nem más, mint a technikák specifikus felhasználási területe. A hash függvényeket az elektronikus adatok integritásvizsgálatánál alkalmazzuk: ha az elküldendő adathoz csatoljuk az üzenet elküldés előtti lenyomatát, akkor a fogadó egyszerűen ellenőrizheti, hogy az adat

megváltozott-e a továbbítás során, mivel a fogadáskor ugyanazzal az algoritmussal készített lenyomat más lesz, ha az üzenet akár egyetlen bittel is különbözik az eredetitől. Viszont még elméletileg sincs módunk a lenyomat alapján az eredeti üzenet visszaállítására. A titkos kulcsú algoritmusok ezzel szemben az üzenetek rejtjelezésére ideálisak. A küldő ráadásul üzenetenként megváltoztathatja a viszonykulcsot, ehhez persze az szükséges, hogy erről a fogadó is értesüljön, továbbá neki is birtokában kell lennie a vonatkozó titkos viszonykulcsnak. Az eljárások gyorsak, rugalmasak, és a kulcshossz megválasztásával biztonsági szempontból is jól ská- 16 lázhatóak. A kulcskiosztás problémáját viszont kizárólag a nyilvános kulcsú technikákkal oldhatjuk meg hatékonyan Ezek hátránya viszont, hogy a hagyományos (szimmetrikus) kódolási algoritmusoknál körülbelül 3 nagyságrenddel, vagyis nagyjából 1000-szer

lassabbak, az üzenetek hosszát körülbelül a duplájára növelik, és ugyanazt a szintű informatikai biztonságot csak lényegesen nagyobb kulcsméret mellett képesek biztosítani (egy 80 bites szimmetrikus titkosító kulcs erejének egy körülbelül 1024 bites nyilvános kulcs/privát kulcs ereje felel meg, míg egy 128 bites szimmetrikus kulcs ereje egy 3000 bites nyilvános kulcs erejét hordozza [8]). Ezért a jelenlegi megvalósítások az úgynevezett hibrid módszereket alkalmazzák, ahol (amint azt feljebb említettük, és a későbbiekben majd részletesen tárgyaljuk) a nyilvános kulcsú módszereket csak egy egyszer használatos viszonykulcs kialakításához használják, maga a biztonságos kommunikáció a szimmetrikus viszonykulcs általi titkosítással védett, és ha hitelesítésre is szükség van, ezt a hash függvények és üzenetpecsétek alkalmazásával valósítják meg. 2.7 A digitális aláírás Ha következetesek akarunk lenni, a digitális

aláírásokról nem az alapvető kriptográfiai módszereket bemutató részben kellene szólnunk, hiszen ezek az előbbiekben felsorolt technikák bizonyos ötvözetét képezik, és nem alkotnak egy önálló részterületet a titkosítási módszereken belül. Mindamellett a későbbiekben használni fogjuk a digitális aláírás fogalmát más témákkal való összefüggésben, ezért a módszer (szigorúan a titkosítási módszerekkel kapcsolatban vett) alapjait már ehelyütt bemutatjuk. Amint azt a 6. fejezetben részletesen tárgyaljuk majd, digitális dokumentumnak tekinthetünk szinte bármit, aminek létezik elektronikus közegen keresztül továbbítható formája. Említettük, hogy a hagyományos (papír-alapú) dokumentumokhoz hasonlóan itt is szükség lehet a dokumentumok hitelesítésére, és ezen a területen a digitális aláírások többet nyújtanak, mint a papíron létező társaik. Az ily módon aláírt üzenetek továbbítása kapcsán a digitális

aláírások három fő tulajdonságát különböztethetjük meg: - Lehetővé teszik, hogy a fogadó ellenőrizze a feladó valódiságát; - Biztosítják, hogy a küldő nem tagadhatja le később, hogy valóban ő küldte az üzenetet; valamint - Biztosítják az üzenet integritásának ellenőrzését, vagyis a digitális aláírással meggyőződhetünk arról, hogy a dokumentum tartalma nem módosult út közben. Az első feltételnek a fenti módszerek figyelembe vételével triviális módon tehetünk eleget: válasszunk egy nyilvános kulcsú algoritmust, titkosítsuk a teljes dokumentumot a saját magánkulcsunkkal, csatoljuk hozzá a nyilvános kulcsunkat, és az egészet küldjük el a fogadónak. Ha a nyilvános kulcs alkalmazásával visszafejtett üzenet értelmes lesz, a fogadó biztos lehet benne, hogy csakis a nyilvános kulcshoz tartozó privát párral titkosíthatták az üzenetet, vagyis az üzenet csak a küldőtől származhat, hiszen csak ő ismeri az adott

magánkulcsot (ehhez természetesen meg kell oldani egy adott magánkulcs és egy adott személy egyértelmű egymáshoz rendelését és ennek nyilvánosságra hozását; a későbbiekben erre is kitérünk részletesen). Ezzel viszont nyilvánvaló módon eleget teszünk a második feltételnek is. A harmadik feltételnek oly módon tehetünk eleget, hogy kiválasztunk egyet a fenti hash függvények közül, és ezzel elkészítjük az üzenet digitális lenyomatát, vagyis az üzenetpecsétet, amit aztán szintén titkosítunk a saját magánkulcsunkkal. Ezt a lenyomatot csatoljuk a dokumentumhoz, amit az előzőekben leírt módon titkosítottunk, majd az egészet továbbítjuk a fogadóhoz. (Néha nincs szükség a teljes dokumentum titkosítására, ilyenkor csak a kódolatlan, eredeti dokumentumhoz csatoljuk a titkosított lenyomatot) Fogadáskor a fogadó a nyilvános kulcsunkkal visszafejti az üzenetpecsétet (ha a dokumentum titkosított, akkor a teljes dokumentumot is),

majd a küldő által választott hash algoritmust a fogadó oldalon futtatva elkészíti a dokumen- 17 tum lenyomatát. Ha a két lenyomat megegyezik, akkor az üzenet tartalma nem változott meg az úton Szintén említettük már, hogy az aszimmetrikus módszerek lassabbak, mint szimmetrikus társaik, valamint hogy az aszimmetrikus titkosítás jelentősen megnöveli a dokumentum méretét, ezért a gyakorlatban a küldő oldalon a következő „csomag” készül el: A küldő választ egy véletlenszerű szimmetrikus kulcsot, és a kulcs felhasználásával titkosítja a dokumentumot egy szimmetrikus (például a 3DES) algoritmus segítségével. Ezután a szimmetrikus titkosítási kulcsot titkosítja a magánkulcsával A lenyomat a fentiekben leírt módon az eredeti dokumentumról készül, bár szokás a szimmetrikus kulcsos titkosítás után is készíteni, mivel ez növeli a biztonság mértékét. Ezután mindezt – a nyilvános kulcsával együtt – elküldi a

fogadónak (a gyakorlatban az egész csomagot szokás még ellátni úgynevezett időbélyeggel is, ezt szintén a későbbiekben tárgyaljuk), ahol a fentiekkel analóg ellenőrzések kerülnek végrehajtásra. Meg kell jegyeznünk azonban egy fontos körülményt, amely nélkül a fenti fejtegetés nem működhetne: a nyilvános kulcsú módszerekkel foglalkozó részben az egyik feltétel az volt, hogy teljesüljön a D(E(P)) = P feltétel. A digitális aláírások esetében azonban nem ennek, hanem az E(D(P)) = P tulajdonságnak kell teljesülnie, hiszen most a titkosító kulccsal (D) titkosított üzenetnek a nyilvános kulccsal (E) való visszafejtésére van szükség. Az RSA – de az aszimmetrikus módszerek szinte mindegyike – rendelkezik ezzel a tulajdonsággal, tehát az említett módszereket valóban helyesen használhatjuk digitális aláírások készítésére és ellenőrzésére. Megjegyezzük továbbá, hogy léteznek titkos (szimmetrikus) kulcsú aláírási

módszerek is, ezekre szintén a későbbiekben térünk ki. 18 3. Digitális tanúsítványok és nyilvános kulcsú infrastruktúrák Az előző fejezetekben bemutattuk azokat az alapvető módszereket és algoritmusokat (legalábbis néhányat a legfontosabbak közül), amelyek nélkülözhetetlenek a biztonságos üzenetküldéshez, és ily módon a biztonságos kommunikációs csatornák felépítéséhez is. Egy igen fontos kérdést azonban figyelmen kívül hagytunk, és ez a kérdés egyben a jelen dolgozat elsődleges tárgya: Honnan tudjuk, hogy az a nyilvános kulcs, amit a kommunikációs partnerünkkel való üzenetváltás során az üzenet titkosításához vagy a dokumentum digitális aláírásához használunk, valóban annak az embernek a birtokában van, akinek mi őt hisszük? A kérdés lényegi mondanivalójának tisztázásához szabadjon bemutatnunk egy egyszerű példát. 3.1 A közbeékelődéses támadás Tegyük fel, hogy üzenetet akarunk küldeni a

partnerünknek, és nem tudjuk, hogy a „beszélgetésünket” egy harmadik fél folyamatosan lehallgatja. Ez a harmadik fél a szakirodalomban közbeékelődéses (man-in-the-middle) típusú, aktív vagy passzív támadást hajthat végre, amely lényege a következő: egy lehetséges forgatókönyv szerint a kommunikáció kezdeti szakaszában jelezzük az F fogadó félnek, hogy üzenetet szándékozunk neki küldeni, mire ő elküldi nekünk az EF nyilvános kulcsát, hogy azzal titkosítsuk az M üzenetet. A T támadó ezt az üzenetet elfogja, és lecseréli egy másik üzenetre, amiben azt állítja, hogy az ő nyilvános kulcsa (ET) a partnerünk kulcsa. Mi megkapjuk ezt az üzenetet, és mit sem sejtve ezzel a hamis ET kulccsal titkosítjuk a partnerünknek szánt M üzenetünket, amit persze csak a támadó képes visszafejteni, hiszen ő birtokolja a nyilvános kulcs vonatkozó párját, azaz a DT magánkulcsot. Ezt az ET(M) üzenetet persze a támadó ismét elfogja, és

a DT magánkulccsal visszafejtve megkapja az eredeti, kódolatlan M üzenetet. T ismeri a partnerünk EF nyilvános kulcsát, hiszen azt elfogta már a kommunikáció legelején, ezért képes az EF(M’) üzenet előállítására, ahol M’ egy általa választott üzenet, amelyre T lecserélte az M üzenetet. Ezt az EF(M’) üzenet küldi el tehát a partnerünknek, amit természetesen F képes visszafejteni a DF magánkulcsával. Ha az eredeti M üzenetben (számítva az esetleges válaszra) elküldtük a mi nyilvános kulcsunkat, az M’ üzenetben a támadó állíthatja azt, hogy a mi kulcsunk nem más, mint az ő ET nyilvános kulcsa. Innentől kezdve viszont ismeri mind a mi, mind pedig a partnerünk nyilvános kulcsát, továbbá mi is és a partnerünk is azt hisszük, hogy a másik nyilvános kulcsa az ET kulcs; ily módon a további üzenetváltások során folyamatosan lehallgathatja a beszélgetést, sőt, akár módosíthatja is az üzeneteket anélkül, hogy

bármelyikünk ezt észrevenné. 3.2 Hitelesítés digitális tanúsítványokkal Amint az a fenti egyszerű példából is látszik, önmagában a nyilvános kulcsú kriptográfia még nem garancia a nem biztonságos közegek feletti biztonságos kommunikációra. A példából az is kitűnhet, hogy a probléma abból adódik, hogy nincs egyértelmű megfeleltetés a kommunikáló felek és az általuk használt nyilvános kulcsok között (és ez persze a magánkulcsokról is elmondható) Ezt a megfeleltetést hozzuk létre az úgynevezett digitális tanúsítványokkal (digital certificate). A tanúsítvány tulajdonképpen nem más, mint a bevezetőben említett igazolások vagy bizonyítványok digitális megfelelője: egy olyan adatszerkezet, amely azt bizonyítja, hogy a nyilvános kulcs valóban hozzánk tartozik, és mi birtokoljuk a hozzá tartozó privát kulcspárt. Természetesen egy tanúsítvány csak akkor bizonyíthat bármit is, ha tartalmazza az őt kibocsátó

hitelesítő hatóság, az úgynevezett hitelesítés-szolgáltató (Certificate Authority, CA) „pecsétjét”. Hogy egy köznapi példát említsünk: a diákigazolvány is csak akkor érvényes, ha rajta van az érvényesítő matrica A bevezetőben említett papír-alapú dokumentumok esetében is a dokumentumok hitelességét nem 19 maga a fizikai hordozó adta, hanem a rajta szereplő hivatalos pecsét, illetve annak a hatóságnak a megkérdőjelezhetetlensége, amely a pecsétet rányomta az igazolásra. A digitális tanúsítványok esetében is ez a helyzet: a CA a tanúsítvány kiadásával igazolja, hogy a nyilvános kulcs hozzánk tartozik, valamint mi birtokoljuk a hozzá tartozó magánkulcsot is. És nyilvános kriptográfiai rendszerekben mi mással is igazolhatnánk bármit is, mint egy nyilvános kulcsú kriptográfiai aláírással: a tanúsítvány végső soron attól lesz hiteles (és ezen keresztül mi is attól lehetünk hitelesek), hogy a hitelesítő

hatóság, vagyis a hitelesítés-szolgáltató a nyilvános kulcsú aláírásával látta el a tanúsítványt, vagy az arról készült lenyomatot. A hitelesítés-szolgáltatókat és a köréjük épülő infrastruktúrát a későbbiekben tárgyaljuk. 3.3 Tanúsítványformátumok A fentieken kívül persze a tanúsítványok más, az alábbiakban részletezendő információkat is tartalmazhatnak; ha ezeket osztályozni szeretnénk, a tanúsítványok tartalmát négy fő szekcióba sorolhatjuk. Az első a nyilvános kulcs tulajdonosának azonosítására szolgáló adatok, a második a hitelesítés-szolgáltató (egység vagy szervezet) azonosítására szolgáló adatok, a harmadik maga a nyilvános kulcs, a negyedik pedig minden más, vagyis az attribútumok. A tulajdonos azonosítójaként leginkább annak egyedi neve szokott szerepelni, de feltüntethető bármilyen más, a tulajdonos felismerésére alkalmas adat is, sőt akár álnév is használható (megjegyezzük,

hogy az egyedi név egyedisége általában csak a hitelesítés-szolgáltató által „felügyelt” tartományban egyedi, bár léteznek globális egyediséget garantáló javaslatok/megoldások is, ilyen például az ITU X.500 [9] ajánlásában szereplő megkülönböztetett név is). A hitelesítés-szolgáltató azonosítása annak egyedi neve alapján történhet. Az attribútumok közt helyet szokott kapni a tanúsítvány érvényességi ideje, osztálya, típusa, egyedi sorozatszáma és a hitelesítés-szolgáltató megjegyzései, sőt lehetőség van akár a tulajdonos fotójának és egyéb biometrikus azonosítóinak a beillesztésére is (Megjegyezzük, hogy léteznek olyan tanúsítvány-formátumok is, amelyek jogosultság-jellegű információkat tartalmaznak.) Mindez a hitelesítésszolgáltató magánkulcsával van aláírva (ez az aláírás szintén a tanúsítvány része), s így ezek az adatok megbonthatatlanok és megváltoztathatatlanok. Nyílván ilyen

tanúsítványokat nem lehet ad hoc módon létrehozni (illetve lehet, csak nagy valószínűséggel senki sem fogja elfogadni), ezért különféle szervezetek létrehozták a saját tanúsítvány-formátumukat A két legelterjedtebb tanúsítványformátum bemutatása előtt megemlítjük, hogy a bevezetőben vázolt különböző bizalmi modellek nagyban befolyásolták a formátumok szerkezetét, erre külön is kitérünk majd. 3.31 Az X509 tanúsítványformátum Az X.509 [10] az ITU (International Telecommunications Union) azon ajánlása, mely a tanúsítvány és a későbbiekben bemutatásra kerülő tanúsítvány-visszavonási lista szerkezetére, felépítésére, tartalmára, kezelésére és még sok más, ezzel összefüggő dologra ad előírásokat. A jelenleg elérhető, elektronikus aláírást és tanúsítványt alkalmazó rendszerek szinte kivétel nélkül e szabványnak (többé-kevésbé) megfelelve működnek, pontosabban az e szabványnak megfelelő

tanúsítványokat képesek hasznosítani. Az X.509-es ajánlás legfrissebb, 3-as verziója szerint egy tanúsítvány a 2 ábrán bemutatottak szerint néz ki. Az egyes mezők jelentése a következő: - Verzió: A tanúsítvány a szabvány mely verziója alapján készült (v1, v2, vagy v3). - Sorozatszám: A tanúsítvány egyedi sorozatszáma (hitelesítés-szolgáltatón (CA) belül egyedi). 20 - Aláírás algoritmusa: A hitelesítés-szolgáltató által a tanúsítvány aláírására használt algoritmus azonosítója. - Kibocsátó-azonosító: A tanúsítványt kibocsátó hitelesítés-szolgáltató egyedi (X.500) neve - Érvényesség: A tanúsítvány érvényességének kezdő és végdátuma. - Tulajdonos-azonosító: A tanúsítvány tulajdonosának egyedi (X.500) neve - Nyilvános kulcs: A tanúsítvány által hitelesített nyilvános kulcs és annak algoritmus-azonosítója. - Kibocsátó-ID: A kibocsátó egyedi azonosítója (csak a v2 és v3 verziókban). -

Tulajdonos-ID: A tanúsítvány tulajdonosának egyedi azonosítója (csak a v2 és v3 verziókban). - Bővítmény típusa: A bővítmény típusának egyedi objektumazonosítója (csak a v3 verzióban). - Bővítményjelző: Kritikus / Nem kritikus (csak a v3 verzióban). - Bővítmény értéke: A bővítmény értéke a típusnak megfelelően (csak a v3 verzióban). A Verziótól a Nyilvános kulcsig terjedő mezők már az első verzióban jelen voltak, és kötelezően kitöltendők. A Kibocsátó-ID és Tulajdonos-ID mezők a második verzióban kerültek bevezetésre, opcionális felhasználásra Ezek a mezők egyrészt azt a célt szolgálják, hogy a kötelező részben elhelyezkedő azonosítókat egyértelművé tegyék abban az esetben, ha ugyanaz az X.500-as név valamilyen okból újra kiosztásra kerülne, másrészt, hogy az X.500-as névformátumtól eltérő névkonvenciónak megfelelő nevet is fel lehessen tüntetni azonosítóként. A bővítmény mezők (ezekből

több is követheti egymást) az alkotók óvatosságát jelzik: ahelyett, hogy negyedévente egészítenék ki a szabványt, a bővítményekkel lehetőséget biztosítanak arra, hogy bármely kibocsátó olyan adatot foglaljon a tanúsítványba, ami neki tetszik. Verzió Sorozatszám PGP-verziószám Kibocsátó-azonosító Nyilvános kulcs Érvényesség Azonosító-információ Tulajdonos-azonosító Digitális aláírás Nyilvános kulcs és algoritmus-azonosító Azonosító-információ Tulajdonos-ID Digitális aláírás Típus Jelző Érték Típus Jelző Érték Kibocsátó aláírása Bővítmény Kibocsátó-ID Több aláírás Aláírás algoritmusa Érvényességi idő Szimmetrikus algoritmus 2. ábra: Az X509 és a PGP tanúsítványformátum (Forrás: [10, 8]) 3.32 A PGP tanúsítványformátum A PGP (Pretty Good Privacy) első ránézésre nem több, mint egy egyszerű, de biztonságos elektronikus levelezési alkalmazás. A szerző, Phil

Zimmermann azonban en- 21 nél sokkal többet hozott létre: nemcsak egy levelező programot, hanem egy a nyilvános kulcsú és a szimmetrikus kulcsú kriptográfia előnyeit ötvöző rendszert, és nem mellékesen egy teljes hitelesítési és bizalmi modellt is. Magát a programot az Alkalmazási réteggel foglalkozó részben mutatjuk be részletesen, most azonban megvizsgáljuk a rendszer által felhasznált tanúsítványok szerkezetét; ennek részletes leírása a [8] honlapon található meg. A 2 ábra a tanúsítvány sematikus szerkezetét mutatja be, ahol az egyes mezők jelentése a következő: - PGP-verziószám: A tanúsítványhoz kapcsolódó kulcs létrehozásához felhasznált PGP-verzió azonosítója. - Nyilvános kulcs: A tanúsítvány birtokosának nyilvános kulcsa, a kulcs algoritmusával (RSA, DSA vagy DH) együtt. - Azonosító-információ: A tanúsítvány tulajdonosával kapcsolatos „azonosítási” információk, például a név, felhasználói

azonosító, fénykép és hasonlók. - Digitális aláírás: A tanúsítvány tulajdonosának digitális aláírása, amelyet szokás önaláírásnak (self-signature) is nevezni; a tanúsítványhoz tartozó nyilvános kulcs privát kulcs-párját használó digitális aláírás. - Érvényességi idő: A tanúsítvány érvényességének a kezdődátuma és végdátuma, azt jelzi, hogy a tanúsítvány érvényessége mikor jár le. - Szimmetrikus titkosítási algoritmus: Azt a szimmetrikus titkosítási algoritmust jelöli, amelyet a tanúsítvány tulajdonosa előnyösnek tekint a neki szánt információ titkosításához. A PGP által támogatott algoritmusok a CAST [6], az IDEA és a Triple-DES. A PGP tanúsítványoknak van néhány speciális, csak rájuk jellemző tulajdonságuk. Ezek egyike, hogy egyetlen tanúsítvány több aláírást is tartalmazhat Több személy is aláírhatja a kulcs/azonosító párt annak kifejezésére, hogy biztosak benne: a nyilvános kulcs

valóban a tanúsítványban specifikált személyhez tartozik. A PGP tanúsítványok további sajátossága, hogy egyetlen nyilvános kulcshoz több azonosító információ (például a tulajdonos neve, e-mail címe, vállalati azonosítója stb) is tartozhat, amelyek mindegyike különböző aláírással lehet ellátva Így például a tulajdonos nevének és nyilvános kulcsának az összetartozását egy közeli ismerősének aláírása bizonyíthatja, az e-mail cím és nyilvános kulcs összetartozását a vállalat digitális aláírása, és így tovább. 3.33 Különbségek a tanúsítványok között Az X.509 és a PGP tanúsítványok között több lényegi különbség is felfedezhető, ezek közül a legfontosabb talán a tanúsítvány kibocsátójának személyében rejlik. Bárki kibocsáthat önmaga számára PGP tanúsítványokat, azaz hitelesítheti a saját nyilvános kulcsát Az X509 tanúsítványokat viszont minden esetben a CA bocsátja ki, mégpedig oly

módon, hogy miután megadtuk az azonosító információinkat, nyilvános kulcsunkat és valamiféle bizonyítékát annak, hogy rendelkezünk a privát párjával (például aláírjuk az azonosító információkat vele), elküldhetjük az egészet a CA-nak, amely esetleg valamiféle „kutatást” végez az információk helyességével kapcsolatban, majd generálja, és végül visszaküldi a tanúsítványt. A folyamat pontos menetét a későbbiekben részletesebben is bemutatjuk További fontos különbség még, hogy az X509 tanúsítványok csak egyetlen tulajdonosi nevet tartalmazhatnak, valamint ezeknél csak egyetlen digitális aláírás használható a tanúsítványok aláírására. Az igazi különbség mégiscsak a bevezetőben említett, mögöttes bizalmi modellben rejlik; az előbb említett különbségek mindegyike ennek csak a következménye. 3.34 Bizalmi modellek 22 Amint a bevezetőben is utaltunk rá, a bizalom mindig szubjektív. Továbbá, a köznapi

bizalmi modellnek megfelelően a bizalom „tranzitív”, vagyis ha A megbízik Bben, és B azt állítja, hogy megbízik C-ben, akkor elég nagy valószínűséggel A meg fog bízni C-ben. Ily módon bizalmi hálók alakulnak ki, ahol egy adott pontból (személy/szervezet tanúsítványától) kiindulva egy bizalmi láncon keresztül érhetünk el egy másik ponthoz. A fő különbség az X509 tanúsítványokat alkalmazó rendszerek és a PGP tanúsítványokat alkalmazó rendszerek között az, hogy az első esetben a bizalmi lánc a CA-val, a másodikban pedig magával a felhasználóval kezdődik. Az X.509 tanúsítványok úgynevezett hierarchikus, fa-struktúrájú bizalmi modellt feltételeznek, amely fa gyökere mindig egy CA (és mivel mindig a gyökér felé eső irányban bízunk meg egy tanúsítványban, mindenképpen megbízhatóként kell elfogadnunk a CA által kibocsátott tanúsítványban állítottakat). Ennek megfelelően viszont a tanúsítványok láncolata

mindig nyomon követhető, és mivel a lánc mindig véges hosszú, biztonsági jellegű problémák felmerülése esetén könnyebb megtalálni a „vétkes” tanúsítványt, és könnyebb lokalizálni azokat a tanúsítványokat, amelyek a láncolat miatt hitelüket/érvényességüket vesztették, hiszen ezek a fa azon részfáját alkotják, amelyeknek ez a tanúsítvány a gyökere. Hátránya viszont, hogy a különböző CA-k által kiadott tanúsítványok szigeteket alkotnak (ezért említettük az X.509 formátumú tanúsítványok esetén, hogy az egyedi név csak a CA által kibocsátott tanúsítványok között egyedi), mivel nem létezik egy szuper-CA, amely hitelesítené az összes többi CA-t (elméletileg létezhetne, gyakorlatilag azonban ez olyan mértékű centralizáltságot eredményezne, amelyet egyetlen internetes közösség sem kíván) Ezt a problémát általában úgy oldják fel, hogy a CA-k kereszthitelesítik egymást, vagyis kölcsönösen

aláírják egymás úgynevezett gyökértanúsítványait. Ettől a bizalmi modell valamelyest veszít a centralizált jellegéből. A PGP bizalmi modellje egy általános gráffal írható le, amelyben előfordulhatnak akár körök is; ez a gyakorlatban sűrűn elő is fordul. Lényegileg – az alább vázolt „bemutatási esetek” keretein belül – mindenki hitelesítheti mindenki tanúsítványát, létezik az önaláírás mechanizmusa (ezáltal mindenki tekinthető egy különálló CA-nak), továbbá egy kulcsot többen is aláírhatnak.2 A PGP bizalmi modell bevezeti az ún Megbízható Bemutató (Trusted Introducer) és a Meta-Bemutató (Meta-Introducer) fogalmát. Ha A egy Megbízható Bemutatóként írja alá B tanúsítványát, akkor a B által aláírt C-hez tartozó tanúsítványok hitelesek lesznek A számára. Ha azonban A MetaBemutatóként írja alá B tanúsítványát, akkor egyrészt a B által aláírt tanúsítványok hitelesek lesznek A számára

(vagyis B Megbízható Bemutatóvá válik), másrészt ezzel az aláírással feljogosítja B-t, hogy Megbízható Bemutatóként írja alá C tanúsítványait. Ily módon a C által aláírt tanúsítványok nemcsak B, de A számára is hitelesként fogadhatóak el. A különbség végső soron az, hogy a Megbízható Bemutatók nem „hozhatnak létre” újabb Megbízató Bemutatókat. A Megbízható és Meta-Bemutató megnevezések csak PGP-terminológiában használatosak, X.509 alapú rendszerekben ezek „gyökér CA” (root CA) és „alárendelt CA” (subordinate CA) néven ismeretesek. Megjegyezzük még, hogy a PGP modellje még ennél is bonyolultabb: háromféle bizalmi szintet és szintén háromféle hitelességi szintet vezet be, ezek bemutatását hely hiányában a jelen dolgozatban mellőzzük [11]. A decentralizált struktúra következménye, hogy a hibás (például lejárt) tanúsítványok megtalálása, valamint a láncban őket követő tanúsítványok

felfedése és lecserélése meglehetősen nehéz, hiszen a körök miatt a láncok hossza végtelen, másrészt a különböző körök egy vagy több tanúsítványon keresztül egymáshoz kapcsolódhatnak, ezért tulajdonképpen beláthatatlan következményekkel járhat egy jól kiépült, szövevényes tanúsítvány-hálózatban, ha egy vagy több tanúsítvány érvényét veszti. Továbbá egyes rosszindulatú támadók kihasználhatják a hálózat bonyolultságát, és közreműködhetnek egy „személyiséghamisításban”. A modell decentralizált jellege és az előbb vázolt problémák miatt a PGP nem örvend túl nagy népszerűségnek vállalati körökben, 2 PGP-terminológiában ha aláírjuk a kulcsot, akkor „bemutatjuk a kulcsot” (introduce a key), vagy a kulcs „bemutatójává válunk” (introducer of key). 23 ugyanakkor a létrehozójának valószínűleg nem is ez volt a célja: sokkal „életszerűbb”, „Internetszerűbb” modellt kívánt

kidolgozni és magvalósítani, amely jobban illeszkedik az internetes közösségek önszerveződő jellegéhez. 3.4 Nyilvános kulcsú infrastruktúrák A tanúsítványok a bizalom kifejezésének digitális eszközei, és hétköznapi, papír alapú társaikhoz hasonlóan csak egy jól működő háttér-infrastruktúrán keresztül lehet megvalósítani az elvárt funkciókat. Mivel a funkciók sokrétűek, és a megvalósítandó szolgáltatások biztonsági természetűek, a mögöttes infrastruktúra szükségszerűen meglehetősen összetett. Ezt az infrastruktúrát az alkalmazott kriptográfiai módszerek jellemzői miatt nyilvános kulcsú infrastruktúrának (PKI – Public Key Infrastructure) nevezzük. Megjegyezzük, hogy a PKI kifejezést általában az ipari de facto szabványnak tekintett X.509 formátumú tanúsítványokkal kapcsolatban szokták használni, bár az infrastruktúra nem zárja ki más típusú (például PGP) tanúsítványok használatát. A rendszer

számos funkcionális elemet tartalmaz, és ezek nem feltétlenül különülnek el egymástól fizikailag is. Ezért a továbbiakban a rendszert és egyes komponenseinek a funkcióját egy köznapi életből kölcsönzött analógián (az útlevél kiváltásán) keresztül mutatjuk be [12] Természetesen, mint minden analógia, ez sem tükrözi tökéletesen a valóságot, különösen ha szem előtt tartjuk azt, hogy az infrastruktúrák az őket kiépítő/implementáló szervezetek egyedi ízlésének és elvárásainak megfelelően (persze bizonyos határok között) változhatnak. 3.41 Fő funkcionális egységek Tekintsük tehát az útlevél-kérés folyamatát és szereplőit. A kérelem megindításához ki kell tölteni az útlevélkérő lapot; meghatározott szabályrendszer alapján, meghatározott adatokat kell szolgáltatni, s utána a megfelelő hatóság fogadja a kérelmet; ez a hatóság a regisztráló hatóság (RA – Registration Authority). Így az RA

kapcsolja össze a kérelmező fizikai személyét az ily módon létrejött digitális entitással. Az RA ellenőrzi a beérkezett adatok pontosságát, majd továbbítja az elfogadás helyszínére, ahol az útlevelek kiállításra kerülnek (ez a már emlegetett hitelesítés-szolgáltató, vagyis a CA). A hatóság az útlevél kiállításával tanúsítja, hogy az útlevélben szereplő személy – akinek azonosítását a feltüntetett adatok alapján már könnyen el lehet végezni – jogosult elhagyni a Magyar Köztársaság területét. Biztonsági szempontból fontos, hogy az útlevél kérőjének adatai (fénykép, aláírás, különböző személyes adatok) szigorúan ellenőrzötten kerüljenek rá a műanyag utolsó oldalra, s azt olyan módon kell megoldani, hogy azt más ne tudja megvalósítani (ennek felel meg az elkészült tanúsítvány digitális aláírása a CA magánkulcsával). Az útlevél-kérelem feladását, vagy átvételét mindkét fél által

elfogadottan dátumozza a Posta, vagy a fogadóiroda (a TSA – TimeStamping Authority – hitelesnek tekintett időbélyeggel látja el a tanúsítványt). Ha az útlevelünkben szerepel valamiféle egyéb jellemző, attribútum vagy tulajdonság (például az, hogy magán-, szolgálati, vagy diplomáciai az útlevél), akkor ezt a tulajdonságot valamely hatóságnak igazolnia kell (ez az attribútumokat hitelesítő hatóság az Attribute Authority – AA). De az is lehetséges, hogy amennyiben a tanúsítványhoz kapcsolódnak pl aláírási, utalványozási jogkörök, akkor ezeket nem a tanúsítványt kiállító hatóság fogja igazolni, hanem a személyzeti osztály – vagyis az, aki a legpontosabb információval rendelkezik az adott tulajdonság és a személy kapcsolatát illetően. Amennyiben az útlevélkérelmet a hatóság elutasítja, mert szerinte a kérelmezőnek az valamiért nem jár, a kérelmező szerint viszont igen, a vita eldöntéséért a bírósághoz

lehet fordulni. Ezt a szerepet a PKI rendszerben az arbitrátor, a döntőbíró 24 játssza, ő dönthet a hitelesítő és az aláíró közötti vitás kérdésről. Ez lehet egy mindkét fél által elfogadott választott döntnök, de lehet a bíróság is. A kommunikáció során használt kulcs-párok hitelességét bizonyító tanúsítványok lehetnek a felhasználónál is, de – mivel ennek alapján ellenőrzi a kommunikációs partner a hitelességet – széles körben hozzáférhetővé kell ezeket tenni, például úgynevezett tanúsítványtárolókban (CR – Certificate Repository) tárolhatjuk őket. Alapvető cél, hogy ne (csak) a felhasználó tárolja a saját lokális gépén a tanúsítványokat, hanem legyen egy széles körben hozzáférhető központi tanúsítványtároló, ami állandóan elérhetővé teszi a tanúsítványokat. A CR több részre osztható fel: a tanúsítványtároló felhasználói tanúsítványokat tartalmazó részét

tanúsítványtárnak (CD – Certificate Directory) nevezhetjük, míg a már visszavont tanúsítványokat a tanúsítványvisszavonási lista (CRL – Certificate Revocation List) tárolja. Amennyiben valamilyen tulajdonságot is hozzákapcsoltunk a tanúsítványokhoz, és azokat szeretnénk visszavonni, akkor a visszavont tanúsítványokat az attribútum tanúsítvány-visszavonási lista (ARL – Attribute Certificate Revocation List) tartalmazhatja. Általában a tulajdonságok rövid életűek, ezért a tulajdonságokat igazoló tanúsítványok ún rövid élettartamú tanúsítványok (short-lived certificate), ami azt jelenti, hogy a tulajdonság érvényességi idejét a tanúsítvány kibocsátásának pillanatától, vagy az aláírás ellenőrzésétől számított rövid, de meghatározott ideig értelmezzük Emiatt visszavont tulajdonságok listája is lehetséges, de nem feltétlenül szükséges a gyakorlatban Megjegyezzük még, hogy a CR-ek az esetek túlnyomó

részében LDAP protokollt alkalmazó, az ITU X.500 szabványnak megfelelő kiszolgálókként kerülnek megvalósításra; a részletek iránt érdeklődők további részleteket találnak a [14] műben. 3.42 Irányelvek és integráció a meglévő rendszerekkel Maradva a példánál, a tanúsítványokkal kapcsolatos irányelvek, vagyis az úgynevezett hitelesítési szabályzatok (CP – Certificate Policy) megfeleltethetőek annak a törvénynek, ami alapján magyar állampolgár beadhatja az útlevélkérő lapját a hatósághoz. A szolgáltatási szabályzat (CPS – Certificate Practice Statement) pedig a törvény végrehajtási rendeleteként fogható fel, ami már tartalmaz – az általános irányelveken túl – specifikus elemeket is Ez azt jelenti, hogy a CPS már termékfüggő dolgokat is kell, hogy tartalmazzon, szemben a CP-vel, ami általános elvi iránymutatást ad Ebből következően a CPS-t csak az implementálás után lehet elkészíteni. Ha ezt a

szoftvercsomag szállítójától kérjük, akkor az adott szállító a saját termékének ismeretében képes a CPS-t elkészíteni. Ezeket az irányelveket is a CR tartalmazza Természetesen a PKI nem egy öncélú, és nem különálló rendszerként jelenik meg: a PKI elemeit integrálni kell a meglévő információs rendszerbe [14]. Tehát olyan alkalmazások is szükségesek, amelyek használni fogják a PKI rendszer által nyújtott előnyöket (például az elektronikus levelezésben, biztonságos böngészéskor, vagy állományok hiteles letöltéséhez, kódolásához illetve titkosításához), természetesen ezzel egyidőben ezekhez kell igazítani az irányelveket is. A PKI gyakorlati megvalósításánál az egyes funkcionális egységeket több lehetséges helyre is telepíthetjük: elképzelhető, hogy az összes funkció egy helyen valósul meg, de az is lehet, hogy bizonyos funkciókat le kell választani. Ha például egy olyan szervezetről van szó, amelyik egy

központtal rendelkezik, és területileg szétszórt, nagy létszámú telephelyei, alvállalatai vannak, akkor pl. a regisztráló hatóságot célszerű minden nagy alegység személyzeti osztályára telepíteni és ott fogadni a kérelmeket, hiszen a dolgozóról az adott személyzeti osztály rendelkezik a legtöbb személyes információval. A tanúsítványok generálását pedig a központban, egyetlen helyen javasolt elvégezni – a titkos kulcs védelme érdekében gyakran off-line módon, más fizikai védelemmel is ellátott helyen. Megjegyezzük, hogy ha az információs rendszerben már létezik digitális aláírás gyakorlat, ott a CA csak a tanúsítványok kibocsátását végzi. Ahol még nem létezik ilyen, ott a tanúsítványok kibocsátása előtt a felhasználói kulcs-párok generálását és 25 felhasználóhoz történő eljuttatását is meg kell valósítani. Ehhez kapcsolódik az aláírás-létrehozó eszközön az aláírás-ellenőrző adat

elhelyezése funkció Gyakorlatilag egy CA az aláírás-létrehozó adatot két módon teheti rá az eszközre: vagy saját maga generálja és ezek után juttatja el az ügyfélhez, vagy az ügyfél generálja a tanúsítványszolgáltatónál – annak közreműködésével, oly módon, hogy nem juttatja ki a létrehozó adatot a generáló eszközből (ez az úgynevezett „On-Board Key Generation”), mely egyben a tároló eszköz is lesz. Ilyen tároló eszközként manapság jellemzően az úgynevezett USB-tokenek és intelligens kártyák (smartcard) terjedtek el a kereskedelmi jellegű megoldásokban. (Itt jegyezzük meg, hogy a szakirodalomban gyakran találkozni a hitelesítési mechanizmusok kapcsán az intelligens kártyákkal és hozzájuk kifejlesztett protokollokkal. A jelen dolgozatban ezekkel nem foglalkozunk, mivel ezek a mechanizmusok jellemzően azonosítási funkciókat látnak el, és nem azzal a hitelesítésfogalommal kapcsolatosak, amellyel a jelen dolgozat

foglalkozik Hasonló megfontolásból nem foglalkozunk itt a biometrikus azonosítás kérdéskörével sem) 3.43 A PKI-t ért kritikák Az informatikai biztonság témakörében bevett szokás, hogy az új keletű technológiákat hosszú ideig és alaposan elemzik, vizsgálják és tesztelik, így a kezdeti lelkesedést viszonylag sok negatív vélemény „hűtheti le”, amint fény derül az esetleges tervezési/koncepcióbeli illetve implementációs hibákra vagy hiányosságokra. Ebben a fejezetben ezekből mutatunk be néhányat a PKI kapcsán Az informatikai biztonság és kriptográfia területén nagy hírnévnek örvendő Bruce Schneier szerint [15] az informatikában minden évnek megvan a slágertechnológiája, minden év valaminek „az éve”; ilyenek voltak a tűzfalak, később a behatolás-észlelő rendszerek, azután a VPN-ek (Virtual Private Network – virtuális magánhálózat), most pedig a PKI. Nem kétli a technológia hasznosságát, de nincs

meggyőződve afelől, hogy a vállalati döntéshozók valóban azért építenek ki PKI-t, mert ténylegesen szükségük van rá az általuk felmért biztonsági kockázatok tükrében, hanem egyszerűen azért, mert például a konkurens cégnél már kiépítettek PKI-t, vagy mert a PKI megoldásokat szállító cégek marketingosztálya jól végezte a dolgát. A PKImegoldásokat szállító cégek (Schneier szerint) azt hangoztatják, hogy az elektronikus kereskedelemnek mindenképpen szüksége van PKI-re, hogy igazán felvirágozhasson – a szerző szerint ez éppen fordítva van: a PKI-szállítóknak van inkább szüksége az elektronikus kereskedelemre ahhoz, hogy igazán felvirágozhassanak. Biztonsági megoldások esetén már szinte közhelyszámba megy annak hangoztatása, hogy a biztonság egy lánc, és minden lánc csak annyira erős, mint a leggyengébb láncszem; ez pedig majdnem mindig az ember. A nyilvános kulcsú módszerek kriptográfiailag erős biztonságot

valósíthatnak meg, de az egész mit sem ér, ha az emberi tényező hibájából a rendszer megsérül A közelmúlt egyik nagy port felvert eseménye [16] is erre vezethető vissza: a VeriSign nevű, világszerte elismert hitelesítésszolgáltatóhoz besétált néhány személy, és Microsoft alkalmazottnak kiadva magukat tanúsítványt igényeltek. Valószínűleg emberi mulasztás miatt állításukat senki nem ellenőrizte, és így megkapták a tanúsítványt. Az ügy kiderültét követően a Microsoft vezetősége körlevélben volt kénytelen tájékoztatni a Microsoft termékek felhasználóit, hogy bizonyos tanúsítványok kompromittálódhatnak, ezért mindenki a saját felelősségére fogadjon el Microsofttól érkező tanúsítványokat. Ez meglehetősen komoly blamázs volt mind a Microsoft, mind pedig a VeriSign számára, főleg ha figyelembe vesszük, hogy e két cég által kibocsátott tanúsítványok valószínűleg mindannyiunk Internet böngészőjének

tanúsítvány-listájában „beégetve” szerepelnek, vagyis a böngészőnk feltétlenül hitelesként fogadja el az ezektől a cégektől származó tanúsítványokat. Egy további aspektus lehet, hogy az ilyen „beégetett” tanúsítványok biztonsági szempontból hogyan minősíthetőek, illetve hogy etikus-e egyáltalán ez a gyakorlat. Hosszan sorolhatnánk még a kritikákat, az ezek iránt érdeklődők bőséges irodalmat találhatnak a szakirodalomban és az Interneten; ezek közül néhányat felsoro- 26 lunk az irodalomjegyzékben (ilyen például a [17] munka). Szabadjon azonban még egy fontos aspektust megemlítenünk, amely azzal kapcsolatos, hogy a jó technológia sosem lehet elég jó akkor, ha hibás vagy hiányos az implementációja. Ha konkrét példát akarunk említeni, a későbbiekben bemutatásra kerülő SSL protokollt alkalmazó Netscape böngészők korai verzióinak hiányosságai között szokták felsorolni a szakirodalomban, hogy bár

ismeri és használja a tanúsítványokat, nem használja ki a tanúsítvány-visszavonási listák nyújtotta biztonsági szolgáltatásokat (bár ez inkább az SSL hiányossága). Természetesen nem tudni, hogy ez a véletlen folytán alakult-e ki, esetleg szándékos tervezési folyamat következménye, de ily módon komoly biztonsági támadásoknak lehetnek kitéve az ilyen böngészők használói [17]. Igazságtalan lenne, ha a PKI-t ért negatív kritikák mellett nem sorolnánk fel pozitív jellemzőket is, most mégis ezt tesszük. Ennek oka egyszerű: a PKI nagy népszerűségnek örvend, és igazán komoly biztonsági hiányosságokat sem tudtak találni benne, legalábbis a tiszta, szabványos formájában. Jól bevált, stabil módszereken alapszik, és a szabványok modulárisak, így a jövő eredményei beépíthetőek lesznek a rendszerbe. Sokszor éri támadás amiatt, hogy például csak a személyek hitelesítésére használható, jogosultságvizsgálatra nem, de

az informatikában nem meglepő, ha egy megoldás csak egyetlen meghatározott problémára megoldás (arra viszont tökéletesen alkalmas), és vannak olyan feladatok, amelyet egy másik technológiával lehet hatékonyan, „jól” megoldani. Szokás azt állítani, hogy a PKI nem más, mint olyan komponensek és szabályok összessége, melyekkel kiadhatók, kezelhetők és visszavonhatók a digitális tanúsítványok. Az esetek túlnyomó részében azonban a szolgáltatások biztonságos módon való nyújtásához és igénybevételéhez (például a hálózati végpontok közötti biztonságos kommunikációhoz és a jogosultságvizsgálathoz) nem magára a PKI-ra van szükségünk, hanem csak a tanúsítványokra, és ezekhez mintegy „szükséges rosszként” kell felépítenünk az említett mögöttes infrastruktúrát. A dolgozat további részében a fent említett hálózati szolgáltatások nyújtása kapcsán felmerülő problémákat, és az ezeket hitelesítés

és digitális tanúsítványok felhasználásával megoldó módszereket mutatunk be, mégpedig oly módon csoportosítva, hogy a TCP/IP modell mely rétegén valósítják meg a személyek, szervezetek, szolgáltatások, vagy esetleg IP címek hitelesítését. 27 4. Hitelesítés a hálózati rétegen Korábban már említettük, hogy a biztonságos kommunikáció megteremtéséhez nem elegendő önmagában az elküldendő adatok titkosítása, szükség van hitelesítésre is, hogy biztosak lehessünk benne: valóban azzal folytatunk kommunikációt, akivel szeretnénk. Mivel az esetek jelentős részében esetleg nem a kommunikációs partner személye érdekel minket, mint az előző példákban, hanem az, hogy hol, milyen IP címen helyezkedik el a partner, itt hitelesítés alatt jellemezően a kommunikáló végpontok, illetve ezek IP címének hitelesítését értjük. Már a kapcsolatok felépítése sem egyszerű feladat egy olyannyira nem biztonságos közegen, mint

amilyen az Internet, mindamellett lehetséges: ehhez a fentiekben bemutatott nyilvános kulcsú módszereket használhatjuk fel. A nyilvános kulcsú kriptográfia módszerei azonban számításigényes, költséges műveletek, ezért nem mindegy, hogy például a titkosítást a TCP/IP rétegmodell (illetve az ISO/OSI hivatkozási modell) melyik rétegen végezzük el. A biztonságot célszerű a rétegszerkezetben a lehető legmélyebben megvalósítani. Triviálisan adódna a fizikai réteg vagy az adatkapcsolati réteg; figyelembe kell vennünk azonban, hogy az Interneten keresztül utazó csomagok valójában több, különböző protokollt és különböző csomagformátumot alkalmazó fizikai hálózaton (Ethernet, Frame Relay, ATM stb.) keresztül haladnak át, így a csomagokat minden fizikai hálózathatáron dekódolni majd újra titkosítani kellene Még ennél is fontosabb, hogy a csomag továbbításához használt információk (például a feladó és a címzett IP

címe) az IP csomag fejrészében van elhelyezve, így ezek a fizikai hálózati csomagok/keretek titkosított adatrészébe kerülnének, ami miatt az útválasztóknak is dekódolniuk és ismét titkosítaniuk kellene a csomagot a továbbküldéshez, ez pedig elfogadhatatlanul nagy terhelést róna rájuk. Mivel a továbbításhoz feltétlenül szükséges információk az IP csomagban helyezkednek el, célszerűnek látszik, hogy a csomagokat a hálózati réteg szintjén titkosítsuk és hitelesítsük. (Megjegyezzük, hogy a dolgozat további részében az ISO/OSI hivatkozási modell helyett a TCP/IP protokollszerkezet rétegeire fogunk hivatkozni. Ennek az elsődleges oka az, hogy az internetes kommunikáció legtöbbször olyan hálózati szegmenseken zajlik, amelyek ez utóbbi protokolljait alkalmazzák. Az előbbi protokolljait használó szegmensek a gyakorlatban rendszerint olyanok, amelyek kiépítése és fenntartása, ezért használata is költséges, viszont magasabb

szintű biztonságot nyújtanak. Ezen tulajdonságok egyike sem kedvez igazán a széleskörű, kommunikációs célokra való felhasználásuk elterjedésének.) Ezeket a funkciókat több protokoll is megvalósítja, ezek közül a legjobban kidolgozottabbakat mutatjuk be a következő szakaszokban. 4.1 Kulcskezelés A hálózati szinten megvalósított biztonsági protokollok (csakúgy, mint a későbbiekben bemutatásra kerülők is) nyilvános kulcsú kriptográfiai módszereket alkalmaznak, ezért nyilvános kulcsokra van szükségük a küldő és a csomagok azonosításához és hitelesítéséhez is. Ezeknek a kulcsoknak a karbantartása, kezelése (ami alatt a kulcsok generálását, kiosztását, tárolását és törlését értjük) nem triviális feladat, ezért jónéhány protokoll született ezek megvalósítására, amelyeket az alábbiakban veszünk sorra [18]. A biztonságos kapcsolatok felépítése általában egy azonosítási adatcserével kezdődik; ezt

követően egy kulcscserélő mechanizmus biztosítja a forgalom védéséhez szükséges biztonsági kulcsokat, ily módon a hitelesítés kiterjed a kommunikáció hátralevő részére is (természetesen a kulcscserét is hiteles módon kell elvégezni). A kezdeti hitelesítést és a kulcscserét egy úgynevezett hitelesített kulcscserélő protokoll biztosítja 4.11 A kulcscserélő protokollok tulajdonságai 28 Diffie, Van Oorschot és Wiener definiálták a biztonságos hitelesített kulcscserélő protokollok fogalmát, amihez két feltételt állítottak fel: egyrészt amikor A elfogadja B azonosságát, a kettőjük közben váltott üzenetek megfelelnek egymásnak (vagyis az üzenetek nem módosultak az átvitel során), másrészt pedig lényegileg lehetetlen kettőjükön kívül más számára a kulcs megtalálása. Az előző kettőn kívül szokás további elvárásokat is definiálni Ilyen például a tökéletes továbbított biztonság (PFS – Perfect Forward

Secrecy), vagyis ha a hosszútávú kulcsot (például a mester kulcsot) egy támadó megszerzi, akkor azzal ne legyen képes a rövidtávú kulcsok (például viszonykulcsok) megszerzésére is. Ezzel együtt elvárás szokott lenni, hogy az egyik viszonykulcs feltörésével ne lehessen következtetni se a mester kulcsra, se a többi viszonykulcsra További elvárás lehet az úgynevezett direkt hitelesítés feltétele, miszerint a protokoll végrehajtása végén a megosztott titok (például a viszonykulcs vagy valamilyen szimmetrikus kulcs) generálásához használt értékek hitelesítettek, illetve mindkét fél bebizonyította, hogy ismerte a viszonykulcsot. A felsoroltakon kívül számos elvárás létezhet még, ezekkel nem foglalkozunk részletesebben. 4.12 A Diffie – Hellman nyilvános kulcscserélő algoritmus Ez a névadók által 1976-ban kidolgozott protokoll lehetővé teszi két fél számára, hogy anélkül hozzanak létre egy megosztott (közös) titkot, hogy

bármiféle előzetes ismerettel rendelkeznének egymásról. Ezt a megosztott titkot használhatjuk azután egy vagy több további kulcs létrehozására. Az algoritmus a következő lépésekből áll: - A és B megegyezik egy nagy n prímszámban és egy g számban, ahol g és n relatív prímek. Ez a két egész nyilvánosságra hozható - A választ egy nagy „a” véletlenszámot, amelyet titokban tart, és kiszámítja az ő nyilvános értékét, azaz az A = ga (mod n) értéket. B hasonló módon generálja „b”-t és a B = gb (mod n) nyilvános értékét. - Elküldik egymásnak az A és B nyilvános értékeiket. - A kiszámítja a KAB = Ba (mod n) értéket, B pedig kiszámítja a KBA = Ab (mod n) értéket. Ekkor a kettejük közös kulcsa a KAB = KBA = gab (mod n) érték lesz A fenti algoritmus azonban önmagában támadható a már említett közbeékelődéses támadási módszerrel, amit a már szintén említett módszerekkel védhetünk ki. 4.2 Hitelesített

kulcscserélő algoritmusok az IP rétegen Korábban már említettük, hogy a nyilvános kulcsú műveletek még a nagy (manapság átlagosnak mondható) feldolgozási kapacitású számítógépek esetén is meglehetősen számításigényesnek tekinthetőek, amit a gyakorlatban alkalmazott protokollok oly módon védenek ki, hogy az egyeztetett titokból további szimmetrikus kulcsokat generálnak, amelyekkel a kapcsolat tulajdonképpeni védelmét valósítják meg. A következő pontokban ilyen protokollokat mutatunk be részletesebben 4.21 A SKIP protokoll A SKIP (Simple Key management for Internet Protocols) példa az olyan protokollokra, amelyeknél nincs szükség semmilyen kapcsolat előzetes felépítésére, és nincs szükség semmiféle üzenetváltásra sem, mielőtt titkosított csomagokat küldhetnénk. Minden egyes csomag magával hordozza a visszafejtéséhez szükséges információt. Ezen kívül a megosztott titkot a Diffie-Hellman algoritmus használatával

generáljuk hitelesített nyilvános kulcsokkal, ezért az egyetlen megszorítás az, hogy mindkét félnek 29 rendelkeznie kell egy saját hitelesített Diffie-Hellman nyilvános értékkel, amelyek felhasználásával kiszámíthatnak egy megosztott titkot. A másik fél nyilvános kulcsának megszerzéséhez felhasználhatunk valamiféle könyvtár-szolgáltatást, esetleg tanúsítványok elküldését. Tegyük fel, hogy (az előbbi jelöléssel) A és B a két kommunikálni szándékozó fél, és a privát és nyilvános értékeik ebben a sorrendben „a” és „b”, illetve ga (mod p) és gb (mod p). A megosztott titkot mindkettőjük úgy számítja ki, hogy a partnerük nyilvános kulcsát emelik (hatványozás) a saját magánkulcsuknak megfelelő hatványra, azaz meghatározzák a (gb (mod p))a = (ga (mod p))b értékeket. Ekkor a gab (mod p) értéket nevezzük a hosszútávú megosztott titoknak, és ezt használjuk a Kab titkos kulcs származtatására A

gyakorlatban gab (mod p) tipikusan legalább 1024 bit hosszú, a Kab titkos kulcs hossza pedig a 40-256 bites tartományba esik A SKIP-ben a Kab titkos kulcs a gab (mod p) érték alsó bitjeiből (lower weight bit) áll. A Kab valójában egy kulcstitkosító kulcs, amit kizárólag arra használunk, hogy sokkal rövidebb élettartamú kulcsokat titkosítsunk vele; ilyen kulcs például a Kp csomagkulcs, amit viszont két másik kulcs létrehozásához használunk: az egyikkel titkosítjuk, a másikkal pedig hitelesítjük az IP csomagot (vagy a csomagok egy részét). Annak, hogy a titkosított csomagküldést megelőzően nincs szükség kommunikációra, ára van: megnő az egyes csomagok mérete. Valójában egy új fejrész (a SKIP fejrész) kerül a csomag elejére; ebben továbbítják a (Kab-vel titkosított) Kp kulcsot, valamint jelzik a felhasznált algoritmust. A protokollnak önmagában lenne még egy hátránya: nem biztosítja a PFS tulajdonságot: ha a támadó

megszerzi Kab-t, a múltban használt összes Kp kulcs kompromittálódik. Ezért kifejlesztettek a SKIP-hez egy kiterjesztést (ez az úgynevezett SKIP PFS), ami a Diffie-Hellman kulcscsere egy „rövidéletű” változatát alkalmazza, azaz a nyilvános kulcsok élettartama rövid. Ezek a rövid élettartamú kulcsok váltják fel a hosszútávú megosztott titkokat Ekkor viszont a vonatkozó nyilvános kulcsokat tartalmazó tanúsítványok cseréjére van szükség, amihez az itt bemutatásra nem kerülő CDP (Certificate Discovery Protocol) protokollt [61] és a Kab kulcsot használjuk fel. Ily módon az eredeti SKIP-től eltérően szükségessé válik néhány üzenetváltás a felek között a titkosított csomagküldést megelőzően 4.22 A PHOTURIS protokoll A SKIP protokollal ellentétben a Photuris egy kapcsolat-alapú protokoll abban az értelemben, hogy az opciók egyeztetéséhez és a kulcsok generálásához meghatározott számú cserét tartalmaz, melyek

megelőzik a titkosított üzenetek cseréjét. Ez a protokoll is egy Diffie-Hellman kulcscserén alapuló megosztott titok generálásán alapul, de ez a titok rövid élettartamú, és a kommunikáció hátralevő részének védelméhez szükséges viszonykulcsok generálására használjuk. A közbeékelődéses támadás kivédése céljából a titok generálásához használt értékek cseréjét az értékek hitelesítése követi, hosszútávú kulcsok alkalmazásával. Mivel ezeket a kulcsokat csak hitelesítésre használjuk, a Photuris rendelkezik a PFS tulajdonsággal. A Difife-Hellman kulcscsere egyik hátránya, hogy a rendszererőforrások tekintetében költséges műveleteket igényel, ami miatt sérülékenyé válik az úgynevezett szolgáltatásmegtagadási (DoS – Denial of Service), más néven elárasztásos támadásokkal szemben. Az ilyen fajta támadás ellen a Photuris ún sütik (cookie) kicserélését alkalmazza a Diffie-Hellman értékcserét

megelőzően. A sütik értéke függ a résztvevő felektől (különösen az IP címüktől), valamint az UDP port-számtól. Ennek célja, hogy megakadályozza a támadót abban, hogy érvényes sütit szerezzen, és azt arra használja, hogy véletlenszerű IP címekről és/vagy portokról indított kérésekkel árassza el az „áldozatot”. Ezen kívül nem lenne kívánatos, ha a támadó olyan sütiket generálhatna, amelyeket egy hálózati entitás a sajátjaként azonosítana, ezért az entitás lokális titkos információkat használ fel a sütik generálásakor és a későbbi ellenőrzések során. A protokoll a következő három lépésből áll: 30 - Sütik kicserélése: ezzel elkerülhetőek az egyszerűbb DoS támadások. Mindkét résztvevő fél generál egy sütit, és ezeket elküldik a másik félnek egy üzenetben. - Nyilvános értékek kicserélése: ezekkel generálható egy megosztott titok. - Azonosítók cseréje: a felek ezzel azonosítják

önmagukat a másik fél felé, és ellenőrizhetik az előző lépés során kicserélt értékek hitelességét. Ennek a cserének a bizalmasságát a megosztott titok és a sütik alapján származtatott magánkulcsok (és más kulcsok) biztosítják. A későbbiek során további üzenetváltásra is van lehetőség, például a viszonykulcsok és más biztonsági paraméterek megváltoztatása céljából. Ezeket az üzeneteket szintén a harmadik lépésben vázolt módszerek biztosítják. A fenti üzenetváltásokkal egyidejűleg a kommunikáló felek megegyeznek a megosztott titok generálási módszerében, valamint a biztonságos kapcsolat során használt biztonsági paraméterekben is. 4.23 A SKEME protokoll A SKEME egy a Photuris kiterjesztéseként 1996-ban kidolgozott kapcsolatalapú protokoll. A Photurissal ellentétben azonban nem definiálja a protokoll egy meghatározott menetét, hanem változatos kulcscserélő módokat biztosít Annyiban mégiscsak hasonlít

elődjére, hogy a SKEME alap módja is nyilvános kulcsok használatán és a Diffie-Hellman algoritmus megosztott titok-generálásán alapszik. Viszont ez a protokoll nem korlátozódik a nyilvános kulcsok használatára: lehetővé teszi az előzetesen megosztott (pre-shared) kulcsok használatát is. Ezek a kulcsok megszerezhetőek manuális kulcskiosztás során, de akár egy kulcskiosztó központ (KDC – Key Destribution Center) „közvetítője” (intermediary, Tannenbaumban megnézni) által is (ilyet alkalmaz például a későbbiekben bemutatásra kerülő Kerberos is). A KDC lehetővé teszi, hogy a kommunikáló felek egy megbízható harmadik fél közvetítőjén keresztül osszanak meg valamilyen titkot. Ha ezt a titkot csak a Diffie-Hellman titok hitelesítésére, és nem közvetlenül viszony kulcsként használjuk, akkor csökken annak a szükségessége, hogy megbízzunk a KDC-ben. Ezen túlmenően a SKEME lehetővé teszi a gyorsabb kulcscserét azáltal,

hogy nem használja a Diffie-Hellman algoritmust akkor, amikor nem kívánjuk meg a tökéletes továbbított biztonságot A SKEME lényegileg négy különböző módban működhet: - Alap mód, amely nyilvános kulcsokon alapuló kulcscserét tesz lehetővé, és biztosítja a PFS tulajdonságot a Diffie-Hellman módszer által; - Nyilvános kulcsokat használó kulcscserélési mód, de a Diffie-Hellman algoritmus nélkül; - Előre kiosztott kulcsok és a Diffie-Hellman algoritmus használatán alapuló kulcscserélési mód; valamint - Kizárólag szimmetrikus algoritmusokon alapuló gyors kulcs-újrakiosztási (fast rekeying) mechanizmus. A SKEME ezen kívül három fázisból áll: - A SHARE fázisban a felek úgynevezett fél-kulcsokat (half-keys) cserélnek, melyek a saját nyilvános kulcsukkal vannak titkosítva; ezeket a fél-kulcsokat használják fel egy K titkos kulcs kiszámítására. Ha anonimitást akarunk biztosítani, a két fél azonosítóját is titkosíthatjuk

Ha már létezik közöttük megosztott titok, ez a fázis kihagyható - Az EXCH cserélési fázisban a kiválasztott módtól függően vagy Diffie-Hellman nyilvános kulcsok cseréje, vagy pedig véletlenszerű üzenetek (nonce) cseréje történik meg. A Diffie-Hellman megosztott titok kiszámítása csak a cserék befejeződését követően végezhető el - A nyilvános értékek vagy véletlenszerű üzenetek hitelesítése az AUTH fázisban történik meg, a SHARE fázisban kialakított titkos kulcs felhasználásával. 31 Megjegyezzük, hogy a három fázisban váltott üzenetek nem feltétlenül követik a leírás fenti sorrendjét; a gyakorlati megvalósításokban szokás ezeket egymással kombinálni, hogy minimalizáljuk a váltott üzenetek szükséges számát. Ezen kívül egy a SHARE fázist megelőző további fázist, az úgynevezett COOKIES fázist is bevezethetünk a DoS támadások elleni védekezésként, a Photurisban bevezetett süti-mechanizmus

alkalmazásával. 4.24 Az Oakley protokoll Az Oakley egy a SKEME protokollal sok közös vonást mutató kulcscserélő protokoll: több módban működhet, sütiket használ, és nem követeli meg a Diffie-Hellman megosztott titok kiszámítását a protokoll befejeződését megelőzően. Az előzőekben bemutatott protokolloktól abban különbözik, hogy explicit módon teszi lehetővé a felek számára, hogy megállapodjanak a felhasználandó kulcscserélési, titkosítási és hitelesítési mechanizmusokban. Az Oakley protokoll tényleges célja az volt, hogy lehetővé tegye a felek számára a cserék védelméhez használt paraméterek (például a kulcs neve, a titkos kulcs, a felek azonosítói, a titkosítási és hitelesítési algoritmusok vagy a hash függvények) biztonságos módon való megosztását. A protokollban több opció is létezik: a hagyományos Diffie-Hellman kulcscserén kívül egy régi kulcsból származtathatunk egy új kulcsot, illetve kulcsokat

titkosítással oszthatunk szét; ezeknek az opcióknak az eredménye, hogy a protokoll több módot ismer. Az üzenetcserét kezdeményező fél az első üzenetben annyi információt határozhat meg, amennyit csak akar. A másik fél viszont a válaszban annyi információt biztosít, amennyit ő akar A párbeszéd addig folytatódik, amíg elérik a kívánt állapotot Az egyes üzenetek által tartalmazandó információ mennyiségének megválasztása a választott opciótól (állapotnélküli sütik, azonosító-védelem, vagy PFS használata, letagadhatatlanság stb.) függ A protokoll három komponense a következő: - Sütik cseréje (opcionálisan állapot nélkül); - Diffie-Hellman nyilvános értékek cseréje (opcionális); és - Hitelesítés (opciók: anonimitás, PFS az azonosítókra, letagadhatatlanság). A protokoll részletes leírása az RFC 2412 [19] dokumentumban található meg. Hátravan még a jelenlegi egyik legszélesebb körben alkalmazott és

legkifinomultabbnak tartott kulcscserélő protokoll, az IKE (Internet Key Exchange), amely ötvözi az eddigiekben bemutatott protokollok szinte minden előnyét, azonban a részletes tárgyalását megelőzően meg kell ismerkednünk azzal a protokollal, amely tulajdonképpen „életre hívta” az IKE-ot: ez pedig nem más, mint az IPSec (Internet Protocol Security) protokoll, vagyis a biztonságos Internet protokoll. 4.3 Az IPSec protokoll A CERT (Computer Emergency Response Team) az 1998. évi jelentésében 1300 biztonsági incidenst említett, ezek közel 20000 kiszolgálót érintettek [20]. A leggyakoribb támadásfajta az IP-címhamisítás (IP spoofing) volt, vagyis a támadó meghamisítva az IP csomagban a feladó IP-címét olyan kiszolgálókhoz és alkalmazásokhoz férhetett hozzá, amelyek IP cím alapján azonosították a felhasználókat Az IPSec protokoll létrejötte tulajdonképpen ennek köszönhető, ezen támadások kivédésére dolgozták ki. Ez olyannyira

jól sikerült, hogy az IETF (Internet Engineering Task Force) nemcsak egészében, hanem részenként is elfogadta (ezek részletes leírásai megtalálhatóak az RFC 2746, RFC 2401, RFC 2402, RFC 2406 és RFC 2104 [21] számok alatt, ezek az idők során valószínűleg tovább bővültek). AZ IPSec az egyik legteljesebb, legalaposab- 32 ban kidolgozott szabványos protokollkészlet, amely biztosítja az adatok hitelességét, integritását és bizalmasságát, miközben az adatok a kommunikációs végpontok között utaznak az IP-alapú hálózatokon keresztül. 4.31 Kapcsolat-alapú kapcsolat nélküli protokoll Az IP kapcsolat nélküli protokoll, vagyis a csomag elküldését megelőzően a küldő nem győződik meg afelől, hogy a fogadó elérhető-e a hálózaton, és a fogadó nem küld nyugtát a csomag fogadásáról; a kapcsolat felépítése és a forgalom szabályozása az IP feletti TCP protokoll feladata. A TCP végzi a fogadott csomagok sorbarendezését is, a

TCP csomagok sorozatszáma alapján. Az IP csomagok is rendelkeznek ugyan egy 16 bites sorozatszámmal, de ha a csomag útja során a csomagot több darabra kell bontani, az utód-csomagok ugyanazt a sorozatszámot „öröklik”, ami nem alkalmas a csomagok egyértelmű azonosítására, lehetőséget biztosítva a támadóknak az ún. csomagismétléses (replay) támadásra: a támadó másolatot készít egy-egy elfogott csomagról, majd ezeket kis késleltetéssel újra elküldi A hatás kiszámíthatatlan, az alkalmazástól és a TCP megvalósításától függően megbéníthatja a kapcsolatot Ennek elkerülésére az IPSec csomagokban bevezettek egy 32 bites SN (Serial Number) sorozatszámot (ezzel egyedileg azonosítható minden IPSec csomag), és egy ablak alkalmazásával az adott sorozatszámnál kisebb sorozatszámú csomagokat eldobják. Ez javít a kommunikáció biztonságán, azonban nem oldja meg a biztonságos kapcsolat felépítésének problémáját, mivel ahhoz

hitelesíteni kell a végpontokat, valamint a titkosításhoz és hitelesítéshez használt kulcsokat továbbítani, de legalábbis egyeztetni kell. Ehhez az IPSec protokoll bevezeti a Biztonsági Kapcsolat (SA – Security Association) fogalmát: az RFC 2408-ben leírtak szerint „az SA egy olyan kapcsolat két vagy több entitás között, amely leírja, hogy az entitások hogyan fogják felhasználni a biztonsági szolgáltatásokat a biztonságos kommunikáció során”. Az SA egyirányú logikai kapcsolat két IPSec végpont között. Minden SA rendelkezik egy egyedi 32 bites azonosítóval (SPI – Security Parameters Index) Ezeken kívül a végpont nyilvántartja minden SA esetén: a címzett IP címét; az előbb említett SN sorozatszámszámlálót; egy túlcsordulásjelzőt (ha a sorozatszám túlcsordul, az SA-t le kell bontani, és egy újat kell felépíteni); a titkosítási vagy hitelesítési mód jellemzőit (tikosító és hitelesítő algoritmusokat, kulcsokat

stb.); valamint az IPSec alkalmazási módját (transzfer vagy tunnel mód; erről a későbbiekben lesz szó). A végpont feladata az SA kapcsolatok felépítése és az IP forgalomhoz való hozzárendelése: normális esetben egy kétirányú IP kapcsolathoz két SA tartozik, de lehetőség van egy IP kapcsolat több SA-hoz rendelésére, illetve több kis forgalmú IP kapcsolat összefogható egyetlen SA-ba. Ezeket az SPD (Security Policy Database) adatbázisban tárolja, csakúgy, mint a forgalomhoz tartozó csomagok normál (IP) vagy IPSec módon való kezelésére vonatkozó bejegyzést. 4.32 Az IPSec csomagok szerkezete Az IPSec biztonságát elsősorban az adja, hogy oly módon alakítja át az IP csomagokat, hogy a csomag tartalmának tikosításán és/vagy hitelesítésén keresztül a végpontot is hitelesíti. Ennek megvalósításához kétféle lehetőséget kínál: a hitelesítő AH (Authentication Header) fejrész és a titkosító ESP (Encapsulating Security

Payload) beágyazás alkalmazását. Az AH nem titkosítja, csak hitelesíti az eredeti IP csomag tartalmát, az ESP pedig mindkét feladatot ellátja Az AH fejrész tartalmazza a csomag tartalmát hitelesítő hash lenyomatot (amely a 2. fejezetben leírt üzenetpecsét-módszerek valamelyikével készült az eredeti csomagról a küldést megelőzően), és az eredeti IP csomag fejrésze és adatrésze közé kerül (3 ábra). A HMAC-nek (Hash Message Authentication Code) nevezett hash függvénnyel 33 készült lenyomatba nemcsak az IP csomag adatrésze kerül bele, hanem az AH és az IP fejrész is. Eredeti IP fejrész AH fejrész Eredeti adatrész 3. ábra: Az IPSec AH csomag (Forrás: [59]) Az ESP egy fejrészt és két lezáró blokkot illeszt az IP csomaghoz; az első szükséges a titkosításhoz, a második pedig az (opcionális) hitelesítéshez. A fejrész elhelyezkedése attól függ, hogy az előbb említett transzport vagy tunnel módok melyikét alkalmazzuk az

SA kapcsolat során (4 ábra) Transzport Eredeti IP ESP mód fejrész fejrész Eredeti ESP ESP hiteadatrész záróblokk lesítő blokk titkosított hitelesített Eredeti Tunnel Új IP ESP Eredeti ESP ESP hiteIP fejrész mód fejrész fejrész adatrész záróblokk lesítő blokk titkosított hitelesített 4. ábra: Az IPSec ESP csomagok (Forrás: [59]) Transzport módban csak az eredeti IP csomag tartalmát tikosítjuk, és az elé, de az IP fejrész mögé kerül az ESP fejrész; az eredeti IP fejrész változatlan marad. A támadó nem fér hozzá a csomag tartalmához, bár a fejrész alapján valamelyest elemezheti a forgalmat, ami ebben a módban általában végpontok között zajlik (ügyfél – kiszolgáló és kiszolgáló – kiszolgáló kommunikációk során). Az úgynevezett tunnel (vagyis „alagút”) módban az IPSec egy új IP csomagot készít, ennek tartalma a teljes eredeti csomag lesz, titkosítva. Ily módon az eredeti IP cím nem változik meg a csomag

útja során, sőt, az útválasztók nem is tudnak róla, mintha valóban egy alagúton keresztül utazna, ráadásul az új IP fejrész nem ad lehetőséget a forgalom elemzésére. Ez persze csak akkor érvényes, ha a tunnel módot nem végpontok között alkalmazzuk, hanem például tűzfalak, proxyk vagy útválasztók között; fontos tervezési szempont viszont, hogy ilyenkor a titkosítás és visszafejtés is a hálózati eszközre hárul. Ekkor azonban egyszerűbbé válik az IPSec konfigurálása, a kulcskiosztás és a kulcskezelés, mint a végpontok esetén. Megjegyezzük az IPSec csomagok szerkezetével kapcsolatban, hogy azok tartalmazhatnak AH fejrészt vagy ESP fejrészt, de egyszerre mindkettőt nem. 4.33 Az IKE protokoll Az IPSec protokollkészletének komponensei közül az utolsó a már emlegetett IKE, ami a kulcskezelést és a biztonsági kapcsolatok kezelését is biztosítja. Az IPSec lényegileg arra használja az IKE protokollt, hogy egyszerűbbé tegye

és automatizálja az SA-k felépítését és a kulcscserét az adatokat cserélő felek között. A kulcsok használata 34 biztosítja, hogy csak az üzenet küldője és fogadója férhessen hozzá az üzenethez. Az IPSec megkívánja, hogy a kulcsokat gyakran újrageneráljuk vagy frissítsük, hogy a felek biztonságosan kommunikálhassanak egymással. Az IKE kezeli a kulcsfrissítési folyamatot; viszont a felhasználó szabályozhatja a kulcs erősségét és a frissítés gyakoriságát. Az IKE az egyik legjobban kidolgozott, és talán ezért is az egyik legelterjedtebb kulcscserélő protokoll a hálózati rétegen. Ezt annak is köszönheti, hogy a korábbi protokollok „keveréke”: alkalmaz például az Oakley protokollban definiált módok közül néhányat, valamint átvette a SKEME-től a nyilvános kulcsok hitelesítésre való használatát és a kulcsok véletlenszerű adatok cseréjén keresztüli gyors kulcs-újrakiosztásási eljárását. Az IKE egy másik

szabványos protokollt használ fel, az ISAKMP-t (Internet Security and Key Management Protocol) [22], amely nem írja elő a kulcscsere algoritmusát, hanem – mint keretrendszer – olyan üzenetkészletet tartalmaz, amellyel többféle kulcscsere is elvégezhető. A kulcscseréhez mindkét oldal először létrehoz egy-egy nyilvános-privát kulcs-párt, és abból a nyilvános kulcsot elküldi a másik félnek. Ezután a csomagtitkosításhoz használt titkos kulcsot ezzel a nyilvános kulccsal titkosítva továbbítják. Ha a hitelesítés meg van oldva, akkor ez elég biztonságos eljárás lehet, főleg ha a kulcsok rendszeresen lejárnak, vagyis cserélik őket. A hitelesítéshez a fent említett PKI-tanúsítványok használhatóak. Elképzelhető lehet egy olyan forgatókönyv, amikor a nyilvános kulcsot az azonosítóval együtt nem a másik oldalnak küldik el, hanem a hitelesítő hatóságnak, például a saját magánkulcsával titkosítva. Ha a CA a küldő

nyilvános kulcsával vissza tudja azt fejteni, akkor az csakis a küldőtől jöhet, és ekkor a CA a saját digitális aláírásával ellátva küldheti el azt a másik oldalnak. 4.331 Módok és fázisok Az IKE kétfázisú folyamatként működik. Az első fázis felépíti az aktuális IKE SAkat, lényegében a titkosítási és hitelesítési kulcsok cseréjével foglalkozik A második fázis felépíti a biztonságos adatátviteli csatornákat, nevezetesen az IPSec SA-kat. A protokoll négy módot használ: a fő módot (Main Mode), az agresszív módot (Agressive Mode), a gyors módot (Quick Mode) és az új csoport módot (New Group Mode). A fő mód és az agresszív mód az 1 fázisban használatosak, míg a gyors mód egy 2. fázisú üzenetcsere Az új csoport mód egy kicsit eltér ezektől: se nem 1 fázisú, se nem 2. fázisú üzenetcsere, viszont csak akkor hajtódhat végre, ha már létezik egy felépített ISAKMP SA; arra használjuk, hogy egy új csoportot

egyeztessünk a későbbi Diffie-Hellman cserékhez. Az 1. fázis során az IKE a következő attribútumokat egyezteti (és később ezeket fogja használni): egy titkosító algoritmus, egy hash függvény, egy hitelesítési eljárás, és egy Diffie-Hellman csoport. Az 1 fázis végén három kulcsot generálunk: egyet-egyet a titkosításhoz, a hitelesítéshez, és egyet további kulcsok generálásához. Ezek a sütiktől, a kicserélt véletlenszerű adatoktól, valamint a Diffie-Hellman nyilvános értékektől vagy az előre megosztott titkoktól függenek. A kiszámításuk az ISAKMP SA-hoz meghatározott hash függvény felhasználásával történik, és függ a kiválasztott hitelesítési módtól A pontos formulákat az RFC 2409 definiálja. 4.332 Az 1 fázis: fő mód és agresszív mód A fő mód hat üzenetet tartalmaz, ebből az első kettő az SA egyeztetéséhez, a második kettő a Diffie-Hellman nyilvános értékek kicseréléséhez, míg az utolsó kettő a

nyilvános értékek hitelesítéséhez szükséges: - Az első két üzenet biztosítja az IKE paraméterek egyeztetését, ezek: a titkosító algoritmus, a hash függvény, a másik felet hitelesítő eljárás, és a Diffie-Hellman cso- 35 port. A négy lehetséges hitelesítési eljárás a digitális aláírás, kétféle nyilvános kulcsú titkosítás általi hitelesítés, valamint az előre megosztott titkok használata. - A következő két üzenet a megosztott titok kialakítását teszi lehetővé a DiffieHellman protokoll alkalmazásával. A titkot használjuk viszonykulcsok generálására, amelyek közül kettőt használunk a következő csere megvédésére az előzetesen egyeztetett titkosító és hash algoritmusokkal. - Az utolsó két üzenet a cserék, nevezetesen a nyilvános értékek hitelesítését végzi el. Az agresszív mód csak három üzenetből áll, és az ISAKMP Aggressive Exchange módjának a megvalósítása, ennek részleteit is a [22]

dokumentum mutatja be. A fenti két módban a hitelesítéshez választott eljárás befolyásolja az üzenetek tartalmát és a viszonykulcs-generáló eljárást. Az RFC 2408 részletezi az egyes hitelesítési eljárások során küldött üzeneteket, valamint az aláírások és hash függvények kiszámításának formuláit 4.333 A 2 fázis: gyors mód A 2. fázis során váltott üzeneteket (hitelesség és bizalmasság vonatkozásában) az 1. fázis során egyeztetett elemek segítségével védjük Az üzenetek hitelességét az ISAKMP fejrész után beillesztett HASH adatrésszel biztosítjuk, míg a bizalmasságot az üzenet összes adatrészének a titkosításával garantáljuk. A gyors módot az IPSec-hez hasonló biztonsági protokollok esetében a biztonságos kapcsolatok (SA-k) egyeztetéséhez használjuk. (Mivel az SA csak egyirányú kapcsolatot definiál, valójában minden egyes egyeztetés két SA-hoz vezet, a kommunikáció egy-egy irányának megfelelően). A

mód által tartalmazott üzenetváltások szerepe a következő: - Egy IPSec paraméter-készlet egyeztetése (SA kötegek, SA bundles); - Véletlenszámok cseréje egy új viszonykulcs generálásához, amely viszonykulcsot az 1. fázis során generált titokból származtatunk Opcionálisan igénybe vehetünk egy újabb Diffie-Hellman cserét a PFS tulajdonság biztosítása céljából, amelyet önmagában még nem biztosítunk, amikor az új kulcsot generáljuk a régi kulcsból és a véletlenszámokból; - Az SA-köteg által védendő forgalom azonosítása szelektorok használatával (itt általában a felek IP címét használjuk fel). Megjegyezzük, hogy az IKE protokoll a leírtnál jóval összetettebb, a részletek iránt érdeklődők a felsorolt RFC-kből nyerhetnek további információkat. 4.34 Az IPSec értékelése Schneier szerint az IPSec-nek sok hibája van, de az általa megvizsgált, hasonló funkcionalitást nyújtó protokollok közül még mindig ezt tartja

a legjobbnak [23]. A protokoll hátrányaként hozza föl az összetettségét – ahogy ő fogalmaz: „a biztonság legnagyobb ellensége a komplexitás”. Az IPSec túl sok lehetőséget tartalmaz és túl nagy rugalmasságot enged meg, valamint néha ugyanazt (vagy nagyon hasonló dolgokat) többféleképpen is meg lehet benne valósítani. Például a csomagok hitelesítését akár négy módon is megvalósíthatjuk (transzport/AH, tunnel/AH, transzport/ESP NULL titkosítással, valamint tunnel/ESP NULL titkosítással). Ráadásul a dokumentációja is bonyolult, sok benne a visszahivatkozás, és az értelmezési hibák hibás implementációhoz vezethetnek Problémákat vet fel a működési módokkal, a fejrészekkel és a régebbi szabványokra (ISAKMP) való épüléssel kapcsolatban is. Létezik azonban még egy, az előbbieknél talán fontosabb, inkább elvi/koncepcionális jellegű probléma is. Az IPSec és az általa felhasznált kulcscserélő 36 protokoll

(valamint annak bemutatott elődei) mind kapcsolat-, illetve állapot-alapúak, azaz a kapcsolat felépítésekor és használatakor a résztvevő feleknek információkat kell tárolniuk a kapcsolatról. Ez azonban nem felel meg az Internet – mint világméretű kommunikációs hálózat – tervezési alapelvének, hiszen a létrehozás alapvető célja már az ARPANET idejében is az volt, hogy a rendszer a lehető legnagyobb mértékben legyen hibatűrő, vagyis például egy köztes csomópont megsérülése ne bénítsa meg a teljes rendszert, illetve a csomópontok ne legyenek támadhatóak a félbeszakadt kapcsolatok miatt. A logikai állapotok bevezetésével ezek a problémák megjelenhetnek; a részletes érveléseket az idézett dokumentumban tanulmányozhatják az érdeklődők. 4.4 Ad hoc hálózatok A közelmúltban egy új technológia jelent meg az informatikában, amely lehetővé teszi, hogy valamilyen mobil eszközről csatlakozzunk egy adott hálózathoz, és

adatokat cseréljünk másokkal, akár menet közben is: ez a technológia a vezetéknélküli (wireless) technológia. A hagyományos (vezetékes) hálózati megközelítésektől ez sokban különbözik; a legfőbb különbség mégis talán az, hogy az ilyen dinamikusan változó hálózatok topológiája strukturálatlan, vagy legalábbis folyamatosan változik, képlékeny; ettől „ad hoc” a hálózat A hálózathoz csatlakozó eszközök mindig a hálózat egy másik pontjára szeretnének csatlakozni, ami megnehezíti már az IP címek kiosztását és meghatározását is, ráadásul az útválasztóknak (legalábbis az egyiküknek) mindig tudniuk kell, hogy hol tartózkodik éppen a mobil eszköz. Nem véletlen, hogy viszonylag sok új forgalomirányító protokoll készült az ad hoc hálózatok számára, hiszen az új rendszerekkel új támadási típusok is megjelentek. Ilyen például, amikor egy rosszindulatú támadó azt állítja, hogy ő egy útválasztó

(router), és ő ismeri a legrövidebb utat a mobil eszköz felé, mire az összes többi útválasztó felé irányítja az eszköz számára szóló üzeneteket, amelyeket a támadó elfog, elolvas, módosít, vagy esetleg csak nem juttatja el a címzetthez. Az új protokollok feladata, hogy mechanizmust biztosítsanak a hálózati eszközök azonosságának hitelesítésére. További problémát jelent, hogy a vezetéknélküli kommunikáció sokkal sérülékenyebb, lehallgathatóbb, mint a vezetékes társa, mivel az utóbbi valamilyen szintű fizikai védelemmel mindig el van látva, míg az előbbinél a kommunikáció lehallgatásához kis túlzással elegendő az, ha egy alkalmas eszközzel a mobil eszköz és a hálózat csatlakozási pontja közé állunk. Fokozott hangsúly helyeződik ezért a kommunikáló végpontok és a közbülső útválasztók hitelesítésére, csakúgy, mint az üzenet tartalmának titkosítására és integritásának megőrzésére. 4.41 Az

ARAN protokoll Az ARAN (Authenticated Routing for Ad-hoc Networks) protokoll [24] felismeri és kivédi a fent leírt támadásokat, mégpedig oly módon, hogy bevezeti a hitelesítési, integritásvizsgálati és letagadhatatlansági módszereket az ad hoc hálózatok működésébe. Mindezt a kriptográfiai tanúsítványok alkalmazásával teszi, két fázisban, amely fázisok közül a második opcionális. 4.411 Az ARAN első fázisa Az első fázis tartalmaz egy előzetes hitelesítési lépést, és egy kötelezően végrehajtandó két végpont közötti hitelesítést végrehajtó lépést. Ezek viszonylag egyszerű lépések, nem követelnek túl sok erőforrást. Az előzetes hitelesítési lépés során a protokoll felhasználja egy megbízható T tanúsítvány-kiszolgáló szolgáltatásait. Az ad hoc hálózatba való belépés előtt minden A 37 csomópont kér egy tanúsítványt T-től. A tanúsítvány tartalmazza A IP címét, A nyilvános kulcsát, egy a

tanúsítvány létrehozását dátumozó t időbélyegzőt, és a tanúsítvány lejárásának e időpontját. Ezek a változók össze vannak fűzve, és a T aláírásával vannak ellátva Minden csomópontnak mindenkor a legfrissebb tanúsítványokat kell birtokolnia, valamint ismernie kell T nyilvános kulcsát A végpontok közötti hitelesítés során az A forrás csomópont oly módon kezdi el felépíteni egy X cél csomóponthoz az útvonalat, hogy adatszórással elküld a szomszédainak egy ún. útvonal-feltérképező csomagot (RDP – Route Discovery Packet) Ez tartalmazza a csomag típusazonosítóját („RDP”), a cél IP címét, az A tanúsítványát, egy sorozatszámot (nonce) valamint a t aktuális időt, és A aláírásával van ellátva. A sorozatszám minden RDP-csomag elküldésekor monoton módon eggyel nő A csomópontok az utoljára fogadott sorozatszámot tárolják, az időbélyegzővel együtt. Minden (közbülső) csomópont feljegyzi, hogy melyik

szomszédjától kapott ilyen csomagot, majd továbbítja az üzenetet a saját aláírásával ellátva azt (természetesen olyanok felé nem továbbítják, akitől kapták). Ez az aláírás védi ki a személyiséghamisításos vagy megszemélyesítéses támadásokat, amelyek megváltoztathatják az útvonalat, illetve hurkok kialakulásához vezethetnek. Mielőtt adatszórással ő is továbbítaná a csomagot, csatolja a hozzá tartozó tanúsítványt, de előtte még eltávolítja róla az előző csomópont aláírását. Előbb-utóbb az üzenet megérkezik az X célcsomóponthoz, aki a fogadást követően válaszol az első olyan RDP csomagra, amelyet adott forrástól és adott sorozatszámmal fogad (nincs garancia arra, hogy az elsőként fogadott RDP csomag a legrövidebb útvonalon érkezett). Ez a válasz egy REP válasz-csomag, amit a forrás-cél útvonal megfordításával kapott útvonal (vagyis a cél-forrás útvonal) első közbülső csomópontjának küld el

(vagyis annak, akitől az RDP csomagot kapta), természetesen ezt is aláírva. A fogadott REP csomagokat a közbülső csomópontok annak továbbítják, akitől az eredeti RDP csomagot kapták. Mielőtt azonban továbbküldenék a láncon visszafelé, a fogadó ellenőrzi a küldő aláírását a csatolt tanúsítvány segítségével, eltávolítja azt, majd aláírja a saját kulcsával, és az egészhez csatolja a saját tanúsítványát. Megjegyezzük, hogy a cél csomópont aláírását a közvetlenül a célt megelőző csomópont nem távolítja el (hasonlóan az RDP csomag esetében sem), mivel ekkor nem lehetne ellenőrizni a csomag küldőjének azonosságát. Amikor a REP válaszcsomag végül megérkezik a forrás csomóponthoz, a forrás ellenőrzi, hogy a helyes sorozatszámot kapta-e vissza, valamint ellenőrzi a cél aláírását is. Ha mind a kettőt rendben találja, akkor a cél megkapta az üzenetet, és csakis ő válaszolhatott rá. A módszer hátránya,

hogy meglehetősen költséges, mivel minden egyes csomópontnak egy bejegyzést kell karbantartania egy útválasztó-táblázatban minden egyes aktív forrás-cél párhoz, szemben a nem biztonságos ad hoc forgalomirányító protokollokkal, amelyek cél csomópontonként egyetlen bejegyzést tárolnak. 4.412 Az ARAN második fázisa Ezt a fázist csak azután hajthatjuk végre, miután az 1. fázis befejeződött, mivel itt szükségünk lesz a cél tanúsítványára. A 2 fázist elsősorban egy legrövidebb út megtalálására használjuk fel, mégpedig biztonságos módon. Legelőször a forrás adatszórással szétküld egy SPC (Shortest Path Confirmation, legrövidebb út jóváhagyása) üzenetet a szomszédainak. Ez az üzenet tartalmazza a csomag típusazonosítóját („SPC”), valamint a cél csomópont IP címét és a saját tanúsítványát. Ezen kívül a forrás konkatenálja a cél IP címét és tanúsítványát, egy sorozatszámot, és egy időbélyeget,

majd az egészet aláírja, és titkosítja a cél nyilvános kulcsával, hogy más csomópontok ne módosíthassák a tartalmat Amikor a közbülső csomópontok fogadják az üzenetet, aláírják a fogadott SPC titkosított részét, majd beleteszik a saját tanúsítványukat is a csomagba, végül pedig ismét tikosítják a csomagot a cél nyilvános kulcsával (amit az előző csomópont kül- 38 dött). Ezt követően adatszórással továbbítják az SPC üzenetet Az üzenetet fogadó csomópontok ezen kívül bejegyzéseket hoznak létre a útválasztó (routing) táblájukban, hogy elkerüljék a kettőzött csomagküldést. Ezt a bejegyzést használjuk majd a visszafelé úton a válasz-csomag továbbítására is Amikor a cél csomópont megkapja az SPC csomagot, ellenőrzi, hogy az aláírások érvényesek-e. A cél az elsőként fogadott csomagra, valamint bármely ennél rövidebb rögzített útvonallal rendelkező csomagra is válaszol. Ezt követően a cél egy

RSP (Recorded Shortest Path, rögzített legrövidebb útvonal) üzenetet küld el a forrásnak afelé a közbülső csomópont felé, amely a legrövidebb úton hozzá a legközelebb helyezkedett el. Ez az üzenet tartalmazza a csomag típusazonosítóját („RSP”), a forrás (az A) csomópont IP címét, a cél (az X) csomópont tanúsítványát, az A által küldött üzenetben fogalt sorozatszámot, valamint az útvonalat. Mielőtt elküldené az RSP csomagot, az egészet aláírja. Előbb-utóbb a forrás megkapja a csomagot, és ellenőrzi, hogy a sorozatszám (nonce) megfelel-e az eredeti SPC-ben elküldött sorozatszámnak A vázolt módszer előnye, hogy az egymásba ágyazottan aláírt üzenetek megakadályozzák a közbülső csomópontokat abban, hogy megváltoztassák az útvonalat. Az SPC-ben lévő útvonalhosszt nem tudják megnövelni, mivel ehhez egy további érvényes tanúsítvány szükséges; ugyanakkor lerövidíteni vagy megváltoztatni sem tudják, mivel

ekkor viszont megtörnék a titkosított adatok integritását. 4.413 Kulcsvisszavonás az ARAN-ban Amikor egy kulcs visszavonása szükségessé válik (például kompromittálódik vagy lejár), a megbízható T tanúsítványtároló (cert server) adatszórással szétküld egy üzenetet ahhoz az ad hoc csoporthoz, amelyik bejelentette a visszavonást. Az üzenet tartalmazza az érvényességét vesztett tanúsítványt, és az üzenet a kiszolgáló aláírásával lesz ellátva. A visszavonási értesítéseket addig tároljuk, amíg a tanúsítvány érvényessége normálisan le nem járna A visszavont tanúsítványt birtokló csomópont öszszes szomszédos csomópontjának viszont újra kell konfigurálnia az útválasztó tábláját, hogy elkerülje a megbízhatatlanná vált csomóponton keresztüli adattovábbítást. Ez a módszer azonban nem nyújt teljes biztonságot: például ha az adott (érvénytelen tanúsítvánnyal rendelkező) csomópont egy ad hoc hálózat

két része közötti egyetlen kapcsolat, akkor a visszavonásról értesítő üzenet nem fog eljutni egyik oldalról a másikra – ez viszont a hálózat partícionáltságához fog vezetni. Ezen helyzet felismerése és a visszavonási értesítések terjedésének megerősítése érdekében amikor egy csomópont egy újcsomóponttal találkozik, kicserélhetik egymással a visszavonási értesítéseik valamiféle összegzését vagy listáját. Ha ezek nem egyeznek meg, a ténylegesen aláírt üzenetek átadódhatnak és adatszórással továbbítódhatnak az üzenet terjedésének újraindítása céljából. 4.42 A hálózati topológia elrejtése: Az NDM-módszer Vannak esetek, amikor az üzenet küldője biztonságos módon kíván kommunikálni az üzenet célzott fogadójával, mégpedig oly módon, hogy elrejti előle (és mások elől, így például egy esetleges támadó elől is) a hálózaton belüli elhelyezkedését. Ez a módszer az NDM (Non-Disclosure Method)

eljárás [24], amely több feltételezéssel is él. Egyrészt felteszi, hogy a hálózaton elszórva vannak úgynevezett biztonsági ágensek (SA – Security Agent), amelyek rendelkeznek egy nyilvános-privát kulcs-párral, illetve az ezt hitelesítő tanúsítványokkal. Ezen kívül felteszi, hogy a küldő ismer valamiféle az SA-kon keresztül vezető útvonalat a fogadóhoz, nevezzük ezeket SA1, SA2, , SAn biztonsági ágenseknek, az útvonalon való elhelyezkedésnek megfelelő sorrendű indexeléssel. A módszer lényege, hogy a küldő az M üzenetet és az R azonosítóját (vagy tanúsítványát) beleteszi egy borítékba, amit először a sorrendben utolsó SA nyilvános kul- 39 csával, KSAn-nel titkosít, majd mellétéve SAn azonosítóját (vagy tanúsítványát) újra beleteszi az egészet egy borítékba, amit SAn-1 nyilvános kulcsával titkosít, és így tovább, amíg az egymásba ágyazott borítékokat végül az első SA KSA1 nyilvános kulcsával

titkosítja. Így a végső M’ üzenet a következő alakú lesz: M’ = KSA1 (SA2, (KSA2 (SA3 ((KSAn (R, M)) )))). A csomag küldésekor először SA1 visszafejti a legkülső beágyazás titkosítását a saját magánkulcsával, majd továbbítja a csomagban talált következő SA, most SA2 felé. A csomag úgy halad SA-ról SA-ra, hogy minden közbülső SA csak az őt megelőző és a következő SA-t ismeri (mivel tudja, hogy kitől kapta a csomagot, és a csomagból magából tudja, hogy hova kell küldenie). Az n csomag végül visszafejti a KSAn (R, M) üzenetet, és eljuttatja a fogadóhoz. A módszer előnye, hogy az SA mindig csak az éppen megelőző és a soron következő másik SA-t ismeri, ráadásul rajta kívül más vissza sem képes fejteni az üzenetet, mivel nem ismeri a nyilvános kulcs privát párját, így továbbküldeni sem tudja. Továbbá más nyilvános kulcsú módszerek (például üzenetpecsétek) alkalmazását is lehetővé teszi. A módszer

jelentős hátránya viszont, hogy nagyon komoly számítási költséggel jár az SA-k szempontjából, valamint az eredeti csomag is lényegesen megnőhet az egymásba ágyazott nyilvános kulcsú titkosítások miatt. 4.43 Az SRP protokoll Ez a protokoll, amint a neve is mutatja (SRP – Secure Routing Protocol) [24] egy biztonságos forgalomirányítási protokoll, amely felteszi, hogy az S forrás csomópont és a T cél csomópont között már létezik egy felépített biztonsági összeköttetés (SA, security association). Ez az SA felépíthető oly módon, hogy a másik fél nyilvános kulcsának ismeretében egy megosztott titkot egyeztetünk, például a fent leírt kulcscserélő módszerek valamelyikével, esetleg valamilyen csoportos kulcscserélő sémával. Az SA feltételezése indokolt, mivel a végpontok egy biztonságos kommunikációs sémát választottak, ezért képesnek kell lenniük egymás azonosítására. Feltesszük továbbá, hogy a csomópontok

memóriával rendelkeznek, hogy a már látott útválasztási kéréseket eldobhassák. További feltételezésünk, hogy létezik egy egyértelmű megfeleltetés a MAC kódok és IP címek között. Az S forrás csomópont azzal kezdi az útvonalkeresést, hogy létrehoz egy útvonalkérő csomagot, amit egy véletlenszerű kérésazonosítóval és egy sorozatszámmal azonosít. Feltesszük, hogy a forrás és a T cél csomópont között már létezik egy biztonsági összeköttetés, vagyis egy KST megosztott kulcs Ezután az S csomópont létrehoz egy MAC (Message Authentication Code) üzenethitelesítő kódot, ami a forrás és a cél azonosítójának, a véletlenszerű kérésazonosítónak, a sorozatszámnak és KST-nek egy hash függvénye. Ezen kívül az útvonalkérő csomagban eltároljuk az érintett közbülső csomópontok azonosítóját (IP címét) is. A közbülső csomópontok fogadják és továbbítják az útvonalkéréseket, valamint fenntartanak valamely

korlátozott mennyiségű, a fogadott kérésekre vonatkozó állapot információt (a sorozatszám és a véletlenszerű szám tárolásával), hogy eldobhassák a már látott útvonalkéréseket. A célt egynél több útvonalkérő csomag éri el, különböző útvonalakon. A T cél csomópont kiszámítja az útvonalválasz-tartalmat lefedő MAC kódot, majd visszaküldi S-nek a csomagot a vonatkozó kérés csomagban eltárolt útvonalon visszafelé. A cél csomópont egy vagy több útvonalkérő csomagra válaszol, hogy a forrás számára a lehető legátfogóbb topológiai képet biztosítsa. A protokoll előnye, hogy a MAC kiszámítása nem túl számításigényes, és megőrizhető (ellenőrizhető) vele az üzenet integritása. Ha pedig szükséges az adatok bizalmasságának biztosítása, az üzenetek adatrészét titkosíthatjuk a KST megosztott kulcscsal A protokoll védelmet nyújt az ad hoc hálózatokban végrehajtható különféle támadásokkal szemben is

(bár nem mindegyikkel szemben), a részletek iránt érdeklődők a [24] munkában találhatnak részletes információt. 40 5. Hitelesítés a szállítási rétegen A hálózati réteg protokolljai az esetek túlnyomó részében a teljes hálózati forgalom titkosítását és a résztvevő felek (végpontok) hitelesítését is elvégzik; ehhez általában a nyilvános kulcsú kriptográfia technikáit használják fel. Ugyanakkor említettük azt is, hogy ezek a műveletek költségesek, és tekintve, hogy a hálózati forgalomban jellemzően a sávszélesség a szűk keresztmetszet, néha célszerű lehet, hogy a teljes forgalomnak csak azt a részét védjük, amely valóban igényli az emelt szintű biztonságot. Ezt megtehetjük úgy, hogy a különböző alkalmazás-szintű speciális protokollokat biztonságossá tesszük valamilyen módon, de létrehozhatunk olyan protokollokat is, amelyek szabványos és az alkalmazásoktól független módon nyújtják ezeket a

szolgáltatásokat, az alkalmazási és a hálózati réteg között. Ehhez hasonló megfontolások vezethettek végül a szállítási réteg biztonsági protokolljainak létrehozásához, melyek legfontosabb (és talán az egyetlen) képviselője az SSL-család A „család” kitétel azért indokolt, mert az azt alkotó protokollok egyetlen közös ősre, a Netscape Communications által 1994-ben kidolgozott SSL (Secure Sockets Layer) [25] protokollra vezethetők vissza. Az SSL hamar népszerűségre tett szert az internetes közösségek és a szoftverfejlesztő cégek körében, hiszen akkortájt még nem léteztek a hálózati szintű (fent bemutatott) mechanizmusok, az alkalmazási rétegen viszont egyrészt a protokollok nem nyújtottak megfelelő szintű biztonságot, másrészt ezekből annyira sok létezett, hogy egy több feladatot is ellátó alkalmazás esetén a funkcióknak megfelelő összes protokollt implementálni kellett az alkalmazásban, ami rengeteg munkával

járt. Az új protokollban a „megváltót” látták, és ezt sokáig nem is cáfolta semmi; ily módon az SSL az iparág de facto szabványává válhatott. Ez olyanynyira így történt, hogy a szakirodalomban sokhelyütt találkozni a TCP/IP protokollszerkezetben egy „biztonsági réteggel”, amely az IP és a TCP/UDP rétegek között helyezkedik el, és jellemzően ez alatt magát az SSL protokollt értik Pár év elteltével bebizonyosodott, hogy az akkor a v2 verziónál tartó SSL törhető; ez kapóra jött a Microsoftnak, aki fantáziát (és piaci rést) látott a technológiában, és nemsokára kidolgozta saját variánsát, az SSL-re kísértetiesen hasonlító, de annak hibáit nem tartalmazó PCT (Private Communication Technology) protokollját [27]. A válaszlépés sem váratott sokáig magára: a Netscape is kidolgozta a javított protokollt, ami a v3 verziószámot kapta. Időközben az IETF úgy érezte, megérett az idő a protokollok egységesítésére,

és (némi átdolgozást követően) szabványként fogadta el az SSL 31 verzióját, ami TLS (Transport Layer Security) [28] néven vonult be a köztudatba, és azóta is nagy népszerűségnek örvend; nem véletlen hát, hogy az alkalmazási réteg biztonsági protokolljai közül sok erősen támaszkodik az SSL/TLS szolgáltatásaira. A következő néhány szakaszban az SSL-családot alkotó protokollokat tekintjük át részletesen. 5.1 Az SSL protokoll Fő funkcióit tekintve az SSL lehetővé teszi a rá felkészített kiszolgálók számára, hogy hiteles módon azonosítsák magukat a szolgáltatásaikat igénybe vevő kliensek felé, lehetővé teszi, hogy a kliensek hasonló módon azonosítsák kilétüket a kiszolgáló felé, végezetül lehetővé teszi mindkét gép számára, hogy titkosított kapcsolatot építsenek fel. Az SSL szerver oldali azonosítással a felhasználó meggyőződhet a kiszolgáló identitásáról. Az SSL-re felkészített kliens szoftver

szabványos nyilvános kulcsú kriptográfiai technikákat használ annak ellenőrzésére, hogy a kiszolgáló tanúsítványa és nyilvános azonosítója (megkülönböztetett neve) érvényes-e, és hogy a tanúsítványt egy olyan hitelesítés-szolgáltató (CA) adta-e ki, amely szerepel a kliens megbízható CA-kat tartalmazó listáján. (Megjegyezzük, hogy az SSL az X509 szabványnak megfelelő tanúsítványokat alkalmaz) Ez az azonosítás nagy fontossággal bírhat, ha például a kliens a hitelkártya-számát küldené át az Interneten keresztül Hasonló módszereket 41 használ a szerver is, ha például banki kiszolgálóként bizalmas pénzügyi információkat szándékozik küldeni az ügyfélnek. Ezek a funkciók szabványos szimmetrikus és aszimmetrikus titkosítási technikákat (úgynevezett titkosító-készleteket) alkalmaznak, amelyek a következő algoritmusokat tartalmazzák: DES, DSA (Digital Signature Algorithm, az Egyesült Államok kormányzata

által használt digitális aláírási szabvány), KEA (Key Exchange Algorithm, az Egyesült Államok kormányzata által használt kulcscserélő algoritmus), MD5, RC2 és RC4, RSA kulcscserélő algoritmus, SHA-1, SKIPJACK, és a Triple-DES. Ezen algoritmusokról részletes leírás a [6] műben található Az SSL protokoll két részprotokollt tartalmaz: az SSL rekord protokollt és az SSL kézfogási (handshake) protokollt. A rekord protokoll az adatátvitelhez használt adatformátumot definiálja (ezt itt nem mutatjuk be részletesen, a részletek iránt érdeklődők a [25] dokumentumban találhatnak további információkat), míg a kézfogási protokoll SSL-re felkészített kiszolgálók és kliensek közötti üzenetváltások sorozatát definiálja (a rekord protokoll felhasználásával) egy SSL-kapcsolat felépítéséhez. Ezek az üzenetváltások a következő feladatok automatizálását végzik el: a szerver azonosítása a kliens felé; a kliens és a szerver

mindkettője által támogatott kriptográfiai algoritmusok és titkosítók kiválasztása; opcionálisan a kliens azonosítása a szerver felé; nyilvános kulcsú titkosítási technikák felhasználása megosztott titkok generálására; valamint a titkosított SSL-kapcsolat felépítése. 5.11 Az SSL kézfogási protokoll Minden SSL-kapcsolat egy üzenetváltással kezdődik, amely során a szerver mindig azonosítja önmagát (hiteles módon, nyilvános kulcsú technikák használatával) a kliens felé, majd a két fél együttműködésben hozza létre a kapcsolat során a gyors titkosításhoz, visszafejtéshez és integritásvizsgálathoz felhasznált szimmetrikus kulcsokat. Hangsúlyozzuk, hogy opcionálisan a kiszolgáló is kérheti a klienstől, hogy az hiteles módon azonosítsa önmagát. A végrehajtott lépéseket a következőkként összegezhetjük: 1. A kliens elküldi a szervernek a kliens SSL-verziószámát, a titkosítóbeállításait, valamilyen

véletlenszerűen generált adatot, valamint a szerver által megkövetelt további információkat, amelyek ahhoz szükségesek, hogy a szerver az SSL használatával kommunikálni tudjon a klienssel. 2. A szerver elküldi a kliensnek a szerver SSL-verziószámát, a titkosítóbeállításait, valamilyen véletlenszerűen generált adatot, valamint a szerver által megkövetelt további információkat, amelyek ahhoz szükségesek, hogy a kliens az SSL használatával kommunikálni tudjon a szerverrel. Ezen kívül elküldi a saját tanúsítványát, valamint ha a kliens olyan szerver-oldali erőforrás igénybevételét kéri, amely hiteles azonosítást igényel, kérvényezi a kliens tanúsítványát 3. A kliens a szerver azonosításához felhasználja a szerver által küldött információk némelyikét Ha a szerver nem hitelesíthető, a felhasználó figyelmeztetést kap arról, hogy nem építhető fel titkosított és hitelesített kapcsolat. Egyébként a folyamat a 4.

lépésnél folytatódik 4. A kézfogás során eddig a pontig generált adatok felhasználásával a kliens (a választott tikosító-készlettől függően a szerver együttműködésével) létrehozza a kapcsolathoz az úgynevezett előzetes mester-titkot (premaster secret), titkosítja azt a szerver nyilvános kulcsával (amelyet a szerver tanúsítványából szerezhet meg), majd elküldi a szervernek. 5. Ha a szerver kliens oldali hitelesítést igényel, a kézfogási protokoll opcionális lépéseként a kliens aláír egy másik adatot, amely kézfogási folyamatonként egyedi, de ismeri mind a szerver, mind pedig a kliens. Ebben az esetben a kliens a titkosított előzetes mester titokkal együtt elküldi az aláírt adatot és a saját tanúsítványát is a szervernek 42 6. Ha a szerver a kliens hiteles azonosítását kérte, megpróbálja hitelesíteni a klienst (ezt részletesen az 5.13 pontban tárgyaljuk) Ha a kliens nem hitelesíthető, az összeköttetés véget

ér. Ha a kliens sikeresen hitelesíthető, a szerver a magánkulcsával visszafejti az előzetes mester titkot, majd végrehajt egy műveletsorozatot (amit ugyanabból az előzetes mester titokból kiindulva a kliens is végrehajt) az úgynevezett mester titok generálásához. 7. Mindkét fél a mester titok felhasználásával generálja a viszonykulcsokat, amelyeket az SSL-kapcsolat során cserélt információk titkosítására és visszafejtésére, valamint az adatintegritás vizsgálatára használnak majd. 8. A kliens üzenetet küld a szervernek, amiben arról értesíti, hogy a jövőbeni üzenetei a viszonykulccsal lesznek titkosítva. Ezt követően elküld egy különálló titkosított üzenetet, amivel jelzi, hogy a kézfogás kliens oldali része befejeződött 9. A szerver üzenetet küld a kliensnek, amiben arról értesíti, hogy a jövőbeni üzenetei a viszonykulccsal lesznek titkosítva. Ezt követően elküld egy különálló titkosított üzenetet, amivel

jelzi, hogy a kézfogás szerver oldali része befejeződött 10. Az SSL-kézfogás befejeződött, megkezdődött az SSL-kapcsolat, amely során a viszonykulcsokat használják az adatok tikosítására és visszafejtésére, valamint az integritás ellenőrzésére. Megjegyezzük, hogy a kapcsolat folytatása előtt a szerverek ellenőrizhetik, hogy a kliens tanúsítványa jelen van-e egy (például LDAP-alapú) tanúsítványtárban a felhasználóhoz tartozó bejegyzésben; ezzel az opcióval valamelyest meggyőződhet afelől, hogy a kliens tanúsítványa érvényes. 5.12 A szerver hitelesítése Az SSL-re felkészített kliens oldali alkalmazások mindig megkövetelik a szerver hitelesítését, vagyis hogy a kliens kriptografikusan ellenőrizze a szerver azonosságát. Ehhez a kézfogás 2. lépésében elküldött tanúsítványt használjuk fel a protokoll 3 lépésében A nyilvános kulcs és a nyilvános kulcsot tartalmazó tanúsítvány által azonosított szerver

közötti kapcsolat hitelesítéséhez a következőkben bemutatásra kerülő négy kérdés mindegyikére a kliensnek „igen” választ kell kapnia. Bár a negyedik kérdés technikailag nem része az SSL protokollnak, a kliens felelőssége, hogy támogassa azt, mivel ily módon némileg megbizonyosodhat a szerver valódi azonosságáról, továbbá ezzel kivédhető a közbeékelődésées támadás. A szerver azonosságának ellenőrzéséhez tehát a kliens a következőket ellenőrzi: „A mai dátum az érvényességi időn belül van?” – A kliensnek ellenőriznie 1. kell, hogy a tanúsítvány érvényben van-e a fogadás időpontjában. Ha a dátum és az idő a tartományon kívül esik, a hitelesítési folyamat leáll; egyébként a 2. lépésnél folytatódik 2. „A kibocsátó CA egy megbízható CA?” – Minden SSL-re felkészített kliens fenntart egy listát a megbízható CA-k tanúsítványairól; ez azt határozza meg, hogy a kliens mely szerverek

tanúsítványát fogadja el. Ha a kibocsátó CA megkülönböztetett neve (DN) megegyezik egy a listán szereplő CA megkülönböztetett nevével, a válasz „igen” lesz, és a folyamat a 3. lépésnél folytatódik Ha a kibocsátó CA nem szerepel a listán, a hitelesítési folyamat véget ér (hacsak a kliens nem tud beazonosítani egy olyan tanúsítványláncot, amely a kibocsátó CA-val végződik). 3. „A kibocsátó CA nyilvános kulcsa hitelesíti a kibocsátó digitális aláírását?” – A kliens a CA tanúsítványában lévő nyilvános kulcsot használja a kiszolgáló tanúsítványán lévő, a CA általi digitális aláírás ellenőrzésére. Ha a kiszolgáló tanúsítványában lévő információ megváltozott azóta, hogy a CA aláírta, vagy ha a CA tanúsítványának nyilvános kulcsa nem felel meg a CA által a szerver tanúsítványának aláírására használt magánkulcsnak, a kliens nem hitelesíti a szerver azonosságát Ha viszont a CA

digitális aláírása hitelesíthető, a felhasználó a szerver tanúsítványát a CAtól származó hiteles „bemutatólevélként” fogja kezelni, és folytatja a folyamatot Ennél 43 a pontnál a kliens már megállapította, hogy a szerver tanúsítványa hiteles, és az ő felelőssége, hogy elvégezze a 4. lépést az 5 lépés előtt 4. „A szerver tanúsítványában szereplő tartománynév egyezik-e a szervernek a tartománynevével?” – Ez a lépés megerősítheti, hogy a szerver valóban ugyanazon a hálózati címen helyezkedik el, mint amit a szerver tanúsítványában szereplő tartománynév meghatároz. A teljes hitelesítéshez (bár nem része technikailag az SSL protokollnak) el kell végezniük ezt az értékelést, és el kell utasítaniuk a kiszolgáló hitelesítését és a kapcsolat felépítését, ha a kérdésre „nem” a válasz Egyébként a folyamat az 5 lépésre halad. 5. „A szerver hiteles.” – A kliens folytatja az SSL

kézfogási protokollt Ha bármely okból a kliens nem ér el az 5. lépésig, a tanúsítvány által hitelesített szerver nem azonosítható hitelesként, és a felhasználó figyelmeztetést kap a problémáról, valamint arról, hogy titkosított és hitelesített kapcsolat nem építhető fel a szerverrel. Ha a szerver megkívánja a felhasználó hitelesítését, végrehajtja a kliens hitelesítésének lépéseit. Az itt leírt lépéseket követően a szervernek sikeresen kell használnia a magánkulcsát a kliens által az SSL kézfogási protokoll 4. lépésében küldött előzetes mester kulcs visszafejtéséhez; máskülönben az SSL kapcsolat véget ér. Ez további garanciát jelent arra nézve, hogy a szerver tanúsítványában szereplő nyilvános kulccsal társított identitás valóban az a szerver, akihez a kliens kapcsolódott. 5.13 A kliens hitelesítése Ha a kliens által igénybe vett szolgáltatás olyan természetű, amely megkívánja a kliens

hitelesítését, akkor (amint azt a kézfogási protokoll 6. lépésénél említettük) a kliens elküldi a szervernek a tanúsítványát, valamint egy különálló, digitálisan aláírt adatot. Ezzel oly módon teszi lehetővé a kliens hiteles azonosítását, hogy a szerver a tanúsítványban lévő nyilvános kulccsal ellenőrizheti a digitálisan aláírt adatot, és ezzel hitelesítheti a tanúsítványban állított személyazonosságot. Az SSL protokollnak megfelelően a kliens a digitális aláírást oly módon hozza létre, hogy elkészíti a kézfogás során véletlenszerűen generált (és csak a kliens illetve a szerver által ismert) adat egyirányú hash lenyomatát (vagyis az üzenetpecsétet), majd ezt a lenyomatot titkosítja a szervernek elküldött tanúsítványban foglalt nyilvános kulcs privát párjával. A nyilvános kulcs és a nyilvános kulcsot tartalmazó tanúsítvány által azonosított személy vagy entitás közötti kapcsolat

hitelesítéséhez az SSL-re felkészített szervernek a következőkben bemutatásra kerülő első négy kérdés mindegyikére „igen” választ kell kapnia. Bár az ötödik kérdés technikailag nem része az SSL protokollnak, a szerverek felkonfigurálhatóak úgy, hogy támogassák azt, mivel ily módon a hitelesítési folyamat részeként kihasználhatja a felhasználóhoz tartozó esetleges, valamely LDAP tanúsítványtárban lévő bejegyzés előnyeit. A kliens azonosságának ellenőrzéséhez tehát a szerver a következőket ellenőrzi: „A felhasználó nyilvános kulcsa hitelesíti a felhasználó digitális aláírá1. sát?” – A szerver ellenőrzi, hogy az aláírás hitelesíthető-e a tanúsítványban lévő nyilvános kulcs segítségével. Ha igen, a szerver megállapítja, hogy az a kulcs, amely állítólag az adott személyhez tartozik, a digitális aláírás létrehozásához felhasznált magánkulcs nyilvános párja, és az adat nem módosult az

aláírás időpontja óta Megjegyezzük, hogy ennél a pontnál a nyilvános kulcs és a tanúsítványban lévő megkülönböztetett név (DN) közötti egyértelmű kapcsolatot még nem állapíthatjuk meg, mert a tanúsítványt létrehozhatta esetleg egy olyan személy is, aki a felhasználó nevében próbál meg fellépni. Ezen kapcsolat hitelesítéséhez a szervernek végre kell hajtania a 3 és 4 lépéseket is. 2. „A mai dátum az érvényességi időn belül van?” – A szervernek ellenőriznie kell, hogy a tanúsítvány érvényben van-e a fogadás időpontjában. Ha a jelenlegi dátum 44 és az idő a tartományon kívül esik, a hitelesítési folyamat leáll; egyébként a 3. lépésnél folytatódik. 3. „A kibocsátó CA egy megbízható CA?” – Minden SSL-re felkészített szerver fenntart egy listát a megbízható CA-k tanúsítványairól; ez azt határozza meg, hogy a szerver mely tanúsítványokat fogadja el. Ha a kibocsátó CA

megkülönböztetett neve (DN) megegyezik egy a listán szereplő CA megkülönböztetett nevével, a válasz „igen” lesz, és a folyamat a 4. lépésnél folytatódik Ha a kibocsátó CA nem szerepel a listán, a hitelesítési folyamat véget ér (hacsak a szerver nem tud beazonosítani egy olyan tanúsítványláncot, amely a kibocsátó CA-val végződik). 4. „A kibocsátó CA nyilvános kulcsa hitelesíti a kibocsátó digitális aláírását?” – A szerver a CA tanúsítványában lévő nyilvános kulcsot használja a kliens tanúsítványán lévő, a CA általi digitális aláírás ellenőrzésére. Ha a tanúsítványban lévő információ megváltozott azóta, hogy a CA aláírta, vagy ha a CA tanúsítványának nyilvános kulcsa nem felel meg a CA által a kliens tanúsítványának aláírására használt magánkulcsnak, a szerver nem hitelesíti a kliens azonosságát. Ha viszont a CA digitális aláírása hitelesíthető, a szerver a kliens

tanúsítványát a CA-tól származó hiteles „bemutatólevélként” fogja kezelni, és folytatja a folyamatot. Ennél a pontnál az SSL protokoll lehetővé teszi a szerver számára, hogy hitelesnek tekintse a felhasználó személyazonosságát, és az összeköttetést a 6. lépésnél folytassa Ugyanakkor a szerverek felkonfigurálhatóak oly módon is, hogy a 6. lépést megelőzően végrehajtsák az 5 lépést is 5. „A felhasználó tanúsítványa fel van sorolva a felhasználóhoz tartozó LDAP-bejegyzésben?” – Ez az opcionális lépés lehetőséget biztosít a rendszeradminisztrátorok számára, hogy elutasítsák egy felhasználó tanúsítványát, még ha az át is menne a teszten az összes többi lépés során. (Például a Netscape Certificate Server kiszolgálók automatikusan eltávolíthatják a visszavont tanúsítványokat egy felhasználó LDAP-bejegyzéséből.) A jelen lépés végrehajtására is beállított szerverek ebben az esetben

elutasítják a tanúsítvány hitelesítését, és nem építik fel az SSL-kapcsolatot. Ha viszont a felhasználónak a tanúsítványtárban lévő tanúsítványa megegyezik az SSL kézfogási protokoll során a szerverhez elküldött tanúsítványával, a folyamat befejeződik, a kézfogási protokoll a 7. lépéstől folytatódhat Felhívjuk a figyelmet arra, hogy az 5. lépés nem része az SSL protokoll eredeti verziójának, tehát az nem támogatja a tanúsítvány-visszavonási listák ellenőrzését Ezen kívül elképzelhető itt egy 6 lépés is, amely során a szerver ellenőrzi, hogy a kliens által küldött tanúsítvány (ha az például egy attribútum tanúsítvány) alapján a felhasználó jogosult-e a kért szolgáltatás igénybevételére, azonban ez a lépés sem része az SSL protokoll specifikációjának, másrészt pedig a jogosultságvizsgálat témakörét nem szándékunk a jelen dolgozatban tárgyalni. 5.14 Az SSL protokoll értékelése Manapság

az SSL az egyik legszélesebb körben alkalmazott hálózati biztonsági protokoll, amelyet számtalan, a szolgáltatásait a szállítási réteg feletti rétegen nyújtó biztonsági protokoll is felhasznál. Ez egyrészt annak köszönhető, hogy a protokoll már meglehetősen „öreg” (a jelen dolgozat készültekor éppen 10 éves), másrészt viszont jelentős hibát – az említett és mára befoltozott biztonsági résen kívül – még nem találtak benne. Mellette szól még, hogy minden igényt kielégítően széles körű kriptográfiai technikákat támogat, és emellett is meglehetősen egyszerűen implementálható. Hátránya viszont, hogy (amint azt említettük) eredeti formájában nem teszi kötelezővé a kliensek hitelesítését, ami olyan alkalmazások fejlesztéséhez vezethet, amelyek komoly biztonsági hiányosságokkal rendelkeznek, és hibái között szokták felsorolni, hogy a jogosultságvizsgálattal sem igazán foglalkozik, habár nem is ez volt

a kifejlesztésének a célja. Említettük azt is, hogy eredeti formájában (talán ismét időrendi okokból) nem támogatja a tanúsítvány-visszavonási listák ellenőrzését sem. Ráadásul a kézfogási protokoll meglehetősen erőforrás-igényes, ezért a gyakorlatban az előző kapcsolatokból viszonylag sok információt gyorsítótárakban raktároznak el, ami jelentősen felgyorsít- 45 hatja a kézfogási folyamat végrehajtását [26]. A következő részben az időrendben őt követő, az eredeti protokollhoz képest fejlesztéseket tartalmazó PCT protokollt mutatjuk be. 5.2 A PCT protokoll A PCT (Private Communication Technology) [27] a Microsoft által 1995-ben kidolgozott biztonsági protokoll. A létrehozásának célja egy az SSL hibáit kijavító protokoll kidolgozása volt, amely hasonló funkcionalitással és szerkezettel rendelkezik, de az említett hibák nélkül. Mindazonáltal a PCT modellje általánosabb, mint az SSL protokollé: a PCT nem

foglalkozik tanúsítványok hitelesítésével és ellenőrzésével, hanem felteszi, hogy a protokoll implementációi valamiféle „fekete dobozhoz” férnek hozzá, amely fekete doboz végzi a kliens hitelesítését a szerver felé és megfordítva. Ezzel tulajdonképpen az SSL funkcionalitását terjesztették ki (általánosították), hiszen semmiféle konkrét előírást nem tettek a hitelesítési mechanizmusra, inkább csak helyet biztosítottak a számára 5.21 Hasonló vonások A két protokoll sok közös vonással rendelkezik: mindkettő két kommunikáló alkalmazás közötti biztonságos, nem lehallgatható kommunikáció lebonyolítását teszi lehetővé, az alkalmazások számára transzparens módon. A kézfogási protokoll a PCT esetén is a titkosított és hitelesített kapcsolat felépítéséhez és a használatához szükséges paraméterek egyeztetését teszi lehetővé, nyilvános kulcsú módszerek alkalmazásával. A PCT-összeköttetést is

szimmetrikus kulcsú titkosítás védi, továbbá az információcsere közben az adatok integritását a MAC (Message Authentication Code) hash függvény használata biztosítja. A PCT rekordformátuma kompatibilis az SSL rekordformátumával A protokollok közötti lényeges különbség a kézfogási protokoll során váltott üzenetekben rejlik. 5.22 Lényegi különbségek A PCT üzenetek az SSL üzenetekhez képest számos, a biztonságot megerősítő aspektussal bővültek, ezek a következőképpen összegezhetőek: – Az üzenetváltások és az üzenetek struktúrája jelentősen lerövidült és egyszerűsödött. Például egy kapcsolat újrafelépítéséhez vagy az újrakapcsolódáshoz csak egyetlen üzenet elküldése szükséges mindkét oldal részéről (ha nem kívánjuk meg a kliens hitelesítését), és egyetlen más típusú kapcsolathoz sincs szükség irányonként kettőnél több üzenet elküldésére. – A kapcsolatok során alkalmazandó

kriptográfiai algoritmusok és formátumok kiválasztásához szükséges egyeztetés keretein belül megválasztható opciókat kiterjesztették, ily módon többféle protokoll alkalmazható, ezen kívül a különböző protokollok egymástól függetlenül egyeztethetőek. A titkosító típusán és a szerver oldali tanúsítvány típusán kívül a PCT kliens és szerver megbeszélhetik a hash függvény típusát és a kulcscsere típusát is. Ha igény van a kliens hitelesítésére, a kliens oldali tanúsítvány típusa és az aláírás típusa is egyeztethető. – Az üzenetek hitelesítését átalakították, ehhez a PCT a titkosító kulcsoktól különböző kulcsokat használ. Ennek következtében a üzenethitelesítő kulcsok hosszabbak lehetnek, mint a titkosító kulcsok, és így a hitelesítés biztonságosabb lehet – Az SSL kliens oldali hitelesítésben talált biztonsági rést befoltozták: a PCT kliens hitelesítési kihívás-válasz folyamat a

kapcsolathoz választott titkosító típusától függ. Az SSL kliens hitelesítése független a választott titkosító erősségétől, valamint 46 attól is, hogy a hitelesítést egy régebbi kapcsolat újrafelépítése vagy egy új kapcsolat felépítése során alkalmazzák. Ennek következtében egy az SSL-kapcsolatot lehallgató közbeékelődéses típusú támadó, aki megszerezte egy gyenge titkosítással védett SSLkapcsolat viszonykulcsát, ezt a megszakadt kapcsolatot felhasználhatta arra, hogy egy erős hitelesítést alkalmazó SSL-kapcsolat klienseként építse fel újra a kapcsolatot. Ha például egy szerver bizonyos biztonság-érzékeny funkciókat csak a magas biztonsági szintű kapcsolatokra korlátozta, ez a biztonsági rés lehetővé tette a támadók számára, hogy megkerüljék a megszorítást a kapcsolat újraépítésével. – Végezetül a kézfogási protokollt kibővítették egy új mezővel, amivel a kliens és a szerver ellenőrizheti,

hogy a titkosító típusára (és egyéb paraméterekre) vonatkozó egyeztetések nem változtak meg a kommunikáció során. (Az SSL v3 verziója hasonló mechanizmust alkalmaz, azonban a korábbi verziókkal való teljes visszafelé kompatibilitás elnyomja ezek biztonsági funkcióit; az esetleges támadó egyszerűen megváltoztathatja a verziószámot a kézfogási protokoll során, és így a titkosító típusára vonatkozó paramétert is.) A protokoll tartalmaz néhány kisebb jelentőségű eltérést is; ezek a protokoll átfogó leírásával együtt megtalálhatóak a [27] munkában. 5.3 A TLS protokoll Bár nem sokban különbözik az SSL v3 verziójától, mégis célszerű ejtenünk néhány szót az 1999-ben az IETF által kidolgozott TLS (Transport Layer Security) protokollról [28] is. Létrehozását az internetes közösségek szabványos, szállítási rétegen működő biztonsági protokoll iránti igénye ösztönözte. A hangsúly a szabványosságon van: a

TLS-sel a Netscape „házi” szabványából valódi szabványt dolgoztak ki. A TLS teljesen hasonló rekordprotokollt és kézfogási protokollt alkalmaz, mint az SSL; mégis létezik néhány különbség közöttük, főleg a kézfogási protokoll kapcsán. Ha pár szóban akarnánk leírni a TLS rész-protokolljait, a következőképpen jellemezhetnénk ezeket: A rekord protokoll fogadja a felsőbb réteg entitásától a továbbítandó üzenetet, kezelhető méretű blokkokra tördeli, opcionálisan tömöríti, alkalmazza rájuk a hash üzenet-hitelesítő kódot (HMAC – Hash Message Authentication Code), majd titkosítja és továbbítja a blokkokat. A fogadó oldalon természetesen az inverz műveletek hajtódnak végre. (Megjegyezzük, hogy a blokkok szabványos veszteségmenetes tömörítő algoritmus használatával kerülnek tömörítésre A dolog érdekessége, hogy az eredeti (1.0 verziójú) TLS protokoll által támogatott tömörítési eljárás az ún

„CompressionMethod.null” eljárás, amely azt írja elő, hogy az adatok ne kerüljenek tömörítésre a kapcsolat során; később azonban definiáltak további tömörítőket is a TLS protokollhoz, egy ilyet ír le például a [29] dokumentum.) A kézfogási protokoll lehetővé teszi, hogy a kommunikáló felek egyeztessék a biztonsági paramétereket, hitelesítsék egymást, valamint hogy hibakörülményről tájékoztassák egymást (ezek a funkciók megtalálhatóak az SSL protokollban is). Egy további eltérés a TLS és az SSL között, hogy a TLS-ben új kriptográfiai eljárásokkal bővítették az SSL eszközkészletét; ilyen például a Triple-DES titkosító, az SHA hash függvény, a Diffie-Hellman kulcscsere, valamint a DSS digitális aláírási szabvány használata. Készültek egyéb bővítések és kiegészítések is a protokoll eredeti változatához, ezeket például a [30] dokumentum írja le. Az SSL és a TLS hét fő különbségét idézi a [31]

dokumentum Megjegyezzük, hogy a jelen dolgozat írása idején jelent meg a TLS protokoll 1.1es verziója [32], valamint a DTLS (Datagram Transport Layer Security) protokoll, amely tulajdonképpen a TLS protokoll datagram alapú, nem megbízható jellegű hálózatokra való kiterjesztése. A TLS egy másik kiterjesztése a vezetéknélküli hálózatokra és eszközökre kidolgozott WTLS protokoll, amely a TLS funkcionalitását viszi át a kevesebb erőforrással rendelkező kézi készülékekre. A következő pontokban az utóbbi két protokollt mutatjuk be 47 5.4 A WTLS protokoll Amint azt már említettük, a mobil eszközök egyre növekvő piaca is megkívánja a hagyományos, vezetékes rendszerek biztonságát; talán annál még erősebbet is. A WTLS (Wireless Transport Layer Security) protokoll ennek biztosítását célozza meg. Maga a protokoll a WAP (Wireless Application Protocol) biztonsági rétegén helyezkedik el (a WAP protokoll részletes bemutatását a jelen

dolgozat terjedelme nem engedi meg; a részleteket és a WTLS protokoll részletes leírását lásd a [33] műben), és az általa nyújtott biztonsági szolgáltatások is a hagyományos megközelítés szerint csoportosíthatóak: az adatintegritás és –titkosság biztosítása, hitelesítés, illetve a szolgáltatásmegtagadási támadások elleni védelem. Mindezeket ráadásul a mobileszközök meglehetősen csekély számítási kapacitását és sávszélességét figyelembe véve szükséges megvalósítani. A biztonságos WAP kommunikáció két fázisból áll: először a webkiszolgáló és a WAP-átjáró közötti adatátvitel történik meg, TLS-sel védett módon, majd a WAP-átjáró küldi tovább az adatokat (általában azoknak csak egy részét) a kézi készülék WAPböngészőjének, amit a WTLS véd. Ily módon a WAP-átjáró lesz a „híd” a WTLS és a TLS protokollok között. 5.41 A WTLS architektúra A WTLS rekord protokoll (Record Protocol)

rétegelt szerkezetű, ami az adatok integritását és hitelesítését végzi el. A rekord protokoll továbbítandó nyers adatot fogad a felsőbb rétegektől, opcionálisan tömöríti, alkalmazza rá a MAC kódot, majd titkosítja és továbbítja az adatot (tehát nem tér el a TLS hasonló funkciójától). A fogadó oldalon történik a fogadott adat visszafejtése, hitelesítése és kitömörítése, majd a felsőbb rétegeknek való átadása. A rekord protokoll négy részből (protokoll-kliensből) áll, ezek a kézfogási protokoll (Handshake Protocol), a figyelmeztetési protokoll (Alert Protocol), az alkalmazási protokoll (Application Protocol), és a titkosító specifikáció megváltoztatására használt protokoll (Change Cipher Spec Protocol). A jelen dolgozat szempontjából ezek közül az első és az utolsó érdekes, a továbbiakban ezeket nézzük meg részletesebben. 5.42 A kézfogási protokoll A biztonsággal kapcsolatos összes paraméter a kézfogás

során kerül egyeztetésre; a paraméterek magukban foglalják a protokollverziót, kriptográfiai algoritmusokat, valamint egy megosztott titok generálásához felhasznált hitelesítési és nyilvános kulcsú technikákkal kapcsolatos információkat. A WTLS kézfogási protokoll során a következő lépéseket hajtjuk végre: - Kezdeti (hello) üzenetek cseréje az algoritmusok egyeztetéséhez, valamint véletlenszerű értékek cseréje; - Kriptográfiai paraméterek cseréje, amelyek ahhoz szükségesek, hogy a kliens és a szerver megállapodhassanak egy előzetes mester titokban; - Tanúsítványok és más kriptográfiai információk cseréje a kölcsönös hitelesítéshez; - Mester kulcs generálása az előzetes mester kulcs és a véletlenszerű értékek alapján; - Biztonsági paraméterek átadása a rekord rétegnek; valamint - Mindkét oldalon annak ellenőrzése, hogy a társentitás ugyanazokat a biztonsági paramétereket számította ki, valamint hogy a

kézfogás anélkül zajlott le, hogy egy támadó megváltoztatta volna az üzeneteket. 48 5.43 A titkosító specifikációkat megváltoztató protokoll A TLS-hez hasonlóan itt is ez a protokoll szolgál a titkosítási stratégiák változtatásának jelzésére. A protokoll egyetlen üzenetből áll, amely az aktuális kapcsolati állapot alapján kerül titkosításra és tömörítésre Ezt az üzenetet azután küldhetjük el, miután a kézfogási protokollban a két fél megállapodott a biztonsági paraméterekben. 5.44 Kriptográfiai módszerek a WTLS-ben A protokoll mind szimmetrikus, mind pedig nyilvános kulcsú titkosítási módszereket alkalmaz: szimmetrikus titkosításra a DES, Triple-DES és RC5 algoritmusokat, az üzenetek hitelesítésére pedig a HMAC algoritmust, amely az üzenethez tartozó MAC kódot az SHA-1 vagy MD5 hash függvények felhasználásával számítja ki. A WTLS specifikáció része továbbá az elliptikus görbéken alapuló

kriptográfia (ECC – Elliptic Curve Cryptography) [62] is, figyelembe véve, hogy ez az új módszer az RSA funkcióit tökéletesen, de annál jóval gyorsabban látja el, és kevesebb CPU és memória erőforrást igényel. A specifikáció támogatja továbbá az AES (Advanced Encryption Standard, a DES felváltására kidolgozott kriptorendszer) [63] algoritmusát is. Verzió Aláírás algoritmusa Kibocsátó Érvényesség kezdete Érvényesség vége Tulajdonos Nyilvános kulcs algoritmusa Nyilvános kulcs paraméterei Nyilvános kulcs 5. ábra: A Szerver Tanúsítvány üzenet (Forrás: [33]) 5.441 Hitelesítés A WTLS a hitelesítési funkciót tanúsítványok felhasználásával látja el; a támogatott tanúsítvány-formátumok tartalmazzák a hagyományos X.509 formátumot, az X9.68 formátumot, valamint a WTLS saját, méretre optimalizált tanúsítványformátumát A szerver minden esetben hitelesen azonosítja önmagát a kliens felé, a másik irányú

hitelesítés opcionális Ugyanakkor a WTLS specifikáció értelmében a teljes hitelesítési mechanizmus is opcionális a kézfogási protokollon belül Ha viszont igény van rá, akkor az mindig a „hello” üzenetek cseréjét követően zajlik le, mégpedig oly módon, hogy a szerver elküld egy Szerver Tanúsítvány üzenetet (ennek szerkezetét az 5. ábrán mutatjuk be). Valójában a kliens egy tanúsítvány-listát kap, amelyben az első a szerver saját tanúsítványa A listában soron következő tanúsítvány mindig az azt megelőzőt hitelesíti A forgalom csökkentése érdekében a specifikáció lehetővé teszi, hogy a szerver csak egyetlen tanúsítványt küldjön el (mégpedig a saját tanúsítványát). Ha a fordított irányú hitelesítésre is szükség van, a szerver elküldhet egy tanúsítvány-kérési üzenetet is, amelyben megadhatja az általa elfogadott CA-k listáját. Ha a kliensnek 49 van tanúsítványa, elküldheti azt, de küldhet

üres üzenetet is. Ebben az esetben a kliens konkatenálhatja az összes addig fogadott üzenetet, kiszámíthatja ennek egy hash lenyomatát, és elküldheti a szervernek jelezvén, hogy a folyamat addig a pontig jól haladt. 5.442 Kulcscsere A fenti tanúsítvány-alapú kulcscserén kívül a specifikáció lehetővé teszi, hogy ha a szerver Tanúsítvány üzenete nem tartalmazott elég információt ahhoz, hogy a kliens végrehajthassa az előzetes mester titok cseréjét, a szerver explicit módon (a szerver Kulcscsere üzenettel) biztosíthatja ezeket az információkat. A WTLS kulcscserélő mechanizmusa lehetővé teszi az anonim kulcscserét is; ilyenkor a szerver Kulcscsere üzenete a szerver nyilvános kulcsát tartalmazza A kulcscserélő algoritmus lehet az RSA algoritmus, a Diffie-Hellman algoritmus vagy annak az elliptikus görbék számításán alapuló változata, az ECDH (Elliptic Curve Diffie-Hellman) [64] algoritmus. 5.45 Biztonsági problémák A vizsgálatok

számos problémát fedtek fel a WTLS-sel kapcsolatban; ezek közül az egyik legfontosabb, hogy a TLS és a WTLS nem teljesen kompatibilis egymással. Ha például a felhasználó a kézi eszközén keresztül kíván lebonyolítani egy vásárlást az Interneten keresztül, el kell küldenie a hitelkártya számát. A készülék felépít egy WTLS kapcsolatot a WAP-átjáróhoz, amely észreveszi, hogy biztonságos kapcsolat felépítésére van szükség, amit meg is próbál végrehajtani a TLS felett. A probléma abban rejlik, hogy a WAP átjáró nem tudja átvinni a WTLS kapcsolatot a szerverhez, mivel az csak a TLS-t ismeri. Az átjáró egyféleképpen tudja feloldani a problémát, mégpedig ha visszafejti a WTLS-üzenetet, majd újratitkosítja a TLS eszközeivel Ennél a pontnál az adat „meztelenné” válik, nem védi semmilyen titkosítás, bár a probléma feloldható, ha az átjáró biztosítja, hogy a memóriájához senki nem férhet hozzá kívülről. Ezen a

problémán kívül akad néhány kisebb is, ezek leírása megtalálható a [33] munkában, a WTLS és a WAP protokollok nagyobb részletességű leírásával együtt. 5.5 A DTLS protokoll A 2004-ben bemutatásra került DTLS (Datagram Transport Layer Security) protokoll [34] a TLS ellen kardoskodó (főleg IPSec-párti) biztonsági szakemberek azon vádjaira válasz, miszerint a TLS igazándiból csak megbízható (általában a TCP) szállítási csatorna felett használható, így nem képes a nem megbízható datagram-alapú forgalom védésére [35]. Ennek az oka viszonylag egyszerű: a csomagok elveszhetnek, illetve a sorrendjük megváltozhat. Ez motiválta a tervezési filozófiát, vagyis egy UDP csomagokon alapuló TLS-variáns kidolgozását Fontos tervezési szempont volt továbbá, hogy a szükségesnél nagyobb mértékben ne változtassák meg az eredeti TLS protokollban (közelebbről az 1.1 verzióban) specifikált struktúrát és funkciókat A következőkben csak

a két protokoll közötti különbségekre térünk ki. 5.51 Problémák és megoldások A megbízhatatlanság két fő területen okoz problémát a TLS számára: egyrészt a TLS forgalomtikosító rétege nem teszi lehetővé a rekordok egymástól független visszafejtését (vagyis ha az N. rekord nem érkezik meg, az N+1 rekord nem fejthető vissza), másrészt pedig a kézfogási protokoll megbízható kapcsolatot feltételez (vagyis a protokoll megszakad, ha valamelyik üzenet elveszik). Az első problémát úgy oldják meg, hogy az IPSec ESP-hez hasonlóan egy explicit állapotot vezetnek be a rekordokhoz, 50 valamint sorozatszámokkal látják el azokat. A második probléma megoldásához viszont újraküldési időzítéseket alkalmaznak További probléma, hogy az UDP datagramok rendszerint sokkal kisebbek (kb. 1500 bájt méretűek), mint a TLS és DTLS üzenetek (ezek a gyakorlatban néhány kilobájt nagyságúak), ezért az üzeneteket (már a kézfogási

protokoll során küldötteket is) fel kell darabolni alkalmas méretű partíciókra. Ehhez persze meg kell határozni az elküldhető UDP csomagok maximális méretét – erre szolgál a PMTU Discovery eljárás, mely részleteit itt nem mutatjuk be. Mivel az üzenetek is feldarabolásra kerülnek, az egyes üzenet-töredékeket pufferelni kell, míg az összes darab meg nem érkezik, ekkor lehet csak a szükséges választ elküldeni a másik félnek. A DTLS kézfogási protokoll három lényeges funkciótól eltekintve teljesen megegyezik a TLS hasonló protokolljával. A különbségek: - A DTLS állapot nélküli süti–cserét hajt végre a szolgáltatásmegtagadási (DoS) támadás kivédése céljából; - A kézfogási üzenetek fejrészét meg kellett változtatni az üzenetek elvesztésének, sorrendjük felcserélődésének és feldarabolásának kezeléséhez; és - Bevezették az újraküldési időzítőket az elveszett üzenetek újraküldéséhez. Mindazonáltal a

WTLS ugyanazon biztonsági szolgáltatások nyújtására képes, mint a TLS (többek között ez volt az egyik legfontosabb tervezési szempont), sőt, annál többre is, hiszen a sütik alkalmazásával a WTLS képes a DoS támadások kivédésére (természetesen a süti-mechanizmust egyáltalán nem vagy hibásan implementáló alkalmazások továbbra is támadhatóak ezzel a támadástípussal). Megjegyezzük továbbá, hogy a WTLS kifejezetten „megtiltja” az RC4 algoritmus használatát, a felhasználható algoritmuskészlet ezen kívül megegyezik a TLS-ben specifikált algoritmusokkal. A protokollról további részletek találhatóak a [36] munkában. 51 6. Hitelesítés az alkalmazási rétegen A hálózati réteggel foglalkozó fejezetben megemlítettük azt a vitát, ami azzal kapcsolatos, hogy a biztonsági szolgáltatásokat a hivatkozási modellek mely rétegén célszerű nyújtani. Időrendben az a megközelítés volt az első, amely az egyes alkalmazások

kommunikációjának védelmét az egyes alkalmazások szintjén, vagyis a réteg/protokollhierarchia legtetején valósította meg Ez a megközelítés egyben azt is jelentette, hogy a különböző alkalmazásokhoz külön, specifikus védelmi protokollokat kellett kialakítani. Manapság a védendő alkalmazások jellemzően négy csoportba sorolhatóak, egyfelől azért, mert ez a négy leggyakrabban igénybe vett alkalmazás-típus, másfelől pedig az egyes csoportok a megvalósítandó biztonsági szolgáltatások (ezen belül is a hitelesítés) más-más részterületeinek alkalmazását kívánják meg. A jelen fejezet ezért az elektronikus levelezéssel és dokumentumcserével (külön kitérve a digitális aláírások alkalmazási területeire), az elektronikus vásárlással és tranzakciókkal, az általános webes biztonsággal, valamint az erőforrások távoli menedzselésével és a jogosultságvizsgálattal foglalkozik. 6.1 Elektronikus levelezés és

dokumentumcsere A PGP bemutatásával foglalkozó részben utaltunk rá, hogy az elektronikus dokumentumok cseréjekor több hitelességgel és hitelesítéssel kapcsolatos tényezőt is figyelembe kell vennünk. Meg kell tudnunk győződni arról, hogy a dokumentumot valóban azt küldte, aki a dokumentumban vagy az e-mailben küldőként szerepel (hiteles személyazonosítás); biztosítanunk kell, hogy a küldés során a dokumentumot ne változtathassák meg, vagy ha mégis, lehetőségünk legyen ennek felismerésére (integritásvizsgálat); valamint mechanizmust kell biztosítanunk annak megelőzésére, hogy a feladó utólag ne tagadhassa le a dokumentum küldésének tényét (letagadhatatlanság). Ebben a pontban olyan protokollok közül mutatjuk be a legelterjedtebbeket, amelyek a fenti szolgáltatások mindegyikét támogatják. Külön kitérünk a digitális aláírások felhasználására az ilyen jellegű alkalmazásoknál, valamint áttekintő jelleggel bemutatjuk a

magyar digitális aláírásról szóló törvényt, amely előírásokat és ajánlásokat tesz ezzel kapcsolatban. 6.11 A PEM protokoll A PEM (Privacy-Enhanced Electronic Mail) nem csak egy egyszerű elektronikus levélküldő és -fogadó alkalmazás: egy mögöttes kulcskezelési infrastruktúrát is definiál [37]. A kettő együtt hatékony, és főleg biztonságos elektronikus üzenetküldési lehetőséget biztosít, szabványos módon (ezeket az RFC 1421-1424 dokumentumok [38] definiálják) A PEM szimmetrikus és aszimmetrikus technikákat is alkalmaz az üzenetek védéséhez. A szimmetrikus technikák akár a kulcskiosztás esetén is alkalmazhatóak, bár a protokoll ezt erősen ellenjavallja, csakúgy, mint az üzenetek és tanúsítványok aláírása és hitelesítése esetében. A PEM minden üzenet esetén alkalmazza az eredethitelesítési, integritásvizsgálati és letagadhatatlansági funkcionalitást, a titkosítás viszont opcionális A titkosítást a DES

algoritmussal végzi, az integritásvizsgálathoz az MD2 és MD5 hash függvényeket használja, míg a személyhitelesítés X.509 tanúsítványokkal és RSA kulcskiosztással valósul meg 52 6.111 A küldő hiteles azonosítása A PEM a küldő meghatározására tanúsítványokat használ, amelyet egy az RFC 1422 dokumentumban definiált, az X.509 szabványban definiálttal kompatibilis, bár annál valamelyest egyszerűbb hierarchikus hitelesítési keretrendszer támogat. Ez a keretrendszer négy entitást ismer. A sorban a legelső a hierarchia gyökereként funkcionáló IPRA (Internet Policy Registration Authority) Ez az entitás adja az összes tanúsítvány-alapú kulcshitelesítés alapját a hierarchián belül, valamint ez felelős a következő szinten lévő entitások hitelesítéséért és az irányelveik felülvizsgálatáért Ezen a következő szinten találhatóak a PCA (Policy Certification Authority) entitások, amelyek feladata a következő szinten

elhelyezkedő, már jól ismert hitelesítés-szolgáltatók (CA) hitelesítése. A CA entitások az alárendelt CA-kat és az egyedi felhasználókat hitelesítik, ezek helyezkednek el a hierarchia legalsó szintjén A hierarchia ugyanazon előnyökkel és hátrányokkal rendelkezik, mint amelyeket a hierarchikus bizalmi hálókkal kapcsolatban említettünk. 6.112 Az üzenetek titkosítása A PEM az RFC 1423 dokumentumban specifikált (szabványos) algoritmusokat használja az üzenetek titkosítására. Ez a dokumentum egyetlen szimmetrikus algoritmust, a DES láncolt módú (DES-CBC) variánsát definiálja a szimmetrikus titkosításhoz, míg a szimmetrikus kulcskezeléshez a DES 64 bites kulcs-párokat alkalmazó ECB és EDE módjait engedi meg [1]. Az aszimmetrikus kulcskezelés az RSA algoritmussal valósulhat meg 6.113 Üzenet típusok A PEM négyféle üzenet-típust definiál: hagyományos, nem védett üzenetek; integritásvédelemmel ellátott, de módosítatlan

(MIC-CLEAR) üzenetek; integritásvédelemmel védett és kódolt (MIC-ONLY) üzenetek; valamint kódolt, titkosított és integritásvédelemmel ellátott (ENCRYPTED) üzenetek. A kódolt kitétel itt azt jelenti, hogy az eredeti üzeneteket 6 bitenként kódolja 8 bites karakterekké a hordozhatóság végett. 6.114 PEM üzenetek létrehozása – a szöveg átalakítása A PEM üzenet két fő részből áll: a fejrészből és a szövegből. A fejrész kis mértékben kerül csak átalakításra, esetleg a Tárgy (Subject) mező változhat (titkosítás esetén a mező „tikosított üzenet” értéket kaphat) Az üzenet viszont egy három lépésből álló transzformáció-sorozat végrehatása során alakul át: az első lépés az úgynevezett SMTP kanonikus alakra hozás (ez az SMTP [65] szabvány 7-bites ASCII formátuma), a második az üzenet integritási kód (MIC – Message Integrity Code) kiszámítása, míg a harmadik az opcionális titkosítás, amit egy szintén

opcionális 6-bites kódolás követ. A második lépés lehetővé teszi szimmetrikus módszerek alkalmazását, de általában az aszimmetrikus módszereket alkalmazzák – mindkét esetben a fejrész MIC-Info mezőjében meghatározott algoritmussal. Ha a küldő titkosítást igényel, akkor még ebben a lépésben létrehozunk egy csak erre az üzenetre érvényes (szimmetrikus) üzenet kulcsot, majd ezzel a kulccsal, és a fejrész DEK-Info mezőjében megadott titkosító algoritmussal titkosítjuk az üzenetet (az algoritmus egyéb paramétereit is tartalmazza a fejrész). Hangsúlyozzuk, hogy a titkosítást csak akkor hajtjuk végre, ha az üzenet típusa ENCRYPTED Végül a harmadik lépésben az ENCRYPTED vagy MIC-ONLY üzeneteket SMTP protokollal való átvitelre alkalmas formára hozzuk: a szöveget egy 6- 53 bites ábécé feletti titkosított szöveggé alakítjuk át. A MIC-CLEAR típusú üzenetekre nem hajtjuk végre a harmadik lépést. 6.115 PEM üzenetek

létrehozása – a fejrész kialakítása Az üzenet szövegének átalakítása után hozzuk létre a fejrészt, amely lépései az alkalmazott kriptográfiai módszerektől függenek. Mivel a protokoll a nyilvános kulcsú módszereket ajánlja, mi is az ily módon létrejövő fejrészformátumot mutatjuk be. Az adateredet-hitelesítéshez, az integritásvizsgálathoz, valamint a letagadhatatlanság támogatásához a fentiekben a 2. lépésben kiszámított MIC értéket a küldő nyilvános kulcsának privát párjával titkosítjuk, vagyis digitális aláírást hozunk létre. Ha az üzenet ENCRYPTED típusú, ezt az aláírást titkosítjuk az üzenet-kulccsal (amit magának a szövegnek a titkosítására is használtunk). Ezt az értéket helyezzük el a MIC-Info mezőben, a létrehozáshoz használt MIC algoritmus és a digitális aláírási algoritmus azonosítóival együtt Ha az üzenet titkosított, a titkosítási algoritmus azonosítója és a paraméterek a DEK-Info

mezőbe kerülnek A bizalmasság biztosításához az üzenet kulcsot titkosítjuk a címzett nyilvános kulcsával (több címzett esetén az egyes címzettek nyilvános kulcsával titkosítjuk az üzenet kulcs egy-egy példányát), majd elhelyezzük a Key-Info mezőben, amit a nyilvános kulcsú algoritmus azonosítója követ. Minden KeyInfo mezőt megelőz egy Recipient-ID-Asymmetric mező, ami a fogadót azonosítja (az X.500 megkülönböztetett nevével és a tanúsítvány sorozatszámával) A küldő csatolhatja a saját tanúsítványát (az Originator-Certificate mezőben), illetve a tanúsítványát hitelesítő entitás tanúsítványát, és így tovább. Az üzenetek fogadásakor ezen mezők alapján dönthetőek el a hitelességgel és integritással kapcsolatos kérdések; ezek a fentiekben már vázolt mechanizmusokkal analóg műveletek, azért bemutatásukat itt mellőzzük. 6.116 A PEM értékelése Bár a PEM mérföldkőnek számít az elektronikus

üzenetküldés területén, mégsem bizonyult maradandónak; ennek két fő okát említjük meg. Először is a PEM szintaxisú üzenetek nem voltak kompatibilisek az akkoriban (1993-ben) már elterjedt MIME szintaxissal, másrészt pedig a PEM kulcskezelő infrastruktúrája, illetve annak hitelesítési hierarchiája túlságosan merev volt. Ráadásul a PEM csak tiszta (RFC 822 szintaxisú [39]) szöveg küldésére volt képes, azonban a felhasználóknak meglehetősen természetes elvárása volt, hogy akár csatolt képeket, vagy egyéb (nem szöveges) üzeneteket is elküldhessenek ugyanolyan szintű biztonsággal védve, ezért hamarosan további, rugalmasabb protokollokat dolgoztak ki. 6.12 Az S/MIME protokoll Ilyen protokoll az 1992-ben kidolgozott MIME (Multipurpose Internet Mail Extensions) szabvány is, amely tulajdonképpen nem más, mint különféle formátumú adatok (objektumok) elektronikus levelekben való elhelyezését lehetővé tevő szabvány. (Ez

meglehetősen sarkított fogalmazás; a szabványt ennél jóval több célra is fel lehet használni.) A szabvánnyal az üzenetek tartalmazhatnak képeket, hangokat, videót, bináris adatokat, többféle betűtípussal íródott szövegeket, egyéb objektumokat, valamint lehetővé teszi a korlátozás nélküli üzenethosszt. Ennél a szabványnál is nagy hangsúly helyeződik a fejlécre, hiszen ez írja le az üzenet által tartalmazott objektumokat. A MIME üzenetek formátumára nem térünk ki részletesen, azokat az RFC 2045-2049 dokumentumok [40] írják le. A MIME önmagában nem támogatja kellő 54 mértékben az elektronikus levélküldés biztonságát, ezért hamarosan napvilágot látott annak biztonságos kiterjesztése, az S/MIME. Az S/MIME (Secure Multipurpose Internet Mail Extensions) egy az RSA Inc. által javasolt, mára rendkívül elterjedtté vált szabvány [41], amely 3-as verziójú változata már olyan biztonsági szolgáltatásokat is nyújt, mint

a tértivevényes levelek és a biztonságos levelezési listák létrehozása és alkalmazása. A szabvánnyal egy MIME entitásból készíthetünk titkosított vagy aláírt MIME entitást Az S/MIME nem korlátozódik a levelezésre; általános üzenetformátumot biztosít, amelyet számos más területen is alkalmazhatunk (legalábbis ott, ahol MIME entitások használata indokolt). Az S/MIME a biztonsági funkciókhoz az X.509 tanúsítvány-formátumot alkalmazza, míg az üzenetek törzsére a PKCS#7 [66] előírásait követi A PKCS#7 objektumok különböző típusúak lehetnek A Data típusú objektumok egyszerű adatokat tartalmaznak, és a titkosítandó MIME formátumú levélből először egy ilyen típusú PKCS#7 struktúrát hozunk létre. A SignedData típus már digitális hitelesítési információkat is tartalmaz Tartalmazhat tanúsítványokat is, illetve tetszőleges számú aláíró azonosítóját Ezekhez az aláírókhoz tartozhatnak attribútumok, illetve

az attribútumok összességéből képzett hash értékek, a küldő privát kulcsával titkosítva Ilyen attribútumok lehetnek például a MessageDigest érték (ami az üzenet törzsének hashértékét tartalmazza); a SigningTime érték (a levél aláírásának időpontja); illetve az SMIMECapabilities (itt vannak felsorolva az aláíró által támogatott kriptográfiai algoritmusok azonosítói a preferált sorrendben). A szabvány egyébként az RSA, SHA-1 és az RC2/40 (40-bites szimmetrikus titkosító [6]) ismeretét kötelezően előírja, és a Triple-DES használatát javasolja. További fontos adattípus még az EnvelopedData, amely tartalmazza az adatokat egy szimmetrikus kulccsal tikosítva, valamint a szimmetrikus kulcsot az aláírók magánkulcsával titkosítva. Az S/MIME formátumú levelek lehetnek aláírva, titkosítva, illetve mindkettő (a szabvány lehetővé teszi a titkosítást követő aláírás és az aláírást követő titkosítás

végrehajtását is). Az S/MIME üzenetek létrehozása során először a levelet MIME formátumúra alakítjuk át (bináris csatolt fájlok átalakítása stb), majd ebből PKCS#7 Data típusú objektumot készítünk. Ezt beillesztjük egy SignedData típusú objektumba, és aláírjuk. Az objektum lényegileg nem más, mint egy bitsorozat, ezért ebből készíthetünk egy MIME entitást, amiből ismét PKCS#7 Data típusú objektumot készíthetünk A következő lépésben ez utóbbi objektumot egy véletlenszerűen generált szimmetrikus kulccsal titkosítjuk, majd beletesszük egy EnvelopedData típusú objektumba, a címzettek nyilvános kulcsával titkosított üzenet-kulccsal együtt. Az utolsó lépésben (az utóbbi objektumot ismét bitsorozatnak tekintve) elkészítjük a végső application/pkcs7-data típusú elküldendő üzenetet. Látható, hogy a módszer meglehetősen „tekervényes”, és viszonylag sok számítási időt is igényel, mindazonáltal a módszer

stabil, és megfelelő biztonságot nyújt az elektronikus üzenetcseréhez A szabványról további részletes információ található például a [42] dokumentumban 6.13 A PGP protokoll A Phil Zimmermann által 1991-ben létrehozott kriptorendszer némely komponenséről (nevezetesen a tanúsítványformátumáról és a bizalmi modelljéről) már említést tettünk a 3. fejezetben, ezért most ezeket mellőzve a biztonságos elektronikus levélküldési funkcionalitását vizsgáljuk meg részletesebben 6.131 A PGP története A PGP lehetővé teszi mind a nyilvános, mind a szimmetrikus kulcsú titkosítás használatát (az utóbbi esetben persze a feleknek előzőleg valamilyen módon meg kell egyezniük a kulcsban). A korábbi verziók (az RFC 1991 munkában [43] dokumentált 2.7 verzióig) csak az RSA, MD5, IDEA algoritmusok használatát teszik lehetővé Kez- 55 detben a PGP egy saját szövegformátumot használt (az „ascii armor” formátumot) az üzenetek

„belső szabványos” szöveggé való alakítására, ezért a levélben érkezett üzeneteket a PGP-vel kellett feldolgozni. Később (az RFC 2015 dokumentumban [44]) leírták, hogy hogyan lehet az üzeneteket szabványos MIME formátumúra alakítani az application/pgp-encrypted MIME típus felhasználásával. A PGP támogatja az üzenetek tömörítését a jobb erőforrás-kihasználás érdekében. A PGP 5. verziójától kezdve jelentős változások jelentek meg a PGP-ben (ettől kezdve hívják OpenPGP-nek, amit az RFC 2440 [45] definiál). Lehetőséget nyújt szinte valamennyi ismert kriptográfia algoritmus használatára. A levelezőprogramok a levélben felsorolják az általuk ismert, illetve preferált algoritmusokat, és így egyeztetik, hogy melyiket használják. A javasolt kombináció a TripleDES, ElGamal [6] és az SHA-1 használata. 6.132 PGP üzenetek létrehozása A PGP az egyik első olyan elektronikus levélküldő alkalmazás volt, amely nyilvános

kulcsú infrastruktúrára támaszkodott; ennek megfelelően a biztonságot megvalósító algoritmusok között is hangsúlyozott szerepet kapnak az aszimmetrikus kulcsú kódolók (előnyösen az RSA); ugyanakkor magának az üzenetnek a titkosítására sebességgel kapcsolatos megfontolások miatt szimmetrikus algoritmusokat (előnyösen az IDEA-t) alkalmaz. Az üzenetpecséteket az MD5 algoritmussal hozhatjuk létre A biztonság növelése érdekében a rendszerben minden felhasználó több kulcs-párral is rendelkezik, amelyek nyilvános párja egy úgynevezett kulcskarikára (keyring) van felfűzve. A kulcsokat azonosítóval különböztetjük meg egymástól, mivel ezekre a levélküldés során hivatkoznunk kell (az üzenet tartalmazni fogja az azonosítót); ez a kulcs alsó 64 bitje. A PGP egyébiránt 348, 512 és 1024 bites kulcsokat támogat Az üzenetküldés során feltesszük, hogy a küldő és a fogadó előzetesen ismeri a másik nyilvános kulcsát (ha nem így

lenne, a 3. fejezetben ismertetett módszerek segítségével egyszerűen megszerezheti azt) Az első lépésben a küldő az MD5 algoritmussal elkészíti az eredeti üzenet hash lenyomatát, majd titkosítja azt a magánkulcsával A következő lépésben összefűzi az eredeti szöveget a lenyomattal, majd tömöríti a ZivLempel eljárással (P1.Z) Ezt követően egy véletlenszerű érték alapján (például a felhasználó begépel egy véletlenszerű karaktersorozatot, vagy az egérmozgatásból generálunk ilyet) az IDEA algoritmus előállít egy 128 bites szimmetrikus kulcsot, amit a fogadó nyilvános kulcsával titkosítunk, valamint az IDEA algoritmussal titkosítjuk a P1.Z bitsorozatot Utolsó lépésként a két kódsort összefűzzük, és a Base-64 [67] eljárással kódolva továbbítjuk 6.133 A PGP üzenetek szerkezete A PGP üzenet három fő részből áll. Az Üzenetkulcs részben helyezkedik el a címzett nyilvános kulcsának azonosítója és az üzenetkulcs.

Ezt követi az Aláírás rész, amelyben az aláírás fejrésze és az aláírás időpontja, valamint az aláíró nyilvános kulcsának azonosítója és maga az MD5 hash érték szerepel. Az PGP üzenet harmadik része az Üzenet rész, amely tartalmazza az üzenet fejrészét, a csatolt fájlok nevét, a létrehozás időpontját (ami nem feltétlenül egyezik meg az aláírás időpontjával), valamint magát az üzenet szövegét. Az Aláírás és az Üzenet részek tömörítve és IDEA-val titkosítva vannak, és az ehhez hozzáfűzött Üzenetkulcs résszel együtt Base-64 eljárással kerülnek kódolásra. 56 6.134 A PGP üzenetek elolvasása A fogadott üzenetet először Base-64-gyel vissza kell kódolni, ami után már leválasztható a kulcsot tartalmazó sáv, amit a fogadó magánkulcsával visszafejtve megkaphatjuk az üzenetkulcsot. A kulcs birtokában visszakaphatjuk a P1Z bitsorozatot, és mivel ez veszteségmentes tömörítés, abból egyszerűen

visszaállíthatjuk az eredeti üzenetet és az aláírást. Az aláírásból a küldő nyilvános kulcsának ismeretében visszafejthetjük a hash értéket, és ezt összevetve az eredeti üzenetből a fogadó által előállított hash értékkel biztosak lehetünk benne (ha a kettő megegyezik), hogy az üzenet valóban a küldőtől származik, és az üzenet tartalma nem módosult az aláírás időpontja óta. Ha a kulcsok hitelesítettek (például valamely mögöttes PKI infrastruktúra felhasználásával), a PGP módszer igen erős biztonságot nyújthat, természetesen a választott kulcsok kriptográfiai ereje által szabott határokon belül 6.14 Az elektronikus aláírás és jogi vonatkozásai Az elektronikus levélküldés fenti módszereiben a biztonságot minden esetben az adta, hogy a szimmetrikus és nyilvános kriptográfiai módszerek (és az esetleges háttérintézmények) segítségével egyértelműen megbizonyosodhattunk a küldő személyéről, valamint

az üzenet sértetlenségéről. Azzal, hogy a küldő fél elkészíti az elküldést megelőzően a levél hash lenyomatát, majd a magánkulcsával titkosítja azt, lényegileg a küldőhöz (és kizárólag hozzá) tartozó digitális aláírással látja el az üzenetet. Ez a technika azonban nem korlátozódik az elektronikus levelekre: tetszőleges elektronikus dokumentumot elláthatunk digitális aláírással Az aláírási mechanizmus alapja minden esetben megegyezik, ezért erre ebben a szakaszban nem térünk ki; mindazonáltal a felhasználható technikák bőséges választéka meglehetősen széles kombinációs spektrumot nyújt, továbbá a digitális aláírásban rejlő potenciált a köznapi élet (például a gazdaság vagy a közigazgatás) szereplői számos, egymástól gyakran nagyon különböző, de minden esetben emelt szintű biztonságot igénylő területen használják ki. Mindenképpen indokolt tehát, hogy az államigazgatás a megfelelő szintű

döntések meghozatalával a hagyományos, papíralapú társaival egyenrangú szerepkörrel ruházza fel az elektronikus aláírást és az azzal aláírt dokumentumokat. Ebben a fejezetben a digitális aláírások felhasználásának jogi hátterével és közigazgatási szabályozásával foglalkozunk. 6.141 Az elektronikus aláírásról szóló törvény háttere A Magyar Köztársaság Országgyűlése 2001-ben fogadta el a 2001./XXXV számú, elektronikus aláírásról szóló törvényt [46], amely nemzetközi (az Európai Közösség „1999/93/EC Directive on Electronic Signatures” című direktívája) és hazai (a Miniszterelnöki Hivatal Informatikai Kormánybiztossága – MEH-IKB, illetve utódja, az Informatikai és Hírközlési Minisztérium – IHM által kidolgozott) ajánlások alapján került megalkotásra. A törvény definiálja az elektronikus aláíráshoz kapcsolódó fogalmakat (például elektronikus dokumentum, elektronikus aláírás, digitális

aláírás stb.), az elektronikus aláírás létrehozásának és ellenőrzésének folyamatát és szereplőit, valamint a minősítési és felügyeleti funkciók szereplőit és jogállását. A törvény célját és álláspontját talán a törvényhez kiadott ajánlás fogalmazza meg a legérthetőbben; ebből idézünk néhány alapelvet [47]: - „Az elektronikus aláírásokról és iratokról indokolt az Európai Közösség vonatkozó Irányelveivel összhangban levő jogszabályt alkotni. A tárgy jelentőségére és az érintett jogviszonyokra tekintettel törvényi szabályozás szükséges.” - „Technológia független szabályozás szükséges.” 57 - „Az elektronikus aláírásokat és iratokat általános érvénnyel el kell ismerni, amely szerint elfogadásuk nem tagadható meg csupán elektronikus jellegük miatt.” - „Az aláírás hitelesítés nem hatósági tevékenység, hanem szabadon végezhető piaci szolgáltatás. Meg kell teremteni az

elektronikus aláírással kapcsolatos szolgáltatások törvényességi, technikai felügyeletét” - „A minősített elektronikus aláírással ellátott elektronikus irathoz a teljes bizonyító erejű magánokirati – illetve a kiállító szervezetre tekintettel közokirati – minőséget kell rendelni.” - „A minősített hitelesítés-szolgáltató a törvényben előírt mértékben felelős az általa kiadott tanúsítványokért.” - „A minősítési rendszer nem korlátozhatja azt a jogot, hogy az elektronikus aláírás és irat kölcsönös elfogadásának feltételeiről a felek szabadon megállapodjanak.” - „A törvényben meghatározott általános elveket és eljárásokat az állami/közszféra területén is alkalmazni kell azzal az eltéréssel, hogy az államhatalmi, bírói, ügyészi, központi és helyi közigazgatási szervek, valamint önkormányzatok elektronikus aláírásainak hitelesítésére a törvény felhatalmazása alapján, a Kormány

határozza meg azokat a követelményeket, amelyeknek az ebben a körben tevékenykedő hitelesítés-szolgáltatónak vagy hitelesítés-szolgáltatóknak meg kell felelniük.” - „Az elektronikus irat és aláírás alkalmazását az ügyfelet érintően nem lehet kötelezővé tenni. A bírósági és egyéb hatósági eljárás során beadványként nem minősített elektronikus aláírással ellátott elektronikus irat is elfogadható, hacsak az adott esetben más jogszabály ennél szigorúbb feltételeket nem követel meg.” - „A szabályozás hatálya ne terjedjen ki az elektronikus irat tartalma titkosításának kérdéskörére.” 6.142 Elektronikus aláírás a törvény szellemében Az elektronikus aláírást (nem teljesen meglepő módon) elektronikus dokumentumok aláírására használjuk. A törvény az elektronikus dokumentumból háromfélét különböztet meg. Az első az elektronikus aláírással ellátott általános jelsorozat (pl: szöveg, kép,

hangfelvétel, videófelvétel); a második szintként meghatározott elektronikus irat már jellemzően szöveg, de társulhat hozzá fejléc vagy ábra is; míg a törvény a 3. szintként az elektronikus okiratot ismeri el, amely már jogokat és kötelezettségeket is rögzít Az elektronikus okirat aláírója vállalja és elismeri a benne foglalt jogokat és kötelezettségeket. Az elektronikus aláírásról szóló törvény nem határoz meg egyértelműen módszert az aláírás létrehozására, mindazonáltal a törvény értelmében öt főbb tulajdonsággal kell rendelkeznie: egy adott elektronikus aláírásnak csak egy és kizárólag egy tulajdonosa lehet; lehetővé teszi az aláíró személyének egyértelmű meghatározását; az aláírónak kizárólagos lehetősége van aláírásának elkészítésére; egyértelműen megállapítható az aláírt elektronikus irat bármely, az aláírást követő véletlen vagy szándékos módosulása; és további

technológiai elemek, illetve szolgáltatások alkalmazásával az aláírás hiteles időpontja is csatolható az elektronikus irathoz. (Láthatjuk, hogy a korábbi fejezetekben bemutatott módszerek és technikák biztosítják ezen tulajdonságok teljesülését, vagyis a törvény inkább csak „legitimálta” a már meglévő módszereket, lehetővé téve az aláírás jogi értelemben vett biztonságát is.) A magyar törvény az elektronikus aláírások három típusát különbözteti meg Egyszerű elektronikus aláírás a dokumentumhoz (amely nem csak szöveg, hanem kép és hang is lehet) hozzárendelt olyan elektronikus adat, amely egyértelmű logikai kapcsolatot ad meg a feladó és a dokumentum között. Nem bír jogi bizonyító erővel, egy esetleges jogvita esetén a bíróságtól függ, hogy elfogadja-e vagy sem A fokozott biztonságú elektronikus aláírás meghatározott biztonsági feltételeknek eleget tevő elektronikus adat (pl. minden módosítás

detektálható a dokumentumon), amely alkalmas az aláíró azonosítására, és jogi bizonyító ereje van. Végül a minősített elektronikus aláírás a Hírközlési Főfelügyelet (HIF) által minősített hitelesítés-szolgáltatónál nyilvántartott elektronikus aláírás. Tel- 58 jes bizonyító erővel bíró okirat, amely jogilag egyenértékű egy 2 tanú jelenlétében aláírt okirattal. 6.143 Az elektronikus aláírás alkalmazásának szereplői A magyar törvény az aláírás alkalmazásának három szereplőjét különbözteti meg a jogok és a kötelezettségek alapján; ezek az aláírás tulajdonosa, az irat ellenőrzője, és a hitelesítés-szolgáltató. Az aláírás tulajdonosa - az aláírása hamisítását megelőzendő – köteles biztonságosan őrizni a magánkulcsát úgy, hogy ahhoz illetéktelen személy (vagyis rajta kívül senki más) ne férjen hozzá. Ha elveszik, vagy más megszerzi a magánkulcsot, köteles azonnal a

hitelesítés-szolgáltató felé jelezni a kulcs érvénytelenítése, letiltása érdekében Az irat ellenőrzője az irat átvételét követően a hitelesítés-szolgáltató segítségével meggyőződhet az irat hitelességéről, és az aláíró személyéről A hitelesítés-szolgáltató köteles a nyilvános kulcsot nyilvánosan kezelni és kérésre rendelkezésre bocsátani, az ügyfeleiről és a kiadott kulcsokról megbízható, illetéktelen módosítást kizáró módon nyilvántartást vezetni, s a kulcsot a tulajdonos kérésére, valamint bíróság, vagy más erre jogosult szerv határozata alapján érvényteleníteni Itt megint megjegyezzük, hogy a fenti kötelezettségek lefedik az előzőekben (például a nyilvános kulcsú infrastruktúrák kapcsán) tárgyalt szereplők által nyújtott szolgáltatásokat, azzal a különbséggel, hogy míg ott ezek inkább csak a szereplők által nyújtott (opcionális) szolgáltatásokat írtak le, addig itt sokkal

inkább (jogi értelemben vett) kötelezettségekről van szó. 6.144 Minősítés és felügyeleti szervek A nyilvános kulcsú kriptográfiai módszereken alapuló rendszerek előnye az, hogy az elektronikus iratok cseréje során nincs szükség a küldő és címzett személyes találkozására; pont emiatt viszont az aláíró személyének hiteles azonosításához harmadik (jogi) személyre, a hitelesítés-szolgáltatóra van szükség, aki olyan elektronikus tanúsítványt állít ki, amely hitelesíti az aláíró személyét és az elektronikus üzenetet, iratot, a címzett pedig egyértelműen meggyőződhet azok hitelességéről. Az aláírás felhasználási céljától függően különböző megbízhatóságú tanúsítványra lehet szükség, ily módon a hitelesítés-szolgáltató különféle megbízhatósági szinttel rendelkező tanúsítványt állíthat ki. Egyszerűbb esetben az ügyfél kérésére (általában minimális felelősségvállalás mellett)

minősítetlen (vagy egyszerű) tanúsítványt ad ki Ez történhet például elektronikus levélben érkező kérésre, amikor is az aláírás tulajdonosának a személyét alig vagy egyáltalán nem ellenőrzi a hitelesítés-szolgáltató. Nagyobb értékre vonatkozó kötelezettségvállaláshoz a törvény nem ajánlja az ilyen tanúsítványok használatát, ami egy meglehetősen természetes javaslat. Ilyen esetekre a törvény a fokozott biztonságú vagy minősített tanúsítványok használatát ajánlja A minősített aláírásra vonatkozó tanúsítvány kiadásakor szigorú előírások betartására van szükség. Az előírások kiterjednek mind az aláírás leendő tulajdonosa személyének az ellenőrzésére, a kulcsok generálására, tárolására, visszavonására, a használt informatikai eszközök minőségére, stb. A hitelesítés-szolgáltatások biztonságának emelése érdekében lehetőség van a hitelesítés-szolgáltatók önkéntes alapon való

minősíttetésére, akkreditálására, ugyanakkor ez szükséges feltétele annak, hogy a szolgáltató emelt biztonsági szintű tanúsítványokat adhasson ki Az EK Irányelv szerint a hitelesítésszolgáltatók szolgáltatás-nyújtását engedélyhez nem kötheti a szabályozás A szolgáltatás minőségének a biztosítása önkéntes alapon akkreditálható, ehhez köthető a minősített hitelesítés-szolgáltatóként való működés A magyar jog szerint a hazai akkreditálást a Nemzeti Akkreditáló Testület végzi el 59 A minősített tanúsítvány kiadásával kapcsolatos eljárások betartásának a biztosításához és a piac biztonsága érdekében megengedhető az állami felügyelet, amely nem azonos az engedélyezéssel. A Felügyelet nyilvántartást végez a minősített hitelesítés-szolgáltatókról, amit a piac szereplői megismerhetnek A minősített aláírásokat nyújtó hitelesítés-szolgáltatóknak 30 nappal a működésük megkezdését

megelőzően bejelentést kell tenniük, ezen kívül be kell jelentkezniük az adatvédelmi nyilvántartásba is. A HIF rendszeresen ellenőrzi a hitelesítés-szolgáltatók működését, és ha szabálytalanságot fedez fel, akkor a figyelmeztetésen túl pénzbüntetést is kiszabhat (a céget sújtó büntetés 100 ezer forinttól akár 10 millió forintig is terjedhet majd, az ügyvezetőt pedig 50 ezertől 1 millió forintig büntethetik), visszavonhatják a kiadott tanúsítványokat, sőt igazán súlyos esetekben a nyilvántartásból is törölhetik a szolgáltatót [47]. 6.145 Hazai hitelesítés-szolgáltatók A hazai piacon már a törvény 2001-es érvénybe lépését megelőzően is működtek hitelesítés-szolgáltatással foglalkozó cégek, ezek közül a négy legrégebbi piaci szereplőről ejtünk néhány szót [48]. Közülük a 8 éve alapított NetLock Kft. foglalkozik a legrégebben (7 éve) az elektronikus hitelesítéssel 2002-ig körülbelül 100000

tanúsítványt bocsátottak ki, túlnyomórészt ingyenesen, elektronikus postafiókok azonosításához A személyes és szervezeti tanúsítványok kibocsátása mellett internetes kiszolgálók hitelesítését is végzik, valamint kiadnak láncolt tanúsítványokat is, ami annyit tesz, hogy egy teljes tanúsítvány-kibocsátási rendszer kialakításával az ügyfél szervezetet feljogosítják újabb, nagy tömegű tanúsítvány kibocsátására, és ezek hitelességét a NetLock elismeri. A Microsec Számítástechnikai Fejlesztő Kft. 6 éve bocsát ki tanúsítványokat, ez idő alatt néhány száz, cégképviselői szerepkörhöz kötött tanúsítványt adtak ki. Ezeket a pénzintézetek használják elektronikus változásbejegyzési kérelmek benyújtására az ország cégbíróságain működő ügyfélszolgálati irodákban. Mindemellett a társaság magánszemélyeket is kiszolgál A Matáv Rt. a német anyacége, a Deutsche Telekom segítségével végzi (1998

óta) elektronikus aláírás-hitelesítési szolgáltatását. Egy ideig elsősorban közép- és nagyvállalatok szolgáltatójaként működött, de mára már magánszemélyek is elérhetik az Eszignó szolgáltatást Az általuk használt minden eszköz rendelkezik minősítő tanúsítvánnyal, így megfelelnek a minősített tanúsítványok kiadásához szabott összes feltételnek Negyedikként említjük meg a bankközi elszámolási rendszert működtető Giro Elszámolásforgalmi Rt.-t, amely tanúsítványait nem közvetlenül, hanem ügyfelei, a pénzintézetek közvetítésével bocsátja ki. A bankok tipikusan saját ügyfeleikkel folytatott elektronikus kommunikáció hitelesítéséhez használják fel ezeket a tanúsítványokat 6.2 Elektronikus kereskedelem A hitelesítési sémák és protokollok megjelenésének illetve elterjedésének az egyik legfőbb mozgatórugója minden kétséget kizáróan az elektronikus kereskedelemhez kapcsolódó szolgáltatások

megjelenése volt. Az internetesen vásárlás, a cégek egymás közötti kereskedelme és az on-line banki szolgáltatások mind-mind olyan területek, amelyek fokozott biztonságot igényelnek, és az ezzel foglalkozó cégek általánosnak mondható meglátása szerint ezek nem kielégítő mértékű elterjedtsége (illetve az e mögött rejlő ok, a potenciális ügyfelek bizalmatlansága) az addig alkalmazott technológiai (kriptográfiai) nehézségekre vagy hiányosságokra vezethető vissza. Nem csoda hát, hogy az elektronikus formájú pénzmozgásokban érdekelt cégek időt, fáradságot és főleg pénzt nem kímélve támogatták az ezirányú kutatásokat, aminek a következménye jónéhány, egymástól gyakran nagymértékben eltérő protokoll és szabvány lett. Termé- 60 szetesen ezek között is léteznek elterjedt, ipari de facto szabványként kezelt megoldások; a továbbiakban ezeket mutatjuk be részletesebben. 6.21 A SET protokoll A biztonságos

elektronikus tranzakciókat megvalósító protokollok esetében mindig előny, ha a fejlesztésekben olyan cégek is részt vesznek, akiknek egyfelől gyakorlatuk van a hagyományos banki tranzakciók bonyolításában, másrészt pedig ők lesznek a protokoll későbbi felhasználói is. Így történt ez a SET (Secure Electronic Transactions) protokoll esetében. 1995-ben két konzorcium is alakult az elektronikus banki tranzakciók biztonságát megvalósító protokoll kidolgozására. A MasterCard, Netscape Corporation, az IBM és mások által alkotott egyik szövetség létrehozta a SEPP (Secure Electronic Payment Protocol) protokollt; ezzel szinte teljesen egyidőben a Visa és a Microsoft nevével fémjelzett másik konzorcium az STT (Secure Transactions Technology) protokollal rukkolt elő. (Talán az eltelt évek miatt, esetleg más megfontolásokból kifolyólag, mindenesetre manapság már az Interneten is alig-alig találni ezekről a protokollokról információt.)

Természetesen a piac szereplői megengedhetetlennek tartották, hogy a két legnagyobb hitelkártya-társaság különböző protokollokat támogasson, így 1996ban az egyesítési törekvések eredményeként megszületett a SET protokoll. 6.211 A SET modellje A SEPP és STT protokollokhoz hasonlóan a SET is a későbbiekben bemutatásra kerülő S-HTTP protokollt használja. A hitelkártyás tranzakcióban résztvevő felek a tranzakció során hiteles módon bizonyítják azonosságukat (opcionálisan a hitelkártya birtokosa ezt nem teszi meg), a kulcs-párjuk privát tagjának felhasználásával. Az üzenetek letagadhatatlanságát az üzenetpecsétek illetve időbélyegzők biztosítják A nyilvános kulcsokat egy (nem meghatározott) megbízható harmadik fél hitelesíti, és a nyilvános kulcsok illetve a személyazonosság közötti kapcsolatot X509 tanúsítványok biztosítják A SET hierarchikus bizalmi modellt, vagyis a CA-k hierarchikus szerveződését feltételezi.

A SET modelljében a résztvevő felek rendelkeznek egy a cégek (például a MasterCard vagy a Visa) tanúsítványainak aláírására használt (előnyösen 2048 bites kulcshosszúságú) gyökér kulccsal. Ezek a tanúsítványok is rendelkeznek lejárati idővel, ezért létre kellett hozni a kulcsok lecserélési mechanizmusát, még azelőtt, hogy a kulcsok lejárnak. A cég hitelesítés-szolgáltatói (CA) (és a hierarchiában lejjebb elhelyezkedő szervezet) által kibocsátott tanúsítványok 1024 bites kulcsokkal vannak aláírva A kártyabirtokos számára a tanúsítványok kibocsátását a kártyakibocsátó cég végzi. A SET az X.509 tanúsítványok (v3 verziójában már megtalálható) bővítménymezőjét használja; ilyen bővítmény lehet például egy „Kulcshasználat-korlátozás” mező, amely a kulcsnak a hitelesítés-szolgáltató által meghatározott felhasználási körét írja le; erre példa az adatok titkosítása vagy az aláírás

hitelesítése. Szokás az ügyfélnek aláírás-létrehozó kulcs tanúsítványt kibocsátani; viszont a protokoll nem ajánlja a kulcs párjának üzenetek titkosítására való felhasználását. A tranzakcióban résztvevő feleket a tanúsítványban az X.500 megkülönböztetett nevük (DN) azonosítja, viszont a SET kártyatulajdonosi tanúsítványok nem tartalmazzák sem a kártyatulajdonos nevét, sem pedig a hitelkártya számát. Ehelyett konkatenálják a hitelkártya számot egy véletlenszerű értékkel (nonce) és néhány rögzített karakterből álló szöveggel, majd kiszámítják a hash értékét. Ezt a számítást csak egy alkalommal végzik el, és a kártya kibocsátója tárolja az eredményezett értéket. Amikor a felhasználó vásárlást próbál végrehajtani, ezt az értéket összehasonlítják a fizetési felhatalmazási kérés által tartalmazott elrejtett (blinded) bankszámlaszámmal. 61 A SET protokoll kérés-válasz üzenet-párokból

áll, ezeket a kompatibilitás végett gépfüggetlen formátumban, MIME-objektumokként definiálja a specifikáció. Az üzeneteknek csak bizonyos részei titkosítottak, ami lehetővé teszi, hogy a felek igény szerint férjenek hozzá az információkhoz. Elképzelhető az például, hogy a kereskedő nem ismerhet meg financiális jellegű adatokat a hitelkártyáról, és a vásárlásokkal kapcsolatos információkat el kell rejteni a kártya elfogadója (acquirer) elől Egy kapcsolatalapú összeköttetés két végpont közötti tikosításával ezt nem lehetne megtenni. – viszont megvalósítható a következő pontban bemutatott úgynevezett kettős aláírásokkal. A váltott üzenetek között vannak inicializáló, vásárlási-megrendelési, felhatalmazási, fizetési tranzakció-begyűjtési, valamint kártyatulajdonos-lekérdezési üzenetek. 6.212 Kettős aláírások Mielőtt folytatnánk a SET bemutatását, célszerű bemutatnunk a kettős aláírás (dual

signature) technikáját. Ezt főleg olyan esetekben használjuk, amikor valamely tranzakcióban kettőnél több fél vesz részt; ilyen például, amikor a hitelkártyás tranzakció során a kártyatulajdonos, a kereskedő és a bank is kommunikációt folytat. A kártyatulajdonosnak például el kellene különítenie a kereskedőnek szóló, a rendelés részleteivel foglalkozó információkat a banknak szóló, pénzügyi jellegű információktól. Ehhez két üzenet lenne szükséges; a kettős aláírás technikájával azonban elegendő egyetlen üzenet is. A két üzenethez külön-külön készítjük el az üzenetpecsétet, amelyeket aztán összefűzünk, és erre ismét alkalmazunk egy hash függvényt, amit azután a küldő aláír a magánkulcsával. A gyakorlatban ha a küldő egy-egy üzenetet kíván elküldeni a két fogadónak úgy, hogy mindkét féllel közben tudatja, hogy létezik egy kapcsolódó második üzenet is, akkor az első fogadónak elküldheti az

első üzenetet és a második üzenet lenyomatát az aláírással együtt, míg a második fogadónak a második üzenetet, az első üzenet lenyomatát, és az aláírást küldheti el. Fogadáskor az első fogadó alkalmazza a hash algoritmust az első üzenetre, hozzáfűzi a második üzenetet, majd az egészre ismét alkalmazza a hash algoritmust, és az eredményt összeveti a kettős aláírással. Bár az első fogadó csak az első üzenet tartalmát láthatja, biztos lehet benne, hogy létezik egy olyan második üzenet, amely lenyomata a második lenyomat, továbbá ezt a két üzenetet ugyanaz a kettős aláírás kapcsolja össze. (A másik oldalon az eljárás analóg ezzel.) A küldő szempontjából előnyt jelent, hogy csak egy kettős aláírást kell kiszámítania, ami erőforrást takarít meg számára 6.213 A SET tanúsítványok A SET üzenetek váltásához mindkét félnek rendelkeznie kell nyilvános kulcsú tanúsítványokkal. Ezen kívül szükségük

van egy aláíró tanúsítványra (signature cert) is, amely tartalmazza a nyilvános aláírási kulcsukat az általuk aláírt üzenetek ellenőrzéséhez. A tanúsítványok érvényességi ideje általában megegyezik a hitelkártya lejárati idejével. A kártya és a tanúsítvány lejáratakor a kártyatulajdonosnak meg kell újítania a tanúsítványát. A hitelesítés-szolgáltatóhoz (CA) való bejelentkezéshez a kártyatulajdonos először elküld egy üzenetet, amelyben a CA kicserélési tanúsítványát (exchange certificate) kéri el. Az ebben található nyilvános kulcsú csere kulccsal (public-key exchange key) fogja a küldő a CA-nak küldött összes többi üzenetet titkosítani. Ezen tanúsítvány ellenőrzéséhez minden felhasználónak meg kell szereznie a gyökér nyilvános kulcs egy példányát, végül kérnie kell egy elektronikus regisztrációs űrlapot a kártya kibocsátójától. A CA válasza tartalmazza a megfelelő regisztrációs űrlapot

(ez attól függ, hogy a kártyatulajdonos aláíró tanúsítványt, titkosító tanúsítványt, vagy mindkettőt igényelt), a CA tanúsítványait és a hitelesítésükhöz szükséges tanúsítványokat, valamint egy visszavont tanúsítványokat tartalmazó listát (CRL-t), és ez mind alá van írva a CA ma- 62 gánkulcsával. Innentől kezdve a kártyatulajdonos felelőssége, hogy ellenőrizze ezeket a tanúsítványokat (ezt oly módon végezheti el, hogy bejárja a bizalmi láncot, és eltávolítja belőle a CRL-ben szereplő tanúsítványokat). Ekkor biztos lehet benne, hogy érvényes regisztrációs űrlapot kapott, mégpedig egy minősített CA-tól A következő lépésben a kártyatulajdonos kitölti az űrlapot, amiben feltünteti a hitelkártyaszámot és a lejárat dátumát is. Ezután az űrlapot tikosítja a CA nyilvános RSA kulcsával, ami a SET extraerős titkosítását alkalmazza. Ezután összefűzi a kártyatulajdonos véletlenszerű értékét

(Nonce CARD) és a CA által generált véletlenszerű értéket (Nonce CA), ezzel kialakul a közös véletlenszerű érték (PANNonce); ezt használják majd a fizetési protokoll során. A kártyatulajdonos tanúsítványai tartalmazzák a kártya adataiból és a közös véletlenszerű értékből képzett hash értéket is. Végül a kártyatulajdonos aláírja a hitelesítendő nyilvános kulcsokat, és beleteszi azokat a regisztrációs űrlapba. A nyilvános kulcsok és a regisztrációs űrlap együtt alkotják a tanúsítványkérési üzenetet, amelyet titkosít és elküld a CA-nak. A kérés fogadásakor a CA azonosíttatja a hitelkártyát az azt kibocsátó bankkal, valamely köztük felépített biztonságos csatornán keresztül. Ha a kártya érvényesnek bizonyul, a CA generálja és aláírja a tanúsítványokat a kártyatulajdonos nyilvános kulcsai számára. Ezután a CA elküldi az új tanúsítványokat és az erős titkosítással védett Nonce CCA

véletlenszerű értéket. A kártyatulajdonos ellenőrzi a tanúsítványokat, és összefűzi a visszafejtett Nonce CCA értéket és a Nonce CARD értéket, amivel megkapja a közös véletlenszerű (PANNonce) értéket. Így már lehetséges annak ellenőrzése, hogy az egyedi kártyatulajdonos-azonosító valóban az, ami a tanúsítványokban van feltüntetve. A kártyatulajdonos innentől kezdve képes lesz hitelkártyás fizetések végrehajtására. Hely hiányában a protokollt ehelyütt nem mutatjuk be részletesebben, a téma iránt érdeklődők további részleteket a [49] munkában találhatnak. 6.22 A Payword protokoll Ezt a rendszert Rivest és Shamir dolgozta ki 1996-ban [50]. A Payword protokoll a nyilvános kulcsú kriptográfia módszereit alkalmazza, és úgynevezett digitális zsetonokkal végrehajtott tranzakciókkal valósítja meg a vásárlást. Egy ilyen zseton értéke a rendszer igényeitől függően változhat (lehet például 10 dollár). A módszer

lényege, hogy amikor az ügyfél számlát nyit a banknál, kap a banktól egy tanúsítványt, amely feljogosítja őt zsetonok generálására. Az elektronikus vásárlást megelőzően az ügyfél offline módon generál szükséges mennyiségű zsetont, majd ezeket egy hash függvénnyel egymáshoz láncolja, majd az egészet aláírja. A kereskedő pedig a banknál válthatja be a zsetonokat. 6.221 A protokoll megvalósítása A protokoll a következő lépésekkel írható le: - Az ügyfél a szükséges összegtől függően létrehoz n darab (ZS0, ZS1, , ZSn-1) zsetont oly módon, hogy generál egy véletlen számot (vagyis az (n-1)-ik zsetont), és az i sorszámú zseton az (i+1) sorszámú zseton valamely hash függvény szerinti képe lesz, azaz ZSi = h(ZSi+1). - Az ügyfél kap a banktól egy tanúsítványt, amely tartalmazza a bank és az ügyfél nevét, az ügyfél nyilvános kulcsát stb. a bank magánkulcsával aláírva - A kereskedővel való első

kapcsolatfelvételkor az ügyfél elküld egy kötelezvényt, amely tartalmazza a kereskedő nevét, az ügyfél tanúsítványát, a 0 sorszámú zseton (vagyis a láncban utolsó hash) értékét, valamint további azonosító információkat és paramétereket. A kötelezvény az ügyfél magánkulcsával van aláírva Ez alapján a bank nyilvános kulcsával a kereskedő ellenőrizni tudja az ügyfél-bank kapcsolat valódiságát. 63 - Az ügyfél úgy fizethet k zsetont, hogy elküldi a k sorszámú zseton értékét és a k sorszámot, azaz egy (ZSk , k) párt. A következő l zseton értékű fizetéskor az (l + k) sorszámú zseton értékét és az (l + k) sorszámot, azaz a (ZSl+k , l+k) párt küldi el a kereskedőnek. A kereskedőnek elegendő azt tárolnia, hogy az utolsó fizetésnél melyik zsetont kapta, és hogy annak mennyi volt az értéke (más szóval, hogy idáig összesen hány zsetont kapott, és az utolsó zseton értékét). - A kereskedő időnként

elküldi a banknak az ügyfél nevét, kötelezvényét, valamint az utolsó zseton értékét és sorszámát (azaz a (ZSk , k) párt). Az átutalás előtt a bank ellenőrzi, hogy az ügyfél valóban k zsetont költött-e addig oly módon, hogy ZSk-ra k-szor alkalmazva a hash függvényt, a kötelezvényben szereplő ZS0 értéket kell kapnia. Ha az érték nem egyezik meg, valami problémának kellett időközben fellépnie. 6.222 A rendszer biztonsági szolgáltatásai Mivel a kötelezvény tartalmazza a kereskedő és az ügyfél nevét is, más kereskedő és ügyfél számára a zsetonok értéktelenek. A hash függvény fentiekben említett tulajdonságai miatt a kereskedő nem tud zsetonokat generálni, hiszen ehhez a hash láncban visszafelé kellene lépkedni, amihez viszont fel kellene törnie a hash függvényt. Elég nagy kulcs és elég erős módszer esetén ez gyakorlatilag lehetetlen. A tranzakciókhoz szükséges online kapcsolatok száma minimális, és a

kereskedőnek egyetlen vásárlás során sem kell közvetlen kapcsolatba lépnie a bankkal; elegendő, ha például havonta egyszer elküldi (esetleg személyesen elviszi) a bankhoz az utolsó zseton értékét A rendszer – talán egyetlen – hátránya, hogy a tranzakciók során sehol nem jelenik meg, hogy az ügyfél mit vett (illetve, hogy vett-e valamit egyáltalán). 6.3 SSO-rendszerek és távoli rendszermenedzselés Létezik a hitelesítési alkalmazásoknak egy manapság meglehetősen népszerű, és ezért (vagy ennek ellenére) vitatott részterülete, amely jellemzően a felhasználók azonosságának hitelesítésével, illetve az általuk végrehajtható feladatok ellenőrzésével, vagyis a jogosultságvizsgálattal kapcsolatos. Ezen rendszerek lényege, hogy olyan mechanizmust biztosítanak, amely használatával a felhasználóknak nem szükséges jelszók tucatjait megjegyezniük, ezt elvégzi helyettük egy rendszer, amely felé egyetlen jelszóval

azonosíthatják magukat, és a rendszer lényegében átvállalja a többi alkalmazás felé a felhasználó azonosítását. (Az ilyen rendszerek ellen szóló érv, hogy a központosítás mindig biztonsági kockázatokkal jár; a rendszernek egyetlen „Achilles-sarka” lesz). Ezeket a rendszereket egyszeri beléptetéses (SSO – Single Sign-On) rendszereknek nevezzük Az SSO-rendszereken belül kétféle megközelítést szokás megkülönböztetni [51]. A bróker alapú megközelítésben a felhasználó a brókerhez fordul azonosítás céljából, és ha ez sikeres, egyfajta tanúsítványt kap tőle, amit bemutathat a szolgáltatásnak hiteles azonosítás céljából. Ebben a fejezetben bemutatjuk az egyik legelterjedtebb bróker alapú protokollt, a Kerberos rendszert, a lehetőségekhez mérten a hitelesítéssel kapcsolatos vonatkozásra szorítkozva. A másik megközelítés az úgynevezett ügynök alapú megközelítés, amely során egy ügynök alkalmazás

automatikusan azonosítja a felhasználót a további alkalmazások felé; ilyen protokoll a jellemzően távoli rendszerkarbantartásra használt SSH protokoll – ezt a fejezetben szintén részletesen bemutatjuk. 64 6.31 A Kerberos rendszer A Kerberos rendszert az 1980-as évek végén fejlesztették ki az M.IT egyetemen, a „vicces kedvű” hallgatók általi jelszólopások kivédésére Mára a UNIX/Linux világban elterjedten használt, nyílt forráskódú megoldásként tartják számon, de a Microsoft Windows 2000 is alkalmazza. Ebben a fejezetben a működési elvével, ezen belül is a felhasználók hiteles azonosításával, valamint az előnyeivel és hátrányaival foglalkozunk. 6.311 A Kerberos alapvető működési modellje Ha pontosak akarunk lenni, a Kerberos nem a felhasználókat azonosítja; inkább úgy fogalmazhatnánk, hogy a felhasználó által futtatott alkalmazás valamely kliens-szerver modell szerint egy kiszolgálón futó alkalmazás

szolgáltatásait szeretné igénybe venni, és a rendszer azt vizsgálja meg, hogy az alkalmazás (vagyis a felhasználó) az-e, amit állít magáról, és ha igen, van-e felhatalmazása a szolgáltatás igénybevételére. Ennek bizonyítására a felhasználó egy úgynevezett hitelességvizsgáló szerver (AS – Authentication Server) AS által kiállított olyan jegyet vagy tikettet (ticket) mutat fel a szolgáltatás számára, amely a felhasználóról tartalmaz őt egyértelműen azonosító információkat. Ha az adatokat a szolgáltatás helyesnek találja, engedélyezi a szolgáltatás igénybevételét. A Kerberos rendszer több előfeltevéssel is rendelkezik: felteszi, hogy az AS ismeri a felhasználó jelszavát, azonban ezt csak a köztük zajló kommunikáció védelmére használt úgynevezett felhasználói kulcs generálására használják (a kulcs lényegileg a felhasználó jelszavából alkalmas hash függvénnyel generált lenyomat). Felteszi továbbá, hogy

létezik a szolgáltatás és az AS között is egy titkos kulcs, az úgynevezett szolgálati kulcs, amely nem egy másik kulcsból származtatott kulcs, tehát biztonságos módon kell tárolni, a szolgálati kulcs-fájlban (SKF – Service Key File). A rendszer további feladata annak a biztosítása, hogy a fájlhoz csak az AS és a szolgáltatás férjen hozzá. Ezt a következő módon valósítja meg: Az első lépésben a felhasználó elküldi a nevét és a szolgáltatás nevét az AS-nek. Az üzenet fogadásakor az AS létrehoz egy kapcsolatonként változtatott viszonykulcsot, helyesebben annak két példányát; ez lesz a felhasználó és az alkalmazás közötti rövid távú titkos kulcs. (Megjegyezzük, hogy a Kerberos rendszer alap verziójának sajátossága, hogy a használt titkosítási módszerek mindig szimmetrikus kulcsokon, ezen belül is jellemzően DES kulcsokon alapulnak, így a viszonykulcs is ilyen típusú. A protokoll újabb verziói megengedik a

nyilvános kulcsú módszerek és PKI-komponensek alkalmazását is.) Ezután az AS két üzenetet küld a felhasználónak: az első üzenet tartalmazza a viszonykulcs egyik példányát és a szolgáltatás nevét (mindkettőt a felhasználói kulcs titkosítja), a második üzenet pedig (amely maga a jegy, vagyis a tikett) a viszonykulcs másik példányát és a felhasználó nevét tartalmazza (a szolgálati kulccsal titkosítva). A felhasználó ismeri a felhasználói kulcsot, tehát képes az első üzenet visszafejtésére, amiből megkapja a viszonykulcsot; másrészt megbizonyosodik afelől, hogy az üzenet az AS-től érkezett, hiszen neki küldte el a szolgáltatás nevét. Ezt követően a felhasználó két üzenetet küld a szolgáltatásnak: változtatás nélkül visszaküldi a kapott jegyet (ha akarná sem tudná visszafejteni, mivel az a szolgálati kulccsal van titkosítva), valamint elküld egy időbélyeget, a viszonykulccsal titkosítva (ez az üzenet az

úgynevezett Kerberos hitelesítő, vagy authenticator). Fogadáskor a szolgáltatás az általa ismert szolgálati kulccsal visszafejti a jegyet (az első üzenetet), amiből megtudja a viszonykulcsot és a felhasználó nevét, és a viszonykulccsal visszafejti az időbélyeget. Opcionálisan a felhasználó is hitelesítheti a szolgáltatást: ehhez egy utolsó lépés során az időbélyeget és egy csak rá jellemző azonosítót (például a nevét) titkosítja a viszonykulccsal, és visszaküldi a felhasználónak. Az azonosító alkalmazásával kerülhető el a hitelesítő (authenticator) üzenet viszszajátszása (A rendszer sematikus működését a 6 ábra mutatja be) A rendszernek mindazonáltal van egy komoly gyakorlati hátránya: a fenti lépéseket minden új szol- 65 gáltatás igénybevételénél végre kell hajtani, vagyis a felhasználónak mindig be kell gépelnie a jelszavát, és azt el kell küldeni, ami támadási felületet nyújt. 1. F,S Jegy KF,S

4. EKF,AS(S|KF,S) F EKS,AS(S|KF,S) AS 3. 2. KF,S KF,S Jegy Hitelesítő EKS,AS(F|KF,S) EKF,S(t) 5. S 6. EKF,S(t,S) KF,S t 7. 6. ábra: A Kerberos rendszer egyszerűsített működési modellje (Forrás: [51]) 6.312 TGS és TGT E probléma áthidalására bevezettek egy speciális szervert: a jegyigazoló szervert (TGS – Ticket Granting Server). Ez funkcionálisan elkülönül az AS-től, de gyakorlatilag egy helyen szokás azzal elhelyezni, és a kettő együttesen alkotja a kulcskiosztó központot (KDC – Key Distribution Center). A hitelesítési folyamat ekkor úgy változik, hogy a szolgáltatáshoz való fordulás helyett a felhasználó a KDC-vel lép kapcsolatba. Ez úgynevezett jegyigazoló jegyet (TGT – Ticket Granting Ticket) ad a felhasználónak, amivel a szolgáltatás igénybe vételekor a TGS-hez fordulhat, és a TGS ad majd olyan jegyet, amellyel végül is igénybe veheti a szolgáltatást. Szemléletes példával élve egy biztonsági védelemmel

ellátott intézménybe való bejutáskor a személyi igazolványunk fejében kaphatunk olyan látogatói kártyát, amellyel az egyes részlegeket/osztályokat látogathatjuk, de nem mindegyikhez kapunk külön egyet. A Kerberos rendszerrel védett szolgáltatások esetében végső soron a személyazonosságunkat ezek a jegyek hitelesítik a szolgáltatások igénybevételéhez 6.313 A Kerberos 5 modellje Ebben a pontban a gyakorlatban használt legfrissebb, az RFC 1510 dokumentumban specifikált 5-ös verzió protokolljának lépéseit mutatjuk be részletesebben. Ez az előző pontokban vázolt modellre épül, és inkább a kiterjesztésének tekinthető. A példa kommunikáció során a felhasználó gépén futó alkalmazás szándékozik igénybe venni egy másik alkalmazás (vagy kiszolgáló) szolgáltatását. A protokoll inicializálási fázisában az alkalmazás az AS-től megszerez egy TGT-t, míg a következő ún. kliensszerver hitelesítési fázisban a felhasználó

gépén található kliens alkalmazások kommunikálnak a TGS-sel és a távoli szolgáltatásokat nyújtó Si szerverekkel; ezt illusztráljuk a 7 ábrán Az inicializálási fázis (másként inicializálási protokoll) során az AS az F felhasználó (az AS által ismert) pwdF jelszavát ellenőrzi, és létrehozza illetve eljuttatja 66 hozzá a KC,TGS viszonykulcsot (vagyis a kliens és a TGS közös titkát) és a TGT-t. Ehhez feltesszük, hogy léteznek az F és AS közötti KF,AS, valamint az AS és a TGS közötti KAS,TGS szimmetrikus (közös) kulcsok. A fentiek alapján a KF,AS viszonykulcsot egy hash függvénnyel származtatjuk a jelszóból, azaz KF,AS = h(pwdF). A protokoll első lépésében a felhasználó gépén futó alkalmazás elküldi az AS-nek az {FN, TGSN, L1, N1} üzenetet, ahol FN a felhasználó azonosítója, TGSN a TGS azonosítója, L1 a TGT érvényességi ideje, és N1 egy véletlenszerű érték (nonce). Az üzenet fogadásakor az AS kikeresi a

KF,AS és a KAS,TGS kulcsokat az adatbázisából, generálja a rövidtávú, véletlenszerű KC,TGS viszonykulcsot, végül pedig oly módon hozza létre a TGT-t, hogy a KAS,TGS kulccsal titkosítja az {FN, HN, TGSN, KC,TGS, T, L} ötöst, ahol HN a felhasználó gépén futó program azonosítója, T egy időbélyeg, és L a jegy érvényességi ideje. Ezt követően az AS elküldi a felhasználó által futtatott alkalmazásnak az FN és TGT értékeket, valamint a KF,AS kulccsal titkosított {TGSN, KC,TGS, T, L, N1} ötöst. A fogadáskor a H program kéri a felhasználó jelszavát, mire az begépeli a pwd1 jelszót Az inicializálási protokoll utolsó lépésében az alkalmazás kiszámítja a jelszó hash értékét, és megpróbálja visszafejteni vele az előző lépésben utolsóként elküldött titkosított struktúrát. Ha ez sikerül, akkor egyrészt az üzenet csak az AS-től érkezhetett, hiszen csak az ismeri a felhasználói jelszót, másrészt az alkalmazás

visszafejtheti és tárolhatja a KC,TGS, T és L értékeket, valamint a TGT-t. Minden más esetben a protokoll megszakad A kliens-szerver hitelesítési protokoll során a hoszt gépen futó kliensek próbálják igénybe venni az S szerver szolgáltatásait (jogosultak erre, hiszen az inicializálási fázison túljutottak). Ehhez azonban biztonságos csatornát kell felépíteniük, amely során először is a TGS generál egy új, C és S közötti közös KC,S viszonykulcsot, majd megtörténik a kulcsok kiosztása. Maga a hitelesítési protokoll feltételezi, hogy C már rendelkezik az érvényes TGT-vel, valamint a KC,TGS kulccsal. A protokoll első lépésében C elküldi a TGS-nek az SN, N, L, és TGT értékeket, valamint a KC,TGS viszonykulccsal titkosított (CN, T1) párt, ahol SN és CN a szolgáltatás ill. a kliens azonosítói, N egy véletlenszerű érték, T1 pedig egy új időbélyeg Az üzenet fogadásakor a TGS először a KAS,TGS kulccsal visszafejti a TGT-t, és

abból meghatározza a KC,TGS kulcsot és a T időbélyeget, amivel ellenőrizni tudja a TGT létrehozásának idejét. A KC,TGS kulccsal visszafejti a (CN, T1) párt, és T1 alapján ellenőrzi az időt. Ezután generál egy KC,S viszonykulcsot, és az {FN, CN, SN, KC,S, TS, LS} hatost titkosítva a KS,TGS viszonykulccsal létrehozza a szerver számára kiállított ST (Server Ticket) jegyet. A következő lépésben a TGS elküldi a kliensnek az FN és ST adatokat, valamint a KC,TGS kulccsal titkosított {SN, KC,S, TS, LS, N} ötöst. Fogadáskor ez utóbbit a KC,TGS kulccsal visszafejti a kliens, tárolja a benne foglalt paramétereket, és TS alapján ellenőrzi az üzenet idejét A következő lépésben C elküldi S-nek az ST értéket és a KC,S kulccsal titkosított (CN, T2) párt, aminek a felhasználásával a szerver egyrészt KS,TGS alapján visszafejti ST-t, és meghatározza a KC,S viszonykulcsot, majd TS alapján ellenőrzi az ST érvényességi idejét. Ezután KC,S-sel

meghatározza T2-t, amivel viszont egy újabb időellenőrzést hajt végre. A protokoll utolsó lépésében S elküldi C-nek a KC,S-sel tikosított T2 adatot 67 KDC F Hoszt AS H TGS C1 C2 S1 S2 Cn Sn 7. ábra: A Kerberos rendszer inicializálási (szaggatott nyilak) és hitelesítési (folytonos nyilak) fázisa (Forrás: [51]) A protokollok első ránézésre bonyolultnak tűnnek, viszont a segítségükkel egy nagyon hatékony, és ráadásul szimmetrikus kulcsú technikákkal megvalósított módszert kapunk. Ez nagyban hozzájárult a Kerberos elterjedéséhez, mindazonáltal a protokoll számos hiányossággal is rendelkezik A következő pontban ezek közül vizsgálunk meg néhányat, a problémák bővebb listáját és az azokat megoldó javításokat az [52] címen találhatnak az ez iránt érdeklődők. 6.314 A Kerberos hiányosságai Amint azt a protokollok részletes bemutatásából is látszik, a Kerberos megbízhatósága nagyban függ az időbélyegek

alkalmazásától, így komoly problémát okozhat a rendszerben található eszközök belső óráinak szinkronizálása. Az időbélyegek ellenőrzése csak egy adott időintervallumban valósulhat meg, ami például visszajátszásos típusú támadást tehet lehetővé. Elképzelhető olyan forgatókönyv is, hogy a támadó meghamisítja a szolgáltatások óráit, ami által az elutasítja a felhasználók érvényes időbélyegét. Problémát jelenthet, hogy bár a jelszavak kódolva továbbítódnak a hálózaton, a viszonylag hosszú érvényességi idejük miatt szótáras támadással a rosszul választott jelszavak megszerezhetőek. További probléma, hogy a protokoll eredeti verziójában nem szerepel az AS hiteles azonosítása, ami lehetővé teszi hamis AS-ek felállítását; ez már önmagában is indokolhatja a nyilvános kulcsú módszerek (például tanúsítványok) bevonását, ami a Kerberos „európai verziójának” tekintett SESAME rendszereknek már

szerves részét képezi. Végül a rendszer implementálásakor fontos körülmény, hogy szinte minden esetben a védendő alkalmazásokat többé-kevésbé át kell alakítani, fel kell készíteni a Kerberos funkcionalitására; erre az angolszász szakirodalomban elterjedt a „kerberize” kifejezés. A Kerberos v5 verziójával kapcsolatos további részletek az [53] és [54] munkákban találhatóak 6.32 Az SSH protokoll Az SSH (Secure Shell) v1 verziója 1995-ben készült el, szintén egy jelszólopási incidens apropóján. Az alapvető célkitűzés egy olyan kliens-szerver architektúrájú rendszer kidolgozása volt, amely távoli rendszerekre való biztonságos belépést valósít 68 meg, mégpedig oly módon, hogy a felhasználónév és jelszó (az addig alkalmazott gyakorlattal, például a Telnettel ellentétben) titkosított módon utazzon a két gép közötti hálózaton keresztül. A rendszer azonban néhány biztonsági hiányosságtól szenvedett, azért

néhány évvel később elkészült az SSH v2 verziója; a dolog érdekessége, hogy ez szinte egyáltalán nem kompatibilis az előző verzióval. Az elvi megfontolások mindkét esetben hasonlóak, mi azonban a továbbiakban főleg a mára elterjedt (és 2001-től az egy IETF-munkacsoport által szabványosítás alatt álló) v2 verzióval foglalkozunk [55]. Megjegyezzük, hogy az SSH fogalom alatt mi minden esetben az SSH protokollkészletet, nem pedig a hasonló néven ismert, a protokollt megvalósító alkalmazáscsomagról beszélünk. 6.321 Az SSH részprotokolljai Az SSH széles körben elterjedt protokoll a távoli rendszermenedzselés, távoli bejelentkezés és biztonságos fájlátvitel területein (bár ennél többre is képes, teljes VPNszerű rendszerek építhetőek fel a szolgáltatásaival). Mégis ezen különböző funkciók megvalósításához ugyanazokat a feladatokat kell megoldani, ennek megfelelően a protokoll három rész-protokollból áll: a

szállítási (transport) protokoll feladata a kapcsolat felépítése, a szerver hitelesítése, és a használt algoritmusok egyeztetése; a hitelesítési (authentication) protokoll irányítja a felhasználó hitelesítését; míg a kapcsolat (connection) protokoll végzi a csatornán keresztül továbbított (többszörös) adat- és vezérlőcsomagok kezelését, például az adatcsatornák hasítását vagy multiplexelését. A jelen dolgozat témaköréhez az első kettő protokoll kapcsolódik szorosabban, ezért a továbbiakban ezeket mutatjuk be részletesebben. 6.322 A szállítási protokoll Mivel a protokollnak mindkét verziója meglehetősen elterjedt, megeshet, hogy (lévén kliens-szerver architektúrájú protokoll) a két oldalon különböző verziójú SSHkliens és SSH-szerver alkalmazások futnak, így egy általános TCP-kapcsolat felépítését követően legelső lépésként elküldik egymásnak a verziójukat, és bináris kapcsolatra váltanak át.

Ezután megkezdődhet a kapcsolati paraméterek és algoritmusok egyeztetése, ami oldalanként egyetlen SSH MESSAGE KEXINIT üzenet elküldését jelenti Az üzenet lényegileg egy lista, amiben felsorolják az általuk támogatott algoritmusokat, preferencia-sorrendben; a gyakorlatban jellemzően a Diffie-Hellman kulcscserélő algoritmust szokás megjelölni, SHA-1 hash függvénnyel. Az üzenetben található egy first kex packet follows flag, amely azt jelzi, hogy a soron következő üzenet már az általunk választott (a listában az első) módon lesz védve. A következő lépésben a kliens választ egy véletlenszerű x számot, és elküldi a szervernek az e = gx (mod p) értéket (g és p értékei a Diffie-Hellman szabványban definiáltak szerint ekkorra már ismertek mindkét oldalon). A szerver a kliens üzenetének fogadása után választ egy véletlenszerű y számot Ebből egyrészt kiszámítja az f = gy (mod p) értéket, illetve a K = ey (mod p) Diffie-Hellman

megosztott tikot. Ezután konkatenálja a kliens és a szerver verziószámát, a kliens és a szerver SSH MESSAGE KEXINIT üzenetének az adatrészét, a szerver nyilvános kulcsát, valamint az e, f és K értékeket, majd erre az egészre alkalmazza az SHA-1 hash függvényt. Végezetül a szerver a magánkulcsával aláírja a hash függvény H értékét, és elküldi a kliensnek a nyilvános kulcsát és az aláírt értéket, valamint az f értéket. Fogadáskor a kliens ellenőrzi, hogy a nyilvános kulcs valóban a szerverhez tartozik-e (például már tárolja azt lokálisan, vagy máshonnan szerez meg egy alkalmas tanúsítványt), kiszámítja a K = fx (mod p) értéket (vagyis a megosztott titok kliens oldali példányát), meghatározza (a szerver-oldali számításokkal analóg módon) a H hash értéket, és ellenőrzi az aláírást. Ekkor állhatnak neki a kapcsolati kulcsok generálásának, valamilyen előre egyeztetett módon (például az SSL-nél bemutatott

módszerrel) Ha ezzel végeztek, megkezdődhet a kommunikáció, jellemzően azzal, hogy a kliens ké- 69 rést küld a szervernek, hogy az (most már hiteles módon) azonosítsa őt, például a felhasználói név és jelszó alapján. 6.323 A hitelesítési protokoll A felhasználó hiteles azonosítását az SSH többféleképpen is képes megoldani. Ennek egyik módja a jelszó-alapú hitelesítés, amikor az immáron titkosítva elküldött jelszót a szerver összeveti a lokálisan tárolt jelszó-példánnyal, és ezáltal győződik meg végső soron a felhasználó azonosságáról (az előző pontban vázolt módszerekkel esetleg csak az alkalmazást futtató gép vagy maga az alkalmazás hitelesíthető). Egy másik, fejlettebb módszer, ha az azonosság bizonyításához minden gép rendelkezik egy saját nyilvános/privát kulcs-párral, valamint a kommunikációs partner nyilvános kulcsának másolatával. Egy további módszer, ha minden egyes felhasználó

generál egy új kulcspárt, aminek privát tagját jelszóval védetten őrzi a kliens gépen. Amikor a felhasználó kommunikálni kíván a szerverrel, az SSH-kliens alkalmazás elküldi a kulcspár nyilvános tagját a szervernek, amely egy kihívás-üzenetet (például véletlenszerű adatot) titkosít azzal, és az egészet visszaküldi a kliensnek. Ő visszafejti az üzenetet, elkészíti a lenyomatát, majd visszaküldi a lenyomatot. Itt a szerver is elkészíti a kihívás-üzenet lenyomatát, és a kettőt összevetve megbizonyosodhat afelől, hogy valóban a nyilvános kulcs tulajdonosával kommunikál. 6.324 Titkosítás és integritásvizsgálat Amikor a fenti protokollok véget érnek, a kommunikáció valamilyen szimmetrikus kulcs (az egyeztetett viszonykulcs) által védetten folyhat. Az SSH többek között a DES, 3DES, Blowfish, AES és Twofish algoritmusokat támogatja. Az adatok integritásvizsgálatához a Message Authentication Code (MAC) algoritmusokat

használja fel (legalábbis a v2 verzió; a v1 verzió a valamelyest egyszerűbb 32 bites CRC eljárást, illetve a HMAC-SHA1 alkalmazza), és a kulcskiosztás pedig – amint azt már említettük – a Diffie-Hellman kulcscserével valósul meg. A csomagformátum is viszonylag egyszerű: a v2 verziójú csomag hosszát tartalmazó kezdő mezőt egy kitöltő mező követi (amely 8 bájt többszörösére egészíti ki a csomagot), majd következik az adatrész, amit ismét egy feltöltő mező zár le. Az adatrész opcionálisan tömörítésre kerülhet, viszont az eddigi mezők mindegyike titkosítva van a viszonykulccsal. Az SSH csomagot az integritásvizsgálathoz szükséges adat, vagyis a MAC érték zárja le, ami a titkosított rész hash lenyomata A v1 verzió esetén kicsit különbözik a csomag felépítése: a csomaghossz mezőt és a kitöltő mezőt a csomag típusát jelző mező követi, majd a csomag adatrésze következik, végül a csomagot szintén egy hash

lenyomat zárja le. Itt a csomag típusa mező és a csomag adatrésze opcionálisan tömörítve lehet, míg a két szélső mező kivételével az összes többi mindenképpen titkosítva lesz. 6.325 Ügynökök és ügynöktovábbítás (agent-forwarding) Az SSH protokollt bemutathattuk volna az általános webes biztonsági protokollok között is. Van azonban egy fontos szolgáltatása, ami miatt alkalmas SSO megoldásként való felhasználásra – ezért is ebben a részben mutatjuk be Amellett, hogy a felhasználó gépén több SSH-kliens alkalmazás is futhat, lehetőség van arra is, hogy egy SSH-szerver lépjen fel a nevünkben egy másik SSHszerverhez való kapcsolódás során, vagyis kvázi egy SSH-proxyként működhet. Ezzel a módszerrel nem kell a jelszavakat újra és újra begépelni a különféle szerverekhez való kapcsolódáshoz; ezt egy a felhasználóhoz rendelt ügynök (ágens) végzi. A módszer 70 „hátránya”, hogy csak olyan szerverek esetén

alkalmazható, amelyek ismerik a nyilvános kulcsunkat (vagy elfogadják a tanúsítványunkat). Ha például a felhasználó a gépéről az A SSH-szerveren keresztül kíván kapcsolatba lépni a B SSH-szerverrel, akkor elegendő egyszer hitelesen azonosítania magát az A szerver felé, és majd az végzi a B szerver felé a felhasználó azonosítását. A módszer hátránya viszont, hogy ekkor a rendszer sebezhetősége az ügynökök sebezhetőségén múlik, tehát biztosítani kell ezek védelmét [51]. 6.4 Hitelesítést alkalmazó protokollok a Világhálón A Világháló (WWW – World Wide Web) egy óriási, elosztott hipermédia-rendszer, amelyen elképzelhetetlen mennyiségű információ található meg, weboldalak milliárdjain. Ezen weboldalak túlnyomó része a HTML nyelven íródott, és a tartalmukat a felhasználók gépein futó böngészők jelenítik meg Először azonban ezekhez az információkhoz hozzá kell férni, „el kell kérni” a webhelyektől

(illetve biztosítani kell a másik irányú adatmozgást is): erre fejlesztették ki a HTTP protokollt. A jelen dolgozat terjedelme nem teszi lehetővé ennek bemutatását, a szabvány 11 verziójának részletes leírása az [56] dokumentumban található meg Természetesen a HTTP-n kívül számos más protokoll is létezik, de ezeknek van egy közös jellemzője: nem vagy nem kielégítő mértékben támogatják a biztonsággal kapcsolatban felmerülő problémák protokollszintű megoldását. A következőkben olyan protokollokat mutatunk be, amelyek lehetőséget biztosítanak például arra, hogy a szerver hiteles módon azonosítsa a klienst (és fordítva) a letöltést megelőzően, az azonosság meghatározása után esetleg attól függően jelenítsenek meg tartalmat, illetve lehetőséget biztosítsanak a kommunikáció titkosítására és az adatintegritás ellenőrzésére. 6.41 Az S-HTTP protokoll Az S-HTTP (Secure HTTP) protokoll első változatát E. Rescorla és

A Schiffman tervezte a 90-es évek közepén (szabványos változatát az [57] dokumentum írja le). Céljuk egy olyan biztonságos, üzenetorientált kommunikációs protokoll megvalósítása volt, mely felülről kompatibilis a HTTP protokollal, és a biztonsági irányelvek élesen elkülönülnek benne az azokat megvalósító mechanizmusoktól. Azonos képességekkel ruházza fel mindkét kommunikáló felet, miközben megtartja a HTTP tranzakciós modelljét. A HTTP üzenetek átvitelét beágyazással (encapsulation) valósítja meg Az üzenetek beágyazásának két ajánlásban rögzített módját használja (ezek a CMS és a MOSS; mindkét ajánlás támogatja az üzenetek titkosítását, aláírását és hitelesítését), és az üzenetek beágyazása akár rekurzív is lehet. A visszajátszásos támadási típusok kivédésére az S-HTTP protokoll is alkalmaz véletlenszerű értékeket (nonce). 6.411 Alkalmazott kriptográfiai módszerek Az adatok titkosítása

megvalósítható szimmetrikus és aszimmetrikus titkosítási módszerekkel is. A szimmetrikus titkosításhoz szükséges kulcs átadására a protokoll a Diffie-Hellman és RSA kulcscserélő algoritmusokat, valamint a kommunikáción belüli (Inband – Egy S-HTTP fejléc (Key-Assign) tartalmazza a kulcsot, természetesen a fejléc titkosítva van a fogadó nyilvános kulcsával) és a kommunikáción kívüli (Outband – A kulcs egyéb forrásból származik, például begépelik, de a forrás nem vesz részt a kommunikációban) módszereket támogatja. A tartalom titkosítására a protokoll a DES, az IDEA, az RC2 és a CDMF algoritmusok ECB variánsait alkalmazza. A kommunikáló felek hitelesítése történhet nyilvános kulcsú módszerekkel, például X.509 formátumú tanúsítványokkal (fontos itt megjegyezni, hogy a protokoll nem követeli meg a kliens 71 oldali kulcsok és tanúsítványok létezését), viszont a protokoll nem ír elő semmiféle bizalmi modellt

(bár a több gyökerű hierarchikus modell használatát ajánlja). A küldő azonosítására és az üzenet integritásának ellenőrzésére a MAC (Message Authentication Code) kódot használja, mely az üzenet tartalmának és egy közös titok lenyomatából (hash) áll; ehhez opcionálisan csatolható a küldő tanúsítványa (esetleg tanúsítvány-lánca), illetve a fogadóra bízható ezek beszerzése. 6.412 Üzenetformátum Az üzenet tényleges felépítése három dologtól függ: egyrészt az eredeti üzenet szövegétől (ami lehet akár egy HTTP-kérés), illetve a küldő és a fogadó kriptográfiai preferenciáitól. Az üzenetek felépítése hasonló, mint a HTTP protokollnál Rendelkeznek egy parancs/állapot sorral és a megfelelő fejlécekkel A hagyományos HTTP fejlécek közül csak a HOST és a CONNECTION használható az S-HTTP üzenet fejlécei közül A fejlécek sorokból állnak, amelyek az egyes kriptográfiai módszerek (preferált) attribútumait

írják le. A sorokban lévő paraméterek segítségével egyeztetik a kapcsolatban résztvevők a küldéskor és feldolgozáskor használandó biztonsági algoritmusokat Eldönthetik azt is, hogy a különböző biztonsági funkciókat (titkosítás, hitelesítés, digitális aláírás) használják-e egyáltalán, és ha igen, ezek közül melyeket. Egy fejléc sor az alábbi részeket tartalmazhatja: • Property – a paraméter, amit egyeztetnek (például a titkosító algoritmus azonosítója); • Value – az értéke (például DES-CBC); • Direction – az irány, amire érvényes (a forrás szemszögéből); és • Strength – előírás az algoritmus szükségességére (szükséges, opcionális, vagy elutasítva). A fejlécek után következik a tartalom, mely általában a HTTP kérést illetve választ tartalmazza, az egyeztetés során meghatározott titkosítási eljárással titkosított formában. Ugyanakkor a protokoll megengedi S-HTTP kérések tetszőleges

mélységű egymásba ágyazását is. 6.413 Előnyök és hátrányok A protokoll egyértelműen fontos előnye, hogy jól bevált, szabványos protokollra épül; nem egy teljesen új, hosszú tervezést és tesztelést igénylő protokoll, hanem a régit csak újabb funkcionalitással bővíti ki. Az S-HTTP ezen kívül végponttól-végpontig terjedő biztonságot garantál, de csak akkor, ha igény van rá (ezt az érvet általában az SSL/TLS „mindent tikosító” hozzáállása ellen szokás felhozni az S-HTTP/TLS vitákban): egyetlen biztonsági funkciót sem tesz kötelezővé, hanem mind opcionális, és egymással igény szerint kombinálható. Végezetül fontos előnyének tarják, hogy támogatja ugyan a tanúsítványok felhasználását, viszont nem ír elő követendő bizalmi modellt [58] 6.42 A Surf’n’Sign protokoll Ebben a pontban egy 1997-ben publikált, főleg a webes biztonság digitális aláírásokon alapuló megközelítésére koncentráló protokollt

mutatunk be [60]. Bár a publikálás idején a Surf’n’Sign protokoll nem volt teljesen kész, célszerűnek találjuk ennek bemutatását, hiszen a protokoll jól jellemzi az alkalmazási rétegen megvalósuló biztonság azon jellemzőjét, miszerint a felmerülő biztonsági problémát nem mindig egy 72 a teljes kommunikációt védő biztonsági protokollal orvosolnak, hanem ehelyett létrehoznak egy olyat, amely célzottan egyetlen alkalmazás-típusra dolgoztak ki. A jelen esetben ez nem más, mint a Világhálón elhelyezett dokumentumok hiteles módon való digitális aláírása. Sokszor előfordulhat (és az infokommunikációs társadalmat megvalósító célkitűzések értelmében remélhetőleg gyakran elő is fog fordulni), hogy például egy bank, az önkormányzat vagy az adóhatóság által az intézmény honlapján közzétett dokumentumot (például űrlapot) ki kell töltenünk, majd az aláírásunkkal hitelesítve kell azt visszaküldeni a kiállító

intézménynek. Ehhez a természetesen biztosítanunk kell annak egyértelmű (hiteles) igazolását, hogy az aláírás valóban a miénk, biztosítanunk kell annak ellenőrizhetőségét, hogy a küldés során az általunk kitöltött űrlap mezői nem módosultak, valamint biztosítanunk kell a letagadhatatlanságot is. Ezen funkciók megvalósítására triviálisan adódik a digitális aláírások felhasználása 6.421 A Surf’n’Sign architektúrája A publikált protokoll implementálása egy böngészőbe beépülő modul, úgynevezett plugin segítségével történt, tehát a biztonsági (aláírási) mechanizmusok a kliens oldalán valósulnak meg. Maga a protokoll meglehetősen egyszerű: először ellenőrizzük a kliens gépre letöltött dokumentum aláírhatóságát (az ilyen dokumentumok jellemzően szövegesek, a protokoll a publikálás idején még nem tartalmazott a beágyazott elemek – képek, egyéb mezők – aláírására szolgáló mechanizmust), és

ha azt aláírhatónak találjuk, a kliens magánkulcsával titkosítjuk a dokumentumról készült lenyomatot (az aláíráshoz RSA aláírási mechanizmust alkalmazunk, a lenyomatkészítéshez pedig MD5 üzenetpecsétet). Ehhez csatoljuk a nyilvános kulcsot, az aláírás időpontját, a dokumentum címét (ez azonosítja a szerver oldalon a dokumentumot), valamint a használt böngésző típusát, és az egészet elküldjük a szervernek a HTTP POST metódusával Az üzenet fogadásakor a szerver ellenőrzi a kliens kriptográfiai értékeit, visszaállítja a mezőket, és ha mindent rendben talált, eltárolja az üzenetet, valamint pozitív nyugtát küld a kliensnek. Ilyen nyugta fogadásakor a kliens is eltárolja az üzenet saját példányát, így későbbi esetleges vitás esetekben mindketten bizonyítani tudják a dokumentum aláírását 6.422 Megjegyzések a protokollhoz A fenti leírás csak a hitelesítési mechanizmust tartalmazza; a publikált leírás ennél

több funkciót említ. Mindazonáltal ez utóbbi „megvallja” a protokoll hiányosságait („további bővítési lehetőségek” címszó alatt) is: első sorban említi a protokoll szerver-oldali párjának kidolgozását, bár a protokoll nem titkolt célja volt olyan mechanizmus kidolgozása, amelynél (például az SSL-lel ellentétben) éppen a kliens hitelesítésén van a hangsúly További bővítési lehetőségként említik a beágyazott elemek, illetve az ilyeneket tartalmazó dokumentumok aláírását is 73 7. A protokollok összegzése Az előző fejezetekben számos, a biztonság témakörén belül kifejezetten a hitelesítést illetve a hiteles azonosítást megvalósító protokollt mutattunk be. Ezek a protokollok nagymértékben különböznek egymástól az általuk nyújtott biztonsági szolgáltatásokban, az ezekhez igénybe vett kriptográfiai mechanizmusokban, illetve abban, hogy szolgáltatásaikat a protokoll ill. rétegmodellek mely rétegén

nyújtják Célszerűnek látszik tehát, hogy a vázolt protokollokat egy táblázat formájában is összegezzük, ezzel esetleg további segítséget nyújtva a témakör és a protokollok iránt érdeklődőknek. Minden protokoll esetén feltüntetjük a protokoll nevét (zárójelben mögötte megadjuk, hogy mely fejezetben ill pontban foglalkoztunk részletesebben a protokollal), ezután megadjuk, hogy a rétegmodell mely rétegén nyújtja az adott szolgáltatásokat, majd megadjuk a protokoll jellemző alkalmazási területét, végül felsoroljuk a szolgáltatás nyújtásához felhasznált kriptográfiai és hitelesítési mechanizmusokat. A könnyebb eligazodás végett a protokollokat a következő táblázatban a nevük alfabetikus sorrendjében rendszerezzük. I. Protokoll ARAN (4.41) II. Szolgáltatási réteg Hálózati réteg III. Jellemző alkalmazási terület IV. Felhasznált módszerek Hitelesített forgalomirányító csomagok küldése útválasztók

között, vezetéknélküli ill. ad hoc hálózatokban A TLS protokoll kiterjesztése nem megbízható (UDP alapú) kapcsolatokra. Hitelesítés: PKI tanúsítványok Integritásvizsgálat: digitális aláírással DTLS (5.5) Szállítási réteg IKE (4.33) Hálózati réteg Az IPSec kulcscsere mechanizmusa, két végpont közötti biztonsági kapcsolat (SA) felépítése. IPSec (4.3) Hálózati réteg Két hálózati végpont közötti titkosított és/vagy hitelesített kapcsolat felépítése. Kerberos (6.31) Alkalmazási réteg NDM (4.42) Hálózati réteg Oakley (4.24) Hálózati réteg Payword (6.22) PCT (5.2) Alkalmazási réteg Szállítási réteg PEM (6.11) Alkalmazási réteg Bróker alapú SSO rendszer hiteles azonosítására és jogosultságvizsgálatra, köztes kommunikációs csatorna titkosítása. Két hálózati végpont közötti biztonságos kommunikáció a hálózati topológia elrejtésével. Megosztott titok generálásával vagy előzetesen

megosztott titkok használatával biztonságos hálózati szintű kapcsolat létrehozása. Biztonságos elektronikus kereskedelem digitális zsetonok segítségével. Biztonságos szállítási réteg-szintű kapcsolat felépítése kliens-szerver architektúrában a szerver (és opcionálisan a kliens) hitelesítésével. Titkosított és/vagy hitelesített elektronikus üzenetek küldése, mögöttes kulcskezelési infrastruktúrával. PGP (6.13) Alkalmazási réteg PHOTURIS (4.22) Hálózati réteg SET (6.21) Alkalmazási réteg S-HTTP (6.41) Alkalmazási réteg Titkosított és/vagy hitelesített elektronikus üzenetek küldése, mögöttes kulcskezelési infrastruktúrával és bizalmi modellel. Megosztott titok generálásával biztonságos hálózati szintű kapcsolat létrehozása. Biztonságos elektronikus tranzakciók és kereskedelem. A Világhálón elhelyezett oldalak biztonságos letöltése a HTTP kiterjesztésével. Titkosítás: Triple-DES Hitelesítés: DSS

Üzenetpecsét: SHA-1, HMAC Kulcscsere: Diffie-Hellman Hitelesítés: digitális aláírás, kétféle nyilvános kulcsú (PKI tanúsítványok) vagy előre egyeztetett titok Kulcscsere: Diffie-Hellman, előzetesen megosztott titok Titkosítás: DES, Triple-DES Hitelesítés: előre kiosztott kulcsok, PKI tanúsítványok Üzenetpecsét: MD5, SHA-1, HMAC Kulcscsere: IKE Titkosítás: DES, Triple-DES Üzenetpecsét: MD4, MD5, CRC Hitelesítés: PKI tanúsítványok Titkosítás: nyilvános kulccsal Üzenetpecsét Kulcscsere: Diffie-Hellman Hitelesítés: PKI tanúsítványok Titkosítás: DES, Triple-DES, RC2 Hitelesítés: nincs előírva Üzenetpecsét: MAC, DSA, RSA Kulcscsere: Diffie-Hellman, RSA Titkosítás: DES Üzenetpecsét: MD2 és MD5 Hitelesítés: PKI tanúsítványok Kulcscsere: RSA Titkosítás: IDEA, Triple-DES, RSA, ElGamal Üzenetpecsét: MD5, SHA-1 Kulcscsere: Diffie-Hellman Üzenetpecsét: MD5 Titkosítás: DES, RC4, RSA Hitelesítés: PKI tanúsítványok Kettős

aláírás (RSA) Kulcscsere: RSA Titkosítás: DES, IDEA, RC2, CDMF Hitelesítés: PKI tanúsítványok Üzenetpecsét: HMAC Kulcscsere: Diffie-Hellman és RSA 74 I. Protokoll SKEME (4.23) II. Szolgáltatási réteg Hálózati réteg III. Jellemző alkalmazási terület IV. Felhasznált módszerek Megosztott titok generálásával vagy előzetesen megosztott titkok használatával biztonságos hálózati szintű kapcsolat létrehozása. Megosztott titok generálásával biztonságos hálózati szintű kapcsolat létrehozása, csomagtitkosítással és – hitelesítéssel. Kulcscsere: Diffie-Hellman Nyilvános kulcsokkal titkosított félkulcsok SKIP (4.21) Hálózati réteg S/MIME (6.12) Alkalmazási réteg Titkosított és hitelesített elektronikus üzenetek küldése. SRP (4.43) Hálózati réteg Biztonságos forgalomirányító protokoll SSH (6.32) Alkalmazási réteg Ügynök alapú SSO rendszer, jellemzően távoli bejelentkezésre és rendszermenedzselésre,

a kliens és a szerver közötti tikosított csatornán keresztül. SSL (5.1) Szállítási réteg Biztonságos szállítási réteg-szintű kapcsolat felépítése kliens-szerver architektúrában a szerver (és opcionálisan a kliens) hitelesítésével. Surf’n’Sign (6.42) TLS (5.3) Alkalmazási réteg Szállítási réteg WTLS (5.4) Szállítási réteg A Világhálón elhelyezett oldalak (tipikusan űrlapok) aláírása. Biztonságos szállítási réteg-szintű kapcsolat felépítése kliens-szerver architektúrában a szerver (és opcionálisan a kliens) hitelesítésével. Biztonságos szállítási réteg-szintű kapcsolat felépítése vezetéknélküli ill. ad hoc hálózatokban a mobil eszköz és a WAP átjáró között. Titkosítás: DES, Triple-DES, RC2, IDEA Hitelesítés: PKI tanúsítványok Üzenetpecsét: MD5, SHA-1 Kulcscsere: Diffie-Hellman Titkosítás: RC2 (40 bit), Triple-DES Üzenetpecsét: SHA-1 Hitelesítés: PKI tanúsítványok Kulcscsere: RSA

Kulcscsere: Diffie-Hellman Csomaghitelesítés és integritásvizsgálat MAC kóddal Titkosítás: DES, Triple-DES, Blowfish, AES, Twofish Hitelesítés: PKI tanúsítványok, nyilvános/privát kulcs-pár Üzenetpecsét: MAC, CRC, HMAC, SHA1 Kulcscsere: Diffie-Hellman Titkosítás: DES, Triple-DES, RC2, RC4, SKIPJACK Hitelesítés: PKI tanúsítványok, DSA Üzenetpecsét: MD5, SHA-1 Kulcscsere: KEA, RSA Aláírás: RSA Üzenetpecsét: MD5 Titkosítás: Triple-DES Hitelesítés: HMAC, DSS Üzenetpecsét: SHA-1 Kulcscsere: Diffie-Hellman Titkosítás: DES, Triple-DES, RC5, AES, ECC Üzenetpecsét: HMAC, SHA-1, MD5 Kulcscsere: RSA, Diffie-Hellman, ECDH Hitelesítés: PKI tanúsítványok, saját formátumú tanúsítványok 75 8. Összefoglalás A dolgozat elsődleges célja a napjainkban elterjedt, biztonsági (ezen belül is a hitelesítési) mechanizmusokat támogató illetve megvalósító protokollok lehető legszélesebb körű bemutatása volt. Más szavakkal élve a

protokollok olyan horizontális öszszegzését készítettük el, amely önmagában is hasznosítható, illetve későbbi, az egyes protokollokra és algoritmusokra fókuszáló, vertikális elemzések alapjául szolgálhat. A jelen dolgozat további tárgya volt annak bemutatása, hogy a felmerülő biztonsági jellegű problémák többféleképpen, különböző protokollok által is megoldhatóak, akár különálló protokollokkal, akár ezek kombinációjával, de mindenképpen az adott probléma által támasztott igényeknek megfelelően. Ezért a dolgozat nem titkolt célja volt annak megmutatása is, hogy a szabványosítási szervezetek és az iparágban jelentős szerepet vállaló cégek minden törekvése ellenére sem létezik jelenleg „az” univerzális, mindenre gyógyírt nyújtó biztonsági protokoll. A dolgozat során – köznapi életből kölcsönzött analógiák felhasználásával – bemutattuk a felmerülő hitelesítéssel kapcsolatos problémákat, a

megoldást nyújtó mechanizmusok kriptográfiai hátterét és a mechanizmusok közül is néhányat, illetve az ezeket a mechanizmusokat felhasználó, komplexebb, így a biztonság témakörén belül több területet is lefedő protokollok egyes jelentős képviselőit. Mint oly sok más terület viszonylatában, a szakirodalomban ezen protokollok osztályozásával kapcsolatban sem létezik egységes nézet, ezért mi a protokollok oly módon való osztályozását választottuk, ami azon alapul, hogy a protokoll a TCP/IP protokoll modell mely rétegén fejti ki hatását. (A dolgozat során arra is kitértünk, hogy miért nem az ISO/OSI hivatkozási modellt választottuk, illetve hogy miért csak a hálózati és afölötti rétegeken működő protokollokat vettük figyelembe.) A protokollok bemutatásából kitűnhet, hogy ezek túlnyomórészt a nyilvános kulcsú kriptográfia módszereit alkalmazzák, amelyek viszont egyrészt valamely mögöttes (legyen az bármilyen

csekély) infrastruktúrát, másrészt pedig az e mögött rejlő bizalmi viszonyok modelljét feltételezi (és miként arra már kitértünk, a bizalom mindig a bizalmas információt birtokló személyes megítélésétől függ); az előző fejezetekben ezekre is kitértünk. Nem esett szó ugyanakkor a felhasználó szerepéről, pedig – mint minden biztonsággal kapcsolatos rendszerben – rendszerint a leggyengébb láncszem mindig az ember: hiába alkalmazunk elképesztően bonyolult, több ezer bites kulcsokat, ha a felhasználó nem biztonságos helyen tárolja azokat, vagy egyszerűen elfelejti az azokat védő jelszavát. A felhasználó szerepéről, valamint a dolgozatban tárgyalt további témakörökről bőséges irodalom található a könyvesboltokban és az Interneten, a téma iránt érdeklődőknek ezeket ajánljuk; az Irodalomjegyzékben pedig megtalálhatóak a felhasznált munkák elérhetőségei is. Zárógondolatként megjegyezzük, hogy az informatika

általánosságban is (és a biztonság vonatkozásában főleg) egy minden képzeletet felülmúlóan dinamikus tudományág. Nemcsak a meglévő protokollokhoz készülnek biztonsági kiegészítések, de teljesen újak is születnek, amelyek mindig a technika más területein megjelenő újdonságok igényeihez igazodnak, ezért nemcsak a fentiekben emlegetett cégeknek és szabványosítással foglalkozó szervezeteknek, de az „egyszerű” szakembereknek és a laikusoknak is komoly erőfeszítéseket kell tenniük ahhoz, hogy szakmailag naprakészek lehessenek. A témaválasztáskor és a jelen dolgozat elkészítésekor nem titkolt szándékunk volt, hogy a dolgozat keretei közé szorítva bár, de segítséget nyújtsunk ebben – legalábbis egy összegző munka erejéig. 76 Fogalomtár Ad hoc hálózat: Változó (nem rögzített) hálózati topológiával rendelkező kommunikációs hálózat (42). Aláírás tulajdonosa: Az a személy, aki kizárólagos módon képes

a digitális aláírás létrehozására (68). Azonosságvizsgálat/azonosítás: Mechanizmus annak ellenőrzésére, hogy az azonosítás alatt álló személy meghatározott ismerettel, jellemzővel vagy eszközzel rendelkezik (5). AH/ESP fejrész: Az IPSec hitelesítési és titkosítási funkcióit ellátó fejrész (38). ARAN: Hitelesített forgalomirányító protokoll a hálózati réteg szintjén (42). Biztonsági ágens: Hitelesítési mechanizmust megvalósító logikai hálózati komponens az NDM módszernél (45). Bizalmi háló, bizalmi lánc: Valamely rendszerben az egymásban megbízó entitások közötti logikai kapcsolatok irányított gráfja (24). Biztonsági Kapcsolat: Az IPSec-ben definiált, két végpont közötti egyirányú logikai összeköttetés (37). Biztonságos hitelesített kulcscserélő protokoll: Kommunikálni szándékozó entitások között a kulcsok szétosztását hitelesített módon megvalósító módszer (32). Bróker alapú megközelítés:

Az egyszeri beléptetéses rendszerek azon osztálya, ahol a felhasználó vagy alkalmazás azonosságát a brókertől kapott egyfajta tanúsítvány hitelesíti egy szolgáltatás igénybevételéhez (75). Csomagismétléses támadás: Olyan aktív támadásfajta, ahol a támadó egy elfogott csomagot kis időbeli késleltetéssel újraküld (37). DES: Szimmetrikus kulcsú, szorzat típusú titkosító szabvány (10). Diffie-Hellman kulcscsere: Nyilvános kulcsú kriptográfiai algoritmus megosztott (közös) titok létrehozására két olyan entitás között, akik nem rendelkeznek semmiféle előzetes ismerettel egymásról (32). Digitális tanúsítvány: Olyan adatszerkezet, amely hitelesített módon kapcsolja össze egy entitás azonosítóját és nyilvános kulcsát (21). Digitális zseton: A Payword protokollban alkalmazott kriptográfiai érték (74). DTLS: A TLS protokoll datagram alapú hálózatokra való kiterjesztése a szállítási réteg szintjén (58). Egyszeri

beléptetéses (SSO – Single Sign-On) rendszer: Olyan azonosítási rendszer, ahol a felhasználó egyszeri hiteles azonosításával több azonosítást igénylő rendszerre is bejelentkezhet (75). Egyszerű elektronikus aláírás: Jogi bizonyító erővel nem bíró elektronikus aláírás (68). Elektronikus aláírás: Elektronikus dokumentumhoz rendelt olyan elektronikus adat, amely egyértelmű logikai kapcsolatot ad meg a dokumentum és az aláírója között (66). Elektronikus dokumentum: Tetszőleges dokumentum, amelynek létezik elektronikus formája; lényegileg egy általános bitsorozat (67). Elektronikus irat: Jellemzően szöveg-alapú elektronikus dokumentum, amelyhez kapcsolódhat ábra vagy fejléc is (67). Elektronikus okirat: Elektronikus dokumentum, amely a papír alapú okiratokkal egyező jogi bizonyító erővel rendelkezik (67). Előzetes mester-titok: További kulcsok (megosztott titkok) generálásához felhasznált érték (49). Faltörő módszer:

Támadási módszer, amely során a támadó a kulcstér összes elemének végigpróbálásával kísérli meg a kulcs feltörését (12). Fokozott biztonságú elektronikus aláírás: Jogi bizonyító erővel rendelkező elektronikus aláírás (68). Fokozott biztonságú (minősített) tanúsítvány: Minősített hitelesítés-szolgáltató által kibocsátott, emelt biztonsági szintű digitális tanúsítvány (69). 77 Hibrid módszerek: Olyan kriptográfiai módszerek, ahol a kulcsok kiosztását aszimmetrikus kulcsú kriptográfiai módszerek biztosítják, míg az összeköttetést a nyilvános kulcsokkal létrehozott szimmetrikus kulcs védi (18). Hierarchikus bizalmi modell: Olyan modell, ahol a bizalmi háló fa-struktúrájú (24). Hiteles azonosítás: Valamely hitelesítési mechanizmus által támogatott azonosítási módszer (6). Hitelesítés-szolgáltató: A nyilvános kulcsú infrastruktúra azon komponense, amely a tanúsítványok kibocsátását,

nyilvántartását és visszavonását végzi (21, 26). Hitelesítési szabályzat: Tanúsítványok felhasználhatóságát meghatározó szabályrendszer nyilvános kulcsú infrastruktúrákban (27). Hitelességvizsgálat/hitelesítés: Olyan mechanizmus, amely segítségével egy entitás bizonyíthatja az önmagáról állítottak valódiságát (5). Hitelességvizsgáló szerver: A Kerberos rendszer azon funkcionális egysége, amely az entitás hiteles azonosítását végzi el a beléptetést megelőzően (76). IDEA: Szimmetrikus kulcsú blokk-titkosító algoritmus (11). Időbélyeg: Valamely időpontot azonosító érték (19). IKE: Az IPSec kulcscserélő protokollja (39). IP-címhamisítás: Olyan támadási módszer, amelynél adott IP címen elhelyezkedő hálózati entitás más IP címen elhelyezkedőnek állítja be magát (37). IPRA: A PEM hierarchikus hitelesítési keretrendszer gyökereként funkcionáló, tanúsítványok kibocsátását és kezelését végző

entitás (61). IPSec: A hálózati réteg szintjén két végpont közötti titkosított és hitelesített logikai öszszekötést megvalósító protokoll (37). Irat ellenőrzője: Az elektronikus dokumentumok hitelesítési folyamatának azon szereplője, aki az elektronikus aláírás hitelességét ellenőrzi (68). Jegy: Olyan speciális tanúsítvány, amely a Kerberos rendszerben igazolja, hogy az entitás jogosult valamely szolgáltatás igénybe vételére (76). Jegyigazoló jegy: A Kerberos rendszerben a kulcskiosztó központ által adott olyan jegy, amellyel az entitás a jegyigazoló szerverhez fordulhat valamely szolgáltatás igénybe vétele céljából (77). Jegyigazoló szerver: A Kerberos rendszer azon funkcionális egysége, amely személyazonosságot hitelesítő jegyeket bocsát ki (77). Kettős aláírás: Digitális aláírási technika, amely segítségével két entitás számára küldhető egyetlen fizikai üzenetben két logikai üzenet oly módon, hogy a

másiknak szóló üzenet elolvasására a fogadók nem képesek, viszont biztosak lehetnek benne, hogy létezik a nekik szóló üzenet párja (72). Kerberos: Bróker alapú egyszeri beléptetéses rendszer az alkalmazási réteg szintjén (75). Kerberos hitelesítő: A viszonykulccsal titkosított időbélyeg a Kerberos rendszerben (76). Közbeékelődéses támadás: Olyan támadási módszer, amely során az aktív vagy paszszív támadó két kommunikáló entitás közé beékelődve lehallgatja a kapcsolatot oly módon, hogy mindkét entitás a támadót hiszi a másik entitásnak (20). Kötelezvény: A Payword protokollban a vásárlótól a kereskedőhöz küldött üzenet, amely tartalmazza a vásárlót hitelesítő információt, illetve digitális zsetonokat (74). Kulcskarika: A PGP rendszerben a nyilvános kulcsok tárolására szolgáló adatszerkezet vagy fájl (65). Kulcskiosztási probléma: Olyan probléma, amely tárgya, hogy nem biztonságos hálózaton keresztüli

biztonságos kommunikációhoz hogyan egyeztethetőek a kommunikációt védő titkosító és hitelesítő kulcsok (13). Kulcskiosztó központ: Funkcionális egység a Kerberos rendszerben, amely az entitás hiteles azonosítása után titkosító kulcsot ad az entitás és a szolgáltatást nyújtó kiszolgáló közötti kapcsolat titkosításához (77). Magánkulcs/privát kulcs: Nyilvános kulcsú rendszerekben a kriptográfiai kulcs-pár azon tagja, amelyet csak az azt birtokló entitás ismer (12). MD5: 128 bites kimenetet generáló üzenetpecsét-algoritmus (16). 78 Megbízható Bemutató: A PGP rendszerben ily módon aláírt tanúsítvány birtokosa által aláírt újabb tanúsítványt a láncban első entitás is hitelesként fogadja el (25). Meta-Bemutató: A PGP rendszerben az ily módon aláírt tanúsítvány birtokosa Megbízható bemutatóként írhat alá egy újabb tanúsítványt (25). MIME és S/MIME: Szabványos elektronikus üzenetküldési protokoll, és

annak biztonsági funkciókkal kiegészített kiterjesztése (63). Minősített elektronikus aláírás: Minősített hitelesítés-szolgáltatónál nyilvántartott, teljes jogi bizonyító erővel bíró elektronikus aláírás (68). Minősítetlen (egyszerű) tanúsítvány: Minimális (vagy semmilyen) felelősségvállalást biztosító, minimális azonosítás mellett kibocsátott tanúsítvány (69). NDM: A hálózati réteg szintjén való titkosított és/vagy hitelesített csomagküldést megvalósító protokoll, amely elrejti a küldő csomópont hálózatbeli elhelyezkedését (45). Nyilvános kulcs: Nyilvános kulcsú rendszerekben a kriptográfiai kulcs-pár azon tagja, amelyet az azt birtokló entitás nyilvánosságra hoz (12). Nyilvános kulcsú infrastruktúra: A digitális tanúsítványok hitelesítési célokra való felhasználását lehetővé tévő, nyilvános kulcsú kriptográfiai módszereket alkalmazó komponensek összessége (25). Oakley: Nyilvános

kulcsú kriptográfiai mechanizmusokat alkalmazó kulcscserélő protokoll a hálózati réteg szintjén (36). Önaláírás: Aláírási mechanizmus, amely során a tanúsítvány birtokosa a saját tanúsítványát írja alá, vagyis lényegileg a sajt nyilvános kulcsát hitelesíti (23). Payword: Elektronikus kereskedelmi protokoll az alkalmazási réteg szintjén, amely nyilvános kulcsú kriptográfiai technikákkal és digitális zsetonokkal valósítja meg az elektronikus fizetési mechanizmust (74). PCA: A PEM hierarchikus hitelesítési keretrendszer második szintjén elhelyezkedő entitás, amely az alatta lévő szinten elhelyezkedő hitelesítés-szolgáltatók hitelesítését végzi (61). PCT: Titkosított és/vagy hitelesített kliens-szerver architektúrájú kommunikációt megvalósító protokoll a szállítási réteg szintjén (53). PEM: Titkosított és/vagy hitelesített elektronikus üzenetküldést megvalósító protokoll és mögöttes kulcskezelési

infrastruktúra az alkalmazási réteg szintjén (60). PGP: Titkosított és/vagy hitelesített elektronikus üzenetküldést megvalósító protokoll és bizalmi modell az alkalmazási réteg szintjén (23, 64). Photuris: Nyilvános kulcsú kriptográfiai és süti-mechanizmusokat alkalmazó kulcscserélő protokoll a hálózati réteg szintjén (34). Regisztráló hatóság: A nyilvános kulcsú infrastruktúra azon funkcionális egysége, amely a tanúsítvány-kérelmeket fogadja és regisztrálja (26). RSA kulcscsere: Nyilvános kulcsú kriptográfiai algoritmus megosztott (közös) titok létrehozására két olyan entitás között, akik nem rendelkeznek semmiféle előzetes ismerettel egymásról (14). SET: Elektronikus tranzakciók biztonságos végrehajtását elősegítő protokoll az alkalmazási réteg szintjén (71). SHA: 160 bites kimenetet generáló üzenetpecsét-algoritmus (17). S-HTTP: A Világhálón elhelyezkedő oldalak titkosított és/vagy hitelesített

letöltését lehetővé tevő protokoll az alkalmazási réteg szintjén (82). SKEME: Nyilvános kulcsú kriptográfiai mechanizmusokat alkalmazó kulcscserélő protokoll a hálózati réteg szintjén (35). SKIP: Nyilvános kulcsú kriptográfiai mechanizmusokat alkalmazó kulcscserélő protokoll a hálózati réteg szintjén (33). SRP: Biztonsági összeköttetéseken alapuló, nyilvános kulcsú kriptográfiai módszereket alkalmazó biztonságos forgalomirányító protokoll a hálózati réteg szintjén (46). SSH: Ügynök alapú egyszeri beléptetéses rendszer távoli bejelentkezésre és rendszermenedzselésre az alkalmazási réteg szintjén (79). SSL: Titkosított és/vagy hitelesített kliens-szerver architektúrájú kommunikációt megvalósító protokoll a szállítási réteg szintjén (48). 79 Surf’n’Sign: A Világhálón elhelyezkedő oldalak (jellemzően űrlapok) hiteles módon való elektronikus aláírását lehetővé tevő protokoll az alkalmazási

réteg szintjén (84). Süti (cookie): Az egyszerűbb szolgáltatásmegtagadási támadások megakadályozását elősegítő adatszerkezet (34). Szimmetrikus kulcs: Olyan kriptográfiai titkosító kulcs, ahol a kulccsal tikosított szöveg visszafejtése ugyanezen kulcs használatával lehetséges (12). Szolgáltatási szabályzat: A hitelesítés-szolgáltató tevékenységével kapcsolatos eljárási és működési szabályokat tartalmazó szabályzat (27). Szolgáltatásmegtagadási támadás: Olyan aktív támadási módszer, amely során a támadó akkora mennyiségű szolgáltatáskérési üzenetet küld a kiszolgálónak, hogy azok feldolgozása megbénítja a szolgáltatásnyújtási tevékenységet (34). Tanúsítványtároló: A nyilvános kulcsú infrastruktúra azon funkcionális egysége, amely a tanúsítványokon kívül a tanúsítvány-visszavonási listákat is tárolja (27). Tanúsítvány-visszavonási lista: A nyilvános kulcsú infrastruktúra azon

funkcionális egysége, amely a visszavont tanúsítványokat tárolja (27). Titkos kulcs: Szimmetrikus kriptográfiai kulcs (11). TLS: Titkosított és/vagy hitelesített kliens-szerver architektúrájú kommunikációt megvalósító protokoll a szállítási réteg szintjén (55). Tökéletes továbbított biztonság: A hitelesített kulcscserélő protokollok azon (opcionális) tulajdonsága, amely szerint ha a támadó megszerzi a kapcsolat hosszútávú kulcsát, abból nem képes a rövidtávú kulcsok kitalálására (32). Transzport mód: Az IPSec protokoll azon működési módja, amelyben csak az eredeti IP csomag adatrésze kerül titkosításra, az IP fejrész nem (38). Tunnel mód: Az IPSec protokoll azon működési módja, amelyben a teljes eredeti IP csomag titkosításra kerül, és ez alkotja az új IPSec csomag adatrészét (38). Ügynök (ágens): Az ügynök alapú egyszeri beléptetéses rendszerekben a felhasználóknak a további kiszolgálók felé való

hiteles azonosítását végző alkalmazás (82). Ügynök alapú megközelítés: Az egyszeri beléptetéses rendszerek azon osztálya, ahol a felhasználó vagy az alkalmazás azonosságának hitelesítését a hozzá rendelt ügynök alkalmazás végzi egy szolgáltatás igénybevételéhez (75). Üzenetpecsét-függvények (hash függvények): Olyan egyirányú kriptográfiai algoritmusok, amelyek változó hosszúságú szövegből rögzített hosszúságú kódolt szöveget (lenyomatot) készítenek (16). Vezetéknélküli (wireless) technológia: Olyan kommunikációs technológia, amely lehetővé teszi a hagyományos (vezetékes) csatornáktól eltérő, például infravörös vagy rádiófrekvenciás csatornák használatát a mobil eszközök és rögzített topológiájú hálózatban lévő eszközök (vagy más mobil eszközök) között (42). WTLS: A TLS protokoll vezetéknélküli vagy ad hoc hálózatokra való kiterjesztése a szállítási réteg szintjén (55).

X.509: Nyilvános kulcsú infrastruktúrákkal használható tanúsítványok formátumát, kezelését és visszavonását definiáló ajánlás (22). 80 A felhasznált irodalom és hivatkozások jegyzéke [1] Tannenbaum, Andrew S.: Számítógép-hálózatok, Panem Könyvkiadó Kft, 1999 Budapest (Prentice-Hall Inc.) ISBN 963 545 213 6, 619-637 oldal [2] Láng, Csabáné: Bevezető fejezetek a matematikába I. – egyetemi jegyzet ELTE, 1997., Budapest [3] http://www.dbassochu/maksign/dak/Nemetzbhtm, 2003 november 21 [4] HVG XXIV. Évfolyam 43 szám (2002 október 26), 65 oldal, ISSN: 1217-9647, INDEX:25385 [5] http://www.rsasecuritycom, 2003 november 21 [6] Tannenbaum, Andrew S.: Számítógép-hálózatok, Panem Könyvkiadó Kft, 1999 Budapest (Prentice-Hall Inc.) ISBN 963 545 213 6, 639 oldal [7] Schneier, Bruce: Applied Criptography, Second Edition: Protocols, Algorithms and Source Code in C, John Wiley & Sons Inc., 1996 január 1, ISBN: 0471128457 [8]

http://www.pgpiorg/doc/pgpintro, 2003 november 7 [9] http://www.faqsorg/rfcs/rfc2256html, 2003 október 28 [10] http://www.faqsorg/rfcs/rfc2459html, 2003 október 28 [11] http://www.itsecuritycom/papers/openpgphtm, 2003 október 28 [12] http://informatika.ilabsztakihu/dms/konyvtar/digitalis-alairas/ 2fejezetpdf, 2003. november 21 [13] http://www.garykesslernet/library/cryptohtml, 2004 március 23 [14] http://nws.iifhu/ncd2001/docs/eloadas/4/indexrtf, 2003 október 20 [15] www.schneiercom/paper-pki-fttxt, 2003 november 7 [16] Computerworld-Számítástechnika, XVII. Évfolyam 9 szám (2002 február 26), 16. oldal, IDG Magyarországi Lapkiadó Kft, ISSN: 0237-7837 [17] http://www.thebellnet/papers/certoverpdf, 2003 október 28 [18] http://www.hscfr/ressources/articles/ipsec-tech/indexhtmlen 2004 március 23 [19] http://www.faqsorg/rfcs/rfc2412html, 2004 március 23 [20] Computerworld-Számítástechnika, XVII. Évfolyam 29 szám (2002 július 16), 15. oldal, IDG Magyarországi Lapkiadó

Kft, ISSN: 0237-7837 [21] http://www.faqsorg/rfcs/rfc2401html, 2004 március 23 [22] http://www.faqsorg/rfcs/rfc2408html, 2004 március 23 [23] http://www.counterpanecom/ipsecpdf, 2004 április 5 [24] http://cs.engrukyedu/~singhal/term-papers/Fourth-paperdoc, 2004 április 11. [25] http://developer.netscapecom/docs/manuals/security/sslin/ contents htm, 2003. november 7 [26] http://bob.marlboroedu/~msie/2004/it/nov7-ether-crypto/ lecture.html#SSL, 2004 április 5 [27] http://www.graphcompcom/info/specs/ms/pcthtm, 2003 november 10 [28] http://www.faqsorg/rfcs/rfc2246html, 2004 április 14 [29] http://www.ietforg/internet-drafts/draft-ietf-tls-compression-07txt, 2004 április 14. [30] http://www.faqsorg/rfcs/rfc3546html, 2004 április 14 [31] www.giacorg/practical/GSEC/Holly McKinley GSECpdf, 2003 december 29 [32] http://www.ietforg/internet-drafts/draft-ietf-tls-rfc2246-bis-06txt, 2004 április 14 [33] http://www.hutfi/~jtlaine2/wtls/, 2004 április 14 [34]

http://community.roxencom/developers/idocs/drafts/draft-rescorla-dtls00html, 2004 április 14 [35] http://snoopy.seassmuedu/ee8392 summer01/week7/ perlman2pdf, 2003 november 7. [36] http://crypto.stanfordedu/~nagendra/papers/dtlspdf, 2004 április 14 [37] http://www.acsacorg/secshelf/book001/17pdf, 2004 április 14 81 [38] http://www.faqsorg/rfcs/rfc1421html, 2003 november 10 [39] http://www.faqsorg/rfcs/rfc822html, 2003 november 10 [40] http://www.faqsorg/rfcs/rfc2045html, 2003 november 10 [41] http://www.faqsorg/rfcs/rfc1847html, 2003 november 10 [42] http://www.osbornecom/networking comm/007213139X/ 007213139X ch08.pdf, 2004 április 14 [43] http://www.faqsorg/rfcs/rfc1991html, 2003 november 11 [44] http://www.faqsorg/rfcs/rfc2015html, 2003 november 11 [45] http://www.faqsorg/rfcs/rfc2440html, 2003 november 11 [46] http://www.ihmhu/jogszabalyok/ealairaspdf, 2003 október 20 [47] http://informatika.bkehu/root/Project/telepiacnsf/0/2c117 425271a1304c1256aa0002e5ae5?OpenDocument,

2003. október 20 [48] HVG XXIV. Évfolyam 43 szám (2002 október 26), 72 - 76 oldal, ISSN:12179647, INDEX:25385 [49] http://www.oubliettezetnetcouk/MSc/MscTwohtml, 2004 március 23 [50] http://ludens.eltehu/~papp/hitelesihtml, 2003 október 20 [51] http://security.tttbmehu/Jegyzet/jegy4pdf, 2003 október 20 [52] http://web.mitedu/kerberos/www/advisories/indexhtml, 2003 december 29. [53] http://www.sansorg/rr/papers/indexphp?id=206, 2003 december 29 [54] http://www.faqsorg/rfcs/rfc1510html, 2003 december 29 [55] http://www.vandykecom/solutions/ssh overview/ssh overviewpdf, 2004 április 19. [56] http://www.faqsorg/rfcs/rfc2616html, 2004 április 10 [57] http://www.faqsorg/rfcs/rfc2660html, 2003 november 10 [58] http://www.homeportorg/~adam/shttphtml, 2003 november 10 [59] Computerworld-Számítástechnika, XVII. Évfolyam 30 szám (2002 július 23), 11. oldal, IDG Magyarországi Lapkiadó Kft, ISSN: 0237-7837 [60] http://www.researchibmcom/journal/sj/371/herzberghtml, 2003 november 7

[61] http://www.olymporg/~caronni/work/papers/CDPhtml, 2004 május 6 [62] http://www.biztostuhu/oktatas/kriptologia/ECC 1 beveze tohtm, 2004 május 6 [63] http://www.biztostuhu/oktatas/kriptologia/aes 1 beveze tohtm, 2004 május 6 [64] http://www.biztostuhu/oktatas/kriptologia/ECC 4 ECDHhtm, 2004 május 6. [65] http://www.faqsorg/rfcs/rfc821html, 2004 április 14 [66] http://www.faqsorg/rfcs/rfc2315html, 2004 április 14 [67] http://www.netacademianet/konyv/kripto/kriptog15pdf, 2004 január 11 82 Ajánlott irodalom és honlapok http://biztostu.hu – Informatikai biztonsággal foglalkozó kiváló magyar oldal, protokollok és algoritmusok részletes leírásával és elemzésével http://www.counterpanecom – A modern kriptográfia egyik atyjaként ismert Bruce Schneier általalapított cég honlapja. Az oldalakon kriptográfiával kapcsolatos (néhol igen kritikus, de szellemes hangvételű) cikkek és alapos elemzések olvashatóak. http://www.faqsorg/rfcs/ - Az IETF hivatalos

honlapján rendszerezett formában találhatóak meg az RFC-k, illetve a tervezett és már elfogadott szabványok http://www.itsecuritycom – Informatikai biztonsággal kapcsolatos honlap, általános leírásokkal, konkrét gyakorlati megoldásokkal és jótanácsokkal látja el az oldalra látogatókat. http://www.netlockhu – Az egyik legrégebben működő hazai hitelesítés-szolgáltató honlapja. Részletese információkkal szolgálhat a hitelesítési mechanizmusok gyakorlati megvalósításával kapcsolatban. http://www.pki-pageorg – A nyilvános kulcsú infrastruktúrákkal foglalkozó egyik legnagyobb nemzetközi szervezet oldala, amelyen az érdeklődők részletes elemzésekkel, elméleti háttérrel és további hivatkozásokkal találkozhatnak http://www.rsasecuritycom – Az RSA algoritmus alkotói nevét viselő cég honlapján megtalálhatóak az RSA algoritmust alkalmazó megoldások leírásai, a cég saját szabványai/szabadalmai, valamint további

kriptográfiai jellegű írások. http://www.sansorg – A szervezet honlapján a kriptográfia teljes spektrumát átfogó írások olvashatóak az elektronikus olvasószobában, valamint további oldalakra mutató hivatkozások bőséges választékával találkozhatnak az érdeklődők. 83 Köszönetnyilvánítás Ezúton szeretném köszönetemet kifejezni témavezetőmnek, Kincses Zoltánnak, hogy értékes megjegyzéseivel és tanácsaival mindig segítségemre volt a dolgozat megírása során. Hálával tartozom a Családomnak, akik mindenben támogattak, és lehetővé tették, hogy egyáltalán eljussak a dolgozat megírásáig, valamint megértéssel és türelemmel voltak irántam a dolgozatírás közben. Végezetül külön köszönet és hála illeti a barátnőmet, Andit, aki ezt az egészet egyszer már végigcsinálta, és amikor mélypontra érkeztem, mindig tudta, hogy mivel rántson ki belőle. Nélküle a dolgozat nem születhetett volna meg Ezer köszönet

és hála mindannyiótoknak!