11.5. Bizalmi modellek

A nyilvános kulcsú infrastruktúrában kiemelt fontossággal bír a bizalom. Az infrastruktúra feladata, hogy a bizalmat, a megbízhatóságot továbbítsa és kezeskedjen az egyes szereplőkért illetve tanúsítványokért. A nyilvános kulcsú infrastruktúra kapcsán alapvetően kétféle bizalomról beszélhetünk. Egyrészt a bizalom jelentheti egy adott tanúsítvány megbízhatóságát, azt a tényt, hogy a vonatkozó titkos kulcs valóban annak a birtokában van, akinek az adatai a tanúsítványban szerepelnek. Másrészt egy teljesen általános értelemben vett bizalomról is szó lehet, ahol egy adott entitástól egy meghatározott viselkedést várunk el. Az ebben az értelemben vett bizalom természetesen nem lehet teljes bizonyosságú, amikor emberi tényezőkről van szó. Azt hogy a bizalom milyen utat jár be és hogyan teszi lehetővé az egyes protokollok végrehajtását, alkalmazások használatát az alkalmazott bizalmi modell határozza meg. A körülményektől, a lehetőségektől, az elvárásoktól és a szervezeti felépítéstől függően az egyes helyzetekben más és más bizalmi modellek használata lehet indokolt.

Az egyes bizalmi modellek három központi kérdés körül forognak (refp2.131):

1. Hogyan határozzuk meg, hogy az egyes tanúsítványokat egy adott szereplő megbízhatónak talál-e vagy sem?

2. Hogyan alapozható meg a bizalom?

3. Milyen körülmények között korlátozható vagy szabályozható ez a bizalom egy adott környezetben?

11.5.1. Szigorú hierarchia

A legalapvetőbb bizalmi modell. Minden modell ennek valamilyen változata, bővítése. A bizalom továbbadásának, megalapozásának módszere (a tanúsítvány lánc) is alapvetően megegyezik. A szigorú hierarchiánál az egyes hitelesítő szervezetek (CA - Certificate Authority) egy fa-struktúrába vannak rendezve. A fa gyökerében álló hitelesítő szervezet a gyökér CA, vagy más néven a bizalmi horgony. A modell alapja, hogy a rendszer minden szereplője megbízik a gyökérben. Ebből indul ki a bizalom továbbadása a tanúsítványláncon. A modell működésének előfeltétele, hogy a hierarchia minden résztvevője birtokában legyen a bizalmi horgony saját maga által aláírt tanúsítványának. Ezt a biztonság érdekében nem internetes csatornákon kell továbbítani vagy ellenőrizni. Tipikus megoldás a gyökér tanúsítványának valamilyen digitális ujjlenyomattal, ellenőrző összeggel való megerősítése. Ebben az esetben természetesen az ellenőrző összeget kell nem elektronikus csatornákon felülvizsgálni.

A bizalmi fa levélelemei a végfelhasználók, a köztes elemek pedig az alárendelt hitelesítő szervezetek. Szigorú hierarchia esetén a bizalom mindig a bizalmi horgonyból indul ki és a fában a kérdéses levélelemhez vezető úton az egyes alárendelt hitelesítő szervezeteken halad keresztül. Az úton a két elem közötti bizalom továbbadása digitális aláírás segítségével történik. Egy hitelesítő szervezet azzal szavatol a közvetlenül alatta lévő CA megbízhatóságáért, hogy annak tanúsítványát aláírja. Ennek megfelelően, amikor valamely végfelhasználó ellenőrizni akar egy másikat, akkor a bizalmi horgonyból kiindulva végigellenőrzi a hozzá vezető útvonalon a hitelesítő szervezetek tanúsítványait.

Tehát például, ha a gyökérből (G) egy U felhasználóig vezető úton rendre CA1, CA2 és CA3 alárendelt hitelesítő szervezetek szerepelnek, akkor az ellenőrző félnek U megbízhatóságának megítéléséhez első lépésben CA1 tanúsítványát kell ellenőriznie. Ha a gyökér tanúsítványának segítségével ellenőrizte és helyesnek találta a CA1 tanúsítványán lévő aláírást, akkor azt megbízhatónak ítéli. Következő lépésben az ellenőrző fél CA2 tanúsítványát fogja ellenőrizni az ekkorra már megbízhatónak ítélt CA1 tanúsítványával. Ha ennek alapján CA2 tanúsítványát megbízhatónak találja, akkor annak segítségével megalapozhatja CA3 megbízhatóságát. Ha sikeresen ellenőrizte CA3 tanúsítványát, akkor azt felhasználva dönthet U megbízhatóságáról. Kölcsönös ellenőrzés után megkezdődhet a biztonságos kommunikáció a két fél között.

