DUNAÚJVÁROSI FŐISKOLA MÉRNÖK INFORMATIKUS BSC SZAKDOLGOZAT DIGITÁLIS ALÁÍRÁS MEGVALÓSÍTÁSA VÁLLALATI KÖRNYEZETBEN

Átírás

1 DUNAÚJVÁROSI FŐISKOLA MÉRNÖK INFORMATIKUS BSC SZAKDOLGOZAT DIGITÁLIS ALÁÍRÁS MEGVALÓSÍTÁSA VÁLLALATI KÖRNYEZETBEN Ravasz Csaba mérnök informatikus jelölt 2009

2 Összefoglalás Ma már természetes dolognak számít, hogy teendőink egy részét az Interneten keresztül intézzük, hiszen így sok esetben időt és pénz takaríthatunk meg magunknak. Ezért nem is csoda, hogy az elektronikus ügyintézési formák egyre négyszerűbbek, egyre többen veszik igénybe e megoldások kényelmes szolgáltatásait. A cégek is felismerték az ebben rejlő lehetőségeket és ezekre az igényekre támaszkodva megpróbálták saját érdekeiket is kiszolgáló módszereket kialakítani. Azonban ezek a megoldások csak bizonyos keretek között jöhettek létre, hiszen sok esetben szükséges az ügyfelek azonosítása vagy az általuk küldött adatok hitelesítése, amely elektronikus adatok esetén nehezen megoldható feladat. Erre a problémára kínál megoldást a digitális aláírás, amely a mai modern web-es technológiákkal karöltve lehetőséget kínál a teljesen elektronikus ügyintézés megvalósítására. Diplomamunkámban egy olyan elektronikus ügyintéző rendszer tervezésével és gyakorlati megvalósításának lehetőségeivel foglalkozom, amely megteremti a cégek számára az online szerződéskötést és az elektronikus számlázást. Célom a digitális aláírásban rejlő lehetőségek bemutatása, a céges ügyintézésben való jelentőségének ismertetése. Elsősorban azért válaszoltam ezt a témát, mert nagyon érdekelnek azok az elektronikus megoldások és web-es technológiák, amelyek életünket hivatottak megkönnyíteni. Dolgozatom első szakaszában bemutatom a digitális aláírás és az azzal kapcsolatos technológiákat, melyek a rendszer működésének megértéséhez szükségesek. A második részben felvázolom az általam elképzelt ügyintéző rendszert, annak felépítését és a működéséhez szükséges feltételeket. Ezután röviden bemutatom azt a céges környezetet, ahol az ügyintéző rendszert szeretnénk megvalósítani. A továbbiakban pedig ismertetem azokat a tényezőket, amelyek megteremtésével, lehetővé tettem a cég számára az online szerződéskötő rendszer Java platformon történő megvalósítását. 1

3 Summary Nowadays it is natural to do some of our tasks through the Internet, as in many cases we can save time and money in this way. There is no wonder that the electronic administration forms are becoming more and more popular, there are more and more people using these comfortable services. Companies have also realised the opportunities of this field, and, taking these claims into account, they tried to work out methods serving their own interests as well. However, these solutions could only work under certain circumstances, as in many cases it was necessary to identify the customers or to certify the data sent by them, which, in case of electronic data, is not easy to carry out. A solution for this problem is the digital signature, which, accompanied by today s modern web-technologies, offers a possibility for electronic administration. In my MA Thesis I deal with the planning and possible practical execution of an administration system that can offer companies the opportunity to sign their contracts and make their invoices online. My purpose is to introduce the possibilities of digital signature and their significance in company administration. I have chosen this topic mainly because I am highly interested in electronic solutions and web-technologies that make our lives easier. In the first part of my thesis I introduce the digital signature and the technologies in connection with it, which are necessary for understanding the system. In the second part I make an outline about the construction and working conditions of the administration system I planned. Then I briefly introduce the company environment in which it would be carried out. Finally, I list the factors I worked out to make the online contract-signing system available for the company on Java platform. 2

4 NYILATKOZAT a szakdolgozatról Alulírott Ravasz Csaba Mérnök Informatikus BSC. kijelentem, hogy Digitális aláírás megvalósítása vállalati környezetben (című) szakdolgozatomat (nyomtatott és elektronikus formában) a Dunaújvárosi Főiskola oktatói és hallgatói, szükség esetén más érdeklődők is felhasználhatják (pl. hivatkozás alapjául, olvasótermi használatra) későbbi munkájukhoz a szerzői jogok tiszteletben tartása mellett. Ugyanakkor kijelentem, hogy a szakdolgozat saját kutató munkám eredménye.... Ravasz Csaba Dunaújváros, május 6. 3

5 Tartalomjegyzék 1. Szakirodalmi összefoglaló Kriptográfiai bevezető Szimmetrikus kulcsú kriptográfia Aszimmetrikus kulcsú kriptográfia Hitelesítés aszimmetrikus kulcsú kódolással Lenyomat készítő függvények Nyílt kulcsú Infrastruktúra (PKI) A PKI bemutatása Regisztráló szervezet (Registration Authority - RA) Hitelesítés-szolgáltató (Certification Authority - CA) Tanúsítványtár (Certificate Directory) Visszavonási listák (Certificate Revocation List - CRL) Felhasználók A digitális aláírás Digitális aláírás a gyakorlatban A digitális aláírás jogi háttere A digitális aláírás típusai Digitális aláírással kapcsolatos fontosabb szabványok, ajánlások Egy digitális aláíráson alapuló ügyintéző rendszer tervezése Az ügyintéző rendszer feladatainak meghatározása Az Online szolgáltatók problémája Az érintett területek Az új ügyintéző rendszer feladatinak megállapítása Az ügyviteli rendszer felépítése és működése A szerződéskötő rendszer Elektronikus számlázó rendszer Az alrendszerek felépítése A szerződéskötő rendszer komponensei A számlázási rendszer komponensei Az ügyintéző rendszer komponensei Az ügyviteli rendszer működéséhez szükséges feltételek meghatározása A megvalósítás környezete A cég rövid bemutatása A jelenlegi ügyintézés A cég informatikai infrastruktúrája Az online szerződéskötő rendszer megvalósításának előkészítése A felhasznált eszközök A Sun Java platform Netbeans IDE Apache Tomcat A rendszer javasolt felépítése Az alkalmazás-szerver előkészítése A kiszolgáló jellemzői Az Apache Tomcat szerver telepítése A Java környezet konfigurálása

6 A Tomcat szerver konfigurálása A tanúsítványok előkészítése Az ügyintéző rendszerhez szükséges tanúsítványok beszerzése Tanúsítvány aláírási kérelmek (CSR) készítése A tanúsítványok megfelelő formátumra alakítása A rendszerhez szükséges külső tanúsítványok beszerzése Java kulcstárak létrehozása A komponensek megvalósítása Java környezetben A szükséges külső programkönyvtárak A szerver-kliens kapcsolat megvalósítása A szerződésdokumentum előállító komponens A szerződésmegjelenítő komponens A tanúsítványkezelő komponens A szerződés aláíró komponens Az aláírási formátum ellenőrző komponens A visszavonás ellenőrző komponens Az időbélyegző komponens A szerződés véglegesítő komponens A levélküldő ügynök komponens A kulcsárkezelő és a dokumentum elhelyező komponens A komponensek teszteléséhez felhasznált tesztkörnyezet Fejlesztési lehetőségek Összegzés Irodalomjegyzék Mellékletek

7 1. Szakirodalmi összefoglaló 1.1. Kriptográfiai bevezető Szimmetrikus kulcsú kriptográfia A kriptográfia történetében, egészen az 1970-es évekig, a kódoló eljárások az úgynevezett szimmetrikus kulcsú kriptográfián alapultak. Ennek lényege, hogy a kódoláshoz és a visszafejtéshez ugyanazt a kulcsot használták. Ezeket az eljárásokat a technológiai fejlődés során gépesítették, és tovább tökéletesítették, megnehezítve ezzel a kódfejtők dolgát. A lényeg az, hogy az eljárásnak annyira kell bonyolultnak lennie, hogy a mai ismert legjobb kódfejtő módszerek és az elérhető legjobb technológia alkalmazásával, a feltörés időtartama nagyobb legyen, mint hogy az a kódtörőnek megérje. 1. ábra Szimmetrikus kulcsú kódolás A szimmetrikus kulcsú kódolás működése a következő. Adott a kommunikáló felek által ismert E k kódoló, D k dekódoló algoritmus, és k kulcs. Az üzenet küldője x nyílt szöveget, E k algoritmussal, k kulcsot felhasználva kódolja, majd továbbítja az üzenet címzettjéhez. Az üzenet fogadója y kódolt üzenetet, k kulcsot felhasználva, D k dekódoló algoritmussal dekódolja.[1] A szimmetrikus kulcsú kódolás gyakorlati megvalósításainak két főbb típusa van, a blokk kódollók és a folyamkódolók. A blokk kódolók a kódolandó üzenetet adott méretű darabokra (általában 64 vagy 128 bit), blokkokra, bontják szét és ezeket kódolják. Ha az üzenetrészek nem érik el a kívánt hosszt, akkor az algoritmusnak gondoskodnia kell ezek megfelelő kiegészítéséről (padding). 2. ábra a blokk kódoló működése A folyamkódolók a folyamatában érkező üzenetet egységnyi szinten kódolják.[2] 6

8 3. ábra a folyamkódoló működése A szimmetrikus titkosítás mind a mai napig jól használható. Előnye, hogy a kulcsok relatíve kicsik, így a kódoló algoritmusok gyorsak, ezáltal alkalmas a valós idejű kódolásra. Azonban komoly gondot jelent a kulcsok biztonságos eljuttatása a partnerekhez, továbbá ezt nem elég egyszer megtenni, hanem meg kell oldani a kulcsok folyamatos cseréjét, mivel előbb vagy utóbb feltörhetik vagy megszerezhetik a kulcsot. Ennek kivitelezése a gyakorlatban nehéz, főleg ha egyszerre több kulcs cseréjét kell megoldani Aszimmetrikus kulcsú kriptográfia Az 1970-es évek közepén született meg a kriptográfia új utakat nyitó kódoló eljárása, az aszimmetrikus kulcsú kódolás. Az új típusú algoritmus lényege, hogy szemben a szimmetrikus kulcsú kódolással, nem egy kulcsot használ, hanem egy kulcspárt. Bármelyik kulccsal kódolt üzenet csak a másikkal fejthető vissza és fordítva. Így két kulcs szorosan összefügg egymással, azonban mégsem számolhatók ki egymásból. Továbbá a kódoló algoritmus a dekódoló algoritmusból való előállítása rendkívül bonyolult. 4. ábra aszimmetrikus kulcsú kódolás Az aszimmetrikus kulcsú kódolás működése a következő. Adott két személy, akik kódolt üzenetet szeretnének küldeni egymásnak. A küldő valamely kulcsát elküldi a címzettnek, vagy akár nyilvánosságra hozhatja. A küldő az E k1 kódoló eljárással, a címzett K 1 nyilvános kulcsát felhasználva, titkosítja x nyílt szöveget, majd elküldi a címzettnek. Az üzenet fogadója D k2 dekódoló algoritmust és K 2 titkos kulcsát felhasználva dekódolja y kódolt üzenetet, így megkapja x-et. Bárki küldhet titkos üzenetet bárkinek, ha a címzett nyilvános kulcsa elérhető. Az üzenetet csak a címzett tudja elolvasni, mivel csak ő rendelkezik a visszafejtéshez szükséges titkos kulccsal. [1] Az aszimmetrikus kulcsú titkosítás előnye, hogy nem jelent problémát a kulcsok kiosztása, hiszen az egyik kulcs nyilvános, bárki számára elérhető. Azonban ezek az algoritmusok 7

9 nagyobb kulcshosszal dolgoznak, ezért lassúak, és kevésbé alkalmasak hosszú üzenetek titkosítására Hitelesítés aszimmetrikus kulcsú kódolással Az aszimmetrikus kulcsú kriptográfia lehetővé teszi az úgynevezett nyilvános kulcsú rendszerek kialakítását. A rendszer felhasználói egy-egy kulcspárral rendelkeznek. A kulcspárokból az egyiket nyilvánossá, bárki számára elérhetővé tesszük, ez lesz a nyilvános kulcs, a másik kulcsot titkossá, ez pedig a titkos kulcs. Az így kialakított rendszer két felhasználási lehetőséget nyújt: Titkosítás: az üzenetküldés során az üzenet küldője a címzett nyilvános kulcsával titkosítja az üzenetet, amelyet a címzett saját titkos kulcsával visszafejthet. Az üzenet titkosítása a címzett nyilvános kulcsával történt, így a küldő biztos lehet, hogy az üzenetet csak a címzett tudja elolvasni, hiszen azt csak az ő birtokában lévő titkos kulccsal lehet visszafejteni. Hitelesítés: ebben az esetben a küldő, saját titkos kulcsával titkosítja az üzenetet, amelyet a címzett a feladó nyilvános kulcsával visszafejthet. Ebben az esetben a címzett bizonyosodhat meg az üzenet hitelességéről, hiszen a titkosításhoz használt titkos kulcs csak a feladó birtokában lehet. Ebben az esetben viszont az üzenet nem titkos, hiszen a nyilvános kulcs segítségével bárki elolvashatja. [16] Az utóbbi felhasználás jelentősége abban rejlik, hogy bár az aszimmetrikus kulcsú titkosítást nagyon nehéz feltörni, azonban nem lehetünk biztosak abban, hogy tényleg azzal váltunk üzeneteket, akivel eredetileg szerettünk volna. A probléma a követező. Adott A és B, két fél, akik titkosított üzeneteken keresztül szeretnének kommunikálni egymással. Továbbá adott T, egy támadó, aki tudni szeretné az üzentek tartalmát. A, a küldő, elküldi B-nek nyilvános kulcsát. Azonban T elkapja ezt az üzenetet és az A nyilvános kulcsa helyett, saját nyilvános kulcsát küldi tovább B felé. B azt hiszi, hogy A nyilvános kulcsát kapta meg. B a kapott nyilvános kulcsot felhasználva titkosított üzenetet küld A-nak. T úgyszintén elkapja ezt az üzenetet is és saját titkos kulcsával visszafejti azt, majd B nyilvános kulcsát használva, titkosítva továbbküldi az üzenetet A-nak. A és B nem is sejtik, hogy T közéjük épülve, minden üzenetet elolvas. Ezt a folyamatot nevezzük megszemélyesítésnek. Ezt a problémát valamilyen módon orvosolni kell, tehát valamilyen módot kell találni az üzenetküldő felek azonosítására. Erre megoldás az előbbiekben említett hitelesítési eljárás, melynek során az üzenet titkos kulccsal való titkosítását használjuk fel az üzenetküldő felek azonosítására. Ezt az eljárást nevezzük digitális aláírásnak. 8

10 Lenyomat készítő függvények Mivel az aszimmetrikus kulcsú titkosítás nagyon lassú és aláírás esetében nem is az üzenet titkosítása a cél, ezért nincs szükség arra, hogy az egész üzenetet kódoljuk. Ehelyett használhatunk egy olyan függvényt, amely az eredeti üzenetről egy lenyomatot készít. A függvények tulajdonságai a következők: A lenyomatot gyorsan állítják elő A lenyomatból semmilyen módon nem lehet következtetni az eredeti üzenetre A nincs két olyan üzenet, amely azonos lenyomatot generál A függvényre érvényes a lavina elv, azaz a bemeneten az üzenet egységnyi megváltozása is teljesen más kimenetet eredményez [3] A függvény által generált lenyomat, vagy hash, egy az üzenetből képzett fix hosszúságú bitsorozat. Ezt a lenyomatot felhasználhatjuk az üzenetváltó felek azonosításához. megszokott módon A és B egy üzenetváltás szereplői. A titkosított üzenetet küld B-nek. B viszont tudni szeretné, hogy A tényleg az, akinek mondja magát. Az eredeti aláírási eljárás csak annyiban módosult, hogy A az eredeti üzenet helyett, annak saját titkos kulcsával titkosítva lenyomatát küldi el B-nek. A lenyomat készítő függvény mindkettőjük számára ismert. B A nyilvános kulcsát felhasználva visszafejti a titkosított lenyomatot, majd saját maga is elkészíti az eredeti üzenet lenyomatát. Ha a kettő egyezik, akkor az üzenet küldője tényleg A. A lenyomatok az őket előállító függvényekkel gyorsan számolhatók, sokkal gyorsabban, mint amennyi idő szükséges a teljes üzenet aláírásához, így alkalmasak az aláírási folyamat gyorsítására. Azonban a megszemélyesítéses támadást még így sem lehet sikeresen kivédeni. Meg kell oldani a személyazonosság és a nyilvános kulcsok összerendelését. Ezt egy megbízható harmadik félnek (Third Trusted Party) kell biztosítani, aki igazolja, hogy a nyilvánosa kulcsok tényleg azokhoz tartoznak, akik üzenetet váltanak. Ezen felül meg kell oldani az esetleges kulcscserét, ha valamelyik fél titkos kulcsa rossz kezekbe kerül. Ezek és a többi nyilvános kulcsú rendszerek működésével kapcsolatos feladatok megoldását végző rendszer a Nyílt Kulcsú Infrastruktúra Nyílt kulcsú Infrastruktúra (PKI) A PKI bemutatása A nyílt kulcsú rendszerekben a megbízható működéséhez szükség van nyilvános kulcsok hitelesítésére. Ezt a nyilvános kulcsok és azok tulajdonosaira vonatkozó adatok ellenőrizhető módú összerendelésével, úgynevezett digitális tanúsítványok (Certificate) 9

11 kiadásával oldható meg. Ezen tanúsítványok kiadását, visszavonását, folyamatos menedzselését és használatát biztosító protokoll rendszert, az ezt biztosító hardver, szoftver eszközöket és intézményrendszert együttesen Nyílt Kulcsú Infrastruktúrának (Public Key Infrastructure) nevezzük. A PKI több szereplőből áll, ezek funkcionális szempontok szerint vannak felosztva. [4] 5. ábra a PKI szereplő is főbb folyamatai Regisztráló szervezet (Registration Authority - RA) Mielőtt egy felhasználó számára tanúsítvány állítanak ki, meg kell győződni annak személyazonosságáról, hogy a felhasználó nyilvános kulcsa hitelesen a felhasználóhoz köthető legyen. Ezt a funkciót az úgynevezett regisztráló szervezet (RA) látja el. Az RA tehát egy olyan szervezet, amely megbízható módon azonosítja azokat a felhasználókat, akik számára a hitelesítés-szolgáltatót (CA) a későbbiekben tanúsítvány bocsát ki, ezáltal megteremti a PKI működéséhez szükséges bizalmat. Egy CA-hoz több akkreditált RA is tartozhat.[5] Hitelesítés-szolgáltató (Certification Authority - CA) Ha regisztrálni kívánó felhasználó egyértelműen azonosítható, akkor az RA engedélyezi a tanúsítvány kiadását a hitelesítés-szolgáltatónak (CA). A CA egy olyan szervezet, amely a regisztrált felhasználók számára bocsát ki tanúsítványokat, és ezeket egy nyilvánosan 10

12 hozzáférhető tanúsítványtárban tárolja. Az itt szereplő tanúsítványokban a felhasználó adatai, nyilvános kulcsa, az arra vonatkozó adatok, és a tanúsítványra vonatkozó adatok szerepelnek, ezek formátumát az ITU X.509v3 szabvány írja le. CA-k szervezeteknek, magánszemélyeknek és más CA-knak is adhatnak ki tanúsítványt. A CA az általa kibocsájtott tanúsítványokat saját titkos kulcsával hitelesíti, és meghatározott időre bocsátja ki. [5] Tanúsítványtár (Certificate Directory) Hogy a nyílt kulcsú rendszer felhasználói egymás nyilvános kulcsait hitelesíteni tudják, a tanúsítványokat a rendszer felhasználói számára elérhető módon kell tárolni. Ezt a funkciót a tanúsítványtár (Certificate Directory) látja el. A tanúsítványtár egy olyan címtár, ami a CA kibocsájtott tanúsítványokat, visszavonási listákat tárolja és ezeket a nyilvánosság számára elérhetővé teszi. Ez célszerűen az X.509 az X.500-as szabvánnyal való kompatibilitása miatt egy LDAP címtár. [5] Visszavonási listák (Certificate Revocation List - CRL) Ha egy adott tanúsítvány lejár, vagy valamilyen oknál fogva kompromittálódik, a tanúsítványt érvényteleníteni kell és az érvénytelenítésről a regisztrált felhasználókat értesíteni kell. A CA az érvényüket vesztett tanúsítványokat a visszavonási lista(crl) segítségével tartja számon. A CRL-t tanúsítványként kezeljük, amely a visszavont tanúsítványok sorszámát, a kibocsátó nevét, digitális aláírását, a lista kiadásának időpontját és verziószámát tartalmazza. Ezeken felül tartalmazhat még egyéb opcionális részeket, mint pl. a visszavonás oka. Egy tanúsítvány akkor kerül visszavonásra ha: lejár az érvényességi ideje, a tulajdonos titkos kulcsa kompromittálódott a tanúsítványt kiállító CA titkos kulcsa kompromittálódott a regisztrált felhasználó töröltetni akarja magát akár az RA, akár a CA nyilvántartásából A CA a CRL-t célszerűen egy LDAP címtárban hozza nyilvánosságra, és megadott időpontonként frissíti. A CRL-eknek három kategóriája van: Tanúsítvány visszavonási lista (Certificate Revocation List - CRL) A listák ezen típusa azoknak a visszavont tanúsítványoknak a listáját tartalmazza, amelyeket a CA regisztrált felhasználók számára bocsátott ki. Szervezeti Visszavonási Lista (Certification Authority Revocation List CARL) 11

