Megvalósíthatósági tanulmány hitelesítő szolgáltató létrehozására

Megvalósíthatósági tanulmány hitelesítő szolgáltató létrehozására

Szerkesztők: Dravecz Tibor Egerszegi Krisztián

Szerzők: Dravecz Tibor Egerszegi Krisztián Erdősi Péter Dr. Kiss Ferenc Marczisovszky Dániel Siklósi Attila Urbanovits György

BME GTK Információ- és Tudásmenedzsment Tanszék Detim Kft. Egerszegi Consulting Kft. Insurance Technology Kft. INTEGRITY Kft. Molág Bt.

© EGERSZEGI CONSULTING – INTEGRITY, 2002

1

Tartalomjegyzék Tartalomjegyzék ...................................................................................................................................... 2 Összefoglaló............................................................................................................................................ 3 Bevezetés ................................................................................................................................................ 5 Európai szolgáltatók ................................................................................................................................ 9 Nemzetközi szolgáltatók........................................................................................................................ 14 Hazai szolgáltatók ................................................................................................................................. 19 A hitelesítés-szolgáltatás....................................................................................................................... 26 Gyakorlati megvalósítási lehetőségek................................................................................................... 32 a.) Computer Associates eTrust PKI ..................................................................................................... 32 b.) Utimaco SafeGuard PKI ................................................................................................................... 39 c.) Egyedi fejlesztés lehetősége............................................................................................................ 45 d.) További termékek............................................................................................................................. 51 Felhasználók, erőforrásigény, bevételek és költségek.......................................................................... 55 Bevételek és kiadások........................................................................................................................... 55 Felelősség és felelősségvállalás ........................................................................................................... 58 Megoldási javaslat ................................................................................................................................. 60 Előnyök és hátrányok az ISzT, tagjai és regisztrátorok részére ........................................................... 61 Jogszabályi kötelmek ............................................................................................................................ 62 Melléklet................................................................................................................................................. 64 Irodalomjegyzék .................................................................................................................................... 65


2

Összefoglaló Az ISZT (Internet Szolgáltatók Tanácsa), olyan tanulmány elkészíttetését határozta el, melynek alapján képet kaphat a PKI (Public Key Infrastructure) rendszerek alkalmazásának pillanatnyi állapotáról, környezetéről és megvalósítási feltételeiről – különös tekintettel a hitelesítés-szolgáltatásnyújtásra. A döntést az indokolja, hogy 2001-ben Magyarországon is megteremtődtek a PKI-rendszerek használatának jogi feltételei, melynek következtében eddig három hitelesítés-szolgáltató kezdte meg működését a nyilvánosság számára, és még több üzemel zárt körben. A PKI-piacon telítettségről azonban távolról sem beszélhetünk, ami maga után vonja további szolgáltatók megjelenésének magas valószínűségét. Emellett szól az is, hogy a tanúsítvány-piac – a teljes körű használat kialakulása után – nyereséggel kecsegtet, a viszonylag magas beruházási költségek ellenére is. Ha 1.000.000,-ra tesszük a potenciális tanúsítvány-birtokosok végső számát, 5.000,- Ft/év tanúsítvány-ár – ami a jelenlegi legalacsonyabb piaci ár körül mozog – mellett is 5 milliárd Ft/év a várható teljes bevétel. Ezzel szemben áll a fokozott biztonságú szolgáltatók kialakításának 20-60 millió forintos becsült beruházási és indulás utáni éves üzemeltetési költsége1, valamint a minősített szolgáltatók minimális 2-300 millió Ft-os becsült beruházási költsége2. Megjegyezzük, hogy ezeket az eddigi tapasztalatok alapján becsült költségeket a szabályozási költségek és az induláskor hiányzó feltételek (gépterem, eszközpark, üzemeltetési személyzet és tapasztalat, működő biztonsági alrendszer) akár 50%-kal is módosíthatják felfelé. A tanulmány a szolgáltató megvalósításához szükséges információkat az alábbi felépítésben teszi közzé: Az elektronikus aláírás és tanúsítvány fejezet bevezet az aláíráshoz kapcsolódó fogalmakba, folyamatokba, és felhasználási lehetőségekbe. Az Európai szolgáltatók részben kitekintünk néhány Európában megvalósított szolgáltatóra, az EU Irányelven keresztül, majd ezt követően a Nemzetközi szolgáltatók kínálatába nyújtunk betekintést. A Hazai szolgáltatók fejezetben a magyar törvényi szabályozás érdemeit és hiányosságait foglaljuk össze, majd ismertetjük a három eddigi hazai szolgáltató kínálatát, árait a Szolgáltatási Szabályzataik és Általános Szerződési Feltételeik tükrében. A Hitelesítés-szolgáltatás fejezet elméleti hátteret nyújt ahhoz, hogy egy szolgáltatás kiépítésekor mire kell figyelni, mit kell implementálni – a vonatkozó nemzetközi szabványok alapján. Ez a fejezet tartalmaz egy javaslatot is az ISZT-szolgáltató felépítésére. A Gyakorlati Megvalósítási Lehetőségek fejezet bemutatja az elméleti modell két különböző szoftvergyártó termékével történő megvalósíthatóságának lehetőségét. A fejezet végén található egy öszszehasonlítás, melynek célja, hogy nagyságrendileg elhelyezze a hitelesítés-szolgáltató kiépítésének szoftveres költségeit. Ebből kiemelve a két megoldással körülbelül elérhető tanúsítvány árak:

Szoftvergyártó Utimaco Safeguard PKI

Tanúsítvány Darabszám

Ár/darab (Ft)

10.000

2.700

100.000

840

1.000.000*

250

* korlátlan tanúsítvány számra is az 1.000.000 darabos ár áll fenn, így e mennyiség felett a tanúsítványok ára tovább csökken.

CA eTrust PKI

10.000

1.100

100.000

450

1.000.000

60

Két termék, ill. megoldás részletes tárgyalása mellett tárgyaljuk a nyílt szoftver alapú egyedi fejlesztést lehetőségét.

1 szoftver licenc és támogatás díjai nélkül 2 egyesek milliárdos költségekkel tartják csak megvalósíthatónak minősített szolgáltató létrehozását


3

Ún. fokozott biztonságú szolgáltató megvalósítását jártuk körül, tárgyaljuk a lehetséges felhasználási és felhasználói kört, a domén regisztrációval összehasonlítva tekintjük át a beruházásokat és üzemeltetési kiadásokat. Végkövetkeztetésként hitelesítő szolgáltató létrehozását javasoljuk franchise rendszerben.


4

Bevezetés Az elektronikus aláírás és tanúsítvány A biztonságos elektronikus kommunikáció az e-világ egyre gyorsuló fejlődésével alapvető igényként fogalmazódik meg a felhasználók részéről. Egy jó és egyre inkább terjedő megoldás az elektronikus aláírás használata, amellyel például a kommunikáló felek ellenőrizni tudják az egymásnak küldött üzenetek eredetét, tartalmát, megbízhatóságát és sértetlenségét. De nem ilyen egyszerű a helyzet, mert az elektronikus aláírás egy gyűjtőfogalom. Minden eljárás elektronikus aláírásnak nevezhető, amely hitelesítés céljára szolgál. Így elektronikus aláírásnak tekinthető – amit igazából nem is kellene annak tekinteni – az elektronikusan beírt név vagy beszkennelt aláírásminta is, de ezek egyáltalán nem nevezhetők biztonságosnak. Biztonságos megoldásnak tekinthetjük a következőkben részletezésre kerülő MAC (Message Authentication Code) kódot és az aszimmetrikus kriptográfián alapuló digitális aláírást. MAC kód A MAC kód a szimmetrikus kriptográfián alapszik, tehát a kommunikáló felek ugyanazzal a kulccsal kódolják és oldják meg az üzeneteiket. Ennél az eljárásnál egy meghatározott algoritmus alapján az üzenet egészéből vagy egy részéből az algoritmussal képzett kódot továbbítanak az üzenettel együtt a hitelesség és sértetlenség bizonyítására. Ez jó megoldás lehet kis létszám esetén, ahol a kódoláshoz és dekódoláshoz alkalmazott kulcsot a felek biztonságosan el tudják egymáshoz juttatni, vagy meg tudnak állapodni kódolási eljárásban a kommunikáció előtt, anélkül, hogy illetéktelen fél ezekhez az információkhoz hozzáférne. A szimmetrikus kriptográfia hátránya, hogy nagy létszám esetén már a kulcsok bizalmas kezelése nem igazán megoldható, valamint a kommunikáló felek egyértelműen nem azonosíthatóak az azonos kulcs miatt. Digitális aláírás A szimmetrikus kriptográfia esetén említett hátrányok kiküszöbölésére az aszimmetrikus kriptográfia adhat jó megoldást. Itt nem szükséges előzetes megállapodás a használt eljárásról vagy az alkalmazott kulcsról, mivel itt az aláírás/titkosítás és az ellenőrzés/megoldás egy ismert közös eljárás segítségével, de két különböző kulcs felhasználásával történik. A két kulcs – nyilvános és privát kulcs – jellemzője, hogy egymásból nem állíthatók elő, mégis alkalmasak arra, hogy a privát kulcs segítségével kódolt üzenetről a nyilvános kulccsal megállapítsuk, hogy az üzenetet a privát kulccsal kódolták. A digitális aláírás készítése és ellenőrzése tulajdonképpen egy tetszőleges adathalmazból képzett digitális ujjlenyomat, vagy másképpen egy adatsorozatból képzett fix hosszúságú egyedi digitális jelsorozat transzformálása egy aszimmetrikus kulcspár segítségével. Egy továbbítandó adatból képzett ujjlenyomatot a küldő a saját privát kulcsával bekulcsol, amit a fogadó egyrészt a küldő nyilvános kulcsával megold, másrészt újra előállít – hiszen az algoritmus ismert –, így ellenőrzi, hogy az átküldött adat a küldés folyamán nem változott-e meg. Aláírás

aláírt szöveg

szöveg

Ellenőrzés

elektronikus csatorna

aláírt szöveg

szöveg

HASH algoritmus

digitális ujjlenyomat 1

Hiteles

=?

HASH algoritmus

digitális ujjlenyomat

egyenlő

Titkosítás

Aláíró privát kulcsa

digitális aláírás


Kérdés: Ez tényleg a küldő kulcsa?

Megoldás


nem egyenlő

Nem hiteles

Aláíró nyilvános kulcsa

1. ábra: Digitális aláírás készítésének és ellenőrzésének folyamata © EGERSZEGI CONSULTING – INTEGRITY, 2002

5

Ez a tulajdonság jól használható az elektronikus kommunikáció során a kommunikáló felek személyének az azonosítására, feltéve, ha igazolható, hogy nyilvános kulcshoz tartozó privát kulcs az üzenet feladójának kizárólagos birtokában van. Erről nem egyszerű meggyőződni, mivel a kommunikálók általában földrajzilag nem egy helyen tartózkodnak, vagyis tulajdonképpen a digitális aláírás önmagában nem jelent teljes megoldást a távollevők közötti kommunikáció esetén az azonosítási problémára. Ehhez szükség van egy megbízható harmadik fél bevonására is. Tanúsítvány alapú hitelesítés A tanúsítvány alapú hitelesítést a PKI (Public Key Infrastructure – Nyílt kulcsú infrastruktúra) rendszerekkel lehet megvalósítani, mely a tanúsítványok segítségével garantálhatja a kommunikáló felek személyazonosságát. Egy PKI-rendszer – a teljesség igénye nélkül – az alábbi komponenseket tartalmazhatja: Aláírási Politika és Szabályzatok − Hitelesítés-szolgáltató − Regisztrációs hatóság − Tanúsítvány elosztás − PKI-megfelelő alkalmazások Fontos látnunk, hogy a digitális aláírás és a tanúsítványok kibocsátása különálló funkcióként jelentkezik a PKI-rendszerben. Lehetséges megvalósítani digitális aláírás-rendszert tanúsítványok nélkül is (pl. PGP), és lehetséges a digitális aláírás-ellenőrző kulcsokat tanúsíttatni is. Nyilván ez utóbbi magasabb megbízhatóságot nyújthat, megfelelő megvalósítás esetén. További elemek is megvalósíthatóak a PKI-rendszerben: −

−

−

időbélyegzés (TS – Timestamping): melyet a digitális aláírás mögé helyezve igazolja, hogy az aláírással ellátott dokumentum (kötelezettségvállalás) nem létezett az időpecsét előtt, és biztosítja, hogy a tanúsítvány lejárta vagy visszavonása után a korábban készített – amúgy hiteles – digitális aláírás továbbra hiteles maradjon. a valós idejű tanúsítvány-állapot szolgáltatás (OCSP): ezzel on-line módon ellenőrizhetjük az aláírás érvényességét (ennek főként azonnali tranzakciók esetében van jelentősége) a tulajdonság-tanúsítás (attributum authority): mellyel eldönthetjük, hogy az adott aláírónak van-e jogosultsága ahhoz, amit aláírt (pl. értékhatárig történő aláírási jog)

Ebben a struktúrában a korábban említett megbízható harmadik fél a digitális aláíráshoz kapcsolódó tanúsítványok előállítását végző hitelesítés-szolgáltató (Certification Authority – CA). A CA tanúsítja, hogy a felhasználó és a felhasználó privát kulcsához tartozó nyilvános kulcs összetartozik, valamint felelősségvállalást követel meg a felhasználótól, hogy a privát kulcsot csak a felhasználó ismeri. Így a tanúsítvány tartalmazza a felhasználó meghatározott adatait és a nyilvános kulcsát. Emellett a CA-nak egy nyilvántartást kell vezetnie az általa kibocsátott tanúsítványokról és azok aktuális állapotáról (érvényességéről, érvényesség megszűnéséről és annak okáról, időpontjáról, stb.), és ezt nyilvános távközlési hálózaton elérhetővé kell tennie az érintettek számára, akik így ellenőrizni tudják kommunikáló partnerük és az üzenetek hitelességét. Aláírás

aláírt szöveg

szöveg

Ellenőrzés

elektronikus csatorna

aláírt szöveg

szöveg

HASH algoritmus


Hiteles

=?

HASH algoritmus

digitális ujjlenyomat

egyenlő

Titkosítás



Certificate Aláíró privát kulcsa

Megoldás


nem egyenlő

Nem hiteles

Certificate Aláíró nyilvános kulcsa

CA

2. ábra: Digitális aláírás készítésének és ellenőrzésének folyamata CA-val


6

A tanúsítványok használatának mikéntjét és feltételeit meg kell határozni a kapcsolódó szabályzatokban, és ezt az érintettekkel el kell fogadtatni ill. a felhasználókat megfelelő képzésben kell részesíteni a tanúsítványok használatával kapcsolatban. Tanúsítvány típusok Tanúsítványokat többféle célra lehet kibocsátani, így megkülönböztethetünk szervezet, szerepkör, személy és eszköz tanúsítványt. •

Szervezet tanúsítvány Egy szervezet vagy annak szervezeti egységének tanúsítására szolgál, mellyel szervezeti szintű aláírást lehet készíteni. Ez egy vállalat esetében megfelel a cégszerű aláírásnak.

•

Szerepkör tanúsítvány Ez a tanúsítvány bizonyítja, hogy egy természetes személy valamely szervezet tagja, és emellett tanúsíthatja a szervezetben betöltött funkcióját is.

•

Személy tanúsítvány Természetes személy azonosítására szolgáló tanúsítvány.

•

Eszköz tanúsítvány Az eszköz tanúsítvány egy bizonyos eszköz – mely lehet például szerver– tanúsítására szolgál.

A tanúsítványok használatánál figyelni kell arra, hogy mikor, milyen típusú tanúsítványt használunk, mert várható, hogy egy személy több tanúsítványtípussal is rendelkezik a szervezetben betöltött helyétől függően. Például egy cégjegyzésre jogosult felhasználó nem mindegy, hogy a személyes tanúsítványát vagy a szervezet tanúsítványát használja egy szerződés hitelesítésénél, mert a személy tanúsítvány ehhez nem elegendő, hanem a cégszerű aláíráshoz hasonlóan a szervezet tanúsítvány szükséges ahhoz, hogy a céget érintő kérdésekben megbízható módon felvállalhasson kötelezettségeket.


7

Felhasználási lehetőségek A PKI rendszerek és így a tanúsítvány alapú hitelesítés felhasználási lehetőségei zárt és nyílt hálózatok esetén: − − − − − − − − − − − −

−

elektronikus kommunikáció, levelezés: biztosítható a kommunikáció hitelessége, sértetlensége és letagadhatatlansága webes felület, szolgáltatás elérése: különféle szolgáltatásokhoz, területekhez történő hozzáférés a felhasználó egyértelmű azonosítása után webes felületen hitelesített alkalmazások futtatása: különféle alkalmazások futtatása előtt meggyőződhet a felhasználó azok eredetéről, hitelességéről (ide tartozik a szerver tanúsítvány is) megbízható szoftver disztribúció: a felhasználó képes a tanúsítvány által hitelesített szoftverek és a nem hitelesített szoftverek megkülönböztetésére, és ez alapján történő felhasználására vagy elvetésére Internet Banking szolgáltatások: banki tranzakciók, lekérdezések végrehajtása biztonságosan elektronikus ügyintézés, adóbevallás, adatszolgáltatási kötelezettség teljesítése: gyorsan, kényelmesen a felhasználó egyértelmű azonosítása mellett interneten keresztüli vásárlás: a vásárlás biztonságának növelése, a felek megbízható azonosításával, ami a bizalom növekedésével járhat beléptető rendszer: intelligens kártya segítségével, PIN-kóddal védett, biometrikus azonosítással a zárt területekre számítógépes bejelentkezés (login): a hagyományos felhasználói név/jelszó páros helyett intelligens kártyája használatával jelentkezik be a munkaállomására a felhasználó hálózati erőforrás-elérés: a kártya birtokosához különböző hálózati erőforrások elérése rendelhető, vagy tiltható (fájl-szerver, nyomtató.) Single Sign On: egyszeri azonosítás után több rendszerhez történő hozzáférés, természetesen mindegyik rendszerhez a megfelelő jogosultságokkal távoli elérés: külső helyszínről vagy otthonról a felhasználó – pl. virtuális magánhálózaton keresztül – hozzáférhet a vállalat hálózatának bizonyos részeihez biztonságos drótnélküli kommunikáció

Megállapíthatjuk tehát, hogy az alkalmazás sokrétűsége is nehezíti a bevezetését, hiszen a PKIrendszert önmagában használni nem lehetséges, minden implementáció előtt meg kell mondani azt is, hogy mire lesz használva a rendszer.


8

Európai szolgáltatók Jogi háttér, az 1999/93 EU Irányelv 1999. december 13-án az Európai Tanács irányelvet fogadott el az elektronikus aláírás szabályozásáról (továbbiakban: irányelv). Az irányelv kötelezi a tagállamokat, hogy legkésőbb 2001. július 19-ig az irányelv rendelkezéseire figyelemmel szabályozzák az elektronikus aláírások használatát, vagy ha korábban már létezett tagállami szabályozás, akkor teremtsék meg az irányelv rendelkezési és a saját szabályozásuk közötti összhangot. Az irányelv rendelkezései alapvetően két csoportra oszthatók. Az első csoportba sorolhatók azok a rendelkezések, amelyek az áruk és szolgáltatások, konkrétan az elektronikus aláírási termékek és a hitelesítés szolgáltatók által nyújtott szolgáltatások Közösségen belüli szabad mozgását, illetőleg a fogyasztók érdekeinek védelmét hivatottak biztosítani. A másik csoportba pedig azok a rendelkezések sorolhatók, amelyek az elektronikus kereskedelemben rejlő lehetőségek kiaknázhatósága érdekében az elektronikus aláírások jogi elismerésére kötelezik a tagállamokat. Fontos megemlíteni a 3. cikk 1. pontjában foglalt tilalmat, amely szerint a tagállamok nem köthetik a hitelesítés szolgáltatás nyújtását előzetes hatósági engedély megszerzéséhez. A rendelkezés célja, hogy a tagállamok ilyen módon ne akadályozhassák a tagállamon belüli vagy a különböző tagállamok hitelesítés szolgáltatói közötti versenyt. Szabályozási elv tehát a hitelesítés szolgáltatás előzetes hatósági engedélyezésének tilalma. A másodikként megemlítendő rendelkezéscsoportba az elektronikus adathitelesítés technológia semlegességét és az elektronikus aláírási termékek interoperabilitásának támogatását kimondó rendelkezések tartoznak (bevezető rész (5) és (8) pontok). E rendelkezések szintén az áruk és szolgáltatások szabad mozgását hivatottak biztosítani. A 3. cikk 3. pontja szerint a tagállamok kötelesek felügyelni azon hitelesítés szolgáltatók tevékenységét, amely hitelesítés szolgáltatók minősített tanúsítványokat bocsátanak ki. A rendelkezés kettős célt szolgál, egyfelől biztosítja a fogyasztók érdekeinek a védelmét, másfelől biztosítékul szolgál arra nézve, hogy a biztonsági követelményeket a hitelesítés-szolgáltatók egyformán teljesítsék. A 3. cikk 2. pontja szerinti önkéntes akkreditáció elve ezzel szemben azt jelenti, hogy bár a tagállamok saját rendszerét alakíthatják ki a hitelesítés-szolgáltatók akkreditálásának, de az akkreditálást nem tehetik a hitelesítés-szolgáltatók számára kötelezővé. Az akkreditálás így elsődlegesen a fogyasztói bizalom megnyerését szolgálhatja. Ugyanakkor megfigyelhető, hogy a német elektronikus aláírási törvény szerint, az akkreditáltság ténye azzal a jogkövetkezménnyel jár, hogy az akkreditált hitelesítés-szolgáltatók esetében vélelmezni kell, hogy a szolgáltatók és az általuk kibocsátott tanúsítványok megfelelnek a német jogszabályokban meghatározott informatikai-biztonsági és egyéb technikai és eljárási követelményeknek. Végül, de nem utolsósorban az irányelv 7. cikke szerint a tagállamok, kötelesek a külföldi hitelesítésszolgáltató által kibocsátott minősített tanúsítványnak ugyanolyan jogi hatályt biztosítani, mint a belföldi által kibocsátott minősített tanúsítványnak, ha: 1. a hitelesítés-szolgáltató – amely kibocsátotta – teljesíti az irányelv követelményeit, és valamely tagállamban önkéntes akkreditáláson esett át; 2. tagállam által kötött két vagy többoldalú szerződés a külföldi hitelesítés-szolgáltatót vagy a tanúsítványt elfogadottnak minősíti, 3. belföldi hitelesítés szolgáltató meghatározott módon felelősséget vállal azért, hogy a külföldi által kibocsátott tanúsítvány megfelel a minősített tanúsítvánnyal szemben támasztott biztonsági követelményeknek. Az irányelv a jogi elismerés szempontjából három aláírás típust különböztet meg. Elektronikus aláírás minden olyan adat, mely egy másikhoz kapcsolódik vagy logikailag társítható vele, és hitelesség igazolására használható. A fejlett elektronikus aláírás definíciója: egyedülálló módon köthető az aláíróhoz; alkalmas az aláíró azonosítására; olyan eszközökkel készült, mely az aláíró egyedüli ellenőrzése alatt áll; valamint a vonatkozó adathoz oly módon kapcsolódik, amellyel minden későbbi változtatás felismerhető. A tagállamoknak egyrészről biztosítaniuk kell azt, hogy a minősített tanúsítvánnyal rendelkező és biztonságos eszközön készült fejlett elektronikus aláírással aláírt dokumentum jogilag egyenértékű legyen a kézírással aláírt irattal, továbbá ez bizonyítékként elfogadható legyen a jogi eljárásokban. Másrészről, – nagyon fontos ezt is szem előtt tartani – az összes elektronikus aláírás © EGERSZEGI CONSULTING – INTEGRITY, 2002

9

vonatkozásában az irányelv arra kötelezi a tagállamokat, hogy bírósági és hatósági eljárásokban a (tetszőleges) elektronikus aláírással aláírt iratok és az elektronikus aláírások bizonyítási eszközként való felhasználását ne tagadják meg pusztán azok elektronikus formája miatt, vagy mert nem rendelkezik minősített tanúsítvánnyal, vagy mert nem akkreditált szolgáltató által kibocsátott minősített tanúsítvánnyal van ellátva az aláírás, továbbá azért se tagadják meg az elfogadást, mert az nem biztonságos eszközön készült. Az irányelv 3. cikkének 7. pontja szerint a tagállamok az elektronikus aláírások közszférán belüli használatát további követelményekhez köthetik. Ezeknek a követelményeknek azonban objektíveknek, arányosnak, és előre megismerhetőknek kell lenniük, továbbá nem vezethetnek a piaci szereplők hátrányos megkülönböztetéséhez. Piaci szereplők az EU-ban EuroPKI 1996/1997-ben zajlott az ICE-TEL projekt (Internetworking Public Key Certification Infrastructure for Europe) a TELematics Application Programme keretén belül, melynek célja az volt, hogy megoldást kínáljon az ipari és akadémiai kutató intézeteknek az Internet-használat biztonsági problémáira. A cél elérése érdekében olyan biztonságos alkalmazásokat fejlesztettek ki, melyek az európai országokon átívelő széles skálájú nyilvános kulcsú tanúsítvány struktúrát használnak a felhasználók hitelesítésére, és rendelkezésre bocsátották az összes szükséges technológiai komponenst is, amivel az egymáshoz csatlakozás könnyen megvalósíthatóvá vált. Ez a projekt alapozta meg az EuroPKI programot, melynek keretében egy non-profit szerveződés felállított egy páneurópai nyilvános kulcsú infrastruktúrát (PKI). Az első lépésként létrejött root-CA kezelése a torinói Security Group kezében van (Politecnico di Torino). A PKI hierarchia a következőképpen épül fel: EuroPKI Top Level CA (Torino) EETIC CA (European Entrapreneurs Telematics Initiatives Committee) − Italian CA − Slovenian CA − Polish CA − Norvegian CA (UNINETT) − British CA (University College of London) − Irish CA (Trinity College of Dublin) − Austrian CA (Institute for Applied Information Processing and Communications) Az olasz és a szlovén CA alá további sub-CA-k csatlakoznak. Árak Árakról nincs tudomásunk, csak azt lehet tudni, hogy non-profit módon végzi az EuroPKI a szolgáltatását. IKS GmbH Jena A cég egy thüringiai regionális Internet-szolgáltató, aki komplex megoldásokat is nyújt ügyfeleinek az információ-menedzsment területén. Kétszintű tanúsítványt bocsát ki: low level security és high level security szinten, személyek és eszközök (számítógépek) számára. A regisztrációs folyamatokat csak személyesen lehet elintézni. Az ügyfelek a kulcspárjaikat a saját lokális rendszerükön generálhatják. A cég felhívja a figyelmét a felhasználóknak, hogy a kulcsgenerálási folyamat során (és végén), a nyilvános kulcs az egyetlen adat, mely elhagyhatja a lokális rendszert – a biztonság sérülése nélkül. Az új tanúsítványokhoz történő hozzáférést a tulajdonos e-mailben kapja meg. Ezen kívül természetesen biztosított a tanúsítványok kereshetősége és a visszavonási eljárások kezelése is.