5. ábra

11.5.2. Laza hierarchia

A hitelesítési szervezetek itt is a szigorú hierarchiához teljesen hasonló fa-struktúrába szerveződnek. A fő különbség, hogy itt az egyes szereplők nem kizárólag a gyökér tanúsítványával rendelkeznek alaphelyzetben, hanem a saját tanúsítványukat kibocsájtó hitelesítő szervezet tanúsítványával is. Ez lehetővé teszi a lokális hitelesítést, nevezetesen, ha a két fél ugyanazon hitelesítési szervezet hatáskörébe tartozik, akkor nem szükséges a tanúsítványláncot a gyökérig felépíteni és ellenőrizni, hanem elegendő a bizalmat a lokális CA -ig visszavezetni. Ebben az esetben a bizalom nem szigorúan véve a bizalmi horgonytól kerül levezetésre, hanem a tanúsítványt kibocsájtó szervezettől.

11.5.3. Szabályzat alapú hierarchiák

Mind a szigorú mind a laza hierarchia esetén egy hitelesítési szervezetnek csak egy fölérendeltje lehetett. A szabályzat alapú hierarchia lehetővé teszi, hogy egy CA-nak tetszőleges számú fölérendeltje legyen. Ez virtuálisan több szigorú hierarchia párhuzamos használatát jelenti. Az egyes hierarchiák jelentik az egyes szabályzatokat, szabályozásokat. Az egyes szabályzatok az adott helyzetben elvárt szervezeti felépítés vagy szerkezet egyes ágait hivatottak képviselni és a bizalmi modell szintjén reprezentálni.

11.5.4. Elosztott bizalmi architektúra

Az elosztott bizalmi architektúra lehetővé teszi a szereplők hitelesítését több különböző bizalmi hierarchia esetén is. Több különböző hierarchia esetén több különböző bizalmi horgony van jelen és közvetlenül mindegyikük az architektúrának csak a saját fa-struktúrájába tartozó részét tudja hitelesíteni. Az egyes szereplők alaphelyzetben csak a saját gyökér CA -juk tanúsítványában bíznak meg. A teljes körű hitelesítés megvalósításához tehát szükség van valamilyen módszerre, amivel a bizalmat az egyes bizalmi horgonyok között továbbítani lehet. Erre a legelterjedtebb megoldás a kereszthitelesítés vagy más néven a "PKI networking".

Háló konfiguráció esetén a bizalmi horgonyok teljesen vagy majdnem teljesen kapcsoltak páronkénti kereszthitelesítéssel. Ez a megoldás akár tetszőleges két végfelhasználó kölcsönös hitelesítését is lehetővé teheti, viszont ehhez megközelítőleg n(n-1)/2 kereszthitelesítésre van szükség.

A hub konfiguráció (Hub-and-Spoke) egy kitűntetett hitelesítő szervezet jelenlétét feltételezi. Ez a kitűntetett hitelesítő szervezet a hub, ez áll kereszthitelesítéssel összeköttetésben az egyes bizalmi horgonyokkal. A kereszthitelesítés lehetővé teszi, hogy a hubon keresztül más hierarchiákba is eljusson az egyes gyökerek által képviselt bizalom. Ez a megoldás nem összesíti az architektúrát egyetlen hierarchiába, hiszen a kezdeti bizalom minden résztvevő esetén csak a saját bizalmi horgonyához kötődik, minden szereplőnél csak a saját gyökerének a tanúsítványa van, csak az abba helyezet bizalmat várjuk el az architektúra működéséhez. A hub architektúra előnye, hogy n bizalmi horgony esetén csupán n+1 kereszthitelesítésre van szükség.

Egyéb alternatív megoldások a kereszt-elismerés (nem technológiai jellegű megoldás, nem elektronikus eljárással hidalja át a problémát), a Tanúsítvány Bizalmi Lista (CTL - Certificate Trust List) amely a megbízható bizalmi horgonyok listáját jelenti, illetve az Akkreditációs Tanúsítvány amivel egy megbízható és ismert tanúsítványkiadó szervezet felelősséget vállal egy kisebb CA -ért. Az Akkreditációs Tanúsítvány nem jelenti a kisebb CA integrálását a kiadó szervezet hierarchiájába, továbbra is független marad tőle.

11.5.5. A "Négy Sarok" bizalmi modell

