Mellékleteink: HUP | Gamekapocs
Keres
React Native, Kotlin, Flutter, Flux, WebAssembly, Java, Android... + app security. Nettó 20 óra fejlesztői tartalom, HWSW mobile!, november 29-30!

PKI -- avagy mit takar a publikus kulcsú infrastruktúra?

Barna József, 2002. június 05. 10:09
Ez a cikk több évvel ezelőtt születetett, ezért előfordulhat, hogy a tartalma már elavult.
Frissebb anyagokat találhatsz a keresőnk segítségével:

Az üzleti szférában az utóbbi időben rendre felbukkan egy első hallásra misztikusnak tűnő kifejezés, a PKI fogalma. Mit is jelent e rövidítés? A PKI, a nyilvános kulcsú infrastruktúra az a rendszer, melynek feladata a digitális aláíráshoz szükséges nyilvános kulcsok létrehozása, kibocsátása, publikálása, menedzselése és visszavonása.

Az alábbi cikket Csabai Csaba, a SaveAs Kft. vezető tanácsadója írta.

Az üzleti szférában az utóbbi időben rendre felbukkan egy első hallásra misztikusnak tűnő kifejezés, a PKI fogalma. Mit is jelent e rövidítés? A PKI egy mozaikszó, mely magyarra "nyilvános kulcsú infrastruktúra"-ként (Public Key Infrastructure) fordítható. A nyilvános kulcsú infrastruktúra az a rendszer, melynek feladata a digitális aláíráshoz szükséges nyilvános kulcsok létrehozása, kibocsátása, publikálása, menedzselése és visszavonása. A nyilvános kulcsú technológiák segítségével biztosítjuk a rendszerben a következő tulajdonságok meglétét: hozzáférés, hitelesítés, letagadhatatlanság, integritás és bizalmasság.

Ez az öt fogalom olyan folyamatokat ír le, melyeket többé-kevésbé bármilyen módon meg lehet oldani. Mégis mi az, ami miatt a PKI ezt az öt fogalmat képes egyesíteni? A PKI egy olyan matematikai és logikai technológiára épül, mely biztosítja azt, hogy egy nyílt hálózatban egyértelműen azonosítani lehessen bárkit. Elmondható, hogy a fenti öt fogalom egységesen garantálható bármilyen nyílt hálózatban, ha feltétel nélkül garantálható bármely fél "személyazonossága".

Fontos tisztázni, hogy mit is jelent egy nyílt hálózaton a személyazonosság garantálása. Ez a folyamat sokkal bonyolultabb annál, mint amilyennek első látásra tűnhet. Az olyan nyílt hálózatok, mint amilyen az internet is, akár több évtized alatt kialakult, folyamatosan fejlődő rendszerek egymásra épülésének tekinthetők, és e rendszerek közel sem a fenti öt fogalom szempontjait figyelembe véve nyerték el végső formájukat. Részben ennek, részben az internetet alapvetően jellemző szabadságnak, szabadosságnak köszönhetően nem nehéz elérni a tökéletes anonimitást a világhálón. Az anonimitás meglétének vagy az identifikáció meghamisíthatóságának ténye azonban egyértelműen kizárja a hozzáférés-kontroll, a hitelesítés, a letagadhatatlanság, az integritás és a bizalmasság meglétét. E szempontok együttese készteti a megoldásszállítókat arra, hogy minél tökéletesebb azonosítási módszereket dolgozzanak ki.

Mindenki számára egyértelmű, hogy a tudásalapú azonosítás nem tökéletes védelem, hiszen azt, amit én tudok, más is tudhatja, és ha még eltekintünk is az emberi esendőségtől, akkor sem garantálható, hogy a kizárólag általam ismert információt más nem tudja lehallgatni. Éppen ezért ha nem tudom biztosítani, hogy csak az ismerjen egy azonosítót, akinek ismernie kell, akkor a letagadhatatlanságot sem tudom garantálni. Mindezek miatt a tudásalapú azonosítások még komoly szabályozás mellett sem elégségesek akkor, ha nyílt hálózatokon keresztül történik az azonosítás.

A következő azonosítási szint az, "amit birtoklok". A birtokomban lévő eszközök, megoldások, melyek kizárólag az én tulajdonomban vannak, egy jóval magasabb biztonsági szintet nyújtó védelmet képeznek. E védelem azonban nyílt hálózatokon keresztül nem feltétlenül nyújt magasabb szintű védelmet, hiszen a "birtokomban" lévő eszköz csak az emberi hibáktól mentesít -- vagy azoktól sem, hiszen láthattunk már bankkártyákat, melyekre rá volt írva alkoholos filccel a pin kód. Még mindig problémát jelenthet a közvetítő csatornák nyíltsága, hiszen hiába létezik egy olyan tökéletes tárolóeszköz, mely biztosítja, hogy én azonosítsam magam, ha az azonosítóm lehallgatható.

Erre a problémára nyújthatnak megoldást a challenge-response elven működő eszközök. Itt az a működési elv, hogy mind szerveroldalon, mind a kliens oldalán létezik egy olyan eszköz, melybe azonos paramétereket tápláltak és azonos matematikai műveleteket programoztak. Ezeknek a paramétereknek együttese lehetőséget ad arra, hogy a szerver által generált "kulcs"-ból a kliens generáljon egy választ. A szerver elvégezve ugyanazokat a számításokat megkapja ugyanazt a végeredményt, ami igazolja, hogy a kliensoldalon biztosan ugyanazt az azonosító eszközt alkalmazzák. Olyan egyéb védelmi megoldások bevonása a challenge-response folyamatba, mint amilyen az idő és a személyi azonosítók, tökéletesen lehetetlenné teszi a hálózati adatforgalmak reprodukálását.

Látható, hogy a challenge-response elven működő azonosítási modellek szinte tökéletes azonosítást tudnak nyújtani, melyet még hálózati lehallgatás esetén sem lehet jogosulatlanul reprodukálni. Ezzel megtettük az első lépést a nyílt hálózaton keresztüli bizalmas adatkommunikációban, hiszen garantálni tudjuk, hogy az a személy, aki a kommunikációs csatorna másik oldalán található, garantáltan az a személy, akinek állítja magát. A PKI által összefogott öt támponttal szembesítve a challenge-response a következőképpen írható le:

  • Hozzáférés garantált -- hiszen tudjuk, ki van a kapcsolat másik végén, így a személyhez jogosultságokat rendelhetünk, melyeket ilyen módon nem lehet megkerülni.
  • Hitelesítés garantált -- hiszen épp ez a lényege a módszernek.
  • Letagadhatatlanság részben garantált -- a challange-response nem feltétlenül ad erre lehetőséget.
  • Integritás nem garantált -- hiszen az autentikációs fázis után már nem kerül további kontroll alá a kapcsolat.
  • Bizalmasság nem garantált -- erre a fenti két pont egyértelmű választ ad.
A cikk több oldalból áll:
Facebook
Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.
React Native, Kotlin, Flutter, Flux, WebAssembly, Java, Android... + app security. November 29-30!