10

Árak Client certificate Típus

Érvényesség

Ár

Teszt

2 hét

ingyenes

Normál

6 hónap

7 euró

Normál

1 év

10 euró

Megújítás

6 hónap

5 euró

Server and Group certificate Típus

Érvényesség

Ár

Teszt

2 hét

ingyenes

Normál

6 hónap

150 euró

Normál

1 év

300 euró

Megújítás

6 hónap

150 euró

Deutsche Telekom (www.telekom.de) A Deutsche Telekom, mint vezető távközlési és telekommunikációs vállalat, fő tevékenységei mellett foglalkozik teljes PKI megoldás bevezetésével, támogatásával és szerver típusú tanúsítványkiadással is. Hitelesítés szolgáltatói tevékenysége alatt a DT több mint százezer tanúsítványt bocsátott ki. Termékek ServerPass A ServerPass tanúsítvány Internet szerverek és a biztonságos SSL-en keresztül történő kommunikáció hitelesítésére szolgál. A tanúsítvány ára 255 euró/év, de teszt célra 1 hónapig ingyenesen elérhető felelősségvállalás nélkül. A nem teszt célra kiadott tanúsítványhoz tartozó felelősségvállalás mértékéről nincs hivatalos információnk. PKS (Public Key Service) Ez egy komplett PKI megoldás, melyet a DT üzemeltet, és a kibocsátott tanúsítványok után egyegyszeri kibocsátási díjat és egy folyamatos éves díjat számít fel. A CA-t a Deutsche Telekom üzemelteti „Trust Center” néven és egy ún. Master RA (központi regisztrációs hatóság) gyűjti be az igényléseket a kihelyezett RA-któl, amik elvégzik az azonosítási folyamatot is.


11

3. ábra: A Deutsche Telekom PKI megoldásának felépítése

A kibocsátott tanúsítványok fajtája egyedi megegyezés alapján történik, a tanúsítványokat a DT javaslata szerint, saját előállítású chip-kártyán helyezik el. A felelősségvállalás pontos mértékéről nincs hivatalos információnk. A tanúsítványok egyszeri kiállítási díja 53,48 euró chip kártyán, és 10,10 euró mágneslemezen. Ez egy átlagos ár, ettől eltérés egyedi esetekben előfordulhat. A PKS szolgáltatás éves alapdíja 97,44 euró tanúsítványonként. Árak ServerPass Típus

Érvényesség

Ár

Teszt

1 hónap

ingyenes

Normál

1 év

255 euró

Típus

Érvényesség

Ár

Normál

1 év

97,44 euró (+ kiállítás díja)

PKS

Önkéntes akkreditációs szervezetek Európában A PKI-szolgáltatókkal szemben támasztott követelmények két oldalról közelíthetőek meg. Egyrészt fontos ismerni azt, hogy az állam milyen törvényi szabályozást állít fel a szolgáltatók számára, másrészt a piac önszabályozásának érvényesülése is garantálhatja a fogyasztói érdekek védelmét. Nyilvánvalóan ott jöhet létre és erősödhet meg az önkéntes akkreditáció intézménye, ahol az állam kevésbé kíván beavatkozni a piaci szereplők tevékenységeibe. Két ilyen rendszerről teszünk említést az alábbiakban (tScheme, TTP.NL), de megjegyezzük, hogy a működésük még pusztán elméleti jelentőségű, mivel akkreditált tagjaik 2002 februárjának végén még nincsenek. tScheme A tScheme angol kezdeményezés. Létrejöttét az inspirálta, hogy az angol kormányzat felismerte, az elektronikus kereskedelem alapját képező megbízhatóság, bizalmasság, biztonság megvalósításául szolgáló kriptográfiai alkalmazások, PKI-rendszerek használatát szabályozni kell, a széles körben való elterjeszthetőség érdekében. A piac úgy gondolta, hogy képes saját magát szabályozni, és kialakított egy önszabályozó sémát ebben a vonatkozásban. Ez tükröződik is az angol elektronikus kommuniká-


12

cióról szóló törvényben, mely jóváhagyott megbízható harmadikfélről tesz említést (The approval of trusted third parties (Trust Service Providers – TSPs)). A tScheme tagjai tehát lefedik az angol piac összes szegmensét, a kormányzattól a szolgáltatókig, gyártókig és felhasználókig egyaránt. Tagjai: APACS, Barclays, RBG, Viacode, BCC/ChamberSign, TrustWise, Chubb, CSSA, ICL, Vodafone, Microsoft, Consumers’ Association, DMA,e-centre, FEI, IBM, DTI, Cabinet Office, Interclear Működésének alapelvei: − − − − −

kidolgozza a jóváhagyás követelményeit, definiálja az elfogadható technikai és működési eljárásokat, felelős a jóváhagyási folyamatért, a jóváhagyásokat kezeli (kibocsátja, felülvizsgálja, visszavonja), előmozdítja a megbízható szolgáltatások létrejöttét.

Fontos látni azt is, hogy a tScheme gyakorlatilag akkreditációs tevékenységet végez, auditot nem folytat. A jóváhagyás folyamatában a szerepe a követelmények kidolgozására és az általa elfogadott elemző szakértők felsorolására korlátozódik. A szakértő (cég) kidolgozza a folyamodó TSP-re vonatkozó jelentést, melynek birtokában a TSP benyújtja akkreditációs kérelmét a tScheme felé. A tScheme ezt elbírálja – a szükséges policy-k, szabályzatokkal együtt – és dönt az elfogadásról. Ha döntése pozitív, a jóváhagyott szolgáltatásra ki lehet tenni a tScheme emblémát, jelezve annak megfelelőségét, megbízhatóságát. 2002 februárjában a következő cégek várnak folyamodványuk elbírálására: The Royal Bank of Scotland Group, − BT plc, − ViaCode Limited, − Nexus TSP Limited, − ChamberSign. TTP.NL A TTP.NL (Trusted Third Parties) projektet az ECP.NL (Electronic Commerce Platform, Netherlands) hozta létre, 1997-ben. A projekt célja, hogy minősített szolgáltatókra vonatkozó követelményeket fogalmazzon meg, egyrészt az EU Direktívával összhangban, másrészt az ETSI TS 101 456 szabványnak megfelelően. A követelmények, a sémák kibocsátására 2000-ben került sor. A projekt további koordinálására létrejött a Központi Szakértői Tanács (Central Council of Experts, CCE). A CCE feladata a létrejött sémák karbantartása valamint a Tanúsítvány Testület munkájának felügyelete. A Tanúsítvány Testület jogosult auditálni a PKI-folyamatokat, a biztonsági alrendszert és a szervezeti megbízhatóságot. A CCE feladati közé az alábbiak tartoznak: 1. a létező sémák karbantartása (biztonsági, TTP.NL), 2. a Tanúsítvány Testület bevonása a munkába, 3. a TTP.NL márkajelzés kezelése, 4. az Informatikai Biztonság címke menedzselése, 5. európai harmonizáció, 6. részvétel az Önkéntes Akkreditációs Eljárások kidolgozásában, további feladatok: 1. promóció, 2. oktatási és tréning programok kidolgozása, terjesztése, 3. aktív részvétel az ECP.NL munkájában. A TTP.NL akkreditációról nincsen információnk.


13

Nemzetközi szolgáltatók Verisign (www.verisign.com) Az amerikai Verisign cég vezető szolgáltató a digitális hitelesítő szolgáltatások piacán. A hitelesítő szolgáltatások mellett PKI és egyéb biztonsági megoldások értékesítésével, tanácsadásával, oktatásával is foglalkozik. A tanúsítványok háromféle szintűek lehetnek, Class 1, Class 2 és Class 3. Ez a szint az ellenőrzési, azonosítási folyamatot jellemzi; a leggyengébb a Class 1, ami csak email cím ellenőrzést végez, ezt követi a Class 2, ami meghatározott iratokkal történő igazolást is igényel, melyeket független forrásból ellenőriz, és a legerősebb a Class 3, ami az ellenőrzés során a személyes jelenlétet is megköveteli. Termékek Personal ID (személy tanúsítvány) A személyes kommunikáció bizalmasságának és hitelességének biztosítására szolgáló tanúsítvány. Az ellenőrzés során az email címet vizsgálják, és lényegében ez a tanúsítvány a felhasználó és az email cím összetartozását igazolja. Az ára 14,95 USD/év és 1000 USD felelősségvállalást tartalmaz, de lehetőség van egy 60 napos ingyenes tesztperiódus igénybevételére, ám ekkor a Verisign nem vállal semmilyen felelősséget. Az ellenőrzési folyamat Class 1 szintű. Server ID (szerver tanúsítvány) Szerver és weboldalak összetartozásának tanúsítására szolgál. Az ára az SSL titkosítás erősségétől függően változik. 40 bit erősség esetén 895 USD/év, 128 bit erősség esetén pedig 1395 USD/év a tanúsítvány ára. A tanúsítványokhoz 100000 USD-s felelősségvállalás tartozik. Az ellenőrzési folyamat Class 3 szintű. Code Signing Digital ID Szoftverfejlesztőknek kínált tanúsítványfajta, mellyel az elkészített szoftver, alkalmazás vagy kód hitelesíthető, így az ügyfél, vagy felhasználó megbizonyosodhat, hogy megbízható forrásból származó szoftvert, alkalmazást vagy kódot kap. A tanúsítvány a hozzáadott plusz szolgáltatások függvényében 400 USD vagy 695 USD lehet egy évre. A felelősségvállalás mértéke a hitelesíteni kívánt kódoktól, alkalmazásoktól függően változó. Az ellenőrzési folyamat Class 1 szintű. Az ellenőrzési folyamatról, illetőleg, hogy melyik szintű ellenőrzés pontosan mit követel meg a felhasználótól, nem rendelkezünk hivatalos információval. Árak Personal ID Típus

Érvényesség

Ár

Teszt

60 nap

ingyenes

Normál

1 év

14,95 USD

Típus

Érvényesség

Ár

40 bit SSL

1 év

895 USD

128 bit SSL

1 év

1395 USD

Típus

Érvényesség

Ár

Normál

1 év

400 USD

Bővített

1 év

695 USD

Server ID

Code Signing ID

Globalsign (www.globalsign.com) Nemzetközi hitelesítés-szolgáltató, főleg Európára koncentrál. A tanúsítványkiadás mellett széleskörű PKI rendszerekhez kapcsolódó szolgáltatásokat is kínál ügyfeleinek. © EGERSZEGI CONSULTING – INTEGRITY, 2002

14

Termékek PersonalSign 3 szintű személyazonosság igazolására szolgáló tanúsítvány. PersonalSign Demo: ez egy ingyenes, egy hónapi érvényes csupán teszt célokra szolgáló tanúsítvány, mindenféle garanciavállalás nélkül. Az igénylés során csak email cím ellenőrzés történik. PersonalSign 2: ez egy, 1 évig érvényes tanúsítvány, mely igénylése során a személyazonosság megállapítása az email cím ellenőrzésével ill. egy személyazonosság igazoló irat (útlevél/jogosítvány) aláírt másolatának a céghez való eljuttatásával történik. A tanúsítvány ára 16 euró/év és 2480 euró felelősségvállalást tartalmaz. PersonalSign 3 Pro: ez a legnagyobb garanciát nyújtó tanúsítvány, mely a PersonalSign 2 tanúsítvány követelményein túl személyes megjelenést is igényel a Globalsign regisztrációs hatóságainál. Ilyen regisztrációs hatóság jelenleg 17 országban van, így ezt a tanúsítványt csak ezekben az országokban lehet igényelni. A tanúsítvány ára 50 euró/év és 37500 eurós felelősségvállalást tartalmaz. ServerSign Szerver és a hozzá tartozó domén név hitelességének, valamint 56 bites SSL-en megvalósuló biztonságos kapcsolat igazolására szolgál, így lehetővé teszi a biztonságos kommunikációt az üzleti partnerek és ügyfelek, felhasználók között. Az igénylés során ellenőrzik, hogy kinek a tulajdonában van a domén név, és vizsgálják a tulajdonos igazoló iratait, cég esetén a céges papírokat. A tanúsítvány ára 175 euró/év és 37500 eurós felelősségvállalást tartalmaz. ServerSign for WAP A ServerSign-hoz hasonló elven működik csak WAP szerver hitelesítésére szolgál és a WAP szerver és a WAP-os eszköz közti biztonságos kommunikációt teszi lehetővé. A tanúsítvány áráról és az ellenőrzés módszeréről nincs hivatalos információ, valószínűleg a ServerSignéval megegyezően történik. A tanúsítvány 37.500 eurós felelősségvállalást tartalmaz. HyperSign A ServerSign-nal megegyező tanúsítvány, csak ez már 128 bites SSL kapcsolatot igazol, éves díja 225 euró, a felelősségvállalás mértéke változatlanul 37.500 euró. ObjectSign Szoftverfejlesztőknek és terjesztőknek kialakított tanúsítvány, mely az ügyfél felé igazolja a szoftver, alkalmazás vagy kód eredetét. Az igénylés során ellenőrzik az igénylő email címét, és vizsgálják hivatalos iratait. A tanúsítvány ára 175 euró/év, 37.500 eurós felelősségvállalást tartalmaz. Árak PersonalSign Típus

Érvényesség

Ár

Demo

1 hónap

ingyenes

PersonalSign 2

1 év

16 euró

PersonalSign 3 Pro

1 év

50 euró

Típus

Érvényesség

Ár

Normál

1 év

175 euró

Típus

Érvényesség

Ár

Normál

n/a

n/a

ServerSign

ServerSign for WAP


15

HyperSign Típus

Érvényesség

Ár

Normál

1 év

225 euró

Típus

Érvényesség

Ár

Normál

1 év

175 euró

ObjectSign

Entrust (www.entrust.com) A kanadai székhelyű Entrust főleg PKI és biztonsági termékek, megoldások értékesítésére helyezi a hangsúlyt, de ezek mellett foglalkozik tanácsadással, és a következőkben részletezett hitelesítés szolgáltatásokkal is. Termékek WEB Server Certificates Ez a tanúsítvány azonosítja a weboldalt és engedélyezi az SSL-en keresztül történő biztonságos kommunikációt. A böngésző programok több mint 99%-a támogatja az Entrust root CA-t. A tanúsítvány 1 évre 149 USD, 2 évre 275 USD. WAP Server Certificates A tanúsítvány azonosítja a WAP szervert, és engedélyezi a biztonságos kommunikációt a WAP képes eszköz ill. a WAP szerver között. Az ára 1 évre 749 USD, 2 évre 1.295 USD, de lehetőség van egy 21 napig érvényes ingyenes teszt tanúsítvány kipróbálására. A tanúsítványok kibocsátásához szükséges ellenőrzési folyamatról, valamint a felelősségvállalás mértékéről nincs hivatalos információnk. Árak WEB Server Certificate Típus

Érvényesség

Ár

Normál

1 év

149 USD

Normál

2 év

275 USD

WAP Server Certificates Típus

Érvényesség

Ár

Normál

1 év

749 USD

Normál

2 év

1.295 USD

Thawte Corporation (www.thawte.com) A cég központja a dél-afrikai Cape Town-ban van (Fokváros), itt folyik a technikai support, a kutatásfejlesztés és a marketing stratégia kidolgozása is. Az amerikai iroda csupán az amerikai tanúsítványokkal kapcsolatos tevékenységeket végzi. A cégnek az alábbi országokban van képviselete, mely ellátja egyben az adott országokban a tanúsítványok értékesítését is: Ausztrália, Brazília, Kanada, Costa Rica, Kína, Horvátország, Észtország, Franciaország, Németország, Hong Kong, Izrael, Japán, Portugália, Puerto Rico, Oroszország, Szingapúr, Szlovénia, Spanyolország, Svédország és Anglia. A cég egy olyan világméretű digitális tanúsítvány-megoldás szállító, amely az Internet használat biztonságosabbá tételéhez biztosít eszközöket. Ezen belül a Thawte megbízható harmadik félként tanúsítvány-szolgáltatóként is működik az Interneten. Tanúsítványokat cégeknek és magánszemélyeknek egyaránt szolgáltat, az ügyfelek on-line módon is azonosíthatják magukat.


16