A négy sarok bizalmi modell egy tipikus feliratkozási illetve vásárlási szituációt vesz alapul. A szereplők itt egy feliratkozók vagy vásárlók illetve egy szolgáltató, kereskedő. Mindkét félhez tartozik egy külön hitelesítő szervezet, amelyek kereszthitelesítéssel igazolják egymást. A vásárlás során felépülő biztonságos kommunikációban a bizalom megalapozása ezen a kétpólusú hitelesítési rendszeren keresztül történik.

11.5.6. A webes modell

A modell a World Wide Web-ről kapta a nevét, az interneten alkalmazott ott kialakult modellt jelent. Itt az egyes különálló hierarchiákat nem a bizalmi horgonyok közötti kereszthitelesítések kötik össze, hanem az összes bizalmi horgony kiosztásra kerül az összes szereplőhöz. A gyakorlatban ez azt jelenti, hogy a szoftvergyártó a gyökér CA-k egy listájával szállítja a szoftvereit, így azok biztonságos és megbízható módon jutnak el a végfelhasználókhoz.

Maga a modell a gyakorlatban egyszerű és kényelmes, ugyanakkor feltételezi az összes bizalmi horgony teljes megbízhatóságát. Ha akár csak egy hitelesítő szervezet is megbízhatatlan vagy rosszindulatú befolyás alá kerül, akkor az egész rendszer kompromittálódik. Ebben a modellben a szoftver minden gyökér hitelesítő szervezetben egyformán és teljes mértékben megbízik, azaz, ha egy rosszindulatú befolyás alatt álló CA kiad egy olyan tanúsítványt ami valamelyik szereplő személyazonosságához egy, a támadó birtokában lévő kulcsot köt, akkor sikerrel személyesítheti meg a kommunikációban azt a szereplőt.

Ez a probléma más modellekben is felléphet, de ott jellemzően (a használt modelltől függő mértékben) lokális problémáról van szó. Az ilyen jellegű gyengeség a Webes modell esetében sokkal súlyosabb: a teljes architektúra kompromittálódását jelentik.

A helyzetet súlyosbítja, hogy a modell nem ad választ arra a kérdésre, hogy egy gyökér CA kompromittálódása esetén hogyan távolítható el a listából. A biztonsági rés felfedezése után mihamarabb frissíteni kell az összes listát a megbízhatóság helyreállítása érdekében. Ez azonban egy több millió felhasználót érintő alkalmazás tekintetében akadályokba ütközik.

További problémát jelent, hogy ebben a modellben semmiféle jogi kapcsolat nincs a felhasználó és a CA között, a felelősség az esetleges károkért nem vezethető vissza az egyes hitelességszolgáltatókig, minden felelősség a szoftvergyártót terheli, amit viszont az ingyenesen letölthető programok (például böngészők) esetében a licencszerződésben szereplő használati feltételek és kikötések alapján minden valószínűség szerint nem fog vállalni.

11.5.7. Felhasználó központú bizalom

Ebben a modellben minden felhasználó egyben hitelesítő szervezetként működik. Mindenki kialakítja a saját bizalomhálóját azzal, hogy a megbízhatónak ítélt ismerőseinek a tanúsítványát aláírja (ha CA-nak tekintjük őket akkor valamilyen típusú kereszthitelesítést végeznek). A bizalom, az egyes tanúsítványok ellenőrzése nem teljesen automatikus: a felhasználó dönt a kérdéses tanúsítványhoz vezető úton szereplő ismerős vagy ismerősök illetve az útvonal hossza alapján, hogy megbízik-e benne avagy sem. Ezt a modellt valósítja meg például a PGP (Pretty Good Privacy, refzimm) illetve a nyílt forráskódú verziója a GnuPG.

A rendszer fő problémáját az a feltételezés jelenti, hogy a felhasználók megértik és átlátják a publikus kulcsú infrastruktúra mibenlétét és az egyes esetekben erre a megértésre alapozva tudnak és akarnak is döntést hozni. Nevezetesen, hogy kinek a tanúsítványát írják alá és kiét ne, illetve hogy mely tanúsítási útvonalakat fogadjanak el és melyeket ne. Nagyon szimpatikus ez a feltételezés, de idealisztikus is. A felhasználók döntő többségéről ilyen felelősségteljes döntés nem várható el. Gondoljunk arra, hogy a leggyakrabban használt jelszavak még ma is az: abc123, qwertz, 12345678, stb..

11.5.8. Kereszthitelesítések