13 A listák ezen típusa azoknak a visszavont tanúsítványoknak a listáját tartalmazza, amelyeket a CA, CA-k számára bocsátott ki. Delta Visszavonási Lista (Delta Revocation List dcrl) A listák ezen típusa egy részleges lista, amely azon visszavont tanúsítványok listáját tartalmazza, amelyek dcrl előtt kibocsátott CRL közzététele óta vesztették érvényüket. [5] Ma már a CRL-ek mellett, a tanúsítványok visszavonásának ellenőrzésére az OCSP (Online Certificate Status Protocol) is használják. Az OCSP lehetővé teszi, hogy az érvényesség ellenőrzésére ne kelljen megvárni az új CRL kiadását, hanem tetszőleges időben lekérdezhetjük a tanúsítványok állapotát. Ezen állapotok a következők lehetnek: GOOD: a tanúsítvány érvényes REVOKED: a tanúsítványt visszavonták UNKNOWN: a tanúsítvány ismeretlen Az OCSP további előnye, hogy egy kérésben több tanúsítvány állapotát is le tudjuk kérdezni, ennek köszönhetően a tanúsítványok érvényességének megállapítása egy lépésben elvégezhető. [6] Felhasználók A felhasználók azok az egyének, akik a CA-któl tanúsítványokat igénylenek, hogy a PKI felhasználóivá válva, igénybe vehessék annak szolgáltatásait. Legfontosabb funkcióik: Kulcsok generálása, biztonságos tárolása Tanúsítványok igénylése, megújítása Tanúsítványok és visszavonási listák lekérdezése, ellenőrzése Tanúsítvány visszavonásának igénylése Kódolás, dekódolás Elektronikus aláírás készítése és ellenőrzése 1.3. A digitális aláírás Digitális aláírás a gyakorlatban Hiteles digitális aláírás készítése a valóságban igen sok tényezőtől függ. Mindenekelőtt gondoskodni kell a titkos kulcs és a tanúsítvány megfelelő tárolásáról, hogy illetéktelenek ne tudjanak hozzáférni. A tároló tipikusan egy szoftveres kulcstár vagy egy kriptográfiai eszköz. Ezekben egyszerre több titkos kulcs-tanúsítvány pár tárolható, melyeket álnevek (aliases) alapján különböztetünk meg. 12

14 A szoftveres kulcstárhoz való hozzáféréshez egy jelszó, esetlegesen titkosított privát kulcs esetén a kulcshoz való hozzáféréshez egy külön jelszó is szükséges. Az ilyen kulcstárak előnye, hogy egyszerre több példányban is létezhetnek egyszerre, hátrányuk hogy viszonylag könnyel feltörhetők és a kompromittálódás ténye akár el is elkerülheti tulajdonos figyelmét, hiszen nem tudja, hogy a kulcstár egy másolta illetéktelen kezekbe került. A kriptográfiai eszközön az aláírói adatok relatívan nagyobb biztonságban vannak, a mivel titkos kulcs lemásolása az eszközről nem lehetséges. Bizonyos típusoknál még a kulcspár generálása is az eszközön történik, így maga a titkos kulcs sosem hagyja el magát az eszközt. A tanúsítványokhoz és a titkos kulcshoz való hozzáférés egy számazonosítóval, PIN kód segítségével történik. Adott számú próbálkozás után az eszköz lezárja önmagát, amelyet csak egy magasabb biztonsági szintű, PUK kód segítségével lehet feloldani. Az aláírást is maga az eszköz végzi, így bizonyos esetekben az eszköz az aláírási folyamat gyorsítását is szolgálja. Az eszközök következő típusúak lehetnek: egyszerű intelligens kártya intelligens kártya saját kártyaolvasóval USB Token 6. ábra a kriptográfiai eszközök típusai 13

15 Az eszköz biztonságától függően rendelkezhet saját billentyűzettel, a PIN kód eltulajdonításának megelőzéseképpen. A kriptográfiai eszközök előnye a relatív biztonság, hátrányuk hogy számottevően megnövelik az aláírási tanúsítvány belépési költségeit, továbbá egyszerre csak egy helyen lehet használhatók, egyes típusok kevésbé mozgathatóak és a biztonságos fizikai tárolásukról is gondoskodni kell. Az aláírás elkészítése mindig valamilyen szoftverrel történik. A szoftver feladata az aláírandó dokumentum előkészítése, a titkos kulcs és a hozzá tartozó tanúsítvány kiolvasásra a kulcstárból. Az aláírás folyamata a következő: a szoftver az aláíró tanúsítványban található adatok alapján megállítja a tanúsítvány érvényességét ellenőrzi a tanúsítvány érvényességi idejét, még vagy már nem érvényes e az aláíró hitelesítés-szolgáltatója által kibocsátott visszavonási lista és az OCSP szerver válasza alapján ellenőrzi, hogy a tanúsítvány nem került visszavonásra megvizsgálja, hogy az aláró tanúsítványának hitelesítésben szerepet játszó hitelesítés-szolgáltatói tanúsítványok lánca, a tanúsítványlánc, érvényesek e ha a feltételeknek megfelel, akkor engedélyezi az aláírást ezek után a szoftver elkészíti az aláírandó dokumentum lenyomatát a lenyomatot az aláíró titkos kulcsával együtt átadja egy szoftveres kriptográfiai modulnak, vagy egy kriptográfiai eszköznek a kulcs használatához szükséges jelszót bekéri a felhasználótól a modul elkészíti az aláírást a modul által elkészített aláírást, a tanúsítványlánccal együtt az eredeti dokumentumhoz csatolja. A tanúsítványlánc csatolása azért célszerű, mivel a hitelesítés-szolgáltatók tanúsítványtárai közvetlenül nem elérhetők, ami megnehezíti az ellenőrzéshez szükséges tanúsítványok beszerzését. Az így elkészült dokumentummal létrejött az alap aláírási formátum. Az ilyen típusú aláírás viszont csak addig érvényes, ameddig az aláíró tanúsítványát vissza nem vonták, ez aláíró tanúsítványok esetében általában egy-két év. Így ez az aláírási formátum nem minden célra megfelelő, főleg olyan esetekben, amikor szükség van az aláírás keletkezésének időpontjára, amely itt nem garantált. 14

16 7. ábra az aláírás folyamata Olyan esetekben, amikor szükség van az aláírás megbízható idejének megállapítására, az aláírt dokumentumra időbélyeget (Timestamp) kell helyezni. A megbízható időpontot tartalmazó időbélyeget az időbélyegző szolgáltató (Timestamping Authority - TSA) állítja elő. Az időbélyegzés menete a következő: a szoftver az aláírandó dokumentum lenyomatát elküldi az időbélyegző szolgáltatónak az időbélyegző szolgáltató a lenyomat és a megbízható időpontot tartalmazó adat alapján létrehozza az időbélyeget, melyet aláírásával hitelesítve visszaküld a szoftvernek. a szoftver leellenőrzi az időbélyeg hitelességét hiteles időbélyeg esetén hozzácsatolja az aláírt dokumentumhoz Az így létrejött aláírási formátum érvényessége az időbélyegző szolgáltató tanúsítványának érvényességi idejére hosszabbodik meg, amely általában maximum 10 év. 15

17 A digitálisan aláírt dokumentumokat az aláírás után minden esetben ellenőrizni kell. Az aláírás ellenőrzése általában szintén az aláíró szoftverrel történik. Az ellenőrzés menete a következő: 8. ábra az aláírás ellenőrzésének menete a szoftver az aláírási formátumból kiolvassa az eredeti dokumentum aláírt lenyomatát majd kiolvassa az aláíró nyilvános kulcsát tartalmazó tanúsítványát a nyilvános kulccsal dekódolja a titkosított lenyomatot az adott lenyomatozó algoritmussal elkészíti az eredeti dokumentum lenyomatát ha a kettő egyezik, akkor az aláírás hitelessége bizonyítást nyert 16

18 ezután következik az időbélyeg ellenőrzése az időbélyegző tanúsítványában szereplő nyilvános kulccsal dekódolja az időbélyegen található aláírást adott lenyomatozó algoritmussal elkészíti az időbélyeg lenyomatát ha a kettő egyezik, az időbélyeg hitelessége bizonyítást nyert majd végül leellenőrzi az aláíró, az időbélyegző és az azokat hitelesítő tanúsítványok érvényességét felépíti az aláíró és az időbélyegző szolgáltató tanúsítványának tanúsítványláncát lekérdezi a tanúsítványok visszavonási állapotát (CRL, OCSP) megvizsgálja a tanúsítványok érvényességi időtartamát ha a feltételeknek megfelelnek, akkor a tanúsítványok érvényesek az így leellenőrzött dokumentum hitelesnek mondható A visszavonási információk ellenőrzésekor előfordulhat, hogy az állapotokat a hitelesítésszolgáltató csak hosszabb időközönként hozza nyilvánosságra. Ebben az esetben az ellenőrzéshez meg kell várni, amíg a visszavonási információk frissítésre kerülnek, ezt az időt nevezzük kivárási időnek A digitális aláírás jogi háttere A megbízhatóan működő technológia azonban nem elég, hogy a digitális aláírás használható legyen. Biztosítani kell a megfelelő jogi hátteret mind a digitális aláírás bizonyítóerejének, mind az azt kiszolgáló rendszer szabályozása, megbízható és hiteles működésének érdekében. Magyarországon ezt a jogi hátteret a évi LXXVI. az elektronikus aláírásról szóló törvény (EAT) biztosítja. A törvény megalkotása az Európai Parlament és Tanács 1999/93/EC direktívája és annak alapelvei lapján történt. Az egyik legfontosabb alapelv az volt, hogy a jogi szabályozásnak technológiafüggetlennek kellett lennie. Ezért a jogi terminológiában az ismert technológiai kifejezések helyett azok funkció szerinti elnevezésére került sor. Definiálásra kerültek a digitális aláírás, azt megvalósító rendszer és annak szereplőivel kapcsolatos fogalmak, mint például: Aláírás-létrehozó adat, Aláírás-ellenőrző adat, Aláírás-létrehozó eszköz Elektronikus aláírás, Elektronikus aláírás ellenőrzése Elektronikus aláírás hitelesítés-szolgáltató Tanúsítvány, Minősített tanúsítvány Időbélyegző, Időbélyegző szolgáltató 17

19 Ezek alapján meghatározták a digitális aláírással hitelesített dokumentumok és a digitálisa aláírással kapcsolatos szolgáltatások jogi következményeit. A törvényben meghatározásra kerültek a digitális aláírás megvalósító rendszer szereplőinek, a digitális aláírással kapcsolatos szolgáltatásokat nyújtók és azokat igénybevevők, jogai és kötelezettségei. A szolgáltatást nyújtók számára megadták a rendszerbe való belépés, kilépés feltételeit és hogy milyen körülmények között kell szolgáltatniuk. A szolgáltatással kapcsolatos részletesebb követelményeket a 3/2005 (III. 18.) IHM rendelet írja le. A törvény négy szolgáltatástípust határoz meg: elektronikus aláírás hitelesítés-szolgáltatás, melynek során a hitelesítés-szolgáltató tanúsítvány ad ki ügyfelei számára időbélyegzés, melynek során az időbélyegző szolgáltató időbélyeget helyez el az ügyfelei által kért dokumentumon aláírás-létrehozó eszközön az aláírás-létrehozó adat elhelyezése, ahol a szolgáltató az ügyfél tanúsítványát és titkos kulcsát biztonságos kriptográfiai eszközön bocsájtja annak rendelkezésére elektronikus archiválás szolgáltatás. A digitálisan aláírt dokumentumok, ellentétben a hagyományos dokumentumokkal nem maradnak hosszútávon hitelesek. Azonban bizonyos dokumentumokat határozatlan ideig kell megőrizni, melyeknek hitelességét akár évtizedek múlva is ellenőrizni kell. Ezért megbízható módon biztosítani kell a digitálisan aláírt dokumentumok hosszú távú hitelességét. Ez az elektronikus archiváló-szolgáltató feladata. Az EAT nagy hangsúlyt fektet a technológiai fejlődés követésére, ami biztosítja, hogy a digitális aláírással kapcsolatos technológiák és műszaki eszközök biztonsága adott technológia szinten garantálható legyen. Ez az elv a digitálisan aláírt dokumentumok archiválásakor különösen fontos. A digitális archiválás szabályairól a 114/2007. (XII. 29.) GKM rendelet rendelkezik. A törvény megkülönböztet nem minősített és minősített hitelesítés-szolgáltatókat, aszerint hogy a szolgáltató megfelel-e 3/2005 (III. 18.) IHM rendeletben leírt informatikai, minőségirányítási illetve szabályozási előírásoknak. A szolgáltatók működésének folyamatos ellenőrzését ellátó hatóságnak a Nemzeti Hírközlési Hatóságot (NHH) jelölték ki. Meghatározták az ellenőrzés feltételeit, a hitelesítés-szolgáltatók kapcsolatos adatok gyűjtésének és felhasználásának módjait. Az 18

20 NHH a hitelesítés-szolgálatokról és az általuk alkalmazott eszközökről nyilvántartást vezet, amelyet az nyilvánosság számára elérhetővé tesz. [7] A digitális aláírás típusai Az EAT három elektronikus aláírás típust különböztet meg attól függően, hogy milyen technológiával, milyen minősítésű eszközzel és milyen minősítésű aláírás létrehozó adat segítségével készült: 9. ábra a digitális aláírás típusai Egyszerű digitális aláírás: Elektronikus dokumentumhoz az aláíró azonosítása céljából csatolt vagy azzal logikailag összekapcsolt elektronikus dokumentum. Az ilyen típusú aláírásnak semmilyen joghatása sincs. Például valaki generál magának egy kulcspárt, amit -ek digitális aláírására használ. Fokozott biztonságú digitális aláírás: Olyan elektronikus aláírás, amely alkalmas az aláíró azonosítására és egyedülállóan hozzá köthető, kizárólag az aláíró befolyása alatt álló eszközzel hozták létre, valamint a dokumentum tartalmához technikailag olyan módon kapcsolódik, hogy minden az aláírás elhelyezését követően az iraton, illetve dokumentumon tett módosítás érzékelhető. Az ilyen aláírással ellátott elektronikus dokumentumok jogilag megegyeznek a kézírással hitelesített dokumentumokkal, azaz magánokiratnak minősülnek. Fokozott biztonságú aláírást készíteni csak az képes, aki fokozott biztonságú (nem minősített) tanúsítvánnyal rendelkezik. Ilyen tanúsítványt minősített és nem minősítet hitelesítés-szolgáltatók is kiadhatnak. Minősített elektronikus aláírás: Olyan fokozott biztonságú elektronikus aláírás, amely biztonságos aláírás készítő eszközzel készült, és amelynek hitelesítése céljából minősített tanúsítványt bocsátottak ki. Az digitális aláírások e típusa jogilag megegyezik a két tanú vagy közjegyző általi hitelesítéssel. Ez a legmagasabb biztonsági követelményeknek megfelelő aláírás típus. Ilyen aláírást csak biztonságos aláíró eszközzel (BALE) és minősített tanúsítvánnyal rendelkező 19

21 egyének tudnak készíteni. Minősített tanúsítványt csak minősített hitelesítésszolgáltatók adhatnak ki.[7][8] Digitális aláírással kapcsolatos fontosabb szabványok, ajánlások W3C XMLDsig: A W3C által kiadott ajánlás a XML dokumentumok aláírásának szintaxisáról. Általában olyan web-szolgáltatások által használt protokollokban alkalmazzák, amelyek az üzenetváltáshoz XML-t használnak (SOAP, SAML). [9] ETSI TS (XML Advanced Electronical Signatures - XAdES): egy XMLDsig kiterjesztési csomag, amelyet az ETSI (European Telecommunication Standards Institute) határozott meg az Európai Unió 1999/93/EC direktívája szerint. A csomag több aláírási formátumot határozz meg az aláírás élettartamának függvényében. XAdES-BES: alap aláírási formátum, az aláírt dokumentum az aláíró tanúsítványának visszavonásáig érvényes. XAdES-T (timestamp): a dokumentumon szereplő aláírást időbélyeggel látjuk el, így az aláírás az időbélyegző-szolgáltató tanúsítványának visszavonásáig érvényes: XAdES-C (complete): az időbélyegzett aláírást tartalmazó dokumentumhoz csatoljuk az ellenőrzéséhez szükséges tanúsítványokat és visszavonási információk referenciáit (CRL, OCSP). XAdES-X (extended): a dokumentumhoz csatolt ellenőrzési adatok referenciáira időbélyeg kerül, hogy az ellenőrzéskor bizonyítható legyen, hogy a mellékelt tanúsítványok és visszavonási adatok az aláírás készítésekor érvényesek voltak. XAdES-XL (extended long term): az ellenőrzéshez szükséges tanúsítványok és visszavonási adatok csatolása a dokumentumhoz, hogy az aláírás hitelességének vizsgáltata akkor is elvégezhető legyen, amikor azok eredeti helyükön már nem elérhetőek. XAdES-A (archive): az aláírást tartalmazó dokumentumot meghatározott időközönként időbélyeggel látják el, így garantálva annak hosszú távú érvényességét, még azon túl is, amikor az aláíráshoz használt algoritmusok már nem biztonságosak. [10] RSA PKCS (Public Key Cryptography Standards): az RSA Security által kidolgozott és publikált számos kriptográfiai szabványt tartalmazó csomag. A szabványok a nyílt kulcsú kriptográfiában alkalmazott eljárásokra vonatkozó előírásokat definiálnak, számos ezek közül nemzetközi szabványintézetek által elismert vagy de facto szabvánnyá vált. A fontosabbak ezek közül: 20

22 PKCS1: azokat az előírásokat definiálja, amelyek az RSA kulcspárok generálására és az azokkal való kódolás, dekódolás megvalósításához szükségesek. PKCS3: olyan kriptográfiai protokollt ír le, amely lehetővé teszi két ismeretlen fél közötti kulcsegyeztetést, nem megbízható kommunikációs csatornán. PKCS5: a jelszóból generált kulcs alapú titkosítás eljárását írja le. PKCS6: az X509 típusú tanúsítványok kiterjesztéseit definiálja. PKCS7: titkosított üzenetek kódolásához és dekódolásához használt eljárásokat határozza meg. PKCS10: a tanúsítvány aláírási kérelem, CSR (Certificate Sign Request), formátumára vonatkozó előírásokat tartalmazza. PKCS11: a kriptográfia eszközök eléréséhez egy általános hozzáférési felületet biztosító API-t határoz meg. PKCS12: egy szoftveres kulcstár formátumot határoz meg, melyben a privát kulcs és a hozzá tartozó tanúsítványok egy jelszó alapú szimmetrikus kulccsal vannak titkosítva. A formátum alkalmas több titkos kulcs-tanúsítvány páros tárolására. PKCS15: egy kriptográfiai protokollt ír le, ami lehetővé teszi az alkalmazásokban történő azonosítás kriptográfiai eszközökkel való elvégzését, amely független a szoftver PKCS11 megvalósítástól. [11] CEN WorkShop Agreements (CWA): az Európai Szabványügyi Bizottság (CEN) által kiadott referenciadokumentumok, melyek egy része a digitális aláírás létrehozó eszközök és szoftver komponensekkel szemben támasztott követelményeket tartalmazza. Ezek a következők: CWA 14167: Biztonsági előírások a digitális aláírás tanúsítványokat kezelő megbízható rendszerekhez CWA 14169: Biztonságos aláírás létrehozó eszközök EAL+4 CWA 14170: Biztonsági előírások digitális aláírás létrehozó alkalmazásokhoz CWA 14171: Általános iránymutató a digitális aláírás ellenőrzéséhez CWA 14172: EESSI megfelelőség-értékelési útmutató CWA 14355: Iránymutató biztonságos aláírás létrehozó eszközök megvalósításához CWA 14365: Útmutató a digitális aláírás használatához CWA 14890: Alkalmazási felület biztonságos aláírás létrehozó eszközként alkalmazott intelligens kártyákhoz 21

23 2. Egy digitális aláíráson alapuló ügyintéző rendszer tervezése 2.1. Az ügyintéző rendszer feladatainak meghatározása Az Online szolgáltatók problémája Az Internet elterjedésével egy új kommunikációs csatorna nyílt meg a cégek számára. Ez az új csatorna lehetőséget adott új elektronikus megoldások megvalósításához, amelyek képesek voltak alternatívát nyújtani a hagyományos információhordozó eszközökre, mint a levél, telefon, televízió, rádió. Ezek elektronikus változati ma már mind-mind elérhetők és nagy tömegek által használt technológiák. Az új csatornán keresztül a cégek számára könnyebb és olcsóbb volt a potenciális ügyfelek elérése, a különböző termékek és szolgáltatások értékesítése. Ez eredményezte új Internetes szolgáltatások megjelenését, amelyekkel a cégek önmaguk és ügyfeleik életét próbálják megkönnyíteni. Jó példa erre az e-banking, vagyis elektronikus banki ügyintézés, amelyet lassan már minden bank elérhetővé tesz kliensei számára. Segítségével az ügyfelek az Interneten intézhetik pénzügyeiket, amellyel időt és pénzt takaríthatnak meg, csakúgy, mint a szolgáltatást nyújtó bank. Viszont ahhoz, hogy ezt a szolgáltatást igénybe vehessék, meg kell kötni az erről szóló szerződést a bankkal valamely bankfiókban. Ez nem nagy fáradtság ahhoz képest, amennyi időt meg lehet vele takarítani a későbbiekben. Visont az elektronikus ügyintézés a bank számára csak egy költségmegtakarítási forma, nem lételeme működésének, a bankfiókokat annak ellenére is működtetnie kell, hogy az egész bankrendszer teljesen elektronikus. Vannak viszont olyan cégek, amelynek az Internet annyira szerves része, hogy nélküle nem is létezhetnének. Ezek az online szolgáltatók, amelyek csak és kizárólag internetes vagy internetes technológiákhoz kötődő szolgáltatásokat nyújtanak. Azonban ezek a cégek is, akaratuk ellenére, a világ nagy részén kötöttek a fizikai elérhetőséghez. Erre részben a szigorú szabályozás, részben pedig saját érdekük miatt kényszerülnek. Az általuk nyújtott szolgáltatások megrendelőivel ugyanúgy szerződést kell készíteni, mint bármely más hagyományos szolgáltató cég esetében, ez az egyetlen dokumentum, ami bizonyítja a két fél közötti megállapodást. Ennek eredményeképpen ezek a cégek az irodák fenntartásával felesleges többletköltségekkel terhelik magukat. Erre a helyzetre kínálhat megoldást a digitális aláírás, amely a megfelelő jogi biztosítás és a webes technológiák révén képes egy lehetséges alternatívát nyújtani, a hagyományos ügyintéssel szemben. 22