Termékek − SuperCerts: az összes kommunikációt 128-bites erős titkosítással támogatja meg. Korábban az USA-ból exportált böngészők csak a 40-bites titkosítást ajánlották fel. Ez a tanúsítvány lehetővé teszi a non-USA böngészők számára, hogy 128-bites erős titkosítást használjanak, egy saját site hozzáférésekor. Ehhez szükséges, hogy a site látogatói minimum IE 5.01 vagy Netscape 4.7 böngészőt használjanak. − Wildcard Certs: A "wildcard" tanúsítvány egy olyan domén névhez tartozó tanúsítvány, mely megengedi, hogy a domén névben wildcard-karakterek ("*") szerepeljenek (pl. *.domain.com. Ha egy kliens a tanúsítvány alapján ellenőrizni kívánja a host-nevet, ez a tanúsítvány érvényes lesz mind a www.domain.com, a www1.domain.com, mind pedig a www2.domain.com host-nevekre is. Tehát kiválóan használható sub-domain-ek egyetlen tanúsítvánnyal történő levédésére. − SSL-szerver Certs: A web-szerverhez történő 40-, 56-, és 128-bites SSL-hozzáférést támogatja meg tanúsítvánnyal. A kulcsok hosszát dinamikusan választja meg, a szerver és a kliens tulajdonságai alapján. − Developer Certs: A fejlesztői tanúsítványok használatával lehetővé válik a megírt programkód aláírása a nyilvános hálózaton történő továbbítás előtt, így biztosítható az útközbeni változások észlelése. − Personal Cert: Ez a tanúsítvány a hagyományos elektronikus levelezés aláírásához, illetve annak ellenőrzéséhez használható. Árak SuperCert Új ár

Megújítás

1 évre: 300 USD

1 évre: 300 USD

2 évre: 600 USD

2 évre: 600 USD

WildcardCert Új ár

Megújítás

egyéni elbírálás

egyéni elbírálás

SSL-szerver certs Új ár

Megújítás

1 évre: 125 USD

1 évre: 100 USD

2 évre: 225 USD

2 évre: 200 USD

Developer certs Új ár

Megújítás

1 évre: 200 USD

1 évre: 100 USD

Personal certs Új ár

Megújítás

n/a

n/a

Digital Signature Trust (www.digsigtrust.com) A Digital Signature Trust az USA-ban egy vezető hitelesítés-szolgáltató cég. A digitális azonosítás és tanúsítványkiadás mellett végeznek ezekhez kapcsolódó szolgáltatási, tanácsadási tevékenységet is. Termékek TrustID Personal Certificate Magáncélú személyazonosításra szolgáló tanúsítvány, mely egy évre 24 USD-be kerül, ezért 1. 000 USD felelősségvállalást tartalmaz.


17

TrustID Business Certificate Üzleti célú személyazonosításra szolgáló tanúsítvány, mely tartalmazza a felhasználó szervezetét és a felhasználó szervezetben betöltött szerepkörét is. Az ellenőrzés során vizsgálják a szervezet valódiságát, így megerősítést kérnek a szervezettől, hogy valóban igényli-e e szolgáltatást a felhasználó részére. Éves díja 175 USD, az előzőhöz hasonlóan ez is 1.000 USD felelősségvállalást tartalmaz. TrustID Server Certificate SSL csatornán keresztül kommunikáló webszerverek azonosítására kibocsátott tanúsítvány. Az ellenőrzés során vizsgálják a szervezet valódiságát, hogy a szervezet tulajdonában van-e az adott doménnév, így megerősítést kérnek a szervezettől, hogy valóban igényli-e ezt a szolgáltatást. Éves díja 175 USD, 250.000 USD felelősségvállalást tartalmaz. Az ellenőrzés folyamata során – mindhárom tanúsítványfajtánál – a vizsgált adatok érvényességét és valódiságát hiteles és független forrásból (pl. állami nyilvántartás) származó információkkal vetik öszsze, a tanúsítványok kibocsátására csak az egyezőség esetén kerül sor. Árak TrustID Personal Certificate Típus

Érvényesség

Ár

Normál

1 év

24 USD

TrustID Business Certificate Típus

Érvényesség

Ár

Normál

1 év

175 USD

TrustID Server Certificate Típus

Érvényesség

Ár

Normál

1 év

175 USD


18

Hazai szolgáltatók Törvényi szabályozás állása, hiányosságai Az elektronikus aláírásról szóló 2001. évi XXXV. törvény szeptember 1-jén lépett hatályba. A végrehajtáshoz ez azonban önmagában kevés, alkalmazását rendeletek segítik, készítik elő. A törvény az aláírás használatához számos rendelet megalkotásához ad felhatalmazást. Ennek értelmében az állami ellenőrzést megvalósító Hírközlési Főfelügyelet (a továbbiakban Főfelügyelet) – e törvénnyel kapcsolatos – feladatkörét és hatáskörét a 151/2001 Kormányrendelet szabályozta, valamint kormányrendelet fogja majd várhatóan leírni a központi közigazgatási szervek és helyi önkormányzati szervek elektronikus aláírással, az azokat hitelesítő szolgáltatókkal kapcsolatos követelményeket is. A Miniszterelnöki Hivatalt (MeH) vezető miniszter a 16/2001 rendeletben szabályozta az elektronikus aláírással kapcsolatos szolgáltatások és szolgáltatókra vonatkozó részletes követelményeket, a 15/2001 rendeletben pedig rendelkezett az elektronikus aláírási termékek tanúsítását végző szervezetekről, kijelölési szabályaikról. A MeH minisztere állapította meg a 20/2001. MeHVM rendeletben a Főfelügyeletnek e törvény alapján járó igazgatási szolgáltatási díjak mértékét is, a pénzügyminiszterrel egyetértésben, valamint irányelvet fog kibocsátani a 16-os rendelet záró rendelkezése alapján. Ebben olyan szabványokon és műszaki előírásokon nyugvó alapelvek lesznek megfogalmazva, hogy ha ezeknek egy szolgáltató eleget tesz, akkor a Főfelügyelet köteles a vonatkozó követelményeknek megfelelő szolgáltatónak tekinteni – ezek tekintetében legalábbis. Kérdés, vajon a felügyeleti szerv számára elégséges lesz-e az, ha egy szolgáltató a leírt követelményeknek megfelelően működve kéri a minősítését, bár nyilvánvalóan nem lehet cél az automatikus minősítés megadása sem. Néhány gondolat az aláírások jogkövetkezményeiről. Amennyiben az aláírás minősített, azt bármely olyan bírósági, vagy államigazgatási eljárásban el kell fogadni, amelyeknél ezt a megfelelő rendelet lehetővé teszi. Ez egyben azt is jelenti, hogy a rendeletek nélkül nem használhatjuk az elektronikus aláírást az állammal folytatott ügyintézéseinkben. Ezen kívül a fokozott biztonságú elektronikus aláírással ellátott elektronikus irat kielégíti az adott jogviszonyban az írásba foglalás követelményét – a meghatározott kivételeken kívül. Mindezeken túl bármely elektronikus aláírással ellátott irat, dokumentum kötelezettség-vállalásának elfogadását, bizonyítási eszközként történő alkalmazását sem lehet megtagadni kizárólag amiatt, hogy az aláírás csak elektronikus formában létezik. Más kérdés persze, hogy ezen túlmenően még milyen követelményeket kell kielégítenie az elektronikus dokumentumnak ahhoz, hogy a nyugtázásától eljuthassunk a teljes körű elfogadásáig. A miniszterek – a törvény záró rendelkezései szerint – rendeletekkel fogják szabályozni azoknak a jogviszonyoknak a körét, ahol mód van kizárólag elektronikus iratok, dokumentumok használatára, valamint megállapítják az ezekkel történő ügyintézés sajátos szabályait is. Ugyanezt meg kell tenniük majd a helyi önkormányzatoknak is, hogy rendeletben szabályozzák azokat az eljárásokat, ahol mód lesz elektronikus iratokkal intézni az ügyeket. A felhatalmazási rész ugyan kizárólagos elektronikus ügyintézésről beszél, de a 3§. 7-es pontja kimondja, hogy jogszabály nem teheti az elektronikus aláírás használatát kötelezővé. Megállapítható tehát, hogy a közeljövő, számos értelmezési feladatot is tartogat a jogalkotók számára, a szükséges rendeletek kodifikálásán túl. Elektronikus aláírási termékek tanúsítását végző szervezetek nyilvántartásba vételéről nincsen még hír. Nyilvános szolgáltatást hazánkban csak nyilvántartott és felügyelt szolgáltató nyújthat. A nyilvántartás megindult, ez azt is jelenti egyben, hogy a hatósági eljárás módszere kialakult, és elvégezhetővé vált. A törvény azonban olyan fogalmat, mint "fokozott biztonságú hitelesítés-szolgáltató" nem ismer. Ha részletesen áttanulmányozzuk a jogszabályokat, arra a következtetésre jutunk, hogy meg kell különböztetni az elektronikus aláírások és a tanúsítványok, sőt a szolgáltatók osztályozási kategóriáit is, mert nem ugyanazok. A törvény alapján háromtípusú elektronikus aláírás létezhet (normál, fokozott biztonságú, minősített), de csak kéttípusú tanúsítvány lehetséges: minősített és nem minősített. A 16/2001-es Kormányrendelet vezeti be a "fokozott biztonságú szolgáltató" fogalmát is implicit módon. Fokozott biztonságú tanúsítványról azonban egyik jogszabály sem tesz említést, csak fokozott biztonságú szolgáltatásról. Megállapítható az is, hogy a fokozott biztonságú szolgáltatónak a kibocsátott (nem minősített) tanúsítványait – úgy tűnik – nem kell fokozott biztonságú elektronikus aláírással hitelesítenie. Továbbá a fokozott biztonságú elektronikus aláírás kritériumai között nem szerepel az, hogy tanúsítvánnyal is rendelkeznie kell. Következésképpen tehát abból, hogy a szolgáltató fokozott biztonságú, nem következik automatikusan az, hogy az általa kibocsátott tanúsítványok fokozott biztonságú elektronikus aláíró adatokhoz (privát kulcs) kapcsolódnak. © EGERSZEGI CONSULTING – INTEGRITY, 2002

19

A különböző szolgáltatók közötti különbséget a tanulmány készítésének idején tehát nem az általuk kibocsátott tanúsítvány típusa határozza meg, hiszen eddig Magyarországon csak „nem minősített” címkéjű tanúsítvány kibocsátására van lehetőség. Mi jelenti akkor a különbséget a különböző tanúsítványok között? A választ a regisztrációs folyamatokban kell keresnünk. Különböző szintűnek értékelünk egy tanúsítványt akkor, ha az személyhez vagy eszközhöz kötődik, illetve a személyhez kötődő tanúsítványnál az is fontos, hogy milyen mértékben, mennyire erősen győződött meg a regisztrációs hatóság a személy identitásáról (e-mail cím, személyi igazolvány, tanúk, közjegyzői igazolás). A magyarországi szolgáltatók kínálatát a tanúsítvány-típusaik, és a hozzájuk kapcsolódó regisztrációs folyamatok mentén járjuk körbe. NetLock Informatikai és Hálózatbiztonsági Korlátolt Felelősségű Társaság Korát tekintve a Netlock a legrégebbi motoros ezen a pályán, hiszen már több mint öt éve, elsőként kezdte meg tanúsítványok szolgáltatását Magyarországon. Szolgáltatását informatikai biztonsági szempontokból megbízható módon és helyen nyújtja. A HÍF 2001. október 20-tól nyilvánította "fokozott biztonságú szolgáltatóvá" – azaz vette lajstromba. A Netlock a törvény által felsorolt mindhárom szolgáltatás végzésére (tanúsítvány-kiadás, időbélyegzés és privát kulcs elhelyezés) bejegyeztette magát. Ez tehát azt jelenti, hogy regisztrációs és hitelesítő funkciót végez, amely közben négy hitelesítési osztályban ad ki tanúsítványokat – de valójában csak három az, ami tényleges kötelezettség-vállalás igazolására használható közülük. A szolgáltatások nyújtásának módjaiban a cég rugalmas, támogatja a csak tanúsítványt kérőket is, de lehetővé teszi, hogy nála virtuális szolgáltatót hozzon létre más cég saját használatra, melynek csupán a rendelkezésre állását biztosítja, az adminisztrációs feladatok a megrendelő cégre áthárítódnak. Valamint a láncolt CA-tanúsítvány lehetővé teszi bármely vállalati CA bekapcsolását a Netlock által felülhitelesítettek körébe. Teszt osztályú tanúsítványok A teszt tanúsítvány a hálózatbiztonsági szolgáltatások tesztelési céljaira kiadott tanúsítvány. A teszt szinten a hitelesítés szolgáltató nem végez, illetőleg nem vesz igénybe entitás-azonosító szolgáltatásokat. A teszt tanúsítvány csak a megadott elektronikus cím létezését biztosítja az érintett felek számára, semmi többet. Érvényességi időtartama 1 hónap, igénylése on-line módon történik. Felelősséget erre a Netlock nem vállal. "C" osztályú tanúsítványok A "C" osztályú tanúsítvány olyan személyeknek, szervezeteknek vagy szervereknek kiadott tanúsítvány, amely alanyát korlátozott, részben emberi beavatkozással történt ellenőrzési lépéseken keresztül azonosította a hitelesítés szolgáltató. Használata elektronikus levelezéshez, kisebb kockázatú tranzakciókhoz, on-line szolgáltatások igénybevételéhez, szoftver forrásának ellenőrzéséhez ajánlja a kft. Felelősséget 50.000,- Ft-ig vállal ezen típusú tanúsítványokra. A C-osztályú tanúsítványok kiadását az alábbiak ellenőrzése előzi meg: Ellenőrzés Személyek azonosításához

Szervezetek azonosításához Szerverek azonosításához Nyilvános kulcs ellenőrzése Jogosultság ellenőrzéséhez Funkció ellenőrzéséhez


C osztály “B” osztályban regisztrált 2 tanú Postacím, telefonszám létezése Személyi igazolvány másolata Adóigazolvány bemutatása Közüzemi számlák másolata Nyilvános cégnyilvántartási adatok Postacím, telefonszám létezése Saját domén név Kérelem elektronikus aláírása Igénylő felhatalmazása Nyilatkozat a funkció ellátásáról

20

"B" osztályú tanúsítványok A "B" osztályú tanúsítvány olyan személyeknek, szervezeteknek vagy szervereknek kiadott tanúsítvány, amely alanyát szigorúbb ellenőrzési lépések során azonosította a hitelesítés szolgáltató. Használata elektronikus levelezéshez, közepes kockázatú tranzakciókhoz, on-line szolgáltatások igénybevételéhez, szoftver forrásának ellenőrzéséhez ajánlja a cég. Felelősséget 500.000,-Ft-ig vállal ezen típusú tanúsítványokra. A B-osztályú tanúsítványok kiadását az alábbiak ellenőrzése előzi meg: Ellenőrzés Személyek azonosításához

Szervezetek azonosításához Szerverek azonosításához Nyilvános kulcs ellenőrzése Jogosultság ellenőrzéséhez Funkció ellenőrzéséhez

B osztály Személyi igazolvány, útlevél bemutatása Postai adategyeztető lap Adóigazolvány bemutatása Közüzemi számlák Cégbíróság, APEH okmányok Kamarai adategyeztető lap Saját domén név Kérelem elektronikus aláírása Igénylő felhatalmazása Funkció írásos megerősítése

"A" osztályú tanúsítványok Az "A" osztályú tanúsítvány olyan személyeknek, szervezeteknek vagy szervereknek kiadott tanúsítvány, amely alanyát szigorú ellenőrzési lépések során azonosította a hitelesítés szolgáltató. Használata nagy értékű tranzakcióknál, pénzügyi utasítások és információk ellenőrzésénél, szerződéskötéseknél ajánlott a Netlock szerint. Felelősséget 5.000.000.- Ft-ig vállal ezen típusú tanúsítványokra. Az A-osztályú tanúsítványok kiadását az alábbiak ellenőrzése előzi meg: Ellenőrzés

A osztály

Személyek azonosításához Szervezetek azonosításához Szerverek azonosításához Nyilvános kulcs ellenőrzése

Közjegyzői nyilatkozat Közjegyzői nyilatkozat Saját domén név Kérelem elektronikus aláírása

Jogosultság ellenőrzéséhez Funkció ellenőrzéséhez

Közjegyzői nyilatkozat Közjegyzői nyilatkozat

Tanúsítványtípusok Az "A", "B" és "C" osztályokban a következő tanúsítványtípusok kiadását végzi a Netlock: Személyes aláíró és titkosító tanúsítványok Személyes tanúsítványokat természetes személy igényelhet saját nevében. Meghatalmazásos aláíró és titkosító tanúsítványok Meghatalmazásos (névjegykártyás) tanúsítványokat természetes személy igényelhet egy adott szervezet tagjaként. A szervezet – többek között – lehet gazdálkodó szervezet, hivatal, önkormányzat, egyesület, alapítvány. A tanúsítványban szerepel a személy szervezetben betöltött funkciója is. Szervezet aláíró és titkosító tanúsítványok Szervezet tanúsítványokat szervezet vagy annak szervezeti egysége igényelhet saját nevében. A szervezet – többek között – lehet gazdálkodó szervezet, hivatal, önkormányzat, egyesület, alapítvány.


21

Szerver tanúsítvány Szerver tanúsítványt Internet címmel (ún. host névvel) rendelkező, szervert üzemeltető természetes személy vagy szervezet igényelhet. WAP Gateway tanúsítvány WAP Gateway tanúsítványt WAP Gateway eszközt üzemeltető természetes személy vagy szervezet igényelhet. VPN tanúsítvány VPN tanúsítványt VPN eszközt üzemeltető természetes személy vagy szervezet igényelhet. Láncolt Hitelesítés Szolgáltató tanúsítvány Egy adott szervezet számára, a szervezet alkalmazottai számára történő tanúsítvány-kibocsátást lehetővé tevő tanúsítvány. Expressz (Class C) Személyes Névjegykártyás Névjegykártyás csomag (5 db) Szervezeti SSL-Szerver Láncolt CA

400,- Ft/hó 800,- Ft/hó 2.400,- Ft/hó 800,- Ft/hó 1.600,- Ft/hó Egyedi elbírálás

Üzleti (Class B) 650,- Ft/hó 1.300,- Ft/hó 3.900,- Ft/hó 1.300,- Ft/hó 2.600,- Ft/hó Egyedi elbírálás

Közjegyzői (Class A) 750,- Ft/hó 1.500,- Ft/hó 4.500,- Ft/hó 1.500,- Ft/hó 3.000,- Ft/hó Egyedi elbírálás

Magyar Távközlési Részvénytársaság A MATÁV Rt. hosszasan készülődött a hitelesítés-szolgáltatási tevékenysége megkezdésére, amíg eldöntötte, hogy anyavállalata, a Deutsche Telekom eszközeit és know-how-ját adaptálja a magyarországi viszonyokra. A szolgáltatás értékesítését e-Szignó néven kezdte meg, a HiF 2001. december 21-i regisztrációját követően. A törvényben meghatározott szolgáltatások közül csak kettőt nyújt, időbélyegzéssel nem foglalkozik – a tanulmány írásának pillanatában. Szolgáltatásának lényege, hogy a MATÁV, mint szolgáltató virtuális CA-kat (VCA) definiál és bocsát rendelkezésre a saját eszközein minden ügyfelének, akik ún. Közvetítőként biztosítják egy webfelületen keresztül a szolgáltatás tartalommal való feltöltését, az Egyedi Ügyfélszerződésben leírt igényeik alapján elkészített tanúsítvány-típusok használatával. Ennek megfelelően a regisztrációs szervezet is kétszintű, mivel helyi viszonylatban a Local Registration Authority-t (LRA) képviselő operátorok betanítását és tanúsítvánnyal történő ellátását a MATÁV Master Registration Authority-jének (MRA) munkatársai végzik. Tanúsítvány-típusokat külön a MATÁV nem határoz meg az MRA, CA, LRA és BatchRA profilokon kívül, ellenben megadja a Szolgáltatási Szabályzatában az általa kezelhető legbővebb tanúsítvány mezőit, és kijelenti, hogy a kibocsátott tanúsítvány-típusokat a tanúsítvány-mezők adatai alapján lehet azonosítani. A kibocsátott tanúsítványok típusa Közvetítőnként kerül meghatározásra és azt, az Egyedi Ügyfélszerződés, illetve a Tanúsítvány Szabályzat rögzíti. A tanúsítvány-típusok vonatkozásában a Tanúsítvány Szabályzatban minden esetben szabályozásra kerülnek az alábbiak: i) az, hogy a Tanúsítvány az Aláíró saját nevében történő elektronikus aláírásra, vagy más személy (szervezet) nevében történő elektronikus aláírásra jogosít fel. ii) a kulcshasználat lehetőségei – pl. elektronikus aláírás, ügyfél azonosítás, titkosítás, stb. iii) a Tanúsítványok felhasználásának korlátai és egyben a Tanúsítványok használatához kapcsolódó jogkövetkezmények. iv) Az Aláíró és az Aláírás Ellenőrző feleket terhelő kötelezettségek.


22

Díjak A MATÁV díjairól explicit információ nem lelhető fel. A Szolgáltatási Szabályzatban leírtak szerint a szolgáltatás érvényes díjait és fizetési feltételeit a Közvetítővel kötött Egyedi Ügyfélszerződés rögzíti. Sejteni azért lehet, hogy a MATÁV üzletpolitikája a nagy cégeknek kedvez, azaz a nagy tételben tanúsítványt rendelők bizonyosan számíthatnak jelentős kedvezményekre, így a darabonkénti ár nem mond semmit ebben az esetben. Azt lehet csupán tudni, hogy a szolgáltatás díjazása során alkalmazott díjelemek az alábbiak közül kerülnek ki. I. VCA létrehozásához, megvalósításához és üzemeltetéséhez kapcsolódó díjtételek 1. egyszeri felállítási, testre szabási díj: egyszeri díjtétel, mely magában foglalja az Egyedi Ügyfélszerződésben meghatározott paraméterekkel rendelkező VCA felállítását, valamint 2 fő LRA-operátor kártyáját (a kapcsolódó kulcspárral és Tanúsítvánnyal), olvasóját és oktatását). 2. havi üzemeltetési díj: havonta számlázandó díjtétel, mely magában foglalja az Egyedi Ügyfélszerződésben meghatározott paraméterekkel rendelkező VCA üzemeltetését. 3. Konzultáció díja: Opcionális díjtétel, mely tartalmazza az Egyedi Ügyfélszerződésben rögzített, Közvetítő által igényelt konzultációs tevékenység díját, a szolgáltatás létesítése és üzemeltetése során. II. Kártyás Tanúsítványokhoz kapcsolódó díjtételek 1. chipkártya (+ telepítő) díja: egyszeri, kártyánként fizetendő díjtétel, mely akkor kerül számlázásra, ha a Tanúsítvány illetve a magánkulcs tárolásához a Közvetítő chipkártyát rendelt meg. 2. kártya perszonalizálás díja: egyszeri, kártyánként fizetendő díjtétel, mely magában foglalja a kulcsok és a Tanúsítvány elhelyezését a kártyán, valamint a kártya egyoldali indent nyomással történő perszonalizálását, így akkor kerül számlázásra, ha a Tanúsítvány illetve a magánkulcs tárolásához a Közvetítő kártyát rendelt meg. A perszonalizációs rendszer szállítója a Cardnet Rt, auditálója a HunGuard Kft. III. Tanúsítványokhoz tartozó díjtételek 1. Tanúsítványok éves díja: Tanúsítványonként számlázott éves díjtétel. A MATÁV az egész éves díjat a Tanúsítvány kiadásakor számlázza egy összegben. A Tanúsítvány éves díja magában foglalja a Tanúsítvány korlátlan használatának lehetőségét az érvényességi időn belül. Tranzakciós díj a Tanúsítvány használatához kapcsolódóan nem kerül felszámításra. A Tanúsítvány visszavonása esetén az éves díjból nincs visszatérítés. A Tanúsítvány érvényességi időtartama – az Egyedi Ügyfélszerződés alapján – egy évnél rövidebb időszak is lehet. Az ennek megfelelő árakat az Egyedi Ügyfélszerződés tartalmazza. 2. Tanúsítványok regisztrációs díja: opcionális egyszeri, Tanúsítványonként számlázandó díjtétel, melyet akkor számláz a MATÁV, ha az Aláírók Tanúsítvány kérelembe rögzített adatainak ellenőrzését, az adategyeztetési tevékenységet és a Tanúsítvány kérelmek jóváhagyását (LRA operátori funkciók) az Egyedi Ügyfélszerződésben rögzített feltételekkel a Szolgáltató végzi. 3. Egyéb hitelesítés-szolgáltatáshoz kapcsolódó díjak: egyéb egyszeri, vagy havi díjtételek, melyek akkor számlázandók, ha az Egyedi Ügyfélszerződésben rögzített módon a Szolgáltató a Közvetítő részére más szolgáltatásokat is biztosít. (pl. Közvetítő munkatársainak oktatása, vagy oktatási kurzusok Aláíróknak, végfelhasználók részére biztosított ügyfélszolgálati tevékenység havidíja, stb.) GIRO Elszámolásforgalmi Részvénytársaság "A GIRO Elszámolásforgalmi Rt. küldetése a magyar fizetési rendszerben a hitelintézeti elszámolóház feladatainak hatékony ellátása, tevékenységének folyamatos fejlesztése úgy, hogy a szolgáltatást igénybe vevő pénzintézetek magas szinten felelhessenek meg ügyfeleik elvárásainak. Ennek érdekében megbízható és stabil, de ugyanakkor megújulásra képes csapatot épít. Új termékeket és szolgáltatásokat fejleszt ki és nyújt, amelyekre a bankközösség minden körülmények között számíthat." Ez a hitvallás alapvetően determinálja a GIRO potenciális ügyfélkörét, mely szerint GIRO Rt., a GIRO Rt.vel szerződést kötött Pénzügyi Intézmények, a Magyar Nemzeti Bank, a Magyar Államkincstár és a KELER Rt. lesz a GIRO által kibocsátott tanúsítványok alkalmazó közössége. A tanúsítvány megszerzéséhez a bankoknál vezetett számlák tulajdonosainak a saját bankjuknál kell érdeklődniük. A GIRO a hitelesítési szolgáltatását a pénzintézetek – mint Regisztrációs Szervezetek – bevonásával nyújtja. A tanúsítvány-igénylést tehát a honos bank fogja befogadni, és elbírálni. Azonnal felmerül az a kérdés is, hogyha több banknál is szeretnénk elektronikusan intézni bankügyeinket, vajon mindannyiszor újra © EGERSZEGI CONSULTING – INTEGRITY, 2002

23

kell-e regisztráltatni magunkat, vagy ha egyszer beléptünk a GIRO-s tanúsítvánnyal rendelkező ügyfelek táborába, szabadon mozoghatunk-e a továbbiakban a bankok között? Elképzelhető, hogy a bankok közösen megállapodnak abban, hogy a másik pénzintézet által végzett ügyfél-regisztrációt elfogadják mindenkire nézve érvényesnek – nyilván bizonyos korlátozások mellett-, így alakulna ki az, hogy milyen feltételek mellett lehetnének a pénzintézetek az ügyfelek számára "átjárhatóak". Emellett szól egyrészt az, hogy a GIRO non-profit módon nyújtja a szolgáltatását, másrészt az is, hogy a GIRO Hitelesítés-Szolgáltató működési rendjét, Szolgáltatási Szabályzatát a GIRO, tehát a tagintézményei alakítják ki, így gyakorlatilag saját maguk számára készítik el az egész PKI-rendszert. Ez nagymértékben valószínűsíti azt, hogy a GIRO szolgáltatása a hitel- és pénzintézetek többségének meg fog felelni, így nem fognak a piacon más szolgáltatókat keresni. A GIRO fokozott biztonságúnak nevezett, szolgáltatói és teszt osztályú tanúsítványokat fog kibocsátani. A szolgáltatói és teszt osztályú tanúsítványok kibocsátását és kezelését a GIRO nem nyilvános szolgáltatás keretében tervezi végezni. A Szolgáltatási Szabályzatban a fokozott osztályúnak nevezett tanúsítványok kezelését találhatjuk meg. A fokozott biztonságú tanúsítvány olyan személyeknek, szervezeteknek vagy eszközöknek kiadott tanúsítvány, amely alanyát szigorú ellenőrzési lépések során azonosította a szolgáltató. Használatát pénzügyi tranzakcióknál, utasításoknál és információk eredetiségének és sértetlenségének ellenőrzésénél ajánlja a GIRO. A felelősségvállalás mértékéről információ a tanúsítványban is fel lesz tüntetve. A Szolgáltatási Szabályzat tanúsítvány-profil részében azonban erre nem történik utalás. Az Általános Szerződési Feltételek rendelkeznek a felelősségvállalás mértékéről az alábbi módon: A GIRO azon bizonyított vagyoni károkért, amelyek felelősségi körében keletkeztek, kártérítést fizet a következő káreseményenkénti felső határokkal: a) A fokozott biztonságú, a magánszemély részére kiadott személyi tanúsítványok esetében 100.000,Forint/tanúsítvány, de összesen legfeljebb 50.000.000,-Ft; b) a fokozott biztonságú, szervezet kiadott tanúsítványok esetében 250.000,-Forint/tanúsítvány, de összesen legfeljebb 100.000.000,-Ft; c) a fokozott biztonságú, eszköztanúsítványok esetében 250.000,- Forint/tanúsítvány, de összesen legfeljebb 50.000.000,-Ft. A felelősség felvállalhatóságához a GIRO szerint hozzátartozik az is, hogy nem fogad el más által generált privát kulcsot, azt minden esetben saját maga szeretné generálni újonnan. Díjak Az ügyfelek által fizetendő díjakat a Szolgáltatási Szabályzat szerint – az Általános Szerződési Feltételeknek megfelelően – a Regisztrációs Szervezet által közzétett díjszabás tartalmazza. Ilyen szervezettel azonban a GIRO Rt.-nek még nem volt a tanulmány írásának idején érvényes szolgáltatási szerződése. A díjszabást az teheti érdekessé, hogy a Szolgáltató nyereségéből a tulajdonos bankok részesednek, így egyrészről érdekeltek a relatíve magas díjtételekben, másrészről a díjat a banki ügyfelek fogják megfizetni, így az alacsony díjak potenciális ügyfeleket – vagyis más oldalról jelentkező bevételt – jelenthetnek a kiélezett pénzpiaci versenyben. A hazai szolgáltatók jövője – vízió Úgy tűnik, hogy a 2002. év eleji piaci hitelesítés-szolgáltatók békésen megférnek egymás mellett. A Netlock a kisebb ügyfeleket is kiszolgálja, a MATÁV a nagyobb vállalatokra, önkormányzatokra szakosodott első körben, míg a GIRO a bankokon keresztül toborozza kimondottan pénzügyi területre a tanúsítványainak potenciális felhasználóit. A "több szolgáltató – több tanúsítvány" elvnek van létjogosultsága, hiszen egyetlen kulcspárral nem lehetséges minden alkalmazási terület igényeit maximális mértékben kiszolgálni. Emiatt várhatóan több tanúsítvánnyal is fog rendelkezni egy-egy személy, több digitális identitása lesz a cyber-térben. Ez – ha a plasztik-kártyákra gondolunk – nem lesz kezelhetetlen, hiszen nem ritka dolog, hogy ismerősünk tárcájában 4-5 műanyag lapocska (bankkártya, klubkártya, pontkártya…) húzódik meg. A nagy kérdés az lesz, hogy egy intelligens kártyán mennyi kulcspár lesz elhelyezhető, azaz multifunkciós kártyákat a különböző applikációk hogyan és mennyire fognak támogatni.


24

Nagyon izgalmas kérdés lesz az első minősített szolgáltató kiléte3. 2002 februárjának végén a helyzet az, hogy nincsenek még kellőképpen kidolgozva a minősített szolgáltatóra vonatkozó részletes követelmények. Egyik fontos kérdés lesz a közeljövőben, hogy külföldön elhelyezett eszközökön, lehetséges-e minősített szolgáltatást nyújtani? Másik nagyon fontos kérdésnek tűnik az is, hogy nemzetközi minősítő szervezetek által kiadott igazolás szükséges-e a CA szoftverek hazai minősítettségéhez? Amennyiben mindkét válasz nemleges, a piac két szereplője (MATÁV, Netlock) előtt meghosszabbodik az út a "minősített szolgáltató" titulus elnyeréséig. A kétszemélyes versenyfutás nyertese a MATÁV lehet, ha az Európai Unió is úgy gondolja, ill. a Deutsche Telekom minősített szolgáltatást nyújt Európában. A GIRO sem biztos, hogy fel lesz arra készülve, hogy a banki ügyintézésen túlmenő jogosítványokkal rendelkező tanúsítványok kibocsátását végezze – nemcsak banki ügyfelek számára. Ha az előbb feltett kérdésekre adott válasz igenlő, akkor sem egyértelmű a helyzet. A bizonytalanság a tanúsítvány használatában van. Lehetséges-e egy minősített tanúsítvánnyal rendelkező kulcspárt sok funkcióra felhasználni? A tanúsítvány Certificate Usage mezője megadja erre a választ. Minimum kettő kell, hiszen a Nonrepudiation funkciójú tanúsítványt csak aláírásra lehet használni. A DigitalSignature és KeyCipherment használatú tanúsítványhoz tartozó kulcspár már lehet azonos. Felmerül továbbá – az előzőektől némileg függetlenül – az a kérdés is, hogy ha a mostani szolgáltatók késlekednek a minősítési eljárás követelményeinek megfelelni, akkor az állammal folytatott elektronikus ügyintézéseinkhez ki fogja a minősített tanúsítványt szolgáltatni?

3

Kormányzati szándék van saját kormányzati minősített szolgáltató létrehozására (mely leginkább a Magyar Posta berkeiben várható), közel milliárd forintos beruházással.


25

A hitelesítés-szolgáltatás Egy CA felépítése A 2001. évi XXXV. törvény szerint a hitelesítés-szolgáltató három tevékenységet végezhet: hitelesítésszolgáltatást, időbélyegzést, valamint aláírás-létrehozó eszközön az aláírás-létrehozó adat elhelyezését. A hitelesítés-szolgáltatás tevékenységen belül a szolgáltató azonosítja az igénylő személyét, tanúsítványt bocsát ki, nyilvántartásokat vezet, fogadja a tanúsítványokkal kapcsolatos változások adatait, valamint nyilvánosságra hozza a tanúsítványhoz tartozó szabályzatokat, az aláírás-ellenőrző adatokat és a tanúsítvány aktuális állapotára (különös tekintettel a visszavonására) vonatkozó információkat. Ennek megfelelően egy tanúsítvány-szolgáltató a gyakorlatban igen összetett rendszer. A lehetséges elemeit az alábbi táblázat tartalmazza: Megnevezés

Rövidítés

Certificate Authority

CA

root Certificate Authority Bridge CA Registration Authority (Local, Master)

root CA Bridge CA RA

TimeStamping Authority Attribute Authority Certificate Repositories Certificate Directory Certification Revocation List Attribute Certificate Revocation List

TSA AA CR CD CRL ARL

