A biztonságos elektronikus kommunikáció, az elektronikus aláírás architektúrális kérdéseiről 2001. február-március
MTA Információtechnológiai Alapítvány 2001
Tartalom A biztonságos elektronikus kommunikáció, az elektronikus aláírás architektúrális kérdéseiről.. 1 Bevezetés....................................................................................................................................... 5 A megbízható és hiteles elektronikus kommunikáció, az információvédelem megvalósítása ..... 6 Digitális aláírások a technológiai, igazgatási és jogszabályi feltételek áttekintése....................... 7 Svéd eredmények, AT és SEIS kártyák a digitális aláírásra ..................................................... 9 Jogszabályi vonatkozások ....................................................................................................... 10 A formával kapcsolatos követelmények ............................................................................. 10 Ellenőrzési kötelezettség hamisítás, csalás gyanúja esetén................................................. 11 A polgári jog kérdései ......................................................................................................... 11 Bűnügyi kérdések................................................................................................................ 11 Archívumok......................................................................................................................... 12 Jó példák.............................................................................................................................. 14 USA Védelmi Minisztérium a közepes szintű bizalmi együttműködés nyilvános kulcsú infrastruktúrája .................................................................................................................... 15 Címtárszolgáltatás ....................................................................................................................... 17 Az elektronikus kommunikáció és az elektronikus kereskedelem biztonsága............................ 18 Kockázati tényezők ................................................................................................................. 21 Védekezés................................................................................................................................ 22 A védekezés célja .................................................................................................................... 23 A felhasználók ellenőrzése.................................................................................................. 23 Titkosítás ..................................................................................................................................... 24 Privát kulcsos rejtjelezés ......................................................................................................... 24 Nyilvános kulcsos rejtjelezés .................................................................................................. 25 A feladó azonosítása (authentikálás: az üzenet hitelességének, eredetiségének, valódiságának bizonyítása) ................................................................................................. 25 A hiteles harmadik fél ............................................................................................................. 26 Az üzenet teljessége ................................................................................................................ 26 Az Internet üzenetkezelés védelmi eljárásai ........................................................................... 26 Az üzenetkezelés biztonsági intézkedései............................................................................... 27 A nyilvános kulcsú infrastruktúra, a PKI .................................................................................... 27 Áttekintés .................................................................................................................................... 28 A nyilvános kulcsú szolgáltatási környezet ................................................................................ 31 A PKI szolgáltatással szemben támasztott lényegi követelmények............................................ 32 A PKI a következő szolgáltatásokat nyújtja................................................................................ 32 PKI modellek............................................................................................................................... 33 2
A nyilvános kulcsú infrastruktúra architektúrális elemei............................................................ 34 Az együttműködés biztosítása..................................................................................................... 43 Alkalmazásprogramozási felületek, az API-k............................................................................. 44 A CryptoAPI ........................................................................................................................... 45 A CDSA .................................................................................................................................. 45 Szabványosítási kérdések............................................................................................................ 46 Az ITU-T X.509 3. változat szerinti tanúsítványok ................................................................ 49 Internet Engineering Task Force, IETF hozzájárulása a szabványosításhoz .......................... 49 A PKIX RFC 2459 X.509 Certificate and CRL Profile.......................................................... 50 A Simple PKI (SPKI) munkacsoport ...................................................................................... 51 A PKCS, Public Key Cryptography Standards ....................................................................... 51 A PKI szabványok alkalmazásonként. .................................................................................... 52 Elektronikus aláírások PKCS#7 .......................................................................................... 52 Tanúsítvány és CRL formátumok, RFC 2459..................................................................... 53 Tanúsítvány visszaállítási protokollok, RFC 2559. ............................................................ 55 Tanúsítványmenedzselési protokollok, PKCS#10, RFC 2510............................................ 55 PKI tanúsítvány és CRL irányelvek ............................................................................................ 57 Tanúsítvány irányelvek ........................................................................................................... 57 CPS, tanúsítvány gyakorlat ügyrendje .................................................................................... 58 Együttműködő-képesség ......................................................................................................... 58 Útmutatók................................................................................................................................ 58 Hivatkozások............................................................................................................................... 59 1.
melléklet: USA Védelmi Minisztérium (DoD) tanúsítvány profil mintái.......................... 62
2.
melléklet USA Védelmi Minisztérium (DoD) tanúsítvány mintái..................................... 67
3. melléklet
USA Védelmi Minisztérium (DoD) tanúsítvány visszahívási lista mintája....... 77
4. melléklet
Elektronikus azonosító alkalmazások, az SS 61 43 30-as svéd szabvány ......... 78
0 Bevezető ................................................................................................................................... 78 1 Hatály ....................................................................................................................................... 78 2 Normatív referenciák................................................................................................................ 78 3 Definíciók és rövidítések.......................................................................................................... 79 3.1 Definíciók.......................................................................................................................... 79 3.2 Rövidítések........................................................................................................................ 79 4 A fő fájlkönyvtár tartalma ........................................................................................................ 80 4.1 EFPAN (a kártya sorszám fájl) ............................................................................................ 80 4.2 EFPIN (a fő PIN fájl) .......................................................................................................... 80 3
4.3 EFDIR (a könyvtár fájl)....................................................................................................... 80 5 Az EID alkalmazás könyvtár.................................................................................................... 81 5.1 EFAUF (Application Usage File, alkalmazás használati fájl) ............................................. 81 5.2 EFPrK (Private RSA key file, privát RSA kulcs fájl) ......................................................... 81 5.3 EFCIF (Certificate Index file, tanúsítvány index fájl) ........................................................ 81 5.4 EFCERT (Certificate file, tanúsítvány fájl).......................................................................... 82 6 EID alkalmazási szakasz .......................................................................................................... 82 6.1 AID az EID alkalmazáshoz ............................................................................................... 82 6.2 Közvetlen alkalmazásválasztás ......................................................................................... 82 6.3 Közvetett alkalmazásválasztás .......................................................................................... 82 7 Alkalmazás használati fájl........................................................................................................ 82 7.1 Közös adattípusok ............................................................................................................. 83 7.2 Az AUF fálj tartalma......................................................................................................... 84 7.3 PIN információk................................................................................................................ 84 7.3.1 PIN formátum............................................................................................................. 85 7.3.2 PIN flag-ek ................................................................................................................. 86 7.3.3 PIN irányelvek............................................................................................................ 87 7.4 Kulcs információk ............................................................................................................. 87 7.5 CA tanúsítvány információ ............................................................................................... 89 8 Tanúsítvány fájlok.................................................................................................................... 90 A.
melléklet - Alkalmazási és fájl azonosítók (normatívák).................................................... 91 A.1 Alkalmazás azonosító (AID) ................................................................................ 91 A.2 Fájl azonosítók ..................................................................................................... 91
B.
melléklet - Példa egy EID alkalmazási fájl struktúrára (tájékoztató).................................. 92 B.1 Általános megjegyzések ....................................................................................... 92 B.2 Definíciók ............................................................................................................. 92 B.3 Egy EID logikai modellje ..................................................................................... 92 B.4 Közös adatfájlok ................................................................................................... 93 B.5 Alkalmazásfüggő fájlok........................................................................................ 93
C.
melléklet Az EID specifikus fájlinformációk kódolása (informatív példák) ...................... 94 C.1 Az AUF fájl kódolása ....................................................................................................... 94 C.2
A DIR fájl kódolása..................................................................................................... 96
C.3
A PAN fájl kódolása ................................................................................................... 96
C.4
A Subjct Key Hash érték számítása ............................................................................ 96
4
Bevezetés Az Internet technológiát alkalmazó, összekapcsolódó hálózatok és információs rendszerek szabványos, elosztott biztonsági architektúrájának kialakítása sok évre visszanyúló, hosszú folyamat, amely végső soron megteremeti az elektronikus kereskedelem feltételeit. Az ezredforduló idején az elektronikus aláírás törvényi szintű szabályozása az architektúra bizonyos összetevőire a közvélemény és a politikusok figyelmét is ráirányítja. Az elektronikus aláírás jogi kérdéseinek rendezése felgyorsíthatja a biztonságos üzenetkezelés és általában az elektronikus kereskedelem hazai elterjedését is, azonban hiba lenne azt gondolni, hogy ezzel minden feltétel teljesült. Közismert, hogy az elektronikus aláírás az RSA féle kétkulcsos titkosítás alkalmazására épül1, ezért használata elképzelhetetlen a támogató nyilvános kulcsú infrastruktúra (Public Key Infrastucture, a továbbiakban PKI) megfelelő fejlettsége nélkül. A PKI szolgáltatásai az azonosítás, jogosítás, titkosítás és a digitális aláírások kulcs menedzsmentjének fontos, általános eszközévé válnak számos Internet/intranet alkalmazásban, beleértve a biztonságos üzenetkezelést és az elektronikus kereskedelmet. A PKI menedzselését illetően azonban jelentős kérdések még megválaszolatlanok, ezért a szervezetek fejlesztőinek, beruházóinak megfontoltan kell dönteniük, miként, mikor és hol telepítsenek PKI termékeket. Sok szállító terméke nem fedi le teljesen a szervezet infrastrukturális igényeit és még időbe telik, míg a konzisztens, PKI szabványú elemek teljes mértékben rendelkezésre állnak. Addig is a PKI-t igénylő alkalmazások fontossága miatt fel kell készülni az együttműködésre képes, hatékony infrastruktúrák elkerülhetetlen telepítésére. A PKI jellemzőinek és a használata során felmerülő potenciális problémáinak megértésével jobban felkészülhetünk alkalmazására (1,2,3,4,5,6,7). Már évek óta, mikor a kliens személyi számítógépekre telepítjük a Netscape Navigátor, vagy a Microsoft Internet Explorer böngészőket, egyben telepítjük a WEB szerverek tanúsítványait is a nyilvános kulcsaikkal együtt, amely biztosítja az SSL alapú kommunikációt vagy a Java és ActiveX szoftverek digitális aláírás ellenőrzését. A csoportmunkát támogató Lotus Notes szintén a nyilvános titkosítást alkalmazza. A PKI licencek tekintetében az RSA kapcsolatokkal rendelkező VeriSign-t és a Northern Telecom érdekeltségű Entrust-ot érdemes megemlíteni. A következő lépés az infrastruktúra fejlesztésében a szervezeten belüli kulcs menedzsment és név/címtár szolgáltatások használatának elősegítése. Ezeket pedig a Microsoft Windows 2000 natívan tartalmazza. Az elektronikus aláírások használatának elterjedését biztosító jelentős fejlesztések és beruházások kudarcait elkerülni, illetve kezelni csak a kellő időben elvégzett architektúra tervezéssel lehet. Az architektúra tervezés figyelembe veszi a megrendelő/tulajdonos és a felhasználó/előfizető közötti lánc minden szereplőjének igényeit és meghatározza a rendszer összes elemét, valamint kapcsolatukat. A szabványokon és ajánlásokon alapuló architektúra mindenki számára érthetően közvetíti a feladatokat és jellemzőiket. Jelen írásban az együttműködésre képes hazai PKI architektúra megvalósításának feltételeit tekintjük át, az architektúra tervezés lényegi jellemzőinek fényében. Az informatikai architektúra tervezésről a szerző négy éven át a BKÁE Vezetőképző Intézetében tartott előadásai szolgálhatnak részletekkel.(8) 1
A Massachusetts Institute of Technology professzorai Ronald Rivest, Adi Shamir és Len Adleman 1977-ben szabadalmaztatták a nevükről elnevezett RSA nyilvános kulcsú kriptográfiai rendszert (Public Key Cryptosystem). Eltekintünk az USA Szövetségi Kormányzat Digital Signature Algorithm (DSA) NIST FIPS 186 szerint definiált rendszerétől, amely jelenleg még korlátozott körben kerül alkalmazásra, bár egy időben ingyenes megoldásként kívánták terjeszteni világszerte a Capstone javaslat részeként.
5
A megbízható és hiteles elektronikus kommunikáció, az információvédelem megvalósítása Az információs rendszerek és hálózatok legfontosabb feladata, hogy bárhol és bármikor szolgáltassák a szervezet alkalmazottjai és ügyfelei számára az őket megillető információkat, de csak azokat. Az informatikai hálózatokon az adatok, illetve információk biztonságos cseréjéhez biztosítani kell −
az adatszolgáltató és az adatot fogadó azonosíthatóságát, azaz hitelességét;
−
az információk sérthetetlenségét;
−
az információcsere letagadhatatlanságát.
−
az információk védelmét, bizalmas voltát.
A feladatot az információk titkosításán túl a digitális aláírás és az ezekhez szükséges titkosító kulcsrendszer kialakításával oldják meg, úgy, hogy a kulcsok kiadását, nyilvántartását u. n. „hitelesítő hatóság”-ra bízzák. A hitelességhez szükséges naprakész adatok biztosítása komoly apparátust igényel. Ennek alapja, belső kulcsrendszer esetében a humánpolitikai osztályok nyilvántartása lehet, illetve országos körben az állami szervek, a belügyminisztériumok népesség-nyilvántartása, a cégnyilvántartás, a társadalombiztosítási, vagy az adózók nyilvántartása, de például szűkebb körre elterjedt az orvosi kamarai tagság alapján kiadott tanúsítvány is. A „piaci hitelesítő hatóság” –ként jobbára azonban, egy független, harmadikfelet alkalmaznak. Magyarországon magán cégek (pl. Netlock, Pik-sys) már évek óta foglakoznak titkosító kulcs kiadással és az akadémiai szféra (SZTAKI, ELTE) is üzemeltet ilyen rendszereket, azonban államilag garantált rendszer nincs. Több európai országban is a belügyminisztériumok által kezelt népesség-nyilvántartás alapján az állam által hitelesített tanúsítványokat, elektronikus személyi azonosító okmányokat adnak ki. Az informatikai biztonsági rendszerek jelentősége az elektronikus kereskedelem térhódításával együtt különösen növekszik. Az elektronikus kommunikáció biztonságos hálózati megoldásainak gyors elterjedését elsőként a banki szektor szorgalmazta a különböző bankkártyás alkalmazások biztonságosabbá tételére, de mind az Európai Bizottság, mind az egyes fejlett nyugati kormányok kötelességüknek érzik a folyamat támogatását. A biztonságos információcsere hiánya akadálya az elektronikus gazdaság és az elektronikus kormányzás (egovernment) fejlődésének is. A világon az egyik legelterjedtebb rendszer, amely a WEB szerverek és az azokat használó ügyfelek közötti adatátvitelt is titkosítja a VeriSign cégé. A VeriSign az USA szövetségi kormányzat tenderét megnyerve a kormányzati szervek és az állampolgárok közötti védett forgalom biztosítását is ellátja. A digitális aláírás használatát biztosító szolgáltatás és infrastruktúra összetettségét mutatja, hogy a VeriSign a következő témákban ajánlja szolgáltatásait: Digitális aláírás és szervezeten belüli két kulcsos megoldások; Tűzfalak, és telepítésük; Behatolás és sebezhetőség teszt; Virtuális privát hálózatok tervezése, telepítése; Biztonsági oktatás; Biztonsági politika és infrastruktúratervezés; WEB tükrözés; Behatolás detektáló eszközök.
6
A digitális aláírások képzését biztosító hash függvények és az elosztott alkalmazások, az Internetes hálózatra előnyösen alkalmazható kétkulcsos, aszimmetrikus titkosítás feltalálása a kilencszázhetvenes évek végén volt. 1995-96-óta pedig pilot projektek és szűkebb körű alkalmazások sora működik szerte a világon. Több esetben az intelligens kártyák alkalmazásával, melyek alkalmazásának elősegítésére a OSI (Nemzetközi Szabványosítási Szervezet) első azonosító kártya szabványai 1993-94-ben már kiadásra kerültek (ISO/IEC 7812, illetve 7816). A digitális aláírások használatának elterjesztésre az egyik fő szempont az állami példamutatás a saját közigazgatási tevékenységben, illetve a vállalatokkal, állampolgárokkal való együttműködésben. Ennek megoldása a divatos kifejezéssel élve az e-Government, az elektronikus kormányzat kialakulásának segítése. Az 1999. évi EU irányelvekkel összhangban, sok országban létezik törvény a digitális, vagy elektronikus aláírásról. Ez nemcsak az EU jogharmonizáció szempontjából, hanem a nemzetközi gazdasági kapcsolatok területén is fontos eredményt hozhat. Az EU tagországok többsége már 1997-98-ban törvényt hozott a digitális aláírásról. Ausztria azonban csak 1999 tette ezt, azonban jellemző módon most az elsők között van - a németeket megelőzve - az általuk "Bürgerkarte"-nak nevezett állampolgári kártya bevezetésében. Hasonló, de már megvalósított személyi azonosítót használnak a finnek (1997-98) a svéd (EID (electronic identity card) példa alapján, de meg kell említeni a 2000 nyarán bevezetett olasz IEIC (Italian Electronic Identity Card) azonosítót is vagy a hasonló dán állampolgári kártyát, amely már 1996-ban elkészült azonban politikai megfontolásokból nem terjedt el. Az osztrák, finn, olasz példákban közös, hogy a népesség-nyilvántartás adatai alapján a kormányzati szervek bocsátják ki, és személyi azonosító okmányként használható a mellett, hogy az államigazgatási eljárásoknál a digitális aláíráshoz szükséges kulcsokat és tanúsítványt is hordozza. Ma már az állampolgári kártya használatához Magyarországon is kialakultak azok az országos információs és adatátviteli rendszerek, melyek a lakosság túlnyomó részét is ki tudnák szolgálni, amennyiben a közigazgatásban használt sokféle rendszer együttműködése megoldható. Más országok ugyancsak alulról kezdték.
Digitális aláírások a technológiai, igazgatási és jogszabályi feltételek áttekintése A kilencvenes években az elektronikus aláírásokat, az adatok és üzenetek titkosításával együtt szigetszerű alkalmazásokban már elterjedten használták a fejlett informatikai infrastruktúrával rendelkező országokban. Az információs társadalom fejlesztésében élenjáró G-7-es országok, elsősorban az USA Kormány ösztönzésére, nemcsak a technológiai, infrastrukturális fejlesztéseket támogatták, de jogszabályokkal és az államigazgatási alkalmazásokkal is ösztönözték a biztonságos elektronikus tranzakciók eszközét a digitális aláírást és titkosítást. Több évre visszanyúló előkészítő munkát és infrastruktúrafejlesztést követően a 2000 év tájára látják indokoltnak, hogy belefogjanak a szélesebb körű konkrét megvalósításba. Egy 1998-as, a digitális aláírás műszaki és jogi kérdéseit sokoldalúan bemutató, svéd kormányzati dokumentum (9) jól példázza a feladat összetettségét. Az Európai Bizottság 1993 óta tartja napirenden (10) és 1996 óta irányelvekkel is ösztönzi az elektronikus kereskedelem elterjedésének alapfeltételének tekinthető bizalom teremtő rendszer egységes megvalósítását. Az 1999/93/EC EU irányelvek pedig EU szinten egységes keretet biztosítanak a törvény által
7
szabályozott módon működő, hiteles harmadikfélként megjelenő minősített tanúsító hatóságok tevékenységének, és általánosságban az elektronikus aláírás használatának. Az egyes európai országok meglévő törvényeiket az EU irányelvekhez igazították 1999-2000ben, illetve, ahol ilyen törvény nem volt, pl. Csehországban, ennek figyelembe vételével hozták meg az elektronikus aláírásról szóló törvényt (később Magyarországon is). Például Svédországban az 1999/93/EC EU irányelvek harmonizációjára készített ”minősített elektronikus aláírások”-ról szóló 2000. évi újabb törvényjavaslatot a svéd kormány 2000. májusában terjesztette be a Parlamentbe. Ebben a felügyelő hatósági szerepre a HIF-nek megfelelő Nemzeti Postai és Távközlési Hivatalt javasolja. A sokféle elektronikus aláírás biztonságosabb, technikailag, jogilag is védettebb formája a minősített digitális aláírás. A digitális aláírások használatának elterjesztésre az egyik fő szempont az állami példamutatás a saját közigazgatási tevékenységben, illetve a vállalatokkal, állampolgárokkal való együttműködésben. A kormányzatnál munkacsoport alakult. A munkacsoport az igazságügyi, külügyi, honvédelmi, közlekedési és távközlési, kereskedelmi és ipari, pénzügyi valamint a belügyi tárcák képviselőiből állt. A csoport munkáját az Országos Postai és Távközlési Hivatal és külső szakértők is támogatták. Felhasználták a svéd IT infrastruktúra projektek (1995-től) eredményeit, mint a (Allteminalen (AT, totális terminál), amelyek kapcsán a Rendőrség, a Honvédség, az Állami Hivatal, a Svéd Biztosító Hivatal, az Országos Adóhivatal és az Adatfelügyelet menedzselt és AT kártyákat bocsátottak ki a kártyás bejelentkezésre. Ez az aktív kártyás megoldás, ami lényegesen biztonságosabb, mint a klasszikusan elterjedt jelszavas bejelentkezés.) és a SEIS (1995) kereteiben végzett munkát. Az 1999/93/EC EU irányelvek szerinti svéd Minősített elektronikus aláírásokról szóló SFS 2000:832 törvény végrehajtásának előkészítésére megbízták az Országos Adóhatóságot, az Országos Társadalombiztosítási Tanácsot, a Svéd Szabadalmi Hivatalt és a Közigazgatás Fejlesztési Hivatalt, hogy vizsgálják meg és dolgozzanak ki javaslatokat a digitális aláírások biztonságos menedzseléséhez szükséges felelősségi viszonyok megszervezésére. A javaslat elkészítési határideje 2000. október 1. volt, amely alapján a intézkedés történt, hogy első lépésben az Adóhivatalnál és a Rendőrségnél bocsássanak ki tanúsítványokkal ellátott intelligens kártyákat a meglévő rendszerek továbbfejlesztése során. Az eredményességet támasztja alá a svéd Igazságügyi Minisztérium 2000. december 20-i sajtóközleménye, melyet a januári számítástechnikai lapok is átvettek az alábbiakat tartalmazza: "A Kormány törekszik az Interneten az aláírás használatára Svédországban a vállalatok és az egyének a kormányhivatalokkal az Interneten át fognak tudni kommunikálni még olyan ügyekben is, amelyekhez aláírás szükséges. Ez a Kormány célja az Országos Adóhivatal (Rikskatteverket) megbízásával, hogy koordinálja az elektronikus azonosító és elektronikus aláírás rendszerek és rutinok készítését az állami hatóságok számára. Finnország a világon az első az elektronikus azonosításban és tanúsításban. Svédország reméli, hogy gyorsan utoléri. Ezen a tavaszon például a vállalatok a havonkénti ÁFA bevallásaikat és az alkalmazotti adóikat elektronikusan adhatják be, és egy éven belül az Adóhivatal tervezi, hogy az egyéni adófizetőknek is lehetővé teszi, hogy az éves adó visszatérítéseiket az Interneten nyújtsák be. A közeljövő tervei szerint az egyének és a társadalombiztosítási irodák közötti kapcsolatokat az Interneten át fogják kezelni olyan esetekben, mint az egészségügyi és gyermekjóléti segély kifizetések. Több mint 3000 cég jelentette be, hogy érdekelt az ÁFA bevallások hálózaton át történő benyújtásában. 8
Britta Lejon, a demokrácia és közigazgatási ügyek minisztere szerint ez fontos lépés a "24 órás közszolgálat" megvalósítása felé. A miniszter asszony azt mondja, hogy mivel a svédek a banki, pénzügyi és kereskedelmi ügyeiket az Interneten bonyolítják, nincs semmi oka, hogy a vállalatok és az egyének miért ne kezelhetnék kapcsolataikat a közhivatalokkal ugyanazon az egyszerű és hatékony módon. Forrás: Ministry of Justice, 20 Dec 2000, Computer Sweden, 10 Jan 2001, Dagens Industri, 11 Jan 2001 (ISA)" Svéd eredmények, AT és SEIS kártyák a digitális aláírásra Az alábbiakban véletlenszerűen kiragadva néhány svéd példát ismertetünk, melyek jól mutatják az elektronikus aláírás széleskörű bevezetését megelőző aprólékos munkákat és kisebb kiterjedésű kísérleteket. A bevezetési folyamatnak 2-3 év multán még mindig nincs vége, sőt a technológia éretlensége folytán az óvatosak további évekre javasolják a fontolva haladást. Az intelligens kártyák, digitális aláírás, és a tanúsítványok elterjedésének kezdetén Svédországban létrehoztak egy számítógépes bűnözési munkabizottságot, mely fontos jogi vonatkozású javaslatokat tett, például a CA-k tanúsítási és ellenőrzési kérdései vonatkozásában, a CA-k felelőssége vonatkozásában az aláíró, a tanúsító felek és az állam viszonyáról. Ma már ezeket szabványos ajánlások, illetve a digitális aláírásokkal kapcsolatos törvények írják elő. Sok másvonatkozásban azonban indokolt foglakozni a munkabizottság eredményeivel. 1997-ben kezdik kibocsátani a SEIS EID kártyákat, miután a Toppeldarforum elfogadta az IT az állami, városi és regionális kormányzatok biztonsági megoldását, amely az aktív kártyák három alapfunkciójának használatán alapul. A honvédség 1994-95-ben fejlesztette ki az azonosításra, digitális aláírásra és titkosításra szolgáló aktív kártya rendszerét. A vámhatóság már 1991-ben ajánlotta a szimmetrikus kulcsú digitális aláírás használatát az export-import engedélyeknél. 1997-ben tértek át az AT kártyákra, most 500 cégnél 700 kártya van. A műveletek ¾-e elektronikus. (de nem alkalmaznak CA-t) A Svéd Adóhatóság szintén az Allteminalen-t választotta, jelenleg 13000 AT kártyahasználó van, ezekből 3000 a rendészeti szolgálatnál. (A teljes kiépítéskor 15000 lesz.) Mintegy 250 hivatalnok jogosult kiadni a szigorú autentikációt biztosító kártyát. A Rendőségnél 25000 Allteminalen kártyát használtak már 1996-97-től, 15000 stabil és 2000 mobil munkaállomáson. Az ügyészségi előírások szerint azonban az iratok papíralapúak, így itt nem használható a digitális aláírás az elektronikus irat törvényi elfogadásáig. A biztosítóknál szintén 15000 munkaállomásra telepítettek 1997-ben AT kártyákat. Az AT kártyákat kimondottan csak azonosításra használják. A Stockholm megyei Danderys kórházban az Allteminalen-hoz hasonló megoldást vezettek be a kórlapok és más információk adminisztrációjára és ellenőrzésére. Az egészségügyben a Svéd Posta által kibocsátott SEIS kártyák bevezetésén munkálkodtak a stockholmi Huddinge kórházban és több regionális közgyűlés hivatalában, 2000-ben azonban már országos rendszer kiépítése folyt. Az egészségügyi digitális aláírások algoritmusára CEN szabvány van az ENV 12388 számon. 1997-tól a Stockholmi Műszaki Egyetem diákjai a vizsgajelentkezéseiket az IDOL diákigazolvány digitális aláírás funkciójával igazolják. (http://idol.promotor.telia.se)
9
Kártyaalkalmazásokat használnak a kórházi közbeszerzésekhez. Az egyik legnagyobb és leghosszabb projekt a nyugdíjas kártyák kibocsátása volt, amellyel a nyugdíjalap egy részének egyéni részvényportfoliós kezelését oldották meg. A Svéd Pénzügyi Felügyelet 10 banknál és biztosítónál alkalmazza a Svéd Posta által kibocsátott aktív kártyát, de csak azonosításra és titkosításra. A Nordbank 1997-ben bocsátott ki aktív kártyát 10 000 ügyfelének fényképpel, vagy a nélkül. (bérek, új jogosultságok és hozzáférés a megtakarítási számlákhoz.) A GIRO a rendszert 1998 első negyedévében vezette be. A Stockholmi Tervezési Bizottság űrlapjai Stockholmshemből a Posta (CA is) által kibocsátott SignOn kártyákkal használhatók az Internetről. A Kereskedelmi Bank a hálózatos azonosítást és autentikációt választotta (SSL). SET – 1995 Visa, MasterCard a svéd kísérletben 40 kereskedelmi pont és 8000 magán ügyfél vesz részt, várják a kártyák 2001. nyarára ígért korszerűsítését, ami az intelligens kártyákra történő áttérést jelentené. Jogszabályi vonatkozások A formával kapcsolatos követelmények A jogszabályi előírások bizonyos esetekben az iratokra megkövetelik, hogy írásos formában, személyes aláírással és egy eredeti példányban készüljenek. A személyes aláírásban benn foglaltatik mind az aláírás, mind az eredeti fizikai formátum. Az előírások nem teljesülése különböző következményekkel járhat. Bizonyos esetekben az okmány birtoklása, jelenti a benne szereplő jogok gyakorlást. (pl. váltó). A fő ok azonban a jogbiztonság és a hatékonyság bizonyos, főként gazdasági tevékenységeknél. Ilyen például bizonyos tevékenységek tanúsítása, ki csinálta, mire vonatkozott. Más esetben az állam bizonyos tevékenységeket támogat, pl. az adózáskor. A formai követelmény figyelmeztető is lehet, hogy az irat elkészítése, kiadása jogokat, kötelezettségeket adhat, vagy ruházhat át, azaz bizonyos jogi következményekkel jár. A formai követelmények országról-országra változnak, így a nemzetközi tranzakcióknál bonyodalmak merülhetnek fel. A szerződések formája a nemzetközi polgári jogban speciális helyzetű. A szerződés érvényes, ha a szerződésben érintett ország, vagy a szerződés szerinti jogügyletet bonyolító ország formai előírásainak megfelel. (kivételek a Római Egyezmény 9. cikkelye szerint). Az elektronikus kommunikáció esetén problémák lehetnek a hely meghatározásával. Az elektronikus dokumentumok különböznek a papírformájúaktól. A megkövetelt aláírással problémák lehetnek. Az országok joganyagát külön-külön kell megvizsgálni. Például az 1994-1996-ban lefolytatott svéd IT vizsgálat 562 helyen talált „aláírás” és 1095 helyen „írásban” előírást. Néhány közülük: −
Ingatlanok adás-vétele.
−
Bíróság előtti képviseletre ügyvéd felhatalmazása.
−
Éves pénzügyi beszámolók.
−
Cégszerű aláírások
−
Végrendeletek
Bizonyítékok 10
Még abban az esetben is, ha nincs formai előírás az írásos formának és az aláírásnak nagy jelentősége van. A svéd bíróság előtti bizonyításban nincs különbség a papír és a digitális aláírás között, inkább gyakorlati kérdések merülnek fel: az információ eredete és megbízhatósága. Az IT anyag értékelése technikailag bonyolult lehet. Miként biztosíthatók a megfelelő szakértők. Mindezeket a Számítógépes Bűnözéssel foglalkozó munkacsoport (SUO 1992:110) és az Európa Tanács R (95) 13-as ajánlása az IT-vel kapcsolatos bűnügyi eljárási jogról részletesen tárgyalja.
Ellenőrzési kötelezettség hamisítás, csalás gyanúja esetén. Általában a hitelező bizonyítja a dokumentum eredetiségét, ha az adós azt kétségbe vonja, ha azonban a hiteles dokumentum tartalmi megváltoztatásról (a teljesség kérdése, tartalmihamisítás) van szó, az adósra hárul a kötelezettség. A bankkártyákra például a svéd Legfelsőbb Bíróság 1992-ben hozott ítélete szerint a kártya használójának kell bizonyítania, hogy a csalás lehetősége legalábbis fenn áll. Ha ez teljesül a kártya kibocsátó cégnek kell bemutatnia, hogy a megbízás eredeti volt az adott esetben. A polgári jog kérdései Normál szerződések. Az EDI kapcsolatok jelenleg zárt hálózaton bonyolódnak. A digitális aláírások elterjedésével elképzelhető a kapcsolatok nyílt hálózatú és széleskörű szervezése is. A CA tevékenységre szabványos előírások vannak az u.n. Certification Practice Statement, CPS-szerint. Szabadalmak Az aláírási és hash algoritmusokat szabadalmaztatják. Van egy szabadalommal védett technológia arra, hogy a kártyák egy aktiválásával csak egy aláírást lehessen végezni. Aláírási algoritmusok: RSA, nemzetközileg (ISO, ISO/IEC) szabványosított. Az USA-ban szabadalommal védett, de Európában szabadon használható. DSA az USA DSS része, de a NIST is szabványosította, és ingyenes lesz a használata, bár jelenleg szabadalmi viták vannak körülötte. Elliptikus görbék alkalmazását az elektronikus aláírásokra még nem védték le, más hatékony alkalmazások azonban szabadalmazottak. Hash algoritmusok: a legáltalánosabbak nem védettek szabadalommal, de szabványosságuk sem teljes körű. Bűnügyi kérdések Az OECD No. 10. jelentése (Computer-related Crime: Analysis of Legal Policy, 1986) és a Európa Tanács foglalkozott már a kérdéssel (R (89)9 recommendation on Computer- related Crime és az EU Bizottság 1990-es végdokumentuma a kriminalisztikai problémákról.) Az IT területen a svédeknél az adatvédelmi törvény bevezetésével kapcsolatos intézkedések és az
11
1983-as bűnözés a tulajdon ellen jelentés (SOU 1983:50) jogi védelmet ad, kivéve az okmányokkal kapcsolatos bűnözést. Az elektronikus iratok, okmányok eredetiségének, hitelességének bizonyításának eszköze a digitális aláírás. Más fizikai zárakhoz hasonlóan kétséges, hogy bármely elektronikus zár abszolút védelmet nyújtson a betörés, hamisítás ellen. Az alkalmazásához meg kell vizsgálni a feltételeket és korlátokat. A digitális aláírás célja annak megállapítása, hogy ki készítette az elektronikus iratot, valamint, hogy az iratot nem változtatták meg. Az elektronikus aláírási rendszer sikeres bevezetéséhez az elképzelésnek élveznie kell a társadalom bizalmát. Ez nem csak magas biztonságot jelentő technológiai megoldást igényel, hanem a megfelelő bűntetőjogi szankciókat is a technológiával kapcsolatos visszaélések esetére. A jelenleg használatos EID kártyák PIN kódokkal védettek. Normál használat esetén a vizuális igazolványoknál, bankkártyáknál már megszokott jogi és funkcionális védelmek alkalmazhatók. A kérdés hogyan védhetők a PIN kód és a kártyán tárolt digitális adatok. A jelszavakkal való visszaélésekre új büntetési tényállást javasolnak. Meg kell például határozni, hogy a tárolt adatokkal a chip mikor tekinthető jogi szempontból okmánynak, dokumentumnak. Mi történik, ha nem a jogos tulajdonos használja az EID-t. Hogyan lehet ezt egyáltalában megállapítani. Felvetődik a kérdés, hogy minden idegen használatot büntetni kell-e. Egy másik fajta visszaélés a digitális aláírással a korábbi aláírás letagadása. Ennek bizonyítása mindenképpen sok munkát jelent és csökkenti a bizalmat ezért ezt ugyanúgy célszerű büntetni, mint a hagyományos esetekben. A bűnüldöző szerveknek ügyészi vagy bírói felhatalmazással, bizonyos esetekben a normálisnál több jogot kell kapni. (pl. az aláírást, titkosítást biztosító titkos kulcs párok visszafejtése) Itt finom egyensúlyozás van az egyéni jogok és a társadalmi érdek védelme között. Az igazgatási jog kérdései A svéd AHT nem követeli meg a hivatalokba küldött dokumentumok aláírását, azonban a hatóság kérheti ennek személyes jóváhagyását egy másik csatolt dokumentumban a lex specialii-ban. Az elektronikus dokumentumok1998-ra már 30 svéd jogszabályban szerepeltek. Ezekben az elektronikus dokumentumot úgy definiálják, mint amely tartalmát és kezdeményezőjét bizonyos technikai folyamatokkal lehet meghatározni. Használatuk főként a vám és az adózás területén szabályozott a rendészeti szerveknél és a jelzálog bejegyzéseknél. A Parlament szerint vám és adózás esetén a fogadó hatóság speciális engedélye szükséges. Ilyen például a Svéd Vámtanács TFS 1994:45 számú szabályzata. Az elektronikus adózás alapjai 1994-ből származnak. A javaslat szerint az elektronikus fájl tartalmazhat elektronikus dokumentumokat és a papír dokumentumok elektronikus másolatait. A kétféle dokumentumot egyenrangúnak ismerik el, és 1998 óta mind a központi, mind a helyi adóhatóságok engedélyezhetik az elektronikus adóbevallást, azonban csak az aláírást nem igénylő mellékletek nyújthatók be elektronikusan. A rendszerhez az ELDA diszk tartozik, amelyen megtalálható a szükséges szoftver, a titkos és nyilvános kulcs a tanúsítvánnyal. 1998tól az adóhatóság WEB technológiát fejleszt, u.n. IN/OUT platformon, SSL protokollal. Archívumok Az archívum kifejezés itt elsősorban a funkciót és nem az intézményt, vagy az okmánytárat jelenti, amely utóbbiak évszázadokon át biztosították, hogy a jogokat és kötelezettségeket 12
dokumentáló okmányokat megmaradjanak. Az idők során ez a funkció is változott, a jogi szempontok helyett a fő hangsúly átkerült az őrzött papírok vizsgálatának főként tudományos és kulturális szempontjaira. Ezzel az archívumok jelentősége a jogbiztonság megőrzése szempontjából leértékelődött, az utóbbi években azonban ismét elismerik a törvényalkotásban az archívumok jelentőségét. Az archívumokról készült svéd 1990:782 törvény (1991. július 1) alapján az Országos Levéltár új szabályokat vezetett be, amelyben részben felülvizsgálták az archiválási gyakorlat kodifikációját. A leglényegesebb a médiumfüggetlenség szabálya, amely minden fajta okmányra (papír, számítógéppel előállított rekordok, mikrofilmek, stb.) érvényes. Lehetővé teszi a részletek felesleges ellenőrzésének elhagyását, inkább a levéltár számára legalkalmasabb módszerek alkalmazását támogatva. Az egyetlen korlátozás, hogy az előállított okmányok olvashatóak és átvihetőek legyenek idővel az új tároló médiumokra, minden lényeges minőségvesztés nélkül. A számítógépes rekordokról: A levéltári archívumok a nemzeti kulturális örökség részei. A levéltári archívumokat meg kell őrizni, rendben tartani és úgy gondozni, hogy biztosítsák a közokiratok vizsgálatának jogát, a jogalkotási adminisztráció és a kutatási szükségletek információ igényét. A számítógépes dokumentumok archiválása számos problémát vethet fel. A módosítások, jogosulatlan változtatások, stb. elleni védekezésül a rendszerek jogosultság ellenőrzése, a biztonsági másolatok és a másolatok különböző, biztonságos helyen való tárolása szükséges. Az állandó, megbízható adathordozó anyagok hiánya miatt az adatokat rendszeresen új adathordozókra kell átvinni. Ehhez tartozik, hogy a műszaki berendezések hamar elavulnak a gyors fejlődés következtében. A gyors technikai fejlődés további problémát is felvet, nevezetesen a sokféle adatformátumot, a betűkészletek, fájl formátumok, tömörítési módszerek, stb. szerint. A fenti példák az állami feladatok egész sorát vetik fel, melyek ellátásra a közigazgatás informatikai szakterületének kell felhívni a figyelmet. A kérdések helyes, a magyar környezetben megfelelő felvetésére, feladatok kimunkálására projekteket kell indítani.
13
A német digitális aláírás törvényről (11) A kriptográfia alkalmazásáról sok politikai vita folyik, különösen a bizalmasság területén. A digitális aláírás bizalmasságához nem akarunk hozzányúlni. Az egyetlen cél az aláíró személyazonosságának a megállapíthatósága, és az üzenet megváltoztathatatlanságának a biztosítása az on-line hírközlés területén. Ebből a szempontból Németországban a kriptográfia alkalmazása területén teljes a szabadság. Minősített digitális aláírás - mit jelent ez? A Digitális Aláírás Törvény csak a minősített digitális aláírással foglalkozik. A minősített aláírást adó technológiák az összes létező technológiáknak csak mintegy 5 %-át képezik. Ez az 5 % engedheti meg magának a minőségi jelzőt. A biztonsági szint, amire szükség van, egy sor technikai komponenst tételez fel. Ilyen például a titkos kulcsok tárolásának a módja. Ezen kívül néhány technika funkciót is el kell látni. A német törvénykezés nem ír elő semmiféle konkrét technológiát. De előír néhány technikai feltételt a biztonság érdekében. Ez nem egy könnyű feladat. Akadémiai viták folynak arról, hogy mi a technika-semleges, és mi nem semleges. Olyan feltételeket adtak meg, amelyek szerintük nem függnek a technikai megoldásoktól. Ilyen például az, hogy mik a biztonságos adattárolás feltételei. Egy technikai feltétel például az, hogy senki se tudja elolvasni a titkos kulcsot, még a Hitelesítő Hatóság sem. Ez vonatkozik a chip-kártyán tárolt titkos kulcsokra is. Minden digitális aláírásnál ez a legdöntőbb, legfontosabb elv. Egy másik fontos biztonsági elv az, hogy a szakértői testület, a Távközlési és Postai Szabályozó Hatóság rendszeresen (évente, vagy ha szükséges, akkor gyakrabban) ellenőrizze a jogosítvánnyal rendelkező szolgáltatókat. Egy harmadik elv, ami nagyon fontos ezen a területen, hogy a felhasználók kellően legyenek tájékoztatva annak a szolgáltatásnak a minőségéről, amit igénybe vesznek. Ha például egy chipkártyát, vagy hitel-kártyát használ, akkor azt ne adja át a titkárnőjének egyetlen alkalommal való használatra sem. A felhasználónak tudnia kell, hogy ezzel az adott kártyához fűződő valamennyi jogosultságát veszélyezteti. Jó példák Sajtó információ 1998. szeptember 4. Idézet a ZDNet News 1998. szeptember 4-iki számából: "Clinton elnök és az ír miniszterelnök Bertie Ahern Dublinban fejet hajtott az elektronikus kereskedelemnek, mikor a két vezető digitális aláírás technológiát alkalmazott, hogy rátegye személyi "aláírását" egy nyilatkozatra, amely az 14
elektronikus kereskedelem széleskörű koncepcionális kérdéseivel foglalkozik….Ahelyett, hogy tollat használtak volna egy papír okirat aláírására a két vezető notebook számítógépek elé ült, bele tették a saját "aláíró adataikat" tartalmazó kártyáikat, beütötték a PIN kódjukat, ezzel aláírták az USA-Irország nyilatkozatot az elektronikus kereskedelemről," Angolok-svédek: 2000. március 23. „Az angol e-commerce miniszter megkötötte az első papír nélküli, csak elektronikusan létező európai megállapodást. Az ICL által vezetett konzorcium fejlesztette a biztonságos digitális aláírás rendszerét. Első ízben érvényesítettek digitális aláírással két európai kormány közötti megállapodást tegnap, amikor Patricia Hewitt, angol e-commerce miniszter és svéd partnere, Mona Sahlin elektronikus aláírással látták el az Egyesült Kirlyság és a Svéd Kormány közös nyilatkozatát a kisvállalkozásokról és a vállalatokról. Az aláírást az ICL vezette Unitas* konzorcium fejlesztése tette lehetővé. Londonban Ms Hewitt a Royal Mail ViaCode által erre az alkalomra kifejlesztett biztonságos elektronikus aláírását használta, míg Ms Sahlin a személyi azonosító kártyáján már meglévő elektronikus aláírását alkalmazta. Ez utóbbi rendszert a Svéd Posta vállalata, a Postnet hozta létre.” További információ: az eredeti angol szövegből vagy az
[email protected] címen nyerhető. USA Az 1997. július 1-i elnöki rendelet az elektronikus kereskedelemről: "Utasítom minden minisztérium és állami szervezet vezetőjét, hogy támogassák az erőfeszítéseket, amik az Internetet biztonságos környezetté teszik a hazai és a nemzetközi kereskedelem számára. Ebbe értendők a biztonságos és megbízható távközlési hálózatok; az ezen hálózatokra csatlakozóinformációs rendszerek hatékony védelmét biztosító eszközök; hatékony eszközök biztosítása az azonosításra és az elektronikus információk bizalmasságának garantálására, hogy megvédjék az adatokat a jogosulatlan használattól; és biztosítsák az információkat, hogy az Internet felhasználók jól képzettek legyenek, és megértsék hogyan védhetik meg rendszereiket és adataikat." USA Védelmi Minisztérium a közepes szintű bizalmi együttműködés nyilvános kulcsú infrastruktúrája Az USA Védelmi Minisztérium (DoD) számára ajánlatos a nyilvános kulcsú (PK) technológia használata a céltűzések teljesítésére mind a minisztérium katonai, mind a szervezeti feladatai ellátására (12). A DoD a PK technológiát több bizalmi szinten alkalmazza, a magas, közepes és alacsony szinteken. A PK technológia alkalmazásának meggyorsítására, nevezetesen a közepes bizalmi szinten, a DoD egy közepes bizalmi szintű pilot nyilvános kulcsú infrastruktúrát (PKI) telepített 1999-ben, amelyet sokféle alkalmazási területen kíván használni minden szolgálatban 15
és minden ügynökségnél. A PKI alapvető célkitűzése a digitális azonosító szolgáltatások megvalósítása, de a személyes adatok védelmét is támogatja. Felismerve azt, hogy a PKI technológia még nem kiforrott a piacon és gyorsan változik, a DoD stratégiája a korai alkalmazkodás biztosítása és az aktív részvétel az iparral együtt a szükséges részletes műszaki ismeretek megértésében, hogy teljes értékűen meg tudják határozni a követelményeket, megoldhassák a szabványosítási kérdéseket, és felgyorsítsák a teljes iparra kiterjedő konvergenciát a tisztán szabvány alapú, együttműködő kapacitásokra, amely független a szállítói lehetőségektől vagy technológiáktól. A DoD nyilvános kulcsú infrastruktúra célkitűzése az alábbiakkal jellemezhető tanúsítványszolgáltatás: −
Szabványalapú.
−
Sokféle alkalmazás és termék támogatása.
−
Biztonságos együttműködés a DoD, más szövetségi kormányzati végpontok között és az iparral.
−
A digitális aláírás és kulcs csere/titkosítás támogatása
−
A kulcsok funkcionális szétválasztása.
−
A kulcs és adat visszaállítás támogatása.
−
A jogi letagadhatatlanság támogatása.
−
Üzleti alapú, amely az elemek lehetséges, jövőbeni outsourcing-ját lehetővé teszi.
−
Támogatja a FIPS megfelelőségi követelményeket.
Végeredményben a DoD olyan közepes bizalmi szintű pilot nyilvános kulcsú infrastruktúrát valósított meg, amely az X.509 3. változata szerinti tanúsítványokat és a 2. változat szerint visszahívási listákat (CRL) használ, és teljesen szabvány alapú. A DoD pilot erősíti a szövetségi PKI és az IETF szabványosítási tevékenységet, a szabványok kétértelműségeinek feloldásában amint kiderülnek. Meg kell jegyezni, hogy a tanúsítványregisztrálási folyamat szabványosítása továbbra is fejlődésben van, ami szükségessé teszi a szállítók termékeiben alkalmazott egyedi megoldások közbeeső használatát. A DoD szándéka, hogy amilyen gyorsan csak lehet áttér a szabvány alapú regisztrálási megoldásra. A Public Key Cryptography Standard (PKCS)#10 szerinti tanúsítványigénylő interfészt már jelenleg is támogatják. Mindenképpen, amennyiben egyszer már regisztrálták, a kulcsok és tanúsítványok használata már szabvány alapú, és biztosított más a szabványoknak megfelelő alkalmazások támogatása. A DoD PKI pilot program elkötelezetten együtt dolgozik a nagy ipari alkalmazásszállítókkal, hogy biztosítsa a rövid és hosszú távú együttműködést, amelyet a szabványok következetes használatával lehet elérni. A PKI program folyamatosan követi az új és fejlődő IETF szabványokat és a termékeket, hogy biztosítsa a jövőbeni maximális együttműködés támogatására a legéletképesebb kereskedelmi szabványok teljes megerősödését. A DoD a közepes bizalmi szintű PKI pilotra vonatkozóan számos egységre várja a konstruktív ajánlatokat a nagy ipari, technológiai szállítóktól. Ebbe bele tartozik a DoD PKI Medium Assurance X.509v3 certificate standard profile. A DoD ugyancsak várja a konstruktív ajánlatokat a fejlesztés további vezetésére, valamint a támogatására, ahol lehetséges a szabvány alapú tanúsítványokra történő áttéréshez a meglévő, jelenleg a közepes bizalmi szintű pilotban használt termékek esetében. A meglévő termékek közötti biztonságos együttműködési kérdések vizsgálatának elősegítésére a DoD az alábbi teszt tanúsítványt és kulcs információkat bocsátja az ipari technológiai szállítók rendelkezésére: X.509v3 tanúsítvány profil példája az 1. és 2. mellékletben látható 16
X. 509v2 CRL mintája a 3. mellékletben látható Letagadhatatlanság és e-mail privát kulcsok és tanúsítványok PKCS#12 formátumban készülnek.
Címtárszolgáltatás ITU-T (CCITT) X.500-X.525 (1993) ajánlások, ISO 9594 (directory). A világ első nyilvános telefonközpontjának megnyitásakor 1878 januárjában a 21 előfizetőt a telefonos kisasszonyok ismerték és név szerint összekötötték a hívóval. A telefonközpontokhoz kapcsolt állomások előfizetőinek adatait először inkább reklámként jelentették meg a helyi újságokban, de hamarosan kiadják a telefonkönyveket. Magyarországon 1897-től készítenek telefonkönyvet. A nevek helyett a számokat csak később vezették be, de kétségtelenül hasznosnak bizonyult, mikor a gyors fejlődés következtében már 1892 novemberére működni kezd az első automata telefonközpont. A telefonkönyv készítés szükséglete tehát a hálózat bővülésével egyidős. A mai számítógépes tudakozók, a CD-ROM-os “sárga lapok” (Yellow Pages) korában továbbra is gondot jelent a távoli városok naprakész cím-szám információinak megszerzése. Az elektronikus üzenettovábbítás univerzális használata világméretű automatikus hozzáférésű címrendszert tételez fel. A különböző információtovábbító eszközök végpontjainak azonosítására, országonként, berendezés fajtánként különböző azonosító számsorokat (pl. telefonszámok) használnak. Ezek összerendelését a felhasználóval, tulajdonossal a név szerinti címtárak, telefonkönyvek segítik. Más típusú az Internet címkiosztási struktúrája és a körzeti (domain) névszerver rendszer, de a telefonkönyvek felépítése is országonként változik. Az elektronikus levelezésen alapuló információcsere nem képzelhető el a résztvevők azonosító adatainak ismerete nélkül. A nemzetközi szervezetek már a korai időben elkezdtek foglalkozni egy alkalmas rendszer létrehozásával. Ennek alapján készült el 1993-ban az akkori CCITT, ma ITU-T X.500-as ajánlása. A karbantartott és hiteles, személyhez kötött információk világméretű biztosítására igen jó eszköz lehet az X.500-as rendszerű adatbázisok rendszere. Az X.500-as ajánlás globális, attribútumokon alapuló szabványos rendszerű címtárat hoz létre. Struktúrájában hasonló az Internet (domain) tartománynév rendszerhez Lehetővé teszi a világ bármely országában, azaz az elosztottan kezelt és tárolt adatok egységes használatát. Az X.500-as adatbázis sokféle információt tartalmazhat, melyek között képek, de akár digitalizált hang is lehet. Az attribútumok például: személynév (fényképpel), posta, illetve lakcím, X.400-as, illetve IP cím, telefon, fax, telex számok, printerek neve, címe, stb. Az X.509-es ajánlás meghatározza, hogy a bejegyzések között, milyen formában jelenik meg a kétkulcsos rejtjelezéséhez szükséges nyilvános kód, valamint az ennek hitelességét, aktualitását szolgáló hatósági tanúsítvány, illetve milyen a hitelességet biztosító hierarchia. Minden információ egy bejegyzésnek felel meg, amelyet egy attribútum halmaz és egy hozzáférés vezérlési lista alkot. Az ország bejegyzéshez például ilyen attribútumok tartozhatnak: objectClass countryName description lastModifiedTime, vagy a személy bejegyzésnél az attribútumok: személynév, beosztás, szervezet, cím, telefon, email cím, telefax, valamint becenév, hozzáférési jogosultságok, stb. 17
Az attribútum jellemzői a típus (szöveg, szám, kép, hang, stb.), értelmezés (pl. kis-nagybetű figyelembe vétele), minősítés (pl. kötelező az ország érték), és maga az attribútum értéke. Az attribútumok között egy kitüntetett (leaf) van. Ez hierarchia szintenként a kulcs attrinútum, például a Relative Distinguished Name. Az RDN mindig kötelező. Példa: Country: C=HU, Organization O=MATAV, Org. Unit Ou=Marketing, Név CN=Kiss, Tel= …. Minden bejegyzés azonosítására a megkülönböztetett név RDN szolgál, ami alapján keresni is lehet a rendszerben. A bejegyzések hierarchikusan felépített fastruktúrája a helyi adatbázis kezelőkön DSA-kon (Directory System Agent) található, melyek meghatározott protokoll szerint érik el egymást. A teljes információ alkotja a Directory Information Base-t. Az információk hierarchikus fa struktúrájában a legmagasabb szinten vannak az országot, szervezetet leíró bejegyzések, míg a legalacsonyabb szinten (a levelek) vannak a személyek, gépek. Minden csomóponton a bejegyzések az illető csomópont “gyerekei” (children). A felhasználó a DUA (Directory User Agent) felhasználói felület programmal éri el az adatokat. Külön DSA-DUA protokoll (DAP: Directory Access Protocol) szabályozza a lekérdezést. Ilyen felhasználói művelet lehet: egy bejegyzés információinak kiolvasása egy adott érték összevetése egy bejegyzés egy attribútumának értékével egy csomópont alárendeltjeinek listázása bejegyzések keresése attribútum kulcsok alapján bejegyzések hozzáadása vagy törlése bejegyzések módosítása. Ha a felhasználó által keresett információ nincs meg az adott DSA-n, akkor az továbbítja a kérést, vagy közvetlenül összekapcsolja azzal a szerverrel. Az univerzális telefon elérés biztosítás mellett az elektronikus üzenetkezelés, de még inkább a nyilvános kulcsú infrastruktúra nyilvános kulcsait hordozó és hitelesítő tanúsítványok általános elérhetőségének biztosítása indokolt. A tanúsítványok és visszavonási listák esetében magán a tanúsítványon is megadásra kerül a címtár pontos elérhetősége. Sok esetben felmerül annak lehetősége, hogy a telefonszámok, illetve a levelezési címek hordozható, személyhez, nem pedig lakcímhez, vagy szolgáltatóhoz kötött rendszerét kellene kialakítani, és ezen tárolni minden jellemző adatát születésétől haláláig. Ez természetesen nem az X.500-as címtár, inkább a személyi azonosítás rendszeréhez és a személyzeti, kádernyilvántartáshoz lehetne hasonlítani. Az ilyen, akár egyetlen számon alapuló rendszer igen leegyszerűsíti az egyénnel kapcsolatos sokféle nyilvántartás összevonását, ezért sokan támogatják, de merőben sérti a személyiségi jogokat. Magyarországon az 1992. évi LXIII. törvény szerint, és az Alkotmánybíróság döntése értelmében a személyiségi jogok sérelmét jelentené, így nem alkalmazható olyan egyetlen azonosító szám, amely akárcsak a nyilvántartások közvetlen összekapcsolását is lehetővé tenné. Mindezek mellett nem elképzelhetetlen, hogy jelenlegi társadalombiztosítási azonosító jel, személyi azonosító jel, adószám, bankkártya személyi azonosító jel (PIN kód), stb. mellett minden ember születésekor egy elektronikus levelezési címet, vagy telefonszámot is kaphasson a globális informatikai infrastruktúra kialakulásával.
Az elektronikus kommunikáció és az elektronikus kereskedelem biztonsága Az elektronikus kereskedelem nem pusztán termékek Internetes kereskedelmét jelenti. Az elektronikus kereskedelem, e-business lényegében a hagyományos üzleti, szervezeti, 18
államigazgatási tevékenységek újszerű megközelítésmódja, az új termékekkel. szolgáltatásokkal kapcsolatos kommunikáció automatizálása; új ajánlatok, feladatok ellátásához nyersanyagok, vagy szellemi erőforrások elektronikus biztosítása; az elektronikus ellátási, kereskedelmi csatornák kialakítása és működtetése; és az eladást követő árú és ügyfélmenedzsment. Az elektronikus kereskedelem felgyorsítja a szervezet teljes munkaciklusát, megváltoztatja a marketing gyakorlatot, lehetőséget nyújt a munkafolyamatok és a ráfordítások jobb ellenőrzésére, javítva az eredményességet és nyereséget. A hozzáértők számára hatalmas lehetőséget biztosít. A szervezetek belső hálózatán védett információs erőforrásoknak a partnerek és ügyfelek számára hozzáférhetővé tételével ugyanakkor megnövekszik a kockázata a digitális károkozásnak, amikor bajkeverők egyszerűen, néhány billentyű lenyomásával potenciálisan megfojthatják a szervezet elektronikus kereskedelmét. Az elektronikus kereskedelem működésképtelen a megfelelő vállalati/szervezeti információtechnológiai biztonság nélkül. A biztonsági betörések közvetlen a szervezet működőképességét béníthatják meg. Az informatikai biztonságot veszélyeztető események gyakorisága és az okozott károk költsége drámain növekszik. Az USA-ban az FBI és a Computer Security Institute 1999-es felmérésükben 521 vállalati, kormányzati, pénzintézeti és egyetemi biztonsági szakembert kérdeztek meg. Ezek közül 163-ban tudták számszerűsíteni a veszteséget, amely összegezve 123,8 millió dollár pénzügyi veszteséget mutatott. Azonban a válaszadók több mint fele elismerte, hogy pénzügyi veszteségeik voltak a betörések miatt. Természetesen a veszteségek mértéke függ a cég tevékenységi formájától, attól, mennyire támaszkodik a hálózati kommunikációra. A megelőző évi felmérésben még csak 570 ezer dollár veszteséget mutattak ki azonban ez az 1997. évihez képest 36 százalékkal volt magasabb. A betörések jelentős része belülről származott. A Gartner Group becslése szerint hamarosan a cégek 90 %-a fog jelentős pénzügyi veszteségeket elszenvedni az informatikai biztonsági betörések közvetlen hatására. A legtöbb szervezet manapság igen egyszerűen közelíti meg az információtechnológiai biztonság kérdését. Feltételezik, hogy a "cégen" belül mindenki "jó fiú", és a cégen kívüliek legtöbbje "rossz fiú". A biztonsági tevékenységek abban merülnek ki, hogy korlátozzák a "rossz fiúkat" a belső erőforrások használatában. Az elektronikus kereskedelem ezt a helyzetet drámaian megváltoztatja, megnövelve azok számát, akik kívülről akarják elérni a belső információs rendszereket. A hagyományos szervezeti biztonsági koncepciók és alkalmazások rosszul kezelik az ilyen változásokat. Az elszigetelten működő biztonsági alkalmazások, bár taktikai védelemre megfelelőek, képtelenek a dinamikusan változó követelményeket kezelni, különösen, ha manuális beavatkozást is igényelnek. Az elektronikus kereskedelem biztonságos viteléhez a vállalati biztonságtechnológiákat koordinált együttműködésre kell felkészíteni. A Pricewaterhouse Coopers 1998-as felmérése szerint a rosszakaratú, vagy véletlen biztonsági balesetek okozóinak aránya a következő: alkalmazottak 58 %, ismeretlen eredetű 37 %, külső hacker 14%, korábbi alkalmazott 13%, szerződéses partner, tanácsadó 9 %. A hagyományos szervezeti struktúra három elemet tartalmaz. a felső vezetést, a szervezeti erőforrásokat (közgazdaság-pénzügy, emberi erőforrások, informatika és intézménygondnokság), és a végrehajtó, termelési/szolgáltató részlegeket (fejlesztés, gyártás, kereskedelem, szolgáltatás, ellátás, marketing). A termelési részlegek felső szintjén hatféle elektronikus kereskedelmi alkalmazás ismert, amelyek a következő években egyre meghatározóbbak lesznek: e-marketing, e-eladás, e-szolgáltatás, e-támogatás, e-ellátás és az eműszaki tervezés. Az e-marketing az alapvető WEB alapú alkalmazások, melyeket minden cég kipróbál. Ebből egyesek már tovább lépnek az e-eladás felé, amellyel az Interneten szeretnék eladni termékeiket 19
és szolgáltatásaikat. További differenciálódást jelent a cégek ajánlataiban az e-szolgáltatás és etámogatás alkalmazásainak bevezetése. Sokan a szállítóikkal és ügyfeleikkel integrált ellátási lánc létrehozására e-ellátás alkalmazást fejlesztenek. Néhányan már még tovább mentek a fejlesztő intézetek tűzfalain átmenő közös termékfejlesztés kialakítására e-műszaki tervezői alkalmazások felépítésével. A valóságban, ami nem tűnik fel elsőre, mindezen elektronikus kereskedelmi alkalmazások mélyre nyúló külső hozzáférést biztosítanak a "cég" számítógépes infrastruktúrájába. Az ilyen típusú hozzáférések a korábbi gyakorlathoz képest példa nélküliek és így a biztonságtechnikai alkalmazásfejlesztések legnagyobb ösztönzői. Kockázatot jelentő biztonsági lyukak minden szinten találhatók, beleértve az alkalmazásokat, szolgáltatásokat, adatbázisokat, operációs rendszereket és a hálózatot. A tisztánlátás érdekében a sürgető biztonsági követelmények azonosíthatóságára strukturált megközelítés szükséges, amelyben a veszélyeket és a biztonsági piac megoldásait osztályozzuk, kategorizáljuk és össze tudjuk hasonlítani. A biztonsági menedzsment termékek alapvető célkitűzése a szervezet teljességének, érintetlenségének fenntartása. A globális szervezeti teljesség az elektronikus kereskedelem környezetében öt egymással összefüggő területre bontható: a hálózat teljessége, a rendszerek teljessége, a felhasználói jogosultságok teljessége, alkalmazási /adat teljesség, és az adatok bizalmassága és védelme. Mindenegyes terület a biztonsági megoldások és termékek tekintetében további szegmensekre bontható: − − − − −
Hálózat teljessége: tűzfalak, kommunikációs biztonság. Rendszerek teljessége: vírusvédelem, kockázatelemzés, behatolás detektálás, auditálás. Felhasználói teljesség: felhasználó / felhasználói csoport, egyszeri bejelentkezés, jogosítás (authentikáció), Alkalmazások teljessége: hozzáférés kontroll, felhasználók azonosítása (authorizáció) Bizalmasság: titkosítás
A szervezet teljességének védelmére elsőként a hálózat teljességét kell biztosítani tűzfalakkal és a kommunikációs vonalak védelmével. A második lépésként az egyes rendszerek és a hozzájuk tartozó adatbázisok és alkalmazások védelméről kell gondoskodni a vírus védelem és megelőzés, a behatolás detektálás, a kockázatelemzés és a központosított auditálás bevezetésével. A két első lépés jelen vizsgálódásunk keregtein kívül van. A továbbiakban elsősorban az alkalmazások teljességét érintő felhasználói jogosultságokkal, azonosítással, és a titkosítással foglalkozunk. A papíralapú hivatalos levelezés, a kereskedelmi megrendelések, szerződések, számlák kialakult gyakorlata: a kézbesítési rendszer, a lezárt boríték, az előnyomott fejléces levélpapír, az aláírás, pecsét, a kimenő, illetve beérkező levelek iktatása, illetve a szenzitív tartalmú anyagok elkülönített kezelése hagyományosan és jól szabályozott rendben biztosítja a megfelelő védettséget, hitelességet. A távirat, a telex volt sokáig a kizárólagosan elfogadott elektronikus üzenetforma, mely ugyancsak szigorú működési szabályok szerint bonyolódik. A telefax nem biztosítja alapvetően a fenti követelményeket, de szabványos volta okán széleskörűen elterjedt, erősen fellazítva a hagyományos dokumentumcsere és kezelés szabályozott rendjét. Az elsődlegesen kialakult Internet elektronikus levelezési rendszer, vagy az on-line tranzakciók gyakorlatilag semmiféle védelmet nem biztosítanak a feladó vagy a címzett által bizalmasnak, titkosnak tartott, vagy személyes adatokat, szenzitív üzleti információkat tartalmazó üzenetek megóvására az illetéktelenektől. Az elektronikus üzenetkezelő rendszerek széleskörű alkalmazása, felhasználása hivatalos, illetve kereskedelmi célokra szükségessé tette azonban az üzenet védettségének, sérthetetlenségének, teljességének biztosítását is a kézbesítési 20
prioritások, kézbesítési értesítések rendszerének kialakítása mellett. Az USA törvényhozása 1986-ban fogadta el az elektronikus üzenetek védettségéről (levéltitok) intézkedő Electronic Communication Privacy Act-ot. Ezzel jogilag elismerte az elektronikus levéltitkot és szankcionálhatóvá tette a mások postafiókjának megnyitását, illetve üzeneteik elolvasását. Kockázati tényezők Az elektronikus kommunikációt, kereskedelmet támogató rendszerek veszélyeztetettségei és sebezhető pontjai röviden a következők: • A bizalmasság megszegése (Az üzenet, tranzakció tartalmára, üzenetforgalomra, az összeköttetés útvonalára, módjára vonatkozóan) • Az információ megváltozása. • A tranzakció visszautasítása (feladó-címzett, küldés-kiolvasás, export-import, a különböző szerverek, illetve hálózatok közötti forgalomra vonatkozóan). • A felhasználók azonosságának felfedése illetéktelenek előtt (pl. a levelezési névjegyzékek, a felhasználók neveit, a szervezeti struktúrát, a borítékok bejegyzései a továbbítási útvonalakat, gépeket tartalmazhatják.) • Megszemélyesítés. • Rossz útvonalválasztás (a routing tábla hibája mellett a címzés, csoportos címzés, másolat megadás hibái gyakoribb okok) • A szolgáltatás vagy a tranzakció megtagadása, illetve letagadása. • Üzenet duplikálása (amely a rossz útvonalválasztással jár) • A programozott időtől eltérő továbbítás. • Az üzenetek utasítás nélküli megjelenítése • Biztonsági viszonyok lazulása (egy gépen több felhasználóra megosztott felhasználói szoftver; a megosztott szoftver egyik felhasználója nem ismeri a biztonsági szabályokat; távoli terminálok használata; idegen szerverek és levelezési rendszerek elérése kapcsán) Az elektronikus kommunikációban a felhasználói oldal biztonsági szempontból gyenge pontja a következők (13): • A bekapcsolt, hálózatra feljelentkezett számítógépe mellől sok felhasználó rövidebb, hosszabb időre elmegy, sőt akár éjszakára is működőképes állapotban felejti. A felügyelet nélkül hagyott, működő számítógépen az illetéktelen bármely hálózati szolgáltatással visszaélhet, de szerencsétlen esetben az eredeti felhasználó nevében elektronikus üzenetek hamisítására is módja nyílik. A hamisítvány, tekintve, hogy az eredeti gépen és a tulajdonos jogosítványaival, jelszavával készült, a címzett, de a rendszergazda számára is ellenőrizhetetlen módon teljesen hitelesnek tűnik. • A felkonfigurált számítógép, vagy csupán a merevlemezes (hard disk) tároló javítása, leselejtezése, vagy a hálózati szolgáltatások elérésére is alkalmassá tett hordozható számítógép (laptop, notebook) elvesztése, ellopása folytán lehetővé váló illetéktelen hozzáférés folytán visszaélhetnek a levelezési címtárakban található nevekkel, címekkel, telefonszámokkal, illetve más a hordozható számítógépen a tulajdonos munkájához szükséges szenzitív szervezeti adatokkal. A gazda gépek távoli elérését biztosító hívási módszerek ismerete folytán a tulajdonos jelszavának, postafiókjának illetéktelen használatán túl, más szerverek, illetve adatbázisok elérése is lehetséges, amennyiben a vonatkozó jelszavak a hordozható gépen megvoltak. Az eredeti felhasználó megszemélyesítésével számos hamisításra és visszaélésre nyílik mód. • A közcélú hálózatok igénybevételével (pl. telefon, nyilvános adatátviteli hálózat) létesített elektronikus üzenetforgalom, vagy on-line kapcsolat során mód nyílik az üzenetek elfogására, módosítására, cseréjére, illetve lehallgatására, a használt jelszavak elfogására. 21
• A szenzitív elektronikus üzenetek, vagy dokumentumok szerkesztésére, tárolására használt számítógép, akár közvetlen illetéktelen hozzáféréssel, akár elektromágneses sugárzás útján másolható, módosítható, de veszélyforrás lehet a mások által is elérhető számítógépen az ideiglenes szerkesztés, tárolás is. Felhasználói problémák használatakor:
az
elektronikus
kereskedelem
üzenetkezelő
rendszereinek
• Nem lehet hitelt érdemlően azonosítani a feladót az üzenet vételekor. A címzettnek kétsége lehet, hogy a feladóként megadott levelezési cím, szerver, vagy WEB lap címe pontosan kit takar. Ha funkció, illetve szervezet van megadva valóban az illetékestől származik-e az üzenet, illetve a megadott funkciót ki tölti be. Mindezek hamisítások lehetnek, ha felügyelet nélkül hagyták a gépet, illetve a rendszergazda, a postamester nem tartja folyamatosan karban a rendszert. • Nem tehetünk semmit, ha figyelmetlenségből rossz címzettnek küldjük el az üzenetet, avagy a szerverre történt továbbítás után nem tudjuk letiltani, visszahívni a hibás, módosítandó üzenetet. • Nincs biztosíték az elküldött üzenet teljességének, integritásának megóvására. A levélposta borítékján a sértetlenség ellenőrzése kellően megnyugtató lehet, azonban az elektronikus üzenet vételekor sok üzenetkezelő rendszer esetén semmi nem utal arra, ha a feladótól a címzettig terjedő útvonalon tartalmát megváltoztatták. • Sok üzenetkezelő rendszer esetén a vételi értesítés ellenére a feladó nem lehet biztos, hogy a címzett valóban kibontotta-e üzenetét. Problémák az üzenettovábbító szerver működése kapcsán, tekintve, hogy a szerver egy nagy kiterjedésű hálózat (pl. az Internet) sok gépéről elérhető: • Amennyiben a szerver az üzenetkezelési funkció mellett más feladatokat is ellát, az azok használatára feljogosított felhasználók elérhetik az üzenetkezelő tartalmát. • Az egyszerű felhasználói azonosítók és az egyszerű, ritkán változtatott jelszavak megkönnyítik az illetéktelen hozzáférést a postafiókok, de akár a teljes üzenettároló tartalmához is. A különböző levelezési rendszerek közötti átjárókon sok esetben nem lehetett rejtjelezést használni, ami lehallgatásra és az óvatosság csökkenésére adott okot. Az üzenetek titkosságát, ha azok nincsenek rejtjelezve, az adminisztrátor postamester megsértheti, tekintve, hogy a felhasználók jelszavaihoz hozzáférhet. Elméletileg így a felhasználó nevében hamisítani is tud. Bármely felhasználó üzenetforgalma a helyi hálózaton viszonylag egyszerű eszközökkel lehallgatható. Míg a nyilvános hálózaton csak egy-egy felhasználó figyelhető meg előfizetői összeköttetésenként, a helyi Ethernet hálózaton az üzenetkezelő szerver és a felhasználók teljes forgalma lehallgatható. Még egy példa a biztonság és üzembiztonság veszélyeztetésére: Az első Internet vírust az u.n. Internet Worm-ot a Cornell University diákja Robert Morris Jr. 1988. novemberéren szabadította az Internetre, amelyen aztán végigsöpört, gyorsan megfertőzött és működésképtelenné téve több mint ezer számítógépet (14) Védekezés
22
Az elektronikus üzenetkezelés, kommunikáció fenti biztonsági kockázatai megfelelő intézkedésekkel elkerülhetők, illetve csökkenthetők, úgyhogy a rendszer szenzitív üzenetek kezelésére is alkalmas. Az 1988-as X.400-as ajánlás néhány opcionális biztonsági szolgáltatást is tartalmazott már. Az OSI biztonsági funkciókat az ISO 7498-2 írja le. Jelenleg fontos többféle biztonsági előírás, szabvány ismert. A rendszer üzemeltetőjének választása szerint indokolt bevezetni a szükséges biztonsági intézkedéseket a kockázatelemzés alapján. A biztonság fokozása történhetne úgy, hogy az elektronikus kommunikációt érintő infrastruktúra minden elemét, a személyi számítógéptől a távoli összeköttetést biztosító vonalig mind, mind védeni kellene. Ez meglehetősen költséges és még mindig bizonytalan eredményt adó módszer lenne, tekintve kezelhetetlenségére az üzenetkezelés széleskörű igénybevételekor. Sokkal járhatóbb az üzenetek és az azokat előállító felhasználói szoftver védelme. Ebben az esetben az üzenet jellegétől, a címzett földrajzi helyétől, lehetőségeitől függően a feladó határozhatja meg, hogy üzenete a leghatékonyabban, de kellő biztonsággal kerüljön a hálózatra. A védekezés célja A szenzitív információk továbbítására is alkalmas üzenetkezelő rendszernek az alábbi célkitűzéseknek kell megfelelnie: • Védelem a hamisítás és megszemélyesítés ellen. A címzettnek kétséget kizáróan tudnia kell, hogy az üzenet feladója valóban az, aki fel van tüntetve, és a feladó valóban a megadott illetékes személy. • Biztosított kézbesítés. Az üzenetet kizárólag a címzett bonthatja fel és olvashatja el. Ez nem zárja ki az üzenet elfogását, azonban biztosítja, hogy esetleges, véletlen elfogás esetén legalább az üzenet tartalma ne legyen felhasználható. • Az üzenet teljessége (integritása). A címzettnek tudomást kell szereznie arról, ha az üzenet bármely része megváltozott vagy megsérült a feladás és a vételi oldalon történő felbontás közötti időszakban. • Az információcsere hatékonyság folyamatossága. Az információvédelem alkalmazása nem akadályozhatja a hatékony kommunikációt. Nem jó az a rendszer, amelyben speciális kulcsokat, vagy más információt kell cserélnie a felhasználóknak, vagy az üzenet továbbítása előtt telefonon, vagy személyesen egyeztetniük kell. • A helyhez kötött és a mobil felhasználók azonos szintű védelme. Ez biztosíthatja az üzenetkezelő rendszer széleskörű alkalmazhatóságát. • Alkalmazható eljárások a célkitűzések megvalósítására: • titkosítás • digitális aláírás • üzenetek eredetiségének (autentikusságának) biztosítása • felhasználók azonosítása és valódiságuk ellenőrzése
A felhasználók ellenőrzése A felhasználók azonosítása és jogosultságaik ellenőrzése olyan, ami biztosítja, hogy csak a feljogosított személyek férhessenek hozzá az elektronikus üzenetkezelő rendszerhez, küldhessenek és fogadhassanak üzeneteket. A felhasználó azonosítására az üzenetkezelő szoftver konfigurációjában meghatározott felhasználó, és ő is csak az általa ismert (de a postamester számára általában elérhető) jelszó megadása után indíthatja személyi számítógépén az üzenetkezelő programot. Ez különösen fontos a hordozható számítógépek védelme szempontjából. 23
A jelszó ismerete nélkül nem futtatható a kliens oldali program, de a postafiók sem érhető el a szerveren. Egy illetéktelen személy az üzenetkezelő szoftver birtokában sem éri el a szervert. Csak az engedélyezett felhasználó azonosítójának és jelszavának egyidejű egybeesése teszi lehetővé a rendszerhez a hozzáférést. Kritikus rendszerekben az egyszerű jelszó mellet, további a felhasználó birtokában lévő kizárólagos jelzés, (pl. azonosító kártya, ujjnyom, stb.) további alkalmazása is szükséges lehet a személyi számítógép és a szerver eléréséhez. A jelszavakkal kapcsolatos előírásokat be kell tartani, azaz nem szabad egyszerű, könnyen kitalálható, vagy megfejthető jelszavakat használni, a jelszavakat rendszeresen cserélni kell. A forgalomban lévő elektronikus üzenetkezelő rendszerek közül sok alkalmazza a jelszavas védelmet, de ez nem véd a rendszeradminisztrátorral szemben. Illetéktelenek olvashatják a személyi számítógépen hagyott, vagy akár más szervereken tárolt nem titkosított üzeneteket is. További nyitott probléma még a feladó azonosíthatósága, az üzenet integritása, hitelessége is. Az ilyen kérdésekre az alábbiak adnak megoldási lehetőséget.
Titkosítás A gyakorlatban az üzenetek és a teljes kommunikációs csatorna végponttól végpontig terjedő titkosítása terjedt el a tartalom illetéktelenektől való megvédésére. A titkosítás, kriptográfia egy kulcs (valamilyen karakterfüzér) és egy algoritmus (valamilyen matematikai művelet) alkalmazásával az olvasható, érthető üzenettartalmat felismerhetetlenné teszi. Célja, hogy még számítástechnikai módszerekkel is értelmetlen legyen a kód feltörése, azaz az üzenet tartalmától, milyenségétől függően változhat a rejtjel kulcs és algoritmus. A címzett a rejtjelkulcs és algoritmus ismeretében a folyamat fordított irányú elvégzésével visszaállítja az eredeti állapotot. A rejtjelezésre kétféle módszer terjedt el, a privát, vagy titkos kulcsú és a nyilvános kulcsú rejtjelezés. Meg kell jegyezni, hogy a rejtjelezési eljárások bevezetése, engedélyezése állami feladat. Az alább ismertetett USA fejlesztésű eljárások közül csak a DES kivitelét, használatát engedélyezte sokáig az USA Kormány. Az elektronikus kereskedelem terjedésének támogatásra ez a politika az utóbbi években jelentősen változott, azonban minden ország, illetve akár cég is saját eljárásait részesíti előnyben szenzitív információi védelmére. A különféle rejtjelkulcsok alkalmazása, alkalmazhatósága hosszú ideje polémia tárgya. A DES vonatkozásában, a szabvány megjelenése óta, sokan az USA állami ellenőrzésre való törekvéseket láttak már 1980-ban is (15) a kódoló tervezési elveinek titokban tartása miatt, de 1995-re bizonyítottá vált könnyű megfejthetősége is. Privát kulcsos rejtjelezés A privát kulcsos rejtjelezést hagyományosan használják és kielégítő eredményt ad a védelemre. A polgári számítástechnikai alkalmazásokban az USA Data Encryption Standard (1977), adattitkosítási szabvány, közismerten DES algoritmus terjedt el elsőként. Viszonylag egyszerű 56 bit-es kulcsa 70 kvadrillió kombinációt tesz lehetővé. 1995-re fejlődött annyira a számítástechnikai infrastruktúra, hogy viszonylag nagyobb erőfeszítés nélkül feltörték. (Több hálózati szerver néhány órás munkájával). Ettől függetlenül is a privát kulcsos rejtjelezés problémái az alábbiak: Szimmetrikus, titkos kód, azaz mind a feladó, mind a vevő oldalon előzetes egyeztetés alapján meg kell lennie ugyannak a kódnak, melyet titkosan kell kezelni. Az üzenetcsere ezért csak kétoldalú és igen szűk körű lehet, tehát nagyobb, kiterjedt szervezetben nehezen használható ez a módszer. A kulcsok szétosztására különféle elmés módszereket dolgoztak ki, melyekkel a kulcsok nyíltan is terjeszthetők a hálózaton, igaz jelentős gépidő szükséges előállításukhoz. (16) 24
Nyilvános kulcsos rejtjelezés Az aszimmetrikusnak is nevezett két kulcsot és egy algoritmust alkalmazó nyilvános kulcsú rejtjelezési (PKE = Public Key Encryption) eljárás 1976-77 óta ismert. Whitfield Diffie és Martin Hellman (17) 1976-os elméleti munkáját követően a MIT (Massachusetts Institute of Technology) professzorai Ronald Rivest, Adi Shamir és Len Adleman (18) 1977-ben szabadalmaztatták a nevükről elnevezett RSA nyilvános kulcsú kriptográfiai rendszert (Public Key Cryptosystem). Az egyirányú kódolás során az ismert “A” “nyilvános” kulccsal rejtjelezett szöveg csak a vonatkozó, meghatározott “B” “privát” kulccsal állítható vissza eredeti állapotába. A kulcsok 400-800 bitesek. Az eredeti RSA algoritmus meglehetősen lassú, amelyet azóta a módosításokkal (kombinálva a DES-sel) az egykulcsos rendszer sebességére növeltek. A két kulcs közül elegendő az egyiket véletlenszerűen megválasztani. Ezt, mint a telefonszámot nyilvánosságra lehet hozni. A második, a titkos kód az első matematikai leszármaztatottja, melyet csak a tulajdonosa állíthat elő. A titkos kód csak megfelelő azonosító eljárás után generálható és nem szabad/ajánlott tárolni papírra írott formában. A titkosítandó üzenetet tehát a címzett, bárki által hozzáférhető nyilvános kódjával kell rejtjelezni. Az üzenetet ezután csak ő tudja titkos kódja segítségével visszaállítani eredeti formájába. A feladó azonosítása (authentikálás: az üzenet hitelességének, eredetiségének, valódiságának bizonyítása) A hagyományos papíralapú dokumentumoknál az aláírás szolgál a hitelesség bizonyítására. A sajátkezű aláírás a személyiség azonosítására elfogadott, mivel feltételezzük, hogy alakja és formája az ujjlenyomathoz hasonlóan egyedi és jellemző, senki más által nem utánozható. Az elektronikus kommunikáció elterjedésével hasonló hitelesítő jelre van igény, amely az elektronikus dokumentációhoz ugyanúgy, mint a papírhoz elválaszthatatlanul odailleszthető. Meg kell jegyezni, hogy a technika fejlődésével a sajátkezű aláírás hamisíthatóságára is megnőtt a lehetőség. A nyílt kulcsos rejtjelezési eljárás alkalmasan használható az üzenetek digitális hitelesítésére is. Ez az u.n. digitális aláírás technikája. A digitális aláírásokhoz használt 512 bites kulcsok algoritmusát ElGamal az RSA Data Security Inc. volt munkatársa fejlesztette. Az USA Szabványügyi Intézet (National Institute of Standards and Technology, NIST) ezt felhasználva szabványosított egy eljárást, amely Digital Signature Standard (DSS) néven vált ismertté. A szabvány a rejtjelezési algoritmus mellett a kulcsok, a kriptográfiai kivonatkészítés (hash, “ledarálás”, digitális lenyomat) és a kulcs kiosztási algoritmusokat is szabályozza. Az RSA nyílt kulcsos rejtjelezés szabadalmai időközben a Public Key Partners, (Sunnyvale, Kalifornia) cég birtokába kerültek az RSA módszerrel együtt, így minden alkalmazásért licenszdíjat szednek. (Az RSA-at igen sok cég, többek között az IBM, Lotus, Microsoft, Apple használja, de a DSS-re az USA Hadügyminisztériuma is fejlesztett eljárásokat). A NIST és a Public Key Partners (PKP) hosszas pereskedést követően 1993-ra egyeztek meg. Ennek értelmében a PKP a DSS technológiát világszerte forgalmazhatja alkalmazásfejlesztési csomagban. Viszonzásaként az összes USA állami szerv és önkormányzat royalti mentesen használhatja a PKP technológiát, de ez igaz a privát személyekre is. Csak licensz díjat kellett fizetniük a PKP-nek. A tanulmány írásakor az RSA szabadalmak és eljárások tulajdonosa az RSA Security Inc., melynek külön fejlesztő részlege az RSA Laboratories. (lásd a későbbikben) A digitális aláírás egyik bevált módozatának ismertetése
25
Amennyiben a feladó az elküldendő üzenetet karakterről-karakterre egy matematikai algoritmussal a hash függvénnyel feldolgozva (hashing: “ledarálva, fasírozva”) előállítja az üzenet adatainak egy rövid karakterfüzérből álló kivonatát (digitális lenyomatát) és azt saját privát kódjával rejtjelezi mind az üzenetre, mind saját magára vonatkozó egyedi karaktersort állít elő. A vételi oldalon a megkapott üzenetből azonos módszerrel előállított kivonatot a feladó könnyen hozzáférhető, nyilvános kódjával rejtjelezik, majd összevetik az üzenet digitális aláírásával, amennyiben a kettő azonosítható, kétséget kizáróan a feltüntetett feladó eredeti, változatlan üzenetéről van szó. Sok esetben azonban, amikor az üzenetet váltó partnerek nem ismerik egymást kétségbe vonható a nyilvános kulcs hitelessége. Máskor szükséges lenne hitelt érdemlően azonosítani a feladó/címzett kilétét, beosztását, azaz az elektronikus aláírás önmagában sem elegendő bizonyíték az üzenet valódiságára. Előfordulhat, hogy a címzett hamis, vagy rossz szándékú, csaló üzenetet kap, amikor is elégtelen a digitális aláírás, annak valódiságáról érvényességéről valami módon bizonyságot kell szereznie. Ezt a bizonyítást a hiteles harmadik fél, vagy ahogyan egy időben nevezték az elektronikus közjegyző intézményének közbeiktatásával oldják meg. A hiteles harmadik fél A kétkulcsos rejtjelezés alkalmazásával számos lehetőséget dolgoztak ki a digitális aláírás hitelességnek bizonyítására, pl. a bankok mindennapi gyakorlatára, azonban a legmegnyugtatóbbnak egy harmadik, akár hivatalos fél bevonása látszik. A hivatalos közjegyzői megoldás végül is régóta használatos a polgári iratok, szerződések hitelességének bizonyítására. Az üzenet hitelességének bizonyíthatóságával egyenlő súlyú kérdés, hogy az adott elektronikus címen, vagy egy meghatározott címjegyzékben, címtárban szereplő információ pontosan kit takar, az adatok aktuálisak-e. Ez különösen a hivatalos és üzleti kommunikációban lényeges. A feladatot az u. n. minősített tanúsító hatóság intézményének bevezetésével oldották meg. A nyilvános kódok egy, a kommunikáció szempontjából központi, harmadik fél adatbázisában (hatósági adatbázisban) kerülnek tárolásra az illető személy összes jellemző attribútumával (név, cím, telefonszám, szervezet, illetve cég, beosztás, stb.) együtt. Az adatok valódiságát a papíralapú okmányokhoz hasonlóan de nem a közjegyző, hanem a tanúsító hatóság által kiállított, csatolt elektronikus tanúsítvány bizonyítja. A címtár tehát hiteles, amely alapján mind az üzenet címzettje, mind a feladó adatai ellenőrizhetőek. A címtárak ITU szerinti X.500-as ajánlásai között az X.509 határozza meg a nyilvános kódokat és az “elektronikus közjegyző” tanúsítványát is tartalmazó szabványos hierarchiát. A digitális aláírással ellátott üzenet tehát vagy a tanúsító hatóság adatbázisából érkező tanúsított nyilvános kóddal érkezik a címzetthez az összes adattal, vagy azok onnan az üzenet felbontásakor lehívásra kerülnek. Az üzenet teljessége A digitális aláírás használatával járó további előny, hogy az üzenet karakterenkénti “hash függvényű” feldolgozásával (ledarálásával és tömörítésével, azaz a "fasírozott" adataival) előállított kivonata a feladónál és a címzettnél a legkisebb változás esetén különbözni fog, tehát önmagában ez a tény már jelzi a problémát, hogy az eredeti irat megváltozott, akár egy betűjében is. Az Internet üzenetkezelés védelmi eljárásai Az Internet ellenőrizetlensége és nyitottsága az elektronikus kereskedelem feltételeinek kialakulását megelőzően köztudott volt, ugyanakkor a védelmi rendszerek kutatásában, 26
fejlesztésben és kiépítésében az Internet közösség élenjárt. Ez a munka alapozta meg a biztonságos Internet kommunikációt. A levelezés titkosított védelmét szolgálta elsőként a Privacy Enhanced Mail (PEM) kétkulcsos Internet levelezési szabvány 1993-ban, amely az X.509-es tanúsítvány struktúra első alkalmazása volt a következő biztonsági szolgáltatásokkal: az üzenet bizalmasságának megőrzése, az üzenet keletkezési helyének és az üzenet teljességének ellenőrzése. A két szabvány kölcsönösen elősegítette a másik továbbfejlesztését. Az Internet berkekben az 1994-95-es évek egyik nagy visszhangot kiváltó eseménye a “Pretty Good Privacy” (PGP) kétkulcsos rejtjelezési rendszer készítője ellen indított per volt. Philip Zimmerman, Boulder Software Engineering eljárását az Interneten szabad használatra hozzáférhetővé tette, így az USA kormányhivatalnokok szerint megszegte a vonatkozó export tilalmat Az eljárási licensz tulajdonosa a Public Key Partners cég (Sunnyvale, Kalifornia). Tekintve, hogy Zimmerman a közzétételkor már Svájcban dolgozott a pert megnyerte. A PGP 2.0-ás változatának kifejlesztésében, illetve továbbfejlesztésében sokan részt vettek a világ sok országából és igen sokféle nemzeti adaptációját is elkészítették. Ez a WEB-re alapuló kétkulcsos megközelítés jelenleg visszaszorult az RSA megoldással szemben. Az üzenetkezelés biztonsági intézkedései Az eddig ismertetett eljárások csak akkor eredményesek, ha alkalmazásukat megelőzően már van a szervezetnek jól kidolgozott biztonsági koncepciója, amely szabályozza mi tekintendő szenzitív információnak és meghatározza a kezelésének módját. A biztonsági irányelvekben és szabályzatban kell intézkedni a szerverek, a munkaállomások és a fájlok védelméről a következők figyelembe vételével: 1. Minden szenzitív üzenet kezelésére alkalmas személyi számítógépet használatbavétel előtt el kell látni felhasználói azonosítóval (UserID) és jelszóval (password). Sok eseten a szigorú felhasználói azonosítást lehetővé tevő aktív kártyás megoldást kell telepíteni, amely egyszer használatos jelszót, védett jelszócserét, stb. biztosít. Ki kell oktatni a felhasználókat a jelszóhasználatra, előírva a minimális hosszúságot és a rendszeres jelszócserét. Ellenőrizni kell a lejárt jelszavak és az inaktivált felhasználók rendszeres törlését. 2. Az elektronikus üzenetkezelésre is alkalmas személyi számítógépeket olyan szoftverrel kell ellátni, amely meghatározott idejű felügyelet nélküli működés esetén lekapcsolja a rendszerről a gépet. A visszaállítás csak jelszóval történhet. 3. A postahivatali és üzenettárolási funkciókat ellátó szervereket felhasználói azonosítóval (UserID) és jelszóval (password) kell védeni. Nem szabad megengedni a vendég, “guest” felhasználót. Lehetőséghez mérten az üzenetkezelési funkción kívül más feladatot ne lásson el a szerver. 4. Biztosítani kell, hogy a levelező rendszerbe ne lehessen kapcsolt telefonvonalon behívni, akár a helyi hálózat gépeiről, akár a nyilvános hálózatról. 5. A postamesteri feladatokat és a hálózati adminisztrációt külön kell választani. 6. Biztosítani kell, hogy a szerveren hozzáférési jogokat csak indokolt esetben kaphassanak egyes felhasználók és a jogok minimálisak legyenek. 7. Az üzenetkezelő szerver, az adminisztrációs feladatok és átjárók fizikai védelmét biztosítani kell az illetéktelen személyek hozzáférése ellen.
A nyilvános kulcsú infrastruktúra, a PKI 27
Áttekintés A nyilvános kulcsú titkosítás és az alkalmazását biztosító egymással összekapcsolt elemekből és szolgáltatásokból felépülő nyilvános kulcsú infrastruktúra egyre fontosabb szerepet kap a biztonságos hálózati, elektronikus távszolgáltatásokban. A nyilvános kulcsú titkosítás a különböző, csak az Interneten összekapcsolódó hálózatok és információs rendszerek elosztott biztonsági architektúrájának ideális eszköze, mivel ehhez nem szükséges az egyetlen közös hatóságtól származó titkosító kulcs és biztonsági okmány. A nagyvállalatok, központi költségvetési szervek biztonságos elosztott alkalmazásai, mint a közgazdasági tervező, humánpolitikai-bérszámfejtési rendszerek (ellátási lánc irányítás), a biztonságos elektronikus üzenetkezelés és mindaz ami az elektronikus kormányzat, illetve elektronikus kereskedelem (e-government, e-business) fogalomkörébe tartozik, de ezen túlmenően is a virtuális privát hálózatok és intranet alkalmazások alapeleme a nyilvános kulcsú infrastruktúra, amelyet elterjedten PKI (Public Key Infrastructure) néven ismernek. A PKI az Internet (TCP/IP) technológiát alkalmazó valamennyi hálózat biztonságosságának feltételeit nyújtja, lehetővé téve a megbízható és hiteles távoli szolgáltatásokat (kommunikációt és adatfeldolgozást) is. A szolgáltatásokhoz a titkosító kódolás és a digitális aláírás alkalmazásával biztosítható a szigorú felhasználói azonosítás (authentication), az adatok védelme (confidentiality and privacy) és teljessége (integrity), valamint a letagadhatatlanság (nonrepudiation). A nyilvános kulcsú infrastruktúra - a PKI - lényegében meghatározott biztonsági szolgáltatások köre, amely lehetővé teszi a nyilvános vagy másképpen nevezve kétkulcsos, aszimmetrikus titkosítás és az X.509-es ITU-T ajánlás szerinti, ISO/IEC 9594-8 szabványos tanúsítványok használatát az elosztott információs rendszerekben és biztosítja a kulcsok, tanúsítványok, és használati irányelveik (policy) menedzsmentjét. A szervezet alkalmazottjai, illetve a szervezet információs rendszereit használó külső partnerek, állampolgárok elvárják, hogy a rendszerek és a bennük tárolt adatok, információk megbízható módon, az év 365 napján és biztonságosan rendelkezésükre álljanak. Ezt a jó PKI a digitális tanúsítványokkal, illetve más minősített elektronikus jogosítványokkal biztosítja, lehetővé téve az ellenőrzött belépést az információs rendszerekbe, a titkosított üzenetkezelést és adatátvitelt a szervezet számára lényeges alkalmazások esetén. A követelmények teljesítésére a cég/szervezet minősített on-line PKI szolgáltatást kell üzemeltessen, amely alkalmas a felhasználók azonosítására (authentication), a jogosultságaik szerinti tevékenységek ellenőrzésére (authorization) és a digitális aláírások kulcsainak menedzselésére a legkülönbözőbb Internet/intranet alkalmazásokban. Bár a PKI alapszolgáltatása a nyilvános kulcsok biztosítása, azonban a nyilvános kulcsokat a kulcskibocsátó digitális tanúsítványba csomagolja. A digitális tanúsítvány védi a nyilvános kulcs sértetlenségét és egyben hitelesítési lehetőséget biztosít, mivel a nyilvános kulcson kívül egy sor attribútumot tartalmazhat, mint a használó nevét és más azonosítást segítő adatait, valamint jogosultságait, a kulcs érvényességét, stb. A nyilvános kulcs hitelességét a kulcskibocsátó, vagyis az u.n. CA (Certificate Authority), tanúsító hatóság saját privát kulcsával képzett digitális aláírása bizonyítja a tanúsítványon. A PKI-ban egyidejűleg minden felhasználónak legalább két kulcs párral kell rendelkeznie. Bármelyik pillanatban a felhasználónak kell egy kulcs pár a titkosításra és a megfejtésre, és egy másik kulcs pár a digitális aláírásra és az aláírás ellenőrzésére. A nyilvános kulcsú titkosítás szépsége éppen abban van, hogy széles körben hozzáférhetővé teszi a bizalmas, hiteles információkat és ehhez az emberek és rendszerek nyilvános kulcsaikat nyílt, nem hiteles környezetben tárolhatják, csupán a kulcs pár privát felét kell szigorúan őrizniük. A tanúsítvány hitelességéről a kibocsátó CA titkos kulcsával készített aláírásának a nyilvános kulcsával történő ellenőrzésével győződhet meg a használó. A kibocsátó aláírásával igazolja 28
autentikusságát és korrektségét, melyet például az állami tanúsító hatóság esetén a polgárok bizalma, illetve privát tanúsító hatóságnál a tanúsítvány irányelvek tisztességes betartása és a tanúsító hierarchia hitelesít, amelyhez esetleg kapcsolódik. A közszolgálati CA-knak meghatározott bizalmi felelőssége van jogállásuk következtében, mindezeket bizonyos jogszabályok és jogosítványok tovább erősíthetik. A privát CA-k ugyanakkor rugalmasabban tudják alakítani üzletpolitikájukat és gyakorlatukat a felhasználói igények függvényében. A PKI terméket, szolgáltatást alkalmazó szervezet biztonsági tartományokat alakíthat ki, melyekben egy tanúsító hatóság a tanúsítvány és kulcs kibocsátást ellátja. Minősített kapcsolati viszonyt hozhat létre a szervezet különböző biztonsági tartományokkal egy CA hierarchián belül vagy akár kereszttanúsítással más CA-kkal. Alapkövetelmény a szabvány alapú átjárhatóság, azaz nyílt interoperabilitás a hálózatok között. A tanúsító hierarchiában felette álló CA-tól kapott kulcs pár nyilvános kulcsa a saját tanúsítványába van csomagolva. A hierarchia legmagasabb fokán a felső szintű CA a gyökér (root) hatóság van, amely tanúsítványát már senki nem hitelesíti, ebben saját digitális aláírása szerepel. A root CA minősített, nyilvános kulcsát más, "sávon kívüli" módszerrel igazolják amennyiben ezt egy minősített harmadik fél szolgáltatja nem on-line hálózaton, például PKI kompatibilis kereskedelmi szoftverekhez csatolva. Más módszer szerint a gyökér kulcs másolata nyilvános WEB szerverekről letölthető. A felhasználó ezzel a gyökér tanúsítványt ellenőrizheti, majd ezen keresztül a teljes tanúsítási láncot. Igen előnyös jellegzetessége a rendszernek, hogy a tanúsítványokat a csalástól védi a digitális aláírás, így a tanúsítási láncok szabadon küldhetők a nem biztonságos Interneten is. A szervezeti PKI célja az adatvagyon védelme az azonosítás, a bizalmasság, a letagadhatatlanság, a teljesség és a rendelkezésre állás megteremtésével. Ezek a fogalmak a következők szerint értelmezettek: −
Azonosítás - folyamat a kommunikációban, adatátvitelben résztvevő felek azonosságának megállapítására;
−
Bizalmasság - biztosítja, hogy az információt továbbításakor nem hallgatták le, és feldolgozása, tárolása során illetéktelenek nem fértek hozzá;
−
Letagadhatatlanság - biztosítja, hogy az egyszer végrehajtott tranzakció jogszerűen érvényes és nem visszavonható;
−
Teljesség - az adatok, információk eredeti, változatlan tartalmának és formájának megtartása a dokumentum sértetlensége;
−
Rendelkezésre állás biztosítja hogy a kommunikáció vagy az adatátvitel igény esetén megbízhatóan végrehajtható a 7x24 órás szolgáltatásban.
A piac változatos tanúsító szerver kínálatából legtöbb a technológia fejlődési folyamatában nem vette kellően figyelembe a szervezetek infrastrukturális igényeit, így körülbelül az ezredfordulóra alakult ki az a termék választék, amelyben a felhasználók teljes értékű PKI szolgáltatásokat kaphatnak. Műszaki szempontból a nyilvános kulcsú infrastruktúra (PKI) nyújtja azt a technológiát, infrastruktúrát és eljárást, amely meghatározó mértékben lehetővé teszi az elosztott alkalmazásokban a digitális aláírások és/vagy a nyilvános kulcsú titkosítás használatát. A PKI fő funkciója az elektronikus iratok, vagy más elektronikus adatátvitel titkosítására, illetve szignálására, aláírására, vagy az információs forrásokhoz való hozzáférés engedélyezéséhez a felhasználók személyének előzetes azonosítására a szükséges nyilvános kulcsok pontos és megbízható kiosztása. A folyamatban a szervezet tanúsító hatósága (CA - certification authority) - a nála regisztrált felhasználók számára - saját kibocsátású digitális tanúsítványokat használ, amelyekbe a nyilvános kulcsot "becsomagolja". A tanúsítvány kibocsátás feltétele a 29
felhasználó azonosítása, authority) végez, mikor tevékenységi köre olyan visszavonása/állapotának generálása.
amelyet célszerűen egy regisztráló hatóság (RA - registration a leendő kulcstulajdonos kulcs igényléssel fordul hozzá. A PKI funkciókra is kiterjed, mint a tanúsítvány megújítása, a tanúsítvány ellenőrzése és a felhasználó privát kulcsának biztonsági tárolása/újra
Általános tévedés, amit sokan gondolnak, hogy a PKI valami tárgyiasítható dolog, pedig valójában a PKI egy lehetőség, amely a nyilvános kulcsok közzétételét, menedzselését és használatát könnyíti meg. A PKI szolgáltatás azonban jogi és pénzügyi felelősséggel jár, és igen jelentősek a bizalmi szempontok sikerességében. A szolgáltatónak biztosítania kell a teljes információtechnológiai hátteret beleértve az informatikai rendszereket, távközlést, adatbázisokat, de ezen túlmenően a telephely fizikai biztonságát, az "Internet-biztos" belső hálózatokat, a magas rendelkezésre állást biztosító redundáns rendszereket, a katasztrófatűrő képességet, a PKI szakterület szakértőit, életképes PKI joggyakorlatot, és financiálisan biztos PKI szavatosság védelmet. A költségek és a felelősség megosztására integrált, hierarchikus rendszereket használnak elterjedten. A PKI telepítésére a legalkalmasabb az operációs rendszer. Az operációs rendszerek már egy sor más infrastruktúrát is támogatnak, mint például a hálózati nyomtatást, a háttértárolókról letölthető fájlszolgáltatásokat. A PKI esetében az operációs rendszer a hálózat biztonságos, de transzparens és egyszerű használatát biztosítja. A PKI tanúsító hatóság (CA) telepítésének első napjától a legmagasabb biztonsági követelmények szerint kell eljárni, amelyek szigorúbbak az általános titkosított adatátviteli és feldolgozó rendszerekre előírt követelményeknél. Ez akkor is igaz, ha az első telepítés idején nincsenek szenzitív, védendő állományok, azonban a későbbiekben bármikor szükséges lehet igénybevétele az igen értékes információk védelmére. Alapvető követelmény, hogy a CA-t támogató kritikus alkalmazások a tanúsítványok aláírásához hardveres kriptográfiai modulokat használjanak, mivel a szoftveres alkalmazások ki vannak téve a beavatkozásnak és a visszaéléseknek. A gyökér kulcsok, amelyek az alapját képezik több CA összekapcsolásának és általában hosszabb élettartamúak, különleges óvó rendszabályokat igényelnek, bele értve a privát kulcsok tárolására a biztonságos, nem hálózatra kapcsolt hardveregység alkalmazását. További követelmény a több, meghatározó, megosztott kulcs tulajdonos, a CA tanúsítvány kiadási és a kulcs aláírási folyamat szigorúan ellenőrzött és auditált végrehajtása. A szigorú biztonsági szabályok teljes arzenálját ugyancsak érvénybe kell léptetni, beleértve a CA-nak helyet adó objektumok (helyiség, épület és berendezések) fizikai biztonságát, a személyi biztonsági intézkedéseket (ebbe értve a CA-hoz hozzáférő személyi állomány átfogó ellenőrzését és a különleges képzést), és a folyamat kontrollt, hogy kikényszerítse olyan irányelvek végrehajtását, mint az összes szenzitív funkció kettős ellenőrzése. A biztonságos objektum tipikusan 7x24 órás alapon kell üzemeljen és katasztrófa utáni teljes helyreállítást biztosító mentésekkel kell rendelkezzen. Tekintve, hogy a CA szigorú biztonsági feltételeket támaszt, az épület és az üzemeltetés költségei sok vállalkozás számára elriasztóak. A CA funkció külső kézbe adása nem feltétlen megoldás, mivel a vállalatok legtöbbször teljes irányítási, ellenőrzési jogot akarnak gyakorolni a nyilvános kulcsú infrastruktúrájuk felett, hogy meghatározhassák, ki kaphat tanúsítványt, mi legyen a tanúsítvány tartalma, hogyan és miképp vonható vissza a tanúsítvány és a CA mindennapi üzemeltetését is kézben tarthassák. Erre nyújt megoldást a távoli, biztonságos háttér számítóközpont, amely a napi mentésekkel és visszaellenőrzésekkel, lényegében a CA adatbázisainak megkettőzésével viszonylag olcsó és minden vállalat számára testre szabható megoldást biztosít.
30
A PKI terméket, szolgáltatást alkalmazó szervezet biztonsági tartományokat alakíthat ki, melyekben egy tanúsító hatóság a tanúsítvány és kulcs kibocsátást ellátja. Minősített kapcsolati viszonyt hozhat létre a szervezet, különböző biztonsági tartományokkal egy CA hierarchián belül, vagy akár kereszttanúsítással más CA-kkal. Alapkövetelmény a szabvány alapú átjárhatóság, azaz a nyílt együttműködés a hálózatok között. Fontos a tanúsítvány és kulcs menedzsment központosítása a lehető legteljesebb mértékben. A központosítás és a lehető legkevesebb CA bevezetésére törekvés jelentősen csökkentheti a biztonsági kockázatot. A nagyszámú tanúsítványt kibocsátó CA hierarchia kiépítésére vállalkozó szervezeteknek a PKI technológia gyors változásával járó kockázati problémákra is fel kell készülniük. A felhasználóknak meg kell szokniuk a név/címtár (directory) szolgáltatások, mint a PKI alapelemének használatát. Ezen szolgáltatások nélkül sokkal nehezebb bevezetni és hatékonyan menedzselni a PKI-t. A PKI szervezeten belüli használatához elengedhetetlen a kulcsmenedzsment tökéletes működése. Fontos hangsúlyozni a különbséget a kulcs menedzsment és a tanúsítvány menedzsment között. A kulcs menedzsment a hosszú távú méretezés szempontjából fontos szempont. A PKI jellemzőinek és a használata során felmerülő potenciális problémáinak megértésével jobban felkészülhetünk alkalmazására. Már évek óta, mikor a kliens személyi számítógépekre telepítik a Netscape Navigátor, vagy a Microsoft Internet Explorer böngészőket, egyben telepítik a Web szerverek tanúsítványait is a nyilvános kulcsaikkal együtt, amely biztosítja az SSL alapú kommunikációt vagy a Java és Active X szoftverek digitális aláírás ellenőrzését. A csoportmunkát támogató Lotus Notes szintén a nyilvános titkosítást alkalmazza. A PKI licencek tekintetében az RSA kapcsolatokkal rendelkező Verisign-t és a Northern Telecom érdekeltségű Entrust-ot érdemes megemlíteni. A következő lépés az infrastruktúra fejlesztésében a szervezeten belüli kulcs menedzsment és név/címtár szolgáltatások használatának elősegítése. Mindezt a Windows 2000 natívan tartalmazza. A közszolgálati CA-knak meghatározott bizalmi felelőssége van jogállásuk következtében, mindezeket bizonyos jogszabályok és jogosítványok tovább erősíthetik. A privát CA-k ugyanakkor rugalmasabban tudják alakítani üzletpolitikájukat és gyakorlatukat a felhasználói igények függvényében.
A nyilvános kulcsú szolgáltatási környezet A PKI szolgáltatási környezete három féle lehet. A leglényegesebb feladatok, melyek ellátása minden környezetben szükséges a tanúsítványgenerálás, a tanúsítványterjesztés és a tanúsítványmenedzsment. Az egyes környezeti modellek legfontosabb jellemzői az alábbiak: 1.
Szervezeti környezet
A szervezet által meghatározott környezetben a végfelhasználói alkalmazásokig bezárólag konzisztens és átlátható biztonságot kell teremteni. Ebben a környezetben a szervezet a legnagyobb mértékű ellenőrzési jogokkal és lehetőségekkel rendelkezik, amely biztosítja, hogy mind az infrastrukturális, mind a végfelhasználói alkalmazások beruházásainál érvényre juttassák az együttműködő PKI megoldások elterjesztését. 2.
Szervezetek közötti környezet
A szervezetek közötti környezetet azok a szervezetek közötti kapcsolatok jellemzik, amelyekkel ezek biztosítják a szervezetek közötti un.. B2B vagy B2G elektronikus kereskedelemhez szükséges hiteles és biztonságos infrastruktúrát. Minden szervezet a saját erőforrásai felett
31
rendelkezik, mind az infrastruktúra, mind a végfelhasználói alkalmazások együtt kell működjenek más PKI-kkal. 3.
A fogyasztói környezet
A fogyasztói környezetet azok a szervezetek alakítják, amelyek fogyasztóikkal Internetes elektronikus kereskedelmet - B2C - kívánnak kialakítani, de ide kell sorolnunk az elektronikus kormányzat, vagy az e-demokrácia különböző, az állampolgár és a közigazgatási szervek között kialakítandó, kapcsolatokat is. Az infrastruktúra fejlesztése során a szervezetnek együtt kell működnie fogyasztóival az alkalmazások széles körét - jellemzően WEB böngészőket és elektronikus levelezést - támogatva.
A PKI szolgáltatással szemben támasztott lényegi követelmények Röviden az alábbi követelményeket kell biztosítani bármely PKI szolgáltatásnak: −
Megbízható PKI technológia: ebbe bele tartozik a tanúsítvány kibocsátás és életciklus menedzsment, a különféle tanúsítvány típusok előállítása és működtetése, a megfelelő nyilvántartási tevékenységek, a rekordok tárolása, a címtárak integrálása és a kulcsok menedzselése a legkritikusabb üzemeltetési és terhelési viszonyok között is.
−
Nyílt architektúra, amely a nemzetközi piac legjobb alkalmazásaira épül: biztosítani kell valamennyi régi és bármilyen új alkalmazással az együttműködést, elkerülve a végfelhasználói rendszereken az alkalmazás specifikus szoftverek telepítését, és lehetőséget adva a szervezeten kívüli rendszerekkel a szükséges együttműködésre.
−
Magas fokú rendelkezésre állás és méretezhetőség: a PKI-nak 7x24 órán át rendelkezésre kell állnia, minden felhasználó számára, beleértve a rendszereket, hálózatokat, a felhasználók segítését, a folyamatos, katasztrófatűrő működést, jelentős többlet beruházások nélkül.
−
Biztonságos üzemeltetési infrastruktúra: a PKI üzemeltetése a kockázatkezelésre különleges feladatokat ró. Biztosítani kell, hogy a szervezet jó hírnevét sem erkölcsi, jogi, sem anyagi vonatkozásban ne veszélyeztesse az Internet kapcsolat és a szervezet szenzitív információi a legmegbízhatóbb, hacker-álló PKI védelmet megkapják.
−
Alkalmasság a külső kapcsolatok kezelésére: a PKI különböző szervezeteket, közösségeket szolgálhat ki egy zárt hálózaton belül, több privát hálózat között és azokon kívül az Internetről is.
A PKI a következő szolgáltatásokat nyújtja A PKI célja a hitelt érdemlően működő hálózati környezet kialakítása és működtetése. Ezt a célt a kulcs- és tanúsítványszolgáltatásokkal éri el, amelyek biztosítják a legkülönbözőbb elektronikus alkalmazásokban a titkosítás és a digitális aláírások használatát. Alapvető követelmény a PKI-ban az átláthatóság minden felhasználó számára. Az átláthatóság azt jelenti ebben az esetben, hogy a titkosítás, vagy a digitális aláírás sikeres alkalmazásához a felhasználónak nem kell ismernie, hogy a PKI miként kezeli a tanúsítványokat és kulcsokat, de az tökéletesen és követhetően megbízhat a rendszerben.
32
A leglényegesebb PKI szolgáltatások: −
Kulcsok menedzselése: alapesetként egy új kulcs kibocsátása, a meglévő kulcsok frissítése vagy visszavonása, és a különböző kulcs kibocsátóktól származó kulcsokhoz kapcsolt biztonsági szintek menedzselése.
−
Kulcsok nyilvánossága: a PKI ügyfelei számára a nyilvános kulcsok megtalálására és letöltésére, valamint, az adott kulcs érvényességére jól meghatározott eljárást ajánl. Amennyiben bármely felhasználó nem képes hozzáférni a kulcsokhoz, és tisztázni, hogy az érvényes-e, nem tudja használni a nyilvános kulcsú szolgáltatásokat.
−
Kulcsok használata: a PKI a kulcsok használatának egyszerű módját nyújtja, nem csupán azzal, hogy a felhasználónak rendelkezésére bocsátja a szükséges kulcsot, hanem könnyen kezelhető alkalmazásokat is biztosít, amelyekkel végrehajthatók a nyilvános kulcsú titkosítási műveletek, biztosítva az elektronikus levelezés, az elektronikus kereskedelem és a hálózatok titkosságát, megbízhatóságát.
−
Kiegészítő szolgáltatások: a menedzselt PKI további - az alapvető szolgáltatásokkal együttműködni képes - szolgáltatásokat is biztosíthat. Ezek általában az elektronikus kereskedelem sokféle alkalmazását támogatják. Ilyenek például az időbélyegző, a privilégiumok menedzselése, vagy az automatikus regisztrációs hatóságok.
Mára a PKI minden hálózatbiztonsági megoldás alapja, bele értve az információ források WEB böngészős hozzáférésének ellenőrzését, a titkosított elektronikus üzeneteket, a digitális aláírások és munkafolyamatok különböző formáit, a tűzfalakat, a virtuális privát hálózatok útvonal-irányítóit, könyvtár struktúrákat és a szervezeti alkalmazások egyszerű szignálását. A megfelelően tervezett PKI kötelező szolgáltatási elemei a fentek alapján: −
nyilvános kulcsú tanúsítványok,
−
tanúsítványtároló,
−
tanúsítvány visszavonás,
−
kulcsok biztonsági másolata és visszaállítása,
−
a digitális aláírások letagadhatatlanságának biztosítása,
−
a kulcs párok és tanúsítványok automatikus frissítése,
−
a kulcsok történetiségének menedzselése,
−
a kereszt tanúsítás támogatása,
−
felhasználói szoftver, amely a fenti szolgáltatásokkal konzisztensen és hitelt érdemlő módon együtt tud működni.
biztonságosan,
PKI modellek A tanúsítványok és kulcs menedzsment szempontjából a hierarchikus (VeriSign, Netscape, Microsoft), a hálózati (Entrust) és a WEB központú (PGP) modell koncepciók terjedtek el. Napjainkra úgy tűnik, hogy a hierarchikus megoldás alkalmazása kerül előtérbe hatékonysága és más piaci tényezők (pl. a Windows 2000 is ezt követi) folytán. A hierarchikus megoldáson belül az alábbi két modell lehetséges: 33
A független megoldás a piacon kínált szoftverrel önálló PKI szolgáltatás kialakítása. Ekkor az üzemeltető szervezet százszázalékos felelősséget vállal mindamellett, hogy a PKI kialakítás teljes költségét is magára vállalja. A kiválasztott szállító támogatási készségén és szoftverén múlik, hogy az üzemeltetés mindennapjaiban, a különféle biztonsági veszélyhelyzetek, éjszakai üzemzavarok, felhasználói csúcsterhelések, hacker támadások problémáit, vagy a mindezek elhárítására alkalmazott tűzoltó intézkedéseket, módosításokat hogyan tűri a rendszer. A másik modell az integrált PKI, amely megtartja az adott szervezet által használt PKI szoftver és hardver állomány saját felelősségű ellenőrzött működtetését, azonban a saját PKI rendszer kompatíbilis kapcsolatban áll más bevált alkalmazásokkal, tanúsítvány kibocsátó szolgáltatásokkal és infrastruktúrákkal kialakított, magas fokú rendelkezésre állással és nagy biztonsággal jellemezhető PKI gerinchálózattal, amely lehetővé teszi a függetlenül kontrollált rendszerek mellett a felelősség megosztását. −
A fenti modellek azonban a szervezet/vállalat feladatainak, struktúrájának, sőt outsourcing politikájának függvényében tovább alakulhatnak:
−
Az önálló vállalati tanúsító hatóság esetében akár a szervezeten kívüli cég is elláthatja a CA feladatait.
−
A nagyvállalati tanúsító hatóság saját cégén belül gyökér hatóság, azonban akár alárendelt regisztrációs és elosztó központok, vagy alárendelt tanúsító hatóságok lehetnek a vállalaton belül a szervezeti és földrajzi megosztottság szerint.
−
A heterogén modell a szervezetek közötti biztonságos kommunikáció érdekében külső kapcsolatokat, kölcsönös tanúsítást is lehetővé tesz a felelősségi viszonyok függvényében.
A nyilvános kulcsú infrastruktúra architektúrális elemei A nyilvános kulcsú infrastruktúra architektúrális elemei a digitális tanúsítványok létrehozását, ellenőrzését, továbbítását és használatát biztosítják. −
A tanúsítvány alanya és felhasználója. A legalapvetőbb PKI architektúra elem a tanúsítvány alanya, amely jobbára (minősített eseten kizárólag) egy személy, bár bármely jogi személyiségnek - beleértve egy céget, rendszert és alkalmazást - lehet tanúsított nyilvános kulcsa. (pl. a szervernek). A személy vagy szoftver lehet tehát a tanúsítvány alanya, ugyanakkor más egyedekkel együtt a felhasználója is tanúsítványoknak, amikor ellenőrzi a nyilvános kulcs használatával egy digitális aláírás valódiságát.
A jól felépített PKI architektúra a következő funkcionális elemeket tartalmazza: −
Tanúsító hatóságok (CA). A nyilvános kulcsú titkosítás abban az esetben használható, ha a felhasználókat - akik más felekkel valamilyen kapcsolatot építenek ki biztosítani tudjuk, hogy kapcsolatuk biztonságos, azaz a felek azonossága és kulcsai érvényesek és hitelt érdemlőek. Ez a bizonyosság megköveteli, hogy a PKI minden felhasználója regisztrált azonosítóval rendelkezzen. Ezek az azonosítók a digitális formában tárolt nyilvános kulcsú tanúsítványok. A felhasználó azonosításához szükséges nevét és más adatait a két kulccsal a tanúsító hatóságot megtestesítő emberek, folyamatok és eszközök kapcsolják egybe és tanúsítják a hatóság privát kulcsával aláírt tanúsítványukkal. A tanúsító hatóság az előfizetője számára tanúsítványokat bocsát ki, amelyekben egy sor adatot saját privát kulcsú digitális aláírásával tanúsít. Ezek között hiteles információt nyújt a következőkről: 34
−
Az előfizető u.n. megkülönböztetett neve (DN: Distinguished Name), amely tartalmazza a nevet és valami kiegészítő attribútumot, amely segítségével az előfizető egyértelműen azonosítható (pl. a család és keresztnév mellett célszerűen a személyi azonosító vagy TB szám, de lehet bármi egyéb nyilvántartási szám is).
−
Az előfizető nyilvános kulcsa. Ennek segítségével kódolhatják mások az előfizetőnek szánt üzeneteket, illetve ellenőrizhetik digitális aláírását és üzenteinek teljességét.
− −
A tanúsítvány érvényességének tartama. (pl. a kibocsátás és a lejárat napja) Azoknak a felhasználási céloknak a tanúsítása, amikre a nyilvános kulcs használható. (pl. titkosító kódolásra, illetve digitális aláírás ellenőrzésére vagy mindkettőre)
Az alaphelyzetben a tanúsító hatóság (CA- certificate authority) a felhasználók meghatározott köre számára bocsát ki nyilvános kulcsot hordozó tanúsítványt. A felhasználók közössége alkotja az u.n. biztonsági tartományt (security domain). A gyakorlatban a CA hatókörének két véglete lehetséges, a nagy kereskedelmi CA-k (pl. Verisign, GTE Cybertrust, Thawte, Belsign) amelyek tanúsítványok millióit bocsátják ki, míg a kicsik egy-egy szervezet részlegének munkatársait látják csak el tanúsítvánnyal. Minden CA maga dönti el (bizonyos szabványok, illetve jogszabályok és ajánlások betartása mellett), milyen attribútumokat vesz fel a tanúsítványba, illetve, hogy ezek valódiságát miként ellenőrzi. A CA kezeli a kibocsátott tanúsítványok visszavonási listáját (CRL, Certificate Revocation List) is, amely az adott nyilvános kulcs érvénytelenségét hirdeti, valamely jól hozzáférhető módon kibocsátó pontok alkalmazásával. Bár a tanúsító egy személy is lehet, elnevezéséből következően egy feljebb álló hatósági feladatot ellátó intézményről van szó. A felhasználó a CA tanúsítványban lévő nyilvános kulcsával ellenőrizheti a tanúsítvány hitelességét. Amennyiben a CA minősített hatóság, a felhasználó elfogadhatja, hogy a tanúsított szervezet igazi. A tanúsítvány előállításakor a CA játssza a biztonsági hatóság szerepét a PKI-ban, majd betölti a hiteles harmadik fél (Trusted Third Party) funkcióját. Egészen addig alkalmazhatóak a CA által kibocsátott tanúsítványok, míg a felhasználóknak bizalmuk van a tanúsító hatóságban és a tanúsítványok kiadására és kezelésére vonatkozó üzletpolitikájukban. Ezt a struktúrát a harmadik fél általi hitelesítésként ismerik. −
Regisztrációs hatóságok (RA). Az RA önállósága lehetséges változat, jobbára a CA egy alárendelt szerveréről van szó, amelyre a CA a menedzselési funkciót delegálja. Elosztott WAN környezetben azonban hasznos lehet az egy CA tanúsításos felügyelete melletti LAN-onkénti RA telepítése, bár ez a biztonsági láncot megnyújtja.
35
−
PKI adattárak (repository). Alapesetben legalább két fontos adattárat alkalmaz a PKI architektúra. Először is a tanúsító hatóság a kibocsátott, érvényes kulcsok biztonsági másolatainak tárolására és a lejárt, visszavont kulcsok archiválására a CA-val azonosan magas védettségi fokon, külön elzárt helyiségben, épületben adatbázist tart fenn. Másrészt a tanúsítványokat és a visszavonási listákat egy nyilvánosan könnyen elérhető adatbázisban kell tárolni és elosztásukat biztosítani. Erre gyakorta relációs adatbázisokat használtak bár a PKI adattárakra a leglogikusabb megoldás a Lightweight Directory Access Protocol (LDAP) alapú név/címtár szolgáltatás implementálása. Logikailag ötféle adattárat különböztetnek meg a PKI-ban, melyek azonban különböző fizikai megvalósítást jelenthetnek:
−
MY a használó saját, vagy gépének tanúsítványát és hozzá tartozó privát kulcsot tárolja.
−
CA a tanúsítási láncban a kibocsátó vagy közbenső hatóságok által kiadott tanúsítványokat tárolja.
−
TRUST a minősített CA-k nyilvántartását biztosító CTL -eket (Certificate Trust List) őrzi. A listák digitális aláírással vannak ellátva, így nyílt hálózatokon is továbbíthatóak.
− −
ROOT A minősített, gyökér CA által aláírt tanúsítványokat tárolja. UserDS A tanúsítvány adattárak logikai szerkezetét tárolja a külső adattárak elérésnek egyszerűsítése céljából.
Név/címtár (directory) integráció A név/címtárak igen lényegesek a PKI működése szempontjából. A CA digitális aláírása a tanúsítványon biztosítja, hogy a tartalom bármilyen hamisítása könnyen észrevehető. Egészen addig, míg a CA aláírása a tanúsítványon azonosítható, a tanúsítvány teljessége nem sérült. Tekintve, hogy a tanúsítvány teljessége ellenőrizhető a CA digitális aláírásának a nyilvános kulccsal történő összevetésével a tanúsítvány önmagában biztonságos és teljesen nyilvános formában közreadható (pl. nyilvánosan elérhető címtár rendszereken). Az a felhasználó, amelyik a címtárból egy tanúsítvánnyal letölt egy nyilvános kulcsot, biztos lehet abban, hogy a nyilvános kulcs érvényes. Azaz a felhasználók bizonyosak lehetnek abban, hogy a tanúsítvány és a hozzá kapcsolt nyilvános kulcs ahhoz az egyedhez tartozik, amelyet a DN, megkülönböztetett név azonosít. Továbbá a felhasználó biztos lehet abban, hogy a nyilvános kulcs érvényességi idején belül van, és a nyilvános kulcs biztonságosan használható a CA által tanúsított módon. A tanúsítványokat a megbízható harmadik felet képviselő tanúsító hatóság, vagy akár a felhasználók cége is hozzáférhetővé kell tegye, hogy azokat a különböző alkalmazások lehívhassák és használhassák. A tárolást és szétosztást biztosító adattárak hálózati szolgáltatást is végeznek, tehát nem egyszerű adatbázisok. Alapkövetelmény ma már az LDAP támogatása. A legtöbb szállító PKI terméke LDAP alapú kapcsolatokat használ nemcsak a tanúsítványok, de a CA-k és más PKI elemek szempontjából lényeges címtár adatok előállítására, menedzselésére és olvasására. Hasonló módon alapkövetelmény a név/címtárak replikációja is. Fontos lehetőség, melyet a PKI támogat, a multimaster replikáció. Tekintve, hogy a PKI termékek a név/címtárat használják a kulcsok tárolására, elosztására, keresésére, letöltésére, ezért a PKI termékek telepítése különleges követelményeket támaszt a név/címtárakkal szemben. A CA-k a név/címtárba többféle adatot jegyeznek be (pl. hol tartja karban az általa irányított biztonsági tartományt, kik a kereszt tanúsítók, hol vannak a saját, illetve más tartományok visszavonási listái, de 36
bejegyzi a felhasználók tanúsítványát is, mint a felhasználó objektumának attribútumát, stb.), és mindezeket a napi gyakorlat szerint módosítani is szükséges. Az X.500 az alapvető név/címtár szabvány, azonban a címtár elérését biztosító DAP bonyolultsága folytán az alkalmazásokban nem terjedt el a közvetlen használata, helyette az LDAP-ot használják. A PKI termékek azonban jellemzően támogatják az ITU-T X.500 (X.520, X.521 és X.509) (ISO/IEC 9594 szabványcsalád) objektum osztályokat és attribútumokat, bár egyes PKI termékek egyedi, nem szabványos név/címtárakat alkalmaznak. Az elmúlt évek során ipari szabvánnyá vált az LDAP. Ennek okai: −
A legtöbb cég által megkövetelt átláthatóságot biztosítja a tanúsítványok címtárakban történő tárolása és a felhasználók felhatalmazása alapján működő visszaállító alkalmazások.
−
Az LDAP-ot támogató legtöbb címtár technológia úgy méretezhető, hogy:
−
nagyon nagy számú bejegyzést kezeljen,
−
az alkalmazott információ tárolási és visszaállítási módszereknek köszönhetően hatékonyan válaszoljon a keresőmotorok kéréseire,
−
megosztható a hálózaton úgy, hogy a legmegosztottabb vállalati hálózatok követelményeinek is eleget tesz.
A fentieken túlmenően a címtárak más adatok, pl. a visszavonási listák tárolásra, terjesztésére is alkalmasak. Visszavonási listák (CRL). Az alkalmazási szoftver a tanúsítvány kibocsátó aláírásának ellenőrzésén túl célszerűen megvizsgálja, hogy a felhasználás pillanatában érvényes-e egyáltalában. A hitelességüket elvesztett kártyákat a CA köteles visszavonni. Erre a lejárati idő előtt is számtalan ok szolgálhat. Például a tanúsítványnak megfelelő nyílt kulcshoz tartozó valamelyik privát kulcsot akár az aláíró, akár a megfejtő privát kulcsot kompromittálják. Más esetben a szervezeti biztonságpolitika előírhatja, hogy a cégtől kilépők tanúsítványait vissza kell vonni. Ilyenkor a rendszer használóinak tudomásra kell hozni, hogy a kérdéses tanúsítványok nem tekinthetők biztonságosnak. Tekintve, hogy a visszahívás állapotát a tanúsítvány alkalmazása előtt kell ellenőrizni, a PKI-nak tartalmaznia kell a jól méretezhető visszahívási rendszert. A CA az általa kibocsátott minden tanúsítványra, a visszahívásra vonatkozó információk terjesztését nagy biztonsággal meg kell, oldja. visszahívási rendszerében. Ennek a módja a biztonságos tanúsítvány visszavonási lista (CRL, Certificate Revocation List) fenntartása és terjesztése a címtár segítségével. Másik módszer az Online Certificate Status Protocol (OCSP) alkalmazása, amelyben a szerver az ügyfelek kéréseire adja meg a választ. Bármely megoldást választják, a lényeg, hogy az ügyfél oldali szoftvernek a felhasználó nevében automatikusan le kell tudni ellenőrizni a tanúsítványokat, nincsenek-e a visszahívási listán. −
Tanúsítvány kibocsátó pontok. Alapesetben a második típusú adattárból (név/címtárból) biztosítja a tanúsítványok és a visszavonási listák szervezeten belüli és kívüli elérhetőségét. A jó tanúsító hatóság a kibocsátó pontok replikációjával megteremti a felhasználók számára a hierarchiába tartozó valamennyi tanúsítvány automatikus letölthetőségét. A kibocsátó pont bármilyen fajta név/címtár szolgáltatást használhat a gyártófüggő operációs rendszerhez kapcsolttól az X.500, illetve LDAP szabványos megoldásig, de a tanúsítványokat és a visszavonási listákat közzé teheti WEB lapokon, intelligens kártyákon, hajlékony vagy CD-ROM lemezeken is. 37
−
Kulcs és tanúsítvány menedzselési eszközök. A menedzselési eszközök biztosítják a kiadott tanúsítványok különböző adatainak kötelező nyilvántartását. A lejárt vagy visszavont kulcsokat tartalmazó tanúsítványokat hosszú időre archiválni kell, hogy a titkos levelek, vagy a digitálisan aláírt dokumentumok használatát hosszú távon biztosítani lehessen. A tanúsítványok és hozzájuk tartozó kulcsok archiválását, visszaállítását, megújítását a biztonsági másolatok és a visszaállíthatóság segítik. Biztosítani kell a tanúsító és kibocsátó tevékenységének felügyeletére a lehetőséget, amihez elengedhetetlen a menedzsment, az adminisztráció és az audit eszközeinek használata. Fontos a kulcs és tanúsítvány menedzsment központosítása a lehető legteljesebb mértékben. A központosítás és a lehető legkevesebb CA bevezetésére törekvés jelentősen csökkentheti a biztonsági kockázatot. A nagyszámú tanúsítványt kibocsátó CA hierarchia kiépítésére vállalkozó szervezeteknek a PKI technológia gyors változásával járó kockázati problémákra is fel kell készülniük. A felhasználóknak meg kell szokniuk a név/címtár (directory) szolgáltatások, mint a PKI alapelemének használatát. Ezen szolgáltatások nélkül sokkal nehezebb bevezetni és hatékonyan menedzselni a PKI-t. A PKI szervezeten belüli használatához elengedhetetlen a kulcsmenedzsment tökéletes működése. Fontos hangsúlyozni a különbséget a kulcs menedzsment és a tanúsítvány menedzsment között. A kulcs menedzsment a hosszú távú méretezés szempontjából fontos.
A kulcs és tanúsítvány menedzselés területei: −
Kulcsok visszaállíthatóságának biztosítása.
−
A letagadhatatlanság biztosítása
−
A kulcsok és tanúsítványok frissítése
−
Kereszttanúsítás
Nehéz egyidejűleg eleget tenni a kulcs visszaállíthatóságának és a letagadhatatlanság követelményének teljesítéséhez. Ismeretes, hogy a kulcs pároknak különböző funkciói lehetnek. Az egyik párt az adatok titkosításra és megfejtésére használják, ezt "titkosító kulcs párnak" hívják. A másik kulcs pár az adatok digitális aláírására és az aláírások ellenőrzésére használható, ez az "aláíró kulcs pár". A visszaállíthatóság érdekében a megfejtő kulcsok biztonságos tárolását kell megoldani. A letagadhatatlanság biztosításához azonban az aláíró kulcsról nem készíthető másolat és a kulcs minden pillanatban a felhasználó kizárólagos ellenőrzése alatt kell legyen. Mindezek teljesítéséhez a PKI-ban egyidejűleg minden felhasználónak legalább két kulcs párral kell rendelkeznie. Bármelyik pillanatban a felhasználónak kell egy kulcs pár a titkosításra és a megfejtésre, és egy másik kulcs pár a digitális aláírásra és az aláírás ellenőrzésére. Kulcsok visszaállítása. A tanúsítvány érvényességének lejártakor a megújításhoz a CA felhasználhatja a kérelmező meglévő, már ellenőrzött adatait, esetleg új nyilvános kulcsot is generál. A PKI archív adattár másik lehetősége a kulcs pár visszaállíthatóságának biztosítása, amely csak szigorúan ellenőrzötten, a tulajdonos tudtával és beleegyezésével történhet, pl. elvesztés, megsemmisülés esetén. Ettől eltérően előfordulhat kulcs visszaállítás, ha a kulcsot cég/intézmény felhatalmazásából hivatalos dokumentumokra, stb. használták, illetve bírósági, ügyészi intézkedésre nemzetbiztonsági vagy más súlyos büntetőeljárás során. A kulcs visszaállítással nemcsak a privát kulcs használója személyesíthető meg, de a titkosított elektronikus levelei is elolvashatók.
38
A két kulcsos titkosítást, digitális aláírást alkalmazó személyek, szerveztek jogos igénye, hogy a titkosított adatokat akkor is megfejthessék, ha elveszítik a privát kulcsukat. Ez azt jelenti, hogy az adott vállalat, amelyhez a felhasználó tartozik megköveteli a megfejtő kulcsok biztonsági másolatainak tárolását és helyreállíthatóságukat. Ennek két oka is van. Elsőként említhető az az eset, mikor a felhasználó elfelejti jelszavát. A szervezte számára katasztrofális lehet, ha valamelyik alkalmazottja elfelejtve a hozzáférési jelszavát, mivel örökre elveszít valamely titkosított információt. Megfordítva az is előfordulhat, hogy a felhasználó értékes, szenzitív információkat nem titkosít attól való félelmében, hogy azok elveszhetnek, ha elfelejti a megfejtéshez szükséges jelszavat. Másrészt a felhasználó elveszítheti, elronthatja, tönkre teheti a megfejtő kulcsokat tartalmazó és tároló eszközöket. Például, ha a megfejtő kulcs mágneses tárolón vagy kártyán van, a mágneses tér sérülhet. A titkosított információk ilyen elvesztése ismét csak végzetes lehet. A felhasználóknak problémáik merülhetnek fel titkosított adataik visszafejtésekor, ha a megfejtő kulcsokról nem készítettek biztonsági másolatot. A kulcs visszaállítás és tárolás speciális esete a kulcsok letétbe helyezése harmadik félnél. Az igen szenzitív alkalmazások bonyolultabb, akár jogszabályban, törvényben előírt visszaállítási folyamatokat igényelhetnek. Ekkor merül fel a kulcs letétbe helyezése. A letétbe helyezést két szempontból lehet vizsgálni. Az első a technikai kérdés, a másik, hogy a kormányok megkövetelhetik-e, illetve végezhetnek-e letéti tárolást. A Capstone javaslat részeként például az USA Szövetségi Kormány, igaz eredménytelenül, de megpróbálta rendvédelmi célokból előírni a kulcsok letétbe helyezését. A letéti terv szerint az ügynökségek (melyek egy szervezeten belül, de kívül is lehetnek) az adattitkosításhoz használt kulcsok másolatait tárolják, és a bűnüldöző hatóságnak csak akkor adhatják át, ha speciális meghatalmazás alapján igényelik. A kulcsok bűnüldözés céljából történő letétbe helyezése sok jogi, személyi adatvédelmi problémát is felvethet. A szervezeti, vállalati kulcshasználók esetében azonban a fentiekben is említett okok miatt indokolt a kulcsok letétbe helyezése a biztonsági másolatok és visszaállítási folyamatok kapcsán. A letéti társaság egy harmadik külső fél lehet, mint a tanúsító hatóság, vagy egy belső hivatal, amelyik azonban függetlenül működik. A letéti hivatal a letétbe helyezendő kulcsot, vagy kulcs feleket titkosítja nyilvános kulcsukkal együtt. A letétbe helyezett kulcsok titkosításához a hivatal saját privát kulcsát használja, ezért gyakorta helyben tárolhatók, a hálózati menedzsereknek nem kell továbbítaniuk a titkosított kulcs feleket a hivatalhoz, csak ha a kulcsokat vissza akarják állítani. Ekkor a letéti hivatal visszafejti a kulcs titkosítását és megküldi a kulcsot az ügyfélnek. Ebben a helyzetben a kereskedelmi letéti társaság, mint titkosító biztonsági hálózati ügynök működik. A kormányzati beavatkozás és a bűnüldözés belekeverése ellenére, a kulcs letéti központok körüli ellentmondás a letéti ügynökök megbízhatóságában van inkább. Amennyiben egy szervezet harmadik félnek számító letéti ügynököt vesz igénybe, az ügynök a bizalmi lánc egy tagja lesz. Az ügynök, vagy társaság személyzetére, rendszereire és eljárásaira biztonsági adatokat bíznak, amelyek veszélyeztethetik a vállalat legfontosabb információit. Más szóval a letéti társaság újabb támadási pontot kínál azoknak, akik be akarnak hatolni a vállalathoz, vagy az adatait meg akarják szerezni. Általában véve is, bármilyen letéti tevékenység veszélyezteti a rendszer biztonságát. Amikor egy új személy vagy folyamat beiktatásra kerül a biztonsági 39
láncba, egyidejűleg egy újabb hibaforrás lehetősége is létrejön. Lényegében a kulcs letét elsősorban szervezési és nem technológiai kérdés. A szükséges garanciák, különösen nagy tranzakcióknál igen költségesek lehetnek, ennek ellenére sok cégnél igény lehet a letéti szolgáltatások bevezetésére. Vegyük észre, hogy az eddigiekben nem volt szó az aláíró kulcs pár biztonsági másolatáról és visszaállíthatóságáról. Kizárólag a felhasználó megfejtő kulcsairól szükséges másolatot készíteni. Addig, míg egy hiteles szolgáltató - CA - biztonságosan kezeli a felhasználók megfejtő kulcsait, a biztonság nem sérül, de a felhasználó adatai bármikor visszafejthetőek. Ugyanakkor az aláíró kulcsoknak a titkosító kulcsokétól eltérő követelményei vannak. Az aláíró kulcsok másolása tönkre teszi a PKI alapvető felépítését. Letagadhatatlanság. A letagadhatatlanság követelménye azt jelenti, hogy a felek nem tudják eredményesen megtagadni a részvételt a tranzakcióban. A papír alapú tranzakciókban a kézaláírás biztosítja a letagadhatatlanságot. A digitális világban a digitális aláírás veszi át a toll alapú aláírás szerepét. Amennyiben az egyik fél visszautasítja a tranzakciót, a letagadás esete merülhet fel. (például valaki azt mondja, hogy ellopták bankkártyáját, ez azt jelenti, hogy ő elhárítja a felelősséget minden tranzakció kapcsán, ami a letiltás után létesül.) A digitális aláírás az elektronikus kereskedelem (e-government, e-business) minden formájában szükséges. A letagadhatatlanság legalapvetőbb követelménye, hogy a digitális aláíráshoz használt kulcs - az aláíró kulcs generálása és tárolása biztonságos módon történjen a felhasználó kizárólagos ellenőrzése mellett. Nem engedhető meg az aláíró kulcs másolása. Ellentétben a titkosító kulcs párral nincs semmiféle műszaki vagy szervezeti indok az aláíró kulcsok biztonsági másolására vagy tárolására, ha a felhasználó elfelejti jelszavát, vagy elveszíti, tönkre teszi aláíró kulcsait. Ilyen esetekben elfogadható, hogy a felhasználó számára új aláíró kulcsokat generáljanak, és attól kezdve azokat használja. Frissítés. Egy idő múlva a felhasználóknak számos kulcs párja lehet, melyeket megfelelő módon menedzselni kell. A kulcsok ugyanis nem örök életűek, azokat időről időre frissíteni kell. Ennek kapcsán biztosítani kell a kulcsok frissítését, és az indokolt esetekben kezelni kell a kulcs párok történeti adatait. −
A kulcs párok frissítésének a felhasználó számára átláthatónak kell lennie, azaz nem kell ismernie a folyamatot, azonban biztosítani kell az automatikus frissítést a lejárati idő előtt, hogy a kulcs lejárta miatt ne legyen megtagadható a szolgáltatás. A titkosító kulcs pár frissítésekor a korábbi kulcs pár történetét meg kell őrizni. Ez a kulcs történet biztosítja, hogy a felhasználó bármelyik régi kulcsával titkosított adatát vissza tudja fejteni, ugyanis csak a titkosító kulcs saját megfejtő párjával lehet visszaállítani bármely titkosított információt. A kulcs történetet ugyanolyan biztonságosan kell üzemeltetni, mint a kulcsok biztonsági másolatainak tárolását, vagy a visszaállító rendszert.
Az aláíró kulcs pár frissítésekor a lejárt aláíró kulcsot biztonságos módon meg kell semmisíteni. A megsemmisítéssel megakadályozható, hogy bárki más hozzáférhessen az aláíró kulcshoz. Ez az eljárás indokolt, hiszen nincs szükség a régi aláíró kulcs visszaállításra. Kereszttanúsítás. A harmadik tanúsító fél felelősségi viszonyait a különböző tanúsítási tartományok között ki lehet terjeszteni a kereszttanúsítással, vagy PKI hálózattal. Például két, különböző tanúsítóhoz tartozó kereskedelmi partner azt 40
kívánja, hogy a másik CA által kibocsátott tanúsítványt kölcsönösen ellenőrizni lehessen a kétoldalú kapcsolatban. Más esetben egy földrajzilag szétszórt egységekkel rendelkező nagyvállalat a megfelelő helyi CA-kat úgy tudja igénybe venni, ha a regionális CA-k hierarchikusan alá vannak rendelve a kereszttanúsítással a gyökér CAnak a megbízható elektronikus kapcsolatok segítségével. A kereszttanúsítás két műveletet takar. Az első, nem sűrűn ismételt tevékenység a két CA közötti tanúsítási viszony létrehozása. A kölcsönös, kétoldalú kereszttanúsítás esetén a két CA biztonságosan kicseréli ellenőrző kulcsait. Ezek azok a kulcsok, amelyeket a tanúsítványon lévő elektronikus aláírás valódiságának ellenőrzésére használnak. A művelethez tartozik még egy kereszttanúsítvány kibocsátása, amelyet mindegyik CA a másik ellenőrző kulcsával ír alá. Amennyiben hierarchikus kereszttanúsításról van szó, a magasabban álló CA tanúsítja az alacsonyabban állót, az alacsonyabban álló ellenőrző kulcsával. A másik műveletet a ügyfél oldali szoftver hajtja végre. Ezt a műveletet gyakorta végzik, amikor egy felhasználó, kereszt tanúsított CA által kibocsátott tanúsítványát ellenőrzik. Ezt a műveletet elterjedten "a bizalmi lánc végigjárásának" nevezik. A lánc a kereszt tanúsítvány ellenőrzések listájára vonatkozik, amelyet az ellenőrző felhasználó saját kibocsátó CA-ja kulcsának végig kell járni, hogy a másik felhasználó tanúsítvány kibocsátó CA-jának kulcsát leellenőrizze. A bizalmi láncon végigjárva mindenegyes kereszttanúsítványt ellenőrizni kell, hogy még érvényben van-e. Akár a felhasználói, akár a kereszttanúsítványok bármikor visszavonhatók, erről sokszor megfeledkeznek. −
Alkalmazások a kulcs használatának biztosítására: a felhasználók részére könnyen kezelhető, szabványos megoldásokkal lehetővé kell tenni a digitális tanúsítványokkal a titkosítást, elektronikus aláírást, illetve más CA-k által kibocsátott tanúsítvány hitelesítésének ellenőrzését. A PKI követelmények tárgyalása során gyakran lebecsülik a felhasználói oldal szoftverkövetelményeit, kizárólag a CA elemmel foglakoznak. Végeredményben azonban a PKI értéke akkor jelentkezik csak, ha a felhasználók használhatják a titkosításra és az elektronikus aláírásra. Egyértelmű, tehát, hogy a PKI-nak tartalmaznia kell egy olyan szoftvert, amely a felhasználó asztali, személyi számítógépes környezetében konzisztensen és átláthatóan használható (akár elektronikus levelezéshez, böngészéshez, fájlok, könyvtárak titkosításához), ezzel csökkentve a PKI működési költségeit. Természetesen a felhasználói, ügyfél oldali szoftvernek a PKI minden elemével együtt kell tudni működni. Az alábbiakban összefoglaljuk az ügyfél oldali szoftverrel szemben támasztott követelményeket:
Nyilvános kulcsú tanúsítványok: A hiteles harmadik fél alkalmazásához minden PKI-t használó alkalmazásban a tanúsítványokat konzisztens, hitelt érdemlő módon kell használni. Az ügyfél oldali szoftvernek kell ellenőriznie a tanúsító hatóság, a CA tanúsítványon lévő elektronikus aláírásának hitelességét, és meggyőződni arról, hogy az érvényességi tartamán belül van. Biztonsági kulcs másolat és visszaállítás. A PKI-nak támogatnia kell a megfejtő kulcsok másolatainak tárolását és visszaállíthatóságukat, hogy biztosítsa felhasználóit az adatvesztéstől. Az adminisztratív költségekre tekintettel elfogadhatatlan, hogy minden alkalmazás saját tárolási és visszaállító rendszert használjon, inkább meg kell követelni, hogy az alkalmazás együtt tudjon működni egy közös rendszerrel. Az ügyfél oldali szoftver és a közös biztonsági másolat tároló és visszaállító rendszer közötti
41
kapcsolatnak biztonságosnak kell lennie, és az együttműködés módja legyen konzisztens minden PKI alkalmazásra. A letagadhatatlanság megvalósításának támogatása. A letagadhatatlanság alapvető biztosítására az ügyfél oldali szoftvernek kell generálnia az elektronikus aláíráshoz szükséges kulcs párt. Ezen túlmenően az ügyfél oldali szoftvernek kell biztosítania, hogy az aláíró kulcsokat semmilyen körülmények között se lehessen másolni, és mindig a felhasználó ellenőrzése alatt maradjanak. Ennek a funkciónak is konzisztensnek kell lennie minden PKI alkalmazásban. A kulcs párok automatikus frissítése. Az átláthatóság biztosítására az ügyfél oldali szoftvernek kell kezdeményeznie a felhasználó kulcsainak automatikus frissítését. Ezt a műveletet az adott szervezet biztonsági koncepciójával (policy) összhangban kell végrehajtani. A felhasználó számára nem elfogadható, ha neki kell nyilvántartania, mikor kell frissíteni kulcsait. Ennek teljesítésére az ügyfél oldali szoftvernek kell minden PKI alkalmazásra vonatkozóan átláthatóan és konzisztensen frissítenie a kulcsokat. A kulcstörténetek menedzselése. A felhasználó számára a titkosított adatokhoz való, az időbeliségtől független, könnyű hozzáférés biztosítására a PKI alkalmazásoknak kezelni kell a felhasználó kulcsainak történeti adatait. Az ügyfél oldali szoftvernek képesnek kell lennie a felhasználó történeti kulcs adatainak reprodukálására. Méretezhető tanúsítvány adattár. A tanúsítványok terjesztési költségeinek minimalizálása céljából minden PKI alkalmazásnak közös, méretezhető tanúsítvány adattárat kell használnia. A közös adattárból történő tanúsítvány reprodukálás átlátszó megvalósítása javítja a PKI használhatóságát. Drága és bonyolult, ha az alkalmazások különböző tanúsítvány adattárakat igényelnek. Tanúsítvány visszavonás. A PKI alkalmazásoknak együtt kell működniük egy közös és méretezhető tanúsítvány visszavonási rendszerrel. Tekintve, hogy a hitelesség menedzsment miatt a tanúsítvány visszavonás központosított, az ügyfél oldali szoftvernek minden alkalmazásban konzisztensen és átláthatóan együtt kell működnie a tanúsítvány visszavonási rendszerrel. A kereszttanúsítás támogatása. A hitelesség menedzsment koncepciók (policy) támogatására minden PKI alkalmazásnak közös kereszttanúsítási modell alapján kell működnie, hogy a kereszthivatkozásra meghatározottak teljesüljenek. Ismeretes, hogy a kereszthivatkozás lehetőséget nyújt a PKI-ban, hogy egy idegen tanúsító hatóság által kibocsátott tanúsítványt hitelesként fogadjunk el. Így az ügyféloldali szoftvernek kell leellenőriznie, hogy biztosan nincs egyetlen kereszttanúsítvány sem a "hitelességi láncban", amelyet visszavontak. A fenti követelmények az ügyfél oldali szoftver és a PKI elemek közötti együttműködésre vonatkoznak. További követelmények lehetnek, amelyek függetlenek az infrastruktúra elemeitől, például az ügyfél oldali szoftvernek kell biztosítania, hogy a felhasználó titkosíthassa, vagy visszafejthesse információit még akkor is, ha nem áll on-line kapcsolatban a PKI elemeivel. A maximális használhatóság és a minimális költségek biztosítására az ügyfél oldali szoftver többféle kulcs tároló hardvereszközt kell támogasson (például intelligens kártyát, PC kártyát, biztonsági fájlokat, stb.) Biztosítani kell, hogy a felhasználó bármilyen PKI alkalmazásnál egyetlen fajta kulcs tároló eszközt használhasson.
42
−
Hardver támogatás. A PKI alkalmazások biztonságos és felhasználóbarát megoldásait jelentik a különböző kriptográfiai hardver eszközök, mint az intelligens kártyák, PC kártyák, PCI kártyák, melyek a szoftveres megoldásoknál gyorsabb, nagyobb kapacitású és biztonságosabb műveletekre képesek, ugyanakkor a követelmények szerint különböző teljesítményűek.
−
A hatóságok fizikai és hálózati védelme: A CA-k, RA-k és az archív adattárak jelentős bizalmi elemek, melyek kockázati tényezőjét a kiadott, kezelt tanúsítványok értéke határozza meg. Ezek fizikai elkülönítését, a működést biztosító objektum védelmét biztosítani kell, úgy hogy csak a felhatalmazott személyek férhessenek hozzá.
−
A szigorú biztonsági szabályok teljes arzenálját ugyancsak érvénybe kell léptetni, beleértve a CA-nak helyet adó objektumok (helyiség, épület és berendezések) fizikai biztonságát, a személyi biztonsági intézkedéseket (ebbe értve a CA-hoz hozzáférő személyi állomány átfogó ellenőrzését és a különleges képzést), a folyamat kontrollt, hogy kikényszerítse olyan irányelvek végrehajtását, mint az összes szenzitív funkció kettős ellenőrzése. A biztonságos objektum tipikusan 7x24 órás alapon kell üzemeljen, és katasztrófa utáni teljes helyreállítást biztosító mentésekkel kell rendelkezzen.
Az együttműködés biztosítása Az architektúra az elemek összekapcsolhatóságát azok szabványos kivitelével biztosítja. Amint a fentiekben láttuk a PKI egyes elemei, de még inkább a piacon kapható PKI termékek különfélék. Egyértelmű, hogy ezek csak akkor képesek az együttműködésre, ha az egyes gyártók nemzetközileg elfogadott szabványokhoz alkalmazkodnak. A PKI azonban még nem rendelkezik mindenre kiterjedő szabványokkal. Nem mondható el, hogy az infrastruktúra a szó valódi értelmében is azt jelenti, amit elvárnánk, pedig a fejlesztés már hosszú utat megtett, kezdve az IETF 1993-ban kiadott RFC 1422-es PEM, (Privacy Enhanced Mail Specification) előírásaival, amelyek ITU-T X.509-es alapú PKI-t határoztak már meg. (Ettől eltérő utat követett az Interneten akkoriban nagy népszerűségnek örvendő PGP, melynek mára lassan csak az elnevezése a régi, de ugyancsak szabványossá érleli a piaci verseny). A PEM fejlődése kedvezően hatott az X.509 elterjedésére is. A PKI elterjedését, széleskörű használhatóságát azonban nem a szabványok határozzák meg, bár az előző példán is látszik, hogy kölcsönösen hatnak egymásra. A PKI és a PKI felhasználók szempontjából a kulcskérdések, melyek a szabványosítási törekvések megértését is segítik a tanúsítási hierarchiák, a tanúsítvány és kulcs menedzsment és a méretezhetőség. Az infrastruktúra fogalma azt sugallja, hogy a különböző PKI-k összekapcsolhatók, együtt tudnak működni. Ennek legfontosabb feltétele, hogy le tudjuk képezni a hitelesítési-bizalmi viszonyt (azaz ki kit és mire tanúsít) a szervezetek között és ezt hosszú távon fenntartsuk. Manapság három tanúsítás modell versenyez, a gyökér alapú hierarchiák (például a VeriSign, Microsoft, Netscape), a hálózati modell (például az Entrust) és a WEB-es megoldás (ilyen a PGP). Mindezek között a PKI működéséről jelentős felfogásbeli, elméleti különbség van, ami végső soron nem támogatja az együttműködést. Ezt csak adminisztratív intézkedésekkel, megfelelő átjárók majdani kialakításával lehet orvosolni, ha meghatározott üzleti érdekekből különböző modellek terjednek el, amelyek együttműködését mégiscsak biztosítani kell. Az ipar még nem érte el az együttműködés biztosításához elégséges szabványosítási szintet. A kérdés, mikorra várható reálisan a működőképesség elérése a PK alkalmazások egyre szélesebb körű használatával. Ma már az SSL/TLS és az S/MIME sok termékben alkalmazott, problémát 43
jelent azonban az átjárhatóság hiánya az egyes termékek között az új és alacsony szintű alkalmazások esetén, mint például a kód jelölés és a digitális aláírás formái. Ugyancsak aggasztó, de nehezebben megoldható, hogy a különböző nyelvet használó kódolások között nincs jelenleg olyan technikai mechanizmus, amely a nevek összehasonlítását támogatná. Ez különösen az ékezetes karakterek különféle kódolása miatt jelent gondot. Az ilyen problémákon lehet végeredményben lemérni a PKI technológiák érettségét. A különböző megoldások együttműködését a PKI alapú termékek széleskörű elterjesztése és a szabványosítási törekvések segíthetik. A szabványosítással történelmileg az a probléma, hogy a kereskedelmi termékek egyre túlhaladják a hosszadalmas bizottsági folyamatokat. Az ITU 2000. évi közgyűlése határozott lépéseket ígér a szabványosítás felgyorsítására. A PKI vonatkozásában az egyik szabványalkotó az IETF többféle munkacsoportot is működtet, de a szabványosítás tárgyát képező termékek már a piacon is vannak. Sem ezek, sem más termékek sikeres telepítése azonban nem a szabványokon, hanem a piaci környezeten múlik. A termékek egyszerűen alkalmazzák a tanúsítványok és CRL-ek kibocsátását és publikálását. Az Entrust például - a legrégebbi PKI termék fejlesztő, gyártó cég - az általa kidolgozott tanúsítvány visszaállítási és menedzsment protokollt javasolja, de az ipar még a szabványosítás szükségességében sem egyezett meg, nemhogy ezek elfogadásában. Tekintve azonban az RSA egyedülálló helyzetét, amit a kulcstalálmányok szerzői joga biztosít, a technológiai szabványok vonatkozásában az RSA meghatározó. Továbbra is szükség van nem egy-egy munkacsoport, hanem az IETF által meghatározott szabványokra, bár a PKI együttműködés ösztönzésében a PKIX sokat tett, de a piaci igények által meghatározott termékek milyenségét a szállítók fogják meghatározni. Az együttműködés elképzelhetetlen a protokollok szabványosítása nélkül. A protokollok határozzák meg, hogy az infrastruktúrát alkotó rendszerek és elemeik, illetve a különböző infrastruktúrák miként tudnak egymással kommunikálni. A biztonsági területen a szabványok nem elegendőek, sokkal inkább u.n. profilokat állítanak össze, amelyek a konkrét alkalmazási irányelvek függvényében technológiák szabványos kombinációi.
Alkalmazásprogramozási felületek, az API-k Az alkalmazásprogramozási felületek, azaz az API-k (Application Programming Interfaces) határozzák meg, hogy a rendszer alkalmazásai miként használják az egyes elemek közötti kommunikációt biztosító protokollokat a szolgáltatások teljesítéséhez. A PKI szolgáltatások eléréséhez a fejlesztők API-kat használnak, ha például egy alkalmazásnak szüksége van valaki nyilvános kulcsára, ismernie kell a tanúsítvány visszavonási információkat, vagy éppen tanúsítványt igényel. A szabványos API elvileg biztosítja a hordozhatóságot, azonban az Interneten igen ritkák az API szabványok. Az API-kat inkább az implementációs munka részének tekintik, hiszen az API-nak a működési környezetében, az operációs rendszerhez kötődve kell funkcionálnia. Ennek értelmében a kapcsolódási felületeket - interfészeket - az operációs rendszer, vagy környezet fejlesztője határozza meg a kulcsfontosságú szolgáltatásokhoz architektúrájában. Ilyen formában Microsoft Windows API-kat, vagy JavaSoft Java API-kat használunk. Igen valószínűtlen egy önmagában definiált API szabvány, legtöbb esetben azonban a piaci elterjedtség folytán az API-kat de facto szabványként kezelik, mivel az API-t valamely sikeres infrastruktúra termék határozza meg. Kivételként említhető a GSS-API (Generic Security Service Application Program Interface), ez azonban igen általános előírásokat tartalmaz, és semmiképp sem a biztonsági API szabványaként kezelik. Nincs általános Windows alkalmazás amely biztosítaná az összes szükséges eszközt. Az Európai Bizottság támogatásával Európában a biztonsági technológia számos interfészét meghatározó rendszert fejlesztettek ki SESAME
44
(Secure European System for Application in a Multi-Vendor Enviroment) elnevezéssel, de ez az USA-ban nem terjed el, hiszen sem a Microsoft, sem a Netscape nem támogatja. A szállítók API termékei közül meg kell említeni az Entrust CMS API-t (Certificate Management Services API). A PKI API-k területén azonban a Microsoft CryptoAPI-ja és az Intel CDSA (Common Data Security Architecture) a vezető. Mindkét gyártó termékei piaci részesedésük folytán széleskörű felhasználásra találnak. A CDSA-t nemcsak a PKI termékeket fejlesztők, hanem a PKIX, és bizonyos Open Group elképzelések is támogatták. A CryptoAPI A Microsoft CryptoAPI a MAPI (Messaging Application Programming Interface) és az OBDC (Open Database Connectivity) API-khoz hasonlóan az API hívások egységes készletét biztosítja a szolgáltatások absztrakciós rétegében. A kriptográfiai szolgáltató - a CPS (Cryptographic Services Provider) - a telepített alkalmazásnak megfelelő formában alkalmazhatja ezeket a hívásokat. A CPS-ek a szállító specifikus szolgáltatási alkalmazások driver-eihez hasonlók, amelyekhez az API biztosítja a hozáférést. A CryptoAPI a Microsoft Internet Information Server (IIS) és a Certificate Server része és főbb vonalakban a következő funkciókat tartalmazza: kontext menedzsment, kulcs tárolás, és csere, hashing, digitális aláírás, aláírás ellenőrzése és adatok titkosítása, tanúsítvány igénylés, a tanúsítványok tárolása, visszaállítása és ellenőrzése. A Microsoft CryptoAPI jól átgondolt koncepció szerint épül fel. A Microsoft Windows Open Services Architecture keretében a MAPI, OBDC és CryptoAPI a szolgáltatási architektúrában a biztonsági szolgáltatások terén alkalmazásfüggetlenséget biztosítanak. A CryptoAPI jelentős mértékben támogatja az X.509-et, a PKCS-s és PKIX-eket, lehetővé téve a biztonsági és azonosítási keretrendszereket. A Windows2000 Active Directory támogatással teljeskörű, bár mindenképpen Microsoft központú megoldás. A CDSA A CDSA a biztonsági szolgáltatások és az ezeket használó alkalmazások telepítéséhez általános architektúrát nyújt, így tartalmazza a PKI funkciókat is. Az Intel a CDSA fejlesztésekor kezdettől fogva a digitális tanúsítványokat vette figyelembe a résztvevők azonosításra a biztonságos kommunikációhoz és a tanúsítványokat használók tevékenységeit meghatározó irányelvek megállapításához. A CryptoAPI-hoz hasonlóan a CDSA szintén szintekre bontott szolgáltatási architektúra. Konzisztens alkalmazási felületet és szolgáltatási szinteket u.n. biztonsági modulokat határoz meg, amelyek a kérdéses szolgáltatások megvalósításához képezik le az interfészt. Ennek következtében a CDSA-hoz írt alkalmazások bármilyen rendszerben működhetnek, amelyekhez a fejlesztő biztonsági modult készít. Ezzel a fejlesztőnek jelentős függetlenséget biztosít. A CDSA magja a CSSM (Common Security Services Manager), amely a felső szintű API-t (a CSSM Security API-t) írja le, amelyet a PKI szolgáltatások elérésére használnak az alkalmazások és szolgáltatások. A CSSM API használatával például az alkalmazás kriptográfiai műveleteket végezhet, meghatározhatja a tanúsítványt használó hitelességét, hogy a különböző PKI szolgáltatásokat teljesíthesse. A CSSM mindezt négy alacsony szintű menedzserrel végzi el, amelyek bizonyos értelemben driver-eknek tekinthetők: −
A titkosító menedzser, a Cryptographic Services Manager irányítja a CPS-eket (Cryptographic Services Provider), amelyek végrehajtják a kriptográfiai műveleteket. Meghatározza a CryptoServices API-t ami az alapvető PKI szolgáltatásokat támogatja, a titkosítást, a digitális aláírást és üzenet kivonatot 45
(hashing). A CPS-ek biztosítják a biztonságos kulcstárolást, a privát kulcsok helyi tárolásához, és további válaszható műveletként bizonyos kulcs menedzselési funkciót is elláthatnak. A CPS önmagában egy szoftver, vagy egy hardver eszköz, vagy a kettő kombinációja lehet. −
A hitelesítő menedzser, a Trust Policy Services Manager irányítja a trust policy module-okat, melyek az alkalmazásokhoz szükséges irányelveket érvényesítik. Az irányelvek definiálása helyett a Trust Policy Services Manager egy infrastruktúrát biztosít, amelybe a fejlesztők installálhatják saját moduljaikat. Például egy bank beépítheti hitelkártya ellenőrző modulját. Az alkalmazások a hitelesítési műveleteket a CMMS API-kon át végezhetik.
−
A tanúsítvány menedzser, a Certificate Services Manager irányítja a helyi rendszeren a tanúsítvány könyvtárt (Cerificate Library). Az alkalmazások kezelhetik a tanúsítványokat és a visszavonási listákat, beleértve a tanúsítványok készítését, aláírását és ellenőrzését. Tekintve, hogy a tanúsítvány adatformája határozza meg a műveletet, ezért mindenegyes formátumhoz - a PKIX RFC-kre is speciális modulokat kell fejleszteni.
−
Az adattároló menedzser, a Data Store Services Manager egy API-t határoz meg a tanúsítványok, CRL-ek és más biztonsági objektumok biztonságos és tartós tárolására. Az API lehetővé teszi, hogy az alkalmazások kereshessék és szelektálhassák a tárolt adatokat. Az adattároló műveletek beépíthető adattár könyvtár modulokban telepíthető. Ilyenek lehetnek driver-ek vagy átjárók (gateway-k), vagy hagyományos teljes kiépítésű adatbázis-kezelő rendszerek. Az LDAP-ot hasonlóképpen egy modulon keresztül lehet elérni.
Sok fejlesztő a CryptoAPI és a CSSM API-nál magasabb szintű absztrakciót kíván. A legtöbb biztonsági probléma nem azért következik be, mert a hacker feltör egy kriptográfiai algoritmust, hanem, mert a programozók az algoritmusok szoftverbe illesztésekor hibákat követnek el. A magasabb szintű interfészekkel elkerülhetők lennének az ilyen problémák, és megóvnák a fejlesztőt, aki komplex biztonsági alrendszer használ. A szállító egy teljes biztonsági szolgáltatás implementálására fejleszthet, például a CDSA vagy a CryptoAPI feletti SET (Secure Electronic Transactions)-ra. Ekkor egy elektronikus kereskedelem alkalmazásban a CSSM API közvetlen meghívása helyett a SET szolgáltatáshoz fordul. A SET fogja használni az alatta lévő CDSA architektúrát, hogy biztosítsák a szükséges kriptográfiai szolgáltatást, mint a digitális aláírást, tanúsítvány lekérdezést. Ilyen megoldást tartalmaz az RSA PKCS#11 és számos Entrust kit.
Szabványosítási kérdések Az ISO Nemzetközi Szabványosítási Szervezet mellett, sokféle testület működik és még több de facto, illetve ipari szabványt használunk. Hagyományosan jelentős szabványosítási tevékenységet folyatat az ITU (a CCIR és a CCITT jogutódja) és az IEEE, valamint a különböző európai szabványosítási testületek is. Az ITU dokumentumokat ajánlásoknak nevezik. A PKI elterjedése az Internet nélkül elképzelhetetlen. Ezért a PKI működést meghatározó szabványoknak is célszerű illeszkedniük az Internet szabályaihoz. Sok vonatkozásban ezt az Internet közösség a szabványosítási tevékenysége biztosítja az RFC 2026ban meghatározott módon. Általánosságban az Internet szabvány egy olyan előírás, amely stabil, jól érthető és műszakilag helytálló, többféle, független és együttműködésre képes alkalmazása van, amelyeket megfelelő üzemeltetési tapasztalat támaszt alá, jelentős nyilvános támogatást élvez, és bizonyíthatóan hasznos az Internet egy bizonyos részében, vagy egészében. 46
Az Internet szabványosítási folyamat az Internet Society tevékenysége, melyet az Internet közösség - az Internet Engineering Task Force (IETF) - felhatalmazásával az Internet Architecture Board (IAB) és az Internet Engineering Steering Group (IESG) szervez és irányít. Azok az előírások, amelyek Internet szabványok lesznek, a "standards track" -ként ismert folyamat érettségi szintjein át fejlődnek ki. Ezek a szintek a szabvány javaslat ("Proposed Standard"), szabvány tervezet ("Draft Standard"), és a szabvány ("Standard"). Minden Internet szabvány célzatú előírást a vélemény kérés ("Request for Comments", RFC) dokumentum sorozat részeként közzétesznek. Fontos megjegyezni, hogy nem minden RFC "standards track" dokumentum, és nem minden "standards track" dokumentum éri el az Internet szabvány szintet. Azok az RFC, amelyek az IESG jóváhagyását követően szabvány szintre jutottak STD kiegészítő jelzést kapnak. Azonos módon, nem minden RFC, amely a pillanatnyi legjobb gyakorlatot ismerteti kerül megvizsgálásra és jóváhagyásra, hogy a legjobb gyakorlat példájaként elismerjék. A legtöbb manapság használt tanúsítvány alapja az ITU (International Telecommunications Union) X.509 ajánlása, az ISO/IEC 9594-8 szabvány. A tanúsítvány a személyről vagy egyedről (például szerverről) tartalmaz információkat és a nyilvános kulcsát, valamint a tanúsítványt kibocsátó CA választott adatait, azonban nem PKI Internet szabvány. A PKI termékeket és szolgáltatásokat használják számos hitelesítő és jogosító alkalmazásban, valamint a WEB-en elterjedt Secure Sockets Layer (SSL), Secure/Multimedia Internet Mail Extensions (S/MIME), Secure Electronic Transactions (SET), és mind a Java mind az ActiveX kódazonosító szolgáltatások specifikálják és használják a PKI-t. A Transport Layer Security szabvány szerint (TLS, az SSL-en alapuló IETF szabvány az erős azonosításra) a WEB böngészők és szerverek titkosított kommunikációs csatornáinak felépítésére használják a nyilvános kulcsú titkosítást és a tanúsítványokat. Az IPSec az IP alapú kommunikáció beépített, csomag szintű titkosítást használó megoldása a hálózati forgalom automatikus, transzparens titkosítására. Főként a hálózati útvonal-irányítók között használják, PKI alapon. Egy sor meglévő és a jövőben bevezetendő szabványt érdemes figyelembe venni. Ilyenek az RSA cég Public Key Cryptography Standards (PKCS) szabványai (19), amelyek sok lényeges PKI elemet definiálnak. Az Internet Engineering Task Force (IETF) égisze alatt, az 1995-ben alakult Public Key Infrastructure (X.509) working group - PKIX (X.509) - egy sor ajánlást (RFC-t) dolgozott ki a nyilvános kulcsú infrastruktúrák együttműködésének biztosítására (20). Nevezetesen az: − X.509 PKI tanúsítvány és CRL profilok alkalmazásáról az RFC 2459 (21), − X.509 PKI működési protokollokról, az LDAP-ról az RFC 2559 (22), − X.509 PKI tanúsítványmenedzselési protokollokról az RFC 2510 (23), és − X.509 PKI tanúsítvány irányelvekről és használati szabályokról az RFC 2527 (24), és elkészítették a tervezetet az időbélyegzésről is. Ugyanakkor számos más, régóta bevált biztonsági megoldás (pl. Kerberos alapú azonosítás) megmarad. A GSS-API szabvány és a Simple Public Key Mechanism (a GSS API plug-in, melyet az RFC 2025 definiál) biztosítja a Kerberos és a PKI rendszerek együttműködését az egyszeri bejelentkezésre. Tervezeteik első változatai az eredeti URL-eken (25. 26, 27, 28) már nem elérhetők, mivel az előzőkben hivatkozott RFC-ként jelentek meg. A WEB lapot (www.ietf.org/1id-abstracts.html) érdemes figyelemmel kísérni a szabványosítási munkák pillanatnyi állásáról. Amint az irodalomjegyzékből látható az RFC-k is változnak, illetve újabb tervezeteik jelennek meg. A munkacsoport legjobb úton van az RFC-k alapján a végleges szabványosítás felé.
47
Egy másik, az együttműködést intenzíven támogató társaság az IETF S/MIME munkacsoport. A legfontosabb szabvány ajánlásaik a kódolt üzenetek szintaxisára (RFC 2633), a tanúsítványok kezelésére (RFC 2312) vonatkozik (29) A NIST, az USA Szabványosítási Intézete is felkarolta a PKI együttműködés biztosításának ügyét, de a legkorábbi, 1990-es alapokat az RSA Laboratories PKCS (Public Key Cryptography Standards) de facto szabványai (18) jelentik, melyek jól érthető keretet biztosítanak az együttműködés megteremtésére. Az IETF munkacsoportok is ezek alapján indultak el. A PKI termékeket és szolgáltatásokat használják számos hitelesítő és jogosító alkalmazásban, valamint a WEB-en elterjedt Secure Sockets Layer (SSL), Secure/Multimedia Internet Mail Extensions (S/MIME), Secure Electronic Transactions (SET), és mind a Java mind az ActiveX kódazonosító szolgáltatások specifikálják és használják a PKI-t. A Transport Layer Security szabvány szerint (TLS, az SSL-en alapuló IETF szabvány az erős azonosításra) a WEB böngészők és szerverek titkosított kommunikációs csatornáinak felépítésére használják a nyilvános kulcsú titkosítást és a tanúsítványokat. A PKI együttműködést biztosító protokollok a szolgáltatási környezet függvényében a következők. 1. Szervezeti környezet A szervezet által meghatározott környezetben a végfelhasználói alkalmazásokig bezárólag konzisztens és átlátható biztonságot kell teremteni. Ebben a környezetben a szervezet a legnagyobb mértékű ellenőrzési jogokkal és lehetőségekkel rendelkezik, amely biztosítja, hogy mind az infrastrukturális, mind a végfelhasználói alkalmazások beruházásainál érvényre juttassák az együttműködő PKI megoldások elterjesztését. Az alkalmazandó protokollok például: − Tanúsítványgenerálás - X.509, PKIX RFC 2459 Az X.509 meghatározza a nyilvános kulcsú digitális tanúsítvány és a tanúsítvány visszavonási lista (CRL) formáját. A PKIX Part1 mindkét szabványra vonatkozó profilokat biztosít. − Tanúsítványterjesztés - RFC 2559, a Lightweight Directory Access Protocol (LDAP). Az LDAP meghatározza a digitális tanúsítványok és a CRL-ek adattárból történő publikálásának, illetve hozzáférhetőségük protokollját. − Tanúsítványmenedzsment - RFC 2510 a PKIX Cerificate Management Protocol (PKIX-CMP). A PKIX-CMP meghatározza a kulcsok és tanúsítványok menedzselésének tanúsítvány protokollját. Az egyszerű tanúsítvány igényléseken túl a szervezeti infrastruktúrában megkövetelt PKI életciklus funkciókra is kiterjed. 2. Szervezetek közötti környezet A szervezetek közötti környezetet azok a szervezetek közötti kapcsolatok jellemzik, amelyekkel ezek biztosítják a szervezetek közötti u.n. B2B elektronikus kereskedelemhez szükséges hiteles és biztonságos infrastruktúrát. Minden szervezet a saját erőforrásai felett rendelkezik, mind az infrastruktúra, mind a a végfelhasználói alkalmazások együtt kell működjenek más PKI-kkal. − Tanúsítványgenerálás - X.509, PKIX RFC 2459 Ezek a szabványok a kereszttanúsítványokra és CLR-ekre is vonatkoznak, amelyek a szerveztek közötti kölcsönös, illetve hierarchikus tanúsításhoz használatosak.
48
− Tanúsítványterjesztés - RFC 2559 LDAP, RFC 2312 S/MIME Az LDAP biztosítja a hozzáférési protokollt azon szervezetek számára, amelyek meg akarják osztani teljesen vagy részlegesen a tanúsítvány adattáraikat. Az S/MIME protokoll meghatározza a digitális tanúsítványok végfelhasználók közötti közvetlen cseréjét. − Tanúsítványmenedzsment - RFC 2510 PKIX-CMP, PKCS #7/#10 A PKIX-CMP a kereszttanúsítvány, valamint a szervezeti környezet modelljéhez hasonlóan a kulcs és tanúsítvány lekérdezések, és menedzsment protokollját biztosítja. A PKCS #7/#10 az egyszer, minden menedzsment nélkül létrehozott és elosztott kulcsok, tanúsítványok és kereszttanúsítványok lekérdezésének és vételének protokollja. 3. A fogyasztói környezet A fogyasztói környezetet azok a szervezetek alakítják, amelyek fogyasztóikkal Internetes elektronikus kereskedelmet - B2C - kívánnak kialakítani. Az infrastruktúra irányítása során a szervezetnek együtt kell működnie fogyasztóival az alkalmazások széles körét - jellemzően WEB böngészőket és elektronikus levelezést - használva. − Tanúsítványgenerálás - X.509 v3 (2001. januárban!) új IETF PKIX tervezet az RFC 2459 módosításra Ezek a szabvány tervezetek biztosítják a nyilvános kulcsú digitális tanúsítvány profilt. Erre a környezetre nincs elfogadott szabvány tervezet a visszavonás ellenőrzésére. A javasolt szabvány (ex. OCSP) egyeztetés alatt. − Tanúsítványterjesztés - RFC 2312 S/MIME A tanúsítványok szétosztása ebben a környezetben az S/MIME-os közvtelen felhasználó-felhasználó kapcsolatra korlátozódik. − Tanúsítványmenedzsment - PKCS #7/#10 A PKCS #7/#10 támogatja tanúsítványok lekérdezését és vételét, de nem nyújt semmiféle kulcs vagy tanúsítvány menedzsmentet. Ebben a környezetben nincs elfogadott szabvány a kulcs és tanúsítvány menedzsmentre. Az RFC 2510bis-03 módosítás (2001 február! ex. PKIX-CMP) egyeztetés alatt van. Az ITU-T X.509 3. változat szerinti tanúsítványok A legtöbb manapság használt tanúsítvány alapja az ITU (International Telecommunications Union) X.509 ajánlása, illetve az ISO/IEC 9594-8 szabványa. A tanúsítvány a személyről vagy egyedről (például szerverről) tartalmaz információkat és a nyilvános kulcsát, valamint a tanúsítványt kibocsátó CA választott adatait. Az alap információ tartalmazza az egyed nevét, nyilvános kulcsát, a nyilvános kulcs algoritmusát, és egy válaszható egyedi azonosítót. Az X.509 ver 3. szabványos kiterjesztése további információkat is tartalmaz a kulcsazonosítóra, a kulcs használatára, a tanúsítási irányelvekre, más elnevezésekre és attribútumokra, a tanúsítási útvonal megkötéseire és lehetőségeire a visszavonás esetén, beleértve a visszavonás okait és a CA frissítésekor a CRL partícionálását. Internet Engineering Task Force, IETF hozzájárulása a szabványosításhoz Az IETF különböző munkacsoportjai tevékenykednek az együttműködésre képes PKI megvalósításán Internet szabványokat, RFC-ket (Request for Comments) kidolgozva Meg kell említeni az IETF Public Key Infrastructure (PKI X.509, PKIX), SPKI és az S/MIME munkacsoportokat, amelyek a PKI együttműködést támogató Internet szabványajánlásokat 49
fejlesztik. Korábbi, 1993-ban készült az RFC 1422 az első X.509-es alapú Internet szabvány a PEM (Privacy Enhanced Mail) a nyilvános kulcsokkal védett elektronikus levelezés megvalósítására. A PKIX munkacsoportot 1995 őszén hozták létre az X.509 alapú PKI-t támogató Internet szabványok fejlesztésére. Az IESG (Internet Engineering Steering Group) számos tájékoztató és szabványosítási célú dokumentumot hagyott jóvá, melyeket a munkacsoport az eredeti cél teljesítésére készített. Az első a szabványok közül az RFC 2459, az X.509 3. változatának megfelelő tanúsítvány és a 2. változatnak megfelelő CRL profilok Interneten történő használatra. Jóváhagyásra került Certificate Management Protocol (CMP) (RFC 2510) tanúsítványmenedzselési protokoll, az on-line tanúsítvány állapot protokoll (Online Certificate Status Protocol, OCSP) (RFC 2560), és a tanúsítványmenedzsment igénylő formátum (Certificate Management Request Format, CRMF) (RFC 2511). Hasonlóképpen a tanúsítvány és a CRL tárolásra az LDAP 2. változata (RFC 2587), és PKI műveletekben az FTP és HTTP átvitel használatára az RFC 2585. A tanúsítvány irányelvekről és gyakorlatról egy tájékoztató jellegű dokumentum az RFC 2527 készült. Az IESG jóváhagyta a KEA használatáról az informatív jellegű RFC 2528-at, és várhatóan ugyanígy lesz az ECDSA-val. A munkát 2001ben is folytatják egy másik tanúsítvány menedzsment protokoll (CMC) előkészítésével, amely szorosan kapcsolódik a PKCS dokumentumokhoz és az S/MIME-hoz fejlesztett kriptográfiai üzenet szintaxishoz (CMS). A 2001. február 10-ei állapot szerint a továbbiakban újabb szabványokon munkálkodik a csoport vagy a PKI menedzsmenthez integránsan kapcsolódó, vagy a PKI-hoz egyébként szoros viszonyban lévő protokollokat dolgozva ki. Ezen kívül van tennivaló a tanúsítvány név formátum konvenciókon és a "minősített tanúsítványok" kiterjesztéseinek használatán a letagadhatatlansággal kapcsolatos jogi vonatkozású alkalmazásokban. Végül folyamatban vannak a munkák az időpecsét és adat tanúsítási protokollokon. Ezeket a protokollokat elsősorban a tanúsítványok és CRL-ek alkalmazásával a letagadhatatlanság támogatására tervezik. Ezek szorosan kapcsolódnak a PKI-hoz, ezért a PKIX munkacsoport égisze alatt folyik a munka. A munkacsoport továbbá javasolja egy új RFC készítését, amely egy X.509-es attribútum tanúsítvány profilt határoz meg, esetleg kiterjesztve a meglévő tanúsítványmenedzselési szabványokat, hogy illeszkedjenek az attribútum tanúsítványok és a nyilvános kulcsú tanúsítványok közötti különbségekhez. Az X.509 Internetes megvalósítását segítő szabványajánlás csoport első tagja 1999 szeptemberéből az RFC 2459, amely az X.509 version 3 " Internet honosításának" tekinthető. Ezt részletesebben is ismertetjük az alábbiakban. A PKIX RFC 2459 X.509 Certificate and CRL Profile A PKIX RFC 2459 X.509 Certificate and CRL Profile az X.509 Internet PKI-ban használható elemeit határozza meg, lényegében adaptálja az X.509-et az Internetre, de felhasználja az X.509 3. verzió tanúsítványait és a 2. verzió visszavonási listáit. A profilok tartalmazzák a kiterjesztéseket is. A RFC 2459 meghatározza a tanúsítási és ellenőrzési folyamatokat és a nyilvános kulcsú anyagok titkosítást és a digitális aláírásokat is. Az alkalmazások és szolgáltatások által használt algoritmusok meghatározásával támogatja az együttműködő, közös titkosítási technológiák kialakítását. Fő fejezetei a következők: A tanúsítványban használt könyvtár nevek
50
A könyvtár nevek kódolásának a tanúsítványban háromféle változata lehetséges a PrintableSting, BMPString és a Unicode Transformation Format 8 (UTF-8) TeletexString kódolás, amely ugyancsak megengedett akkor, ha a felhasználói szoftver nem RFC kompatibilis. Minden kódolási típus más karakterkészletet támogat, de a nevekben használt karakterek határozzák meg, melyik kódolást kell alkalmazni. A PrintableString kódolás a default. Ez ASCII karaktereket használ, azaz az angol abc kis és nagybetűit, számokat és a meghatározott írásjeleket. Amennyiben a Printable String nem elegendő a nevek leírására a BMPStringet alkalmazzák. A BMPString Unicode karakter készlet, azaz két byte-ot használ minden karakter leírására, amely 65536 kombinációt biztosít. Egy sor PKI alkalmazás nem támogatja az Unicode tanúsítványokat, bár sokaknak szándékában áll a jövőben. Tanúsítvány kiterjesztések Az RFC 2459 sokféle kiterjesztése választható, de nem kötelező. A kierjesztéseknek további változatai is lehetnek, így ez az együttműködés szempontjából nehézséget jelent. A CA hierarchia különböző szintjeinek megfelelően más és más kiterjesztések lehetnek. Például alapvető megkötések, a kulcs használat, alanyi kulcs azonosító, CRL elosztási pont, (CRL Distribution Point, CDP), tanúsítvány séma, CA verzió, a hatósági kulcs azonosítója, hatósági információ hozzáférés (Authority Information Access, AIA), a kulcstulajdonos alias, vagy más neve. A nemzetközi karakterkészletek és a DNS nevek Az IETF előírta, hogy minden új RFC kötelezően alkalmazza a nemzetközi karakterkészletek használhatóságát jelentő UTF-8-as kódolást. Az ajánlások szerint 2003-ig minden PKI szabványnak támogatnia kell az UTF-8-at, ez azonban egy folyamat, amelyben nem egyformán fejlett minden alkalmazás. A tanúsítványok esetén ez a Domain Name System-ből leszármaztatott CRL és CA elosztó szerverek megnevezése miatt lehet lényeges. Jelenleg a DNS-ekben nem alkalmazzák a nemzetközi karakterkészletet, ezért ez a tanúsítványok ilyen bejegyzésein sem célszerű. A Simple PKI (SPKI) munkacsoport Az IETF másik munkacsoportja a Simple PKI (SPKI), egyszerű, a hitelkártyák használatához hasonló tanúsítványformátumot dolgozott ki. Elveti a hierarchikus tanúsítást, az összes tevékenységet ad hoc módon javasolja megoldani. Átvették Ronald Rivest (az RSA-ból az "R") Simple Distributed Security Infrastructure (SDSI) modelljét is. Tekintve, hogy a PKIX munkacsoport eredményei jelentősek, nem valószínű az SPKI térnyerése. A PKCS, Public Key Cryptography Standards Ezt a jelenleg tizenöt szabványt tartalmazó családot RSA Laboratories fejlesztette ki együttműködve az Apple, Digital, Lotus, Microsoft, MIT, Northern Telecom, Novell, és Sun cégekkel. A PKCS-ek a nyilvános kulcsú titkosítás egy sor adatstruktúrájának szintaxisát írják elő, a leglényegesebbek a következőkre vonatkoznak: Egy üzenet digitális aláírása. Miként kell elektronikusan aláírni az üzenetet úgy, hogy mások meg tudjanak győződni arról, ki írta alá, és az üzent az aláírás óta nem változotte. Az üzenet titkosítása. Miként kell az üzenetet titkosítani, az üzenet címzettjével történő minden előzetes adatcsere nélkül, úgy, hogy a címzetten kívül senki más ne tudja visszafejteni azt.
51
Tanúsítvány kibocsátás ellenőrzése. Meg kell győződni, hogy a tanúsítványigénylő rendelkezik-e titkos kulccsal. Miként kell ehhez tanúsítványt igényelni egy CA-tól úgy, hogy a nyilvános kulcsot tartalmazó, és a nyilvános kulccsal aláírt igénylés alapján a CA leellenőrizhesse az üzenetet, meggyőződhessen arról, hogy az igénylő birtokában van privát kulcs. Ezeket az alábbi PKCS-ek valósítják meg: PKCS #1. A PKCS #1 leírja, hogy az RSA nyilvános kulcsú algoritmusban miként állíthatók elő az elektronikus aláírások a hash algoritmus felhasználásával. Ismerteti továbbá a kulcs cseréhez szükséges szimmetrikus kulcs titkosítási eljárást az RSA algoritmussal. Ez a szabvány a PKCS #7-el együtt meghatározza az aláírt üzenetek készítésnek módját. A PKCS #1 leírja az RSA privát és nyilvános kulcsok megjelenítési formáját is. A PKCS #1-et tartalmazza az RFC 2313. PKCS #7. A PKCS #7 leírja, hogy az elektronikus aláírások és a titkosítás miként alkalmazható bármely adatblokkra. Leírja ugyancsak, miként lehet az adatokhoz az üzenetbe beillesztve más attribútumokat, mint például az aláírás idejét csatolni, és megvédeni ugyanazzal az aláírással. A PKCS #7 speciális formája a torzított (degenerált) üzenet, amelyet a tanúsítványok és CRL-ek továbbítására használnak. A szabvány meghatározza, miként lehet adatot titkosítani szimmetrikus algoritmus használatával (például egy tartalomtitkosító algoritmus), és a szimmetrikus kulcsot titkosítani egy RSA nyilvános kulcsú algoritmus (például egy kulcs csere algoritmus) segítségével. A PKCS #7 1.5-ös verziója a PEM modell kulcs menedzsment eljárását követte, amelyben a kulcsot a kibocsátó és a sorozatszám azonosította. Az 1.6-os verzió elsőként támogatja a SET-et. A 2.0-ás verzió az alkalmazások számára a kulcsazonosítást az alany neve alapján teszi lehetővé. PKCS #10. A PKCS #10 leírja, miként kell felépíteni egy tanúsítványigénylési üzenetet. A tanúsítványigénylés tartalmaz egy nyilvános kulcsot és egy sor választható attribútumot, mint például a kérelmező megkülönböztetett nevét (DN), vagy az elektronikus levelezési címét. A kérelmet tartalmazó egész üzenetet az üzenetben lévő nyilvános kulcshoz tartozó privát, titkos kulccsal kell aláírni. A CA által jóváhagyott kérelmekre visszaküld vagy egy egyszerű X.509-es tanúsítványt, vagy megküldi a tanúsítványt a gyökér tanúsító hatósághoz mutató kapcsolati láncon (PKCS #7 degenerált üzenet formájában). PKI Task Group Az X/Open és az Open Software Foundation kombinálásával alakított szabványosítási testület az Open Group hozta létre a Public Key Infrastructure Task Group-ot, amely egy sor követelményt határozott meg az együttműködő PKI-kre A PKI szabványok alkalmazásonként. Elektronikus aláírások PKCS#7 Elektronikus aláírások a PKI alapelemei. A CA-k a nyílt kulcs tulajdonos jogosultságának tanúsítására aláírják a tanúsítványt. Az alkalmazások ezt követően az adott nyílt kulcsot fogják használni. Az együttműködő aláírási technológiákhoz szükséges az RSA féle PKCS#7, mint az elektronikus aláírások alapja. A legtöbb szállító ezt alkalmazza, az USA Szövetségi Kormány megpróbál bevezetni egy külön digitális aláírási szabványt, a DSA-t (Digital Signature Algorithm). A DSA a DSS-hez (Digital Signature Standard) kapcsolódik, amely a PKCS#7 versenytársa. Egyelőre az RSA ellenáll.
52
A titkosítás és a digitális aláírások elterjedése nem mondható általánosnak, de ahol vannak, ott az RSA PKCS-ek de facto szabványok, melyeket a cég menedzsel és nem adta át az Internet közösségnek, mint RFC-ket, legalábbis amíg a szabadalom védettsége fennáll (kivétel a PKCS #1). Az USA Kormány azonban megköveteli a DSA használatát a hivatalaiban. Tanúsítvány és CRL formátumok, RFC 2459. Alapkövetelmény a szabványos formátum, hogy a sokféle szállító különböző alkalmazásai használni tudják. Az X.509 szabványos formátumot biztosít, azonban ez nem Internet, hanem az ITU-T szabványa. Az X.509 széles keret ad, amely speciális részegységei támogathatják a kívánt együttműködő képességet. Az IETF PKIX munkacsoport RFC 2459, meghatározza az X.509 tanúsítványok és CLR-ek alkalmazását az Internet PKI architektúrában. Tanúsítvány profil. A PKIX RFC 2459 meghatározza az X.509 alapú tanúsítványokat az elektronikus levelezésre, az IPSEC-re és a WEB alapú alkalmazásokra az X.509 3. verzió alapján. Tanúsítvány kiterjesztési profil. Sokféle attribútumot határoz meg, amelyek az ITU-T X.509 mellékletében szerepeltek: felhasználók, nyilvános kulcsok, a tanúsítási hierarchia és a CRL terjesztés menedzselése. A PKI a kiterjesztéseket kritikusként, illetve nem kritikusként jelölni tudja. Ez utóbbiak csak tájékoztató jellegűek, míg a kritikusokat fel kell használni a jogosultság ellenőrzési folyamatban. A RFC 2459. szerint a kiterjesztések az információk szabványos helyei. CRL és CRL kiterjesztés profil. A PKIX RFC 2459 csak ajánlja, de nem írja elő kötelezően a tanúsítvány visszavonási listák (CRL) kibocsátását. A lista formáját az X.509 2. verziója határozta meg. Az együttműködés segítésére a PKIX RFC 2459 a CRL-ekre meghatározza a profilt, amely az alapvető információ készletet tartalmazza, továbbá definiálja a gyakran használt attribútumok helyét a CRL-ben, és ezek általános megjelenési formáját. Lényeges a terjesztési pontok meghatározása is. Tanúsítási útvonal ellenőrzés. A tanúsítványok érvényességének ellenőrzése és a hitelesítők megtalálása lényeges elem az együttműködő PKI-ban. Valószínűleg az alkalmazások és a felhasználók is ellenőrizni akarják a tanúsítvány érvényességét, sőt mind a cégek szabályai, mind állami jogszabályok előírhatják mielőtt elfogadnák az elektronikus aláírást lényeges okiratokon, vagy megrendeléseken. A tanúsítvány ilyen fajta ellenőrzését a tanúsítási útvonal ellenőrzéseként ismerik. Ez egy olyan folyamat, amelyet az alkalmazásoknak és rendszereknek támogatniuk kell. Lényegében a tanúsítási útvonal ellenőrzési folyamat ellenőrzi a kapcsolatot a tanúsítvány tulajdonosa - az alanya - és az alany nyilvános kulcsa között, ami a tanúsítványban van. A folyamatban az alkalmazás, vagy más tanúsítványhasználó a CA nyilvános kulcsával leellenőrzi a CA aláírását. Leellenőrizheti, hogy a tanúsítvány nem járt-e le, nem vonták-e vissza. Ha a tanúsító hatóság korlátozta a használati kört (pl. csak levelek aláírására használható), leellenőrizheti, hogy a kívánt célra alkalmazható-e. Ha bármelyik ellenőrzés negatív, a tanúsítvány nem érvényes. Algoritmus támogatás. A PKIX RFC 2459 végül meghatározza azon alkalmazások kriptográfiai algoritmusait, melyeket a CA-k és más tanúsítvány használó rendszerek alkalmazhatnak. Pontosabban a javaslat egy egyirányú hash függvényt (message digest, azaz üzenet kivonatot) definiál és digitális aláírás algoritmusokat, hogy a CA használhassa a tanúsítványok és a CRL-ek aláírására. A javaslat minden algoritmus számára egységes azonosítókat is meghatároz. Így a CA és az alkalmazások ezekkel az azonosítókkal jelezhetik az együttműködési kapcsolat 53
során, melyik algoritmust, melyik speciális funkcióhoz használják. A javaslat nem teszi kötelezővé az algoritmusok használatát, hanem előírja az algoritmus azonosítók alkalmazásának támogatását, mint az együttműködés lényeges követelményét. A javaslat szerint az USA Szövetségi Kormány által definiált SHA-1 ajánlott egyirányú hash függvényként az Internet PKI-ra. Az SHA-1-re azért esett a választás, mert a PEMben használt RSA definiálta MD2 (RFC 1319) egyirányú hash függvényben megrendült a bizalom bizonyos mértékig. Bár 1995- ben nem tudták feltörni, de a támadás módja azt mutatta, hogy közel kerültek hozzá. Így az MD2 használatát csak visszamenőlegesen, nem pedig új alkalmazásokra javasolták, de azóta már sok termékben az MD4 és MD5 (RFC 1321) is polgárjogot nyert. A PKIX RFC 2459 kétféle digitális aláírás algoritmust tárgyal. Az első algoritmust a tanúsító hatóság használja a tanúsítvány aláírásra. A javaslat szerint a támogató CA-k bármilyen digitális aláírási algoritmust használhatnak a tanúsítvány aláírásra, bár a legvalószínűbb választás az RSA és a DSA. Nyilvánvalóan az RSA az elterjedt azonban az IETF munkacsoport nem kívánt szembe kerülni az USA Kormány DSA terveivel sem. Ezek után a felhasználó rendszernek kell eldöntenie mit használ a tanúsítvány keretében. A másik típusú kriptográfiai algoritmus a javaslat szerint az, amelyikbe a tanúsítványban lévő nyilvános kulcs be van téve. A javaslat ebben az esetben sem határoz meg konkrét algoritmust, a tanúsítványon bármilyen nyilvános kulcsú algoritmus használható. A pontos meghatározás helyett algoritmus azonosítókat határoz meg az RSA, Diffie-Hellman Key Exchange, DSA és a Key Exchange Algorithm-re egyenként. A CA-knak tehát ebben az esetben is az azonosítókat kell használniuk a tanúsítványokon, így az algoritmus felismerhető az összesre felkészített olvasón. Szabványosítási kilátások PKIX RFC 2459 az összes IETF munkacsoport RFC-ből a legérettebb, bár 2001 januárjában újabb módosító tervezet jelent meg. A szállítók egyetértenek és alkalmazzák az X.509 tanúsítvány és CRL formátumokat az Internetes PKI termékekben. Már a korábbi változatnál nézetletérés volt például a kiterjesztések számát és típusát illetően. Nem volt eleinte egyetértés a tanúsítvány, a tárolt adatok és a terjesztésre hivatott címtárak viszonyát illetően sem. A szenzitív információk tárolása vitára ad okot. Például a nyugdíj és egyéb szociális juttatásokhoz szükséges a kártya felhasználó társadalombiztosítási száma. Kérdés, hogy egy nyilvánosan elérhető tanúsítványon, már pedig a tanúsítványok ilyenek, lehetnek-e ilyen információk. Az adatok a tanúsítványon és a CRL-en hosszú időn át hozzáférhetőek. Úgy tűnik tehát, nem éppen bölcs dolog a tanúsítványon ilyen adatokat közzétenni. Amennyiben a tanúsítványon szenzitív adatok vannak, akkor azt a felhasználónak védenie kell. További kulcsok biztosíthatják ezt a védelmet, azonban ezek további tanúsítványokat igényelnek. Ha a tanúsítvány olvasásához további tanúsítványok szükségesek a PKI reménytelenül bonyolulttá válik. A szállítóknak számos ötlete van a probléma megoldására, például a tanúsítványon csak egy mutató legyen, amely egy védett címtárhoz vezet, amelyhez csak a jogosultak férhetnek hozzá. Másrészt sokan javasolták, hogy meg kell változtatni a PKI tanúsítványok tárolásának módját a címtárakban. Az X.509 a tanúsítványon attribútumokat és kiterjesztéseket definiál. Ha a címtár a tanúsítványt a felhasználó, mint objektum attribútumaként tárolja a szenzitív információk olvasásához az alkalmazásnak meg kell találnia a felhasználó belépési pontját a címtárban és lekérdezni a tanúsítványt, csak ezután olvashatja. A Novell és mások a tanúsítványt javasolták objektumként tárolni, saját attribútumaival együtt. Sokan elutasították ezeket a javaslatokat, mivel szerintük a címtár hitelességét túlhangsúlyozzák. Sok kriptográfiai szakértő véleménye szerint csak a tanúsítvány 54
legyen hiteles és a tanúsítvány és a nyilvános kulcs kapcsolatát a CA hitelesítse. Lényeg tehát, hogy a PKIX RFC 2459 szabványosítása ellenére sok munka van még hátra, de az eddigi eredmények a vásárló szempontjából már fontos mérföldkőnek tekinthetők. Tanúsítvány visszaállítási protokollok, RFC 2559. Az X.509-es tanúsítványt használó végrendszereknek szükségük van a tanúsítványra, a CRL-re és más információkra. Ezeket a CA által fenntartott adattárból tudják megszerezni. A PKIX munkacsoport a visszavonási információk on-line elérésére módszert dolgozott ki, amelyhez azonban jól meghatározott kommunikációs protokoll is szükséges. Ezt tartalmazza a PKIX RFC 2559. Tanúsítvány és CRL visszaállítás. A név/címtár szolgáltatásokat általánosságban a tanúsítványok és CRL-ek legjobb adattáraiknak tekintik, ezért az LDAP természeténél fogva a tanúsítvány és CRL visszaállítás ideális mechanizmusát jelenti. A PKIX RFC 2559 egy profilt határoz meg az LDAP használatára az adattárból a tanúsítvány és CRL visszaállításhoz. A PKIX RFC 2559 kétféle helyzetet definiál. Az egyikben a kérdező felhasználó ismeri a tanúsítvány vagy CRL nevét, amelyre szüksége van (ez az u.n. "repository read"), a másikban a tanúsítvány vagy CRL attribútumai alapján kell keresni (ez az u.n. "repository search"). Mindkét művelet az LDAP v2 készletén alapul. A bevezetés elleni egyik vélemény szerint nem elegendő az LDAP v2 biztonsága, mivel a legáltalánosabban alkalmazott azonosítási eljárása az egyszerű azonosítás, melyben az ügyfél és a szerver nyíltan nevet és jelszavat cserél. A címtár alapszolgáltatásainál, mivel ezek nyíltak nincsenek szigorú biztonsági követelmények. A nyilvános kulcsú titkosítás szépsége éppen abban van. hogy széles körben hozzáférhetővé teszi a bizalmas, hiteles információkat és ehhez az emberek és rendszerek nyilvános kulcsaikat nem hiteles környezetben tárolhatják, csupán a kulcs pár privát felét kell szigorúan őrizniük. A CRL érvényességéről a CA titkos kulcsával készített aláírásának a nyilvános kulcsával történő ellenőrzésével győződhet meg a felhasználó. A CA-CA kapcsolat azonban sok esetben szigorú azonosítást követel meg. A címtár szolgáltatások elterjedése nem általános, ezért a PKIX RFC 2559 javasolja az FTP használatát is. A fájl nevek végződéseire a .cer illetve a .crl jön szóba. Online Certificate Protocol, Szenzitív alkalmazások (pl. nagy összegű pénz átutalások esetén) szükséges lehet az on-line tanúsítvány ellenőrzés. Erre dolgozták ki az OCSP-t (RFC 2560). Tanúsítványmenedzselési protokollok, PKCS#10, RFC 2510 A tanúsítvány és CRL visszaállításon túlmenően a PKI elemeknek kommunikálniuk kell egymással az alapvető menedzselési funkciók ellátására. Például az alkalmazások, emberek tanúsítványokat kérnek a CA-tól, valamint a CA-k egymást tanúsíthatják, amely kereszttanúsítás ugyancsak meghatározott adatcserét jelent. Ezen a területen két fontos szabványosítási törekvés ismert. Az RSA PKCS#10 a CA-tól a tanúsítvány lekérdezés alapszintaxisát biztosítja. Ugyanakkor a PKIX munkacsoport az RFC 2510-ben a szabványos üzenetformátum készletet határozott meg egy sor menedzsment funkció támogatására, valamint az üzenetek transzponálására a különböző protokollok között. PKCS#10. A PKCS#10 nem protokollt határoz meg, hanem a tanúsítvány kérés szintaxisát írja le, az üzenet formátumát definiálva. A tanúsítvány megszerzése céljából a felhasználó elküldi a CA-nak elektronikus levélben nyilvános kulcsát megkülönböztetett nevével 55
együtt (amely remélhetőleg egy LDAP címtárban szereplő név). A tanúsítványt igénylő felhasználó más attribútumait is csatolhatja a kérelemhez. Például postai címét, amelyre a hitelesített tanúsítványt visszaküldhetik, ha nem elérhető elektronikus postafiókja. Választhatnak egy u.n. "challenge password" ellenőrző jelszavat, amelyet később a tanúsítvány esetleges visszavonási kérelmekor használnak fel, További attribútumok az RFC 245-ban felsoroltakból adhatók meg. Az igénylő felhasználó kérvényét saját privát kulcsával írja alá, így lehetősége van a CA-nak leellenőrizni, hogy az igénylés kérvénybe csatolt nyilvános kulcs tulajdonosától származik. A CA ezek után elkészíti a tanúsítványt aláírva azt saját privát kulcsával miután hozzákapcsolta a tanúsítványhoz a kérvényező felhasználó nyilvános kulcsát, majd visszaküldi a kérelmező felhasználónak. PKIX RFC 2510. Az RFC 2510 a következő üzenet formátumokat és protokoll implementációkat definiálja: Regisztráció: ez egy folyamat, amelyben a felhasználó bemutatkozik a CA-nak, egy tanúsítvány megkapása céljából regisztrálva magát. Inicializálás: Ahhoz, hogy az ügyfél részt vehessen egy PKI-ban, a biztonságos működéséhez meg kell kapnia a szükséges kulcsokat. Például szüksége van egy CA nyilvános kulcsára, hogy érvényesíthesse a tanúsítási útvonalakat. Ezen túlmenően szüksége van általában saját kulcs párjára. Tanúsítás: A CA-nak egy meghatározott folyamat szerint a felhasználó nyilvános kulcsa számára ki kell bocsátania egy tanúsítványt és ezt a tanúsítványt vissza kell küldenie a felhasználó kliens rendszerére, vagy el kell helyeznie a tanúsítványt egy adattárban. Kulcs pár visszaállítás: A CA-k, vagy a kulcs másolat tároló rendszerek választás szerint a felhasználó privát kulcsának tárolhatják a biztonsági másolatát, őrizhetik vagy archiválhatják. Amennyiben egy alkalmazás a kulcspárt például titkosításra használja, a szervezet ragaszkodhat a kulcs másolatának tárolásához, hogy a felhasználó nyilvános kulcsával titkosított adatok hozzáférhetők legyenek, ha a felhasználó elveszítené privát kulcsát. Ha a felhasználó kulcsa visszaállítását kéri (ha elfelejtette például a kulcsot védő jelszavat), a CA-nak szüksége lehet egy on-line protokoll csere támogatására. Kulcs pár frissítés: A CA.nak rendszeresen frissítenie kell minden kulcs párt, lecserélve azokat új kulcs párral, és új tanúsítványt kiadva. Szokványosan a PKI rendszer az irányelvek által meghatározott időközönként végrehajtja a frissítést. Az irányelveket egy cég határozza meg (amennyiben a CA belső PKI-ban működik), vagy a CA saját maga (ha például a CA az Interneten nyilvános működik). Visszavonási kérés: Amikor a CA tudomására jut egy kulcs kompromittálódása (mint a kulcs elveszése) vissza kell vonnia a kulcsot és a visszavonást jelentenie kell egy CRL nyilvánosságra hozatalával. Kereszt tanúsítás: Akár hierarchikus, akár kölcsönös viszony van két CA között, ki kell cserélniük az egymás közötti kereszttanúsításhoz szükséges információkat, a bizalmi viszony kialakítására. A fenti menedzselési funkciók a PKI egyedek közötti együttműködést határozzák meg, mint a kliens alkalmazás és a CA, vagy CA-k közötti együttműködést. A menedzselési funkciók végrehajtásakor a kliens és a CA kéréseket küld egymásnak. Minden rendszerválasz a kérő jogaitól és lehetőségeitől és az alkalmazott irányelvektől függ. Az RFC 2510 az üzenet formátumokat határozza meg ezekre a kérés-válasz kapcsolatokra. Például az RFC meghatározza az üzenet struktúrát egy kliens alkalmazáshoz vagy azt, amit a CA használ egy 56
tanúsítvány lekéréséhez egy másik CA-tól. Meghatározza a választ is, amit a CA vissza fog küldeni a személynek, alkalmazásnak vagy CA-nak. Hasonlóan a PKI alapvető menedzsment funkcióira is meghatározza az üzenet formátumokat, bele értve a visszavonási kérelem üzeneteket, a kereszttanúsítást és kulcsfrissítést. Ezen túlmenően az RFC 2510 egy menedzsment funkció készletet is meghatároz, melyet a CAnak követnie kell, ha meg akar felelni az előjrásoknak. Ezek a funkciók, a valóságban folyamatok, melyeket az RFC által definiált menedzsment protokollok és üzenet formátumok használnak és a CA-nak végre kell hajtani. A kötelező funkciók definiálásával az RFC megteremti a működőképesség alapját, amelyet bármely alkalmazás vagy CA feltételezhet, hogy azokat minden CA betartja. Az RFC 2510 egyszerű fájl alapú protokollt határoz meg, melyben az üzenetek egyszerű fájl formában vannak kódolva, valamint egy socket alapú protokollt, a TCP/IP feletti használatra. Ezen túlmenően e-mail és WEB alapú protokoll is van. Az RFC 2510 alapjait az Entrust fejlesztette, mint a legrégebbi PKI gyártó és termékeiben alkalmazza is. Az RFC része a PKCS#10, bár némi konfliktus van köztük, de biztosítani kell az együttműködést, mivel a PKCS#10 bizonyos funkciókat önmagában nem támogat.
PKI tanúsítvány és CRL irányelvek A koncepcionális kérdések lényeges szerepet játszanak egy üzemelő PKI működésében. A szervezeti PKI esetében a működési irányelvek szükségesek az eredményességhez, amelyek meghatározzák a tanúsítványok használatát, adminisztrációját és menedzsmentjét. Gyakorta ezeknek az irányelveknek kell meghatározni a szervezetnél kiadott és használt, valamint a szervezeten kívülről származó tanúsítványok használatát és elfogadását. Általánosságban kétféle irányelv van a nyilvános kulcsú infrastruktúrában. Elsőként említendők a tanúsítvány irányelvek, amely a tanúsítványok használatát szabályozzák. A CA-k irányelveket határoznak meg, az általuk kiadott tanúsítványok használatára, attól függően, hogy az Interneten működő nyilvános CA-ról, vagy egy szervezet privát CA-járól van-e szó. Másodszor a CA-knak meg kell határozniuk a Certificate Practice Statement-et (CPS), a tanúsítvány gyakorlat ügyrendjét. Bár ez a két irányelv mind célját, mind kiterjedését tekintve különböző, mégis szorosan összefüggnek, és fontos szerepet töltenek be a PKI fejlődésben. A PKIX munkacsoport az RFC 2527-ben pontosan meghatározza a két irányelv közötti viszonyt. A munkacsoport keretrendszert dolgozott ki, hogy segítse azok munkáját, akik ilyen irányelvek megírásával foglakoznak. A keretrendszer meghatározza azokat az elemeket, amelyeket a CA-nak figyelembe kell venni a tanúsítvány irányelvek, vagy a CPS megfogalmazásakor. Tanúsítvány irányelvek Az X.509 definíciója szerint a tanúsítási irányelvek "meghatározott szabályok gyűjteménye, amely a tanúsítvány alkalmazhatóságára vonatkozik egy azonos biztonsági követelményekkel jellemezhető meghatározott közösségen, és/vagy alkalmazási osztályon belül." Például a tanúsítvány irányelvek meghatározhatják, hogy az alkalmazások milyen tanúsítvány típust használhatnak adott ártartományba tartozó áruk kereskedelmében. Így a tanúsítványt használó (alkalmazás vagy személy) a tanúsítási irányelvek alapján eldöntheti hitelesíthet-e egy tanúsítványt az adott célra. A tanúsítvány irányelvek a CA-k akkreditálásának alapját is jelentik. Ha például egy CA tanúsít egy másik CA-t, a tanúsító CA a tanúsítvány irányelveket használja azon irányelvek és funkciók összeállítására, amelyeken a hitelesítési viszony alapul.
57
Akár a tanúsítvány kibocsátója, akár a felhasználója el kell, ismerjen egy tanúsítási irányelvet, ezért az X.509 az irányelvek azonosításához az egyedi Objektum Azonosítók regisztrálására egy módszert tartalmaz. Az X.509 a tanúsítvány formátumában meghatározza az irányelv mezőket is, amelyeket az RFC 2459 az Internet használatra is bevezeti. Ezek a mezők tartalmazzák a tanúsítvány irányelv kiterjesztéseket, az irányelv leképezési kiterjesztéseket és az irányelv korlátozási kiterjesztéseket is. CPS, tanúsítvány gyakorlat ügyrendje Útmutató tervezet készült a digitális aláírások jogi kérdéseinek és koncepcióinak meghatározására. Ez a tanúsítvány gyakorlat ügyrendjét a következők szerint határozza meg: "egy gyakorlati ügyrend, amelyet a tanúsító hatóság alkalmaz a tanúsítványok kibocsátásakor." Így a CPS általában sokkal részletezőbb, mint az irányelvek, biztosítja a CA gyakorlatának részletes ismertetését, beleszámítva a szolgáltatás kínálatot és a tanúsítványok életciklus menedzsmentjét. Mivel a CPS kritikus CA funkciók részleteit ismerteti a tanúsítványhasználók (mindegy, hogy a CA tanúsítja őket, vagy azok akik használják a tanúsítványt) a CPS-t használhatják a CA hitelességének értékelésre. Például a CA-knak nincs jogi akkreditációja, így a CPS fontos eszközzé vált a CA hitelességének megítélésére. Együttműködő-képesség Az RFC 2527 meghatározza, hogy a CPS nem képezi a CA-k közötti együttműködés alapját. A szervezetek - különösen azok, amelyek nyilvános vagy szervezetek közötti CA-kat üzemeltetnek - a CPS-t használva dokumentálják gyakorlatukat. Másrészt a RFC 2527 ajánlása szerint a tanúsítvány irányelvek az együttműködés alapjaiként szolgálhatnak. Például az egyetlen CPS-el rendelkező CA többféle tanúsítvány irányelvet is meghatározhat. A CA-k különböző alkalmazásokhoz, vagy különböző felhasználói közösségekhez különböző irányelveket használhatnak. Viszont többféle CA különböző CPSekkel ugyanazt a tanúsítási iránylevet használhatja. Így a tanúsítvány irányelveket szervezetek között is lehet alkalmazni és általánosságban is a nyilvános Internetre. Az irányelveket a CAknak és alkalmazásoknak együttműködési bázisként el kell ismerniük. Jelenleg azonban kicsi a kilátás nagy számú szabványos irányelvre. A szabványosítás nemcsak megköveteli a szállítók megegyezését a szintaxisról, de az azonosító objektum regisztrációját is, amely egyedi minden irányelv esetén. Manapság mégis jobb, ha az irányelv készítéséhez figyelembe vesszük a RFC 2527 specifikációit. Útmutatók A PKIX munkacsoport RFC 2527-es javaslatai a gyakorlat és az irányelvek meghatározásával segítik a szervezeteket és embereket, hogy elkészíthessék saját tanúsítvány irányelveiket és a tanúsítvány gyakorlatuk ügyrendjét, a CPS-üket . A RFC 2527-es keretrendszert ad a szabályzatok készítéséhez. Például meghatározza a gyakorlat és irányelv specifikációkat, listákon felsorolva a gyakorlat és irányelv kérdéscsoportokat, amelyek változatos témákat fednek le. A RFC 2527 az egyes témák listáit tartalmazza, (vagy ahogy a specifikáció nevezi "topic"-okat), amelyekre kötelező az irányelveket meghatározni. A specifikáció szerint azonban a CA-knak nem kell minden definiált témára irányelveket kidolgozni, de meg kell fontolni egy ellenőrző lista kialakítását az irányelvek és ügyrendek meghatározásakor. Az témák a következők lehetnek: − Az elsődleges komponensek amelyekre az irányelvek vonatkoznak (pl a CA-k).
58
− A CA-hoz forduló igénylő azonosítási és jogosítási folyamatai, amelyekhez a kezdeti regisztráció, a kulcsfrissítés, (mind a rutin és a visszavonás utáni) és a visszavonási bejelentések tartoznak. − A kulcs menedzsment és a biztonsági intézkedések. A CA-k kötelesek védeni a kulcsaikat és jelszavaikat, ideértve a kulcsgenerálást, a privát kulcsok védelmét és a kulcs menedzsment más vonatkozásait, mint a kulcsok aktív élettartama, és a kulcsok archiválásával kapcsolatos kérdések. − Az úgynevezett nem technikai kontroll, amelyet a CA használ a működése biztonságossá tételére. Ez tartalmazza a fizikai kontrollt (mint a CA rendszerek elhelyezésére szolgáló épület és helyiség típusa, milyensége), működési kontrollt (a bizalmi szerepek meghatározása a CA-k között és kötelezettségeik), és a személyi kontrollt (bele értve az alkalmazottak háttér ellenőrzését és a megbízhatósági vizsgálatokat, képzési követelményeket, munkaköri rotációt, a jogosulatlan tevékenységek szankcionálását, és a szerződéses személyzet kapcsolati követelményeit). − A CA-k által használt technikai biztonsági kontroll a működésük biztonságossá tételére. Ebbe tartozik a számítógépes biztonsági kontroll (mint a hiteles rendszerek használata és a jogosultság ellenőrzés), hálózati biztonság (mint a tűzfalak), és az életciklus biztonság kontrollja (mint a szoftver fejlesztési környezet biztonsága és módszertana). − A CA működési követelményei, bele értve a tanúsítványigénylési irányelveket; a tanúsítvány kibocsátást; a tanúsítvány elfogadását; a tanúsítvány felfüggesztését és visszavonását; a biztonsági auditokat. − Általános feltételek, amelyek a jogi és általános szabályozások széles skáláját tartalmazza, mint a szavatosság, kötelezettségek, pénzügyi felelősség, képviselet és szankcionálás. − Tanúsítvány és CRL profilok, amelyek meghatározzák a CA által használt tanúsítvány és CRL formátumokat. Tekintve, hogy az X.509 tanúsítvány és CRL formátumok szabványok, a CA-k saját irányelv információikba csatolhatják az általuk kibocsátott tanúsítványokon alkalmazott speciális profilokat, verziókat és kiterjesztéseket. − Az előírások adminisztrálása, amely meghatározza, hogy a CA miként tartja karban saját ügyrendjét és irányelveit, bele értve, hogy további információkért kivel kell felvenni a kapcsolatot, az irányelvek megváltoztatásának folyamata, és a nyilvánosságra hozatal és az értesítések kezelésének folyamata. Végezetül a PKIX RFC 2527 az ügyrendekre és irányelvekre egy vázlatot tartalmaz, amelyet a munkacsoport ellenőrzési listaként (vagy tovább fejlesztve szabványos formátumként) javasol a CA-knak saját tanúsítvány irányelveik és ügyrendjük elkészítéséhez. A CA-k használhatják a vázlatot a különböző tanúsítvány irányelvek összehasonlítására a kereszttanúsítások alkalmával (például az azonosság feltérképezésére), a CPS összevetésére a tanúsítvány irányelvek definícióival, annak biztosítására, hogy a CPS hűen valósítja meg az irányelvekben leírtakat, vagy akár két CPS összevetésére.
Hivatkozások 59
(1) Lewis, Jamie: Public Key Infrastructure Architecture v1, 9 Jul 1997, The Burton Group, www.tbg.com (2) Entrust Technologies: Trusted Public-Key Infrastructures, ver. 1.2, August 2000, www.entrust.com (3) VeriSign, Inc. Public-Key Infrastructure (PKI) –The VeriSign Difference. 1999, www.verisign.com/repository/ (4) Ford, Warwick, and Baum, Michael S.: Secure Electronic Commerce: Building the Infrastructure for Digital Signatures and Encryption, Prentice-Hall, 1997. (5) "The VeriSign WorldTrust PKI Architecture," VeriSign White Paper #98-05, 1998. (6) Microsoft Corp.:MS Windows 2000 Public-Key Infrastructure, White Paper (7) Microsoft Corporation.: Windows 2000 Certificate Services, March 31, 2000 (8) Gerencsér András: Architektúrák az informatikában, Jegyzet a BKÁE Vezetőképző Intézet informatikai menedzser hallgatói számára, 1999. (9) Digital Signatures –a technical and legal overwiev, Regeringskasliet, Ministry of Transport and Communications, Stockholm, 27 February 1998. (10) Digital Signature: Inventory of international regulatory, standardisation and commercial activities, http://europa.eu.int/ISPO/legal/en/ecommerc/digsig.html (11) Engel-Flechsig S.:A német digitális aláírás törvény kivitelezése és a közreműködö német vállalatok.http://dbassoc.hu/maksign/dak/Engel.htm (12) DoD PKI Medium Assurance http://www.disa.mil/infosec/pki-int.htm
Interoperability,
15
January
1999.
1
13 Gluck, F.B.: Protection of Electronic Mail and Electronic Messages: Challenges and Solutions. Datamedia Corp. 1993. 1
14 Hafner and Markoff; Cyberpunk; E.H.Spafford, “The Internet Worm: Crisis and Aftermath”, Communications of the ACM, Vol. 32, no. 6 (June 1989), pp. 678-687
1
15 Kahn, D.: Cryptology Goes Public, IEEE.Communications Magazine, vol.18, pp.19-28, March 1980. Smith, R.E.: Civilian Cryptography, Compcon, p.215D, Spring 1980.
1
16 Merkle, R.C.: Secure Communications Over an Insecure Channel, Communications ACM, vol. 21, pp.294-299, April 1978. 1
17 Diffie, W.,Hellmann, M.E.: Exhaustive Cryptanalysis of the NBS Data Encryption Standard, IEEE Communications Magazine, vol.10, pp.74-84, June 1977.
1
18 Rivest, R.L.,Shamir,A., and Adleman, L.: On a Method for Obtaining Digital Signatures and Public Key Cryptosystems, Communications ACM, vol. 21, pp.120-126, Febr. 1978. 1
19 RSA Laboratories: PKCS-1 "RSA Encryption" (RFC 2313), PKCS-7 "Cryptographic Message Syntax Standard",PKCS-10, "Certification Request Syntax Standard." http://www.rsasecurity.com/rsalabs/pkcs/index.html
1
20 PKIX Internet draft, Internet X.509 Public Key Infrastructure, ftp://ftp.ietf.org/internetdrafts/draft-ietf-pkix-roadmap-06.txt, November 2000. 1
21 RFC 2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, January 1999, ftp://ftp.isi.edu/in-notes/rfc2459.txt Új PKIX tervezet az RFC 2459 frissítésére: Internet Public Key Infrastructure X.509 Certificate and CRL Profile, ftp://ftp.ietf.org/internetdrafts/draft-ietf-pkix-new-part1-04.txt, January 2001. 60
1
22 RFC 2559: Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2, April 1999. ftp://ftp.isi.edu/in-notes/rfc2559.txt. Új PKIX tervezet az RFC 2559 frissítésére: Internet X.509 PKI Operational Protocols - LDAPv3 ftp://ftp.ietf.org/internet-drafts/draft-ietfpkix-ldap-v3-03.txt, September 2000. 1
23 RFC 2510: Internet X.509 Public Key Infrastructure Certificate Management Protocols, ftp://ftp.isi.edu/in-notes/rfc2510.txt, March 1999. Új PKIX tervezet az RFC 2510 frissítésére, RFC 2510bis-03 2001 február! 1
24 RFC 2527: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework ftp://ftp.isi.edu/in-notes/rfc2527.txt, March 1999. 1
25 PKIX: Internet Draft Part 1: Internet Public Key Infrastructure X.509 Certificate and CRL Profile, http://www.ietf.org/ids.by.wg/pkix.html
1
26 PKIX Internet Draft "Part 2: Operational Protocols." ftp://ftp.ietf.org/internet-drafts/draftietf-pkix-ipki2opp-00.txt
1
27 PKIX Internet Draft "Part III: Certificate Management Protocols." ftp://ftp.ietf.org/internetdrafts/draft-ietf-pkix-ipki3cmp-02.txt 128 PKIX Internet Draft "Part IV: Certificate Policy and Certification Practices Framework" ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part4-01.txt 1
29 S/MIME:RFC 2630: "Cryptographic Message Syntax," RFC 2633: "S/MIME Version 3 Message Specification," RFC 2312: "S/MIME Version 3 Certificate Handling," ftp://ftp.isi.edu/in-notes/rfcxxxx.txt
61
1. melléklet: mintái
USA Védelmi Minisztérium (DoD) tanúsítvány profil
Certificate Profiles Version 1.3 Date: 22-Jul-98 Certification Authority Certificates Table 12 Certification Authority Certificate Profiles
FIELD
Signing CA Certificate
Root CA Certificate
Basic Certificate Version Serial Number Issuer Signature Algorithm2,3,4 Issuer Distinguished Name5 Validity Period6 Subject Distinguished Name
Subject Public Key Information Issuer Unique Identifier Subject Unique Identifier Issuer’s Signature7
V3 (2) Sequentially as issued sha-1WithRSAEncryption
V3 (2) Sequentially as issued sha-1WithRSAEncryption
cn= DOD PKI Med Root CA
cn= DOD PKI Med Root CA
5 years from date of issue For identity certificates: cn=Med CA-
For email certificates: cn=Med Email CA- 1024 bit RSA key modulus, rsaEncryption Never used Never used sha-1WithRSAEncryption
10 years from date of issue cn= DOD PKI Med Root CA
1024 bit RSA key modulus, rsaEncryption Never used Never used sha-1WithRSAEncryption
c=no c=no
Never used c=no
Extensions authority key identifier8 subject key identifier9
2
Algorithm parameters will not be included.
3
CA’s will use id-dsa-with-sha1 signature algorithm when CA products are capable of both RSA and DSS.
4
Initially the OID will be the RSA registered OID {1 2 840 113549 1 1 5} rather than the OIW OID prescribed.
5
Value is the cn attribute. All CAs will have the common base: ou=PKI, ou=DOD, o= U.S. Government, c=US
6
The values will be in the UTC Time format. The notBefore component will be the certificate’s issue date. The notAfter component will be midnight on the day ending the duration given in the table. 7
See earlier note regarding the issuer signature algorithm field.
8
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key information. 9
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key information.
62
FIELD key usage
Extended key usage Private key usage period Certificate policies10 Policy Mapping subject Alternate Name Issuer Alternate Name Subject Directory Attributes Basic Constraints
Name Constraints Policy Constraints
CRL Distribution Points
10
Signing CA Certificate c=yes; digitalSignature, keyCertSign, cRLSign Never used Never used c=no; pid= id-US-medium-pilot Not used Not used c=no, rootURI Not used c=yes; cA=True; no path length constraint Not used c=no; requireExplicitPolicy set with skipCerts set to zero. c=no; distribution point = rootCACRLURI; reason code and crl issuer not used
No policy qualifiers will be used.
63
Root CA Certificate Never used
Never used Never used Never used Not used Never used Never used Not used c=no; cA=True; no path length constraint Never used Never used
Never used
Standard End-Entity Certificates Table 13 Standard End-Entity Certificate Profiles FIELD
Standard Digital Signature and SSL Client Certificate
E-mail Certificate
Server Certificate
Basic Certificate Version Serial Number Issuer Signature Algorithm11,12,13 Issuer Distinguished Name14 Validity Period15 Subject Distinguished Name Subject Public Key Information Issuer Unique Identifier Subject Unique Identifier Issuer’s Signature17
V3 (2)
V3 (2)
V3 (2)
Sequentially as issued
Sequentially as issued
Sequentially as issued
sha-1WithRSAEncryption
sha-1WithRSAEncryption
sha-1WithRSAEncryption
cn=Med CA-
cn=Med Email CA-
cn=Med CA-
3 years from date of issue
2 years from date of issue
3 years from date of issue
See I/f spec
See I/f spec
cn=
1024 bit RSA key modulus, rsaEncryption 16 Never used
1024 bit RSA key modulus, rsaEncryption Never used
1024 bit RSA key modulus, rsaEncryption Never used
Never used
Never used
Never used
sha-1WithRSAEncryption
sha-1WithRSAEncryption
sha-1WithRSAEncryption
c=no
c=no
c=no
c=no
c=no
c=no
c=yes; digitalSignature, nonRepudiation Never used
c=yes; digitalSignature, 20 keyEncipherment Never used
c=yes; keyEncipherment Never used
Never used
Never used
Never used
Extensions authority key identifier18 subject key identifier19 key usage Extended key usage Private key usage period
11
Algorithm parameters will not be included.
12
CA’s will use id-dsa-with-sha1 signature algorithm when CA products are capable of both RSA and DSS.
13
Initially the OID will be the RSA registered OID {1 2 840 113549 1 1 5} rather than the OIW OID prescribed.
14
Value is the cn attribute. All CAs will have the common base: ou=PKI, ou=DOD, o= U.S. Government, c=US
15
The values will be in the UTC Time format. The notBefore component will be the certificate’s issue date. The notAfter component will be midnight on the day ending the duration given in the table.
16
The entry “never used” means the PKI does not plan to use the field. Clients do not need to process the field.
17
See earlier note regarding the issuer signature algorithm field.
18
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key information.
19
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key information.
20
Because many current S/MIME clients do not enforce functional separation both the digitalSignature and keyEncipherment flags will be set in initial operation. However, once S/MIME clients enforce functional separation the PKI will issue certificates with either but not both of these flags set.
64
FIELD
Standard Digital Signature and SSL Client Certificate
E-mail Certificate
Server Certificate
Certificate policies21
c=no; pid= id-US-
Policy Mapping subject Alternate Name Issuer Alternate Name Subject Directory Attributes Basic Constraints
Never used
Not used
22
Not used
Not used
23
Not used
Not used
Not used
Not used
Not used
Not used
c=yes; cA=False (default) Never used
c=yes; cA=False (default) Never used
c=yes; cA=False (default) Never used
Never used
Never used
Never used
c=no; distribution point = cRLURI; reason code and crl issuer not initially used
c=no; distribution point = cRLURI; reason code and crl issuer not initially used
c=no; distribution point = cRLURI; reason code and crl issuer not initially used
c=no; pid= id-US-
medium-pilot
Name Constraints Policy Constraints CRL Distribution Points
21
medium-pilot
c=no; pid= id-US-
medium-pilot Not used Not used
No policy qualifiers will be used.
22
The entry “not used” means the PKI does not intend to use the field or extension immediately but may at some time in the future. Clients shall be able to process the field or extension.
23
This field will contain the user’s e-mail address if and when S/MIME clients can look in this extension for the user’s e-mail address and not require an E component in the subject’s name. At that time the extension will be: c=no; rfc822name(s) of user’s email address(es)
65
Object Identifiers sha-1WithRSAEncryption OBJECT IDENTIFIER ::= {iso(1) identifiedorganization(3) oiw(14) secsig(3) algorithm(2) 29 } pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 1 } rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} id-dsa-with-sha1 ID ::= {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) iddsa-with-sha1(3) } id-certificate-policy = {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) 11} id-US-medium-pilot = {id-certificate-policy 3} cAURI = ldap://ldap.med_pki.mil/cn=Med CA-, ou=PKI, ou=DOD, o= U.S. Government, c=US24 rootURI = ldap://ldap.med_pki.mil/cn= DOD PKI Med Root CA, ou=PKI, ou=DOD, o= U.S. Government, c=US25 cRLURI = ldap://ldap.med_pki.mil/cn=Med CA-, ou=PKI, ou=DOD, o= U.S. Government, c=US?certificateRevocationList26 rootCACRLURI = ldap://ldap.med_pki.mil/cn= DOD PKI Med Root CA, ou=PKI, ou=DOD, o= U.S. Government, c=US?certificateRevocationList27
24
For readability, this URI is shown without encoding special characters. Certain characters must be encoded (See RFC 1738).
25
See previous note regarding encoding of special characters in URIs.
26
See previous note regarding encoding of special characters in URIs.
27
See previous note regarding encoding of special characters in URIs.
66
2. melléklet
USA Védelmi Minisztérium (DoD) tanúsítvány mintái
Certificate: Data: Version: v3 (0x2) Serial Number: 27 (0x1b) Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: CN=DoD PKI Med Root CA, OU=PKI, OU=DoD, Government, C=US Validity: Not Before: Mon Aug 3 15:02:29 1998 Not After: Mon Aug 4 15:02:29 2008 Subject: CN=DoD PKI Med Root CA, OU=PKI, OU=DoD, Government, C=US Subject Public Key Info: Algorithm: PKCS #1 RSA Encryption Public Key: Modulus: 00:db:ac:cf:c9:f4:5a:c9:49:7f:b3:c4:55:1b:b0:8f:55:c3: 94:1b:82:e5:41:21:af:79:af:05:bf:d0:cf:3e:b0:cd:2b:e6: 07:7e:0d:8e:a2:b9:b9:ba:c2:75:e4:09:2b:db:7d:09:45:10: 34:8a:af:85:98:79:e1:a9:f9:df:56:94:39:d0:76:d0:c5:2d: d0:38:e6:d0:a2:e5:21:e3:9d:6f:a1:18:09:99:9e:57:74:af: 3e:b0:41:e9:05:e7:14:1a:6b:90:3a:c2:38:4c:94:b3:a3:6e: 1d:bb:cf:2b:1c:ae:8a:cc:27:53:b9:14:13:96:9c:41:dc:46: fe:b1:a9 Public Exponent: 65537 (0x10001) Extensions: Identifier: Subject Key Identifier Critical: no Value: 56:b9:98:47:a9:bd:ef:4d:5c:1d:0d:eb:e6:45:f2:1b:bc:ec: 08:dd Identifier: basicConstraints Critical: no DER Value: 30:03:01:01:ff Signature: Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: d5:5f:56:34:62:a0:bb:bd:e9:1e:66:35:71:b7:2b:82:f0:c9:f1:6e:bc: fa:0f:5d:3d:01:7d:3b:2c:42:11:cc:d6:33:c1:9d:30:31:32:26:4a:9f: 6c:13:35:96:fb:71:6e:78:12:14:ec:0c:46:ca:cd:8e:ed:7d:2a:98:dd: f3:82:cc:cf:7d:28:a8:70:1b:90:b9:72:18:41:cb:49:84:a8:c5:e4:a5: 5c:54:64:11:61:89:6d:fa:6c:a1:97:6b:f2:eb:23:f3:11:50:a3:88:ac: 0c:11:bd:52:a6:ed:22:ac:27:fe:94:55:b6:86:c7:63:be:64:90:32:d6:
67
O=U.S.
O=U.S.
6f:3b
-----BEGIN CERTIFICATE----MIICZzCCAdCgAwIBAgIBGzANBgkqhkiG9w0BAQUFADBhMQswCQYDVQQGEwJVUzEY MBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTEcMBoGA1UEAxMTRG9EIFBLSSBNZWQgUm9vdCBDQTAeFw05ODA4MDMyMjAy MjlaFw0wODA4MDQyMjAyMjlaMGExCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRwwGgYDVQQD ExNEb0QgUEtJIE1lZCBSb290IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDbrM/J9FrJSX+zxFUbsI9Vw5QbguVBIa95rwW/0M8+sM0r5gd+DY6iubm6wnXk CSvbfQlFEDSKr4WYeeGp+d9WlDnQdtDFLdA45tCi5SHjnW+hGAmZnld0rz6wQekF 5xQaa5A6wjhMlLOjbh27zyscrorMJ1O5FBOWnEHcRv6xqQIDAQABoy8wLTAdBgNV HQ4EFgQUVrmYR6m9701cHQ3r5kXyG7zsCN0wDAYDVR0TBAUwAwEB/zANBgkqhkiG 9w0BAQUFAAOBgQDVX1Y0YqC7vekeZjVxtyuC8Mnxbrz6D109AX07LEIRzNYzwZ0w MTImSp9sEzWW+3FueBIU7AxGys2O7X0qmN3zgszPfSiocBuQuXIYQctJhKjF5KVc VGQRYYlt+myhl2vy6yPzEVCjiKwMEb1Spu0irCf+lFW2hsdjvmSQMtZvOw== -----END CERTIFICATE-----
Certificate: Data: Version: v3 (0x2) Serial Number: 26 (0x1a) Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: Government, C=US
CN=DoD
PKI
Med
Root
CA,
OU=PKI,
OU=DoD,
O=U.S.
Validity: Not Before: Sun Aug
2 09:45:38 1998
Not
2 09:45:38 2003
After: Sat Aug
Subject: CN=Med CA-1, OU=PKI, OU=DoD, O=U.S. Government, C=US Subject Public Key Info: Algorithm: PKCS #1 RSA Encryption Public Key: Modulus: 00:c9:47:2b:c3:59:3a:40:a7:41:5a:38:2d:18:e9:35:01:56: aa:24:d2:3c:69:c0:c6:82:58:6a:41:0f:78:41:87:ea:64:ab: a8:d7:0c:1d:9d:87:a1:ae:0a:39:41:c1:a4:c3:d5:dc:8c:16: 1e:80:b1:6c:bf:83:42:0b:06:76:a6:0b:1f:60:99:6f:1d:c4: 86:3e:14:ff:c1:13:94:60:4a:57:29:e9:5f:5e:21:1e:68:68: 45:97:cc:c6:72:ab:5e:23:6f:84:05:b3:99:9c:5a:63:63:8c: be:db:97:50:72:36:27:ad:11:8c:01:0f:7c:a8:6c:10:b6:88: 03:88:37 Public Exponent: 65537 (0x10001) Extensions:
68
Identifier: certificatePolicies Critical: no DER Value: 30:0d:30:0b:06:09:60:86:48:01:65:02:01:0b:03 Identifier: Authority Key Identifier Critical: no Key Identifier: 56:b9:98:47:a9:bd:ef:4d:5c:1d:0d:eb:e6:45:f2:1b:bc:ec: 08:dd Identifier: policyConstraints Critical: no DER Value: 30:03:80:01:00 Identifier: Subject Key Identifier Critical: no Value: 33:3a:14:e8:09:67:61:88:65:24:20:ec:79:70:42:d7:a6:93: 1e:f6 Identifier: keyUsage Critical: yes DER Value: 03:02:01:86 Identifier: issuerAltName Critical: no DER Value: 30:75:86:73:6c:64:61:70:3a:2f:2f:64:73:2d:31:2e:63:68: 61:6d:62:2e:64:69:73:61:2e:6d:69:6c:2f:63:6e:25:33:64: 44:6f:44:25:32:30:50:4b:49:25:32:30:4d:65:64:25:32:30: 52:6f:6f:74:25:32:30:43:41:25:32:63:6f:75:25:33:64:50: 4b:49:25:32:20:63:6f:75:25:33:64:44:6f:44:25:32:63:6f: 25:33:64:55:2e:53:2e:25:32:30:47:6f:76:65:72:6e:6d:65: 6e:74:25:32:63:63:25:33:64:55:53 Identifier: basicConstraints Critical: yes DER Value: 30:03:01:01:ff Identifier: cRLDistributionPoints Critical: no DER Value: 30:81:a1:30:81:9e:a0:81:9b:a0:81:98:86:81:95:6c:64:61: 70:3a:2f:2f:64:73:2d:31:2e:63:68:61:6d:62:2e:64:69:73: 61:2e:6d:69:6c:2f:63:6e:25:33:64:44:6f:44:25:32:30:50: 4b:49:25:32:30:4d:65:64:25:32:30:52:6f:6f:74:25:32:30: 43:41:25:32:63:6f:75:25:33:64:50:4b:49:25:32:63:6f:75: 25:33:64:44:6f:44:25:32:63:6f:25:33:64:55:2e:53:2e:25: 32:30:47:6f:76:65:72:6e:6d:65:6e:74:25:32:63:63:25:33:
69
64:55:53:3f:63:65:72:74:69:66:69:63:61:74:65:52:65:76: 6f:63:61:74:69:6f:6e:4c:69:73:74:25:33:62:62:69:6e:61: 72:79 Signature: Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 5a:39:fd:3b:b4:76:cc:bc:b7:28:49:56:fc:5a:28:53:4c:7c:fd:cb:2d: ab:29:97:e3:ab:f2:80:a9:9d:c2:9d:a4:ac:a3:ed:93:ba:b8:9d:27:ee: 8a:af:11:a5:13:86:6f:23:81:74:8d:83:2b:6d:95:83:f0:a0:d0:71:12: c4:ea:fe:50:43:57:7f:b2:fd:ce:b5:a6:cc:37:a8:cd:9b:a0:1d:47:3a: 2d:f1:5e:74:58:f9:eb:46:df:74:cd:f7:2c:9d:ce:b6:79:d9:73:34:86: 72:59:77:8c:48:7e:80:20:aa:ce:13:da:b8:2a:83:c8:71:d3:27:54:ee: 8e:28
-----BEGIN CERTIFICATE----MIID6TCCA1KgAwIBAgIBGjANBgkqhkiG9w0BAQUFADBhMQswCQYDVQQGEwJVUzEY MBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTEcMBoGA1UEAxMTRG9EIFBLSSBNZWQgUm9vdCBDQTAeFw05ODA4MDIxNjQ1 MzhaFw0wMzA4MDIxNjQ1MzhaMFYxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMREwDwYDVQQD EwhNZWQgQ0EtMTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyUcrw1k6QKdB WjgtGOk1AVaqJNI8acDGglhqQQ94QYfqZKuo1wwdnYehrgo5QcGkw9XcjBYegLFs v4NCCwZ2pgsfYJlvHcSGPhT/wROUYEpXKelfXiEeaGhFl8zGcqteI2+EBbOZnFpj Y4y+25dQcjYnrRGMAQ98qGwQtogDiDcCAwEAAaOCAbowggG2MBYGA1UdIAQPMA0w CwYJYIZIAWUCAQsDMB8GA1UdIwQYMBaAFFa5mEepve9NXB0N6+ZF8hu87AjdMAwG A1UdJAQFMAOAAQAwHQYDVR0OBBYEFDM6FOgJZ2GIZSQg7HlwQtemkx72MA4GA1Ud DwEB/wQEAwIBhjB+BgNVHRIEdzB1hnNsZGFwOi8vZHMtMS5jaGFtYi5kaXNhLm1p bC9jbiUzZERvRCUyMFBLSSUyME1lZCUyMFJvb3QlMjBDQSUyY291JTNkUEtJJTIg Y291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTMA8GA1Ud EwEB/wQFMAMBAf8wgawGA1UdHwSBpDCBoTCBnqCBm6CBmIaBlWxkYXA6Ly9kcy0x LmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwUEtJJTIwTWVkJTIwUm9vdCUyMENB JTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUy Y2MlM2RVUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0JTNiYmluYXJ5MA0GCSqG SIb3DQEBBQUAA4GBAFo5/Tu0dsy8tyhJVvxaKFNMfP3LLaspl+Or8oCpncKdpKyj 7ZO6uJ0n7oqvEaUThm8jgXSNgyttlYPwoNBxEsTq/lBDV3+y/c61psw3qM2boB1H Oi3xXnRY+etG33TN9yydzrZ52XM0hnJZd4xIfoAgqs4T2rgqg8hx0ydU7o4o -----END CERTIFICATE-----
Certificate: Data: Version: v3 (0x2) Serial Number: 69 (0x45) Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: CN=Med CA-1, OU=PKI, OU=DoD, O=U.S. Government, C=US Validity:
70
Not Before: Sun Aug
2 10:13:29 1998
Not
2 10:13:29 2001
After: Thu Aug
Subject: CN=ds-1.cistw.saic.com, OU=USAF, OU=PKI, OU=DoD, O=U.S. Government, C=US Subject Public Key Info: Algorithm: PKCS #1 RSA Encryption Public Key: Modulus: 00:d7:da:09:b2:ca:52:1e:75:83:8b:5f:cd:4e:d8:5b:2e:b9: e2:70:3a:20:83:77:3a:dd:91:cf:79:d5:35:60:3f:74:2f:5a: 20:91:8c:f1:48:0d:ad:32:0b:15:66:93:5e:8c:18:25:13:de: f6:99:72:8f:a8:41:83:a2:39:c3:82:5b:51:81:12:ed:2e:a8: ac:22:cd:03:48:54:2b:26:b8:40:f1:e8:0c:1f:fa:47:02:8f: 47:7c:7d:27:f6:b4:14:60:12:37:76:c2:f1:42:41:95:51:26: c1:e0:ff:37:54:78:b4:b1:03:b4:75:6b:2a:e6:61:19:77:d1: be:31:fb Public Exponent: 3 (0x3) Extensions: Identifier: certificatePolicies Critical: no DER Value: 30:0d:30:0b:06:09:60:86:48:01:65:02:01:0b:03 Identifier: Authority Key Identifier Critical: no Key Identifier: 33:3a:14:e8:09:67:61:88:65:24:20:ec:79:70:42:d7:a6:93: 1e:f6 Identifier: Subject Key Identifier Critical: no Value: 71:06:98:3b:c1:04:8e:37:be:54:8d:ef:7c:12:25:0c:2e:87: 36:3d Identifier: keyUsage Critical: yes DER Value: 03:02:05:20 Identifier: basicConstraints Critical: yes DER Value: 30:00 Identifier: cRLDistributionPoints Critical: no DER Value: 30:81:92:30:81:8f:a0:81:8c:a0:81:89:86:81:86:6c:64:61: 70:3a:2f:2f:64:73:2d:31:2e:63:68:61:6d:62:2e:64:69:73: 61:2e:6d:69:6c:2f:63:6e:25:33:64:4d:65:64:25:32:30:43:
71
41:25:32:64:31:25:32:63:6f:75:25:33:64:50:4b:49:25:32: 63:6f:75:25:33:64:44:6f:44:25:32:63:6f:25:33:64:55:2e: 53:2e:25:32:30:47:6f:76:65:72:6e:6d:65:6e:74:25:32:63: 63:25:33:64:55:53:3f:63:65:72:74:69:66:69:63:61:74:65: 52:65:76:6f:63:61:74:69:6f:6e:4c:69:73:74:25:33:62:62: 69:6e:61:72:79 Signature: Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 48:3b:00:2f:5b:69:dd:8a:67:3c:97:e1:ca:8b:53:f9:af:d9:c6:d5:83: ab:44:4b:63:c8:79:24:fb:9e:4f:02:41:cb:fd:6b:c2:0e:dc:ae:2e:86: b2:a8:4e:c4:1f:aa:cf:69:eb:ee:ac:d1:56:e0:1f:73:ca:bc:e0:08:17: 80:c0:a7:96:2a:d7:3c:f7:7c:1f:a1:b1:a1:65:78:7a:ad:0c:db:a5:76: 6d:7e:dd:70:36:3a:a6:b9:69:11:64:6f:a2:ab:ba:dd:04:10:e5:78:73: f1:84:00:f3:ab:44:65:13:cd:89:8e:a7:84:84:73:c4:c4:68:3f:fb:e4: 0e:d1
-----BEGIN CERTIFICATE----MIIDVjCCAr+gAwIBAgIBRTANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEY MBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTERMA8GA1UEAxMITWVkIENBLTEwHhcNOTgwODAyMTcxMzI5WhcNMDEwODAy MTcxMzI5WjBwMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50 MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTENMAsGA1UECxMEVVNBRjEcMBoG A1UEAxMTZHMtMS5jaXN0dy5zYWljLmNvbTCBnTANBgkqhkiG9w0BAQEFAAOBiwAw gYcCgYEA19oJsspSHnWDi1/NTthbLrnicDogg3c63ZHPedU1YD90L1ogkYzxSA2t MgsVZpNejBglE972mXKPqEGDojnDgltRgRLtLqisIs0DSFQrJrhA8egMH/pHAo9H fH0n9rQUYBI3dsLxQkGVUSbB4P83VHi0sQO0dWsq5mEZd9G+MfsCAQOjggEaMIIB FjAWBgNVHSAEDzANMAsGCWCGSAFlAgELAzAfBgNVHSMEGDAWgBQzOhToCWdhiGUk IOx5cELXppMe9jAdBgNVHQ4EFgQUcQaYO8EEjje+VI3vfBIlDC6HNj0wDgYDVR0P AQH/BAQDAgUgMAwGA1UdEwEB/wQCMAAwgZ0GA1UdHwSBlTCBkjCBj6CBjKCBiYaB hmxkYXA6Ly9kcy0xLmNoYW1iLmRpc2EubWlsL2NuJTNkTWVkJTIwQ0ElMmQxJTJj b3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2Ml M2RVUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0JTNiYmluYXJ5MA0GCSqGSIb3 DQEBBQUAA4GBAEg7AC9bad2KZzyX4cqLU/mv2cbVg6tES2PIeST7nk8CQcv9a8IO 3K4uhrKoTsQfqs9p6+6s0VbgH3PKvOAIF4DAp5Yq1zz3fB+hsaFleHqtDNuldm1+ 3XA2Oqa5aRFkb6Krut0EEOV4c/GEAPOrRGUTzYmOp4SEc8TEaD/75A7R -----END CERTIFICATE-----
Certificate: Data: Version: v3 (0x2) Serial Number: 74 (0x4a) Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
72
Issuer: CN=Med CA-1, OU=PKI, OU=DoD, O=U.S. Government, C=US Validity: Not Before: Sun Aug
2 11:02:40 1998
Not
2 11:02:40 2001
After: Thu Aug
Subject: CN=Gumby.Joseph.0000005044, O=U.S. Government, C=US
OU=USAF,
OU=PKI,
Subject Public Key Info: Algorithm: PKCS #1 RSA Encryption Public Key: Modulus: 00:b4:ff:47:b6:cf:aa:cd:5c:d5:8a:97:02:0e:47:36:96:4b: 81:6d:87:b8:07:3b:44:26:8f:d3:a7:04:e1:1e:38:18:12:f0: fd:f4:1c:55:13:4b:9f:9a:60:6d:35:ec:0e:78:e2:65:57:7c: a8:48:18:aa:32:85:42:46:b8:fe:d3:61:68:5e:cd:a3:6b:41: 64:1f:a8:60:bf:de:3f:42:16:b4:ff:a1:fd:6e:83:29:1e:7e: 52:f2:08:76:09:b1:ee:4d:ed:f6:3a:76:43:9d:49:a4:78:61: 28:46:fd:58:de:78:b6:b0:8e:f5:8b:bb:3d:85:3e:2c:8f:39: 8c:42:01 Public Exponent: 65537 (0x10001) Extensions: Identifier: certificatePolicies Critical: no DER Value: 30:0d:30:0b:06:09:60:86:48:01:65:02:01:0b:03 Identifier: Authority Key Identifier Critical: no Key Identifier: 33:3a:14:e8:09:67:61:88:65:24:20:ec:79:70:42:d7:a6:93: 1e:f6 Identifier: Subject Key Identifier Critical: no Value: 90:b0:49:97:e6:b2:2a:0c:ce:a7:fc:30:05:7f:4c:d6:54:a4: 0a:0e Identifier: keyUsage Critical: yes DER Value: 03:02:06:c0 Identifier: basicConstraints Critical: yes DER Value: 30:00 Identifier: cRLDistributionPoints Critical: no DER Value: 30:81:92:30:81:8f:a0:81:8c:a0:81:89:86:81:86:6c:64:61:
73
OU=DoD,
70:3a:2f:2f:64:73:2d:31:2e:63:68:61:6d:62:2e:64:69:73: 61:2e:6d:69:6c:2f:63:6e:25:33:64:4d:65:64:25:32:30:43: 41:25:32:64:31:25:32:63:6f:75:25:33:64:50:4b:49:25:32: 63:6f:75:25:33:64:44:6f:44:25:32:63:6f:25:33:64:55:2e: 53:2e:25:32:30:47:6f:76:65:72:6e:6d:65:6e:74:25:32:63: 63:25:33:64:55:53:3f:63:65:72:74:69:66:69:63:61:74:65: 52:65:76:6f:63:61:74:69:6f:6e:4c:69:73:74:25:33:62:62: 69:6e:61:72:79 Signature: Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 58:da:a6:e0:c7:32:f2:1d:51:e6:11:c8:46:1d:4a:10:51:d4:96:42:db: 4b:49:dc:c4:27:c8:14:2f:79:d7:73:2c:61:43:1a:92:24:44:04:14:ed: 3f:f9:fe:77:bc:94:c7:b1:cb:15:62:0b:6d:71:3a:52:bd:2d:d6:c9:09: b5:72:cb:0b:db:f6:e1:26:ff:58:de:f7:08:9e:41:0b:6b:92:3c:a4:b8: 1f:96:07:aa:93:08:8b:25:00:ef:de:52:68:33:7f:32:04:36:f9:c7:f0: ef:9f:1f:b4:13:af:63:dd:90:59:22:3c:8a:81:25:81:ef:c3:b1:77:5c: 3a:b2
-----BEGIN CERTIFICATE----MIIDXDCCAsWgAwIBAgIBSjANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEY MBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTERMA8GA1UEAxMITWVkIENBLTEwHhcNOTgwODAyMTgwMjQwWhcNMDEwODAy MTgwMjQwWjB0MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50 MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTENMAsGA1UECxMEVVNBRjEgMB4G A1UEAxMXR3VtYnkuSm9zZXBoLjAwMDAwMDUwNDQwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBALT/R7bPqs1c1YqXAg5HNpZLgW2HuAc7RCaP06cE4R44GBLw/fQc VRNLn5pgbTXsDnjiZVd8qEgYqjKFQka4/tNhaF7No2tBZB+oYL/eP0IWtP+h/W6D KR5+UvIIdgmx7k3t9jp2Q51JpHhhKEb9WN54trCO9Yu7PYU+LI85jEIBAgMBAAGj ggEaMIIBFjAWBgNVHSAEDzANMAsGCWCGSAFlAgELAzAfBgNVHSMEGDAWgBQzOhTo CWdhiGUkIOx5cELXppMe9jAdBgNVHQ4EFgQUkLBJl+ayKgzOp/wwBX9M1lSkCg4w DgYDVR0PAQH/BAQDAgbAMAwGA1UdEwEB/wQCMAAwgZ0GA1UdHwSBlTCBkjCBj6CB jKCBiYaBhmxkYXA6Ly9kcy0xLmNoYW1iLmRpc2EubWlsL2NuJTNkTWVkJTIwQ0El MmQxJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVu dCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0JTNiYmluYXJ5MA0G CSqGSIb3DQEBBQUAA4GBAFjapuDHMvIdUeYRyEYdShBR1JZC20tJ3MQnyBQveddz LGFDGpIkRAQU7T/5/ne8lMexyxViC21xOlK9LdbJCbVyywvb9uEm/1je9wieQQtr kjykuB+WB6qTCIslAO/eUmgzfzIENvnH8O+fH7QTr2PdkFkiPIqBJYHvw7F3XDqy -----END CERTIFICATE-----
Certificate: Data:
74
Version: v3 (0x2) Serial Number: 25 (0x19) Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: CN=Med Email CA-1, OU=PKI, OU=DoD, O=U.S. Government, C=US Validity: Not Before: Sun Aug
2 11:06:34 1998
Not
2 11:06:34 2000
After: Wed Aug
Subject: [email protected], OU=USAF, OU=PKI, OU=DoD, O=U.S. Government, C=US
CN=Gumby.Joseph.0000005044,
Subject Public Key Info: Algorithm: PKCS #1 RSA Encryption Public Key: Modulus: 00:bd:4e:0b:32:83:a7:17:d6:e6:84:7b:f1:67:3f:30:09:cf: 5e:44:9d:23:e1:10:74:4a:65:58:a2:af:62:3e:b4:89:07:04: 4e:7a:ec:6e:53:c5:52:24:12:ff:bb:e4:41:e6:de:94:25:53: 63:5c:59:81:d7:04:b4:7e:8c:69:38:71:50:04:55:b2:bd:69: ae:3a:24:54:35:a4:71:4d:50:ab:3b:87:86:fa:79:8c:fd:4f: 3d:0c:a0:1c:f4:55:78:6d:9f:1d:3c:4f:4f:94:af:68:ab:42: 7c:63:60:c8:2b:3d:7e:80:87:8c:d6:c4:cf:32:70:ed:16:07: c6:c8:7f Public Exponent: 65537 (0x10001) Extensions: Identifier: certificatePolicies Critical: no DER Value: 30:0d:30:0b:06:09:60:86:48:01:65:02:01:0b:03 Identifier: Authority Key Identifier Critical: no Key Identifier: 97:2b:48:73:7f:6b:e6:8d:2f:90:ca:d4:da:49:50:8b:d7:f9: b5:67 Identifier: Subject Key Identifier Critical: no Value: 79:d0:df:7b:03:12:b4:1b:a5:35:ec:43:f5:8a:ed:fc:2e:22: d3:07 Identifier: keyUsage Critical: yes DER Value: 03:02:05:a0 Identifier: basicConstraints Critical: yes DER Value: 30:00
75
Identifier: cRLDistributionPoints Critical: no DER Value: 30:81:9e:30:81:9b:a0:81:98:a0:81:95:86:81:92:6c:64:61: 70:3a:2f:2f:64:73:2d:31:2e:63:68:61:6d:62:2e:64:69:73: 61:2e:6d:69:6c:3a:33:39:30:2f:63:6e:25:33:64:4d:65:64: 25:32:30:45:6d:61:69:6c:25:32:30:43:41:25:32:64:31:25: 32:63:6f:75:25:33:64:50:4b:49:25:32:63:6f:75:25:33:64: 44:6f:44:25:32:63:6f:25:33:64:55:2e:53:2e:25:32:30:47: 6f:76:65:72:6e:6d:65:6e:74:25:32:63:63:25:33:64:55:53: 3f:63:65:72:74:69:66:69:63:61:74:65:52:65:76:6f:63:61: 74:69:6f:6e:4c:69:73:74:25:33:62:62:69:6e:61:72:79 Signature: Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 03:dc:fc:87:b2:b8:bf:40:ae:3b:2b:e6:00:b3:65:f1:34:2d:d2:29:df: d3:0e:76:24:95:2f:c3:fd:c5:2c:0e:b6:d8:81:de:fe:f0:bd:54:7c:88: 17:48:9b:48:49:63:59:e3:81:b9:18:e8:30:42:c0:64:65:c2:c1:1b:b8: de:8d:8b:0d:1a:87:af:83:dc:5a:51:b4:b9:4b:60:1d:33:f1:6d:9a:5a: 53:0b:9e:21:90:81:66:0e:7b:7f:b6:61:96:e6:fb:02:0f:80:8d:e3:b2: 6c:58:f7:15:8a:83:07:b4:d8:a9:62:60:02:cf:fb:83:95:9f:34:45:40: 13:07
-----BEGIN CERTIFICATE----MIIDlDCCAv2gAwIBAgIBGTANBgkqhkiG9w0BAQUFADBcMQswCQYDVQQGEwJVUzEY MBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTEXMBUGA1UEAxMOTWVkIEVtYWlsIENBLTEwHhcNOTgwODAyMTgwNjM0WhcN MDAwODAyMTgwNjM0WjCBmTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292 ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxDTALBgNVBAsTBFVT QUYxIDAeBgNVBAMTF0d1bWJ5Lkpvc2VwaC4wMDAwMDA1MDQ0MSMwIQYJKoZIhvcN AQkBFhRndW1ieUBjaXN0dy5zYWljLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAvU4LMoOnF9bmhHvxZz8wCc9eRJ0j4RB0SmVYoq9iPrSJBwROeuxuU8VS JBL/u+RB5t6UJVNjXFmB1wS0foxpOHFQBFWyvWmuOiRUNaRxTVCrO4eG+nmM/U89 DKAc9FV4bZ8dPE9PlK9oq0J8Y2DIKz1+gIeM1sTPMnDtFgfGyH8CAwEAAaOCASYw ggEiMBYGA1UdIAQPMA0wCwYJYIZIAWUCAQsDMB8GA1UdIwQYMBaAFJcrSHN/a+aN L5DK1NpJUIvX+bVnMB0GA1UdDgQWBBR50N97AxK0G6U17EP1iu38LiLTBzAOBgNV HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADCBqQYDVR0fBIGhMIGeMIGboIGYoIGV hoGSbGRhcDovL2RzLTEuY2hhbWIuZGlzYS5taWw6MzkwL2NuJTNkTWVkJTIwRW1h aWwlMjBDQSUyZDElMmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBH b3Zlcm5tZW50JTJjYyUzZFVTP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3QlM2Ji aW5hcnkwDQYJKoZIhvcNAQEFBQADgYEAA9z8h7K4v0CuOyvmALNl8TQt0inf0w52 JJUvw/3FLA622IHe/vC9VHyIF0ibSEljWeOBuRjoMELAZGXCwRu43o2LDRqHr4Pc WlG0uUtgHTPxbZpaUwueIZCBZg57f7Zhlub7Ag+AjeOybFj3FYqDB7TYqWJgAs/7 g5WfNEVAEwc= -----END CERTIFICATE-----
76
3. melléklet lista mintája
USA Védelmi Minisztérium (DoD) tanúsítvány visszahívási
Certificate Revocation List: Data: Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: CN=Med CA-1, OU=PKI, OU=DoD, O=U.S. Government, C=US This Update: Wed Jul 15 13:35:31 1998 Next Update: Wed Aug 12 13:35:31 1998 Number of Revoked Certificates: 2 Revoked Certificates: Serial Number: 2 (0x2) Revoked On: Mon Jul 13 10:40:37 1998 Serial Number: 21 (0x15) Revoked On: Mon Jul 13 15:24:51 1998 Signature: Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 36:cf:b2:fc:d2:8f:76:9e:45:7e:02:cf:d1:27:6f:41:62:30:3c:6b:e4:4b: 10:f5:7f:69:31:4a:c1:4b:43:cf:f1:8b:6a:d6:65:64:56:40:00:33:21:b5: ec:a8:50:f8:7e:f7:36:ce:76:c8:96:aa:f3:a8:cf:f2:a8:87:c7:48:58:bd: e6:ec:e4:ed:69:1a:24:b4:a6:e9:40:1c:91:b7:c3:f3:10:04:f6:f4:17:67: 5c:87:13:e5:f5:fb:d6:b1:82:74:03:01:3f:91:3d:d5:37:27:1e:5d:ac:fc: c1:1c:22:19:5b:e8:4d:5d:5b:3c:f8:8b:fc:58:e7:5f:06:1a
-----BEGIN CRL----MIIBRTCBrzANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVU zEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEw NEb0QxDDAKBgNVBAsTA1BLSTERMA8GA1UEAxMITWVkIENBLTE XDTk4MDcxNTIwMzUzMVoXDTk4MDgxMjIwMzUzMVowKDASAgEC Fw05ODA3MTMxNzQwMzdaMBICARUXDTk4MDcxMzIyMjQ1MVowD QYJKoZIhvcNAQEFBQADgYEANs+y/NKPdp5FfgLP0SdvQWIwPG vkSxD1f2kxSsFLQ8/xi2rWZWRWQAAzIbXsqFD4fvc2znbIlqr zqM/yqIfHSFi95uzk7WkaJLSm6UAckbfD8xAE9vQXZ1yHE+X1 +9axgnQDAT+RPdU3Jx5drPzBHCIZW+hNXVs8+Iv8WOdfBho= -----END CRL-----
77
4. melléklet svéd szabvány
Elektronikus azonosító alkalmazások, az SS 61 43 30-as
Azonosító kártyák - Elektronikus azonosító alkalmazások az SS 61 43 30-as svéd szabvány 1998-09-14 0 Bevezető A kriptográfiai funkciókkal bíró mikroprocesszor alapú integrált áramköri kártyák (melyeket gyakorta intelligens kártyáknak vagy angolul smart card-nak hívnak) az információs rendszerek felhasználóinak biztonságos azonosítására, valamint más alapvető biztonsági szolgáltatásokra használhatóak, mint az elektronikus aláírásokkal biztosítható letagadhatatlanság, és a titkosító kulcsok bizalmas kiosztása. Jelen szabvány célja az ilyen szolgáltatásokhoz az IC kártya alkalmazásokra az előírások meghatározása a meglévő nemzetközi szabványok alapján. A fő célkitűzés olyan megoldást nyújtani, ami felhasználható a többféle kibocsátó kompatibilis kártyáit alkalmazó nagy rendszerekben, első sorban országos vonatkozásban, de feltételezve a nemzetközi cserét is. Ezért egy sor adatstruktúrát határoz meg a nyilvános kulcsú tanúsítási infrastruktúra és a PIN kódok rugalmas menedzselésének támogatásra. Ezen előírások felhasználáshoz néhány kiegészítő definíció szükséges. Az egyik fontos kérdés a tanúsítvány formátuma, amelyre a SIS (a Svéd Szabványügyi Szervezet) külön szabványt dolgozott ki. Továbbá vannak más paraméterek, melyeket a kibocsátó határozhat meg, vagy mint Svédországban egy Nemzeti Formátumban írják elő különböző típusú magán és kormányzati szervezetek megállapodása alapján bizonyos biztonsági paraméterekre, mint például a kulcsok hosszára vonatkozóan egy meghatározott időre.
1 Hatály A szabvány az integrált áramköri kártyával megvalósított elektronikus azonosító kártya (EID) alkalmazások könyvtárszerkezetét és adatfájl tartalmát írja le.
2 Normatív referenciák A következő szabványok tartalmazzák azokat a forrásokat, amely referenciákon ebben a szövegben a szabvány alapul. A közreadás idején a megadott kiadások voltak érvényesek. Minden szabvány felülvizsgálat tárgya, így azon felek akik ezen szabvány alapján egyeznek meg, vizsgálják meg az alább felsorolt szabványokat, hogy a legfrissebb kiadásokat alkalmazzák. EN 726-3:1994
Azonosító kártya rendszerek - Távközlési integrált áramköri kártyák és terminálok - 3. rész: Alkalmazás független kártyakövetelmények
ISO/IEC 7812-1:1993
Azonosító kártyák - Azonosító kibocsátók - 1. rész Számozási rendszer
ISO/IEC 7816-3:1997
Információtechnológia - Azonosító kártyák - Érintkezős integrált áramköri kártyák. 3. rész: Elektronikus jelek és átviteli protokollok. 78
ISO/IEC 7816-4:1995
Információtechnológia - Azonosító kártyák - Érintkezős integrált áramköri kártyák. 4. rész: A csere iparágak közötti parancsai.
ISO/IEC 7816-5:1994
Információtechnológia - Azonosító kártyák - Érintkezős integrált áramköri kártyák. 5. rész: Regisztrációs rendszer az IC kártyák
ISO/IEC 7816-6:1996
Információtechnológia - Azonosító kártyák - Érintkezős integrált áramköri kártyák. 6. rész: Iparágak közötti adatelemek.
ISO/IEC 8824:1988
Információtechnológia - Nyílt rendszerek összeköttetése - A jelölési szintaxisok meghatározásának első összefoglalója (Specificacion of Abstract Syntax Notation One - ASN.1)
ISO/IEC 8825-1:1995
Információtechnológia - ASN.1 kódolási szabályok: az alapvető kódolási szabályok (Basic Encoding Rules -BER) meghatározása, Canonical Encoding Rules (CER) és Distinguished Encoding Rules (DER)
RFC 1738
Uniform Resource Locator (URL)
3 Definíciók és rövidítések 3.1 Definíciók 3.1.1
azonosítás (identification): egy személy vagy tárgy azonosságát megerősítő folyamat.
3.1.2 digitális, (elektronikus) aláírás: adatok, melyek egy tanúsítvány vagy más információk csatolt részei, vagy kriptográfiai transzformációi és amelyek lehetővé teszik az adatok átvevőjének, hogy ellenőrizze az adategység forrását és sértetlenségét. A digitális aláírás véd a hamisítás ellen még az átvevőnél is. (ISO 7498-2) 3.1.3 elektronikus azonosító (ID) kártya (EID kártya): IC kártya privát kulccsal, tanúsítvánnyal és más információkkal, amelyet az információs rendszer vagy más alapvető biztonsági szolgáltatások felhasználójának megbízható azonosítására használnak. Ilyen szolgáltatás a azonosítás (autentikáció), a letagadhatatlanság biztosítása digitális aláírásokkal, és a titkosító kulcsok bizalmas kiosztása. 3.1.4 IC kártya: ID1 formátumú kártya, amely integrált áramkörös (Integrated Circuit) chipet tartalmaz az ISO/IEC 7816 szabvány 1-3 részeiben előírtaknak megfelelően. 3.1.5 azonosítás (autentikáció, authentication): egy állítólagos azonosság megállapításának folyamata. (ISO 10181-2) 3.1.6 tanúsítvány (certificate): egy felhasználó nyilvános kulcsa más információkkal együtt, melyet a kibocsátó tanúsító hatóság privát kulcsával kódoltak a hamisítás megakadályozására. (ISO 9594-8)) 3.1.7 üzenet kivonat (message digest, digitális lenyomat): Meghatározott hosszúságú adat, amely egy tetszőleges hosszúságú üzenet hash függvény számításával adódik. 3.2 Rövidítések AID
Application Identifier
79
ASN
Abstract Syntax Notation
ATR
Answer To Reset
AUF
Application Usage File
BCD
Binary Coded Decimal
CIF
Certificate Index File
DER
Distinguished Encoding Rules
DF
Dedicated File
DIR
Directory file
EID
Electronic Identification
EF
Elementary File
IC
Integrated Circuit
ICC
IC Card
MF
Master File
PAN
Primary Account Number
PIN
Personal Identification Number
PIX
Proprietary Application Identifier Extension
RID
Registered Application Provider Identifier
RSA
Rivest, Shamir, Adleman
SEIS
Secure Electronic Information in Society
URL
Uniform Resource Locator
4 A fő fájlkönyvtár tartalma 4.1 EFPAN (a kártya sorszám fájl) Ez a fájl kötelező minden EID kártyához. Tartalmaznia kell a kártya felületére nyomtatott IC kártya azonosító számot. Az IC kártya azonosító számát az ISO/IEC 7812-1 szerint kell beállítani és tárolni az adatobjektumban, a PAN, primary account number (tag '5A') pedig az ISO/IEC 7816-6 Annex A-ban definiáltak szerint. A struktúra az ISO7813 szerint, míg a kódolás az ISO 8583-ban van előírva. A PAN fájl kódolására egy példa a C mellékletben található. 4.2 EFPIN (a fő PIN fájl) Ez a kötelező fájl tartalmazza a fő PIN-t, amelyet a kártya minden alkalmazása használhat, az alkalmazás-szolgáltató választásától függően. A fájl formátuma kártyaspecifikus. 4.3 EFDIR (a könyvtár fájl) Ez a fálj az közvetett alkalmazás választásra használható, amint a következőkben (6.3. szakasz) ismertetésre kerül.
80
Ez a fájl kötelező, ha a kártya nem támogatja a 6.1 szakaszban ismertetett közvetlen alkalmazás választást. Ha van ilyen, a fájlnak az EN 726-3-ban meghatározottak szerint egy vagy több alkalmazás azonosítót (AID-t) kell tartalmaznia: Byte-ok Leírás
Hossz
1
Application ‘4F’
identifier
tag 1 byte
2
Application identifier length
1 byte
3
Application identifier
1-16 byte
Application label tag ‘50’
1 byte
Application label length
1 byte
Application label
0-16 byte
Path tag ‘51’
1 byte
Path length
1 byte
Path
n byte
(Second Application information)
Az alkalmazás azonosító (Application identifier) paraméternek tartalmaznia kell az AID teljes értékét, egészen 11 oktetig, amint azt az ISO 7816-5 meghatározza és az A mellékletben ismertetésre kerül. Az "Application label" paraméter ebben a szabványvában nincs meghatározva. A "Path" paraméternek a vonatkozó könyvtárig a teljes útvonalat kell tartalmaznia, amint azt az ISO 7816-5 előírja. A DIR fájl tartalmának kódolására egy példa a C mellékletben található.
5 Az EID alkalmazás könyvtár Ez a szakasz a DFEID EID alkalmazási könyvtár fájljait ismerteti. 5.1 EFAUF (Application Usage File, alkalmazás használati fájl) A kötelező alkalmazás használati fájl (AUF) információkat tartalmaz a kártyán rendelkezésre álló kulcsokról és PIN kódokról, mint a kulcs használat, PIN használati irányelvek és a vonatkozó fájlok útvonalai. Ezt a fájlt a számítógépes alkalmazásoknak olvasnia kell, hogy meghatározhassák, hogyan használják a kártya biztonsági szolgáltatásait. Az AUF struktúrája és tartalma a 7. részben kerül ismertetésre. Az AUF fájl tartalmának kódolásra egy példa a C mellékletben található. 5.2 EFPrK (Private RSA key file, privát RSA kulcs fájl) A kártányak egy vagy több RSA kulcsú fájlt kell tartalmaznia. Ezen fájlok formátuma kártyaspecifikus. 5.3 EFCIF (Certificate Index file, tanúsítvány index fájl) Mindenegyes EFPrK fáljra kell lennie egy tanúsítvány index fájlnak, amely a nyilvános kulcsokhoz tartozó tanúsítványokhoz tartozó mutatók listáját tartalmazza. Ilyen mutató lehet 81
egy fájl útvonala a tanúsítványt tartalmazó fájlhoz a kártyán, vagy egy URL formájú külső hivatkozás, amely egy tanúsítványra mutat. A tanúsítvány index fájl tartalmának részletei a 8. szakaszban vannak leírva. 5.4 EFCERT (Certificate file, tanúsítvány fájl) Mindenegyes EFPrK fáljra kell lennie egy vagy több tanúsítvány fájlnak a kártyán. A tanúsítvány fájl vagy egy X.509-es tanúsítványt tartalmazhat, teljesen üres lehet, vagy bináris nullákkal van feltöltve.
6 EID alkalmazási szakasz 6.1 AID az EID alkalmazáshoz Az (AID) alkalmazás azonosító adatelem 5-16 byte-ból áll, tartalmát az A melléklet írja elő. Az AID, használatos a DFEID fájl neveként, hogy támogassa az EID alkalmazás kiválasztását a több alkalmazást tartalmazó kártyákon. A következő két módszer van az EID alkalmazás kiválasztására: 1. Közvetlen alkalmazásválasztás. 2. Közvetett alkalmazásválasztás. Az EID kártya a fentiek közül az egyiket, vagy mindkettőt támogathatja. A közvetlen alkalmazásválasztás a kedvezőbb módszer és ezt támogatja a legtöbb IC kártya. A közvetett alkalmazásválasztás a DIR fájlt használja, amely kötelező, amennyiben a kártya nem támogatja a közvetlen alkalmazásválasztást. Ekkor az AID adatelemnek szerepelnie kell a DIR fájlban. 6.2 Közvetlen alkalmazásválasztás Célszerűen az IC kártyának támogatnia kell a közvetlen alkalmazásválasztást, amint azt az ISO/IEC 7816-4, 9.3.2 alzáradék és az ISO/IEC 7816-5, 6.3.1 alzáradék előírják. Ebben az esetben a teljes AID a "Select File" parancs paramétereként használatos. Az IC kártya operációs rendszerének nyilván kell tartania a pillanatnyilag kiválasztott alkalmazást, és csak azokat a parancsokat engedélyezheti, amelyek a kiválasztott alkalmazáshoz használhatóak. 6.3 Közvetett alkalmazásválasztás Az EID kártyák támogathatják a DIR fájl használatával is az alkalmazásválasztást az ISO/IEC 7816-5, 6.3.2 alzáradékban és az EN 726-3-ban előírtak szerint.
7 Alkalmazás használati fájl Minden EID kártyán kell lennie egy alkalmazás használati fájlnak (AUF), amely leírja a kártya EID alkalmazásainak jellemzőit. Röviden, ez a fájl tartalmazza a rendelkezésre álló privát kulcsok és a kulcsokat védő PIN kódok könyvtárát. Információt tartalmazhat egy vagy több a tulajdonos által aláírt CA tanúsítványról (gyökér tanúsítvány, root certificate) is. Ezt a fájlt el kell olvasnia a számítógépes alkalmazásoknak, ahhoz, hogy meghatározzák, hogyan hajtsák végre a kártya biztonsági szolgáltatásait. Biztonsági okokból az AUF fájlt csak a kártyakibocsátó frissítheti.
82
Az AUF struktúráját és tartalmát az ASN.1 definiálja, miként az ISO 8824 meghatározza. A fájlt DER kódokkal titkosítani kell az ISO 8825-1-nek megfelelően. Az AUF fájl komplett kódolási példája a C mellékletben van. 7.1 Közös adattípusok Version ::= INTEGER { v1(1) } Számos adatstruktúra tartalmazza a változat számot, a kompatibilitás biztosítására ezen szabvány jövőbeni felülvizsgálataival. Jelen szabvány változathoz ennek értéke 1. A jövőben a változat számnak növekednie kell, bármely változatást végeznek a formátumon. A jövőbeni változtatásokat, amennyiben lehetséges, új típusok hozzáadásával egy SEQUENCE végéhez, a számozott típusokra új típusok bevezetésével, miközben megtartják a régi típus szemantikáját, és a BIT STRING-ekbe új flag-ek bevezetésével, miközben megtartják a régieket. A Path típust a ISO 7816-5 határozza meg, és mind a DIR fájlban, mind az alkalmazás használati fájlban és a tanúsítvány index fájlban is használják a kiválasztandó fájl azonosítására. Az elérési útvonal (path) definíciója a ISO 7816-4, 5.1.2 "File referencing methods" alzáradékában található. Az elérési útvonal abszolút vagy relatív lehet. Az abszolút elérési útvonal a fenntartott (3F00) MF fájl azonosítóval kezdődik. Amennyiben az elérési útvonal bármely más azonosítóval kezdődik, az azt jelenti, hogy az relatív elérési útvonal. Jelen meghatározás vonatkozásban a relatív elérési útvonal mindig az EID könyvtárhoz viszonyított. Az ISO 7816-4 alapján a relatív elérési útvonal az EID DF azonosítójával kell kezdődjön, vagy a fenntartott 3FFF azonosítóval. Label ::=
BMPString
83
A Label típusú adatmező tartalmazza egy PIN logikai nevét, kulcsot vagy tanúsítványt, amelyet a kártya használója megjeleníthet. 7.2 Az AUF fálj tartalma Az AUF fájl tartalma a következők szerint definiált: AUFContent ::= SEQUENCE { version Version, pins Pins, keys Keys, caCerificates [0]IMPLICIT CACertificates OPTIONAL } A verzió szám v1 jelen szabvány változathoz. A pins mező az EID alkalmazások által használt PIN kódokról tartalmaz információkat. A keys mező tartalmazza az EID alkalmazásokban rendelkezésre álló privát és nyilvános kulcsos tanúsítványokról az információkat. A caCertificates mező tartalmazza tanúsítványokról az információkat.
az
EID
alkalmazásokban
rendelkezésre
CA
Mindhárom mező részletesen ismertetésre kerül a következő szakaszokban. 7.3 PIN információk A PIN információk adatstruktúrája a kártya PIN kódjairól tartalmaz információt. A következők szerint definiált: Pins ::= SEQUENCE { version Version, pinSequence SEQUENCE OF PinInfo } A verzió szám v1 jelen szabvány változathoz. Minden elem a pinSequence -ben egyetlen PIN -ről tartalmaz információt. A PIN1 az első elem a sorozatban (sequence). PIN2 a második, stb. Egy meghatározott PIN kódról az információ a következőképpen definiálható: PinInfo ::= SEQUENCE { pinLabel Label, format PinFormat, pinFlags PinInfoFlags, path Path, refNr INTEGER policy [0] IMPLICIT PinPolicy OPTIONAL} PinInfoFlags ::= BIT STRING { local (0), change-disabled (1), unblock-disabled (2) }
84
A format mező írja le, hogy a kártyán a PIN miként van kódolva. A részletek az alábbiakban következő 7.3.1-es szakaszban vannak megadva. A pinFlags mező kiegészítő információkat tartalmaz a PIN -ről. A részletek az alábbiakban következő 7.3.2-es szakaszban vannak megadva. A path mező tartalmazza az elérési utat a DF-hez, amely az aktuális PIN fájlt tartalmazza. A z elérési utat egy a számítógépen futó alkalmazásnak ki kell választania, mielőtt elvégzi a PIN műveleteket (ellenőrzés, változtatás vagy a tiltás feloldása). Ez szükséges, hogy a PIN művelet pontos megfelelőségét beállítsa. A refNr mező tartalmazza a kártyatípus speciális PIN referencia számát. Ez a szám amit a PIN azonosításra használnak az ellenőrzési, változtatási vagy tiltás feloldási parancsban, amit a kártyára küldenek. A referencia szám tipikusan egy PIN szám, például 1 vagy 2 a PIN1 vagy PIN2 kiválasztására. Amennyiben a kártya nem használ PIN referencia számot, a refNr mezőt nullra kell állítani. 7.3.1 PIN formátum Együttműködési okokból fontosak a részletek arról, miként van a PIN formálva. A formátum információ az alábbiak szerint definiált: PinFormat ::= SEQUENCE { encoding PinEncoding, formatFlags PinFormatFlags } PinEncoding ::= INTEGER { bcd (0), iso-8859-1 (1)} PinFormatFlags ::= BIT STRING { case-sensitive (0), pad-with-one (1) } Az encoding mező a PIN kódolásához használt karakterkészletet határozza meg. Az alábbi karakterkészletek definiáltak jelen szabványban (ezek kiterjeszthetők a jövőben): Kódolás
Leírás
bcd
Binary coded decimal. A byte minden nibble-je a PIN egy számjegyét tartalmazza. Ez a kódolás önmagában meghatározza a PIN irányelv követelményt, miszerint a PIN tisztán numerikus kell legyen. Ennek tükröződnie kell az EID alkalmazás használati fájl pinPolicy mezőjében.
iso-8859-1 Minden karakter nyolc bites, amint azt az ISO 8859-1 definiálja. Ez a legszélesebb körűen elterjedt karakter készlet
A számítógépes alkalmazásnak kell a kódolás szükséges konverzióját elvégeznie, amint azt a kártya kódolási mezője meghatározza. Például, ha a kódolást az ISO 8859-1 definiálja, és a számítógépes alkalmazás más karakterkészletben adja a bemenetre az adatokat, át kell konvertálnia az adatokat ISO 8859-1-be, mielőtt azokat a kártyára küldi. A formatFlags mező jelentése a következő:
85
Flag
Leírás
casesensitive
Ha be van állítva, a PIN-t a pontosan a beadott karakterekkel tárolja. Ha üres, a PIN-t mindig nagybetüs formában tárolja. Ez a flag lényegtelen ha a PIN tisztán numerikus.
pad-withone
Ha be van állítva a PIN kódot bináris ‘1’ -esekkel egészíti ki a maximális hosszra., mielőtt a kártyára küldené. Ha a flag üres a PIN-t bináris ‘0’.-kkal tölti ki.
7.3.2 PIN flag-ek A PinInfoFlags mező jelentése a következő: Flag
Leírás
local
Ha be van állítva a PIN helyi, máskülönben globális.
changedisabled
Ha be van állítva nem megengedett a PIN változtatása. Máskülönben a PÉIN megváltoztatható. Ez a flag kell tükrözze, miként vannak az aktuális PIN hozzáférési jogok beállítva a speciális kártya típusra.
unblockdisabled
Ha be van állítva nem megengedett a PIN tiltásának feloldása. Máskülönben a PIN tiltásának feloldása megengedett. Ez a flag ugyancsak azt mutatja meg, hogy a PIN kódok az aktuális időben miként vannak beállítva a kártyán.
Két dologra van hatással, ha a PIN lokális vagy globális: 1. Az ellenőrzés (verification) élettartama. A globális azt jelenti, hogy az ellenőrzési folyamaton sikeresen átesett PIN egészen addig érvényben marad, míg a kártya az olvasóban van, vagy nem reset-elik, vagy amíg egy új ellenőrzés során ugyanaz a PIN ki nem esik. Egy alkalmazás, amely egy globális PIN-t ellenőrzött, feltételezheti, hogy a PIN érvényben marad, bár más alkalmazások ellenőrzik saját PIN kódjaikat, kiválasztanak egy másik DF-eket, stb. A lokális PIN esetében az élettartam ellenőrzése nem garantált és szükséges lehet az újra ellenőrzés minden használat alkalmával. 2. Láthatóság. A globális PIN más, nem EID alkalmazásokhoz is rendelkezésre áll, míg a lokális. PIN csak az EID alkalmazásokban használható az adatok védelmére. A lokális vagy globális PIN aktuális telepítésének módja minden kártyatípusonként külön meghatározott. Egy tipikus telepítés az, mikor a globális PIN egy PIN fájl az MF-ben, míg a lokális PIN kódokat az EID DF-ben tárolják. A globális PIN bizonyos telepítései a kártyatípusra is különleges követelményeket állítanak, előírva, hogy miként lehet a kártyára kiegészítő alkalmazásokat telepíteni a PIN globális funkciójának tönkretétele nélkül. Például, ha egy kártyára az MF-ben PIN1-ként globális PIN-t telepítettek, akkor egy másik alkalmazás DF-jében nem lehet PIN1, hiszen ez utóbbi DF kiválasztásával a DF-ben a PIN1 ellenőrzési státuszát tönkre tenné. Amennyiben egy PIN globális és ennek következtében az EID és más alkalmazások is használhatják, a más alkalmazásoknak el kell fogadniuk az előírásokban rögzítettek szerint a PIN formátum és használati irányelveit. Ez különösen akkor fontos, ha a más alkalmazások a 86
PIN-t megváltoztatják vagy megszüntetik a tiltását. Az EID alkalmazás "tulajdona" a PIN és ez határozza meg a formátumát és használati irányelveit, azonban más alkalmazásoknak megengedett a használata. 7.3.3 PIN irányelvek A rögzített PIN-re az opcionális irányelvek kiegészítő követelményeket határozhatnak meg. Amennyiben ilyen nincs, az EID alkalmazások nem támasztanak a PIN-re különleges követelményeket. Az irányelvek leírása az alábbiak szerint definiálható: PinPolicy ::= SEQUENCE { allowedChars [0] IMPLICIT CharSet OPTIONAL, INTEGER OPTIONAL }
minLength [1] IMPLICIT
CharSet ::= INTEGER { digits(0) } Az allowedChars mező meghatározza a PIN-be írható megengedett karaktereket. Amennyiben ez a mező hiányzik az EID alkalmazásnak nincsenek követelményei (bár a számítógépes alkalmazásnak lehetnek különleges követelményei). A lehetséges megengedett karakter készlet az alábbi (ezek kiterjeszthetők a jövőben): Karakter készlet
Leírás
számjegyek
A karakterek „0„-„9„
A miniLength mező, amennyiben van ilyen a PIN kódban megengedett minimális karakterek számát tartalmazza. Amennyiben ez a mező hiányzik az EID alkalmazásnak nincsenek követelményei a minimális hosszra (bár a számítógépes alkalmazásnak lehetnek különleges követelményei). A allowedChars vagy a miniLength mezők közül legalább egynek meg kell lennie. Amennyiben egyik sem fontos a teljes PIN irányelveket el kell hagyni. 7.4 Kulcs információk A kulcs információ adatstruktúra információkat tartalmaz a kártyán lévő privát kulcsokról és a hozzájuk tartozó nyilvános kulcsokról. Az adatstruktúra az alábbiak szerint definiált: Keys ::= SEQUENCE { version Version, keySequence SEQUENCE OF KeyInfo } A verzió szám v1 jelen szabvány változathoz. A keySequence minden egyes eleme a kártya egyetlen privát kulcsáról tartalmaz információt. A kártyán több privát kulcs is lehet ugyanazon kulcs használattal. Az információ az adott privát kulcsról az alábbiak szerint definiált: KeyInfo ::= SEQUENCE { keyLabel Label, keyUsage KeyUsage, keyPath Path, subjectKeyHash OCTET STRING, certIndex Path, 87
keyType KeyType, keyParams ANY DEFINED BY keyType, pinNr INTEGER, keyIndex [1] IMPLICIT INTEGER OPTIONAL} KeyUsage ::= BIT STRING { digitalSignature (0), nonRepudiation (1), keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7) decipherOnly (8) } KeyType ::= INTEGER { rsa(0) } RsaKeyParams ::= SEQUENCE { modulusSize INTEGER } A keyUsages paraméter a privát kulcs korlátozott használatát definiálja. A paraméter egy vagy több kulcs használati bit-et tartalmazhat az alábbiakban definiáltak szerint. A privát kulcs megadott használata engedélyezett csak. A beállításnak azonosnak kell lennie a kártyán tárolt bármely csatolt nyilvános kulcs tanúsítvány KeyUsage kiterjesztésével. A digitalSignature bit-et be kell állítani, ha a privát kulcs digitális aláírások képzésére más célokra is használható, mint a letagadhatatlanság (nonRepudiation), ellenőrző aláírás (cRLSign) és kulcs tanúsítás (keyCertSign), például rövid élettartamú üzenetek hitelesítése céljából. A nonRepudiation bit-et be kell állítani, ha a privát kulcs letagadhatatlanság céljából üzenetek aláírására használható, amely megvéd, hogy az aláíró személy hamisan elutasítson valamely tevékenységet (kivéve a cRLSign és a keyCertSign-ban definiált használatot). Az ilyen kulcsot használó letagadhatatlanság szolgáltatás megkülönböztetett tulajdonsága az, hogy megköveteli a végaláíró személytől az aláírt üzenet tartalmának tudatos elfogadását. A keyEnciphernment bit-et be kell állítani, amennyiben a privát kulcs használható a kulcsok továbbításakor kriptográfiai kulcsokat tartalmazó adatok dekódolására. A dataEnciphernment bit-et be kell állítani, amennyiben a privát kulcs más, nem kriptográfiai kulcs adatok dekódolására használható. A keyAgreement bit-et be kell állítani, amennyiben a privát kulcs használható a kulcs megállapodásokra. A keyCertSign bit-et be kell állítani, amennyiben a privát kulcs aláírás készítésére használható a CA tanúsítványokon. A cRLSign -t be kell állítani, amennyiben a privát kulcs aláírás készítésére használható a CA visszavonási információin.(pl. egy CRL). Az encipherOnly és a decipherOnly bit-ek használata jelen szabványban nincs definiálva. A keyPath mező meghatározza a privát kulcsot tartalmazó fájl elérési útvonalát. Ezt a fájlt a számítógép alkalmazásnak kell kiválasztania, mielőtt kriptográfiai számítást végezne a kulccsal. A subjectKeyHash egyértelműen meghatározza a privát kulcshoz kapcsolt nyilvános kulcsot. A subjectkey azonosító értéke 01000 értékkel kezdődő négy bit típusú mező, melyet a 88
legjellemzőbb 60 bit-je követ az SHA-1 hash-nek, melynek értéke a BIT STRING subjectPublicKey (kivéve a tag-et, a hosszat és a felhasználatlan bit-ek számának indikátorát). Egy példa arra, hogy mit kell bele venni a hash számításba a C mellékletben látható. Ennek a paraméternek néha ugyanaz az értéke lesz, mint az X.509-es tanúsítvány subjectkeyIdentifier kiterjesztésének, ami ugyanehhez a privát kulcshoz tartozik. Ugyanakkor egy tanúsítvány kibocsátó a subject key identifier-t másképp is kiszámíthatja. A számítógépes alkalmazásnak ezért a subject key hash értékét a tanúsítvány nyilvános kulcsából kell kiszámítania, hogy megtalálja a hozzá tartozó igazi privát kulcsot. A certIndex mező az elérési utat határozza meg a CIF fájlhoz, amely hivatkozási mutatóeket tartalmaz a hozzá tartozó nyilvános kulcs tanúsítványokhoz. A keyType mező a privát kulcs típusát határozza meg, és a keyParam mező specifikus információkat tartalmaz a kulcs típusról. A következő kulcs típusok vannak: Kulcs típus
Leírás
rsa
Egy RSA privát kulcs. A keyParams mező RsaKeyParam típusú. Ez tartalmazza a kulcs modulus méretét bit-ekben, például 512, 768 vagy 1024.
A pinNr mező azonosítja a PIN-t védő kulcsot. Ez hivatkozás az AUF fájl PIN adatainak struktúrájában lévő szekvencia számokra. Az egyes pinNr érték vonatkozik az első PinInfo-ra a PIN-ek szekvenciájában, stb. A zéró pinNr érték azt jelenti, hogy a kulcsnak nincs szüksége PIN-re. Az opcionális keyIndex paraméter a kulcs index számát határozza meg, ha ugyanabban a fájlban több kulcsot tárolnak. A keyIndex szemantikája és kódolása kártyafüggő. 7.5 CA tanúsítvány információ A kártya kibocsátó annak érdekében, hogy a kártya használóját elássa egy vagy több minősített CA tanúsítvánnyal (root certificates) ezeket a tanúsítványokat a kártyán tárolhatja. A CA tanúsítványokat a kártya használó például a minősített alkalmazásokban más tanúsítványok vagy tanúsítvány láncok ellenőrzésére használhatja fel. A CA tanúsítványok a kártyán NEM használhatók fel a kártya használó tanúsítványainak ellenőrzésére. Az opcionális CA tanúsítvány információ adatstruktúrája a következők szerint definiált: CACertificates ::= SEQUENCE { version Version, caInfo SEQUENCE OF CAInfo } CAInfo ::= SEQUENCE { caCertLabel Label, caDN Name, caKeyUsage KeyUsage, caCertPath Path, caKeyIdentifier OCTET STRING} A verzió szám v1 jelen szabvány változathoz. A caDN paraméter tartalmazza a kibocsátó megkülönböztetett nevét (Distinguished Name), úgy ahogyan a tanúsítványban szerepel.
89
A caKeyUsage paraméternek azonosnak kell lennie a KeyUsage kiterjesztéssel a tanúsítványban. Az értéke keyCertSign és cRLSign lehet. A caCertpath mező tartalmazza a teljes elérési útvonalát egy fájlnak, amely egy teljes saját aláírású CA tanúsítványt tartalmaz. A caKeyIdentifier egyértelműen azonosítja a CA nyilvános kulcsot. Ezen paraméter értékének ugyanannak kell lennie, mint a CA tanúsítvány subjectKeyIdentifier kiterjesztésének, valamint az authorityKeyIdentifier kiterjesztésnek a tanúsítványban, melyet ez a CA írt alá.
8 Tanúsítvány fájlok Minden privát kulcshoz a kártyán az AUF fájlban van egy mutató egy Certificate Index File (CIF)-hoz. A CIF fájl címkéket és mutatókat tartalmaz, és vagy a kártyán vagy külsőleg tárolják. Így a kártyán tárolt tanúsítványok számát csak a kártyán rendelkezésre álló szabad terület korlátozza, és a külsőleg tárolt tanúsítványok számát csak a CIF fájlban rendelkezésre álló szabad terület korlátozza. A CIF fálj és a tanúsítvány fájlok természetesen a felhasználó által frissíthetők kell legyenek aPIN ellenőrzést követően. A CIF fájl tartalma a következők szerint definiált: CIFContent ::= SEQUENCE { version Version, certificates SEQUENCE OF CertIndex} CertIndex ::= SEQUENCE { certLabel Label, certPointer Pointer} Pointer ::= certPath certURL
CHOICE { Path, IA5STRING}
A verzió szám v1 jelen szabvány változathoz. A certLabel mező tartalmazza a tanúsítvány logikai nevét, amelyet a kártya használója megjeleníthet. A certPath mező meghatározza az elérési utat a tanúsítvány fájlhoz, amely a teljes X.509 V3as tanúsítványt tartalmazza. A certURL mező tartalmazza a Uniform Resource Locator (URL)-t, amint az RFC 1738-ban specifikált. Ez egy tanúsítvány e tárgyban kibocsátott konténerére mutat. A certURL-nek egy abszolút, nem relatív útvonal névnek kell lennie és egy számítógépet kell meghatároznia. Ez a szabvány a következő értékeket ismeri el URL sémában: ftp, http, ldap, és fájl hozzáférés. Az URL használat példái: ftp://ftp.seis.se/hnn.cer http://www.seis.se/hnn.cer ldap://ldap.seis.se file://C:\mycerts\hnn.cer file:///C|/mycerts/hnn.cer
90
A. melléklet - Alkalmazási és fájl azonosítók (normatívák) A.1 Alkalmazás azonosító (AID) Az AID RID || PIX -ből áll, ahol || a konkatenációt jelöli. A RID 5 byte regisztrált azonosító amint az ISO/IEC 7816-5 definiálja. A RID-et A000000037 -re kell beállítani. A PIX (Proprietary application Identifier eXtension) egyenlő ‘EID-xx’, ahol xx az EID szabvány verzió számát jelenti decimális formában. Erre a szabványra az értéke ‘02’. Így ebben a szabványban a teljes AID A0 00 00 00 37 45 49 44 2D 30 32. A.2 Fájl azonosítók A fájl azonosítókat a fő (master) fájlban (MF, path '3F00'h) az alábbi táblázat szerint kell elhelyezni. Fájlnév
Fájl azonosító
EFPAN
‘1000’h
DIR
‘2F00’h
Az EID alkalmazás könyvtárban csak az alkalmazás használati fájlt kell fájl azonosítóval elhelyezni az alábbi táblázatnak megfelelően: Fájlnév EFAUF
Fájl azonosító ‘1003’h
91
B. melléklet - Példa egy EID alkalmazási fájl struktúrára (tájékoztató) B.1 Általános megjegyzések Ez a tájékoztató melléklet egy példát ad egy EID megvalósításra a jelen szabványban meghatározott fájl struktúra alkalamzásával. B.2 Definíciók Ez a tájékoztató melléklet a következő, az ISO/IEC 7816-4 -ben definiált terminológiákat használja, a megfelelő rövidítéseikkel: DF
dedikált fájl (lásd ISO/IEC 7816-4)
EF
elemi fájl (lásd ISO/IEC 7816-4)
MF
fő, master fájl (lásd ISO/IEC 7816-4)
B.3 Egy EID logikai modellje Az EID adatok logikai szervezése az 1. ábrán látható: MF
DFAPPL
DFEID
EFPAN
EFAUF
EFPIN
EFCERT
EFDIR
EFPrK
EFATR
B.1 ábra Egy EID fájl struktúrája
92
B.4 Közös adatfájlok A kártya közös adatfájljai következő célokra lehetnek hasznosak: EFPAN Ez az elemi fájl tartalmazza az ICC sorozatszámát. EFPIN Ez a fájl tartalmazza a kártya fő PIN-jét, ami egy vagy több alkalmazáshoz használható. EFDIR Ez az elemi fájl tartalmazhatja az EID alkalmazás azonosítót. B.5 Alkalmazásfüggő fájlok B.5.1 DFEID (dedikált EID fájl) Ez a fájl kötelező a több alkalmazású kártyákhoz és opcionális az egy alkalmazású kártyák esetében, amint az A.1 táblázatban definiált az EID alkalmazások szülő fájlja (minden EF, amik szükségesek az EID alkalmazás végrehajtásában). File ID
Card issuer dependent
File type
Dedicated file
File name
AIDEID
B.1 táblázat: DFEID (dedikált EID fájl)
B.5.2 Elemi EID fájlok Az EFAUF EID alkalmazás használati fájlok leírása a 7. szakaszban található. Az EFPrK kártyaspecifikus elemi fájl formája és tartalma nincs definiálva ebben a szabványban. Az EFCERT tartalma a 8. szakaszban van leírva. A fájl azonosítókat az A. melléklet szerint kell beállítani.
93
C. melléklet Az EID specifikus fájlinformációk kódolása (informatív példák) C.1 Az AUF fájl kódolása Az alábbi példák az alkalmazás használati fájl kódolására mutatnak példákat, két kulcsos és két PIN kódos kártya esetén. A PIN2 jelű PIN használható kizárólagosan a letagadhatatlanságra és nem szabad a blokkolást megszüntetni. C.1 Az AUF fájl kódolása 30 81 FD 02 01 01 30 42 02 01 01 30 3D 30 1B 30 07 02 01 01 03 02 06 C0 03 01 00 51 02 3F 00 02 01 01 A0 06 80 01 00 81 01 05 30 1E 30 07 02 01 01 03 02 06 C0 03 02 05 A0 51 04 3F 00 03 04 02 01 02 A0 06 80 01 00 81 01 05 30 81 B4 02 01 01 30 81 AE 30 38 1E 0C 00 03 02 51 06 3F 04 08 40 51 06 3F 02 01 30 04 02
41 00 55 00 54 07 80 00 03 04 53 31 11 22 33 44 55 00 03 04 43 31 00 02 04 00
------------------
SEQUENCE Version 1 SEQUENCE Pins Version 1 SEQUENCE OF PinInfo SEQUENCE PinInfo #1 SEQUENCE PinFormat PinEncoding: ISO 8859 PinFormatFlags: case-sensitive, pad-with-one PinInfoFlags: global, changeable, unblock OK Path: MF RefNr PIN1 PinPolicy charset, digits min length, 5 characters
--SEQUENCE PinInfo #2 -- SEQUENCE PinFormat -- PinEncoding: ISO 8859 -- PinFormatFlags: -- case-sensitive, pad-with-one -- PinInfoFlags: -- local, changeable, not unblock! -- Path: EID -- RefNr PIN2 -- PinPolicy -- charset, digits -- min length, 5 characters --SEQUENCE Keys -- Version 1 -- SEQUENCE OF KeyInfo -- SEQUENCE Key#1 -- BMPString: Key Label „AUTKEY„ 00 4B 00 45 00 59 –-- BIT STRING: Key Usage Authentication -- Key Path: -- Key1 -- OCTET STRING: Key Hash 66 77 -- Certificate Index Path: -- Cert1 -- Key type: RSA -- SEQUENCE Key Params -- 1024 bits
94
80 01 01 30 38 1E 0C 00 03 02 51 06 3F 04 08 40 51 06 3F 02 01 30 04 02 80 01 02 30 38 1E 0C 00 03 02 encipherment 51 06 3F 04 08 40 51 06 3F 02 01 30 04 02 80 01 01
-- pinNr: -- Pininfo#1
44 00 49 00 47 06 40 00 03 04 53 32 11 22 33 44 55 00 03 04 43 32 00 02 04 00
--00 --–-66 -–----
SEQUENCE Key#2 BMPString: Key Label „NONREP„ 53 00 49 00 47 –BIT STRING: Key Usage Nonrepudiation Key Path: Key2 OCTET STRING: Key Hash 77 Certificate index Path: Cert2 Key type: RSA SEQUENCE Key Params 1024 bits -- pinNr: -- Pininfo#2
--4B 00 45 00 59 00 05 20 --00 03 04 53 33 –-11 22 33 44 55 66 -00 03 04 43 33 –00 --02 04 00 --
SEQUENCE Key#3 BMPString: Key Label „KEYKEY„ 4B 00 45 00 59 BIT STRING: Key Usage Key
Key Path: Key3 OCTET STRING: Key Hash 77 Certificate Index Path: Cert3 Key type: RSA SEQUENCE Key Params 1024 bits -- pinNr: -- Pininfo#1
95
C.2
A DIR fájl kódolása
A következő példa mutatja a közvetett alkalmazás választásban használatos opcionális DIR fájl kódolását. 4F A0 50 51 3F
C.3
0B -- AID tag and length 00 00 00 37 45 49 44 2D 30 31 -- AID: A0 00 00 00 37 + „EID-01„ 00 -- Label tag and length 04 -- Path tag and length 00 03 04 -- 3F00 0304
A PAN fájl kódolása
A következő példa mutatja a kártya felületére kinyomtatott sorszámát tartalmazó kötelező PAN fájl kódolását. Minden szám a kártya sorszámban BCD számokkal kódolt, amelyben két számjegy van egy byte-ban. 5A 09 15 97 52 22 25 15 40 12 30
C.4
-- TAG for Primary Account Number -- Card number: 9752 2225 1540 123 -- preceded by decimal length field
A Subjct Key Hash érték számítása
A következő példa mutatja a Subject Public Key Info mezőt egy felhasználói tanúsítványban, ahol a subject key hash érték hash számításának kezdődnie és végződnie kell.
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 81 8D 00 -- Start hash computation here >>> 30 81 89 02 81 81 00 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07 02 03 01 00 01 -- Finish hash computation here <<<
--------
SubjectPublicKeyInfo: SEQUENCE SEQUENCE (AlgorithmIdentifier) OBJECT IDENTIFIER: rsaEncryption NULL (Parameter) BIT STRING (SubjectPublicKey)
--- modulus 08 09 0A 0B 0C 08 09 0A 0B 0C 08 09 0A 0B 0C 08 09 0A 0B 0C 08 09 0A 0B 0C 08 09 0A 0B 0C 08 09 0A 0B 0C 08 09 0A 0B 0C -- exponent
96
0D 0D 0D 0D 0D 0D 0D 0D
0E 0E 0E 0E 0E 0E 0E 0E
0F 0F 0F 0F 0F 0F 0F 0F