24 Az érintett területek Az ügyfelekkel való kapcsolat csak az egyik feladata a céges ügyintézésnek. Az online cégeknek is rendelkeznek partnercégekkel, amelyekkel szintén szerződéseket kell kötniük. Ezen felül ugyanúgy, mint bármely más cég, az állam felé is kötelezettségekkel rendelkezik. Ezeket általában mind-mind hagyományos papíralapú megállapodások és nyilatkozatok formájában kell megoldani, így ezek a cégek jelentős hátrányba kerülnek saját technológiai megoldásaikkal szemben. Meg kell vizsgálni, hogy mely területek azok, ahol a digitális aláírás lehetőséget nyújt a jelenlegi megoldás kiváltására. Az ügyintézés területei a következők: Üzleti partnerekkel való kapcsolatok Közigazgatással való kapcsolatok Ügyfelekkel való kapcsolatok Az üzleti partnerek estében van lehetőség az elektronikus ügyintézésre való áttérésre, azonban ez a terület nem homogén, így még abban az esetben sem lehet teljesen átállni, ha a partnercégek nagy része támogatja az elképzelést. Ugyanis mindig lehetnek olyan cégek, akiknek nem kifizetődő az elektronikus megoldások használata, működésük jellegéből adódóan maguk is erősen kötöttek a hagyományos ügyintézési formákhoz, rákényszerítve ezzel az online cégeket is. Így ezen a területen nem valósítható az elektronikus átállás. A közigazgatási területen a cégeknek nem sok beleszólásuk van az ügyintézés megszervezésébe. Itt teljes mértékben az állam diktálja a feltételeket, a cégek csak tanácsolhatják az új megoldások használatát, a megvalósítás nem garantált. Nyilvánvalóan az állam érdeke is, hogy csökkentse az ügyintézéssel járó költségeket. Bizonyos esetekben már próbálják kihasználni a digitális aláírás által nyújtott előnyöket (Ügyfélkapu). Azonban ez önmagában kevés, így itt sem lehet a teljesen elektronikus ügyintézésre váltani. Mivel az ügyfelekkel való kapcsolat esetében maga szabhatja meg az ügyintézés feltételeit, ezért az új digitális aláírásra épülő rendszer megvalósítása ezen a területen történik meg Az új ügyintéző rendszer feladatinak megállapítása A rendszer tervezéséhez először meg kell határozni azokat a feladatokat, amiket a rendszernek el kell látnia. Mivel ezek a szolgáltató cég ügyfeleivel kapcsolatos ügyekben merül ki, ezért össze kell írni minden olyan feladatot, ami ezen a területen felmerülhet. Ezek a következők: Szerződések kötése, bontása 23

25 Ügyfelek adataiban történt változások kezelése Számlák összeállítása, eljuttatása az ügyfelek számára Ügyfél tájékoztatók készítése és továbbítása Hibabejelentések fogadása, problémák elhárítása Szolgáltatatással kapcsolatos kérdések fogadása és megválaszolása az ügyfelek számára Ezek közül a feladatok közül le kell szűrni azokat, amelyek automatizálása ésszerű keretek között megoldható. A szerződéssel kapcsolatos feladatok ellátása a digitális aláírás révén könnyen megvalósítható, hiszen az aláírás elkészítéséhez nem szükséges emberi beavatkozás, egy aláíró alkalmazás elvégezheti a szerződés céges hitelesítését, elég ha az egyedüli aktív fél maga az ügyfél. A számlák elkészítése is egyszerűen megvalósítható feladat, ma használt számlázórendszerek gyakorlatilag teljesen elektronikusak, csak maguk a számlák kerülnek ki a fizikai világba. A digitális aláírás segítségével ez a feladat teljesen automatikusan megoldható. Az ügyfél tájékozatók összeállítása és továbbítása könnyen automatizálható folyamat, mivel azonban itt a hitelesítés nem létfontosságú tényező, új megoldás kialakítására nincs szükség. Az ügyfelek adataiban történt változások kezelése létre lehet hozni egy elektronikus ügyfélkaput, melybe digitális aláírás segítségével azonosítaná az ügyfeleket, akik az esetleges adataikban történő változásokat érvényesíthetnék a cég adatbázisában. Itt azonban felmerül a kérdés, hogy célszerű-e az ügyfeleknek lehetőséget adni a róluk nyilvántartott adatokhoz hozzáférést adni. Mivel az adatokban történő változás nem gyakori eset, ezért a biztonságot szem előtt tartva, az adatok változásának kezelését érdemes a hagyományos megoldásokon keresztül végezni, például telefonon vagy személyesen. A hibabejelentések fogadása és az így felmért problémák megoldása, továbbá a szolgáltatásokkal kapcsolatos kérdések megválaszolása megvalósítható ugyan csak elektronikusan, azonban ezek a feladatok minden esetben emberi beavatkozást igényelnek, így nyilvánvalóan nem automatizálhatóak. Sok esetben azonban az elektronikus csatornák, mint például az , nem képesek ellátni elég hatékonyan ellátni az ilyen feladatokat, 24

26 ezért itt a hagyományos megoldást érdemes alkalmazni, mint például a telefonos ügyfélszolgálat. Ezek alapján összefoglalva a digitális aláíráson alapuló új ügyviteli rendszernek a következő feladatokat kell megvalósítania: Lehetővé teszi, hogy az ügyfelek online köthessék vagy lemondhassák szerződéseiket Elkészíti és továbbítja a szolgáltatás díjait tartalmazó elektronikus számlákat az ügyfelek számára 2.2. Az ügyviteli rendszer felépítése és működése A meghatározott feladatok alapján az ügyviteli rendszer alapvetően két részre bontható: Elektronikus szerződéskötő rendszer Elektronikus számlázó rendszer A rendszereket egy-egy különálló alkalmazás/web-szerveren célszerű elhelyezni, a könnyebb kezelhetőség érdekében. A két alrendszer egy-egy alkalmazásnak felel meg, melyek az alkalmazás-szervereken különállóan végzik feladataikat, ezzel megakadályozatható, hogy az egyik alrendszer hibája a másikban kárt okozzon A szerződéskötő rendszer Az elektronikus szerződéskötő rendszer feladata, hogy a cég jelenlegi vagy leendő ügyfelei online köthessenek szerződést. Ezt ésszerűen egy szerver-kliens alapon működő web-alapú alkalmazáspárral érdemes megvalósítani. A rendszert kiszolgáló alkalmazás-szerver címe a cég névterének egy új tartománya lesz, amely megkönnyíti a rendszer, a cég webkiszolgálói infrastruktúrába illesztését. A kiszolgáló alkalmazás elérhetőségét a cég web-oldalán egy új hivatkozás formájában tesszük közzé. A szerver-alkalmazás az alkalmazás-szerveren fut, amely kapcsolatban áll a cég adatbázis, levelező és fájlszerverével. A kliens program az ügyfél böngészőjében fut, amelyet az új kapcsolat kezdeményezéskor tölt le az alkalmazás-szerverről. Az ügyfél böngészője és az alkalmazás-szerver között a kommunikáció biztonságos SSL (Secure Socket Layer) kapcsolaton keresztül történik, így biztosítható, hogy a szerződéskötés alatt küldött adatok ne kerülhessenek rossz kezekbe. A kliens kapcsolatokat a szerver-alkalmazás munkamenetek (session) alapján tartja nyilván. 25

27 10. ábra a szerződéskötő rendszer környezete A szerződés új médiumaként egy PDF dokumentum fog szolgálni, amely megfelel egy ügyfélszerződés elektronikus változatának, tartalma és formátuma megegyezik nyomtatott másával. Az adatok behelyettesítését a kiszolgáló alkalmazás végzi el az ügyfél böngészőjében futó kliens-alkalmazás által kapott adatok alapján. A szerződést mind az ügyfél mind a rendszer saját aláírásával hitelesíti, így biztosítva a kétoldalú szerződéskötést. A digitális aláírásokat a XAdES XML aláírási formátumnak megfelelően csatoljuk az elektronikus szerződés dokumentumhoz. Az aláírás időpontjának pontos igazolásához és hosszú távú érvényességének megőrzéséhez a rendszer időbélyegzővel látja el az aláírásokat tartalmazó dokumentumot. A szerződéskötés folyamata: Az új szerződést kötni kívánó ügyfelek, a cég web-oldalán található hivatkozás alapján érhetik el a szerződéskötő rendszert. A kiszolgáló alkalmazás az új kérés hatására eljuttatja a kliens az ügyfél böngészőjébe. A kliens egy elektronikus űrlapot jelenít meg, amelyet a weboldalon mellékelt tájékoztató szerint kell kitölteni. Az ügyfélnek minden kötelező adatot meg kell adnia, ami a szerződés 26

28 létrehozásához eddig is szükséges volt, például a személyes adatok, cím, telefonszám és a szolgáltatás típusa, amit az ügyfél igénybe szeretne venni. A mezőkbe beírt adatokon ellenőrzéseket végez, hogy csak megfelelő adatok kerülhessenek továbbításra. Miután az űrlap kitöltésre kerül, az ügyfél a szokványos Küldés gombra kattintva, elküldi az űrlapot a szerződéskötő rendszer szerver részének. A kliens ekkor tájékoztatja az ügyfelet, hogy várni kell, míg a szerver elkészíti a szerződést. A szerver-alkalmazás az elküldött adatokat a szerver oldalon is leellenőrzi, hogy az esetleges hiba esetén a szerződés ne tartalmazhasson érvénytelen adatokat. Az adatokat kétféleképpen fogja felhasználni, először a szerződést tartalmazó fájl megfelelő mezőibe fogja behelyettesíteni, másodszor ideiglenes munkamenet tárolóba menti őket, hogy a sikeres tranzakció végeztével az adatokat rögzíthesse a cég adatbázisában. A klienshez egy új munkamenet azonosítót hoz létre, továbbá generál egy szerződés azonosítót, amelyet az ügyfél szerződésének azonosításához használ fel. Ezt szintén a klienshez tartozó munkamenetben rögzíti. 11. ábra a szerződés előállításának folyamata A kitöltött szerződés előállítása egy XML séma szerint történik. A struktúra tartalmazza a szerződés felépítését, a szerződés szövegét, továbbá a behelyettesítési mezőket. Ezáltal a szerződésben történő változtatásokat könnyen megoldhatók. A kiszolgáló alkalmazás a klienstől kapott adatokat behelyettesíti a megfelelő mezőkbe, majd az így létrejött XML struktúra alapján elkészíti a kitöltött szerződést tartalmazó PDF dokumentumot. Későbbi ellenőrzés céljából elkészíti a dokumentum lenyomatát, amelyet a 27

29 klienshez tartozó munkamenetben rögzít. Majd a szerződést tartalmazó dokumentumot és a szerződésazonosítót, a munkamenet azonosítóval együtt visszaküldi a kliens-alkalmazás számára. Az eddig várakozó kliens-alkalmazás átveszi a munkamenet azonosítót, a szerződést és a szerződés azonosítót a szerver-alkalmazástól, majd előkészíti a dokumentum elolvasásához szükséges grafikus elemeket. A PDF megjelenítése pontosan ugyanolyan formátumban kell, hogy történjen, ahogyan ezt egy PDF-et megjeleníteni képes asztali alkalmazás is tenné. Ez azért fontos, hogy a szerződéskötés befejezésekor, ha az ügyfél megtekinteni a kész szerződést, ne legyen olyan érzése, hogy nem azt írta alá, amit látott. Az ügyfél az erre a célra kialakított gombok segítségével a megjelenített szerződést végiglapozhatja, végigolvashatja és dönthet arról, hogy aláírja-e a szerződést. Az alkalmazás felhasználói felületén a megjelenítő rész alatt található két gomb, az egyik az Aláírom, a másik a Nem írom alá. Ha a Nem írom alá gombot választja, akkor a szerződéskötési folyamat megszakad, a kliens bontja a kapcsolatot és az ügyfél böngészőjét átirányítja a cég kezdőlapjára. A szerver-alkalmazás megszünteti a munkamenetet és a hozzá tartozó adatokat. Ha az ügyfél úgy dönt, hogy aláírja és megnyomja az Aláírom gombot, akkor a kliensalkalmazás egy új párbeszédablakot nyit a szoftveres tanúsítvány megnyitásához. Az ügyfél kiválasztja a megfelelő kulcstárat, majd a jelszómezőben megadja a megnyitáshoz szükséges jelszót. Ha a kiválasztott fájl nem olvasható be kulcstárként, vagy a jelszó nem megfelelő, akkor erről tájékoztatja az ügyfelet. Sikeres beolvasás esetén egy lista jelenik meg a kulcstárban található tanúsítványokról. Az ügyfél kiválaszthatja a megfelelőt, amelyhez meg kell adnia egy opcionális jelszót. Ezután az alkalmazás beolvassa a kiválasztott álnévhez tartozó tanúsítványláncot és titkos kulcsot. A tanúsítvány és a hozzá tartozó tanúsítványláncon ellenőrzéseket végez. Ha a tanúsítványlánc nem felépíthető, a tanúsítvány érvénytelen vagy nem alkalmazató digitális aláíráshoz, akkor visszautasítja annak használatát. Használható tanúsítvány esetén előkészíti az XML aláírási formátumot. Az XML struktúrában a következő adatokra kerülnek rögzítésre: Az aláírandó szerződés dokumentum Az aláró tanúsítványa Az aláíró tanúsítványát hitelesítő hitelesítés-szolgáltató tanúsítványok A lenyomatozáshoz használt algoritmus azonosítója 28

30 Az aláíráshoz használt algoritmuspár azonosítója Az adatok kódolásához, transzformációjához használt algoritmusok azonosítói Ezeket XAdES formátumnak megfelelően rögzíti, majd a megfelelő elemeken adott aláírási algoritmuspárral elkészíti a dokumentum aláírását. Ezek után elkészíti a szerződésazonosító lenyomatát, amelyet az aláíró titkos kulcsával titkosít. Az XML struktúrát, az aláírt szerződésazonosítóval és saját munkamenet azonosítójával együtt elküldi az szerver-alkalmazásnak. A szerver oldali alkalmazás leellenőrizi, hogy a kérésben található munkamenet azonosító létezik-e, ha nem, akkor visszautasítja a kapcsolatot. Létező azonosító esetén átveszi az XML dokumentumot. Ezek után leellenőrzi, hogy az XML dokumentum megfelel-e a XAdES aláírási formátumnak. Ha nem megfelelő, akkor erről egy hibaüzenet formájában tájékoztatja a klienst. Ha megfelelő, akkor tovább folytatja az ellenőrzést. Az XML struktúrából kinyeri a szerződést tartalmazó dokumentumot, a titkosított lenyomatot, a tanúsítványokat, az aláíráshoz használt algoritmusok és az adatokon végzett transzformációs algoritmusok azonosítóit. Először azt vizsgálja meg, hogy a tanúsítványban szereplő név és az ügyfél által megadott név egyezik e. Ha egyezik, akkor folytatódik a szerződéskötési folyamat, ha nem, akkor hibaüzenetet küld az ügyfél számára a böngészőjében futó kliensen keresztül, majd bontja a kapcsolatot. Ez a megoldás nem elégséges egy személy teljes azonosításához, viszont garantálja, hogy a szerződést más nevében nem lehet aláírni. Ez alól persze kivétel, ha két személy neve megegyezik. Az aláíró tanúsítványában található nyilvános kulcs alapján visszafejti a dokumentumon lévő aláírást. A dokumentumban rögzítet algoritmusazonosítók alapján, elvégzi a szükséges dekódolási és transzformációs műveleteket az aláírt XML elemeken, majd elvégzi a lenyomatozást. Ha a két lenyomat egyezik, akkor az aláírás hiteles. Ha eltér, akkor hibaüzenetet küld a kliensnek és bontja a kapcsolatot. Ezután a dokumentumon lévő aláírásról megállapítja, hogy az aláírás tényleg a dokumentumra vonatkozik. Az előzőekben az aláírás dekódolásának eredményéül kapott lenyomatot összehasonlítja a klienshez tartozó munkamenet változóban tárolt lenyomattal, amely az eredeti dokumentum alapján készült. 29

31 Ha a két lenyomat eltér, akkor hibaüzenetet küld a kliensnek és bontja a kapcsolatot Azonosság esetén folytatódik az ellenőrzés. 12. ábra a szerződés aláírásának menete A következő lépés a tanúsítványlánc felépítése. Ehhez a tanúsítványokon szereplő digitális aláírásokat és az azokban található nyilvános kulcsokat használja fel. A láncban minden tanúsítványon szereplő aláírást a kiállító nyilvános kulcsával dekódolja, majd összehasonlítja az általa készített tanúsítvány lenyomattal. Ezt az összes tanúsítványra elvégzi kivéve a legfelsőbb szintű tanúsítványt. 30

32 Ha bármely aláírás nem megfelelő, akkor hibaüzenetet küld és bontja a kapcsolatot Ha a tanúsítványlánc érvényes folytatódik az ellenőrzés Azoknak a hitelesítés-szolgáltatóknak, amelyek tanúsítványait az alkalmazás elfogadja, azok legfelsőbb szintű tanúsítványait előzetesen kézzel kell beszerezni, egy megfelelő kulcstárban kell elhelyezni, amelyet az alkalmazás számára elérhetővé kell tenni. Így szabályozható, hogy a rendszer mely hitelesítés-szolgáltatók tanúsítványait fogadja el. Ezek alapján vizsgálja meg a tanúsítványlánc legfelsőbb szintű elemeit, melynek révén a tanúsítványlánc épsége végérvényesen ellenőrizhető. Ha a tanúsítványlánc nem érvényes vagy az aláíró tanúsítványa nem elfogadott, hibaüzenetet küld a kliensnek és a kapcsolat bontásra kerül. Ha érvényes, akkor folytatódik az ellenőrzés. Ha a tanúsítvány hiteles, akkor a szerver-alkalmazásnak már csak arról kell meggyőződnie, hogy az ügyfél és annak tanúsítványát kiállító hitelesítés-szolgáltató tanúsítványát nem vonták e vissza, ehhez az ügyfél hitelesítés-szolgáltatójának OCSP szerverét használja fel. Ennek elérési címet egy olyan listából állapítja meg, amelyet az indításkori konfigurációs állományból tölt be. Az aláíró tanúsítványláncában szereplő összes tanúsítványból összegyűjti a sorszámát és a kiállító megkülönböztetett nevét (DN). A sorszám-kiállító név párosokat egy szabványos OCSP kérésnek megfelelő csomag formájában elküldi az OCSP szervernek. Az OCSP szerver a kapott adatok alapján ellenőrzi, hogy a kérdéses tanúsítványokat visszavonták e. Az eredményt az állapotok ellenőrzésének idejével együtt egy szabványos válaszüzenet formában juttatja vissza a szerver-alkalmazás számára, melyet saját kulcsával ír alá. A szerver-alkalmazás, a válasz feldolgozása előtt leellenőrzi, hogy az hiteles e. Az alkalmazás számára elérhetővé kell tenni az OCSP szerver tanúsítványát hitelesítő hitelesítés-szolgálatai tanúsítványt, mert csak így lehetséges a válasz hitelességének ellenőrzése, ezt szintén egy az alkalmazás által elérhető kulcstárban helyezzük el. Az OCSP válaszból kiolvassa az abban található aláírást és tanúsítványt. A válaszon a következő ellenőrzéseket végzi: Elvégzi a lenyomatozást a válaszon, majd az azon lévő aláírást az OCSP válaszadó tanúsítványában található nyilvános kulccsal dekódolja, a két lenyomatot összehasonlítja. 31

33 A válaszban található tanúsítványon lévő aláírást, a birtokában lévő hitelesítésszolgáltatói tanúsítvány nyilvános kulcsával dekódolja, elvégzi a tanúsítvány lenyomatozását, a két lenyomatot összehasonlítja Ha ezek közül bármelyik nem teljesül, akkor a válasz nem érvényes, ez azt jelenti, hogy az OCSP szervert meghamisították, az alkalmazás értesíti a rendszer üzemeltetőjét egy formájában a veszélyre. Ameddig az eset nem kerül orvoslásra, az adott hitelesítésszolgáltató tanúsítványai tiltólistára kerülnek. Hiteles válasz esetén a szerver alkalmazás a válaszban lévő tanúsítványok állapota alapján kezeli a szerződéskötési folyamat további menetét. Ebben az esetben három eset lehetséges az ügyfél és tanúsítványláncban szereplő hitelesítés-szolgáltatói tanúsítványok állapota alapján: Ha mindkettő állapota jó (good), akkor az ügyfél és hitelesítés-szolgáltatói tanúsítványok érvényesek, tehát maga az aláírás is, így az szerződéskötési folyamat folytatódik. Ha akármelyik állapota visszavont (revoked), akkor a megszakad a szerződéskötési folyamat, az ügyfél böngészőjében futó kliens figyelmezteti, hogy az ő vagy hitelesítés-szolgáltatója tanúsítványát visszavonták, a szerver-alkalmazás bontja a kapcsolatot, a kliens pedig átirányítja az ügyfél böngészőjét egy meghatározott weboldalra. Ez esetben a szerver-alkalmazásnak figyelmeztetnie kell a rendszert üzemeltetőjét, hogy az adott hitelesítés-szolgáltató tanúsítványa érvénytelenné vált. Ameddig az új tanúsítvány nem kerül beszerzésre, addig azok az ügyfelek, akik ettől a hitelesítés-szolgáltatótól származik tanúsítványuk, nem köthetnek szerződést, az alkalmazás által tiltólistára kerülnek. Ha valamelyik állapota ismeretlen (unknown), akkor ez biztonsági problémát jelent. Ha az ügyfél tanúsítványa ismeretlen, akkor ez azt jelenti, hogy a hitelesítésszolgáltató titkos kulcsa kompromittálódott, mivel az OCSP szerver szerint nem létezik, mégis a hitelesítés-szolgáltató kulcsával van aláírva. Ebben az esetben a szerver-alkalmazásnak értesítést kell küldenie, rendszerüzemeltetőnek a problémáról, aki értesíti a hitelesítés-szolgáltatót. Az új tanúsítvány beszerzéséig az ettől a hitelesítés-szolgáltatótól származó tanúsítványokat használó ügyfelek tiltólistára kerülnek. Ha a hitelesítés-szolgáltató tanúsítványa ismeretlen, ez azt jelenti, hogy a szerver alkalmazás által használt változatát meghamisították, továbbá az általa hitelesített 32