On-line Certificate Status Provider Certificate Policy Certificate Practice Statement Arbitrator

OCSP CP CPS –

Funkció felhasználói kulcsok hitelességének tanúsítása, tanúsítvány-készítés CA kulcsok hitelességének tanúsítása CA-k kereszt-tanúsítása, tanúsítvány-konverzió tanúsítvány-kérelmek rögzítése, Local RA-k szakmai támogatása hiteles időbélyegzés tulajdonság tanúsítás Tanúsítvány-raktár, szabályzatok tárolása felhasználói tanúsítványok tárolása visszavont felhasználói tanúsítványok tárolása visszavont felhasználói tulajdonságok tanúsítványainak tárolása valós idejű tanúsítvány-állapot szolgáltató tanúsítvány kibocsátási irányelvek tanúsítvány kezelési eljárások döntőbíró a felhasználó és a CA között

1. Táblázat

A funkcionális elemek jobb megértése érdekében képzeljük el a következő analógiát (természetesen, mint minden analógia, ez sem fedi tökéletesen a valóságot): Tekintsük 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 érkezteti a kérelmet. Ez a hatóság a Registration Authority, vagy regisztráló hatóság. Ennek alapján a regisztráló hatóság lesz az, aki összekapcsolja a kérelmező fizikai személyét az ily módon létrejött digitális entitással. A regisztráló hatóság 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 (Certificate Authority). A hatóság tanúsítja az útlevél kiállításával, 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 szigorúan ellenőrzötten kerüljenek rá a műanyag utolsó oldalra, (fénykép, aláírás, különböző személyes adatok), s azt olyan módon kell megoldani, hogy azt más ne tudja megvalósítani (Az elkészült tanúsítvány digitális aláírása a CA privát kulcsával – CA Key tárolása). Az útlevél-kérelem feladását, vagy elvételét – mindkét fél által elfogadottan – dátumozza a Posta, vagy a fogadóiroda (TimeStamping Authority). Más esetekben az iktatókönyvben szereplő dátum a hivatalosan elfogadott. Ha az útlevelünkben szerepel olyan jellemző, attribútum, 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 (Attribute Authority). 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 © EGERSZEGI CONSULTING – INTEGRITY, 2002

26

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. Maradva a példánál, a Certificate Policy (CP) megfeleltethető annak a törvénynek, ami alapján magyar állampolgár beadhatja az útlevélkérő lapját a hatósághoz. A Certificate Practice Statement (CPS) 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. Emiatt a CPS-t ebből következendően csak az implementálás után lehet elkészíteni. Ha ezt a szállító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. Amennyiben az útlevélkérelmet a hatóság elutasítja, mert szerinte nekem nem jár, szerintem pedig jár, kihez lehet fordulni a vitás kérdés eldöntéséért? A PKI rendszerben az Arbitrátor, a döntőbíró 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 PKI nem egy öncélú, különálló rendszerként jelenik meg, hanem a PKI elemeit integrálni kell a meglévő információs rendszerbe. 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ára, titkosítására. A kommunikáció során használt kulcspá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. A tanúsítvány tartalmazza a felhasználó nyilvános kulcsát és több személyes adatát is. A tanúsítványokat a Certificate Repository-ban (CR – tanúsítvány raktárakban) kell tárolni. 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ány raktár, amely állandóan elérhetővé teszi a tanúsítványokat. A raktár több részre osztható fel. A szabályzatokat is itt szokták nyilvánosságra hozni. A tanúsítvány raktár felhasználói tanúsítványokat tartalmazó részét Certificate Directorynak (CD) nevezhetjük, míg a már visszavont tanúsítványokat a Certificate Revocation List (CRL) tárolja. Amennyiben valamilyen tulajdonságot is hozzákapcsoltunk a tanúsítványhoz, és azokat szeretnénk visszavonni, akkor a visszavont tanúsítványok listáját az Attribute Certificate Revocation List (ARL) tartalmazhatja. Általában a tulajdonságok rövid életűek, ezért a tulajdonságokat igazoló tanúsítványok ún. short-live (rövid élettartamú) certificate-ek, ami azt jelenti, hogy a tulajdonság érvényességi idejét a tanúsítvány kibocsátásának pillanatában, 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 lehetséges, de nem feltétlenül szükséges a gyakorlatban. Felmerül a kérdés, hogy a CA gyakorlati megvalósításánál melyik funkcionális egységet hova lehetséges helyileg telepíteni? Elképzelhető, hogy az összes funkció egy helyen valósul meg, de az is lehet, hogy bizonyos funkciókat le kell választani. Ha 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 lehetséges off-line módon is. Megjegyezzük, hogy ha az információ-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 a digitális aláírás gyakorlata, ott a tanúsítványok kibocsátása előtt a felhasználói kulcspárok generálását és 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 szolgáltatás. Gyakorlatilag a szolgáltató az aláírás-létrehozó adatot két módon teheti rá az eszközre. Egyrészt, ha saját maga generálja és ezek után juttatja célba az ügyfélnek, másrészt, ha az ügyfél generálja a tanúsítvány-szolgá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, mely egyben a tároló eszköz is lesz (On Board Key Generation). Az európai kvázi-szabványok szerint (CEN draft) egy tanúsítvány-szolgáltatónak (Certificate Service Provider) vannak kötelező és opcionális szolgáltatásai, amelyeket az alábbi táblázat foglal össze. Kötelező szolgáltatás Regisztráció szolgáltatás Tanúsítvány generálás


Opcionális szolgáltatás Időbélyegzés szolgáltatás Aláírás létrehozó eszköz szolgáltatása

27

Kötelező szolgáltatás

Opcionális szolgáltatás

Tanúsítvány szétosztás Visszavonás kezelése Visszavonási információk szolgáltatása

Az alábbi ábra tartalmazza az időbélyegzés-szolgáltatás lényegi elemeit:

Időbélyegzés-szolgáltató elemei TSA Hash algoritmus Elfogadott idõforrás

Aláíró kulcs

Idõparaméter elõûllítása

Tanúsítvány (nem kötelezõ) Idõbélyeg létrehozása

Visszavonási lista (nem kötelezõ)

Sorozatszám Kérés ellenõrzése

Dátum Szabályzat

Felhasználói interface

Idõbélyeg kérés


Idõbélyeg válasz

28

A tanúsítvány-szolgáltatás logikai felépítését és elemeinek kötelező mivoltát az alábbi ábra jól kivehetően tárja elénk.

Kötelezõ elemek

Opcionális elemek

Tanúsítvány generálás

Regisztráció

Tanúsítványok elterjesztése

Visszavonás kezelése

Visszavonási állapot

Aláírás létrehozó eszközök kiadása

Idõbélyegzés

Megbízható külsõ szolgáltatások interface

A hitelesítés-szolgáltató elemei

Aláírási folyamat

Aláírt tranzakció

Válaszok

Kérések

Válaszok

Kérések

Ügyfélkapcsolati interface

Aláírás ellenõrzési folyamat

Az ISZT szolgáltató javasolt felépítése Az ISZT szolgáltató funkcionalitása két részre bontható: 1. ISZT és tagjainak tanúsítvánnyal való ellátása 2. A tagok ügyfélkörének tanúsítványokkal történő ellátása. A szolgáltatást javasolt lépcsőzetesen kiterjeszteni, hiszen egyrészt az elektronikus aláírás használatának támogatásához meg kell(ene) szerezni az ehhez szükséges gyakorlati tapasztalatot, ellenkező esetben könnyen előfordulhat, hogy a szolgáltató munkatársa kér eligazítást abban, amit neki kellene lebonyolítania; másrészt az elektronikus aláírás használatának a tanúsítvány-szolgáltató megléte csak az egyik szükséges, de távolról sem elégséges feltétele. A további feltételek közül megemlíthetjük a felhasználói környezet megteremtését, a tanúsítvány-tár problematikáját (hiteles és aktuális adatokkal való feltöltése), a szabályozási kérdéskört, hiszen az elektronikus aláírás használatának bevezetését és az informatikai biztonságot nem lehet különválasztani, minimum együtt javasolt kezelni. Ellenkező esetben az elektronikus aláírás használata nem fogja beváltani a hozzá fűzött reményeket, hiszen egyenszilárdságú informatikai biztonsági alrendszer kiépítése nélkül biztonsági események tömege várható, melyek azonnal aláássák a szolgáltatás egyik alapvető pillérét: a bizalmat. Vajon ki bízna meg egy olyan cégvezetői (elektronikus) aláírásban, amelyet a cég bármelyik dolgozója elő tud állítani? A biztonság megteremtése, szintjének emelése tehát alapvető fontosságú a megbízható elektronikus aláírás szolgáltatások kiépítésekor (is). A szolgáltatás célcsoportja az Internet-használók köre, akik valamelyik Internet-szolgáltatónál fizettek el Internet-használatra. Valószínűleg ez az a kör, amelyik a leggyorsabban beletanul az elektronikus aláírás használatába – ha még nem használja valamilyen formában (pl. PGP). A használat körébe beletartozik az aláíráson kívül a titkosítás is, a szolgáltatónak erre is megoldást kell nyújtania. A titkosításnál a legfőbb gondot az jelenti, ha a kulcs elvész, megsemmisül, így a titkosított állományokat a továbbiakban nem lehetséges elolvasni. Ennek a feloldására szolgál a kulcs-menedzsment rendszer, melyből a felhasználó – jogos igényének bizonyítása után – visszakaphatja titkosító kulcs(párj)át.


29

Az itt felvázolt szolgáltatáshoz az alábbi strukturális felépítés javasolt: − − − − −

CA (tanúsítványok kibocsátása, benne HSM – Hardver Security Module), RA (regisztráció, mind központilag [ISZT és/vagy tagjai számára], mind lokálisan [ISZT tagok és/vagy ügyfelek számára] – MRA, LRA), Certification Repository (szabályzatok, tanúsítványok hozzáférésének biztosítása; általában az X.500-on alapuló névtár), aláíró adat aláíró eszközön történő elhelyezése (ez a gyakorlatban intelligens kártyakibocsátást és perszonalizációt jelent), Key Management System (a titkosító kulcsok kezelése, visszaállításának lehetősége).

Biztonság A felépítendő szolgáltató zárt körben is szolgáltathat, de piacra is léphet, mint nyilvános szolgáltató. A kettő közötti különbséget gyakorlatilag a HíF államigazgatási eljárás keretében lefolytatott nyilvántartásba vétele jelenti, amely nem támaszt biztonsági követelményeket a pályázó szolgáltatók számára, csupán azt vizsgálja, hogy a szolgáltató megfelel-e e jogszabályi előírásokban lefektetett elvárásoknak. A valóságban ez azt jelenti, hogy a szabályzatai elkészültek-e, valamint tartalmuk nem ellentétes az elektronikus aláírás törvénnyel. Más követelményt az állam nem támaszt, csak a minősített szolgáltatókkal szemben. A megvalósítás lehetséges fázisai Ha PKI rendszer megvalósításában gondolkodunk, arra is figyelmet kell fordítani, hogy azt egy meglévő külvilági és belső biztonsági környezetbe kell integrálni. A technikai megvalósítás nem csak annyiból áll, hogy a hardver/szoftver megvásárlásra kerül, majd telepítik. A gyakorlati példák (pl. Dunaferr) azt mutatják, hogy az implementáció legrövidebb része a technikai megvalósítás – néhány hét, a teljes körű használat időigényes részét a szabályozás és az oktatás teszi ki – több hónap. Nemzetközi módszertanok alapján hat fázisra lehet felosztani a technikai megvalósítást: 1. 2. 3. 4. 5. 6.

Pályáztatás Szerződéskötés Fogadókészség biztosítása Átadás/Átvétel Alkalmazás kiterjesztése Üzemeltetés

A fázisok magukért beszélnek. A fogadókészség biztosítása jelenti azt, amit a megrendelő részéről kell megtenni azért, hogy a rendszert hatékonyan lehessen használni. Az alkalmazás kiterjesztése azt jelenti, hogy a PKI-rendszert úgy javasolt megvalósítani, hogy a felhasználói kör kis lépésekben legyen bővítve, kiterjesztve, mivel így a beüzemelés erőforrás-igénye és az esetlegesen felmerülő problémák megoldása tervezhetővé válik, és elkerülhető lesz a nagy tömegű dömping-munka. Nyilván mindezt akkor lehet ütemezni, ha egy ismert populációról van szó (pl. ISZT tagok munkatársai). Kritikus pontok −

Referencia

Egy pályáztatásnál nagyon fontos, hogy legyen a pályázónak referenciája. Ez nagyon nehéz kitétel, hiszen még annyira új a terület, hogy nehéz olyan céget találni Magyarországon, aki több (nagyobb) referenciával rendelkezik – illetve ezek közismertek, így nagyobb súllyal eshetnek latba a külföldi referenciák is. −

Forráskód

Pályáztatásnál a forráskódra vonatkozó követelmény nagyon nehezen megvalósítható kitétel. Elvárás az, hogy a szállító a forráskódot helyezze letétbe, vagy biztosítson erre hajlandóságot. Miért van erre szükség? Azért, mert ha valami oknál fogva a szállító jogutód nélkül – vagy a termék támogatása megszűnik, akkor attól kezdve – forráskód hiányában – a termék karbantartása gyakorlati korlátokba ütközik. Ezt azért nem szeretik a gyártók, mert akkor a felhasználó elvileg szabad kezet kap a forráskód felett, és megismerheti, és ezt követően sérülhet a forráskód bizalmassága. Meg lehet ezt oldani úgy is, hogy harmadik személynél kelljen letétbe helyezni a kódot (pl. közjegyzőnél), és a felbontásáról, vagy a vevőhöz való eljuttatásáról külön szabályzatban, eljárásban kell megállapodni, hogy mikor © EGERSZEGI CONSULTING – INTEGRITY, 2002

30

lehetséges hozzáférni a letétbe helyezett forráskódhoz. Megjegyezzük, hogy a piacvesztéstől való félelem még a Microsoftot is arra kényszerítette, hogy hozza nyilvánosságra potenciális megrendelői számára a termékeinek forráskódját – vagy bizonyos részeit. −

Acceptance testing

Fontos lehet, hogy mielőtt az egész rendszert üzembe állítjuk, megvalósítjuk, egy elfogadási tesztet kössünk ki a szállító részéről. Vizsgáljuk meg megrendelés előtt, hogy valóban úgy működik-e, valóban azt teszi-e a rendszer, amit mi szeretnénk, és csak utána kelljen megvásárolni. −

Fenyegetés-mentességi nyilatkozat

Szerződésben nagyon fontos kitétel, hogy szerepeljen benne az, hogy a gyártó tudomása szerint az általa elkészített, szállított szoftver nem tartalmaz a vevő információ-rendszerére nézve fenyegetést, trójai falovat, back door-t, vírust – vagy bármilyen rosszindulatú programkódot. −

Fogadókészség biztosítása

Több szabályzat elkészítésére van szükség a CPN, CPS-en túl, amit integrálni kell a meglévő biztonsági, üzemeltetési szabályzatokba. A saját tanúsító központ fizikai elhelyezéséről is rendelkezni kell. Elképzelhető az is, hogy az elektronikus aláírás használatba vétele előtt új biztonsági elemeket, védelmi intézkedéseket kell megvalósítani, magasabb biztonsági követelményeket kell kielégíteni, valamint a leendő felhasználókat képezni kell mindezek használatára. −

Átadás/Átvétel

Nagyon fontos kritérium, hogy az átadás-átvétel történjen meg a tesztidőszak végén. Az átadásátvételkor a fejlesztői jogosultságokat minden tekintetben vissza kell vonni. −

Alkalmazás kiterjesztése

Az alkalmazás fokozatos kiterjesztésének (a felhasználói kör bővítésének) legyen meghatározott ütemterve, mikor, milyen ütemben, hány végpontot kívánunk csatlakoztatni. Ez azért is fontos, mert a csatlakoztatni kívánt felhasználói végpont biztonsági környezetéről a telepítés előtt meg kell győződni. Ha egy PKI rendszerben egy végpont nem biztonságos, vagyis lehet manipulálni valamilyen módon, akkor az egész rendszerre hatással lehet, hiszen mind az aláírás készítési, mind az aláírás ellenőrzési folyamatok a felhasználói környezetben zajlanak, távol a szolgáltatótól. −

Üzemeltetés

Egy PKI-rendszert nemcsak felépíteni, hanem üzemeltetni is kell, a maximálisan elvárható biztonsági színvonalon. Ennek érdekében ki kell alakítani az üzemeltetési szerepköröket – a "need to know, need to do" elv alapján, el kell végezni az üzemeltetési rend, üzemeltetési szabályzatok elkészítését is, hiszen ezek hiányában az üzemeltetés is kritikus lehet.


31

Gyakorlati megvalósítási lehetőségek Computer Associates eTrust PKI A Computer Associates az IT világ vezető, független szoftvergyártó cége, így mindig a legújabb megoldásokkal áll partnerei rendelkezésére. Több biztonsági megoldáscsomagot dolgozott ki, melyek közül most az eTrust Access Solution Kit részét képző eTrust PKI szoftvert és a kapcsolódó megoldásokat mutatjuk be. A Computer Associatesnek több hazai partnere van: Debis – Kidolgozott szolgáltatáscsomagjaik vannak, melyek között azonban nem szerepel PKI; Kersoft – nagyon sokféle szoftvert árulnak több gyártótól, de inkább forgalmazóról van szó; KFKI Isys – ismereteink szerint nem foglalkozik PKI-val4; Minor – Smart kártyás megoldásuk van, de a CA eTrust PKI bevezetésével kapcsolatban nincs információnk; VT-Soft – A CA eTrust PKI-jét támogatják, érdemi információkat kaptunk tőlük, ill. árbecslésünket tájékoztató ajánlatukra alapoztuk. eTrust PKI Jelen ismertetés a szoftver 1.0-ás verzióját mutatja be, de 2002 áprilisára várható a 2.0-ás verzió megjelenése, mely mind funkcionalitásában és menedzselhetőségében, mind a támogatott rendszerek, alkalmazások számában is elődjének továbbfejlesztett változata. Az eTrust PKI tartalmazza egy tanúsítvány directory (eTrust Directory) és egy on-line modul (eTrust OCSPro) alapváltozatát is, de a magas színtű használathoz érdemes e termékek teljes verzióját bevezetni. Lehetőség van még az eTrust Web Access Control segítségével teljesen web alapra helyezni a tanúsítvány igénylő és ezzel kapcsolatos folyamatokat, így megoldott a teljes platform függetlenség is. Az eTrust SSO (Single Sign On) termékkel történő integrálás pedig jó megoldást adhat a tanúsítvány alapú integrált jogosultságmenedzsment kialakítására. A termék jellemzője a nagyon széleskörű kompatibilitás, és integráció lehetősége más gyártók termékeivel. Támogatott termékek − −

Computer Associates termékek, Szabványokkal kompatibilis más gyártók termékei (pl: Baltimore, Entrust stb.).

Támogatott operációs rendszerek Microsoft Windows NT 4, Microsoft Windows 2000, Microsoft Windows XP Támogatott alkalmazások Az eTrust PKI-t úgy tervezték, hogy az általa kibocsátott tanúsítványok és tanúsítvány visszavonási listák (CLR) kompatibilisek legyenek a leggyakrabban használt alkalmazásokkal – pl. Internet Explorer, Netscape, Outlook, Exchange – és más gyártók szabványos termékeivel is. Az esetlegesen nem támogatott alkalmazások felé is lehetőség van az egyedi igényeknek megfelelően interface-k kialakítására, vagy akár egy új PKI-képes alkalmazás fejlesztésére a beépített Software Development Kit segítségével. Támogatott szabványok PKIX, − − − −

PKCS, OCSP, LDAP, X.500,

4 a KFKI-csoporton belül PKI-vel az Icon és az LNX foglalkozik, de ők RSA Keon, Baltimore, iPlanet CMS termékekkel


32

− − − −

X.509, DER, PEM, SSL.

Támogatott biztonsági hardver eszközök Szabványos intelligens kártyák (pl. Gemplus, Rainbow, ActivCard, Datakey, Eracom, nCipher), − USB Tokens, − Luna CA3 HSM (hardware security modul) a CA kulcsmenedzsmentjéhez, − Egyéb szabványos hardver eszközök. Az eTrust PKI elemei CA (Certification Authority) − A CA adja ki a tanúsítványokat és a CRL-t az RA igényei alapján. − RA (Registration Authority) − Az RA szerver továbbítja a bejövő tanúsítvány kérelmeket a CA felé, valamint a kiállított tanúsítványokat és a tanúsítvány visszavonási listát (CRL) a végfelhasználó, illetve a directory felé. − RAC (Registration Authority Client) − Ez egy grafikus felhasználói felület, mely közvetlenül az RA-val kommunikál, és ezen keresztül tud az RAC operátor tanúsítványt kiadni, illetve visszavonni. − Directory (Directory Services) − A tanúsítványok és a tanúsítvány visszavonási lista (CRL) tárolására szolgál. Ennek része a tanúsítvány adatbázis. − DB (Certificate Database) − Tanúsítvány adatbázis. − OCSPro (Online Certification Status Protocol Responser) − A valós idejű tanúsítvány ellenőrzést lehet a segítségével megvalósítani. − EE (End Entity): végfelhasználó

4. ábra: eTrust PKI felépítése és működése

További elemek, melyek nem szerepelnek az ábrán: − Administration Client Központi adminisztrátori felület. − Software Development Kit PKI-képes alkalmazások fejlesztésére, PKI-re nem képes alkalmazások PKI-képessé való fejlesztésére, és alkalmazások testre szabására szolgál.


33

Az eTrust PKI működése A folyamat egy tanúsítvány igényléssel kezdődik. Ez az igény érkezhet automatikusan webes felületről vagy RAC operátoron keresztül az RA-ba. Ha szükséges az igényt lehet hitelesíteni, vagy ellenőrizni mielőtt eljutna a CA-ba, hogy elkészüljön a tanúsítvány. Ha ez rendben van és eljutott az igény a CAba, akkor ott elkészül a tanúsítvány és innen jut vissza az RA-n keresztül a végfelhasználóhoz és a tanúsítvány directory-ba néhány másodpercen belül. A tanúsítvány visszavonási lista (CRL) is a tanúsítvány directory-ban tárolódik. Az OCSPro feladata a rendszerben a valós idejű tanúsítvány ellenőrzés. Előnyei: − −

− −

− − −

−

Bővíthetőség: a felépítéséből adódóan a rendszer könnyen bővíthető, jól tervezhetőek a bővítési lépések és ezek esetén nem szükséges a teljes rendszer újratervezése, átalakítása, mert az új részek egyszerűen beilleszthetők a már meglévő egészbe. On-line tanúsítvány ellenőrzés: ezzel megoldható, hogy az érvénytelen (lejárt, visszavont) tanúsítványok azonnal bekerüljenek a CRL-be a tanúsítvány directory-n belül, így megszűnik az érvénytelen tanúsítványok elfogadására fennálló időrés, amely a nem on-line, hanem periodikus időközönként frissülő CRL esetén a nem azonnali frissítés esetén fennáll. Központi adminisztráció: a különálló rendszerelemek központi adminisztrációja megoldott. Megbízható működés: lehetőség van több CA, RA szerver kialakítására, és bármilyen hiba bekövetkezése esetén, ha egy CA, RA szerver nem áll rendelkezésre a kliensek egy másik CA, RA szerverre kapcsolódnak, így a működés nem áll le az operátorok és a felhasználók számára. Automatikus tanúsítvány installáció: az EE (végfelhasználói) szoftver képes automatikusan importálni a tanúsítványokat. Felhasználói profilok kialakítása: a CA rendszeradminisztrátorok kialakíthatnak felhasználói profilokat a regisztrációs folyamathoz a RAC operátorok részére, így e feladatkör elvégzéséhez minimális képzés szükséges. Interoperabilitás: az interoperabilitás és a kereszthitelesítés megvalósítására a PKI Enablement Toolkit szolgál, mely támogatja a PKCS szabvány alapú és kompatibilis kéréseket, valamint képes kommunikálni más gyártók szoftvereivel Application Interface-en (API) keresztül. CPS generátor: a beépített (angol nyelvű) CPS generátor mintát ad a CPS elkészítésére, elősegíti azt.

Licencelés A szoftver licencelése a felhasználók számán alapszik. Az egy felhasználóra és így tanúsítványra jutó ár a felhasználók és így a tanúsítványok számának növekedésével arányosan csökken. A PKI elemei tetszőleges számban és felépítésben használhatóak, ezt a termék licencelése lehetővé teszi, így nagyon rugalmasan az egyedi igényekhez alkalmazkodva lehet kialakítani a PKI rendszert. Az eTrust PKI mellett még 3 fő termék kapcsolódhat opcionálisan: az eTrust Directory, az eTrust OCSPro, és az eTrust Web Access Control. Az első kettő egy alapváltozatát tartalmazza az eTrust PKI, míg ha ezek bővített változatára van szükség, akkor ezek licencelése szerver alapon történik. A licenc díj egyszeri díj, a felhasználók száma után fizetendő, melyhez egy éves követési díj tartozik, mely a licenc díj 20%-a. Referenciák Arizona Department of Transportation, USA − Cornerstone Solutions, Inc., USA − San Bernardino Sheriff’s Department (SBSD), USA − Computer Associates – CustomerConnect, AccountConnect, SupportConnect szolgáltatás, USA


34

Megoldás javaslat az ISZT hitelesítés-szolgáltató kialakítására Architektúra A javasolt megoldás felépítését a következő ábra szemlélteti: ISZT Key Management szerver

Központi adminisztrációs kliens

OCSPro szerver HSM

CA szerver RA szerver

Duplikált

DB

Regisztrációs szervezet

CA-RA tier szerver

Directory szerver Directory szerver

RACE

SC

RACS

SC

RACE

SC

RACS

SC

RACE

SC

RACS

SC

RACE

SC

RACS

SC

Partner1

személy szervezet szerepkör szerver

Partnern



RACE

SC

RACS

SC

RACE

SC

RACS

SC

RACE

SC

RACS

SC

RACE

SC

RACS

SC

személy

RACE

SC

RACS

SC

szervezet

RACE

SC

RACS

SC

szerepkör

RACE

SC

RACS

SC

szerver

RACE

SC

