A nyilvános kulcsú infrastruktúra önálló kialakításának szükségessége Spisák Andor Bármely szervezet esetében, amely PKI szolgáltatásokat kíván igénybe venni, felmerül a kérdés, önálló PKI létrehozásánál nem elõnyösebb-e, ha egy, a piacon már bizonyított szolgáltató szolgáltatásait veszi igénybe. A szerzõ cikkében felsorakoztat olyan, a szervezet kiszolgáltatottságát, a szolgáltató rendelkezésre állását, a szolgáltatások minõségét, valamint a piacon használt algoritmusok biztonságosságát tárgyaló aspektusokat, amelyek segítségével, ha konkrét esetben megfelelõ súlyozásra kerül sor, a felvetett kérdés megválaszolható. Any company wishing to introduce PKI services may put the question whether it is necessary to establish an own PKI or whether it pays more to make use of the services of providers who have already proved their abilities on the market. In this article the author lists aspects concerning the company being exposed, the availability of the provider, quality of service provided and the security of the algorithms used, the help of which the question at hand may be answered by weighting the listed aspects appropriately according to the special needs of the company. Az informatikai biztonság, ezen belül is a rosszindulatú külsõ beavatkozók elleni védelem egyre inkább kulcskérdéssé válik a különbözõ informatikai rendszerek kialakítása során. Ezért fokozott mértékben szükséges védekezni az ellen, hogy nyilvános általában nem biztonságosnak ítélt csatornán közvetített bizalmas üzenetek tartalma harmadik nem illetékes, esetleg rosszindulatú fél birtokába jusson. Komoly veszélyt jelent, ha a harmadik fél, azon felül, hogy tudomást szerez a bizalmas információról, ezt meg is másítja. Ez a biztonsági igény nem az információs társadalom szülöttje, már az ókorban is problémát jelentett, korunkban csupán a védekezés módszereit szükséges változtatni, finomítani. Szintén nem új keletû az a veszély, hogy egy üzenet küldõje amennyiben az neki egy késõbbi idõpontban kényelmesnek tûnik letagadja az üzenet elküldését, illetve az üzenet fogadója annak fogadását. Mindezekre a veszélyekre léteznek többé-kevésbé biztonságos bírósági eljárás keretében is bizonyíték erejû megoldások, amennyiben az üzenet elküldése papír alapon történik. Az elektronikus üzenetek egyre fokozottabb elterjedése szükségessé tette olyan eljárások kidolgozását, amelyek a lehetõ legnagyobb mértékben védik a nem biztonságos csatornán elküldött üzeneteket a fent felsorakoztatott veszélyektõl, nevezetesen védik az üzenetek sérthetetlenségét, letagadhatatlanságát és hitelességét. 99
Ezen célok elérésének érdekében az üzenetek küldésekor valamilyen titkosító algoritmust használunk, az esetek többségében nyilvános kulcsú algoritmust. Nyilvános kulccsal való titkosítás esetén alapvetõ kérdés, hogy a nyilvános kulcsok, azok birtoklói, illetve kibocsátói egy partner számára megbízhatóak-e. A nyilvános kulcsú infrastruktúra (továbbiakban PKI Public Key Infrastructure) egyik célja, hogy hiteles tanúsítványok, illetve visszavonási listák segítségével biztosítsa minden felhasználó részére, hogy a kulcsokat egy megbízható fél generálta, ezek megbízható, biztonságos helyen kerülnek tárolásra, és a kulcsok kompromittálódása esetén ez a tény egy visszavonási listában nyilvánosan kerüljenek feltüntetésre. A megbízható felet hitelesés szolgáltatónak (továbbiakban CA Certification Authority) nevezzük. A CA általában hatósági engedéllyel mûködik, ennek tükrében megbízhatósága garantáltnak tûnik. (A PKI elemei és az egyes elemek szerepe, illetve a háttérben meghúzódó algoritmusok mûködése számos tanulmányban és cikkben szerepelnek, ezért ebben a cikkben nem részletezzük ezeket.) Egy szervezet több okból is dönthet úgy, hogy PKI szolgáltatásokat vesz igénybe. Teheti ezt annak érdekében, hogy partnerei számára biztosítsa a küldött üzenetek sérthetetlenségét, letagadhatatlanságát, illetve hitelességét. Ez fõként kiterjedt klientúrával rendelkezõ szervezetekre, mint például a bankokra, illetve a pénz- és adóügyi hatóságokra. Másik ok lehet, hogy a szervezet földrajzi tagoltságából kifolyólag VPN (Virtual Private Network)-t hoz létre, és így szükségessé válik PKI szolgáltatások igénybe vétele a szervezeten belüli biztonságos adatforgalom lebonyolítása érdekében. Egy harmadik ok az lehet, hogy a szervezet hierarchikus viszonyban van egyéb szervezetekkel, amelyek megkövetelik de esetleg nem biztosítják a biztonságos adatforgalom lehetõségének megteremtését. A felsorolt okok bármelyike esetén felmerül az alapvetõ kérdés, hogy érdemes-e önálló PKI-t létrehozni, vagy egy megbízhatónak ítélt CA szolgáltatásait igénybe venni. A szerzõ cikkében olyan szempontokat sorakoztat fel, amelyek segítséget nyújthatnak e fontos döntés meghozatalánál, különös tekintettel a védelmi szférára. Biztonsági szempontok Egy esetlegesen önállóan kialakítandó PKI esetén különösen fontos szerepet játszanak a biztonsági szempontok akkor, ha a belsõ adatforgalmat kívánjuk harmadik fél támadásaitól megóvni. Ekkor ugyanis a szervezet kétség kívül önmaga felvállalja a bizalmat megteremtõ CA szerepét, hiszen a szervezet tagjainak (dolgozók, alkalmazottak, stb.) elsõdlegesen a szervezettel önmagával szemben kell bizalmat tanúsítaniuk. Kézenfekvõnek tûnik, hogy ez a feltétel egy jól mûködõ szervezet esetén adott. Ugyanakkor kérdéses, hogy külsõ partnerekkel történõ adatforgalom esetén is ilyen egyértelmû-e a helyzet. Kiszolgáltatottság piaci szereplõknek Amennyiben VPN-n történõ adatforgalom biztonságának garantálása az elsõdleges cél, elõnyösnek tûnhet egy önálló PKI kialakításának ötlete, hiszen a szervezet ez esetben semmilyen szinten nincs kiszolgátatva semmilyen piaci szereplõnek. Egy pi- 100
SPISÁK ANDOR: A nyilvános kulcsú infrastruktúra önálló kialakításának szükségessége aci szereplõnek való kiszolgátatottság sokféleképpen megnyilvánulhat. Nyilvánvaló, hogy bármely CA-nak szerepkörébõl adódóan elméleti lehetõsége van, bármely általa kiszolgált kliens adatforgalmába betekinteni. Szigorúan meg kell jegyezni azt, hogy egy ilyen cselekedet nyilvánvalóan ellentmond a CA-ba fektetett bizalom elvének, amelyre az egész PKI megbízhatósága épül, így feltételezhetõen minden CA tartózkodni fog az ilyen lépésektõl. Elõfordulhat azonban, hogy egy szervezet által kezelt dokumentumok és adatok annyira bizalmasan kezelendõk, hogy bármely, szervezeten kívül álló betekintésének még elvi lehetõségét is ki kell zárni. Mérlegelni kell tehát, hogy a belsõ adatforgalom milyen mértékû megvédése a cél, ennek tükrében eldönthetõ, hogy létezik-e olyan piaci szereplõ, amelyben az adott szervezet kellõ mértékben megbízik, és amelyik a megkövetelt szinten biztosítani tudja az üzenetek biztonságát. Függetlenül egyes PKI szolgáltatások igénybevételének okától sok egyéb módja is lehet a külsõ szolgáltatótól kialakuló függõségnek: csak a külsõ szolgáltató által kínált szolgáltatások vehetõk igénybe a szolgáltató által szabott feltételek és árak mellett, csak azok az algoritmusok használhatók, amelyeket a szolgáltató jónak tart és használ, csak a szolgáltató által meghatározott mértékben érvényesíthetõ pénzügyi vagy erkölcsi jóvátétel, amennyiben a szolgáltató nem tudja teljesíteni a vállalt kötelezettségeit, illetve esetleges vitákat csak jogi úton lehet rendezni. Kulcskérdés a szolgáltató rendelkezésre állása, azaz lehetséges-e bármikor az igényelt szolgáltatások megfelelõen biztonságos igénybevétele. Tekintsük át ezeket a kérdéseket kissé részletesebben A piaci hitelesítés szolgáltatókkal szemben támasztott követelményeket a 3/2005. (III. 18.) IHM rendelet részben meghatározza [1]. Különbözõ biztonsági szintek kialakítása minõsített dokumentumok részére Bármely PKI szolgáltatásokat igénylõ szervezet esetén elõfordulhat, hogy a lebonyolítandó adatforgalom keretében elküldött dokumentumokat osztályozni kell, attól függõen, hogy tartalmuk milyen mértékû védelmet igényel külsõ illetéktelen hozzáférés ellen, illetve milyen mértékben kell a dokumentumok letagadhatatlanságát és hitelességét garantálni. Különösen igaz ez a védelmi szférára, ahol különbözõ szinten minõsített dokumentumok elektronikus úton történõ titkosítása lehet a cél. A problémát két különbözõ aspektus oldaláról megvilágítva tárgyaljuk: A különbözõ szinten minõsített dokumentumok titkosításához, illetve hitelesítéséhez használt algoritmusokat lefuttató és megvalósítható hardver- és szoftvereszközök fizikai tárolását különbözõ szinteken lehet megvalósítani. A NIST FIPS 140-2-es szabványa [2] négy szintet definiál. A szabványhoz történõ igazodást a Miniszterelnöki Hivatalt vezetõ miniszter 2/2002 (IV. 26.) MeHVM irányelve szabályozza [3]. Ez az irányelv elõírja a NIST FIPS 140-1-es szabványban elõírtakhoz történõ igazodást, az irányelv a szolgáltatókra nézve azonban nem kötelezõ. Bármely, önállóan kialakítandó PKI keretein belül is nyilán célszerû igazodni ehhez a szabványhoz. 101
A minõsített dokumentumok kriptográfiai kezelése elképzelhetõ olyan alapon is, hogy a fokozottan minõsített dokumentumok titkosítására, illetve hitelesítésére olyan matematikai algoritmusokat használunk, amelyek fokozott biztonságot nyújtanak rosszindulatú támadók ellen. Ezzel a megközelítéssel kapcsolatban meg kell jegyezni, hogy egyrészt a fokozott biztonságot nyújtó algoritmusokhoz sok esetben saját hardver-, illetve szoftvereszköz szükséges, másrészt a titkosítás, a titkosított dokumentum visszafejtése, valamint a dokumentum lenyomatának elkészítése több idõt vehet igénybe. Ezen felül felmerülhetnek interoperabilitási kérdések, amelyek azonban a szervezeten belüli adatforgalom biztonságának garantálása esetén nem feltétlenül játszanak szerepet, hiszen a PKI egységes belsõ kialakításának köszönhetõen az üzenet küldõje és fogadója tetszõleges algoritmusok esetén képes az üzenetek kezelésére. Külsõ szolgáltató igénybevétele esetén a szolgáltatók többségénél nincs mód az algoritmusok megválasztására, õk ugyanis érthetõ módon az interoperabilitást kiemelt prioritással kezelik, és ezért fõként azokat az algoritmusokat használják, amelyek a NIST által meghatározásra kerültek [4]. A fenti meggondolások alapján indokoltnak tûnhet önálló PKI létrehozása. Létezik azonban olyan elképzelés is, amely szerint csupán a felhasználók regisztrálását és a hozzájuk rendelt attribútumokat kell a szervezeten belül meghatározni és tanúsítani, hiszen egy CA által kibocsátott tanúsítvánnyal ellentétben az ilyen attribútum tanúsítványok nem globális, hanem lokális érvényességûek és szigorúan bizalmas információkat tartalmaznak a felhasználók szervezeten belül meglévõ jogosultságairól, illetve tevékenységérõl, hozzájuk rendelt attribútumaikról. Ehhez, a PKI-hez hasonló, attól mindenképpen független, tulajdonság menedzselési infrastruktúrát (Privilege Management Infrastructure PMI) kell létrehozni, amelynek keretében az attribútum hitelesítõ (Attribute Authority AA) állít ki tanúsítványokat a felhasználók különbözõ jogosultsági körérõl [5]. A magyar törvények és rendeletek értelmében [1,3,6] minden hitelesítés szolgáltató köteles a szolgáltatásokat koordináló, elvégzõ és felügyelõ személyzetet biztosítani. A személyzet feladatköreit, illetve az egyes feladatkörök átfedéseit a törvény korlátozza. Szolgáltatás minõsége és megbízhatósága A 2001/XXXV. törvény az elektronikus aláírásról [6] az alábbi szolgáltatásokat definiálja: elektronikus aláírás hitelesítés-szolgáltatás, idõbélyegzés, aláírás-létrehozó eszközön az aláírás létrehozó adat elhelyezése, elektronikus archiválás szolgáltatás. Ezek közül az elsõ és harmadik pontban felsorolt szolgáltatásokat együtt szokás igénybe venni, de a Magyarországon jelen levõ minõsített szolgáltatók mindegyike ezeket külön-külön is felajánlja. A hitelesítõ szolgáltatások minõségét nehéz konkrét definícióba foglalni, ezért inkább a 2001/XXXV. törvényben [6], a 3/2005 (III.18.) IHM rendeletben [1], illetve a Miniszterelnöki Hivatalt vezetõ miniszter 2/2002 (IV. 26.) 102
SPISÁK ANDOR: A nyilvános kulcsú infrastruktúra önálló kialakításának szükségessége MeHVM irányelvében [3] foglaltak alapján érdemes a problémát megközelíteni. Az ott leírtak értelmében azt kell megállapítani, hogy a szolgáltatások akkor tekinthetõk megbízhatónak, amennyiben a szolgáltatás során a törvényi elõírásokat betartják, a visszavonási listákkal kapcsolatban leírtak maradéktalanul teljesülnek, a szolgáltató rendszerének leállásával kapcsolatosan betartja az elõírásokat. Mindezek betartása semmilyen PKI esetén nem zárja ki a titkos kulcsok kompromittálódását, következésképpen a CA-ba vetett bizalom megrendülését. Meg kell jegyezni, hogy a három dokumentumban foglaltakat minimum-követelménynek tekintjük, ami nem jelenti szükségszerûen, hogy ez minden szervezetnek elegendõ biztosítékot nyújt. Nyilvánvaló, hogy a szolgálatásokkal kapcsolatba hozható megbízhatóság nagymértékben függ az eszközök fizikai és elektronikai védelmétõl. A magyar törvények és rendeletek konkrétan nem rendelkeznek az eszközök fizikai és elektronikai védelmérõl, csupán irányelveket fogalmaznak meg a fizikai védelemmel kapcsolatban, és kimondják, hogy az a szolgáltató, amely megfelel ezeknek az irányelveknek, minõsített szolgáltatónak tekintendõ [1,3,6]. Általánosan elfogadott elv azonban, hogy külön szerveren tárolandó minden egyes szolgáltatáshoz kapcsolódó nyilvántartás és eszköz, így például a tanúsítványok, a visszavonási listák, valamint a regisztrációs adatok. A visszavonási listát õrzõ szervert külön, a szervezet belsõ hálózatát védõ tûzfaltól független tûzfallal szokás védeni. Ezen kívül gondoskodni kell olyan eszközökrõl, amelyeken úgy a CA, mint a felhasználók titkos kulcsai megfelelõ biztonsággal tárolhatók. Piaci szolgáltatók által nyújtott szolgáltatások és a rendelkezésre állás A magyar piacon jelenleg négy szolgáltató van jelen [7], ezek mindegyike elektronikus aláírás hitelesítés-szolgáltatás, idõbélyegzés szolgáltatást és aláírás-létrehozó eszközön az aláírás létrehozó adat elhelyezése szolgáltatást nyújt, szabályzatában mindegyik vállalja az [1,3,6] dokumentumokban leírtak betartását. A szolgáltatások rendelkezésre állását illetõen a törvény egyértelmûen, és a szerzõ meglátása szerint egyre fokozódó szigorral fogalmaz [1,3,6,8]. Ennek értelmében bármely szolgáltatónak biztosítania kell a folyamatos rendelkezésre állást, ami a releváns szolgáltatások esetében azt jelenti, hogy a szolgáltató rendszerének leállásából fakadó szolgáltatás kimaradás nem haladhatja meg a három órát. Az elektronikus archiválás szolgáltatásra vonatkozóan ez a küszöbérték három nap. Megbízhatóság szempontjából sokkal lényegesebb a visszavonási, illetve felfüggesztési listák frissítése, illetve ezek közzététele. A hatósági állásfoglalás [8] értelmében a szolgáltatónak 24 órás folyamatos legalább telefonon történõ rendelkezésre állást kell biztosítania a visszavonási és felfüggesztési kérelmek fogadását illetõen. Ezt követõen a bejelentéstõl számított három óra áll a szolgáltató rendelkezésére, hogy a bejelentés hitelességét ellenõrizze, majd a hitelesség megállapításától számított 60 percen belül az érdekelt fél számára érzékelhetõ hatást kell biztosítania. Ez lényegében azt jelenti, hogy a visszavonási listát (Certification Revocation List CRL) a fent vázolt idõkorlátokon belül a megfelelõ bejegyzéssel frissíteni kell. Egyik Magyarországon mûködõ piaci szolgáltató sem vállal ennél szigorúbb rendelkezésre állást. Nem nyilvánvaló azonban, hogy a védelmi szféra estében a leg- 103
magasabb szinten minõsített dokumentumok titkosítására használt kulcsok esetén ez elegendõ-e. Használt algoritmusok megbízhatósága A Magyarországon engedélyezett hitelesítés szolgáltatók digitális aláírás készítéséhez az SHA1 lenyomatkészítõ (hash) algoritmust, a lenyomat titkosításához pedig RSA algoritmust használnak. Csupán egy szolgáltató az, amelyik MD5 [22] hash-t is felajánl [9,10,11,12]. Titkosítási tanúsítványaik 1024 bites, illetve 2048 bites RSA kulcsokat használnak. Ez azt jelenti, hogy az SSL protokollal ellentétben a piaci szolgáltatók a titkosításra is aszimmetrikus titkosítást kínálnak. A titkosításra használt nyilvános kulcsok méretüket tekintve biztonságosnak mondhatók feltéve, hogy a titkos kulcsra [13]-ban megfogalmazott feltételek igazak. Az MD5-tel szemben az elmúlt év során olyan eredmények [14,15] láttak napvilágot, amelyek biztonságosságukkal kapcsolatban fokozott nyugtalanságra adnak okot. Az SHA 1 algoritmus kompromittálhatóságára egyelõre még nincs konkrét hivatkozás, azonban gyakran hallani azt a véleményt, hogy nem megbízható [23]. A NIST FIPS 180-2-es [16] szabványában definiál olyan hash algoritmusokat, amelynek biztonságossága egyelõre garantáltnak tûnik. Ezek jelenlegi használata azonban feltehetõleg interoperabilitási problémákat vetne fel [4]. Néhány gazdasági szempont és az interoperabilitás Gazdasági szempontokat tekintve figyelembe kell venni, hogy léteznek modellek PKI ajánlott kialakítására vonatkozóan, illetve elõírások, amelyek minden szolgáltató számára nézve kötelezõek. Az elõzõ fejezetben leírtak alapján az egyes szolgáltatásokhoz egy-egy szerver beszerzése szükséges, valamint ezek önálló fizikai elrendezése, és a megfelelõ fizikai (beléptetõ rendszer, a behatolást megnehezítõ nyílászárók, stb.) és elektronikai (esetleges további tûzfalalak) védelem biztosítása. A felhasználóknak általában valamilyen hardver-eszközön szokás a saját titkos kulcsukat átadni. Központi szerveren való tárolásuk nem biztonságos, hiszen addig, amíg a felhasználó nem birtokolja a saját titkos kulcsát, nem áll módjában semmilyen titkosított üzenetet megfejteni. Ezzel szemben áll a piaci szolgáltatók által elkért, hitelesítés szolgáltatásra, idõbélyegzésre és titkos kulcsok tároló eszközön való rendelkezésre bocsátására vonatkozó éves díjak. Konkrét számítások elvégzése túlmutatna ezen cikk keretén. Annyit azonban meg kell jegyezni, hogy megfelelõen nagy szervezetek esetén gazdaságosabb lehet egy önálló PKI létrehozása, tekintve, hogy a legdrágább elemek költsége a szervezet létszámától független. Amennyiben a szervezet önálló PMI-t kíván létrehozni, úgy további legalább két szerverre van szükség, nevezetesen egy az attribútum tanúsítványok tárolására, egy pedig a visszavonási listák tárolására. Egy PKI tervezésekor és implementálásakor a lehetõségek egész palettája áll rendelkezésre, kezdve a CA (illetve CA-k) lehetséges elrendezésétõl, a tanúsítványok, illetve visszavonási listák formátumain át a lehetséges titkosítási, illetve lenyo- 104
SPISÁK ANDOR: A nyilvános kulcsú infrastruktúra önálló kialakításának szükségessége matkészítõ algoritmusokig. Ezek teljesen szabad használata egy sor olyan problémához vezethet, amely a PKI rendszerek egymással való kapcsolatát, de akár egy PKI mûködését is jelentõsen hátráltatja. Ezért létrejött egy, a NIST FIPS által gondozott és összefogott, a PKI-k interoperabilitására vonatkozó minimumkövetelmény-rendszer [4], amely betartása javasolt. A [4]-ben leírtak különös figyelemmel fordulnak a tanusítványok, a visszavonási listák formátumai felé, illetve kiemelten kezelik a javasolt titkosító-, illetve hash algoritmusokat. Leszögezik, hogy a CA könyvtáraihoz való hozzáférés LDAP (Lightweight Directory Access Protocol) segítségével történik [17]. Ez önmagában nem jelent különösebb megkötést, hiszen a könyvtárak az X.500-as ajánlás szerint kerülnek kialakításra, és ehhez LDAP-vel lehet hozzáférni. Pontosan meghatározásra kerül, hogy a CA az ITU-T által gondozott X.509-es ajánlásban definiált v3 típusú tanúsítványt bocsát ki, és v2 típusú visszavonási listát (Certification Revocation List CRL) tesz közzé [18]. Az eddig felsoroltak egy CA számára sem jelentenek jelentõs megkötést, illetve korlátozást és tulajdonképpen irrelevánsak abból a szempontból, hogy egy szervezetnek érdemes-e önálló PKI-t létrehozni, vagy nem. Más szemszögbõl vizsgálva sem jelentõsek ezek a követelmények, hiszen semmilyen mértékben sem vonják maguk után a kliensek CA-val szemben élõ bizalmának csorbulását. A [4]-ben azonban különös figyelemmel specifikálják az interoperabilitás érdekében támogatott titkosító és hash algoritmusokat. Titkosítás szempontjából az RSA [19,20] algoritmust, valamint a NIST FIPS [21] által szabványban rögzített DSA-t határozza meg használandó algoritmusokként. A kitüntetett hash-függvényként pedig kizárólag az SHA 1 [16]-et engedi meg RSA titkosítással párosítva. Amennyiben a PKI kizárólag belsõ használatra, VPN segítségével kerül kialakításra, az interoperabilitási kérdések nyilván nem játszanak akkora szerepet, mint abban az esetben, amikor a szervezet által létrehozott CA külsõ kliensek számára is hozzáférhetõvé teszi tanúsítványait. Ebben az esetben elengedhetetlen a [4] keretein belül leírtakat betartani. * * * A szerzõ cikkében felsorakoztatta azokat a szempontokat, amelyek lényegesek lehetnek egy szervezet önálló PKI kialakítása szükségességének megítélésénél. Konkrét esetben a felsorakoztatott szempontokat súlyozni kell a szervezet biztonsági követelményének, anyagi helyzetének tükrében. Utalás történik a piaci szereplõk által szolgáltatott PKI igénybevételére úgy, hogy a szervezet önálló PMI-t hoz létre, amelynek keretében a felhasználók jogosultságait és attribútumait önállóan tanúsítja, de a hitelesítõ tanúsítványt külsõ szolgáltató állítja ki. Rendelkezésre állás szempontjából a magyar törvények igen szigorú feltételeket szabnak a szolgáltatóknak, amelyeket egy fõként nagy létszámú szervezet nehezen tudna szigorítani. Világossá válik, hogy egyelõre hiába törekedne egy szervezet nagyobb biztonságot nyújtó algoritmusok bevezetésére, erre az interoperabilitás követelményeit szem elõtt tartva nincs lehetõség. Várható azonban, hogy a már szabványosított, biztonságosabb algoritmusok is teret nyernek a jövõben. Egyedül a biztonsági szempontok 105
engednek meg olyan meggondolásokat, amelyek egyértelmûen megindokolhatják egy szervezet önálló PKI kialakításának szükségességét. FELHASZNÁLT IRODALOM [1] 3/2005. (III.18.) IHM rendelet [2] National Institute of Standards and Technology, Federal Information Processing Standards Publication 140-2, 2002 [3] Miniszterelnöki Hivatalt vezetõ miniszter 2/2002 (IV. 26.) MeHVM irányelve [4] National Institute of Standards and Technology, Federal Information Processing Standards Publication, Minimum Interoperability Specification for PKI Components, Version 1, 1997 [5] Dawson, Ed; Lopez, Javier; Montenegro, Jose A.; Okamoto, Eiji: A New Design of Privilege Management Infrastructure for Organizations Using Outsourced PKI, ISC 2002, LNSC 2433, pp. 136 149, Springer Verlag, Berlin, Heidelberg, 2002 [6] 2001/XXXV. törvény az elektronikus aláírásról [7] http://www.hif.hu:7777/pls/portal30/esign_portal.dyn_mi_all.show, 2006.01.11. [8] NHH Informatika Szabályozási Igazgatóság, Minõsített Tanúsítvány Visszavonással és Felfüggesztéssel Kapcsolatos Hatósági Állásfoglalás, 2005.09.27. [9] http://eszigno.t-systems.magyartelekom.hu/eszignohitelesitokozpont/tanusitvanyletoltes.vm, 2006.01.11. [10] http://www.e-szigno.hu/, 2006.01.11. [11] http://www.mavinformatika.hu/ca/, 2006.01.11. [12] http://www.netlock.hu/html/cacrl.html, 2006.01.11. [13] Boneh, Dan, Twenty Years of Attacks on the RSA Cryptosystem, Notices of the AMS, Volume 46, No. 2, 1999, pp 203 213 [14] http://eprint.iacr.org/2004/199.pdf, 2005.09.10. [15] http://www.doxpara.com/md5_someday.pdf, 2005.09.10. [16] National Institute of Standards and Technology, Federal Information Processing Standards Publication 180-2, 2002 [17] http://www.ietf.org/rfc/rfc1777.txt, 2006.01.02. [18] ITU-T Recommendation X.509 (2000), Information Technology Open Systems Interconnection The Directory: Authentification framework. [19] S. Goldwasser, M. Belare, Lecture Notes on Cryptography, http://www-cse.ucsd.edu/users/mihir/papers/gb.pdf, 2002.08.23. [20] A.J. Mezenes, P.C. van Oorschot, S.A. Vanstone, The Handbook of Applied Cryptography, CRC Press LLC, 1997 [21] National Institute of Standards and Technology, Federal Information Processing Standards Publication 186-2, 2000 [22] http://www.ietf.org/rfc/rfc1321.txt, 2005.09.27. [23] http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html, 2005.12.29. 106