34 tanúsítványok is érvényetlenek. Ebben az esetben is jeleznie kell az illetékes személynek a problémát. Ilyen komoly biztonsági probléma esetén a szerződéskötő rendszer leáll. Hiteles OCSP válasz és érvényes tanúsítványok esetén a biztosak lehetetünk benne, hogy az ügyfél aláírása hiteles. Az ügyfél aláírásának ellenőrzése után, a szerver-alkalmazás is aláírással látja el a hitelesített szerződésdokumentumot, majd időbélyegzővel látja el az aláírásokat. Ennek megkezdése előtt azonban saját tanúsítványláncának és az időbélyegző szolgáltató tanúsítványának állapotát is le kell ellenőriznie, hiszen csak akkor lehet érvényes a szerződés, ha mindekét aláírás és az időbélyeg is hiteles. A tanúsítványokat és saját titkos kulcsát a megfelelő kulcstárakból tölti be. Saját tanúsítványláncából és az időbélyegző szolgáltató tanúsítványából összegyűjti azok sorszámának és a kiállítójuk megkülönböztetett nevéből (DN) álló listát, amelyet egy szabványos OCSP kérés formájában elküld a saját hitelesítés-szolgáltatójának OCSP szerverének. Az OCSP szerver lekérdezi a tanúsítványok állapotát, majd szabványos válasz formájában visszaküldi a visszavonási információkat. A válasz feldolgozása előtt azonban meg kell vizsgálni annak hitelességét. A válasz az előző OCSP válasz ellenőrzésével azonos módon zajlik. Ha a válasz nem hiteles, akkor az OCSP szerver kompromittálódott, erről értesíteni kell a rendszer üzemeltetőjét, majd az alkalmazás felfüggeszti működését. Egyébként az ellenőrzés az OCSP válasz elemzésével folytatódik. Ebben az esetben is, a válaszban lévő tanúsítványállapotok függvényében három eset lehetséges: Ha mindhárom állapota jó (good), akkor folytatódhat a szerződéskötés folyamata. Ha valamelyik állapota visszavont (revoked), akkor a szerződéskötő rendszer működését fel kell függeszteni, ameddig az új tanúsítványok beszerzésre nem kerülnek. Ha valamelyik állapota ismeretlen (unknown), akkor azt jelenti, hogy a szerveralkalmazás által használt tanúsítványokat meghamisították, tájékoztatnia kell a rendszerüzemeltető személyt a veszélyről, majd fel kell függesztenie működését. Ilyen esetekben, ha a szerver-alkalmazás által használt tanúsítványokkal van probléma, a szerver alkalmazás még mielőtt felfüggesztené működését, gondoskodik arról, hogy 33

35 elérhetetlené tegye az ügyfelek számára a szerződéskötő rendszert, és hogy az ügyfelek erről a helyzetről tájékoztatva legyenek. Ezt tipikusan azt jelenti, hogy a szerveralkalmazás egy üzenetet küld a szolgáltató cég web-szerverének, hogy a szerződéskötő rendszer elérhetőségét szüntesse meg, a hivatkozás céljaként pedig egy a szolgáltatás nem elérhető sablon web-oldalt helyezzen. Ezek után a szerver alkalmazás saját aláírásával látja el a szerződésdokumentumot, előkészíti az aláíráshoz csatolásához szükséges XML elemeket. A dokumentumhoz a következőket csatolja: saját tanúsítványa a tanúsítványt hitelesítő hitelesítés-szolgáltatói tanúsítványokat a lenyomatozáshoz használt algoritmus azonosítója az aláíráshoz létrehozásához használt algoritmuspár azonosítója az adatok kódolásához, transzformációjához használt algoritmusok azonosítói Az eredeti dokumentumot illetve a fenti adatokat tartalmazó XML elemeket aláírásával hitelesíti. Az aláírást a XAdES formátumnak megfelelően csatolja a dokumentumhoz. Az időbélyegzések elkészítéséhez a két aláírás lenyomatát a szerver-alkalmazás egy-egy szabványos időbélyegzés kérés formájában juttatja el az időbélyegző-szolgáltató szerveréhez. A időbélyegző szerver a lenyomathoz hozzárendeli a pontos időt, egy megadott algoritmussal elkészíti ezek lenyomatát, amelyet saját titkos kulcsával titkosít és ezt az időbélyegzés időpontjával együtt visszaküldi válaszként a szerver-alkalmazásnak. Az időbélyegeket a szerver-alkalmazásnak szintén le kell ellenőriznie. Ehhez szükség van az időbélyegző szolgáltató tanúsítványát hitelesítő hitelesítés-szolgáltatói tanúsítványra, ezt szintén egy az alkalmazás számára elérhető kulcstárban kell elhelyezni. Az időbélyegből kiolvassa az abban található tanúsítványt és az azon található aláírást. A hitelességet a következő vizsgálatokkal állapítja meg: Elkészíti az időbélyeg lenyomatát, majd az időbélyegző tanúsítványában található nyilvános kulccsal visszafejti az aláírást, a kettő eredményét összehasonlítja Megvizsgálja, hogy az időbélyegben található tanúsítványon szereplő aláírás, tényleg a tanúsítványt kiállító hitelesítés-szolgáltatói tanúsítvánnyal készült Ha ezek közül valamelyik nem megfelelő, akkor az időbélyeg nem hiteles, az időbélyegzőszolgáltató szerverét meghamisították, az alkalmazás értesíti a rendszer üzemeltetőjét, majd felfüggeszti működését. 34

36 Hiteles időbélyegek esetén az alkalmazás elkészíti az aláírás formátum végeleges formáját. Az időbélyegeket és az időbélyegző tanúsítványát a XAdES formátumnak megfelelő XML elemben csatolja a dokumentumhoz. A dokumentumot három irányba továbbítja: egy meghatározott tárolóegységre menti el szabványos XML fájlként, ahol a szerződések tárolódnak visszajuttatja az ügyfél számára, aki a kliens segítségével lementheti a saját példányát a számítógépére az ügyfél adatait tartalmazó az ügyfél-szolgálatának címzett levél mellékleteként, elküldi a cég levelező-szerverének, így értesítve őket a sikeres szerződéskötésről. A sikeres szerződéskötés után az eddig munkamenetben tárolt ügyfél és a szerződés adatokat rögzíti a cég adatbázisában, majd bonja a klienssel való kapcsolatot. A kliens is bontja a kapcsolatot, majd miután az ügyfél lementette saját szerződéspéldányát, átirányítja az ügyfél böngészőjét a cég weblapjára. A szerződésbontás menete: A szerződésbontás menete teljesen megegyezik a szerződéskötés menetével, azzal a különbséggel, hogy a szerver alkalmazás a szerződés lemondását akkor engedélyezi, ha az adatbázisban tárolt szerződésazonosító titkosított lenyomata és az ügyfél titkos kulcsával újból elkészített titkosított szerződésazonosító lenyomat megegyezik. Ebben az esetben az ügyfél szerződésének státuszát inaktívra állítja a cég adatbázisában Elektronikus számlázó rendszer Az elektronikus számlázó rendszer feladata, hogy a szolgáltató cég ügyfelei számára, az általuk igénybevett szolgáltatások díjairól számlát állítson össze és azokat továbbítsa elektronikus úton az ügyfelek számára. Az számlázó rendszer is egy külön alkalmazás-szerveren fut, kapcsolata korlátozott az Internetre, csak és kizárólag a cég időbélyegző-szolgáltatójának szerverével és hitelesítésszolgáltatójának OCSP szerverével kommunikálhat a hálózaton kívül. Hálózaton belül a cég adatbázis-szerverével, fájlszerverével és levelező-szerverével áll kapcsolatban. A szolgáltató cég belső adatbázisában rögzítésre kerültek az ügyfelek azonosításához és az ügyfelekkel való kapcsolatfelvételhez szükséges adatok, továbbá az általuk igénybevett szolgáltatások. Az adatokat a számlázó rendszer kiolvassa a cég adatbázisából, amelyeket a számlák sémáját tartalmazó XML dokumentum megfelelő mezőibe helyettesít be. Az kitöltött séma alapján állítja elő a PDF dokumentumokat, melyek tartalma és felépítése megegyezik a hagyományos számlákéval. Ezeket saját titkos kulcsával hitelesíti, az 35

37 időbélyegző-szolgáltatóval időbélyeget az aláíráson, majd a XAdES formátumnak megfelelő aláírási struktúrában csatolja az eredeti dokumentumhoz. 13. ábra az elektronikus számlázó rendszer környezete A számlakészítés folyamata: A számlázás megkezdése előtt, a számlázó alkalmazásnak le kell ellenőriznie azon tanúsítványok érvényességét, amelyek a számlázási folyamatban érintettek. Ez ebben az esetben három tanúsítványt jelent: a szolgáltató cégszámlázáshoz használt tanúsítványát, az időbélyegző-szolgáltató tanúsítványát és az ezeket kiállító hitelesítés-szolgáltatói tanúsítványokat A tanúsítványokat a szerepköröknek megfelelően felosztott kulcstárakból tölti be, melyekhez megfelelő hozzáférést kell biztosítani. A számlázó alkalmazás kiolvassa az érintett tanúsítványokból a sorozatszám-kiállító megkülönböztetett név (DN) párosokat. A listát egy szabványos OCSP kérés formájában továbbítja az OCSP szervernek. Az OCSP szerver megállapítja a kért tanúsítványok állapotát, majd szabványos üzenet formájában válaszol melyet digitális aláírással lát el. A számlázó alkalmazás leellenőrzi az OCSP szerver válaszának hitelességét. Szintén a rendelkezésére álló kulcstárból kiolvassa az OCSP szerver tanúsítványát hitelesítő tanúsítványt, melyet a válasz ellenőrzésére használ fel. Válaszban található tanúsítvány és aláírást kiolvasása után a következő ellenőrzéseket hajtja végre: 36

38 Elkészíti a válasz lenyomatát, majd az azon lévő aláírást az OCSP szerver tanúsítványában található nyilvános kulccsal dekódolja, a két lenyomatot összehasonlítja. Leellenőrzi, hogy a válaszból kiolvasott tanúsítványon szereplő aláírás tényleg a hitelesítés-szolgáltatótól származik Ha bármely ezek közül nem teljesül, akkor az OCSP szervert meghamisították, a rendszer üzemeltetőjét -ben értesíti a veszélyről, majd automatikusan leállítja magát. Ezek után a számlázó alkalmazás a válaszüzenetben található tanúsítványállapotoktól függően folytatja a működését. A tanúsítványok állapota szerint három eset lehetséges: Ha mindegyik állapota jó (good), akkor folytatódhat a számlázási folyamat Ha valamelyik állapota visszavont (revoked), akkor a számlázó alkalmazás nem képes érvényes számlákat készíteni, erről figyelmeztetnie kell a rendszert üzemeltetőjét, működését pedig felfüggeszti. Ez addig tart ameddig, az új tanúsítványok beszerzésre nem kerülnek. Ha valamelyik állapota ismeretlen (unknown), akkor ez azt jelenti, hogy a rendszer biztonsága sérült. Ebben az esetben tanúsítványokat meghamisították, azaz valaki rossz szándékkal fért hozzá a rendszerhez. A számlázó alkalmazás értesíti az rendszert üzemeltető személyt, majd az automatikusan leállítja magát. A tanúsítványok állapotának ellenőrzését az alkalmazás rendszeresen, megadott időközönként végzi el. Az OCSP válaszok tartalmazzák az adott tanúsítvány állapotának következő frissítési időpontját. Így a következő ellenőrzés mindig akkor történik, amikor a tanúsítványokhoz tartozó frissítési időpontok közül a legkésőbbi is letelt. Ezzel elkerülhető, hogy a számlázó rendszer feleslegesen kérdezze le a tanúsítványok állapotát, továbbá hogy leterhelje a cég hálózatát és a hitelesítés-szolgáltató OCSP szerverét. Hiteles OCSP válasz esetén és érvényes tanúsítványok esetén a számlázó alkalmazás elkezdheti működését. 37

39 14. ábra a számlakészítés folyamata Az számlakészítés első lépéseként a számlázó alkalmazás, a cég adatbázisából lekérdezi azon ügyfelek adatait, akiknek számlát kell kiállítani. Elvégzi az adatokon szükséges műveleteket, amelyeket az XML séma megfelelő mezőibe helyettesít be. Az így létrejött XML alapján állítja elő a számlát tartalmazó PDF dokumentumot. Ezután következik a PDF számla digitális aláírása. A számlázó program előkészíti a XAdES-nek megfelelő aláírási formátumot, amelyben a következő adatokat helyezi el: a számlázó alkalmazás tanúsítványa a hitelesítési lánc felépítéséhez szükséges hitelesítés-szolgáltató tanúsítványok a lenyomatok elkészítéséhez felhasznált algoritmus azonosítója az aláírás létrehozásához használt algoritmuspár azonosítója az adatok kódolásához, transzformációjához használt algoritmusok azonosítója 38

40 Az adatokat az aláírási formátum megfelelő elemeiben helyezi el, ezeket aláírásával hitelesíti. Az aláírást a XAdES-nek megfelelő formában csatolja a dokumentumhoz. Az alap aláírás elkészültét követően a számlázó alkalmazás időbélyegzést kér az időbélyegző-szolgáltatótól. Az aláírás lenyomatát és az lenyomatozáshoz használt függvény azonosítóját elküldi az időbélyegző-szolgáltató szerverének. Az időbélyegző szerver a bélyegzés idejét és a lenyomatot digitálisan aláírva küldi vissza válaszként. A számlázó alkalmazásnak le kell ellenőriznie az időbélyeg hitelességét. Kiolvassa az időbélyegben található tanúsítványt és az időbélyegző-szolgáltató aláírását. A tanúsítvány hitelességének ellenőrzéséhez az azt hitelesítő hitelesítés-szolgáltatói tanúsítványt használja fel, amelyet egy kulcstárban áll rendelkezésére. A hitelesség megállapítására a következő műveleteket végzi el: Elkészíti az időbélyeg lenyomatát egy meghatározott függvénnyel, amelyet az időbélyegző tanúsítványában található nyilvános kulccsal visszafejtett aláírás eredményével hasonlít össze A hitelesítés-szolgáltató tanúsítványban található nyilván kulccsal visszafejti a kiolvasott tanúsítványon szereplő aláírást, majd elvégzi a tanúsítvány lenyomatozását, a kettőt összehasonlítja Ha ezek közül valamelyik nem felel meg a feltételeknek, akkor az időbélyegző-szolgáltató szervere kompromittálódott, a rendszer -ben értesítést küld a rendszer üzemeltetőjének, majd felfüggeszti működését. Hiteles időbélyeg esetén a XAdES formátumnak megfelelő módon csatolja az időbélyeget és az időbélyegző tanúsítványát az aláírási formátumhoz, így elkészült a számla végleges formája. A hiteles számlák előállítása után a számlázó alkalmazás összeállítja a számlák kiküldésére szolgáló -eket. Ezek tartalma az ügyfél nevének címzett sablon szöveget tartalmaz, feltüntetve a számlázási időszakot. A levélhez két fájl csatol, az eredeti számlát tartalmazó PDF fájlt és az aláírt, időbélyeggel rendelkező XML fájlt. A levelek az ügyfél által megadott elérhetőségként megadott cím. címzett mezőben az ügyfél elérhetőségként megadott cím kerül. A PDF számla csatolására azért van szükség, hogy az ügyfél az olvasásakor egyszerűen tudja ellenőrizni annak tartalmát. Az -ek úgynevezett ablakokban kerülnek továbbításra a cég levelező-szerveréhez. Ezen ablakok hosszát az határozza meg, hogy a tanúsítványok érvényességének ellenőrzésre mikor kerül sor. A számlázó alkalmazás ez előbbiekben ismertetett módon, 39

41 mindig akkor kérdezi le a rendszer által használt tanúsítványok állapotát az OCSP szervertől, amikor a legkésőbbi frissítési idő is letelik. Tehát ha minden tanúsítvány rendben van, akkor az alkalmazás elküldi azokat az -eket a levelezőszervernek, amelyek a mostani és legutóbbi sikeres tanúsítványellenőrzés között készültek el. Ellenben ha bármely tanúsítvánnyal probléma van, akkor a legutóbbi sikeres állapotlekérdezés és a mostani között készült összes dokumentumot törli és automatikusan leáll. Sikeres kiküldés után, a szerver-alkalmazás a cég adatbázisában jelöli, hogy adott ügyfél számára a számla az adott időszakra elkészült. Így leállás esetén tudja, hogy honnan kell folytatnia számlázást. Ha az összes érintett ügyfél számláját elkészítette és számlákat tartalmazó -eket sikeresen továbbította a cég levelező-szerverének, akkor bontja az összes kapcsolatát és készenléti üzemmódba állítja magát Az alrendszerek felépítése A szerződéskötő rendszer komponensei A rendszer kliens-szerver alkalmazás szerinti felbontásban a következő komponensekből épül fel. 15. ábra a szerződéskötő rendszer felépítése 40

42 A számlázási rendszer komponensei A számlákat előállító rendszer funkciók szerint az alábbi komponensekre bontható. 16. ábra az elektronikus számlázó rendszer felépítése Az ügyintéző rendszer komponensei Adatbázis kliens komponens Ez a komponens biztosítja a kapcsolatot a cég adatbázis szerverével, azon belül az ügyintéző rendszer által érintett adatbázissal. Feladata az adatbázisban szereplő adatok lekérdezése és módosítása. Az eredménytáblákban szereplő adatok feldolgozása, a rendszer egyéb komponensei számára megfelelő struktúrában és formátumban való átadása. Követelmények: Az adatbázis és azt kiszolgáló szerver való hozzáférést biztosító adatok biztonságáról gondoskodni kell. A kapcsolatban fellépő hibák kezelésére a komponenst fel kell készíteni. Az eredménytáblákban megjelenő hibák kezelését meg kell oldani. A komponensnek képesnek kell lennie az cég adatbázisa által használt lekérdezőnyelv használatára. Levélküldő ügynök komponens A komponens biztosítja a cég levelező-szerverével való kapcsolatot. Feladata szabványos formátumú -ek előállítása, a levelek összeállításához szükséges adatok fogadása és az -ek továbbítása a levelező szerver felé. 41

43 Követelmények: A levelező szerverrel való kapcsolatban jelentkező hibákra fel kell készíteni a komponenst. A levelező szerverrel való kommunikációnak meg kell felelnie az SMTP protokoll szabályainak, melyet az RFC 2821 ír le. A levelek felépítésének meg kell felelnie az RFC 2822-ban leírt formátumnak. A dokumentumok az -ekhez való csatolásának meg kell felelnie a MIME RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049 alapján leírt formátumának. Tanúsítványkezelő komponens Lehetővé teszi az ügyviteli rendszer számára szükséges tanúsítványok kezelését. Feladata a tanúsítványok és a hozzájuk tartozó kulcspárok kiolvasása a betöltött kulcstárakból, a tanúsítványok hitelességének ellenőrzése, a tanúsítványokban található adatok és kulcsok átadása más komponensek számára. Követelmények: Meg kell oldani a tanúsítványok feldolgozáskor jelentkező hibákat, feldolgozás előtt ellenőrizni kell, hogy a tanúsítványok megfelelnek-e a tanúsítványok RFC 2459 leírt formátumának. Képesnek kell lennie a tanúsítványlánc felépítésére, a tanúsítványokon szereplő aláírások ellenőrzésére. A tanúsítványlánc-titkos kulcs páros eléréshez szükséges jelszó biztonságáról gondoskodni kell. Szerződés aláíró komponens A kliens oldalon készíti el az alap aláírási formátumot. Feladata az aláírást tartalmazó XML struktúra előkészítése, ehhez a szerződés dokumentum és az aláíráshoz szükséges adatok megfelelő formátumban való csatolása, az ügyfél tanúsítványa alapján az aláírás elkészítése, az aláírást tartalmazó dokumentum megfelelő formátumban történő átadása más komponensek számára. Követelmények: Az aláírást tartalmazó XML struktúrának meg kell felelnie a XAdES-BES formátumnak. Az aláírási formátum egyes elemeinek létrehozásához szükséges transzformációs algoritmusokat a komponensnek meg kell valósítania. 42

44 Szerződés ellenőrző komponens A szerver oldalon végzi el a kliens oldalon készített aláírás hitelességét. Feladata az aláírási formátum ellenőrzése, az abban található aláírás ellenőrzése, az XML struktúrában lévő tanúsítványok és adatok kiolvasása, hitelességük vizsgálata. Követelmények: Az XML dokumentum beolvasásakor jelentkező hibákra a komponenst fel kell készíteni. Biztosítani kell, hogy a komponens képes legyen a XML struktúrában található tanúsítványok kiolvasására és azok tanúsítványláncának felépítésére. Továbbá az aláíró tanúsítványáról meg kell tudja állapítani, hogy megbízható hitelesítésszolgáltatótól származik-e. Meg kell tudnia állapítani, hogy az XML struktúrában lévő aláírás, az eredeti szerződésdokumentumra vonatkozik-e. Szerződés véglegesítő komponens A szerver oldalon elkészíti a végleges aláírási formátumot. Feladata az alap aláírási formátumra alapozva, a végleges XML formátum előkészítése, az aláíráshoz szükséges csatolása megfelelő formátumban, a szerződéskötő rendszer alapján a struktúra aláírása, majd a dokumentumon található aláírások időbélyegzése, az így elkészült dokumentum megfelelő formában történő átadása más komponensek számára. Követelmények: Az XML struktúrában szereplő aláírásoknak a XAdES-BES, az időbélyegzett aláírásoknak pedig a XAdES-T formátumnak kell megfelelnie. A komponensnek implementálnia kell az aláírás formátum egyes elemeink előállításához szükséges transzformációs, és az időbélyegek előállításához szükséges XML kanonikalizációs algoritmusokat. Visszavonási állapot ellenőrző komponens A tanúsítványok visszavonási állapotát ellenőrzi le. Feladata a szabványos OCSP kérés előállítása, az OCSP szerverrel való kapcsolat megvalósítása, a válasz feldolgozása, hitelességének ellenőrzése, a válaszban található állapotok átadása más komponensek számára. Követelmények: Az OCSP szerverrel való kapcsolat hibáira a komponenst fel kell készíteni. 43