RACS

SC

személy szervezet szerepkör szerver

5. ábra: Javasolt hitelesítés-szolgáltató architektúra

Az architektúra ábránál meg kell különböztetni különböző földrajzi helyeket, melyek az ISZT és a hitelesítés-szolgáltatást értékesítő partnereinek telephelyei. Az ISZT telephelyén kerül kialakításra maga a hitelesítés-szolgáltató, és az itt elhelyezett szerverekkel tudnak kapcsolatba kerülni a kihelyezett kliensekkel a partnerek, valamint itt található a tanúsítványtár, ahol a felhasználók elérhetik az aktuális tanúsítványinformációkat, visszavonási listákat és egyéb dokumentumokat. Az eTrust PKI szoftver licenceléséből adódóan a Directory, OCSPro és Key Management szerverek kivételével, a PKI rendszer kiépítésénél plusz szoftverköltség nélkül tetszőleges struktúra kialakítható tetszőleges számú elem felhasználásával. CA-RA tier szerver A hitelesítés-szolgáltató magja a CA-RA tier szerver (Computer Associates eTrust PKI szóhasználatával), mely szerveren található a CA és RA szerver szoftver, valamint ezen belül a CA áll kapcsolatban a HSM-mel (Hardware Security Module), ami a CA titkos kulcsát tárolja. A HSM-et több gyártó termékei közül lehet kiválasztani, egy jó megoldás lehet pl. a Luna CA3 Hardware Security Module. Ennek természetesen meg kell felelni bizonyos biztonsági elvárásoknak, pl. hogy a titkos kulcs soha semmilyen körülmények között nem kerülhet ki az eszközből. Az RA szerver fogadja az RA kliensektől érkező tanúsítvány kérelmeket és továbbítja a CA felé, ami lényegében hitelesíti a tanúsítványokat a HSMen tárolt titkos kulcsával. Az RA szervernél be lehet állítani többféle ellenőrzési metodikát, ami során ez ellenőrzi, hogy az RAC a számra engedélyezett beállítások szerint, és az engedélyezett tanúsítványok fajtára adott-e be kérelmet. Majd a CA-tól visszakapott aláírt tanúsítványt eljuttatja a tanúsítványtárba, valamint az RA kliensen keresztül a végfelhasználóhoz.


35

OCSPro szerver Az RA szerverrel van kapcsolatban az OCSPro és a Directory szerver is. Az OCSPro a valós idejű tanúsítvány ellenőrzést teszi lehetővé, míg a Directory szerveren található a már említett tanúsítványtár. Directory szerver A Directory szerveren kerülnek publikálásra a hitelesítés-szolgáltatótól elvárt nyilvános információk, mint pl. a tanúsítványok, a visszavonási listák, valamint itt célszerű publikálni a szabályzatokat és a kapcsolódó dokumentumokat is. A Directory szervernek nagyon magasfokú rendelkezésre állást kell biztosítani, mert mindig ki kell elégíteni a tanúsítványok vagy a visszavonási listák elérésére felmerülő felhasználói igényeket. Így célszerű a Directory szervert, mint azt az architektúra ábrán is megjelöltük duplikálni, vagy forró háttérrel ellátni. Key Management szerver Fontos elem még a Key Management szerver, ami még szintén az RA szerverhez kapcsolódik, ez tárolja, természetesen, szigorúan szabályozott és biztonságos körülmények között az igényelt titkosításra szolgáló tanúsítványokhoz tartozó titkos kulcsokat, arra az esetre, ha valami módon sérülne, vagy megsemmisülne az eredeti titkos kulcs és a titkosított dokumentumokra, információkra a felhasználónak szüksége van. Központi adminisztrátori kliens Az RA szerverhez kapcsolódik egy központi adminisztrátori kliens, melyen keresztül lehet a CA-RA tier szerver beállításait elvégezni, természetesen a megfelelő azonosítás után, a megfelelő jogosultságok birtoklása esetén. Ezt célszerű egy külön munkaállomásra telepíteni. Regisztrációs szervezet Az eddig bemutatott rendszerelemek mellett nagyon fontos elemek még a Regisztrációs szervezetek, melyek magukba foglalják a különféle RAC-ket, azaz a RA klienseket. A Regisztrációs szervezeten belül a megfelelő RAC fogadja a tanúsítvány igényeket, végzi el az igénylő azonosítását, és továbbítja a tanúsítvány kérelmeket, kommunikál az RA szerverrel. Az architektúra ábrán látható, hogy Regisztrációs szervezet több helyen előfordulhat, az ISZT telephelyén, valamint a partnercégek telephelyein egy vagy több az igények szerint kialakítva. Hogy hány Regisztrációs szervezet lesz kialakítva, az az ISZT akaratától és a partnercégek számától függ. A javasolt az, hogy legyen egy Regisztrációs szervezet az ISZT telephelyén és a partnercégek telephelyein is egy-egy. Ha egy partnercégnek több telephelye is van, akkor mindegyiken ki lehet egy Regisztrációs szervezetet alakítani. Az ábrán bemutatott Regisztrációs szervezet tartalmazza az RAC-ket a tanúsítványok összes variációjához. Az RACE szolgál az megfelelő tanúsítványfajtához tartozó titkosításra szolgáló, az RACS pedig az aláíró tanúsítványokkal kapcsolatos regisztrációs ügyintézésre. A Regisztrációs szervezeten belül nem kötelező az összes féle RAC-t használni, hanem az egyedi igény vagy megállapodás szerint kialakítható tetszőleges struktúra tetszőleges számú RAC-vel. Egy Regisztrációs szervezeten belül elképzelhető, hogy nincs meg az összes féle RAC, de egy féléből esetleg több is van. Az egyes RACkhez létrehozható különféle felhasználói profil, mely segítségével az RAC operátorok munkája egyszerűsíthető, valamint meghatározható hogy melyik RAC-vel milyen tanúsítványt lehet igényelni. Az RAC-ket nem feltétlenül szükséges külön munkaállomásokra telepíteni, de az azonos tanúsítványigényeket közvetítő RAC-ket ésszerűen igen. Az RAC-khez kapcsolódnak még az intelligens kártyaolvasók/írók (SC), amelyek segítségével a tanúsítvány és a titkos kulcs elhelyezhető az intelligens kártyán. Az ábrán minden egyes RAC-hez külön SC tartozik, de amennyiben egy munkaállomáson több RAC is helyet kap, akkor ennek függvényében alakul az SC-k száma is. Szolgáltatások 1. Regisztráció (ügyfelek, attribútumok, eszközök), 2. Tanúsítvány kibocsátás: személyes aláíró, személyes titkosító, szerver, szervezet, szerepkör tanúsítványok, 3. Tanúsítványok kezelése (megújítás, visszavonás), 4. Tanúsítványokkal kapcsolatos információk megbízható nyilvános elérése (tanúsítványok, visszavonási listák, szabályzatok, kapcsolódó dokumentumok), 5. Tanúsítvány és aláíró adat elhelyezése biztonságos aláíró eszközön: © EGERSZEGI CONSULTING – INTEGRITY, 2002

36

Intelligens kártya kibocsátása, perszonalizációja − Szükséges hardver (intelligens kártyaolvasó) biztosítása − Opcionálisan megoldás: az aláíró adat csak biometrikus azonosítás után lehessen elérhető az aláíró eszközön (opcionális hardverrel jellemzően a CA- és RA-operátorok számára), 6. Valós idejű tanúsítvány ellenőrzés, 7. Titkosító tanúsítványokhoz tartozó titkos kulcsok biztonsági tárolása, 8. Időbélyegzés. A fenti szolgáltatások közül az 5., 6., 7. és 8. pontban említettek nem feltétlenül alapszolgáltatások, ezek lehetnek opcionális szolgáltatások, melyek ára nem épül be a tanúsítvány kibocsátás és megújítás árába. Működési folyamat Tanúsítvány kibocsátás a regisztrációs folyamat végeredményeként előálló certificate-request alapján történhet, csak az ISZT központban üzemeltetett CA által. A kibocsátott tanúsítványok felhasználói között javasolt különbséget tenni, azaz minden tanúsítványtípust nem célszerű mindenkinek szolgáltatni: Személyes aláíró kulcsok tanúsítványa (mindenkinek) − Személyes titkosító kulcsok tanúsítványa (mindenkinek) − Szerver (SSL) tanúsítvány (ISZT tagok eszközei számára; ez kiterjeszthető ügyfelekre is) − Szervezet tanúsítvány (ISZT Egyesület tagjai számára; ez is kiterjeszthető céges ügyfelekre is) − Szerepkör (ISZT és tagjainak munkatársai számára; kiterjeszthető kisebb létszámú céges ügyfelekre is) A regisztrációs, illetve megújítási folyamatban a Regisztrációs szervezetben az RAC-k végzik el a fizikai azonosítást, a tanúsítvány-előállítással, megújítással kapcsolatos kérések előállítását, a kártyaperszonalizációt, kulcs-generálást is. Az RAC-hoz beérkezett tanúsítványkérelem az ellenőrzés után és a generált nyilvános kulcs továbbítódik az RA szerverhez, ami egy újabb ellenőrzés után átadja hitelesítésre a CA szervernek, ami ezt a HSM-en tárolt titkos kulcsával megteszi. Ezután a tanúsítvány visszakerül az RA szerverhez, ami ezt publikálja a Directory szerverre és visszajuttatja az RAC-hez, ami a titkos kulcsot és a tanúsítványt biztonságosan elhelyezi az intelligens kártyán. Az RA szerver ezen kívül támogatja a felhasználó kulcsainak tárolását is (Key Management, Key Escrow), amelyek beállítás szerint tárolódnak a Key Management szerveren. Az On-Board-Key-Generation funkció implementálása emeli a szolgáltatás biztonságos voltát, azonban belső vagy fokozott biztonságú szolgáltatók esetében nem feltétlenül követelmény. Ezt a döntést befolyásolja a szolgáltatás létező kulcsokkal kapcsolatos politikája is – engedélyezi vagy megtiltja létező, hozott kulcsok tanúsítását. Megjegyezzük, hogy a magyarországi szolgáltatók alapvetően bizalmatlanok az ügyfél által szállított kulcsokkal szemben, így a GIRO a hozott kulcsok tanúsítását kimondottan nem támogatja, a MATÁV az On-Board-Key-Generation-t támogatja, és megjegyzi, hogy aláírás-létrehozó adatot csak akkor helyez el a felhasználó eszközén, ha a tanúsítványt is ő bocsátja ki. A Netlock a kulcspár generálását csak az ügyfél által tartja megvalósíthatónak, és csupán a tanúsíttatni kívánt nyilvános kulcs titkos párjának birtoklását kívánja meg a regisztrált entitástól, a kulcsgenerálással kapcsolatos minden felelősséget a felhasználóra hárítva át, tehát elvileg – úgy tűnik – a Netlock az, aki hajlandó hozott kulcsokkal is foglalkozni. Költségek Meghatározások Az ISZT, mint szolgáltató a saját és partnercégei alkalmazottainak nyújt tanúsítványokat, valamint a nyilvános szolgáltatás kereteiben elsősorban magánszemélyeknek személyes tanúsítványokat. 1 felhasználó ésszerűen 2 tanúsítvánnyal rendelkezik, egy aláíróval és egy titkosításra alkalmassal. 1 ISZT tag munkatársa átlagosan 2 felhasználónak felel meg, pl. munkahelyi és otthoni felhasználás, hiszen itt már bejön a szerepkör-tanúsítvány is. Szerepkör, szervezet tanúsítványt az ISZT csak saját és partnercégei alkalmazottainak, szerver tanúsítványt pedig a saját vagy partnercégei eszközeinek hitelesítésére biztosít.


37

Tanúsítványra vetített szoftverköltség A tanúsítványra vetített szoftverköltség listaárakon alapul, melyektől a gyakorlatban nagyobb eltérések is lehetnek, mivel nagyobb tételben minden esetben egyedi árak kerülnek kialakításra. Ez a költség nem tartalmazza a lentebb felsorolt kapcsolódó költségeket, amelyekkel a teljes beruházási összeg a szoftverköltség két-háromszorosa is lehet, de ez is erősen függhet az induló darabszámoktól. 10.000 felhasználó esetén 20.0000 tanúsítvánnyal számoltunk. A szoftver licenc díja kb. 22 millió Forint, így az egy tanúsítványra vetített szoftverköltség 1.100,-Ft. 100.000 felhasználó esetén 200.000 tanúsítvánnyal számoltunk. A szoftver licenc díja kb. 90 millió Forint, így az egy tanúsítványra vetített szoftverköltség 450,-Ft. 1.000.000 felhasználó esetén 2.000.000 tanúsítvánnyal számolunk. A szoftver licenc díja kb. 120 millió Forint, így az egy tanúsítványra vetített szoftverköltség 60,-Ft. Kapcsolódó költségek, melyeket nem tartalmaz a fenti tanúsítványra vetített szoftver költség: éves követési díj (licenc díj 20%-a/év) − eTrust Directory és OCSPro szerverek licencdíja − biztonságos hitelesítés-szolgáltatói környezet (CA) fizikai kialakítása (ez növelheti, illetve csökkentheti is a költségeket a már meglévő környezet függvényében) − hardver beszerzések: − Szerverek, kliensek, HSM modul − Intelligens kártyák, kártyaolvasók (ezeket a felhasználók számának növekedésével arányban érdemes beszerezni, valamint ezek költsége áthárítható az ügyfelekre) − implementálási díj (installálás, integráció, bevezetés, tesztelés, stb.) − külső tanácsadói díjak − szabályozás elkészítése − a projekttel kapcsolatban felmerülő belső költségek (ember, erőforrás) − üzemeltetés − támogatás a szoftverszállító, implementáló részéről − éves auditálás − piacra lépés esetében a nyilvántartásba vétellel összefüggő államigazgatási díjak


38

Utimaco SafeGuard PKI Az Utimaco Safeware vezető biztonságtechnikai cég, amely a publikus kulcsok teljes választékát kínálja. Ez lehetővé teszi többek között az erős hitelesítést, biztonságos kommunikációt, SSL-t, VPN-t és digitális aláírást, melyekhez biztonsági hardverként használható az intelligens kártya. Az Utimaco kizárólagos magyarországi képviseletét az Ediport Kft. látja el, és ők foglalkoznak a szoftver bevezetésével is hazánkban. Az Utimaco termékének szerepeltetését az indokolja, hogy 2001-ben elindult egy PKI Challenge nevű EU-projekt, mely a PKI-termékek interoperabilitását hivatott megvizsgálni és dokumentálni, a CA-RA termékektől a végfelhasználói kliensekig bezárólag minden kapcsolatban elemzi a különböző termékek együttműködési képességeit. A projekt – a tervek szerint – 2002 decemberében zárul egy nyilvános jelentéssel. A projekt résztvevői kormányzati, akadémiai, vállalkozói, független tanácsadói és PKI termékgyártói körből kerültek ki, amelybe az Entrust, Globalsign, Baltimore Entegrity, és a SmartTrust mellett az Utimaco is beletartozik. Sőt, a PKI-termékek megfelelőségét – a hírek szerint – úgy mérik, hogy a SafeGuard PKI-nak való megfelelőséget pontozzák a többi gyártó termékei esetében is, azaz az Utimaco SafeGuard PKI rendszer kvázi etalonnak számít az Európai Unióban. SafeGuard PKI A SafeGuard PKI célja, hogy azoknak a cégeknek és szervezeteknek biztosítson megoldást, melyeknek rugalmas biztonsági politikára van szükségük, és hogy a PKI a kliensek alkalmazásaihoz biztonságos hozzáférést, jogosultságokat nyújtson, valamint ahol fontos szempont a méretezhetőség, a jövőbeli szükségleteknek megfelelő bővíthetőség is megtalálható a rendszerben. SafeGuard PKI elemei A SafeGuard PKI, ami az Utimaco új generációs PKI termékein alapszik, a következő elemekből áll: − − − − −

SafeGuard Certification Authority (CA), SafeGuard Registration Authority (RA), SafeGuard Registration Point (RP), SafeGuard User Agent (UA), SafeGuard Publication Agent (PA).

Certification Authority

Szerver

Publication Agent

Adminisztrátor

Registration Authority

Hálózat

Registration Authority

Registration Point

Registration Point

Felhasználó

User Agent

6. ábra: A SafeGuard PKI architektúrája

Tanúsítványkiadáshoz, ebben a konfigurációban, a CA az RA, RP, UA on-line kérelmeit fogadja el. A rendszerelemek felinstallálhatók egy szerverre is, de külön-külön szerveres megoldás is megvalósítható.


39

Az RA batch-mód verzióként is használható. Támogatott operációs rendszerek CA és PA: Microsoft Windows NT version 4.0, Microsoft Windows 2000 RA, RP és UA: Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows Me, Microsoft Windows NT version 4.0, Microsoft Windows 2000 Támogatott alkalmazások X.509 tanúsítvány szabvány alapú alkalmazások, SafeGuard Sign&Crypt; SafeGuard VPN; SafeGuard Advanced Security hitelesítést nyújtó bővítésekkel; CryptWare Toolkit A CA szolgáltatásai: Felhasználói ID érvényességének vizsgálata, − Felhasználói kulcs generálása, tanúsítása, − PIN kód generálás, − PIN mailing, − Felhasználói kulcs, tanúsítvány visszavonása, − CRL generálás, − Felhasználói kulcsmásolás, visszaállítás, − Kereszttanúsítás. Emellett a CA támogatja a következőket: Oracle adatbáziskezelő, − X.500 kibocsátás, − CA roll-over, − Policy menedzsment, − Biztonságos intelligens kártya ellátás. Az RA szolgáltatásai: Felhasználói ID kérelmek végrehajtása, − Felhasználói kulcs tárolása (intelligens kártyán vagy PKCS#12 kulcs fájlban), − Felhasználói tanúsítványkészítési kérelem, − Felhasználói tanúsítvány visszavonási kérelem, − Felhasználói kulcs megújítási, frissítési kérelem, − Intelligens kártya kibocsátása, − Felhasználói policy menedzsment, − Kulcs visszaállítási kérelem, − Felhasználó törlési kérelem, − Intelligens kártya menedzsment, − Eseménynaplózás. Bizonyos rendszerkonfigurációkban szükség lehet automatikus batch kérelmek lebonyolítására. Az RA Batch Mode egy projekt orientált interface-t ajánl nagyszámú tanúsítvány elkészítéséhez, ami a következő funkciókat támogatja: Felhasználói ID elkészítése, − Felhasználói kulcs elkészítése, − Visszavonás, − Frissítési, megújítási kérelmek, − Egyidejűleg használható az általános RA-val. Ha a PKI környezetet egy decentralizált kulcsgenerálási modellbe kell illeszteni, akkor az RA tevékenysége csak regisztrációra korlátozódik, kulcsgenerálási vagy tanúsítási kérelmi funkció nélkül. Ez esetben az RA egy Registration Point-tá változik. A User Agent egy lokális alkalmazás akár a végfelhasználó gépén, ami elvégzi a felhasználó tanúsítását és az intelligens kártya menedzselését. Ezeket a műveleteket csak a végfelhasználó végezheti el, és ezek függenek a policy-ban meghatározott előírásoktól.


40

Az UA tipikus működése: Helyi RSA kulcspár generálás, − Tanúsítvány kérelem, − Frissítési, megújítási kérelem, − Intelligens kártya menedzsment. Az UA a PKI-n belül szorosan együttműködik az RA-val, vagy RP-vel. Általában az UA-t nem kell minden felhasználónak használnia – nem is javasolt -, hiszen a használatához szükséges PKI ismeretek az irodai/otthoni felhasználáson túlmutató speciális tudást jelentenek. A Publication Agent egy olyan modul, amely a CA-n helyezkedik el, és a tanúsítvány directoryba továbbítja az új tanúsítványokat vagy a visszavont tanúsítványokat a CRL-be. A működés egyszerűsítése végett konfigurálható rendszeres időközönkénti automatikus kommunikációra. A PKI szoftverhez igényelhető egy Software Development Kit (SDK) fejlesztőeszköz is, mellyel az egyedi igényeknek megfelelő fejlesztésék megoldhatók bizonyos korlátokon belül. Licencelés A szoftver licencelése a kibocsátott tanúsítványok számán alapszik. Két változata van forgalomban: PKI Light és PKI Enterprise. A Light verzió max. 10.000 tanúsítványt képes kezelni, míg az Enterprise változat a tanúsítványok számát nem köti meg. Az egy tanúsítványra jutó ár a tanúsítványok számának növekedésével arányosan csökken. A Safeguard PKI Enterprise változata tartalmazhatja a szükséges agent-eket és kiegészítő alkalmazásokat. Referenciák A referencia-listája az Utimaco-nak széles, Európában kormányzatok, EU-hivatalok is használják több termékét, a VPN-től kezdve a PKI-rendszerekig. Az alábbi lista a PKI-rendszerek első vásárlóit és felhasználóit mutatja be. FöreningsSparbanken, Svédország (több, mint 10.000 tanúsítvány) − Svájci Posta, Svájc − Európai Unió


41

Megoldás javaslat az ISZT hitelesítés-szolgáltató kialakítására Architektúra A korábban felvázolt szolgáltatáshoz tehát az alábbi strukturális felépítés javasolt: − − − − −

CA (tanúsítványok kibocsátása, benne HSM – Hardver Security Module), RA (regisztráció, mind a központban [ISZT és/vagy szervezetei számára], mind az ISZT tagjainál lokálisan [ISZT szervezetek munkatársai és/vagy ügyfelek számára] – RA, RP, vagy UA), Certification Repository (szabályzatok, tanúsítványok hozzáférésének biztosítása; általában az X.500-on alapuló névtár), aláíró adat aláíró eszközön történő elhelyezése (ez a gyakorlatban intelligens kártyakibocsátást és perszonalizációt jelent – opcionális) Key Management System (a titkosító kulcsok kezelése, visszaállításának lehetősége)

Szolgáltatások 1. Regisztráció (ügyfelek, attribútumok, eszközök), 2. Tanúsítvány kibocsátás: személyes aláíró, személyes titkosító, szerver, szervezet, szerepkör tanúsítványok, 3. Tanúsítványok kezelése (megújítás, visszavonás), 4. Tanúsítványokkal kapcsolatos információk megbízható nyilvános elérése (tanúsítványok, visszavonási listák, szabályzatok, kapcsolódó dokumentumok), 5. Tanúsítvány és aláíró adat elhelyezése biztonságos aláíró eszközön: − Intelligens kártya kibocsátása, perszonalizációja − Szükséges hardver (intelligens kártyaolvasó) biztosítása − Az aláíró adat csak biometrikus azonosítás után lehessen elérhető az aláíró eszközön (opcionális hardverrel jellemzően a CA- és RA-operátorok számára), 6. Valós idejű tanúsítvány ellenőrzés, 7. Titkosító tanúsítványokhoz tartozó titkos kulcsok biztonsági tárolása, 8. Időbélyegzés. A fenti szolgáltatások közül az 5., 6., 7. és 8. pontban említettek nem feltétlenül alapszolgáltatások, ezek lehetnek opcionális szolgáltatások, melyek ára nem épül be a tanúsítvány kibocsátás és megújítás árába. Működési folyamat Tanúsítvány kibocsátás a regisztrációs folyamat végeredményeként előálló certificate-request alapján történhet, csak az ISZT központban üzemeltetett CA által. A kibocsátott tanúsítványok felhasználói között javasolt különbséget tenni, azaz minden tanúsítványtípust nem célszerű mindenkinek szolgáltatni: − − − − −

Személyes aláíró kulcsok tanúsítványa (mindenkinek) Személyes titkosító kulcsok tanúsítványa (mindenkinek) Szerver (SSL) tanúsítvány (ISZT tagok eszközei számára; ez kiterjeszthető ügyfelekre is) Szervezet tanúsítvány (ISZT Egyesület tagjai számára; ez is kiterjeszthető céges ügyfelekre is) Szerepkör (ISZT és tagjainak munkatársai számára; kiterjeszthető kisebb létszámú céges ügyfelekre is)

A regisztráció folyamatát három applikáció is megtámogatja, szűkülő funkcionalitással felsorolva: Registration Authority, User Agent, Registration Point. Mindhárom alkalmazás képes tanúsítványelőállítással, megújítással kapcsolatos kérések előállítására, de a Registration Point a smart-card menedzselését nem támogatja. A Registration Point mögé a felettes működési szervnek (pl. CA) kell biztosítania a kártya-perszonalizációt, valamint a kulcs-generálást is. Elképzelhető egy olyan megvalósítás, melynél a központban üzemelnek a széleskörűen végzett szolgáltatások, ami magában foglalja a CA, RA, WebRA, Batch RA és PA modulok telepítését is. Az RA-k alapvető funkciója az ügyfél személy-azonosságának ellenőrzése és ennek alapján egy (vagy kettő) certificate-request kiállítása, illetve a meglévő tanúsítványok frissítése. Annak RA-javára történő eldöntése után, hogy a visszavonási igényeket hol kell lekezelni, az RA-knak támogatniuk kell ezt a © EGERSZEGI CONSULTING – INTEGRITY, 2002

42

funkciót is. Az RA modul ezen kívül támogatja a felhasználó kulcsainak tárolását is (Key Management, Key Escrow). Az On-Board-Key-Generation funkció implementálása emeli a szolgáltatás biztonságos voltát, azonban belső vagy fokozott biztonságú szolgáltatók esetében nem feltétlenül követelmény. Ezt a döntést befolyásolja a szolgáltatás létező kulcsokkal kapcsolatos politikája is – engedélyezi vagy megtiltja létező, hozott kulcsok tanúsítását. Az eTrust PKI megoldásnál említett megjegyzésünk itt is fenn áll, hogy a magyarországi szolgáltatók alapvetően bizalmatlanok az ügyfél által szállított kulcsokkal szemben, és a szolgáltatók a saját szabályozásuk szerinti megkötésekkel támogatják vagy nem támogatják a hozott kulcsok tanúsítását. Költségek Meghatározások 1 felhasználó (tipikusan ügyfél) ésszerűen 2 tanúsítvánnyal rendelkezik, egy aláíróval és egy titkosításra alkalmassal. 1 ISZT tag munkatársa átlagosan 2 felhasználónak felel meg, pl. munkahelyi és otthoni felhasználás, hiszen itt már bejön a szerepkör-tanúsítvány is). Szerepkör, szervezet tanúsítványt az ISZT csak saját és partnercégei alkalmazottainak, szerver tanúsítványt pedig a saját vagy partnercégei eszközeinek hitelesítésére biztosít. Tanúsítványra vetített szoftverköltség A tanúsítványra vetített szoftverköltség listaárakon alapul, melyektől a gyakorlatban nagyobb eltérések is lehetnek, mivel nagyobb tételben minden esetben egyedi árak kerülnek kialakításra. Ez a költség nem tartalmazza a lentebb felsorolt kapcsolódó költségeket, amelyekkel a teljes beruházási összeg a szoftverköltség két-háromszorosa is lehet, de ez is erősen függhet az induló darabszámoktól. − max. 10. 000 tanúsítvány esetén a szoftver licenc díja kb. 27 millió Forint, így az egy tanúsítványra vetített szoftverköltség 2.700.-Ft. − 100.000 tanúsítvány esetén a szoftver licenc díja kb. 84 millió Forint, így az egy tanúsítványra vetített szoftverköltség 840.-Ft. − 1.000.000 tanúsítvány esetén a szoftver licenc díja kb. 250 millió forint, így az egy tanúsítványra vetített szoftverköltség 250,-Ft, de ez a konfiguráció tetszőleges komponenst és korlátlan számú tanúsítványt foglal magába, azaz további költségek a kiépítettség növekedésével már nem jelentkeznek. Megjegyezzük továbbá, hogy az első két implemetációban 1.000 db User Agent foglaltatott bele, míg a harmadiknál ez (is) korlátlan. A felhasználó oldalán szükségesek további kliens-programok, melyek beépülve az általánosan használt alkalmazásokba, kínálják fel a PKI-rendszer által nyújtott előnyöket. Ezek hiányában a tanúsítványok csupán olyan programokkal használhatók együtt, melyek fel vannak erre készítve (pl. böngészők: Internet Explorer, Netscape Navigator). A levelező programokba a tanúsítványok fájlból most is beimportálhatók, de a kártyán tárolt tanúsítványok használatához alkalmas kliens-alkalmazás szükséges. A kliens-programok listaárait az alábbi táblázat tartalmazza: Kliens SafeGuard Sign&Crypt for Outlook