A kereszthitelesítés két hitelesítő szervezet közötti bizalomátadást tesz lehetővé. Alapvetően két fajtáját különböztetjük meg. Az egyik esetben a két CA ugyanahhoz a gyökérhez tartozik és ez a fajta kereszthitelesítés adja tovább a bizalmat például a hagyományos szigorú hierarchia esetében. Ezt nevezzük "intradomain" kereszthitelesítésnek. A másik változatban a két résztvevő CA két különböző bizalmi horgonyhoz tartozik. Ez az "interdomain" kereszthitelesítés. Az elosztott architektúrák esetén ez a fajta kereszthivatkozás az ami lehetővé teszi két különböző gyökérhez tartozó hierarchiák összekapcsolását. Osztályozhatjuk még a kereszthitelesítéseket annak iránya szerint. Ha csak az egyik CA hitelesíti a másikat, akkor egyirányú, ha mindketten hitelesítik a másikat, akkor kölcsönös kereszthivatkozásról beszélünk.

A kereszthitelesítés jelentősége túlmutat a különböző hierarchiák összekapcsolásán: lehetővé teszi a bizalom terjedésének korlátozását is. A tanúsítványok felépítését meghatározó X509 -es szabvány meghatároz több a bizalom továbbadását szabályozó kiterjesztést is. Ezekkel többek között megadható például, hogy hány kereszthitelesítésen haladhat át a bizalom (Path length constraint), hogy milyen alkalmazások esetén használható a hitelesítési út felépítésében az adott kereszthitelesítés (Policy constraints) illetve, korlátozható az is hogy a céldomain mely szereplőire vonatkozzon az átadott bizalom (Name constraints). Ezek segítségével megadhatóak olyan jellegű korlátozások, mint például, hogy az adott kereszthitelesítés csak SSL azonosítás során továbbítja a bizalmat, vagy hogy például a Debreceni Egyetemen csak az Informatikai Karhoz tartozó résztvevőkben bízunk meg.

11.5.9. Elnevezések

Az X500 Directory egy szabványt kínál az univerzálisan egyedi nevek megadására. Ez a szabvány feltétez az elnevezendő objektumok közötti hierarchikus felépítést, és ezzel együtt azt, hogy az egyes névtereket valamilyen egyén vagy szervezet felügyeli és a saját névterén belül az egyediséget biztosítja. Az X509 tanúsítványokban szerepel a hozzá tartozó entitás az X500 Directory szerinti úgynevezett megkülönböztetett neve (DN - Distinguished Name, lásd bővebben a tanúsítványok felépítését tárgyaló fejezetet).

Ezzel a konvencióval kapcsolatban több dolog is sértheti a nevek egyediségét. Először is nem áll rendelkezésre egy szervezet vagy személy a hierarchia minden szintjén, ami az egyes szervezetek személyek és entitások egyedi elnevezését felügyeli.

Másrészt az egyes területeken már léteznek különböző elnevezési konvenciók, amelyeket az adott szereplők megnevezésére használnak. Ilyen lehet például egy szerver esetében a domain név vagy az ip cím, illetve személyek esetében az e-mail cím.

11.5.10. A tanúsítványlánc feldolgozása

Mint ahogy már szó volt róla, a publikus kulcsú infrastruktúra célja két résztvevő közötti bizalom megalapozása valamilyen elektronikus kapcsolattartás előkészítésének céljából. Ehhez szükség van egy tanúsítvány láncra, amely a résztvevőket valamilyen módon a bizalmi horgonyokkal összeköti. A bizalom megalapozásának első lépése a tanúsítványlánc felépítése. A tanúsítványlánc felépítése az alkalmazott bizalmi modellnek megfelelően történik. A legegyszerűbb esetben, a hierarchikus modellnél a kérdéses tanúsítványtól visszafelé a gyökér CA -hoz az útvonalat az egyes tanúsítványokat kiállító szervezetek alapján egyértelműen fel lehet építeni. A hálós modellben viszont, mivel egy gyökér hitelesítő szervezet akárhány bizalmi horgonnyal lehet kereszthitelesítéses kapcsolatban, a tanúsítványlánc előállításához már komoly matematikai apparátus, illetve gráfkereső algoritmusok szükségesek.

Ha az útvonalat sikeresen előállítottuk, ellenőriznünk kell annak helyességét. Ez magában foglalja a tanúsítványlánc minden tanúsítványán az aláírás ellenőrzését, azt hogy meggyőződünk róla, hogy a tanúsítvány még nem járt le, hogy az éppen aktuális alkalmazásban használható, és hogy a tanúsítvány még nem lett visszahívva és úgy általában ellenőriznünk kell minden szabályozást, kulcshasználati megszorítást, amit a tanúsítvány kiterjesztések előírnak.