45 A szerverrel való kommunikációnak és az OCSP kérés felépítésének meg kell felelnie a RFC 2560 által leírt formátumnak. A válaszok feldolgozásakor jelentkező hibák kezelésére képesnek kell lennie. Az OCSP válaszon található aláírás és a benne található tanúsítvány kiolvasására és hitelességének ellenőrzésére a komponensnek képesnek lennie. SSL kapcsolat esetén meg kell valósítani a tanúsítvány alapú azonosítást. Időbélyegző komponens Az aláírások időbélyegzését valósítja meg. Feladata a szabványos időbélyegző kérések összeállítása, az időbélyegző szerverrel való biztonságos kapcsolat (SSL) létrehozása, az időbélyegek feldolgozása, azok hitelességének ellenőrzése, az időbélyeg megfelelő formátumban való átadása más komponensek számára. Követelmények: Az időbélyegző szerverrel felépített kapcsolat hibáinak kezelésére a komponenst fel kell készíteni. Az időbélyegző szerverrel való kommunikációnak és az időbélyegzés kérés felépítésének meg kell felelnie a RFC 3161 által leírt formátumnak. A válasz feldolgozásakor jelentkező hibák kezeléséről gondoskodni kell. A komponens képes kell, hogy legyen az időbélyegzőben található tanúsítvány és az azon lévő aláírás kiolvasására, hitelességének ellenőrzésére. Az SSL kapcsolat esetén képesnek kell lennie a tanúsítvány alapú azonosítás megvalósítására. Szerződésdokumentum előállító komponens A komponens az ügyfelek adataival kiegészített szerződések elkészítéséért felelős. Feladata a sablon XML dokumentum feldolgozása, a szerződésszöveg kiegészítése az ügyféladatokkal, ezek alapján a PDF dokumentum elkészítése, a dokumentum rendelkezésre bocsátása más komponensek számára. A szerződés ellenőrzéséhez elkészíti a dokumentum lenyomatát. Követelmények: A sémát tartalmazó XML fájlhoz és a szerződés előállításhoz szükséges egyéb adatfájlokhoz (képek, grafikák) a komponens számára hozzáférést kell biztosítani, azok biztonságáról gondoskodni kell. A feldolgozás előtt le kell ellenőrizni, hogy a beolvasott XML dokumentum, csak komponens által feldolgozható elemeket tartalmaz. 44

46 Az előállított PDF szerződésdokumentumoknak meg kell felelnie a PDF 1.7-es vagy más néven ISO :2008 szabványnak. Kulcstár kezelő komponens A szoftveres kulcstárak fájlrendszerről történő elérését biztosító komponens. Feladata a szoftveres kulcstárak beolvasása, a kulcstárban található tanúsítványok álneveinek kigyűjtése, a lista és a kulcstár megfelelő formátumú átadása más komponensek számára. Minden a rendszer által támogatott kulcsártípus formátumának kezelését meg kell oldani. Az olvasáskor vagy a megnyitáskor jelentkező hibákra a komponenst fel kell készíteni. A kulcstárhoz tartozó jelszó biztonságáról gondoskodni kell. Számla előkészítő komponens A komponens az elektronikus számlák nyers, ember által olvasható formáját készíti el. Feladata egy megadott XML séma alapján, a külső forrásból és más komponensektől átvett adatokból, egy meghatározott felépítésű számladokumentum előállítása, ezen dokumentum illetve az előállításkor felhasznált, nem szöveges külső adatok elmentése egy szabványos PDF formátumban. Továbbá az adatok fogadása és az elkészült PDF fájlok rendelkezésre bocsájtása más komponensek számára. Követelmények: Az számlához előállításához XML sémát és az egyéb felhasználandó adatokat (képek, grafikák) tartalmazó fájlokhoz a komponensnek hozzáférést kell biztosítani. Ezek biztonságáról gondoskodni kell. A komponensnek a feldolgozás előtt le kell ellenőrizze, hogy a felhasználandó adatokat tartalmazó fájlok sértetlenek, megfelelnek saját fájlformátumuknak. Az előállított PDF számladokumentumoknak meg kell felelniük a PDF 1.7-es vagy más néven ISO :2008 szabványban leírt formátumnak. Végleges számla előállító komponens E komponens készíti el a számla végeleges, aláírt és időbélyegzett változatát. Feladata a hiteles számladokumentum összeállításhoz szükséges adatok illetve ezekhez kapcsolódó meta adatok átvétele, továbbá egyéb, nem a számlakészítési folyamhoz kapcsolódó adatok beszerzése, ezek megfelelő formátumba és struktúrába szervezése, majd ezen dokumentum szabványos XML formátumba mentése, ezen XML dokumentumok rendelkezésre bocsátása más komponensek számára. 45

47 Követelmények: A digitális aláírást tartalmazó XML dokumentum felépítésének meg kell felelnie XAdES-BES formátumnak. A digitális aláírást és időbélyegzést is tartalmazó XML dokumentum felépítésének meg kell felelnie a XAdES-T formátumnak. Az aláírási formátumok egyes elemeihez szükséges transzformációs algoritmusokat a komponensnek meg kell valósítania. Szerver kapcsolati komponens Ez a komponens tartja a kapcsolatot kliens oldalon a szerver-alkalmazással. Feladata a kiszolgáló alkalmazáshoz való kapcsolódás biztonságos csatornán keresztül, az attól kapott adatok átvétele, rendelkezésre bocsátása más komponensek számára, továbbá a kliens oldalon lévő komponensektől kapott adatok és fájlok továbbítása a kiszolgáló alkalmazás felé. Követelmények: A kliens és a szerver alkalmazás kapcsolatában jelentkező hibák kezelésére a komponenst fel kell készíteni. A kliens munkamenet azonosítóját, minden kéréshez mellékelni kell A kiszolgáló alkalmazástól kapott adatok biztonságáról gondoskodni kell. Kliens kiszolgáló komponens Ez a komponens a szerver oldalon tartja a kapcsolatot a kliens alkalmazásokkal. Feladata a kliens alkalmazások kéréseinek kiszolgálása biztonságos csatornán, a munkamenetek(session) kezelése, adatok fogadása a kliensektől, továbbítása más komponensek számára, az ezektől kapott adatok továbbítása a kliens alkalmazások felé. Követelmények: A komponenst fel kell készíteni a kiszolgáló és a kliens alkalmazások közötti kapcsolat hibának kezelésére. A munkamenet azonosítók alapján, számon kell tartani a szerződéskötési folyamatot indító klienseket, hogy a kéretlen kérések kiszűrhetők legyenek. Az kliensektől átvett adatok megfelelőségét le kell ellenőrizni, csak olyanok kerülnek átvételre, amelyeket a hiteles kliensek állítottak elő. Szerződésmegjelenítő komponens 46

48 A komponens az ügyfelek számára előkészített szerződést jeleníti meg a kliensalkalmazásban. Feladata a kliens alkalmazásban a PDF szerződésfájl pontos megjelenítése, a dokumentumban való navigálás megoldása. Követelmények: A komponensnek meg kell tudnia jeleníteni a PDF dokumentumban lévő összes elemet, olyan módon, ahogy azt a dokumentumban definiált formátumuk előírja. Képesnek kell lennie a felhasználói felület komponenssel való együttműködésre. Felhasználói felület komponens E komponens a kliens alkalmazás és az ügyfél közötti kapcsolatot valósítja meg. Feladata az ügyféllel való interakcióhoz szükséges grafikus elemek megjelenítése, az ügyfél akcióinak lekezelése, ennek alapján a szerződéskötési folyamat kliens oldali vezérlése, az ügyfél által bevitt adatok átvétele és feldolgozása, ezek átadása megfelelő struktúrában és formátumban más komponensek számára. Továbbá az ügyfél folyamatos tájékoztatása a szerződéskötés fázisairól. Követelmények: Az ügyfél által bevitt adatokat a komponensnek le kell ellenőrizni, csak olyan adatok kerülhetnek átvételre, amelyek formátuma és tartalma megegyezik a feldolgozni kívánt adatokéval. Az fájlrendszerrel kapcsolatos akciók kezeléséhez, a komponensnek párbeszédablakokat kell biztosítania. Dokumentum elhelyező komponens A végleges dokumentumokat egy meghatározott tárolón lévő fájlrendszerre menti. Feladata a más komponensektől kapott dokumentumok fájlrendszerre mentése, megfelelő beszédes elnevezéssel, megfelelő könyvtár struktúrában történő elhelyezése. Követelmények: Meg kell oldani az esetleges, tárolóhoz való hozzáféréshez szükséges azonosító adatok biztonságát. A tárhely eléréséhez esetlegesen szükséges protokoll használatára fel kell készíteni a komponenst Az ügyviteli rendszer működéséhez meghatározása 47 szükséges feltételek

49 Ahhoz hogy egy szolgáltató cégnél az előbbiekben bemutatott rendszer megvalósítható legyen, meg kell határozni azokat a feltételeket, amelyek a rendszer működéséhez szükségesek: A szerződéskötő és a számlázó alkalmazások számára szükséges egy-egy megbízható alkalmazás-szerver, amely a számos kriptográfiai művelet ellenére is képes magas teljesítményt nyújtani. Be kell szerezni a rendszer működéséhez szükséges tanúsítványokat, amelyeket szoftveres kulcstárakban helyezünk el: A szerződéskötő és a számlázó rendszer számára egy-egy aláíró tanúsítvány igénylése szükséges. A szerződéskötő rendszert kiszolgáló alkalmazás-szerver számára szükséges egy SSL tanúsítvány, amely az ügyfelek és a szerver között biztonságos a kommunikációról gondoskodik. Mind a számlázó, mind a szerződéskötő rendszer számára szükséges egy authentikációs tanúsítvány, az időbélyegző-szerver illetve az OCSP szerverek használatának igénybevételéhez. Szükséges egy megfelelő adatbázis szerver, amellyel mind a szerződéskötő, mind a számlázó rendszer együtt tud működni. Ezek számára az adatbázis szerverhez, és az adatbázishoz megfelelő hozzáférési jogokat kell biztosítani. Az adatbázis szerveren tárolt adatbázisban a következő három tábla szükséges. Ügyfél tábla, ebben találhatók az ügyfelek adatai, elérhetőségei. Egy rekord minimum az ügyfél azonosítóját, a nevét és egy címet kell, hogy tartalmazzon. Ezen felül a számlázó rendszer számára szükséges egy külön mező annak jelzésére, hogy az adott számlázási időszakban a számla az ügyfél részére elkészült. Szolgáltatás tábla, ebben találhatók a cég által nyújtott szolgáltatások adatai. Egy rekord minimum egy szolgáltatás azonosítót és egy szolgáltatási díjat kell, hogy tartalmazzon. Szerződés tábla, amiben az ügyfelek és a szolgáltatások összerendelései találhatók. Egy rekord minimum az ügyfél azonosítóját, a szolgáltatás azonosítóját és a szerződéshez azonosítót és annak titkosított lenyomatát kell, hogy tartalmazza. Továbbá szükséges még egy mező a szerződés státuszának jelzésére. 48

50 Szükséges egy levelező szerver, amellyel mind a szerződéskötő mind a számlázó rendszer együtt tud működni. A levelező szerveren mind a számlázó, mind a szerződéskötő rendszernek egy-egy postafiókot kell létrehozni, ehhez hozzáférési jogokat kell biztosítani. Szükséges egy fájlszerver, ahol az elektronikus szerződések, illetve az elektronikus számlák biztonságosan tárolhatók. A számlázó és szerződéskötő rendszernek megfelelő kvótát kell biztosítani adatok tárolásához, a tárhelyhez megfelelő hozzáférési jogokat kell biztosítani számukra. 49