SafeGuard Sign&Crypt for Office

Darabszám

Ár

1.000

11.000.000

10.000

83.000.000

50.000

~300.000.000

1.000

20.000.000

10.000

162.000.000

korlátlan

~300.000.000

Kapcsolódó költségek, melyeket nem tartalmaz a fenti tanúsítványra vetített szoftverköltség: − X.500 névtár kialakításának költsége, − felhasználói kliensek ára (Sign&Crypt for Office, Outlook, Notes), − további szükséges User Agent költségek,


43

− − − − − − − − − − − −

biztonságos hitelesítés-szolgáltatói környezet (CA) fizikai kialakítása (ez növelheti, illetve csökkentheti is a költségeket a már meglévő környezet függvényében), hardver beszerzések: Szerverek, kliensek, HSM modul Intelligens kártyák, kártyaolvasók (ezeket a felhasználók számának növekedésével arányban érdemes beszerezni, valamint ezek költsége részben áthárítható az ügyfelekre), implementálási díj (installálás, integráció, bevezetés, tesztelés, stb.), külső tanácsadói díjak, szabályozás elkészítése, a projekttel kapcsolatban felmerülő belső költségek (ember, erőforrás), üzemeltetés, támogatás a szoftverszállító, implementáló részéről, éves auditálás, piacra lépés esetében a nyilvántartásba vétellel összefüggő államigazgatási díjak.

Összehasonlítás Az alábbi táblázat a tanúsítvány/szoftverár költségeket szemlélteti. Fel kell hívnunk a figyelmet, hogy a két termék eltérő filozófiája és moduljai, illetve a szükséges kiegészítők ismeretének hiánya az összehasonlíthatóságot nagyon megkérdőjelezi, valamint az sem tűnik ki ebből, hogy a szolgáltatás és a szolgáltató implementálását melyik termék támogatja jobban, vagy kevésbé. Szolgáltatáson belső, zártkörű kisebb kapacitású rendszert értünk, míg szolgáltatónak nyilvános, nagy létszám lekezelésére is képes rendszert használó szervezetet nevezünk. Jelen összehasonlítás célja, hogy nagyságrendileg elhelyezze a hitelesítés-szolgáltató kiépítésének szoftveres költségeit. A megoldások korrekt összehasonlítását csak a konkrét árajánlatok ismeretében lehet megtenni, mivel azok tartalmazzák a szoftverek, hardverek, kialakítás, implementálás és kapcsolódó szolgáltatások pontos árait. Ilyen árajánlatok viszont csak kész rendszerterv alapján kérhetőek. Gyártó Utimaco Safeguard PKI

Darabszám

Ár/darab (Ft)

10.000

2.700

100.000

840

1.000.000*

250

* korlátlan tanúsítvány számra is az 1.000.000 darabos ár áll fenn, így e mennyiség felett a tanúsítványok ára tovább csökken.

CA eTrust PKI


10.000

1.100

100.000

450

1.000.000

60

44

Egyedi fejlesztés lehetősége Gyártók megoldásai, ill. megoldásszállítók mellett lehetőség van sajátfejlesztésű5 PKI létrehozására, ill. hitelesítő szervezet (CA) szoftverének, ill. rendszerének kifejlesztésére. Kereskedelmi forgalomban beszerezhető kriptográfiai modulok lehetőséget adnak saját tanúsítványhitelesítő rendszerek fejlesztésére, ahol speciális követelmények maximálisan figyelembe vehetőek. Lehetséges Java, C, Microsoft CryptoAPI és más alapokon PKI-t, ill. CA-t létrehozni. Ilyen rendszer fejleszthető C nyelven a Baltimore Keytool Pro csomagja (ANSI C), valamint Windows platformra a Microsoft CryptoAPI csomagjának felhasználásával. Noha C-ben több platformra lehet fejleszteni, az MS CryptoAPI nyilván csak MS Windows alapú rendszer létrehozására alkalmas. A C alapú fejlesztés nemigazán indokolható tanúsítványkiadó esetén, az MS CryptoAPI viszont nem támogatja CA létrehozását, azt az alapokról kellene felépíteni benne. Java alapon platformfüggetlen fejlesztés valósítható meg, készen elérhetők CA létrehozásához szükséges kriptográfiai modulok. A Java előnyei: − − − −

−

platformfüggetlen, adatbázis-kezelő független, a rendszer terhelése elosztható, illetve szükség esetén lehetőség nyílik esetén más nyelven implementált modulok illesztésére (elérési lehetőségek: RMI, CORBA stb.), kriptográfiai modulgyártó független (azaz bármely szabványos kriptográfiai szoftver illeszthető), számos megfelelő modul választható, Internetes alkalmazások, interface-ek fejlesztésére kifejezetten alkalmas, teljes megoldás Java alapon létrehozható.

Megfelelő biztonsági és megbízhatósági szintet képviselő, platform és adatbázis-kezelő független rendszer Java alapon megvalósítható. A rendszer magját képező kriptográfia szempontjából a megfelelő kriptográfiai csomag, ill. csomagok választása kulcskérdés, noha több, a kívánt cél megvalósítására alkalmas csomag is választható. A különböző kriptográfiai csomagokat aszerint kell megvizsgálnunk, hogy milyen szolgáltatásokat, milyen interface-eket tartalmaznak. Az ingyenes Java JDK 1.4-ben elvileg megvannak a szükséges kriptográfiai algoritmusok, de egy tanúsítvány kiadását az alapoktól kellene megvalósítani, komoly programozási munka befektetésével, míg ugyanez az IAIK JCE-ben, vagy a Phaos J/CA-ban egyetlen utasítás meghívásával elvégezhető. Elméleti rendszerfelépítés Ha elfogadjuk a Java nyelvet, mint az egyik legrugalmasabb fejlesztői nyelvet egy CA szoftver fejlesztéséhez, akkor a platformfüggetlenségen kívül a teljes rendszert igény szerint bővíthető modulokból építhetjük fel. A következőkben felvázolunk egy elméleti rendszerfelépítést, sorra vesszük a minimálisan szükséges modulokat, és a megvalósításukban felhasználható termékeket. Egy minimális CA rendszernek – a Baltimore Core Technology csoportjához hasonlóan – a következő modulokat kell tartalmaznia. −

−

5

CA modul: Ez a modul végzi a tényleges tanúsítványkészítést, hitelesítést, hosszabbítást, visszavonást, azaz magát a tanúsítványokat, ill. szerkezetüket érintő módosításokat. Ezentúl a tanúsítványokkal kapcsolatos igénylői adatok kezelését is tartalmazza. Itt kell megjegyeznünk, hogy amennyiben a tanúsítványhoz tartozó privát kulcsot is tárolni kell a rendszerben (és a kulcsvesztésből származó költségek minimalizálása érdekében ez szükséges lehet /opcionális szolgáltatás/), akkor annak biztonságos tárolásáért és visszaállításáért egy teljesen különálló alrendszer felel. CA Operátor modul: Ez a modul gyakorlatilag az interface-t biztosítja a CA operátorok felé. Az operátor ezen az interface modulon keresztül tudja kiadni az utasításokat –tanúsítvány és kapcsolódó igénylői adatok kezelésével kapcsolatban – a CA-modulnak.

pontosabban itt arról van szó, hogy a tanúsítványkiadó megbízhat fejlesztőt a szoftver, ill. rendszere létrehozására


45

−

− −

−

−

−

−

RA modul: Az RA-k feladata a rendszerben az igényelt tanúsítványokhoz tartozó igénylői adatok hitelesítése és az ellenőrzött adatok továbbítása a CA felé, amely a tényleges tanúsítvány készítését végzi. Ezentúl az RA-k tesznek javaslatot adott tanúsítványok visszavonására. RA Operátor modul: Hasonlóan a CA Operátor modulhoz az interface-t biztosítja az RA modul és az RA operátorok között. Publikációs modul: A rendszer másik kulcsfontosságú modulja. Ez a modul felelős a tanúsítvány igények, visszavonási kérelmek fogadásáért, a kész tanúsítványok (és igény szerint privát kulcsok) kézbesítéséért, ARL és CRL listák publikálásáért, az on-line certifikáció ellenőrzésért (OCSP protokoll). Ezenfelül lehetőséget biztosíthat a felhasználók részére, hogy nyomon követhessék certifikációs kérelmük állapotát. (Alapesetben erre nincs szükség, de amennyiben a CA biztonsági politikája többlépcsős eljárást ír elő, abban az esetben ez a funkció hasznos szerepet tölthet be.) Interface modulok: web, email, VPN, LDAP, X500, XML, OCSP, CSR. Tanúsítványkérelmek fogadása: Tanúsítványkérelmeket általában vagy webes interface-en keresztül, vagy pedig CSR (tanúsítványkérelem, kötött fileformátum) file formájában kell fogadni. (Abban az esetben, ha személyesen keresik fel az RA-t szintén a webes interface használata célszerű.) Tanúsítványok és visszavonások publikálása: A tanúsítványok eljuttatása az igénylőhöz legegyszerűbben emailen vagy weben keresztüli letöltéssel történik. (Privát kulcs igénylés esetén vagy védett kommunikációs vonalon keresztüli letöltés, vagy a személyes átvétel jöhet szóba.) A CRL listák frissítése on-line történik a CA modul által. A listákat a CRL szétosztási ponton keresztül érhetik el az érdekeltek. On-line tanúsítvány-ellenőrzés: Nagy értékű, nagy biztonságot követelő tranzakciók esetén általános elvárás a tranzakcióban részt vevő felek tanúsítványainak on-line ellenőrzése. Erre ad lehetőséget az OCSP protokoll, amely szintén a rendszer egyik kiemelten fontos eleme. Szükség van még honlap üzemeltetésére, ahol a szolgáltató közzéteszi tájékoztatóit, szolgáltatási szabályzatait, általános szerződési feltételeit, RA partnereinek listáját és elérhetőségét.

Tanúsítványkiadó rendszernél az auditálhatóság és archiválás különösen fontos feladat. A rendszer eleve auditálhatóra tervezendő, minden tanúsítvánnyal kapcsolatos eseményről hiteles archívumnak kell rendelkezésre állnia. Az archívumok függetlenül több példányban a szolgáltatási szabályzatnak megfelelően megőrzendők. A sajátosságokból következően önálló biztonsági rendszerterv és (felhasználói, üzemeltetői és fejlesztői) dokumentáció készítendő. A szoftver és a teljes rendszer tesztelendő és auditálandó. RA modul RA, ill. RA operátor modul terén az RA-k kezét nem érdemes megkötni. Az RA-k a tanúsítvány és visszavonási kéréseket specifikált formátumban és kommunikációs protokollon keresztül juttatják el a CA-hoz. Elvben web-, email-, XML vagy más interface is alkalmazható erre. Webinterface nem olyan kézenfekvő, mint a Hureg esetén. Az RA-k szabadon biztosíthatnak eszközöket kulcsgenerálásra, tanúsítvány- és visszavonási kérelmek kezelésére. A tanúsítvány kiadását és visszavonását mindig a CA végzi. Tanúsítvány érvényességéről is hiteles (online) információt a CA biztosít. A rendszer felépítéséhez és működtetéséhez szükséges termékek Webszerver (pl. Apache) − Java applikációs szerver (Jrun, TomCat, Websphere stb.) − Java futtatórendszer (Sun Java2 1.4) − Java kriptográfiai csomag (ld. később) − Adatbázis-kezelő (l. később) Alkalmazható adatbázis-kezelők A rendszer adatbázis-kezelést megvalósító adatbázis-szerverrel szembeni elvárás elsősorban a működési biztonság és a replikáció készítés. Ezen elvárások teljesülése a sebesség rovására is történhetnek, hiszen egy CA tevékenysége – néhány részlettől eltekintve -, akár off-line tevékenységnek is nevezhető, teljesítményigénye minimális hardver eszközökkel kielégíthető.


46

Nem szükséges még a tranzakciókezelés sem, ugyanis abban a néhány feladatban, ahol ez szükséges, ott a CA-szoftver biztosítja ezt. A replikáció szükségessége megoldásfüggő, kétségkívül azonban, ha két független helyen online rendelkezésre állást kell biztosítani, akkor ennek megvalósítására replikált adatbázisok alkalmazása kézenfekvő. A kereskedelemben kapható neves adatbázis-kezelők (DB2, MS SQL, Oracle stb.) megfelelőek, azonban a rendszer akár ingyenes adatbázis-kezelőre is épülhet (pl. mySQL, mely tranzakciókezelésre és replikák kezelésére is alkalmas), mivel a kitűzött elvárásoknak több ingyenes adatbázis-kezelő is megfelel. Kétségkívül, a nagy gyártók termékei mellett az áruktól eltekintve több érv szól. Az adatbázisok, adatbázis-kiszolgálók izolálandók a végfelhasználók és az RA-k, ill. az Internet felől. A végfelhasználók az Interneten keresztül számukra csak olvasható replikákkal érintkeznek, sőt maguk a replikák elérése is, pl. kizárólag biztonságos RMI interface-en keresztül történhet. A két vagy több off-site kiszolgálóhely egymással VPN kapcsolatban lehet, de a VPN mellett más szintű védelem is szükséges (kétfaktoros védelem), mely elvben biztonságot (titkosságot és integritást) nyújt VPN nélkül is. A rendelkezésre állás érdekében akár több off-site hely is megkövetelhető. A kereskedelemben beszerezhető kriptográfiai modulok áttekintése Sun Java J2 SDK 1.4: Az alap csomag az 1.4 verziótól kezdve tartalmazza a JCE csomagot (1.3-as verzióig ez külön letölthető volt), amely lehetővé teszi a kriptográfiai feladatok megoldását. Nem biztosít azonban lehetőséget tanúsítványok, CRL-ek direkt létrehozására, OCSP protokoll támogatására, ezeket külön az alapoktól felépítve, a rendelkezésre álló algoritmusokat felhasználva lehet megvalósítani. Cryptix: Ingyenes kriptoszoftver, de nem teljesen kompatibilis a Java JCE elvárásokkal. Szintén problémákat vet fel a specifikusan CA problémák megoldása is, a specifikus feladatokat szintén az alapoktól, komoly munkaerő-befektetéssel lehet csak elkészíteni. (website: www.cryptix.org) Csak a teljesség igénye miatt említettük a Cpyptixet. IAIK JCE: A kereskedelemben kapható egyik legkiforrottabb kriptográfiai szoftvercsomag, a Grazi Műszaki Egyetem (Ausztria) terméke. A termék 1997-től jelentős sikerekkel szerepel a kriptográfiai piacon, mind magas minősége, mind amiatt, hogy európai fejlesztés révén nem vonatkoznak rá az Egyesült Államok export törvényei. Fejlesztése folyamatos. Különböző célokra, különböző változatokban kapható. Az IAIK JCE a Sun JCE működését veszi át, és jelentősen bővíti mind az algoritmusok, mind az egyéb modulok körét, valamint a kódolás erősségét. Az IAIK Silk elsősorban az SSL alapú felhasználást célozza meg. Az IAIK SMIME a biztonságos levelezést támogatja. A rendszernek létezik egy Micro verziója is, amelyek segítségével az egyéb hardver eszközökön válik elérhetővé az erős kriptográfia (a Java Micro Edition rendszerrel együtt). Nem elsősorban Certificate Authority-k létrehozására tervezték, de rendelkezésre áll az összes szükséges modul, amelyek segítségével hatékonyan előállítható a megfelelő célszoftver. Gyakorlatilag bármely a kriptográfia fogalomkörébe tartozó feladat megoldható vele. A fejlesztéshez developer licenc szükséges (1 licenc 500 EURO), valamint a futtatáshoz runtime licenc szükséges (10 db runtime licenc 100 EURO). Phaos J/CA: A Phaos cég (Nagy Britannia) az IAIK termékkel megközelítőleg egy időben jelent meg a piacon. Első termékei egyike az SSLava, egy erős SSL megoldás volt, amely az USA exporttörvények miatti piaci hiányt kihasználva az osztrák konkurensnél jóval magasabb áron került forgalomba. Java területen a Phaos is követte a Sun által definiált „szabványokat” (JCE), megoldáskészlete nagyjából megegyezik az IAIK készlettel. Emellett a Phaos cég speciálisan a Certifikációs Authority-k alapigényeinek kielégítésére is tervezett egy Java implementációt. Nem a JCE integráns része, saját metódusokkal rendelkezik, de ez semmiben nem csökkenti használhatóságát. Az IAIK készlettel összevetve valamivel egyszerűbben – de nem döntően egyszerűbben – lehet egy CA szükségleteinek megfelelő szoftvert felépíteni a segítségével.


47

Licenceléséhez szükséges egy developer licenc (3.000 EURO/developer) és egy deployment licence szerverenként (3.000 EURO). Baltimore Keytools Pro: KeyTools Pro egy felsőszintű API, amely lehetővé teszi a gyors alkalmazásfejlesztést. (A minőséget a Baltimore előbbiekben ismertetett terméke, valamint a cég vezető szerepe is megerősíti.) Jellemzők: − − − − − − − −

−

Kriptográfiai és tanúsítványtámogatás Tanúsítványkérelem és letöltés CA-tól LDAP támogatás Tanúsítványvisszavonás (CRL) ellenőrzés Központi policy kezelés Smartcard támogatás Additional Certificate Authority transporters, OCSP támogatás CRL distribution point támogatás.

Megjegyzés: A KeyTools Pro nemcsak Java, hanem C verzióban is elérhető. Összehasonlító táblázat:

JCE kompatibilitás X509v3 kezelés X509v3 létrehozás CRL kezelés CRL létrehozás CRLDP támogatás LDAP támogatás OCSP támogatás

Ár (fejlesztés+1 szerver)

JDK 1.4 igen

Cryptix nem teljes

IAIK igen

Phaos J/CA nem

Baltimore n.a.

igen

igen

igen

igen

igen

nem

nem

igen

igen

igen

igen

igen

igen

igen

igen

nem

nem

igen

igen

igen

nem

nem

igen

igen

igen

igen

igen

igen

igen

igen

nem

nem

igen

igen

igen

ingyenes

ingyenes

600 EUR

6.000 EUR

n.a.

Megjegyzés: LDAP támogatás (interface) magában a Java disztribúcióban elérhető. Microsoft CryptoAPI A Java elsőszámú konkurensével történő összehasonlítás végett még megemlítjük az MS CryptoAPIt. Jelenleg a 2.0-s verziójában járó Microsoft CryptoAPI elsősorban a Microsoft alapokon, C/C++ nyelven fejlesztők körében használható fel. Az API biztosítja a szimmetrikus és aszimmetrikus codecek használatát, a tanúsítvány alapú bejelentkezést, valamint tanúsítvány tárolók menedzselését. A CryptoAPI Windows NT, Windows 2000 és Windows XP operációs rendszereken használható. Használata során erős korlátozás a platformfüggésen kívül az, hogy a tanúsítvány-kezelés egy jelentős részét szintén az alapoktól kell programozási munkával felépíteni. Létrehozási és üzemeltetési költségek Javaslatunk szerint a CA működését minimum két egymástól fizikailag különböző helyen teljes funkcionalitásban kell biztosítani, az adatcserét köztük 99,9 % rendelkezésre állással biztosítva. Egyik site kiesése esetén a másik teljes funkcionalitásban kell, hogy működjék, mindkét helyen minden adatnak rendelkezésre kell állnia, egyik site-ot érintő meghibásodás esetén is más off-site archiválásról és mentésről kell gondoskodni. A CA kiszolgálóhely lehet egyszerre online ill. egyik online a másik standby.


48

Elvben – költség okokból – egy kiszolgáló hely és egy vagy több off-site archív/backup hellyel is működtethető rendszer. Hardver, operációs rendszer, adatbázis-kezelő, kommunikációs (pl. VPN), backup és archiváló szoftverek összköltsége 10-30 MFt között számolható reálisan. Ilyen eszközök bérelhetők is, ill. részben vagy teljesen outsourcing is választható. Saját fejlesztésű szoftver mellett komoly érv, hogy a hardver és más eszköz erőforrások előre megválaszthatók, tervezhetők. A fejlesztés költségeit és idejét az ISzT számára talán legérzékletesebben a HUREG rendszerrel öszszehasonlítva lehetne megtenni: − − − −

−

A HUREG és CA létrehozása teljes rendszert, ill. a szoftverek fejlesztését tekintve nagyságrendileg nem különböző mértékű feladat, de a CA sokkal összetettebb, több modulból álló rendszer, mely más biztonsági feltételeknek kell, hogy eleget tegyen. A CA során speciális feladatok sora merül fel, így PKI létrehozásra, auditálható rendszer megalkotása, továbbá a redundáns kiszolgálás megteremtése is összetettebb feladat. A tanúsítványok nem egyfélék, mint a domének, hanem többféle tanúsítvány is lehetséges. Számos jogszabályi előírásnak kell eleget tenni. Ugyanakkor a HUREG-gel szemben számos kérdésben egyszerűbb is a feladat, pl. tanúsítványok nem változhatnak, csak lejárhatnak, meghosszabbításukra, ill. visszavonásukra kerülhet sor.

A fejlesztés költségeit 15-30 MFt közöttire becsüljük. A fejlesztésre szóló árajánlatok ettől azonban még eltérőek lehetnek. A műszaki üzemeltetés emberi erőforrás igényénél a 7*24 órás rendelkezésre állás biztosításával számolni kell, valamint azzal, hogy egy ember önállóan tanúsítványt érintő változtatást nem hajthat végre. Az egyéb költségek (döntés előkészítés, tendereztetés, szabályzatok, szerződések elkészítése, hatósági költségek, adminisztráció, audit stb.6) nem függnek attól, hogy sajátfejlesztésű rendszert vagy kész megoldást választunk. Összességében ezen költségekkel nem számolva 30–80 MFt-os induló és 10–30 MFt éves költséggel számolhatunk (az induló költségekben az első éves üzemeltetési költségekkel már számoltunk). Induló költség esetén inkább a nagyobb értékhez közelivel ajánlunk számolni. Saját fejlesztés esetén először is specifikációt (rendszertervet) kell készíteni, majd ennek megvalósítására írható ki tender. Véleményünk szerint első körben az egyedi fejlesztés és a kész termékekre épülő megoldások együtt versenyeztetendők. Előnyök/hátrányok Saját fejlesztés számos előnnyel és hátránnyal járhat. A kereskedelmi termékek és megoldásszállítók árai tipikusan tanúsítványszám függőek. − Viszonylag kis tanúsítványszámot (10.000 db) számolva is a kereskedelmi megoldások áraival versenyképesen fejleszthető saját megoldás. − A saját megoldás korlátlanul testreszabható, a kereskedelmi megoldások mellett is elkerülhetetlenek lehetnek saját fejlesztések. − A saját megoldások platform és adatbázis-kezelő függetlenek, ill. ezeket a létrehozó maga választhatja meg. Ez a szoftver ára mellett igen lényeges költségtényező. − A saját fejlesztésű szoftver forráskóddal együtt elérhető. − − A kereskedelmi megoldásokkal szemben egy saját fejlesztés nemzetközi akkreditációja nehézségekbe ütközhet. − A kereskedelmi termékek azonnal elérhetőek (elvben 3 hónapon belül rendszerbe állíthatók), egy saját fejlesztés minimálisan 3-6 hónap alatt fejleszthető ki (béta teszteléssel7 még nem is számolva), rendszerbe állítással együtt azonban 6-12 hónappal számolhatunk. Ugyanakkor az egyes RA-k a rendszerrel már korábban, a tényleges használatba vétel előtt is ismerkedhetnek. Az RA-k a specifikációk ismeretében felkészülhetnek a saját szolgáltatásukra. Ezekből következően a saját fejlesztés késleltetése már nem is olyan jelentős. 6

Az ISzT, ill. ISzT Kht. bizonyos infrastruktúrája, pl. bizonyos műszaki feltételek, iroda, Választott Bíróság felhasználható (ilyen létrehozása egyébként nem követelmény), bizonyos mértékig a személyi feltételek is adottak. Béta tesztelésre a rendszer bevezethető a domén regisztrátorok és Nyilvántartó kapcsolatában. Kifejezetten szerencsés, hogy az ISzT tagság és regisztrátorok szakmailag felkészült tesztelőként segíthetik a fejlesztést, ill. a rendszer bevezetését. 7


49

−

A kereskedelmi megoldások eleve teszteltebbek, az ismertetett termékek kiforrottak, komoly háttérrel és referenciákkal rendelkeznek. Kriptográfiában jártas hazai fejlesztők vannak, de CA létrehozásával, referenciával rendelkező vélhetően nincs.

Árösszevetés esetén a késztermék adaptációjának, bevezetésének költségével is számolni kell, nem csupán a licenc és támogatás díjával.


50

További termékek A következőkben néhány fontosabb terméket röviden ismertetünk. − − −

−

Baltimore UniCert Entrust Authority™ Enrollment Server for Web Netscape Certificate Management System Microsoft Certificate Server

Baltimore Unicert A kereskedelmi forgalomban beszerezhető szoftverrendszerek közül egyik legsokoldalúbb és legkiforrottabb a Baltimore Unicert. Magyar forgalmazó: KFKI Icon. A Baltimore nem csak komplett CA megoldást kínál, hanem fejlesztőeszközöket is, KeyTools Pro egy felsőszintű API, mely Java, ill. C alapú fejlesztést tesz lehetővé, CA létrehozását is támogatva. Ezen az alkalmazáson keresztül áttekinthetjük egy minden igényt kielégítő hitelesítő rendszer elemeit, a többi kereskedelmi szoftvert rövidebben tárgyaljuk. Érdemes összevetni az előző fejezetben általunk felvázoltakat, ill. a Baltimore Unicert alábbi ismertetését. A rendszer három nagyobb alkalmazás osztályból áll a Core-Technology, amely az egész rendszer alapját képezi, és ennek bővítményeiből, az Advanced Technology és az Extended Technology alkalmazásokból. A rendszer egyes elemeit – akár egy alkalmazásosztályon belül is – lehetőség van külön szerverekre telepíteni, különböző – az egyes moduloknál jelölt – operációs rendszerek alá. Core Technology Elemei: − − − −

−

CA-modul CAOperator modul RA modul RAOperátor mpodul Gateway

CA modul Az egész PKI struktúra központja. Feladatai: − − − − −

A megerősített tanúsítvány kérelmek és visszavonások fogadása, tanúsítványok és megerősítések visszaküldése Ha a policy lehetővé teszi, akkor a végfelhasználó privát kulcsának tárolása az Archive Serveren és igény szerinti kiszolgálása a tulajdonos felé Tanúsítványok aláírása (kereszthitelesítéseknél más CA-k felé is.) CRL (Certificate Revocation List), és ARL (Authority Revocation List) kezelése és közzététele CRLDP-n (CRL Distribution Point) keresztül Tanúsítványok, CRL-ek,ARL-ek publikálása LDAP és/vagy X500 directory szerviznek. CRL-ek publikálása OCSP protokollon keresztül (OCSP-On-line Certification Status Protocol)

Jellemzők: − − − − −

operációs rendszer: Solaris, HP-UX, MS Windows NT 4.0 és 2000 Unicode támogatás smartcard és hardware védelmi modul LDAP és DAP támogatás Támogatott kulcspárok: RSA, DSA, Elliptic Curve DSA (EC DSA)


51

Certificate Authority Operator (CAO) A teljes rendszer adminisztrációját végző modul. Feladatai: − −

−

Policy létrehozás és policy push Visszavonások engedélyezése Kommunikáció a CA és a rendszer között

Registration Authority Az RA-k a teljes PKI rendszert regisztrációs doménekre osztják. Minden regisztrációs domén egy külön struktúra, amely a CA-hoz kapcsolódik.A modul futtatási megkötése: MS Windows 2000 és NT 4.0 operációs rendszeren fut. Registration Authority Operator A fő funkciója, hogy a végfelhasználóktól érkező tanúsítvány kérelmeket megerősítse és a CA felé továbbítsa. Ezenfelül, visszavonási listákat is küldhet a CA felé. Gateway A UniCert Gateway három modulra oszlik: web gateway, email gateway és VPN gateway. A gateway funkciója, hogy fogadja a beérkező certifikációs kérelmeket, valamin továbbítsa a tanúsítványokat és információs üzeneteket. A Gateway a végfelhasználó és az RA-k közti kapcsolatot biztosítja. A web gateway a certifikációs kérelmeket http protokollon fogadja. A kész tanúsítványt file-ba írja, majd email üzenetet küld az igénylőnek, amelyben megküldi a tanúsítvány URL-ét. Ezen felül a felhasználóktól tanúsítvány visszavonási kérelmet is elfogad. Az email gateway PKCS#10 certifikációs kérelmeket fogad POP3 protokollon, válaszként információs üzeneteket és a kész certifikációt küldi PKCS#7 formátumban. A VPN gateway a web gateway-jel megegyező funkciókat lát el. Ezen felül implementálja a SCEP (Simple Certificate Enrolment Protocol, Cisco) protokollt, így a kérelmek és a certifikációk kézbesítése ezen át is történhet. A VP gateway a választástól függően DER,PEM vagy PKCS#7 kódolással kézbesíti a tanúsítványokat. Advanced Technology: Elemei: − − −

−

Key Archive Server: A végfelhasználók privát kulcsának biztonságos tárolását és visszaállítását végzi, így elkerülhetőek a kulcsvesztésből származó költségnövekedések. Advanced Registration Module (ARM): A regisztrációs rendszer beillesztését szolgáló modul a meglévő adatbázis, workflow és biztonsági környezetbe. Advanced Publishing Modul (APM): A szükséges adatok publikációját végzi különböző rendszereken keresztül. Teljes támogatást biztosít a MS Active Directory használatához. Alkalmazásával –mivel a publikációs feladatokat átvállalja- megnő a CA-k teljesítménye. WebRAO: Ez a modul az operátorok számára lehetővé teszi, hogy webes interface-n keresztül erősítsék meg a certifikációs kérelmeket.

Extended Technology: Elemei: − −

Timestamp server: Feladata elektronikus tranzakciók ellátása hitelesített időadatokkal (a Timestamp egy digitálisan aláírt file, X509 szerint). Az előzőekben áttekintett modulokkal teljes mértékben integrálható. Roaming: A certifikáció tulajdonosoknak biztosítja a lehetőséget, hogy tranzakciókat gyakorlatilag bármely böngészőről hitelesíteni tudjanak, anélkül, hogy hardware elemeket kellene használniuk.


52

Entrust Authority™ Enrollment Server for Web Az Enrollment server certifikációk kezelését és kiadását valósítja meg. A szoftver funkcióit a cég egy másik termékével, az Entrust Authority™ Security Manager 5.0 szoftverrel együtt képes ellátni. Jellemzői: − − − − − − − − − −

−

Certifikáció műveletek: kiadás, frissítés, felfüggesztés, visszavonás, menedzselés leghosszabb tanúsítvány élettartam 60 hónap (nincs éves frissítési díj) Skálázhatóság: alapkonfiguráció 500.000 tanúsítvány, többszörös CA konfigurációban több millió tanúsítvány kezeléséig Támogatja a kulcs helyreállítást hibásan rejtjelezett kulcsok esetében Egyszerű vagy hierarchikusan tagolt hitelesítő hatóság (CA) felépítése CA és alá tartozó korlátlan számú RA létrehozása Testreszabható policy template-ek Integrálhatóság Tanúsítványok és CRL-ek szétosztása LDAP szervizeknek Központi egyszerűsített webalapú menedzselés (userek, szerepek, csoportok) OCSP protokoll támogatása.

Entrust Authority™ Security Manager 5. 1 (régebben Entrust/PKI) rendszerkövetelményei: Operációs rendszer: Microsoft® Windows NT® 4.0 − Microsoft® Windows® 2000 Server és Advanced Server − Solaris 7 − HP®-UX 11.0 − AIX 4.3.3 Adatbázis szerver: Informix Database (v 7.23) − Oracle 8i Database website: http://www.entrust.com Netscape Certificate Management System A Netscape cég terméke szervezeti PKI infrastruktúra felépítésére nyújt lehetőséget, X509v3 formájú tanúsítványok kezelésével. A szoftver mind Windows, mind Solaris platformon üzemeltethető. Főbb jellemzők: − − −

−

− − − −

Hitelesítő műveletek: kiadás, frissítés, felfüggesztés, visszavonás, menedzselés (szimpla és duálkulcsos certifikációknál is). Skálázhatóság: több millió tanúsítvány kezeléséig. A rendszer igen jól skálázható (a vizsgált rendszerek közül talán a legjobb ezen a téren), anélkül is, hogy több CA-t tartalmazó hierarchikus rendszerfelépítést követnénk. Támogatja a kulcs helyreállítást hibásan rejtjelezett kulcsok esetében. A kulcshelyreállítás lehetősége a kulcsvesztésből származó költségek minimalizálását hivatott szolgálni. A rendszer erősen és többszörösen titkosítva tartalmazza a certifikációkhoz tartozó privát kulcsokat is, amelyek kulcsvesztés esetén, a megfelelő hitelesítési lépéseket betartva lehetővé teszi, hogy a tanúsítvány tulajdonosa újra kézhez kapja azokat. Egyszerű vagy hierarchikusan tagolt hitelesítő hatóság (CA) felépítése. A rendszer fa szerkezetben gyakorlatilag tetszőleges felépítésű struktúra megvalósítását teszi lehetővé. Ebben a struktúrában sem a CA-k sem az RA-k száma, sem a köztük lévő kapcsolat nincs korlátozva, azaz elméletben bármely környezethez adaptálni lehet a rendszert. (Ennek a lehetőségnek elsősorban nagyvállalati illetve vállalatcsoporti környezetben van jelentősége, ahol elméletileg, akár bármely szervezeti egység lehet CA vagy RA szerepkörben.) Testreszabható policy templatek. Integrálhatóság. − Integrálható a Netscape Directory Serverrel Certifikációk és CRL-ek szétosztása LDAP szervizeknek Integrálható szoftverekkel a publikus programozási interfaceken keresztül


53

−

−

Központi egyszerűsített webalapú menedzselés. A rendszer teljes menedzselése elvégezhető egy webalapú interface-n keresztül. Ezen át módosíthatóak a felhasználók, a csoportok, a szerepkörök. OCSP protokoll támogatása.

Rendszerkövetelmények: Sun Solaris 8, Sun Ultra-10 vagy gyorsabb MS Windows NT 4.0 vagy 2000 Server, Pentium-II 350 vagy gyorsabb website: http://www.netscape.com Microsoft Certificate Server A teljesség kedvéért említjük meg. Nyilvánvaló példa az MS CrpytoAPI alkalmazására, zárt 'vállalati' célú megoldást tesz lehetővé. Nem nyilvános CA létrehozására szolgáló termék. Az MS Certificate Server a NT operációs rendszerrel együtt elérhető, kiválóan alkalmas vállalati (zárt körű) alkalmazásra. Az MS CpyptoAPI, ill. MS CA előnye, hogy NT házirendekkel (policy) együtt alkalmazható. Hasonló vállalati megoldásokra alkalmas terméke számos gyártónak van (Novell, IBM, Entegrity stb.). Egyéb speciális CA megoldások, pl. Intel (Intel NetstructureTM Certificate Authority Pro). További termékek Néhány további terméket is megemlítünk: RSA Keon termékcsalád, RSA Keon CA − (Korábban az Xcert International, Inc terméke, mely céget az RSA felvásárolta) − http://www.rsasecurity.com/products/keon/index.html, http://www.rsasecurity.com/products/keon/datasheets/dskeoncertificateauth.html) Hazai forgalmazója a KFKI Icon. − iPlanet Certificate Management System − http://www.iplanet.com/products/iplanet_certificate/home_certificate.html, hazai forgalmazó szintén a KFKI Icon. − EuroPKI (L. ismertetésünket: európai szolgáltatók) http://www.europki.org


54

Felhasználók, erőforrásigény, bevételek és költségek Felhasználói kör A felhasználási lehetőségeket a hitelesítő szolgáltatásról szóló fejezetünkben már részletesen tárgyaltuk. Itt a felhasználói kört próbáljuk számba venni. A létrehozandó CA induláskor zárt szolgáltatóként indulhat, mintegy próbaüzemként. A zárt szolgáltatás felhasználói a regisztrátorok lehetnek. Nyílt fokozott biztonságú szolgáltatóként történő piacra lépés után általános hitelesítő szolgáltatót célszerű létrehozni, ti. célszolgáltató (pl. csak szerver tanúsítványok kiadása nem lehet rentábilis). A felhasználói igényeknél, ill. felhasználási lehetőségeknél nem csak az aláírás hitelesítést, de a titkosítási célú felhasználást is figyelembe kell venni. Ugyanaz a kulcs nem használható fel titkosításra és aláírás hitelesítésre. A domén regisztrációval kapcsolatban természetes felhasználás a domén igények digitális aláírással történő elfogadása. Az egyes regisztrátorok tanúsítványokat adhatnak ki igénylőknek, mely tanúsítványokkal érkező kéréseket a regisztrátorok általánosan elfogadhatják. Lehetőség nyílik így arra, hogy a regisztrátorok online (pl. webalapú) regisztrációt vezessenek be, vagy viszonteladóik hozzájuk egyszerűen elektronikus formában juttassák el a végfelhasználók által digitálisan aláírt igényléseket. Domén igényléshez akár egyedi tanúsítványtípus is bevezethető. A domén regisztrációnál történő elektronikus aláíráshasználat nem része tanulmányunknak. Számos kérdés tisztázandó, nyilván a szokásos ISzT mechanizmusok keretében. Eldöntendő milyen tanúsítvánnyal fogadható el aláírás, kinek az aláírása fogadható el az igénylő nevében, ill. ennek megfelelően, a regisztrációs szabályozás és eljárási rend több pontban változtatandó. A szerver tanúsítványok kiadása kézenfekvő, lévén az ISzT tagjai, ill. domén regisztrátorok, Internet szolgáltatók, maguk és ügyfeleik üzemeltetik a hazai webszerverek nagyrészét. Ezen túlmenően a jelenlegi tanúsítványigények – melyek nem zártkörű felhasználásra szólnak – tipikusan az Internethez kötődnek. Tanúsítványtípusok széles választékát javasoljuk bevezetni. Felhasználó lehet bármely (cselekvőképes) magánszemély, bármely vállalkozó, gazdasági és más társaság, szervezet. Szervereken kívül más eszközökhöz is szükséges, vagy kívánatos lehet digitális aláírás alkalmazása, sőt potenciálisan az eszközök között a webszerverek marginális szerepet játszanak. Minősített igényeket nem elégíthet ki nem minősített szolgáltató. Idővel szinte mindenki fog digitális aláírást használni, gyakran úgy, hogy maga sem tud róla, ill. a használat során ezzel nem is szembesül. Nem csak magyar, de Európai Unió felhasználóival, ill. az Unión kívüli felhasználókkal is számolni kell (akár csak külföldi tanúsítványkiadók belföldi piaci szerepével). Általános az egyetértés, hogy senki sem tudja megjósolni az elektronikus aláírás elterjedésének ütemét és használatának mértékét. Az elektronikus aláírás használata számos buktatót rejt, jelenleg ezek hatása sem felbecsülhető.

Bevételek és kiadások A bevételek nem igazán tervezhetők előre két okból sem, az egyik az, hogy a digitális aláírás használatának elterjedése, ennek üteme, mértéke ma még csak nem is becsülhető, a másik, hogy a bevétel elsősorban a franchise partnerek üzleti működésétől függ. A létrehozandó tanúsítványkiadó bevétele, a franchise partnerek érdekében is főleg azok forgalmazásától függő (tanúsítványonkénti, észszerűen degresszív díjazású) és nem fix egyszeri vagy éves díjakra alapozandó. Mindazonáltal egyszeri díj és éves díjak a partnerré válás természetes feltételei. A domén regisztrációnál a Nyilvántartó kiadásai bizonyára sokkal kevésbé függenek a delegált domének számától, mint egy tanúsítványkiadóé a kiadott tanúsítványok számától. Tanúsítványonként kell számolni licenc, biztosítási és más költségekkel. A tanúsítványkiadónak háromféle költséggel kell számolni a költségek jelentkezésétől függően: 1. beruházási költség, 2. folyó (éves) üzemi költségek, © EGERSZEGI CONSULTING – INTEGRITY, 2002

55

3. tanúsítványonkénti költségek. A költségek között kevés jól ismert költség van, ilyenek, pl. a szakhatóság felé fizetendő díjak. Azonban ezek a díjak is változhatnak jogszabályváltozásokkal. A költségek más része becsülhető, más részük árajánlatkérések alapján becsülhető. Tipikusan kétfordulós tenderek szolgáltathatnak megoldást szállítók, szolgáltatók, sőt megoldások kiválasztására. Az első fordulóban főként megoldások szűkítendők (eldöntendő, hogy egyedi fejlesztés vagy késztermék vásárlása és bevezetése választandó), a másodikban a szállítók, ill. szolgáltatók választandók ki. Eldöntendő, hogy teljes megoldás szállítását várja el a Megrendelő, esetleg teljesen erőforráskihelyezést alkalmaz, vagy többé-kevésbe maga építi fel és üzemelteti rendszerét. Az erőforrás-kihelyezésről kell először dönteni, azaz, hogy milyen formában és mértékben kívánunk alkalmazni. A következő főbb feladatok merülnek fel: − − −

−

a létrehozás irányítási és szervezési feladatok; a tanúsítványkiadó irányítása, vezetése, adminisztráció és elszámolás az RA partnerekkel; infrastruktúra üzemeltetése; tanúsítványkezelés.

Feltételezzük, hogy a CA a végfelhasználók felé minimális szolgáltatást nyújt (visszavonási listák publikálása, online tanúsítványellenőrzés, szolgáltatási szabályzatok és szerződések publikálása), a végfelhasználókkal tipikusan az RA-kon keresztül érintkezik (saját RA-t is üzemeltet, de csak az RA partnerek részére). Ebben a rendszer hasonló a domén franchise rendszerrel, azonban a CA közvetlenül szerződéses kapcsolatba kerül a végfelhasználókkal. A CA nem végez marketing tevékenységet, nem nyújt támogatást végfelhasználóknak, nem ad el közvetlenül tanúsítványt. Fontos hangsúlyozni, hogy a végfelhasználókkal a CA, a Nyilvántartóval ellentétben közvetlen szerződésben áll, de a domén regisztrációhoz hasonlóan, a végfelhasználók a franchise partnereken (RAk) keresztül állnak kapcsolatban a CA-val. Így a CA által ügyfélszolgálati iroda, helpdesk és hasonlóak szintén nem tartandók fel. Az alábbiakban a beruházási, éves és tanúsítványonkénti költségeket tárgyaljuk. Fontos megjegyeznünk, hogy a költségek fajtái és mértékei a Létrehozó döntéseitől is függnek (másféle költségek vannak, ha nagymértékű erőforrás-kihelyezést alkalmazunk és mások, ha minimálisat, mások a költségek, ha az infrastruktúrát béreljük és mások, ha megvásároljuk). Beruházási kiadások, erőforrásigény Itt tágabb értelemben minden kiadást ide sorolunk, ami csak egy fokozott biztonságú szolgáltatóként üzemelő tanúsítványkiadó létrehozásánál felmerül. A következő féle kiadások merülnek fel: − − − − − − − −

Döntés előkészítés, tervezés, tendereztetés Óvadék és szakhatósági díjak (3,4 – 3,6 MFt) Szabályzatok és szerződési feltételek megalkotása Adminisztráció és vezetés infrastruktúrájának biztosítása (iroda, az ISzT rendelkezik már megfelelő irodával, ügyfélszolgálati iroda nem szükséges) Infrastrukturális feltételek biztosítása (helyiség, távközlési hálózat, szerverterem, stb.) – fontos megjegyezni, hogy itt bizonyára a bérlet kézenfekvőbb, mint az önálló beruházás. PKI infrastruktúra (l. a két gyártófüggő és egy nyílt szoftver alapú megoldást) Tájékoztató website létrehozása Egyéb kiadások

A PKI infrastruktúra esetén −

−

a PKI szoftverek, ill. a PKI szoftverek működtetéséhez szükséges hardver és szoftver eszközök (számítógépek, operációs rendszerek, adatbázis-kezelők stb.) számolandók.

Marketing kiadást nem említettünk, de akár csak a doménliberalizációnál, itt is egy – az indulást megelőző – központi reklámkampány kívánatos lehet. E marketing azután alkalmazható, miután az RA-k megindíthatták a szolgáltatásaikat.


56

Éves kiadások − − − − − − − − − − − −

Munkaerő költségek Díjak szakhatóságoknak Szakértői kiadások Jogi kiadások (szabályzatok, szerződések módosítása, jogviták) Audit költsége Adminisztráció infrastruktúrájának biztosítása (irodabérlet) Kiszolgáló infrastruktúra bérlete PKI infrastruktúra (a Létrehozó ezt megvásárolhatja, maga hozhatja létre vagy bérelheti, ill. átmeneti megoldások is lehetségesek) Éves szoftver licenc és support díjak Support díjak (megoldásszállító/k/) Tájékoztató website fenntartása Egyéb kiadások

A munkaerőköltségnél számolni kell ún. bizalmi pozíciókkal. Így pl. szolgáltatói tanúsítvány kezelését csak két független bizalmi pozíciót betöltő személy végezheti. Természetesen főállás ehhez szükségtelen. Egyéb költségek Tanúsítványonkénti költségként tipikusan a PKI szoftver licenc díja merülhet fel, mint legjelentősebb tétel. Látható a gyártói megoldások során, hogy ez a díj igen jelentős lehet. E díj az RA-kon keresztül bizonyos mértékben és formában a végfelhasználókra hárítható. Tanúsítványonként más díjak is változhatnak, pl. jogviták száma is korrelálhat a kiadott és visszavont tanúsítványok számától, de az audit költségek is növekedhetnek a tanúsítványszámmal. Tervezhetőség Igazából csak a szakhatóságoknak fizetett egyszeri és éves díj tekinthető jól ismertnek, de még e díjak is változhatnak jogszabályok változásával. Minden más kiadás alapvetően tendereztetés során dőlhet el. Magunk és mások becslései során mindenképpen 30-40 millió Forint feletti kiadás várható fokozott biztonságú szolgáltató létrehozása esetén (az újonnan indult tanúsítványkiadók, azaz a GIRO és Matáv nagyobb nagyságrendű kiadással hozta létre szolgáltatását). Egyes PKI megoldások esetén akár már évi 10. 000 tanúsítványkiadást végző szolgáltató akár dupla kiadással is számolhat csupán a szoftverlicencek árai miatt, melyek tanúsítványszám függőek. Éves szinten jóval 10 millió feletti kiadással kell számolni. Az induló és első éves kiadásokat 50-60 millió Forint alatt tartani igen nehéz lehet, de a megoldások ésszerű megválasztásával bizonyára lehetséges. Bevételek A CA tanúsítványokért díjat kér az RA partnereitől. A díj a tanúsítványok fajtái szerint változnak (a tanúsítványok célja, érvényessége, a felelősségvállalás különböző lehet). Lehetnek nagyon olcsó és drága tanúsítványok. A tanúsítványokért egyszeri és éves díj kérhető, de speciális esetekben más díjak is számíthatók. A CA az RA-k felé egyszeri és éves díjat is alkalmazhat. Emellett bizonyos szankcionális díjakat is alkalmazhat a CA az RA partnereivel szemben. Kötelező szolgáltatás igénybevételt is előírhat, pl. oktatásban való részvétel, vizsgadíjak, stb. Amennyiben a CA üzleti típusúan kíván működni, akkor az RA-k felé mennyiségfüggő díjakat is alkalmazhat. Emellett RA-k esetleg a CA teljes szolgáltatáspalettáját vagy annak csak egy részét (pl. egy partner esetleg csak szerver és személyes tanúsítványokat kívánhat kiadni) is kínálhatják. Átlagosan 5.000,-Ft éves tanúsítványonként végfelhasználó díjakkal (lásd még magyar és külföldi szolgáltatókról adott árainkat) és évi 10.000 előfizetéssel számolva 50 millió Ft bevétel keletkezhet. Az RA részéről várhatóan több munka és költség merül fel tanúsítványonként, mint a CA részéről. Az RA partnerek bevételei azonban, akár csak a domén regisztrációnál várhatóan nem a tanúsítványkiadásból, hanem főleg a hozzáadott szolgáltatásokból keletkeznek majd.


57

Felhasználónként egynél több kulcs számítandó (aláíró és titkosító kulcs, szerepkörök, különféle osztályokba tartozó tanúsítványok stb.). Tanúsítványra sokkal többre van szükség, mint domén névre. A tanúsítványkiadásból várható bevétel fajlagosan is magasabb, mint a domén regisztrációból. Ebből kifolyólag az évi 10.000 tanúsítvány nemigen lehet számítási alap még akkor sem, ha az ISzT-n kívül számos más tanúsítványszolgáltató tevékenykedik a piacon. Az ISzT Kht. RA partnerei kedvező feltételek mellett indulhatnak a digitális aláírási (és titkosítási) piacon. Feltehetően kevés regisztrátor képes önállóan fokozott biztonságú szolgáltatóként tanúsítványkiadói tevékenységet folytatni, még kevesebb tudná ezt nyereségesen megtenni. Ellenben egy regisztrátor az ISzT Kht. RA partnereként sokkal kisebb kockázatvállalás mellett folytathat ilyen tevékenységet. Szerver tanúsítvány, szoftver disztribúció, elektronikus levelezés és számos speciális tanúsítvány, ill. felhasználási mód kifejezetten szorosan kötődik az Internet felhasználáshoz. Elsősorban Internetes tevékenységgel foglalkozó cégek, személyek, szervezetek részéről előbb mutatkozik igény általános célú tanúsítványokra is, mint tipikusan mások részéről. Éppen ezek az ügyfelei Internet szolgáltatóknak, mely kétségkívül helyzeti előnyt teremt a szolgáltatóknak ezen az új piaci területre történő nyitásnál. A magasabb költségbecslésekkel számolva sem feltétlenül veszélyezteti a Nyilvántartót ilyen, új tevékenység indítása, hiszen bizonyos mértékű bevétellel mindenképpen lehet számolni. Fontos lenne az ISzT tagság között is felmérést végezni, hogy milyen díjakat (egyszeri, éves, tanúsítványonkénti) tartanak elfogadhatónak. Azt is fel kellene mérni, hogy a tagok mely hányada kíván ilyen tevékenységet végezni az ISzT keretein belül. Az ISzT tagok és regisztrátorok persze nem teljesen azonosak, a tagság igényei jobban felmérhetők, valamint a jelentősebb regisztrátorok tipikusan ISzT tagok.