51 3. A megvalósítás környezete 3.1. A cég rövid bemutatása A szóban forgó cég web-tárhely és domain regisztrációs szolgáltatásokat nyújt magán és céges ügyfelei számára. Ügyfélkörük nagyjából 5000 főre telhető, az általuk kiszolgált weboldalak száma meghaladja a 6000-et, így a web-szolgáltatók piacán igen komoly piaci pozíciót szereztek meg. Havi szinten átlagosan 100 új szerződést kötnek, ami hozzásegítette a céget a gyors növekedéshez. Azonban az ügyfelek egyre növekvő száma igencsak komoly kihívás elé állította a cég adminisztrációját. A magas ügyfélszám ellenére a cég maga relatíve kicsinek számít, kevesebb mint 12 alkalmazottal, akiknek munkája ebben a helyzetben nagyrészt az ügyintézéssel kapcsolatos feladatok megoldásában nyilvánul meg, eredeti munkájuk elvégzése helyett(szolgáltatások fejlesztése, rendszerek karbantartása). Amennyire lehetséges volt kihasználták a digitális technológiák által kínált lehetőségeket, mint például -es ügyfélszolgáltat, saját fejlesztésű elektronikus számlázó rendszer, web-oldalról letölthető szerződés formanyomtatványok, ezek azonban önmagukban nem voltak képesek a helyzeten számottevően változtatni. A probléma forrása a szerződéskötés és a számlázás megoldásában keresendő A jelenlegi ügyintézés Az ügyfélszerződés megkötésének menetére a lehetőségekhez képest kreatív, egyszerű megoldást dolgoztak ki. A szerződéskötés menete a következő: Az ügyfél, ha a webtárhelyéhez igényelni szeretne új domain-t, akkor első lépésben ellenőriznie kell, hogy a kívánt domain még szabad e, ezt a cég weboldalán feltüntetett oldalakon keresztül teheti meg. A cég weboldaláról letölthető a szerződés több elektronikus dokumentum formájában, ezt az ügyfélnek értelemszerűen kell kitöltenie, kinyomtatnia, és aláírásával hitelesítenie. Az aláírt szerződést postán el kell visszaküldenie a cég számára. A szerződéshez személyigazolvány szükséges vagy igazoló cégbírósági papírok végzés) vagy igazolványok fénymásolatát az (például elküldött szerződéshez mellékelve, faxon vagy ben lehet elküldeni. A beérkező igényeket az ügyfélszolgálaton dolgozzák fel, ellenőrzik a szerződések és a csatolmányok megfelelőségét. Probléma esetén felveszik a kapcsolatot az 50

52 ügyfelekkel. Megfelelő szerződés és mellékletek esetén, az ügyfél és a megrendelés adatai kézzel kerülnek rögzítésre a cég adatbázisában. Cég ezek után megkezdi az ügyfél által rendelt szolgáltatás beüzemelését (domain regisztrációja, webtárhely előkészítése). Azonban ezeket csak akkor veheti igénybe az ügyfél, ha a szerződésben rögzített szolgáltatási díjat a cég számlájára átutalja. Az ügyfél átutalja a szolgáltatási díjat. A cég megkapja a tranzakciót igazoló SMS-t a céges telefonra, az összegből és a visszaigazolásban található adatok alapján azonosítja a megrendelőt. Az ügyfél számára kiállítják a megrendelésről szóló számlát, a cég képviselője aláírással hitelesíti a szerződést, e két dokumentumot a tárhelyhez való elérhetőségekkel együtt, az ügyfél által megadott címre postázzák. Egy online szolgáltató cég esetében, a papír alapú ügyintézéshez való kötődés jelenti az igazi problémát. Ugyan is hiába használnak elektronikus megoldásokat az ügyintézésben, ha a dokumentumokat kinyomtatott formában kell hitelesíteni. Azonban a digitális aláírás alapú ügyintéző rendszer bevezetése megoldást jelenthet a helyzetre. A cég vezetése fiatalos összetettsége révén, nyitott az új megoldásokra, így a rendszer kísérleti jellegű bevezetése mellett döntöttek. Azonban azt szeretnék, hogy a rendszer a jelenlegi megoldások mellet párhuzamosan kerüljön bevezetésre. Így mivel a szerződéskötés a legproblémásabb terület, ezért először a szerződéskötő rendszer kerül megvalósításra A cég informatikai infrastruktúrája A megvalósítás előtt meg kell vizsgálni, hogy a cég jelenlegi informatikai infrastruktúrája alkalmas-e a szerződéskötő rendszer megvalósítására. A cég két helyszínen rendelkezik számítástechnikai eszközökkel. Szerverpark 10 multifunkcionális szerver, amely az ügyfelek web-oldalait szolgálja ki, ezeken CentOS operációs rendszer fut. A szervereken elosztottan találhatók a weboldalak kiszolgálásához szükséges web, adatbázis és levelezőszerverek (Apache, PHP, MySQL). egy menedzsment szerver, amely a multifunkcionális szerverek vezérlését látja el, rajta keresztül a kiszolgáló gépek web-es felületen elérhetők. A szerveren Ubuntu Server Edition operációs rendszer fut. 51

53 egy fájlszerverként működő célszámítógép, amelyre a szervereken található adatok biztonsági mentését végzik. minden szervernek, kivéve a fájlszervert, közvetlen csatlakozása van az Internetre, a tűzfal funkcióját a számítógépekre telepített Iptables alkalmazás látja el. a gépek közötti belső kommunikációt egy switch teszi lehetővé. 17. ábra a cég informatikai infrastruktúrája Iroda 12 munkaállomás, PC és Apple számítógépek vegyesen, Windows és Mac OSX operációs rendszerekkel. Ezekkel történik a szerverparkban található gépek üzemeltetése, az ügyintézéssel kapcsolatos feladatok ellátása. egy adatbázis szerver, az ügyfelek és a szerződések adatainak tárolására. A szerveren Ubuntu operációs rendszer és MySQL adatbázis szerver fut. egy fájlszerver, amelyeken az ügyfelek által küldött azonosító dokumentumok és szerződések digitalizált változatát tárolják, ezt a szerepet szintén egy célszámítógép látja el. 52

54 a munkaállomások egy router-en keresztül csatlakoznak az Internetre, az irodán belüli hálózaton egy switch köti össze a számítógépeket, a fájlszerver és az adatbázisszerver a külső hálózattól elszigetelten található, csak a belső hálózatban elérhetők. A szerződéskötő rendszer nyilvánvalóan a szerverparkba kerül, az ügyfelek által generált forgalom csak onnan szolgálható ki hatékonyan. Mivel azonban az ügyfelek adatait tartalmazó adatbázis az irodában a külső hálózattól elszigetelten található, a szerződéskötő rendszer nem lesz képes az ügyfelek és a szerződésadatok automatikus rögzítésére, így ezt a feladatot továbbra is a cég ügyfélszolgálatának kell ellátnia. Itt a végleges szerződések tárolására a biztonsági mentést szolgáló célszámítógépet jelöljük ki. Levelezőszerverként az egyik kitüntetett szerepű multifunkcionális szerver szolgál, amely a cég levélforgalmát is bonyolítja. Így kompromisszumok árán, de a cég infrastruktúrája alkalmas a rendszer megvalósítására. 53

55 4. Az online szerződéskötő rendszer megvalósításához szükséges feltételek megteremtése 4.1. A felhasznált eszközök A Sun Java platform A Java objektum orientált programozási nyelv, amelyet eredetileg a Sun Microsystems fejlesztett ki. A Java alkalmazásokat úgynevezett bájt kódra fordítják le, amely az egyes rendszerek között szabadon hordozható, így az alkalmazások platform függetlenné válnak. A bájtkód gépi kódra fordítását és futtatását Java virtuális gép (Java Virtual Machine JVM) végzi, ami leggyakrabban használt operációs rendszer típusokban alapértelmezetten megtalálható. A nyelvben nagyon sok funkció szabványos programkönyvtárak formájában alapértelmezetten implementálva van, például grafikus felületek, szál-és hálózatkezelés, ami megkönnyíti az alkalmazások fejlesztését. [12] A Java hivatalos weboldala: Netbeans IDE A Netbeans IDE egy Java nyelven írt nyílt forráskódú integrált fejlesztő környezet (Integrated Development Environment), amelyet a Sun ingyenesen elérhetővé tett a Java alkalmazás fejlesztők számára. Támogatja az összes Java alkalmazástípust (asztali, web és mobil alkalmazások), emellett más programozási nyelveket is, mint például, C, Python Groovy, PHP, JavaScript. Moduláris felépítése révén beépített funkciók mellett, mint a grafikus felhasználói felület szerkesztő (GUI Editor) vagy a verziókövető rendszer (CVS), a fejlesztőkörnyezet új elemekkel bővíthető. Az alkalmazás a CCDL licensz feltételei alapján használható fel. [13] A Netbeans hivatalos weboldala: Apache Tomcat A Tomcat az Apache Foundation által kifejlesztett Java nyelven írt ingyenes alkalmazás/web-szerver. Megvalósítja a Sun Servlet és Java Server Pages specifikációit, így lehetővé teszi Java alapú web alkalmazások futtatását. Mivel Java nyelven íródott, ezért az összes Java platformot támogató rendszeren képes futni. [14] Az Apache Tomcat hivatalos weboldala: A rendszer javasolt felépítése A szerződéskötő rendszert a szerver-kliens jellege miatt érdemes egy Applet Servlet webalkalmazás párossal megoldani. Ez lehetővé teszi, hogy a szerződéskötő rendszer bármely Java platformot támogató rendszertípusból elérhető legyen. 54

56 A web-alkalmazás szerkezete a következő: /META-INF a Servlet kontextust leíró állományok /WEB-INF a Servlet saját lefordított osztályai és külső programkönyvtárait tartalmazó könyvtár /Keystores a web-alkalmazás saját kulcstárai /TrustStores hitelesítés-szolgáltatók tanúsítványait tartalmazó kulcstárak /XML a szerződés sémát tartalmazó könyvtár index.html az Applet-et beágyazó HTML dokumentum applet.jar az Applet lefordított osztályai tartalmazó tömörített fájl appletlibrary.jar az Applet által használt programkönyvtárak A kliensként működő Applet-et egy HTML oldalba ágyazzuk be, amit a Servlet web könyvtárának indexének (index.html) jelöljük ki, így mikor az ügyfél böngészője kapcsolatot akar teremteni a Servlet-tel, az HTML oldalt letöltve a beágyazott Applet-et is letölti. Innentől a már az Applet és a Servlet kommunikál egymással. Az Applet osztályait és által külső program könyvtárakat tartalmazó JAR fájlokat digitálisan alá kell írni, különben a biztonsági korlátozások miatt az Applet nem lesz képes teljes értékű alkalmazásként futni. Ezeket a fájlokat a web-alkalmazás gyökér könyvtárában kell elhelyezni, hogy az ügyfél böngészője képes legyen ezek eltöltésére. A Servlet saját tanúsítványait a /KeyStores könyvtárban, az ellenőrzéshez használt hitelesítés-szolgáltatói tanúsítványokat a /TrustStores mappában tesszük az elérhetővé. Az XML mappában a szerződés előállításához használt XML dokumentumot helyezzük el. Az így létrejött struktúrát egy WAR típusú web-alkalmazás archívumba csomagoljuk. A web alkalmazást egy Apache Tomcat szerverre telepítjük fel, amely egy virtual host-ot szolgál ki, a címe a szerzodeskotes.cegnev.hu szerkezetet követi. Ezen a virtual host-on két web kontextust hozunk létre: /, azaz ROOT, ide telepítjük a szerződéskötő rendszernek megfelelő Applet-Servlet párost /manager, ezen a címen a Tomcat szerver beépített menedzsment alkalmazása érhető el, ezzel történik majd a szerződéskötő rendszer telepítése az alkalmazásszerverre Mindkét web-alkalmazás csak és kizárólag SSL kapcsolaton keresztül érhető el. A Tomcat beépített menedzsment alkalmazását csak a cég menedzsment szerveréről lehet elérni, jelszavas azonosítással Az alkalmazás-szerver előkészítése A kiszolgáló jellemzői Az alkalmazás-szervert egy Dell PowerEdge SC440 típusú szerver számítógép szolgálja ki, amelyet a cég tartalék számítógépei közül használtunk fel. Főbb műszaki paraméterek: 55

57 Dupla magos Intel Xeon ,4 GHz processzor 4 GB ECC DDR2 memória 2*600GB SAS SCSI RAID0 merevlemez A szerveren előre telepített Ubuntu Server Edition 8 operációs rendszer található. A kiszolgáló tűzfalaként a rendszerre telepített Iptables alkalmazás gondoskodik. Erre a szerverre telepítjük az Apache Tomcat alkalmazás-szerver 6-os verzióját Az Apache Tomcat szerver telepítése A Tomcat szerver működéséhez szükség van a Sun Java JDK legújabb verziójának telepítésére. Ezt az Ubuntu beépített csomagkezelőjének, az apt segítségével telepítjük fel. sudo apt-get update /a csomaglisták frissítése sudo apt-get install sun-java6-jdk /a Java 6 környezet telepítése A csomaglisták frissítéséhez és csomagok telepítéséhez rendszergazdai jogosultság szükséges. Alapértelmezetten az Ubuntu Server Edition Linux disztribúcióban a root felhasználóként való bejelentkezés biztonsági okokból le van tiltva, ezért szükséges a sudo alkalmazás használata a különböző a rendszer működését befolyásolható parancsok kiadása előtt. Ezzel az admin csoportba tartozó felhasználók rendszergazdai jogokkal futtathatnak alkalmazásokat.[15] A Tomcat telepítése manuálisan történik, a Tomcat projekt hivatalos oldaláról, a található tükörszerverek egyikéről töltjük le a futtaható binárist tartalmazó csomagot. wget /a csomag letöltése az aktuális könyvtárába wget /a csomag aláírt lenyomatának letöltése Mielőtt kicsomagolnánk a tömörített fájlt, le kell ellenőrizni, hogy a csomag hivatalos kiadás. Mindenekelőtt le kell tölteni az Apache alapítvány hivatalos oldaláról, a Tomcat fejlesztőinek nyilvános kulcsait tartalmazó fájlt. Majd a kulcsokat tartalmazó fájl alapján meg kell győződni, hogy a tükörszerveren lévő kiadást egy arra jogosult személy, tehát a projekt egyik tagja készítette e. Erre a gpg nevű alkalmazást használjuk fel. 56

58 sudo apt-get install pgpgpg / a gpg alkalmazást tartalmazó csomag telepítése wget / a nyilvános kulcsokat tartalmazó fájl letöltése gpg -import KEYS / kulcsok importálása gpg -verify apache-tomcat tar.gz.asc / az aláírás ellenőrzése Ha az aláírás nem megfelelő, akkor keresni kell egy másik tükörszervert. Sikeres ellenőrzés esetén folytatódhat a Tomcat telepítése. tar xzvf apache-tomcat tar.gz.asc / a tömörített állomány kicsomagolása mv apache-tomcat /usr/local/tomcat / a Tomcat fájljainak áthelyezése A Tomcat szerver futtatásához be kell állítani a JAVA_HOME környezeti változót. Ehhez létre kell hozni a setenv.sh shell-script fájlt a Tomcat /bin könyvtárában és hozzá kell fűzni a változót létrehozó parancsot. echo export JAVA_HOME=/usr/lib/jvm/java-6-sun > setenv.sh / a shellscript fájl létrehozása chmod 755 setenv.sh / a hozzáférési jogok beállítása mv setenv.sh /usr/local/tomcat/bin / a shell-script átmozgatása a Tomcat /bin könyvtárába Ahhoz, hogy a Tomcat szerver az rendszer indításakor automatikusan elinduljon, szintén készíteni egy parancsfájlt. Ezt érdemes valamilyen egyszerű szövegszerkesztővel elkészíteni. apt-get install vim / a vim szövegszerkesztő letöltése sudo vim /etc/init.d/tomcat / a parancsfájl létrehozása A fájl tartalma: 57

59 #!/bin/sh case $1 in start) sh /usr/local/tomcat/bin/startup.sh ;; stop) sh /usr/local/tomcat/bin/shutdown.sh ;; restart) sh /usr/local/tomcat/bin/shutdown.sh sh /usr/local/tomcat/bin/startup.sh ;; esac exit 0 Ezután szimbolikus linket kell létrehozni a scriptfájlról az /etc/init.d könyvtárban. chmod 755 /etc/init.d/tomcat / hozzáférési jogok hozzárendelése ln s /etc/init.d/tomcat /etc/rc2.d/s99tomcat / link létrehozása a parancsfájlról az alapértelmezett runlevel indítóscriptjeinek könyvtárában Ezek után a Tomcat szerver a rendszer indításával vagy újraindítása eseten automatikusan elindul A Java környezet konfigurálása A szerver telepítésének befejeztével, meg kell adni a szervert kiszolgáló Java környezetre vonatkozó beállításokat, ezeket a Tomcat indítási paraméterin keresztül tehetjük meg. Az első fontos beállítás a Tomcat-et futtató JVM által használt memória mennyiségének beállítása. Ez alapértelmezetten maximum 64 MB-ra van állítva. Nyilvánvalóan ez nem elég egy önálló módban futó alkalmazásszerver számára. Ennek beállítására két paraméter használható: az egyik a Xms, ami a minimum lefoglalt memóriát jelenti, amit a JVM induláskor lefoglal a másik pedig a Xmx azaz a JVM által maximálisan lefoglalható méret. A minimumot érdemes önálló szerver esetén a rendszer memóriájának az 60 és 75%-a közé tenni, amely a rendszer memóriájának méretéről függ. 4GB memória esetén megengedhető a felső határ, ami 3GB. A maximum 75-90% között lehet, mivel az operációs rendszer és egyéb folyamatok számára is hagyni kell elegendő mennyiségű memóriát, nem megengedhető, hogy a rendszer instabillá váljon. Itt is meghagyható a 58

60 90%-os felső határ, ez 4GB esetén 3600MB. Így, ha a Tomcat-nek szüksége van még memóriára, további 1,4GB-ot kérhet az operációs rendszertől. A második fontos paraméter a server, a Server Mode beállítása. Ennek megadására a Tomcat-et futtató JVM különböző futtató környezet optimalizációkat végez. Így a szerver lassabban kerül indításra, azonban a szerveren futó alkalmazások jobb teljesítményt nyújtanak. A paramétereket a CATALINA_OPTS környezeti változóban kell megadni, melyet létrehozó parancsot, a Tomcat /bin könyvtárában lévő setenv.sh nevű parancsfájlhoz kell hozzáfűzni. echo export CATALINA_OPTS=\ -Xms3000m Xmx3600m server\ >> /usr/local/tomcat/bin/setenv.sh A Tomcat szerver konfigurálása A Tomcat könyvtárában /conf alkönyvtárban találhatók a szerver konfigurációs fájljai. A server.xml a Tomcat fő konfigurációs állománya, ebben azok a beállítások találhatók, amelyek magára az alkalmazás-szerver működésére vonatkoznak. A legfelső szintű elem a <Server>, amelynek alapértelmezetten két attribútuma van. <Server port="8005" shutdown="shutdown"> A shutdown attribútum a szerver leállításához használt kódszót, a port pedig azt a portot adja meg, amelyen a szerver ezt a kódszót várja. A kódszó hatására a szerver leállja magát. Habár csak helyi gépen lehet használni, azonban minden Tomcat szerver alapértelmezetten ezzel a kódszóval van konfigurálva, biztonsági okokból érdemes megváltoztatni. A <Service> elem egy gyűjtőelem, amely <Connector> elemeket és pontosan egy <Engine> elemet tartalmaz. A <Connector> elemek írják le azokat a portokat és azokhoz tartozó protokollokat, amelyeken a Tomcat szerver kéréseket fogad. A <Service> elemben két <Connector> elemet kell létrehozni. Connector port="80" protocol="http/1.1" connectiontimeout="20000" redirectport="443" URIEncoding="UTF-8" /> Ezzel az elemmel létrehozunk egy csatolót, amely az alapértelmezett HTTP porton fogad kéréseket. Az URIEncoding attribútumban az URI kódolását adhatjuk meg, amelyet UTF8-ra kell álltani, mivel a szerver és kliens alkalmazások közötti üzenetek UTF-8-as kódolásúak lesznek. 59

61 <Connector port="443" protocol="http/1.1" maxthreads="100" keystoretype="pkcs12" scheme="https" secure="true" SSLEnabled="true" keystorefile="${catalina_home}/certs/sslcert.p12" keystorepass="ssl" clientauth="false" sslprotocol="tls" URIEncoding="UTF-8" /> Ez az elem az alapértelmezett HTTPS csatolót hozza létre. A szerver tanúsítványát tartalmazó fájl típusát a keystoretype attribútummal adjuk meg, ez egy PKCS12 típusú fájl lesz, az eléri útját a keystorefile attribútummal adhatjuk meg, a hozzáféréshez szükséges jelszót pedig a keystorepass attribútum tartalmazza. Az SSLEnabled attribútummal kapcsoljuk be az SSL használatát, a secure attribútummal adjuk meg, hogy a kapcsolat titkosított legyen, sslprotocol-lal az SSL típusát, ami TSL protokoll kell, hogy legyen, a clientauth-tal pedig letiltjuk a kliensek azonosítását. A maxthreads attribútummal megadjuk, hogy a szerver maximum 100 kérést szolgálhat ki egyszerre. A <Engine> elem szintén egy gyűjtőelem, amelyben egy <Host> és egy <Realm> elemet kell megadni. Alapértelmezetten két attribútuma van a name, amit a naplózás és a menedzsment-alkalmazások használnak. A defaulthost pedig az alapértelmezett virtual host-ot adja meg, azaz azt a kiszolgálónevet, amely a szerverhez érkező kéréseket alapesetben szolgálja ki. Itt az alkalmazás-szerver FQDN nevét adjuk meg. <Engine name="catalina" defaulthost="szerzodeskotes.cegnev.hu"> A <Realm> elem biztonsági, elsősorban authentikáció definíciós célokat szolgál, megadjuk a védett web alkalmazásokhoz szükséges azonosító információk kezelési módját. <Realm classname="org.apache.catalina.realm.userdatabaserealm" digest="md5" resourcename="userdatabase"/> A classname az azonosító információkat kezelő Java osztályt adjuk meg. A UserDataBaseRealm az alapértelmezett osztály, ez a Tomcat /conf/tomcat-users.xml fájlban lévő azonosító információkat kezeli. A digest attribútummal megadjuk, hogy a fájlban lévő jelszavak MD5 algoritmus szerinti lenyomataik szerint vannak tárolva, ezt is elsősorban biztonsági okokból célszerű használni. A <Host> elemmel virtual host-okat hozhatunk létre. Mivel ezen a szerver csak egy virtual host fog kiszolgálni, ezért csak egy <Host> elemet hozunk létre, amely a <Engine> elem defaulthost attribútumában hivatkozunk. 60

62 <Host name="szerzodeskotes.cegnev.hu" appbase="webapps" unpackwars="true" autodeploy="false" xmlvalidation="false" xmlnamespaceaware="false"> Ebben az esetben a virtuális host-on futó alkalmazások alapértelmezett helyét a Tomcat /webapps könyvtárának adjuk meg. Az unpackwars attribútummal engedélyezzük, hogy a tömörített formátumú Java web alkalmazások a telepítést követően automatikusan kicsomagolásra kerüljenek, ez javítja a szerver teljesítményét. Le kell tiltani az autodeploy attribútum alkalmazásával, hogy a Tomcat automatikusan elindítsa az új vagy megváltozott konfigurációjú web alkalmazásokat, erre biztonsági okokból van szükség. A xmlvalidation és xmlnamespaveaware letiltjuk a XML konfigurációs állományok validálását és a bennük található névterek ellenőrzését. A tomcat-users.xml fájlban találhatók a védett web alkalmazásokhoz tartozó felhasználói és hozzáférési jog definíciók. <tomcat-users> <role rolename="manager"/> <user username="admin" password="098f6bcd4621d373cade4e832627b4f6" roles="manager"/> </tomcat-users> A <role> elemmel létrehozzuk a manager nevű jogkört, amely a Tomcat beépített menedzsment alkalmazásához ad hozzáférési jogot. Csak egyetlen egy felhasználót hozzuk létre, mégpedig az admin nevű felhasználót, aki Tomcat menedzselését fogja ellátni, ezért kapja meg a roles attribútumban a manager jogkört. A felhasználóhoz tartozó jelszó MD5 lenyomatát password attribútumban kell megadni. A Tomcat /conf könyvtárában lévő web.xml konfigurációs fájl, az alapértelmezett telepítési megkötéseket tartalmazó fájl, amely a szerven lévő összes web alkalmazásra végrehajtódik. Mivel azt szeretnénk, hogy a szerverrel való kommunikáció csak titkosított csatornán történjen, ezért az erre való megkötést ebben a fájlban kell megadni. 61

63 <security-constraint> <web-resource-collection> <web-resource-name>entire Application</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>confidential</transport-guarantee> </user-data-constraint> </security-constraint> Ezt az elemet a fájl végén, a <webapp> elemen belül kell megadni. A <web-sourcecollection> elemmel adjuk meg azokat az alkalmazásokat, melyekre a megkötés vonatkozik. Ebben az esetben ez a /*, azaz minden alkalmazás. A <user-data-constraint> elemben adjuk meg a megkötéseket, itt adjuk meg, hogy az adatcsere titkosított csatornán kell, hogy történjen. Végül a Tomcat beépített manager alkalmazása esetében be kell állítani, hogy csak a cég menedzsment szerverén keresztül lehessen hozzáférni. Ezt a Tomcat /webapps/manager/meta-inf/ könyvtárában található context.xml fájlban kell beállítani. Ez a fájl a csak magára a web-alkalmazásra vonatkozó beállításokat tartalmazza. Alapértelmezetten csak egy <Context> elemet tartalmaz, ebbe az elembe kell beszúrni a következő XML elemet: <Valve classname="org.apache.catalina.valves.remoteaddrvalve" allow=" "/> A <Valve> segítségével olyan feladatok definiálhatók, amelyeket az alkalmazás-szerver a web-alkalmazásokhoz kapcsolódó kérések kiszolgálása előtt végez el. Így lehetőség nyílik a kérések távoli címeinek szűrésére. A classname attribútumban megadott osztály segítségével adjuk meg, hogy a távoli címeken szűrés szeretnénk végezni, az allow attribútumban pedig az engedélyezett IP címek listáját adjuk meg. Ebben az esetben csak a menedzsment szerver helyi címét adjuk meg, tehát minden más címről érkező kérést a Tomcat visszautasít A tanúsítványok előkészítése Az ügyintéző rendszerhez szükséges tanúsítványok beszerzése A szerződéskötő rendszer működéséhez 3 tanúsítványra van szükség: egy aláírói egy authentikációs és egy SSL tanúsítvány 62

64 Ez a Java környezet miatt, kiegészül még egy kódaláíró tanúsítvánnyal, mivel a böngészőben futó Applet csak akkor férhet hozzá az ügyfél számítógépén a fájlrendszerhez, ha azt digitálisan aláírták, ez pedig csak kódaláíró tanúsítvánnyal lehetséges. A tanúsítványok egy hitelesítés-szolgáltatótól való beszerzése nem feltétlenül célszerű. A különböző tanúsítványok különböző szempontok szerint kerülnek kiválasztásra, és a hitelesítés-szolgáltatók nem feltétlen nyújtanak azonos minőségű szolgáltatást minden tanúsítványukhoz. Mivel a megvalósított rendszer saját fejlesztésű és a Magyar Elektronikus Aláírás Törvény terminológiája szerint nem hitelesített, ezért csak fokozott biztonságú aláírás készíthető vele, ezért az aláírói tanúsítvány ennek megfelelően elég, ha csak fokozott biztonságú. A fokozott biztonságú tanúsítványt a szervezet nevére kell kiállítani. Magyarországon a következő hitelesítés-szolgáltatóknál lehet fokozott biztonságú szervezeti tanúsítványt igényelni1: Magyar Telekom Távközlési Nyrt. MÁV INFORMATIKA Kereskedelmi, Szolgáltató és Tanácsadó Zrt. Microsec Számítástechnikai Fejlesztő Kft. NetLock Informatikai és Hálózatbiztonsági Szolgáltató Kft. Ezen felül a rendszer számára szükség lesz időbélyegzés és OCSP szolgáltatásokra is, amelyek az aláíró tanúsítvánnyal szorosan összefüggnek. A hitelesítés-szolgáltatónak ilyen szolgáltatásokkal is kell rendelkeznie. Nyilvánvalóan ezek rendelkezésre állása esetén már az ár a meghatározó tényező. A szolgáltatók honlapján talált árlisták alapján, a Microsec Számítástechnikai Fejlesztő Kft. ajánlata a legkedvezőbb2. Itt a fokozott aláírói tanúsítvány csomagban rendelhető, ami tartalmaz egy aláírói, egy authentikációs és egy titkosító tanúsítványt, továbbá időbélyegzés szolgáltatást és korlátlan OCSP szolgáltatást. Az SSL tanúsítvány esetében a legfontosabb szempont a böngészők és a Java környezet általi támogatottság. Ebben az esetben már nem feltételen szükséges, hogy a tanúsítványt magyarországi hitelesítés-szolgáltató állítsa ki. SSL tanúsítványt mindegyik, előzőekben felsorolt szolgáltató forgalmaz, azonban csak egy szolgáltató van, a fenti feltételnek megfelel, ez pedig Magyar Telekom Nyrt. Azonban az általuk kiadott tanúsítványokat Firefox böngésző nem támogatja, ami a legnépszerűbb böngészők között elfoglalt helye 1 2 Az NHH honlapján található lista alapján A listán szereplő hitelesítés-szolgáltatók árlistái alapján 63

65 miatt igen komoly probléma. Így az SSL tanúsítványt a Java környezet által támogatott hitelesítés-szolgáltatók egyikétől kell igényelni. A listában található hitelesítés-szolgáltatatók árlistái alapján a Go Daddy Group ajánlata a legkedvezőbb.3 Kódaláíró tanúsítvány esetében a Java környezet támogatása a legfontosabb szempont. Magyarországon csak a Microsec kft. forgalmaz kódaláíró tanúsítványt, az ő tanúsítványuk azonban nem szerepel a Java beépített tanúsítványtárában, ennek következtében a tanúsítványt szintén a Java környezet által megbízhatónak minősített hitelesítésszolgáltatótól kell igényelni. A listán szereplő hitelesítés-szolgáltatatók közül szintén a Go Daddy Group ajánlata a legkedvezőbb. Azonban nemcsak az ár miatt ítélhető a legjobb ajánlatnak, hanem azért, mert a kódaláíró tanúsítványhoz korlátlan számú időbélyegző is tartozik, így a tanúsítvány érvényességi ideje alatt, korlátlan számú aláír alkalmazás készíthető, melyek hitelessége a tanúsítvány lejárta után is megmarad Tanúsítvány aláírási kérelmek (CSR) készítése Szoftveres tanúsítványok igénylése esetén, a kulcspár és a hozzá tartozó tanúsítvány generálása az igénylő feladata. Ennek során az igénylő egy megfelelő alkalmazás segítségével, elkészíti a számára megfelelő kulcshosszúságú privát és publikus kulcsot a megfelelő algoritmussal, továbbá a tanúsítvány aláírási kérelemben rögzíti a tanúsítványban szerepeltetendő adatokat. A kérésben szereplő adatokat a hitelesítésszolgáltató egyezteti a tanúsítvány igénylésekor az igénylő azonosításakor megszerzett adatokkal, és ha egyeznek, akkor aláírva visszaküldi a tanúsítványt, így hitelesítve a tanúsítvány tulajdonosát. Jelen esetben 3 darab aláírási kérelmet kell készíteni, ehhez az OpenSSL nevű alkalmazást fogjuk felhasználni. sudo apt-get install openssl / az openssl telepítése openssl genrsa des3 out signkey.key 2048 / kulcspár generálása Ezzel létrehoztuk egy 2048 bit hosszúságú RSA kulcspárt, amelyet egy signkey.key nevű fájlban helyeztünk el Triple DES algoritmussal titkosítva. A kulcsgenerálás után a program bekéri a kulcspár titkosításához szükséges jelszót, majd ismételten a jelszó helyességének ellenőrzése céljából. Ezt a lépéssorozatot használjuk fel mindhárom tanúsítvány 3 A Java 6 környezet által támogatott hitelesítés-szolgáltatók listája alapján 64

66 kulcspárjának generálásakor, természetesen kulcspárokat külön fájlokba mentjük el és mindhárom esetben eltérő jelszót használunk. Ezek után a kulcspárok alapján generáljuk a tanúsítvány aláírási kérelmeket. openssl req new key signkey.key out signcert.csr /az aláírás kérelem generálása Ekkor az alkalmazás bekéri a tanúsítványban szerepeltetendő adatokat, ezeket a különböző tanúsítványok esetében különböző módon kell kitölteni. Az aláíró tanúsítvány esetében: Country Name (2 letter code) [AU]: HU / országkód State or Province Name (full name) [Some-State]: / a cég székhelyének megyéje Locality Name (eg, city) []: / a cég székhelye Organization Name (eg, company) [Internet Widgits Pty Ltd]: Cegnev Webhosting Kft. / a cég teljes neve Organizational Unit Name (eg, section) []: szerzodeskotes / cégen belüli szervezeti egység Common Name (eg, YOUR name) []: Cegnev Kft. Szerzodeskoto rendszer / a cégnév és az aláíró automata neve együtt Address []: elerhetoseg@cegnev.hu / a cég elérhetőségként megadott címe Az SSL tanúsítvány esetében: Country Name (2 letter code) [AU]: HU / országkód State or Province Name (full name) [Some-State]: / a cég székhelyének megyéje Locality Name (eg, city) []: / a cég székhelye Organization Name (eg, company) [Internet Widgits Pty Ltd]: Cegnev Webhosting Kft. / a cég teljes neve Organizational Unit Name (eg, section) []: szerzodeskotes / cégen belüli szervezeti egység Common Name (eg, YOUR name) []: szerzodeskotes.cegnev.hu / a szerver teljes domain neve, ez jelenik meg a böngészőben Address []: / üresen kell hagyni A kódaláíró tanúsítvány esetében: 65

67 Country Name (2 letter code) [AU]: HU / országkód State or Province Name (full name) [Some-State]: / a cég székhelyének megyéje Locality Name (eg, city) []: / a cég székhelye Organization Name (eg, company) [Internet Widgits Pty Ltd]: Cegnev Webhosting Kft. / a cég teljes neve Organizational Unit Name (eg, section) []: szerzodeskotes / cégen belüli szervezeti egység Common Name (eg, YOUR name) []: Cegnev Kft. / a cég rövid neve Address []: / üresen kell hagyni A kitöltés után az OpenSSL bekér egy opcionális jelszót és egy cégnevet, ezeket nem kell kitölteni. Ekkor a tanúsítvány aláírási kérelem az out paraméterben megadott fájlba kerül mentésre. A tanúsítványkérelmek a fájlokban PEM formátumban találhatók meg. Felépítésük a következő: -----BEGIN NEW CERTIFICATE REQUEST----Base64 kódolt tanúsítványkérelem -----END NEW CERTIFICATE REQUEST----- Mindhárom tanúsítványkérelem esetében, ezt a szöveget kell elküldeni a határoló sorokkal együtt a megfelelő hitelesítés-szolgáltatóknak A tanúsítványok megfelelő formátumra alakítása Miután a hitelesítés-szolgáltatók az aláírt tanúsítványokat visszaküldték, a biztonság és a könnyebb kezelhetőség kedvéért a kulcspárokat és hozzájuk kapcsolódó tanúsítványokat egy kulcstárban helyezzük el. A parancs esetében feltételezzük, hogy a hitelesítés-szolgáltatók azonos névvel, de.cer kiterjesztéssel küldték vissza az aláírt tanúsítványokat. A kulcstárak formátuma PKCS12 lesz. openssl pkcs12 signkey.key export name out álnév signcert.p12 passin in signcert.cer pass:kulcsjelszó inkey passout pass:signcertpassword A signkey.key fájlban található kulcspárt és a signcer.cer fájlban tanúsítványt álnév alatt mentjük el a signcert.p12 nevű kulcstárba. A kulcshoz való hozzáféréshez szükséges jelszót a passin paraméteren belül pass: előtaggal, a PKCS12 kulcstárhoz való hozzáféréshez szükséges jelszót pedig, a passout paraméteren belül szintén pass: előtaggal adjuk meg az alkalmazás számára. Mindhárom 66 tanúsítvány esetében ezt a

68 parancsszerkezetet követjük, nyilvánvalóan minden esetben egyedi jelszót és kimeneti fájlnevet használunk. A name paraméter után megadott álnév esetében lényeges, hogy beszédes legyen. Ez a tanúsítványok tanúsítványtárba importálásakor igen fontos, jól elkülöníthetőek kell, hogy legyenek. Ezért álnévnek a tanúsítványokban lévő általános nevet (CN) célszerű megadni. Az aláíró tanúsítvány esetében: -name Cegnev Kft. Szerzodeskoto rendszer Az SSL tanúsítvány esetében: -name szerzodeskotes.cegnev.hu A kódaláíró tanúsítvány esetében: -name Cegnev Kft. Az így elkészült kulcstárak közül az SSL tanúsítványt a Tomcat mappájában létrehozott /certs mappába kell másolni. Az aláírói tanúsítványt a Servlet /KeyStores mappájában kell elhelyezni. A kódaláíró tanúsítványt azon a számítógépen érdemes tárolni, amelyen a rendszer futtatható binárisait készítjük el A rendszerhez szükséges külső tanúsítványok beszerzése Először meg kell határoznunk azokat a hitelesítés-szolgáltatókat, melyek tanúsítványait a szerződéskötéskor elfogadjuk. Mivel az egyik alapvető cél, hogy a lehető legszélesebb körben felhasználható legyen a rendszer, ezért minden olyan magyarországi hitelesítésszolgáltató fokozott biztonságú tanúsítványát elfogadjuk, amely OCSP szolgáltatást nyújt és azt külön előfizetés nélkül elérhetjük. Ezek listája a következő: EDUCATIO Társadalmi Szolgáltató Kht. Magyar Telekom Távközlési Nyrt. Microsec Számítástechnikai Fejlesztő Kft. NetLock Informatikai és Hálózatbiztonsági Szolgáltató Kft.4 A Magyar Telekom Nyrt. és a Netlock Kft. OCSP szerverei nyilvánosan elérhetők, a Microsec Kft. szerverét pedig a rendszer számára a cégtől igényelt aláírói tanúsítvány csomagban szereplő authentikációs tanúsítvány segítségével érhetjük el. Az EDUCATIO Kht. legfelső szintű tanúsítványát a KGYHSZ hitelesíti, így az ő tanúsítványaikat nem tudjuk felhasználni. A MÁV INFORMATIKA Zrt. OCSP szervere nem nyilvános, így az ő tanúsítványaikat a rendszer szintén nem tudja elfogadni. Az így megmaradt 3 hitelesítés-szolgáltatótól a következő tanúsítványokat és elérhetőségeket kell beszerezni: 4 A szolgáltatók szolgáltatási szabályzatai alapján 67

69 fokozott biztonságú tanúsítványok kiállításához használt legfelső szintű tanúsítványokat az OCSP szerverek az OCSP válaszok aláírásához használt tanúsítványát hitelesítő legfelső szintű tanúsítvány (OCSP Root CA) esetlegesen az OCSP szerverek SSL tanúsítványát hitelesítő legfelső szintű tanúsítvány (ha az OCSP szerver HTTPS kapcsolaton elérhető) az OCSP szerverek elérhetőségi címeit (URL) A tanúsítványokat a hitelesítés-szolgáltatók tanúsítványtárában találhatók, melyek elérhetőségét az OCSP szerverekével együtt a szolgáltatók hivatalos web-oldalán és azokon elérhető szolgáltatási szabályzatokban hozzáférhetőek. Az így összegyűjtött tanúsítványokat típus szerint csoportosítva egy-egy Java kulcstárba kell elhelyezni. Ezek után a rendszer saját aláírói tanúsítványához kötődő tanúsítványokat és elérési címeket kell beszerezni a hitelesítés-szolgáltatótól: a hitelesítés-szolgáltató időbélyegző szerverének az időbélyegek aláírásához használt tanúsítványt hitelesítő legfelsőbb szintű tanúsítványát (TSA Root CA) az időbélyegző szerver SSL tanúsítványát hitelesítő legfelsőbb szintű tanúsítvány az időbélyegző szerver elérhetőségi címe (URL) A tanúsítványok a hitelesítés-szolgáltató tanúsítványtárából érhetőek el, melynek elérhetősége az időbélyegző szerver elérhetőségével együtt megtalálható a szolgáltató hivatalos weboldalán és azon elhelyezett szolgáltatási szabályzatban. Az időbélyegző szerver tanúsítványát az SSL tanúsítványokat tartalmazó Java kulcstárba helyezzük. Az időbélyegző szerver aláíró tanúsítványa külön Java kulcstárba kerül. Az így meghatározott kulcstárak a következők: legfelső szintű aláírói tanúsítvány kibocsátó Java kulcstár, ebben találhatók azok a legfelső szintű tanúsítványok, amelyeket a rendszer az aláírók tanúsítványának valódiságának ellenőrzésére használ SSL Java kulcstár, ez alapján ellenőrzi majd a rendszer, hogy a titkosított csatorna másik felén lévő szerver tényleg az, akinek mondja magát OCSP Java kulcstár, ennek alapján ellenőrzi majd a rendszer, hogy a kért OCSP igazolások tényleg az adott hitelesítés-szolgáltatótól származik időbélyegző Java kulcstár, a rendszer ennek alapján ellenőrzi az időbélyegek hitelességét 68

70 Java kulcstárak létrehozása Az előzőekben összegyűjtött tanúsítványokat Java kulcstárakban kell elhelyezni, erre a Java környezet beépített keytool alkalmazását használjuk. keytool import trustcacerts alias álnév file rootca.crt keystore truststore storepass kulcstárjelszó Itt a legfelső szintű tanúsítványt tartalmazó rootca.crt fájlt illesztjük be a truststore nevű Java kulcstárba álnév alatt, ahol a kulcstárat a storepass paraméter után megadott jelszó védi. Minden tanúsítvány Java kulcstárakba illesztéséhez ezt a parancsszerkezetet kell használni. Az álnév célszerűen a tanúsítványban található általános név (CN), így könnyebb a tanúsítványok azonosítása. Az egyes Java kulcstárakba a következő tanúsítványokat kell importálni. Legfelső szintű aláírói tanúsítvány kibocsátó Java kulcstár: Microsec e-szigno Root CA NetLock Közjegyzői (Class A) NetLock Üzleti (Class B) NetLock Expressz (Class C) Magyar Telekom Root CA SSL Java kulcstár: Microsec e-szigno Root CA NetLock Üzleti (Class B) OCSP Java kulcstár: e-szigno OCSP CA NetLock Expressz (Class C) Magyar Telekom Root CA Időbélyegző Java kulcstár: Microsec Advanced e-szigno CA2 Az így létrejött Java kulcstárakat a Servlet /TrustStore mappájába kell másolni A komponensek megvalósítása Java környezetben A szükséges külső programkönyvtárak A Java platform, bár nagyon sok megoldást alapértelmezetten megvalósít, köztük sok kriptográfiai és PKI funkciót, önmagában nem elég, hogy a teljes ügyviteli rendszert megvalósítsuk vele. Szerencsére a szabadon felhasználható programkönyvtárak igen szerteágazóak, így nem kell külön erőfeszítést fordítani az egyedi funkciók 69

71 megvalósításához. Az ügyvitelei rendszerhez a következő programkönyvtárakra van szükség. itext Project Az itext egy a PDF, RTF és HTML dokumentumok előállítására és manipulánsára alkalmas nyílt forráskódú Java programkönyvtár. Ezt az ügyintéző rendszer a szabványos PDF formátumú dokumentumokat előállító funkció megvalósításához szükséges. A forráskód MPL (Mozilla Public License) és LGPL (Lesser General Public License) licensz alatt használható fel. A programkönyvtár elérhetősége: SwingLabs PDF Renderer Az itext project a lehetőségek igen széles skáláját nyújtja PDF dokumentumok előállítása terén, azonban PDF megjelenítő funkciókat nem valósít meg. Erre a SwingLabs PDF Renderer Project-jét használjuk fel. Ez szintén egy nyílt forráskódú Java programkönyvtár, mely PDF dokumentumok megjelenítésre képes Java alkalmazások előállítását teszi lehetővé. A programkönyvtárat az ügyintéző rendszer PDF megjelenítő funkciójának megvalósításához szükséges. A forráskód LGPL alatt használható fel. A programkönyvtár elérhetősége: Bouncy Castle A Bouncy Castle egy ingyenes Java kriptográfiai API csomag, amely különböző kriptográfiai protokollok és szabványok felhasználását teszi lehetővé Java alkalmazásokban. A csomagból 3 darab API-ra van szükség az ügyviteli rendszerhez: Bouncy Castle Provider API Bouncy Castle SMIME/CMS API Bouncy Castle TSP API Ezekre az API-ra építve valósítjuk meg az ügyviteli rendszer kriptográfiai funkcióinak nagy részét, szabványos időbélyeg és OCSP kérés készítése, ezekre adott válaszok feldolgozása. Az API csomag MITL licensz alatt használható fel. A programkönyvtár elérhetősége: Public Domain Base64 Encoder/Decoder A Java platform alapértelmezetten tartalmaz Base64 kódoló osztályt, azonban azt csak a Java saját osztályai használhatják fel, ezért az ügyviteli rendszer működéséhez szükséges Base64 kódolásokhoz szükség van egy külső Base64 kódoló osztályra is. Erre a célra a Public Domain Base64 Java osztályt használjuk fel, amely, nevéből is kitűnik, Public Domain, azaz teljesen szabad forráskódú, szabadon az alkalmazásokba építhető. 70

72 A programkönyvtár elérhetősége: JavaMail A Sun által kifejlesztett API, amely lehetővé teszi elektronikus levelek készítését és küldését Java alkalmazásokon keresztül. A rendszer megvalósításakor az -ek összeállításához és a levelezőszerverhez való továbbításához használjuk fel. A programkönyvtár elérhetősége: Apache XML Security Az Apache Foundation által kifejlesztett Java programkönyvtár, amely elsősorban XMLDsig típusú aláírások készítéséhez használható. A programkönyvtár C14N algoritmus implementációját használjuk fel az időbélyegek elkészítéséhez. A felhasználás feltételeit az Apache License v2.0 határozza meg. A programkönyvtár elérhetősége: A szerver-kliens kapcsolat megvalósítása A Servlet és az Applet közötti kommunikáció HTTP protokollon keresztül, kérés-válasz formájában, titkosított csatornán zajlik. A kommunikáció megfelelő esetben az alábbi két fázisból áll: Az Applet elküldi a szerződéshez szükséges adatokat a Servlet-nek, a Servlet az adatokkal kitöltött szerződést tartalmazó PDF fájlt visszaküldi az Applet-nek. Az aláírt szerződést tartalmazó XML fájlt az Applet elküldi a Servlet-nek, hiteles aláírás esetén a Servlet az újabb aláírással és időbélyeggel bővített XML dokumentumot visszaküldi az Applet-nek. A kliens Applet-eket és hozzájuk tartozó állapotokat a Servlet session-azonosítók és változók segítségével tartja nyilván. Az kliens oldalon a Java URL és HttpsURLConnection osztályát használjuk fel a Servlethez való kapcsolódáshoz. A kapcsolódás megvalósítását a következő függvények és eljárások szemléltetik. 71

73 private HttpsURLConnection getsafeconnection() { URL servleturl = null; // a szükséges változók deklarációja HttpsURLConnection connection = null; try { servleturl = this.getcodebase(); // a Servlet URL-jénak meghatározása connection = (HttpsURLConnection) servleturl.openconnection(); // a kapcsolat megnyitása connection.setusecaches(false); //a HTTP cache letiltása connection.setdefaultusecaches(false); connection.setdoinput(true); // adatküldés, adatfogadás engedélyezése connection.setdooutput(true); } catch (IOException ex) { return null; // kivétel esetén null-t ad vissza } return connection; // HttpsURLConnection objektum visszadása } A getsafeconnection függvény az Applet futtatási környezetéül szolgáló weboldal címe definiálja a Servlet URL-jének értékét, mely alapján létrehozza a HTTP kapcsolathoz szükséges HttpsURLConnection osztálypéldányt. A példányban letiltjuk a HTTP cache használatát, továbbá beállítjuk, hogy a kapcsolat során adatküldés és fogadás is történni fog. Hiba esetén a függvény null értékkel tér vissza. A következő két eljárással a HttpsURLConnection osztályon keresztül olvassuk ki a HTTP fejlécből a kliens munkamenet azonosítóját, majd beállítjuk, mint a HTTP kérés paraméterét. A munkamenet azonosítót egy sessionid nevű globális String változóban tároljuk. private void getsessionid(httpsurlconnection connection) { if (sessionid==null) // ha még nincs beállítva a munkamenet változó, akkor olvassa ki a HTTP fejrészből { sessionid=connection.getheaderfield("set-cookie"); } } private void setsessionid(httpsurlconnection connection) { if (sessionid!=null) // ha a munkamenet változó nem üres, akkor állítsa be a kérés paramétereként { connection.setrequestproperty("cookie", sessionid); } } Adatküldésre és fogadásra az ObjectInputSream illetve az ObjectOutputStream osztályokat használjuk fel. Ezen osztályok esetében a HTTP kapcsolaton keresztül Java objektumokat 72

74 küldünk, amely megkönnyíti a bonyolult adatstruktúrák átvitelét két Java alkalmazás között. Ezeken az osztályokon csak olyan Java osztályokat lehet küldeni és fogadni, amelyek implementálják a Java Serializable interfész osztályát. private Object send_and_get(object tosend) { HttpsURLConnection connection=null; Object inputobject=null; if ((connection=getsafeconnection())!=null) // sikeres kapcsolat vizsgálata { setsessionid(connection); // a munkamenet változó beállítása connection.setrequestproperty( // a kérés és válasz MIME típusok beállítása "Content-Type", "application/x-java-serialized-object"); connection.setrequestproperty("accept", "application/x-java-serializedobject"); try { ObjectOutputStream objectout = new ObjectOutputStream(connection.getOutputStream()); // új kimeneti objektumfolyam létrehozása objectout.writeobject(tosend); // az objektum kiírása a folyamra objectout.flush(); // a folyam elküldése getsessionid(connection); // munkamenet változó kinyerése ObjectInputStream objectin=new ObjectInputStream(connection.getInputStream()); // új bemeneti objektumfolyam létrehozása inputobject=objectin.readobject(); // az objektum kiolvasása a folyamból objectout.close(); // folyamok lezárása objectin.close(); } catch (ClassNotFoundException ex) { // kivételek lekezelése return null; } catch (IOException ex) { return null; } } return inputobject; // a kiolvasott objektum visszaadása } Ez a függvény a Servlet-tel való kapcsolat megvalósítását szemlélteti. Paraméterként a Servlet-nek küldendő objektumot várja, visszatérési értéke a Servlet-től kapott válaszobjektum. A kapcsolat felépítésére az előzőekben definiált getsafeconnection függvényt használjuk fel. Sikeres kapcsolódás esetén beállítjuk a kérés és az elfogadott válasz MIME típusát a kérés paramétereiben. A setsessionid eljárással beállítjuk az Applet munkamenetének azonosítóját. Ezek után létrehozunk egy kimeneti objektumfolyamot, melybe kiírjuk a küldeni szánt objektumot, a Servlet válaszából pedig 73

75 kinyerjük a kliens munkamenet-azonosítóját, majd kiolvassuk a visszaküldött objektumot. Ha a kapcsolatban vagy a folyamok írásakor, olvasásakor hiba történik, a függvény null értéket ad vissza. Sikeres adatcsere esetén visszaadja a Servlet által küldött objektumot. A Servlet oldalon sokkal könnyebb dolgunk van, a titkosított csatorna kezelését a Servletet kiszolgáló alkalmazásszerver látja el, így itt csak a kérések feldolgozásával és a válaszok előállításával kell foglalkozni. A HTTP kéréseket a HttpServletRequest, a válaszokat pedig HttpServletResponse osztályok segítségével dolgozhatjuk fel. Az objektumok átvitele itt is hasonlóan valósul meg, mint a kliens oldalon, azonban éppen fordítva, az adatok kérésválasz feldolgozása miatt. Ezért itt az objektumok kiolvasását és kiírását az objektumfolyamokra külön kell választani. Ezt szemlélteti az alábbi függvény és eljárás. protected Object readobject(httpservletrequest request) { Object inputobject=null; // a beolvasott objektum változójának deklarálása try { ObjectInputStream objectin=new ObjectInputStream(request.getInputStream()); inputobject=objectin.readobject(); } catch (ClassNotFoundException ex) { // új objektumfolyam létrehozása // az objektum kiolvasása a folyamból return null; } catch (IOException ex) { //kivételek lekezelése return null; } return inputobject; // a kiolvasott objektum visszaadása } A readobject függvény a paraméterként átadott HttpServletRequest objektumon keresztül kiolvassa a bemeneti objektumfolyamból az Applet által küldött objektumot, majd azt visszatérési értékként adja vissza. Hiba esetén null értéket ad vissza. protected void writeobject(httpservletresponse response, Object sendobject) throws IOException { ObjectOutputStream objectout ObjectOutputStream(response.getOutputStream()); // = új kimeneti new objektumfolyam létrehozása objectout.writeobject(sendobject); // az objektum kiírása a folyamra objectout.flush(); // a folyam elküldése objectout.close(); // a folyam lezárása } A writeobject eljárás a paraméterként megkapott HttpServletResposne objektumon keresztül a HTTP válaszba írjuk a szintén paraméterként megkapott objektumot. Mivel nincs visszatérési érték, az eljárás kivételt dob, ha válasz előállításakor hiba keletkezik. 74

76 A kérések és válaszok feldolgozását és a hozzájuk kapcsolódó feladatokat a makeresponse eljárás szemlélteti. A Servlet a kérésben található objektum osztályát és a válasz előállításához szükséges feladatokat a kérésben található munkamenet azonosító lapján határozza meg. Ha a kérésben nem található munkamenet azonosító, akkor a Servlet az első fázisnak megfelelő objektumot keres a kérésben, és ennek a fázisnak megfelelő választ fog előállítani. Ha talál munkamenet azonosítót, a második fázisnak megfelelő objektumot keres a kérésben és ennek a fázisnak megfelelő választ állít elő. A munkamenet azonosítókat és a hozzájuk tartozó adatok kezelését a HttpSession osztály segítségével tehetjük meg. protected void makeresponse(httpservletrequest request, HttpServletResponse response) throws IOException { HttpSession session=null; Object inputobject=null; response.setcharacterencoding("utf-8"); // karakterkódolás beállítása response.setcontenttype("application/x-java-serialized-object"); //a válasz MIME típusának beállítása inputobject=readobject(request); // az objektum kiolvasása a kérésből if(request.getsession(false)==null) // a munkamenet azonosító elérhetőségének vizsgálata { session=request.getsession(); // a kérés feldolgozása // ha nincs akkor új munkamenet azonosító ha a kiolvasott objektum nem üres és a megfelelő osztály objektuma if((inputobject!=null) && (inputobject instanceof requestclass1)) { requestclass1 message=(requestclass1) inputobject; // megfelelő osztály objektummá alakítás *** az objektum feldolgozása, a válaszobjektum előállítása*** writeobject(response,responseclass1); // a válasz objektum kiírása a HTTP válaszba } else // az objektum nem megfelelő { session.invalidate(); // a munkamenet törlése writeobject(response,"hibás HTTP kérés!"); a válaszba } } 75 // hibaüzenet kiírása

77 else // ha a kérés tartalmaz munkamenet azonosítót { session=request.getsession(false); //az azonosító kinyerése if((inputobject!=null) && (inputobject instanceof requestclass2)) { // az objektum megfelelőségének vizsgálata String message=(requestclass2) inputobject; // megfelelő osztály objektummá alakítás *** az objektum feldolgozása, a válaszobjektum előállítása*** writeobject(response, responseclass2);// válasz objektum kiírása a HTTP válaszba } else // ha az objektum nem megfelelő { writeobject(response,"hibás HTTP kérés!"); //hibaüzenet kiírása a válaszba } session.invalidate(); // a második fázis végén a munkamenet törlése } } Annak megállapítása, hogy az adott kliens melyik fázisban tart, egy HttpSession objektum segítségével történik. Ha az objektum nem üres, akkor a kliens az első fázisban tart, a kérésből requestclass1 típusú objektumot kell kiolvasni. Ha a kérés nem tartalmaz objektumot vagy a benne található objektum osztálya nem megfelelő, akkor a Servlet hibaüzenetet küld vissza. Ha az objektum megfelelő, akkor visszaalakítjuk a megfelelő osztály objektumává, majd ennek megfelelően kerül feldolgozásra és a válasz előállítása. Ha a kérés tartalmaz munkamenet azonosítót, akkor a kliens a második fázisban tart, ennek megfelelően requestclass2 osztályú objektumot kell, hogy tartalmazzon. Ha az objektum nem megfelelő, akkor a Servlet hibaüzenetet küld. Ha az objektum megfelelő, akkor az objektum feldolgozása és a válasz előállítása ennek a fázisnak megfelelően történik. A munkameneteteket a második fázis válaszának előállítása után, illetve minden olyan esetben lezárjuk, amikor a kérés nem tartalmaz megfelelő objektumot A szerződésdokumentum előállító komponens A PDF szerződésdokumentum előállítása a XMLPDF osztály segítségével történik. Az osztály megvalósításához a com.org.sax csomagot a Java SAX API-ját használtuk fel, amellyel egy új XML feldolgozót hoztunk létre a DefaultHandler osztály kiterjesztésével. A DefaultHandler három metódusát kell felüldefiniálni a XML elemek feldolgozásához: startelement endelement characters 76

78 A PDF dokumentum objektumainak előállításához az itext programkönyvtár com.lowagie.text csomag osztályait használtuk fel. Az XML séma PDF dokumentummá alakításához szükséges SAXParser objektum előállítását, a java.xml.parsers csomagban található SAXParserFactory osztály segítségével állítjuk elő. (A szerződésdokumentum előállításához használt XML séma a szakdolgozat végén található mellékletben lett bekötve. A Java osztályok forráskódjai a CD mellékleten találhatók.) 18. ábra az XMLPDF osztály felépítése Attribútumok font, PDF dokumentumban használt betűtípus boldfont, az eredeti betűtípus félkövér változata document, a PDF dokumentumot felépítését tartalmazó com.lowagie.text.document típusú objektum stringbuffer, az XML elemek szöveges tartalmának feldolgozásához szükséges karakterlánc tároló fontsize, a PDF dokumentumban használt betűméret, alapértelmezetten 12 pont imagelocation, a sémában hivatkozott képfájlok elérési útja a fájlrendszerben data, az ügyféladatokat tároló tömb arraylist, az PDF objektumokat ideiglenesen tároló lista Metódusok: startelement: XML elemek kezdetekor elvégezendő feladatokat végzi el, az elemnek megfelelő PDF objektumot hozz létre. 77

79 endelement: az XML elemek végén hívódik meg, az XML elemek végén elvégzendő feladatokat végzi el, szöveges adatok csatolása PDF objektumokhoz, majd azok csatolása a PDF dokumentumhoz characters: az XML elemek szöveges tartalmának feldolgozására szolgál, az elemben található karakterláncot a stringbuffer változóhoz csatolja filterspecialchars: az XML elemek szöveges tartalmában található speciális karaktereket szűri ki. replacelastarrayitem: a listán utolsó elemét cseréli le egy megadott objektumra. removelastarrayitem: a lista utolsó elemét vágja le. parse: a bemenetként kapott bájttömbben szereplő XML sémát dolgozza fel, behelyettesíti az ügyféladatokat, majd ez alapján előállítja a szerződést tartalmazó PDF dokumentumot, amelyet bájt tömb formájában add vissza A szerződésmegjelenítő komponens A kitöltött szerződést tartalmazó PDF dokumentum megjelenítésére a PDFView osztály szolgál. Az új grafikus elem létrehozásához a Java Swing JComponent osztályát terjesztjük ki. A dokumentumok megjelenítéséhez a SwingLabs PDF Renderer API com.sun.pdfview csomagjában található PDFFile és PDFPage osztályjait használjuk fel..a PDFFile tartalmazza a megjelenítendő PDF dokumentumot, a PDFPage pedig a dokumentum egy oldalát. A PDFPage objektumokban található képeket, Image objektumok formájában olvassuk ki. Ezeket a JComponent felülírt paint metódusában a Graphics osztály drawimage metódusával a felhasználói felületre rajzoljuk. 19. ábra a PDFViewer osztály felépítése Attribútumok: pdffile, a PDF dokumentumot tartalmazó objektum pagenumber, a dokumentum aktuálisan oldala Metódusok: 78

80 getprefferedsize: a grafikus elem számára ideális méret lekérdezése. paint: az aktuális oldal a felhasználói felületre rajzolása. renderpage: a dokumentum egy megadott oldalának megjelenítése. rendernextpage: a következő oldal megjelenítése. renderprevpage: az előző oldal megjelenítése A tanúsítványkezelő komponens A tanúsítványok kezelését és a kulcstárakból történő kiolvasását a CertStore osztály végzi. Bár a Java nyelv rendelkezik egy azonos nevű beépített osztállyal mely hasonló funkciót lát el, azonban ez az osztály önmagában nem képes a komponens feladatinak ellátására. Ezért a Java Security API-jának osztályaira építve új osztályt kell létrehozni. A tanúsítványok szoftveres kulcstárból történő kiolvasása, a KeyStore objektumokon keresztül történik. A kiolvasott tanúsítványon ellenőrzéseket végzünk, hogy csak hiteles és a feltételeknek megfelelő tanúsítványokat lehessen felhasználni. A tanúsítványok kezelésére a X509Certificate osztályt használjuk fel, amelynek segítségével a tanúsítványokban található adatokat az X509 szabványnak megfelelő adatstruktúraként kezelhető. Ez megkönnyíti a tanúsítványban szereplő adatok kiolvasását, ellenőrzését, a nyilvános kulcs kiolvasását. A publikus kulcsot a PublicKey, a titkos kulcsot pedig a PrivateKey osztályon keresztül használjuk fel. 20. ábra a CertStore osztály felépítése Attribútumok: privatekey, a kiolvasott tanúsítványhoz tartozó titkos kulcs certificatechain, a tanúsítványhoz tartozó tanúsítványlánc Metódusok: checkvalidity: a tanúsítvány érvényességi idejének ellenőrzése. 79

81 issignercertificate: a tanúsítványban található kulcsfelhasználási attribútumok alapján megállapítja, hogy a tanúsítvány alkalmas-e digitális aláírás készítésére. buildcertchain: megvizsgálja, hogy a kulcstárból kiolvasott tanúsítványokból felépíthető a tanúsítványlánc. validatecertificate: két tanúsítvány alapján eldönti, hogy az elsőn szereplő aláírás a másodiktól származik-e. getsignercertificate: a tanúsítványláncban szereplő aláíró tanúsítványt adja vissza. getissuercertificates: a tanúsítványláncban szereplő hitelesítés-szolgáltatói tanúsítványokat adja vissza. getcertificatechain: a kulcstárból kiolvasott tanúsítványláncot adja vissza. getprivatekey: a tanúsítványhoz tartozó titkos kulcsot adja vissza. getsignername: az aláírói tanúsítványban szereplő általános nevet (CN) adja vissza, mint az aláíró nevét. certarraytox509certarray: a Certificate típusú tanúsítványokat tartalmazó tömböt alakítja át X509Certificate típusú tömbbé A szerződés aláíró komponens A kliens oldalon az ügyfelek által készített aláírások előállításáról a XAdESB osztály gondoskodik. Az aláírt szerződés formátumaként a magyarországi de facto szabványnak megfelelő Microsec Kft. által kifejlesztett e-akta XML formátumot használjuk. Az e-akta XAdES szabványnak teljesen megfelelő formátum, azonban pontosan megadja az egyes elemek helyét az XML struktúrában a könnyebb feldolgozhatóság, illetve az alkalmazások közötti átjárhatóság megteremtésének érdekében. Továbbá az aláírás körülményeiről különböző meta adatokat szerepeltetését írja elő. A formátum felépítése nagy vonalakban a következő: Az <es:dossier> elem a XML gyökér eleme, itt definiálódnak az XML névterek, amelyek elemeit az aláírási formátum elkészítéséhez használunk fel. Két gyermek eleme van: <es:dossierprofile>, amely magáról az e-aktáról tárol meta adatokat <es:documents>, amely az e-aktában található dokumentumokat és az azokhoz kapcsolódó aláírásokat, tanúsítványokat, időbélyegeket és visszavonási információkat tartalmazza. A <es:documents> elemen belül egy vagy több <es:document> elem található, amely az aktában található dokumentumok megkülönböztetésére szolgál. Minden <es:document> 80

82 elem egy az aláírt dokumentumot Base64 kódolt formában tároló <ds:object> elemből és egy vagy több, az aláírást tartalmazó, <ds:signature> elemből áll. A szerződés aláíró komponens esetében, csak egy dokumentum kerül aláírásra, maga a szerződést tartalmazó PDF fájl, ezt az e-aktában lévő egyetlen <es:document> elem <ds:object> gyermekelemében helyezzük el. Minden egyes <ds:signature> elem erre az elemre fog hivatkozni. Az aláírás formátum megvalósításához a Java XMLDsig típusú aláírás javax.xml.crypto.dsig és a XML struktúra felépítésére pedig org.w3c.dom csomagot használjuk fel. 21. ábra a XAdESB osztály felépítése Attribútumok dossierns, az e-akta formátum által definiált elemek névtere. signxmldocument, egy org.w3c.dom.document típusú objektum, amely magát az XML dokumentumot tartalmazza. objectid, a szerződés dokumentumot tartalmazó <ds:object> azonosítóját tárolja. document, egy org.w3c.dom.element típusú objektum, ami a <es:document> elemet tartalmazza. signatures, a dokumentumon található aláírásokat számlálja. buildbasexml: Inicializálja signxmldocument, objectid és document változókat. Felépíti az aláírás nélküli XML dokumentumot, majd ehhez a bájttömbben található szerződésdokumentumot Base64 kódoltan illeszti be egy <ds:object> elem formájában. getformatedtime: az aláírási formátumnak megfelelő dátumformátumot állít elő. generaterandomid: az XML elemek azonosítóinak előállításra szolgál. 81

83 generatereferenceids: a <ds:reference> elemek azonosítóit állítja elő. generatesigneddataobjectvalues: <SignedDataObjectValues> XML elemeket állítja elő, a <Reference> elemekben hivatkozott adatok MIME típusát tartalmazza. generatecertelement: a <Cert> típusú XML elemek előállítására szolgál. generateencapsulatedcert: a Base64 kódolt tanúsítványokat tartalmazó <EncapsulatedX509Certificate> elemeket generál. generatecertrefsandvalues: a <CompleteCertificateRefs> és <CertificateValues> elemek Base64 kódolt tanúsítványokat és azokra mutató gyermekelemeinek előállítására szolgál. addsignature: aláírást készít a dokumentumra a paraméterben megkapott CertStore típusú objektumban található tanúsítvány alapján. Az új <ds:signature> elemet az XML dokumentumhoz csatolja, az XML struktúráját pedig az e-akta előírásainak megfelelően alakítja át. getxmlsignaturebytes: az elkészült aláírási formátumot egy bájt tömb formájában adja vissza Az aláírási formátum ellenőrző komponens Az aláírt szerződés elkészítése után a szerver oldalon meg kell bizonyosodni az aláírást tartalmazó XML formátum hitelességétől. Az ellenőrzést a XAdESValidator osztály segítségével végezzük el. Az XML fájl kezeléséhez itt is az org.w3c.dom Java csomag osztályaira építünk. A dokumentumban található aláírás kiolvasására a javax.xml.crypto, annak hitelességének ellenőrzésére pedig a javax.xml.validation csomag osztályait használjuk fel. 22. ábra a XAdESValidator osztály felépítése Attribútumok: document, az XML aláírási formátumot tartalmazó org.w3c.dom.document objektum Metódusok: 82

84 loaddocument: a paraméterként kapott bájt tömb alapján inicializálja az XML struktúrát tartalmazó document változót. getsignercertificate: a document objektumból kikeresi a <ds:keyinfo> elemet, majd az abban található <ds:x509certificate> elem Base64 dekódolt tartalmából létrehozza az aláíró tanúsítványát tartalmazó X509Certificate típusú objektumot. getsignercertificate: a document objektumból kikeresi a <CertificateValues> elemet, amelynek <EncapsulatedX509Certificate> gyermekelemei Base64 dekódolt tartalmából létrehozza az aláíró tanúsítványát hitelesítő tanúsítványláncot, egy X509Certificate tömb típusú objektumba. validatecertificate: két paraméterként megkapott X509Certificate típusú objektum alapján eldönti, hogy az első tanúsítványon a második aláírása szerepel-e. buildcertchain: a getsignercertificate és a getsignercertificate metódusok segítségével felépíti és leellenőrzi az aláírói tanúsítványláncot. iscertificatetrusted: a paraméterként megkapott X509Certificate objektumokat tartalmazó tömb alapján eldönti, hogy az aláíró tanúsítványa az elfogadott hitelesítésszolgáltatóktól származik-e. isdocumentvalid: a paraméterként kapott bájt tömb alapján eldönti, hogy a document objektumban található <ds:reference> elemek egyike rendelkezik olyan <ds:digestvalue> elemmel, melynek tartalma megegyezik a szerződés lenyomatával, azaz a dokumentumban tényleg az aláírt szerződés szerepel-e A visszavonás ellenőrző komponens A tanúsítványok visszavonási állapotának ellenőrzéséről az OCSPConfirm osztály gondoskodik. A hitelesítés-szolgáltató felé új kapcsolatot nyit a paraméterként megkapott URL alapján, amely meghatározza a kapcsolathoz szükséges protokoll típusát. HTTPS kapcsolat esetén új SSL kontextust generál, a paraméterként kapott két kulcstár alapján, amelyek a server saját authentikációs tanúsítványát és a hitelesítés-szolgáltatók legfelsőbb szintű SSL tanúsítványait tartalmazzák. A tanúsítványok és kulcstárak kezeléséhez a Java Security API-ját a java.security csomag osztályait, a kapcsolat megvalósításához pedig a java.net és a javax.net.ssl csomag osztályait használjuk fel. Az OCSP kéréseket a paraméterként megkapott X509 típusú tanúsítványok alapján generálja, minden tanúsítvány állapotát egyetlen kérésben kérdezzük le, a gyorsabb feldolgozás érdekében. A kapott válasz hitelessége és a válaszban található állapotok alapján dönti el, hogy a tanúsítvány érvényes e. Az OCSP kérések és válaszok 83

85 feldolgozásához a Bouncy Castle programkönyvtár org.bouncycastle.ocsp és az org.bouncycasle.asn1 csomagját használjuk fel. 23. ábra az OCSPConfirm osztály felépítése Attribútumok: keytstore, objektum a rendszer saját authentikációs tanúsítványát tartalmazza truststore, a hitelesítés-szolgáltatók SSL tanúsítványait kiállító tanúsítványokat tartalmazza URL, a hitelesítés-szolgáltató OCSP szerverének elérési címét tartalmazza issuercert, az OCSP szerver tanúsítványát kiállító legfelsőbb szintű hitelesítésszolgáltatói tanúsítvány keystorepass, az authetikációs tanúsítvány beolvasásához szükséges jelszót tartalmazza Metódusok: generatesslfactory: a paraméterként kapott két KeyStore objektum alapján új SSL kontextust hoz létre, amellyel felüldefiniáljuk az alapértelmezett HttpsURLConnection osztály által használt SSLSocketFactory osztályt. getconnection: a paraméterként kapott elérési cím alapján megállapítja, a kapcsolathoz használandó protokollt, ennek alapján létrehozza a kapcsolatnak megfelelő típusú URLConnection típusú objektumot, az objektumon keresztül beállítja a kapcsolat paramétereit. generateocspreq: a paraméterként kapott X509Certificate tömb alapján előállítja az OCSP kérést tartalmazó OCSPReq objektumot. checkresponses: az OCSP válaszban található állapotok alapján megállapítja, hogy a tanúsítvány érvényes-e. 84

86 validatecertificate: eldönti, hogy a paraméterként kapott két tanúsítvány alapján, hogy egy tanúsítvány tényleg egy adott tanúsítvánnyal hitelesítettek. checkresponsevalidity: az OCSP válaszból kiolvasott tanúsítványok alapján, felépíti a tanúsítványláncot, majd az issuercert változóban található tanúsítvány alapján leellenőrzi a az OCSP válaszban található tanúsítvány hitelességét, azaz leellenőrzi, hogy a válasz hiteles e. getocspconfirmations: az eddig definiált metódusokra alapozva, kapcsolatot teremt a hitelesítés-szolgáltató OCSP szerverével, generál egy OCSP kérést, válaszban található állapotok és tanúsítványok hitelessége alapján állapítja meg a paraméterben kapott tanúsítványok érvényességét Az időbélyegző komponens Az aláírt adatokhoz szükséges időbélyegek beszerzésérről a TimeStamper osztály gondoskodik. Az időbélyegző szolgáltató szerverével az inicializáláskor kapott paraméterek lapján hoz létre új kapcsolatot. Az kapcsolathoz szükséges protokollt az időbélyegző szerver elérési címe alapján határozza meg. SSL kapcsolat esetén a paraméterként kapott két kulcstár alapján új SSL kontextus hoz létre. Az időbélyegek előállítása a paraméterként kapott bájt tömbök alapján történik. Az időbélyegek hitelességének megállapításhoz le kell ellenőrizni a rajtuk lévő aláírás és benne található tanúsítvány hitelességét illetve azt, hogy a válasz az általunk generált kérésre érkezett. 24. ábra a TimeStamper osztály felépítése Attribútumok: keytstore, objektum a rendszer saját authentikációs tanúsítványát tartalmazza 85

87 truststore, a hitelesítés-szolgáltatók SSL tanúsítványait kiállító tanúsítványokat tartalmazza URL, az időbélyegző szerverének elérési címét tartalmazza issuercert, az időbélyegző szerver tanúsítványát kiállító legfelsőbb szintű hitelesítés-szolgáltatói tanúsítvány keystorepass, az authetikációs tanúsítvány eléréséhez szükséges jelszót tartalmazza Metódusok: generatesslfactory: az időbélyegző szerverrel való SSL kapcsolathoz generál új SSL kontextust. getconnection: létrehozza a kapcsolatot az időbélyegző szerverrel, beállítja a kapcsolat szükséges paramétereit. validatecertificate: két tanúsítványról eldönti, hogy az elsőn lévő aláírás a másodiktól származik e. buildcertchain. felépíti az időbélyegben talált tanúsítványok alapján a tanúsítványláncot, megállapítja annak hitelességét. generatetimestamprequest: létrehozza az időbélyeg kérést, a paraméterként kapott bájt tömb alapján. validatetimestampresponse: megállítja az időbélyeg hitelességét, ha a rajta lévő aláírás, a benne található tanúsítványlánc, esetleg nem a megfelelő kérésre tartalmaz választ, akkor az időbélyeg érvénytelen. gettimestamp: az eddigi metódusokra alapozva, elkészíti az időbélyegzés kérést, elküldi az időbélyegző szolgáltató szerverének, megvizsgálja a válasz hitelességét, majd ennek teljesülése esetén visszaadja az időbélyeget egy bájt tömb formájában A szerződés véglegesítő komponens Az aláírási formátum végleges formájának előállítására a XAdEST osztály szolgál. A már előzetesen ellenőrzött, kliens oldalról származó XML aláírási formátumot bővíti ki a rendszer saját aláírásával, majd az aláírásokat időbélyeggel hitelesíti. Az osztály megvalósításához a XAdESB osztály terjesztjük ki, időbélyeg elkészítéséhez a TimeStamper osztályt használjuk fel. Az aláírás és az időbélyeg az XML struktúrába illesztéséhez az org.w3c.dom csomag osztályait alapján történik. Az aláírások időbélyegzéséhez szükség van az Apache XML Security API org.apache.xml.security.c14n csomag osztályaira. 86

88 25. ábra a XAdEST osztály felépítése Metódusok: buildbasexml: az eredeti XAdESB metódust felüldefiniálva, a paraméterként kapott bájttömbből építjük fel az aláírt XML dokumentumot. getdocumentelement: az aláírói formátumból kiolvassa a szerződésdokumentumot és az ügyfél aláírását tartalmazó <es:document> elemet. getobjectid: a szerződésdokumentumot tartalmazó <ds:object> elem azonosítóját olvassa ki az XML struktúrából. getsignatures: az XML struktúrában található, aláírást tartalmazó <ds:signature> elemek számát állapítja meg. addtimestamp: a XML struktúrában található aláírásokon időbélyeget helyez el <SignatureTimeStamp> elemek formájában, az időbélyegek készítéséhez a paraméterként kapott TimeStamper objektumot használja fel A levélküldő ügynök komponens A végleges aláírási formátum ben történő továbbításáról a Mail osztály gondoskodik. A bájt tömbben tárolt XML struktúra és a felhasználói adatok alapján elkészíti a továbbítandó t, melyet a megadott elérési címen található SMTP szerverre csatlakozva kézbesít. A Mail osztályban található Auth belső osztály, az SMTP szerverrel való authentikációt valósítja meg. Az -ek elkészítéshez és továbbításához a JavaMail API javax.mail és a JavaBeans Activation Framework javax.activation csomagjaiban található osztályokat használjuk fel. 87

89 26. ábra a Mail osztály felépítése Attribútumok: host, az SMTP szerver elérhetőségi címét tartalmazza from, az rendszer azonosítóját tartalmazza, ami egyúttal az SMTP szerverhez való hozzáférés felhasználói neve is. to, a címzett címe message, az üzenetet tartalmazó objektum session, az üzenet előkészítéséhez és továbbításhoz szükséges környezeti változó beállításokat tartalmazó munkamenet objektuma Metódusok: createsession: létrehozza az üzenet elkészítéséhez és továbbításhoz szükséges munkamenet objektumot. generatemessagebodytext: a felhasználó adatok alapján összeállítja az üzenet szöveges tartalmát. createmessage: a bájt tömbben tárolt XML struktúra és a felhasználó adatok alapján összeállítja az -t. sendmessage: az előzetesen megadott authentikációs adatok és az elérési cím alapján létrehozza a kapcsolatot az SMTP szerverrel, majd a megfelelő címre kézbesíti az üzenetet. Az Auth osztály felépítése. user, az authentikációhoz szükséges felhasználónevét tartalmazza password, az azonosításhoz szükséges jelszó karaktertömb formában 88