Felelősség és felelősségvállalás Hitelesítő szolgáltató megszűnését is szigorúan szabályozzák a jogszabályok, érthetően, hiszen hitelesítő szolgáltató megszűnése komolyan veszélyezteti és sérti a tanúsítványfelhasználók érdekeit. Hitelesítő szolgáltató csak hosszútávra hozható létre, hosszútávra biztosítandó a stabil működése. Végső esetben az új tanúsítványok kiadása megszüntethető, de ez nem járhat együtt magának a hitelesítő szolgáltatónak a megszűnésével, mely végső soron csak hosszabb folyamat lehet, vagy pedig más szolgáltatónak kell átvenni ezt a tevékenységet. A hitelesítés szolgáltatás komoly erkölcsi, üzleti és jogi felelősségvállalást feltételez. RA partnereken keresztüli hitelesítés az RA partnerekkel szemben egyenszilárdságú követelményekkel jár. Egy RA nem lehet gyenge láncszem. A CA-nak az RA tevékenységére teljes felelősséget kell vállalnia a végfelhasználók felé. Az RA ugyanakkor felelősséget kell, hogy vállaljon munkájáért a CA felé, a felelősségvállalásra garanciát kell adnia. Felelősségbiztosítás kulcskérdés mind a CA-k, mind az RA-k részére. A felelősségbiztosítás megkötésében a CA támogassa az RA-kat a biztosítók tendereztetésével. Az ISzT tagjai, ill. a regisztrátorok körében nem nyerne tetszést jelentős óvadék, bankgarancia letéte. Azonban az RA tevékenységéhez mérten kézzelfogható garanciavállalásra van szükség. Az RA-k tevékenységét ellenőrizni kell, megfelelő külső auditor választását vetjük fel. Nem megfelelő vagy nem elfogadható működés esetén az RA tevékenysége felfüggeszthető, megbízása visszavonható, (pénzbeli) szankciók alkalmazhatók. Ettől függetlenül egy rosszul működő RA nagyobb kárt okozhat, mint ami a CA-nak befizetett díjakból fedezhető. RA számára más fél, ill. felek is nyújthatnak kezességet. Óvadék, bankgarancia, kezesség, biztosítás, pótbefizetés egymást helyettesítőleg és egymással párhuzamosan egyaránt alkalmazható. Az RA-k pénzügyi garanciavállalására egy olyan struktúra dolgozandó ki, amely az egymástól igen különböző partnerek számára is megoldási lehetőséget nyújt. A kívánt garancia más és más, de elégséges módon legyen teljesíthető. RA partner beszüntetheti RA tevékenységét, ez tipikusan nem okozhat gondot. RA megszűnése sem eredményez automatikusan problémákat, de megszűnése utáni időszakban is jelentkezhet korábbi tevékenységéből fakadó kár. Az RA tevékenység megszüntetése, ill. RA partner jogutód nélküli megszűnésével előálló helyzetet előre szabályozni kell.


58

Biztosítási díj elvben beépíthető magába a tanúsítványba. Ekkor is rendelkezik a CA és az RA-k felelősségbiztosítással, ugyanakkor maga a tanúsítvány is 'tartalmaz' biztosítást. A CA-nak megfelelő céltartalékkal kell rendelkeznie káresemények és kártérítés, valamint jogvita rendezésére. A céltartalék a tanúsítványok számától és értékétől, ill. az azokhoz kapcsolódó felelősségvállalásokkal kell, hogy arányos legyen, pontos értéke csak több év tapasztalta alapján becsülhető korrekten. Mindazonáltal úgy véljük a hitelesítő tevékenység felelősségvállalását, a potenciális kockázatokat nem szabad túldimenzionálni. A tanúsítványok eleve területi, cél és felelősségi korlátokkal kerülnek kiadásra. A felelősségvállalás és egyéb korlátozások arányban kell, hogy álljanak az RA által tanúsítványokért a CA-nak fizetett díjakkal. Bizonyos ellenőrzést a kiadásnál – pl. bizonyos felelősségvállalási érték felett – maga a CA is gyakorolhat. Ez hasonló a regisztrációs során alkalmazott adminisztrátori ellenőrzésével. Ez az ellenőrzés lehet szúrópróbaszerű, ill. feltételhez kötött – járhat a CA részéről felelősségvállalással is. Azonban azt javasoljuk, hogy a hitelesítés kockázata azé legyen elsősorban, aki azt végzi, azaz az RA partneré. Megfelelő felkészültséggel rendelkező biztosítási szakértő, ill. alkusz vonandó be a biztosítási megoldás megtalálásába, biztosító kiválasztásába.


59

Megoldási javaslat A tanulmánykészítők az ISzT részére javasolják, hogy az ISzT Kht-n belül hozzon létre hitelesítő szolgáltatót (CA-t). Jogilag ún. fokozott biztonságú szolgáltatóként történő létrehozást javaslunk, mely indulását zárt körű szolgáltatóként is megkezdheti. A CA ne üzemeltessen önállóan RA-t, a jelenlegi regisztrátorok pályázhassanak RA licencre, az RA licence franchise jellegű legyen a jelenlegi regisztrátori licenchez hasonlóan. Nem domén regisztrátorok RA-vá válása az ISzT Kht. tevékenységével kétséges, hogy összeegyeztethető. Mindenképpen javasoljuk, hogy a domén regisztrátori és tanúsítvány ügyintézői tevékenység valamilyen mértékben kapcsolódjon. Az RA-k egyszeri és éves díjat, valamint tanúsítványonkénti8 9 díjat fizethetnek a CA-nak, a tanúsítványonként díjak az üzleti viszonyokhoz alkalmazkodóan az igényelt tanúsítványok számával degresszíven változóak lehetnek. Nem szükséges, hogy egy RA mindenféle, a CA által kínált tanúsítványtípust forgalmazzon, javasoljuk, hogy igény esetén akár többféle szerződéstípus közül is választhat az RA partner. A tevékenységét – szerződésmódosítást követően – bármely RA partner bővítheti, így kezdetben esetleg csak a kevesebb felelősséggel járó tanúsítványok ügyintézést végzi, majd tevékenységi körét akár az összes, a CA által kínált tanúsítvány igény intézésére bővíti. Elvben a tanúsítványtípusok RA szervezetenként is változhatnának, de ez meglehetősen nehezen átlátható tanúsítványrendszert eredményezne. Javasoljuk, hogy a tanúsítványtípusok palettája egységes legyen, ebből választhassanak az RA szervezetek melyeket kívánják kínálni. Tanúsítványvisszavonást bárki kezdeményezhet, tipikusan az RA-kon keresztül. A kiadás során közreműködő RA visszavonási kérelme különösen respektálandó. Az RA partnernek szigorú szakmai, adminisztratív, minőségi és felelelősségvállalási követelményeknek kell eleget tenni, ezt a CA-től független auditor ellenőrizze. Az RA-k felelősségbiztosítással kell, hogy rendelkezzenek, valamint az egyes tanúsítványok díjába is felelősségvállalási díjat kell beépíteni. A következő lépéseket javasoljuk: 1. ISzT vita és döntés CA létrehozásának szándékáról 2. Az ISzT tagjai között felmérést kell végezni a kívánt tanúsítványtípusokról, az RA-vá válás kívánt, ill. elfogadható feltételeiről. Felmérést kell végezni adott feltételekkel, hány tag, ill. regisztrátor kíván RA partnerként is tevékenykedni. Műszaki megoldási javaslat választandó, kétfordulós tendereztetést javaslunk, 3. az első forduló dönthet az alkalmazott technológiáról (pl. nyílt rendszerre épülő egyedi fejlesztés vagy kereskedelmi termék vásárlása és bevezetése); 4. a második forduló a konkrét megoldásszállításra történő tendereztetést jelenti. 5. Szolgáltatói modell, költségvetés, CA-RA mintaszerződés kidolgozandó. 6. Zárt szolgáltatói működés, az elektronikus aláírás bevezetése a regisztrátori rendszeren belül, béta teszt és éles zárt szolgáltatói üzem. 7. Nyílt szolgáltatóként történő fellépés, előzetes központi marketing kampányt követően. Műszaki szempontból egyaránt elfogadhatónak tartjuk a tanulmányban részletezett nyílt rendszerre (Java alapokon) épülő megoldást vagy az említett gyári megoldásokat (költség okokból a CA eTrust PKI-t tartjuk versenyképesnek a tárgyalt másik és említett más megoldásokkal szemben, de eleve tendereztetés előtt nem érdemes leszűkíteni termékekre vagy megoldásszállítókra a kört).

8

Néhány egyéb díj alkalmazása is szükséges, pl. tanúsítványvisszavonási díj, ill. szankcionális díjakat alkalmazását is javasoljuk. 9 új tanúsítvány és tanúsítvány meghosszabbításának díja


60

Előnyök és hátrányok az ISzT, tagjai és regisztrátorok részére Amennyiben feltételezzük, hogy az ISzT Kht. CA szervezetet hoz létre, akkor ebből kifolyólag komoly anyagi kockázattal számolhatunk a Kht. szintjén. A kockázat nem veszélyeztetheti a regisztrációs alaptevékenységet, csak olyan mértékű kockázat vállalható, mely pénzügyi bizonytalansággal nem jár. Egyes ISzT tagok maguk is CA szolgáltatást végezhetnek, ez ellenérdekeltséget teremthet. Azonban a tagság töredéke lenne képes vagy szándékozik önálló CA tevékenységet folytatni, így a tagok, ill. regisztrátorok részére új lehetőségek nyílhatnak. Az ISzT tevékenységéhez, alapszabályában megfogalmazott célokhoz megfelel a CA létrehozása, kétségkívül ez azon túl, hogy a digitális aláírás elterjedésére kedvező hatású indirekt módon általános hatást gyakorolhat a hazai Internetre. A tagok és regisztrátorok részére a CA tevékenység indítása közvetlen hátrányokkal nem jár. A domén regisztrációs tevékenységet egyértelműen segítheti a CA indítása, mindenekelőtt online regisztrációra nyílhat lehetőség10. Sikeres CA létrehozása növeli az ISzT presztizsét és szerepét, sikertelen vagy működési nehézségekkel terhelt indítás viszont csökkentheti. Végül, de nem utolsósorban bevételt és piacbővülést, akár igen jelentőset is eredményezhet az új tevékenység mind az RA partnerek (regisztrátorok), mind a CA (az ISzT Kht.) részére.

10

ehhez nem szükséges feltétel se a digitális aláírás, se a CA létrehozása, elsősorban szabályozási kérdésről van szó


61

Jogszabályi kötelmek Zárt körben, egymással szerződésben álló felek elektronikus aláírására nem kötelező az Elektronikus aláírásról szóló törvényt (továbbiakban: Eat.) alkalmazni, de az Eat. kimondja, hogy bizonyos (Eat. 3. § 2.) korlátozástól eltekintve az elektronikus és hagyományos aláírás hitelesség tekintetében egyenrangú. Nyílt, azaz nem zárt körben végzett szolgáltatói tevékenységek és ilyen körben alkalmazott elektronikus aláírás az Eat. törvény hatálya alá esik. Az Eat. törvény nevesít − −

minősített szolgáltatás és fokozott biztonságú szolgáltatás végzést.

A törvény nevesít minősített hitelesítés-szolgáltatót (Eat. 2. § 18.), ún. fokozott biztonságú hitelesítő szolgáltatót viszont nem. Azonban, egy hitelesítő szolgáltató fokozott biztonságú szolgáltatásnyújtást végezhet. Minősített hitelesítés-szolgáltató létrehozásával tanulmányunk nem foglalkozik, de megjegyezzük: Az Eat. elektronikus irat és aláírás elfogadásán túl, a minősített elektronikus aláírás, minősített hitelesítő szolgáltató bevezetése jelentős lépés a jogalkotó részéről, hogy államigazgatási és bírósági eljárásban is elfogadják a (minősített) elektronikus aláírást. Pillanatnyilag minősített elektronikus aláírás használata még nem lehetséges, csak a törvényi fogalom áll rendelkezésre. A törvény fokozott biztonságú aláírást is definiál (lényegében ez az, amit a kriptográfiában elektronikus aláírásnak, ill. elektronikus kézjegynek hívnak). Fontos megjegyezni, hogy a fokozott biztonságú aláírás definícióját vagy tényét tekintetve indifferens, hogy tanúsítványt belföldi vagy külföldi, fokozott vagy nem fokozott biztonságú szolgáltatást nyújtó hitelesítő szolgáltató adta. A fokozott biztonságú szolgáltatás végzés vagy minősített szolgáltatás állami tanúsítványnak tekinthető, arra utal, hogy a szakhatóság a szolgáltatót fokozott biztonságúként, illetve minősítettként regisztrálta. Nem a hitelesítő szolgáltatón (tanúsítványkiadón) múlik az elektronikus aláírás fokozott biztonságának volta. A fokozott biztonságú elektronikus aláírás csak olyan eszközzel hozható létre, mely kizárólag az aláíró befolyása alatt áll, ez nem tanúsítványkiadó függő feltétel. Lehetséges tehát gyakorlatilag teljesen ellenőrizetlen, nem regisztrált belföldi vagy külföldi hitelesítő szolgáltató által kiadott tanúsítványt felhasználni fokozott biztonságú aláírás létrehozásához, sőt tanúsítvány sem kell hozzá (feltéve, hogy az elektronikus aláírás valami módon alkalmas az aláíró azonosítására). Az Eat. 7. § tárgyalja a szolgáltatások nyújtásának feltételeit. Érdekes módon a 7. § 2. a fokozott biztonságú elektronikus aláírás előállításához olyan aláíró eszköz vagy termék használatát engedi csak meg, amely arra jogosult szervezetek által kiadott igazolással rendelkezik. Mindezt a szolgáltatókra szóló feltételek alatt tárgyalja, de az aláírást tipikusan nem a szolgáltató végzi (természetesen a tanúsítványkiadó a tanúsítványt aláírja). Nem ismert a jogkövetkezménye, ha az aláíró nem a 7. § 2. szerinti eszközt vagy terméket használ. Jelenleg nem lehet jogszabályi feltételeknek megfelelően fokozott biztonságú elektronikus aláírást, időbélyegzőt alkalmazni. Az Eat 7. § 2. szerint ilyen aláíráshoz kizárólag csak olyan aláíró eszköz, ill. aláíró termék használható mely rendelkezik a Felügyelet által nyilvántartásba vett, tanúsításra jogosult szervezetek által kiadott igazolással. Pillanatnyilag nincs ilyen nyilvántartásra jogosult szervezet nyilvántartásba véve és persze termék sincs. A Felügyelet nyilván nem tartja lényegesnek e jogszabályi kötelezettséget (jelenleg e kötelezettségnek eleget tenni senki sem tud), hiszen a Felügyelet fokozott biztonságú szolgáltatást végzőket már nyilvántartásba vett. Hitelesítő szolgáltatás, hitelesítő szolgáltató Az Eat. háromféle szolgáltatást tárgyal (Eat. 6. § 1.): − − −

hitelesítés-szolgáltatás időbélyegzés aláírás-létrehozó eszközön az aláírást-létrehozó adat elhelyezése.

Jelen tanulmány a hitelesítő-szolgáltatásra korlátozódik. A 3. pont valójában a privát kulcs fizikai eszközön történő elhelyezését szolgálja. Ilyen melléktevékenységet hitelesítő-szolgáltató is nyújthat. Az Eat. nem említi, következésképpen nem szabályozza a kulcsőrző tevékenységet. Kulcsőrző szolgáltatást is nyújthat hitelesítő-szolgáltató. Ezenkívül más tevékenységeket is nyújthat a hitelesítő© EGERSZEGI CONSULTING – INTEGRITY, 2002

62

szolgáltató, mely magához a hitelesítő-szolgáltatói tevékenységhez többé-kevésbé szorosan kapcsolódnak, pl. oktatási, ismeretterjesztői, szakértői, kiadói tevékenységet. Kézenfekvő, hogy egy hitelesítő-szolgáltató titkosító kulcsokhoz is ad ki tanúsítványt, az ilyen tanúsítványkiadást külön jogszabály nem szabályozza. A hitelesítő-szolgáltató tanúsítványrendszerét szabadon alakíthatja ki, nincsenek említésre méltó jogszabályi korlátok. Fokozott biztonságú szolgáltatóval szemben támasztott követelmények Fokozott biztonságú szolgáltatást végző explicit definícióját nem adja meg a törvény. Fokozott biztonságú szolgáltatást végzőre a törvény feltételeket, ill. kötelezettségeket ír elő. Az a fokozott biztonságú szolgáltatást végző ezen implicit törvényi definíció szerint, aki e feltételeknek, ill. kötelezettségeknek eleget tesz, lásd alább. A fokozott biztonságú szolgáltatást végzőre vonatkozó feltételek: − − −

−

A fokozott biztonságú szolgáltatást végző tevékenysége megkezdése előtt 30 nappal köteles bejelentkezni a Felügyeletnek. A bejelentéshez csatolnia kell a szolgáltatási szabályzatot és az általános szerződési feltételeket. A Felügyelet nyilvántartásba veszi a szolgáltatót, ha eleget tesz a jogszabályi kötelmeknek és a nyilvántartásba vétellel egyidejűleg, azt követően ellenőrzést végez. A fokozott biztonságú szolgáltatást végző köteles 3.000.000,-Ft bankgaranciát, óvadékot, ill. ezt helyettesítő megfelelő a fél részéről történő kezességvállalást igazolni.

Megjegyezzük, hogy a minősített szolgáltatónak sokkal több és súlyosabb feltételeknek kell eleget tennie. Megemlítjük, hogy a Felügyelet a hitelesítő szolgáltatóra akár 10.000.000,-Ft, ill. a vezető tisztségviselőjére akár 1.000.000,-Ft egyszeri bírságot szabhat ki. Ezek egyszeri bírságok, melyek ismételten, ill. más-más okokból is kiszabhatók. A bírságokkal kockázati és üzleti tervnél számolni kell. Az előzőekből következően a szolgáltatás megindítása előtt mindenekelőtt pontosan ki kell dolgozni − − − −

−

a szerződési feltételeket és szabályzatokat; a hitelesítés folyamatát; a tanúsítvány-visszavonás szabályait és folyamatait; szolgáltatás befejezésére szóló tervet; fokozott biztonságú szolgáltatásnál a bejelentkezést bonyolítani és a feltételeknek eleget tenni.

Technikai szempontból alapvetően irreleváns az, hogy fokozott biztonságú vagy minősített szolgáltatást végez valaki. Jogi szempontból viszont a különbségek rendkívül lényegesek. Számos jogszabályi kötelezettség vonatkozik a hitelesítő-szolgáltatókra és a fokozott biztonságú szolgáltatást végzőkre. A fentiekben a döntés előkészítéshez szükséges kötelezettségeket emeltük ki. Számos jogszabályi kötelem a józan ész szerint is elengedhetetlen. Érdemes figyelemmel lenni a már regisztrált fokozott biztonságú szolgáltatást végzők szolgáltatási szabályzataira és általános szerződési feltételeire (melyek nyilvánosan elérhetők, sőt ezeket kötelező is szolgáltatóknak nyilvánosságra hozni, valamint e dokumentumokat maga a Felügyelet is weben át közzéteszi). Ezek már átestek a Felügyelet ellenőrzésén is, így megalapozottan szolgálnak mintául a Létrehozó számára. Jelentős szakértői és jogi munka a szolgáltatási szabályzatok és általános szerződési feltételek elkészítése. Természetesen más szolgáltatók szabályzatai mintául szolgálnak, de szolgaian nem vehetők át, hiszen bizonyára a kialakítandó rendszer lényeges eltéréseket is fog mutatni más szolgáltatók hasonló struktúrájától (pl. eltérőek a tanúsítványok, eltérő az üzleti struktúra). Véleményünk szerint a tanúsítvány-szolgáltató és RA partnerek szerződéses viszonya franchise típusú szerződésben szabályozható, hasonlóan a Nyilvántartó-regisztrátori viszonyhoz. Az ISzT mellett működő Választott Bíróságot (VB) is fel kell készíteni az új feladatra (legalább is a szerzők javasolják, hogy a jelenlegi VB működését terjesszük ki erre a területre is.


63

Melléklet A http://cert.bad.hu alatt bemutatjuk, hogy ún. root tanúsítvány miként illeszthető be weboldalról MS Internet Explorerbe vagy Netscape Navigatorba. Ez a root tanúsítvány nem valódi, az itt szereplő 'Bad Certification Authority Corporation' fiktív cég. Útmutató: Az "Install Bad Certification Authority Corporation CA certificate"-re kattintva, majd a megnyitást választva, mindenre igent kattintva installálhatjuk a tanúsítványt. MS IE alatt a trusted root certificate-ek alá. Alapvetően az ISzT saját 'trusted root certicate'-jét akár így is propagálhatja saját honlapján. Az ISzT meglehetősen előnyös helyzetben van, hogy mint hitelesítő széleskörben elfogadják, honlapján keresztül hitelesítő tanúsítványát (root certificate) letöltsék. Elvben lehetőség van megállapodni a Microsofttal, a Netscape-pel és más gyártókkal, hogy termékük eleve tartalmazza a root certificate-ek között az ISzT certificate-eit.


64

Irodalomjegyzék 1. 2001. évi XXXV. (IX.1.) Törvény az elektronikus aláírásról 2. 15/2001. (VIII.27.) MeHVM rendelet az elektronikus aláírási termékek tanúsítását végző szervezetekről, illetve a kijelölésükre vonatkozó szabályokról 3. 151/2001. (IX.1.) Kormányrendelet a Hírközlési Főfelügyeletnek az elektronikus aláírással kapcsolatos feladat- és hatásköréről, valamint eljárásának részletes szabályairól 4. 16/2001. (IX.1.) MeHVM rendelet az elektronikus aláírással kapcsolatos szolgáltatásokra és ezek szolgáltatóira vonatkozó részletes követelményekről 5. 20/2001. (XI. 15.) MeHVM rendelet a Hírközlési Főfelügyeletnek az elektronikus aláírással öszszefüggő minősítéssel és nyilvántartással kapcsolatos tevékenységéért fizetendő díjakról 6. Brands, Stefan A.: Rethinking Public Key Infrastructures and Digital Certificates: Building in Privacy. MIT Press, 2000. 7. GIRO Rt. Hitelesítési Szolgáltatási Szabályzata 8. GIRO Rt. Az Elektronikus Aláírás Hitelesítés Szolgáltatás Általános Szerződési Feltételei (ÁSZF) 9. GIRO Rt. Személyes tanúsítványtípus Hitelesítési Szabályzata 10. GIRO Rt. Szervezeti tanúsítványtípus Hitelesítési Szabályzata 11. MATÁV Rt. Szolgáltatási Szabályzat a Matáv Rt. e-Szignó – Üzleti Szolgáltatások nyújtásának feltételeiről 12. Matáv Rt. e-Szignó Üzleti Szolgáltatás Általános Szerződési Feltételek 13. Netlock Kft. Szolgáltatási Szabályzat 14. Netlock Kft. Általános Szerződési Feltételek 15. Egerszegi Krisztián, Erdősi Péter: Minősített aláírás, InfoBYTE 2002. január 16. Erdősi Péter: A PKI rendszerek bevezetésének biztonsági követelményei, Infoszféra Kft. 2000. nov. 29. 17. Feghhi, Jalal: Digital certificates: applied Internet security, Addison Wesley Longman, Inc., 1999. 18. Horváth László, dr. Lukács György, dr. Tuzson Tibor, Vasvári György: Informatikai biztonsági rendszerek, BMF-Ernst&Young, Budapest, 2001. 19. Dr. Rátai Balázs: Az elektronikus aláírás szabályozásának kulcskérdései az 1999/93/EC irányelv alapján (2000. március 19.-i PJ TDK előadásvázlat) 20. Vasvári György: Bankbiztonság, Műegyetemi Kiadó, Budapest, 1995 21. Vasvári György: Biztonsági rendszerek szervezése, Pro–Sec Kft., Budapest, 1997 22. CEN/ISSS WS/E-Sign; Area D1 Draft CWA 14167-1: Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures; Version: 0.17 23. Certification in the area of electronic signatures; TTP.NL-broshure, 2001 június. 24. CISA Review Manual, 2001. 25. Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures (1999.12.13.) 26. Wolfgang et al.: Smart card handbook 2nd ed., Wiley, John and Sons, 2000. 27. http://www.giro.hu/hiteles 28. http://www.netlock.net 29. http://www.matav.hu 30. http://www.hif.hu 31. http://www.itb.hu/ajanlasok 32. http://www.europki.org 33. http://www.iks-jena.de 34. http://www.thawte.com 35. http://www.telekom.de 36. http://digitalid.verisign.com 37. http://www.globalsign.com 38. http://www.entrust.com 39. http://www.digsigtrust.com 40. http://www.baltimore.com/unicert/pdfs.html 41. http://www.tscheme.org/directory/index.html 42. http://www.ecp.nl 43. http://www.etsi.org/sec/el-sign.htm 44. http://www.ca.com 45. http://www.safeguard.com 46. http://www.eema.org/pki-challenge/ 47. http://www.rsasecurity.com 48. http://www.rsasecurity.com/products/keon/datasheets/dskeoncertificateauth.html © EGERSZEGI CONSULTING – INTEGRITY, 2002

65

49. http://www.iplanet.com/products/iplanet_certificate/home_certificate.html 50. http://www.cisco.com/warp/public/cc/so/neso/sqso/eqso/821_pp.htm 51. http://www.pts.co.uk/jca.cfm


66

Megvalósíthatósági tanulmány hitelesítő szolgáltató létrehozására

Recommend Documents