INTEROPERABILITÁSI BEVIZSGÁLÁSI MÓDSZERTAN

INTEROPERABILITÁSI BEVIZSGÁLÁSI MÓDSZERTAN E-közigazgatás keretrendszer kialakítása projekt 1

A dokumentum az Új Magyarország Fejlesztési Terv keretében, az Államreform Operatív Program támogatásával, az Elektronikus közigazgatási keretrendszer tárgyú kiemelt projekt megvalósításának részeként készült. A dokumentum elkészítésében részt vett: E-közigazgatás keretrendszer kialakítása projekt 2

1. Metaadat-táblázat Megnevezés Leírás Cím (dc:title) Interoperabilitási bevizsgálási módszertan Kulcsszó (dc:subject) interoperabilitás; módszertan; bevizsgálás Leírás (dc:description) A dokumentum az interoperabilitási bevizsgálás lehetıségeit és módszereit ismerteti. Az általános vizsgálati módszerek és alapelveke bemutatása után egy gyakorlati példán keresztül is illusztrálja az IOP bevizsgálás módszerét. Ez alapján más vizsgálatok megtervezhetıek. Típus (dc:type) Szöveg Forrás (dc:source). Kapcsolat (dc:relation). Terület (dc:coverage) Magyarország Létrehozó (dc:creator) e-közigazgatási Keretrendszer Kialakítása projekt Kiadó (dc:publisher) Miniszterelnöki Hivatal Résztvevı (dc:contributor) BME Informatikai Központ Jogok (dc:rights). Dátum (dc:date) 2008. Formátum (dc:format) MS-Word Azonosító (dc:identifier). Nyelv (dc:language) HU Verzió (dc:version) V2.0 Státusz (State) Kötelezı Fájlnév (FileName) EKK_ekozig_IOPbevizsgalasmodszertan_080813_V2 Méret (Size) 516KB Ár (Price). Felhasználási jogok (UserRights). E-közigazgatás keretrendszer kialakítása projekt 3

2. Verziókövetési táblázat A dokumentum neve Interoperabilitási bevizsgálási módszertan A dokumentum készítıjének neve BME Informatikai Központ A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma 2008.08.13. Verziószám V2 Összes oldalszám 34 A projekt azonosítója E-közigazgatás keretrendszer kialakítása 2.1. Változáskezelés Verzió Dátum A változás leírása V1 2008.07.27. MeH-nek átadott végleges verzió. V2 2008.08.13. Minıségbiztosító javaslatainak átvezetése. V3 E-közigazgatás keretrendszer kialakítása projekt 4

3. Szövegsablon Megnevezés Leírás 1. Elıszó (Foreword). 2. Bevezetés (Preamble). 3. Alkalmazási terület (Scope) IOP követelmények 4. Rendelkezı hivatkozások. (References) 5. Fogalom-meghatározások. (Definitions) 6. A szabvány egyedi tartalma. (UniqueContent) 7. Bibliográfia. 8. Rövidítésgyőjtemény. 9. Fogalomtár. 10. Ábrák. 11. Képek. 12. Fogalmak. 13. Verzió. 14. Mellékletek (Appendix). E-közigazgatás keretrendszer kialakítása projekt 5

Tartalomjegyzék 1. Bevezetés... 7 2. IOP szerinti bevizsgálás és tanúsítás... 7 2.1. Tesztelés típusai... 7 2.2. Folyamat... 9 2.3. Intézményi háttér... 11 3. Interoperabilitási teszt... 11 3.4. Definíciók... 11 3.5. Az interoperabilitás szintjei:... 12 3.6. Feltételezések, elıfeltételek... 12 3.7. Vizsgálati dimenziók... 13 3.8. Technikai interoperabilitás tesztelése... 13 3.9. Szemantikai interoperabilitás tesztelése... 13 3.10. Folyamat szintő interoperabilitás... 14 3.11. Tesztelés menetének összefoglalása... 15 3.12. Az interoperabilitási vizsgálat lehetséges eredményei... 16 4. Gyakorlati példa... 17 4.13. Háttér... 17 5. Elızmények... 18 5.14. Együttmőködés a kiszolgálói oldalon... 19 5.15. Együttmőködés az ügyfél oldalán... 20 5.16. Szabványosító szervek vizsgálatai... 22 6. A mérés módszere... 25 6.17. Bevezetés... 25 6.18. Elsı körös ellenırzés... 26 6.19. Tapasztalatok, tanácsok az elsı körös ellenırzéshez kapcsolódóan... 26 6.20. Második körös ellenırzés... 27 6.21. Tapasztalatok, tanácsok a második körös ellenırzéshez kapcsolódóan... 27 6.22. Harmadik körös ellenırzés... 28 6.23. Tapasztalatok, tanácsok a harmadik körös ellenırzéshez kapcsolódóan... 28 6.24. Tapasztalatok, tanácsok az átfogóbb ellenırzéshez kapcsolódóan... 30 6.25. Tapasztalatok, tanácsok a szolgáltatói oldalhoz kapcsolódóan... 31 7. Irodalomjegyzék... 33 8. Függelékek... 34 E-közigazgatás keretrendszer kialakítása projekt 6

4. Bevezetés Az elkészült e-közigazgatási alkalmazást használatbavétel elıtt meg kell vizsgálni, hogy megfelel-e a hatályos és az adott alkalmazásra vonatkozó interoperabilitási elıírásoknak és követelményeknek. Ezen követelményrendszer az interoperabilitási követelménytárban található. A bevizsgálás során a megfelelı teszt készletek használatával a vizsgálatot végzı laboratórium megállapítja, hogy az alkalmazás megfelel-e ezeknek a követelményeknek. A 5. IOP szerinti bevizsgálás és tanúsítás Az interoperabilitási bevizsgálás folyamata nehezen egységesíthetı. Mivel maga az interoperabilitás is meglehetısen tág területet ölel fel, ezért a vizsgálat konkrét módja alapvetıen függ a vizsgálandó interoperabilitási feltételtıl, és ebbıl következıen ki kell dolgozni a tesztkészletet. 5.2. Tesztelés típusai Egymással kommunikácló rendszerek vizsgálatára alapvetıen kétféle bevizsgálási lehetıség van: Konformancia tesztelés annak a megállapítása, hogy egy adott implementáció önmagában megfelel-e valamilyen szabványnak, elıírásnak. Itt az elıírásoknak való megfelelést vizsgáljuk, oly módon, hogy az implementációt a kommunikációs felületén keresztül teszteljük. Interoperabilitási tesztelés annak a megállapítása, hogy egy adott implementáció képes-e együttmőködni más, hozzá kapcsolódó rendszerekkel. Ebben az esetben elsısorban a helyes mőködés vizsgálata a cél, méghozzá a normál mőködés során elıforduló esetekkel. A tesztelés elsısorban a felhasználói felület felıl történik. Jelen esetben elsısorban az második esetre, az interoperabilitási tesztelésre koncentrálunk, mivel a vizsgált körben elsısorban magas-szintő, bonyolult kommunikációt megvalósító alkalmazásokról van szó, amelyek kimerítı konformacia vizsgálata gyakorlatilag nem lehetséges. Mindezek bizonyos körülmények mellett a konformacia vizsgálat során alkalmazott elvekre és módszerekre. A követekezıkben bemutatjuk a két alapvetı vizsgálati módszer eleveit. 5.2.1. Konformancia vizsgálat A konformancia vizsgálat célja annak megállapítása, hogy egy bizonyos, adott követelmények (szabványok) alapján készült implementáció milyen mértékben felel meg a követelmény által támasztott elıírásoknak. Az ilyen tesztelés jellemzıi: Az adott tesztelt implementáció képezi a vizsgálat határait. A vizsgálat során az adott elıírásokat megvalósító felületen keresztül vizsgáljuk a rendszert. Ez a felület rendszerint nem azonos a normál mőködés közben a E-közigazgatás keretrendszer kialakítása projekt 7

felhasználók által elérhetı felülettel. Ezen keresztül akár anormál mőködés során elı nem forduló esetek is vizsgálhatóak. A vizsgálatot egy erre a célra készített teszt-ágyban végzik, amely teljes hozzáférést és vezérlést biztosít a vizsgált rendszerhez. A konformancia vizsgálat rendszerint összetett és formalizált vizsgálat. A következı ábra a vizsgálat általános felépítését mutatja. Tesztelt rendszer teszt interfész Tesztelı rendszer 5.2.2. Interoperabilitási vizsgálat Az interoperabilitási vizsgálat a konformancia vizsgálathoz képest kevésbé formalizálható vizsgálat. A célja elsısorban annak megállapítása, hogy egy adott implementáció képes-e együtt mőködni egy másik, referenciának tekinthetı implementációval. A teszt általános felépítését az ábra mutatja. felhasználó Tesztelt rendszer normál kapcsolat Referencia rendszer felhasználó Az interoperabilitási teszt során a vizsgált rendszert normál mőködés közben vizsgáljuk A vizsgálat jellemzıi: A vizsgált és a referencia rendszer együtt képezik a rendszer határait. A vizsgálat során a normál felhasználói felületen keresztül kezeljük a rendszert és figyeljük meg a mőködést. A vizsgálat megállapításai a felhasználó (a tesztelés során ez lehet ember, vagy szoftver) szempontjából észlelt funkcionalításon alapul és a normál használat során használható és elérhetı interfészeket (UI, API) használja. 5.2.3. Konformacia és interoperabilitási vizsgálatok összekapcsolása A két vizsgálati elv célja eltér. A konformancia vizsgálat megmutatja, hogy az implementáció megfelel a vonatkozó elıírásoknak, de nem ad teljes információt arról, hogy két különbözı implementáció hogyan fog viselkedni egymással. Az interoperabilitási teszt ezzel szemben annyit mutat meg, hogy két (vagy több) implementáció képes egymással együtt mőködni, de a szabványnak (követelményeknek) megfelelést nem igazolja. Önmagában az interoperabilitási teszt nem garantálja, hogy a vizsgált rendszer megfelel az adott elıírásnak, és ennek megfelelıen képes lenne-e együttmőködni, más megfelelı rendszerrel. E-közigazgatás keretrendszer kialakítása projekt 8

A konformancia tesztelés rendszerint meglehetısen összetett, hosszadalmas és költséges mővelet. Ugyanakkor nagyon sok alkalmazási környezetben így a közigazgatásban is rendszerint elegendı megbizonyosodni az interoperabilitásról és valamilyen szinten megvizsgálni azt, hogy a rendszer egyébként a normál mőködés során - megfelel a vonatkozó szabványoknak. A két vizsgálat ötvözhetı egymással, az alábbi ábrán vázoltak szerint. Monitorozás felhasználó Tesztelt rendszer Referencia rendszer felhasználó normál kapcsolat A vizsgálat menete hasonló az interoperabilitási teszteléshez, azonban ennek során passzívan monitorozzuk az implementációk közötti interakciót és megállítjuk, hogy az megfelel-e a vonatkozó elıírásoknak (interfész és kommunikációs elıírásoknak). 5.3. Folyamat Az interoperabilitási tesztelési folyamat alapvetıen két fı szakaszból áll: Interoperabilitási teszt specifikálása o a vizsgálandó interoperabilitási funkciók meghatározása o az architektúra meghatározása o teszt készlet meghatározása o egyes interoperabilitási teszt esetek elıállítása Az interoperabilitási teszt végrehajtása o teszt megtervezése o teszt konfiguráció meghatározása o teszt esetek végrehajtása o eredmények kiértékelése és jelentés készítése 5.3.4. Általános tesztelési architektúra E-közigazgatás keretrendszer kialakítása projekt 9

Tesztesetek Jelentés Naplózás Tesztesetek Teszt koordinátor Tesztelı Tesztelt rendszer Tesztelt rendszer Kommunikációs kapcsolat Referencia rendszer Tesztelı A rendszer részei: A tesztelt rendszer (System Under Test SUT). A megvizsgálandó implementáció, amely normál mőködési környezetben van és kapcsolódik a referencia rendszerhez. A referencia rendszer (Qualified System QS). Ismert tulajdonságokkal bíró, rendszer, amelyet úgy tekintünk, hogy megfelel (konform) a rá érvényes elıírásoknak. A referencia rendszer természetesen lehet más, már létezı rendszer, sıt, lehet a teszt céljaira kialakított rendszer is. A referencia rendszernek nem kell funkcionálisan ekvivalensnek lennie a tesztelt rendszerrel, sıt, általában nem az, hiszen valamiféle együttmőködést kell vizsgálni. A referencia kiválasztása folyhat úgy, hogy valamilyen konformancia teszttel meggyızıdünk egy rendszer megfelelıségérıl és ezt nevezzük ki referenciának. Történhet úgy is, hogy többrendszer interoperabilitását vizsgáljuk és a sikeres vizsgálat után ezeket a rendszereket nevezzük ki referenciának. Mind a tesztelt, mind a referencia rendszert a tesztelési interfészen keresztül használjuk. Ez lehet a normál felhasználói felület, vagy egy olyan felület, amely kifejezetten a tesztelés megkönnyítését szolgálja, de alapvetıen a felhasználói felület funkcionalitást nyújtja. Tesztelı a tesztelt és a referencia rendszer kezelését végzı személy vagy eszköz. Mivel alapvetıen a funkcionális szinten kell vizsgálni a rendszert, ezért a tesztelı a használó szempontjából vizsgál. Egyszerőbb teszteknél a tesztelı lehet ember, összetett vagy reprodukálandó teszteknél pedig valamilyen automatizált (szoftver) eszköz. Teszt koordinátor mivel alapvetıen két rendszert (tesztelt és referencia) vizsgálunk egyidıben, mindkettıt külön teszt esetekkel meghajtva, ezért szükség van a két oldalon folyó tesztek koordinálására, összehangolására. Teszt esetek azoknak a lépéseknek a részletes leírása, amely szükséges az adott IOP követelmény megvizsgálásához. 5.3.5. Teszt készletek elıállítása Az egyes tesztek meghatározása során elı kell állítani a tesztelendı interoperabilitási feltétel meglétét vizsgáló teszt(ek)et. Ennek során a vonatkozó elıírásból (szabvány, mőszaki leírás, stb.) A tesztkészlet elıállítása során a következı lépéseket kell megtenni: a vizsgálandó interoperabilitási funkciók meghatározása az egyes IOP funkciókat meg kell határozni, mivel a teszt eseteket úgy kell majd elıállítani, hogy lehetıség E-közigazgatás keretrendszer kialakítása projekt 10

szerint egy funkcióra koncentráljanak, ugyanakkor összeségükben lefedjék az összes értékelés célját képezı funkciót. az architektúra meghatározása a teszthez szükséges architektúra meghatározása. Ide tartozik a vizsgált és a referencia rendszerek típusa, verziója, konfigurációja. A köztük lévı kommunikáció fajtája, konfigurációja, és más szükséges paraméterek. teszt készlet meghatározása azon teszt esetek készletének összeállítása, amely lefedi a vizsgált funkciót. Annak meghatározása, hogy mely eredményt esetén tekintjük sikeresnek az adott funkció vizsgálatát. egyes interoperabilitási teszt esetek elıállítása a teszt készlet elemi lépéseit tartalmazó esetek elıállítása. A teszt eset léterhozása során meg kell határozni a követekzıket: o Elıfeltételek a teszt eset futtatásához szükséges elızetes beállítások, állapotok, stb. o Teszt lépéseket azokat a tennivalókat, amelyet a teszt végrehajtójának meg kell tennie a teszt végrehajtása érdekében. o Értékelési feltételeket azok a feltételek, amely alapján a teszt lépés sikeressége értékelhetı. 5.4. Intézményi háttér Az IOP szerinti bevizsgálás és tanúsítás igényli a megfelelıen kidolgozott intézményi hátteret. A bevizsgálás és tanúsítás véghezviteléhez szükség van a tanúsítást kiadó intézményre, másrészt az ennek alapjául szolgáló bevizsgálásokat végzı gyártófüggetlen - laboratórium(ok). A nemzetközi tapasztalatok is azt mutatják, hogy van létjogosultságuk kifejezetten IOP bevizsgálással foglalkozó intézményeknek. Ilyen intézmények mőködnek pl. az ETSI (European Telecommunications Standards Institute), vagy az UNH IOL (University of New Hampshire, Interoperabilty Laboratory) keretén belül. A lényeges követelmények az intézménnyel szemben: Legyen szállítófüggetlen. Rendelkezzen a megfelelı szakmai kompetenciákkal. Rendelkezzen a megfelelı infrastruktúrális háttérrel. Tipikus, hogy az IOP bevizsgálási intézmények akadémiai vagy felsıoktatási intézmény részeként mőködnek. 6. Interoperabilitási teszt 6.5. Definíciók A dokumentum további részében bemutatásra kerülı módszerekhez elengedhetetlen a fogalmak megfelelı definiálása. a) Interoperabilitás: Kétirányú együttmőködési képesség. aa) Egyik irány: A komponens a rendszer által nyújtott szolgáltatások közül minden, számára szükséges funkciót megfelelıen tud használni. E-közigazgatás keretrendszer kialakítása projekt 11

ab) Másik irány: A befogadó rendszer az újonnan beillesztett komponens funkcióit megfelelıen tudja használni. 6.6. Az interoperabilitás szintjei: Az interoperabilitás definíciójában adott "tudja használni" képesség több szinten megfogalmazható. Alapvetıen három szintet különböztetünk meg: a) Technikai: ezen a szinten vizsgáljuk, hogy a rendszerek képesek-e egymással kommunikálni, az elıírt protokollt megfelelıen implementálták-e. b) Szemantikus interoperabilitás: Az a kérdés, hogy az átvitt adatok tartalmát azonos módon értelmezik-e a komponensek. Nyilvánvalóan, a szemantikus IOP értelmezése a szervezeti IOP meglétét követeli, hiszen a szervezeti szintő funkció ad lehetıséget az adatok azonosítására. c) Szervezeti szintő interoperabilitás: A komponens azon képessége, hogy a szervezeti mőveletet megfelelıen hajtja-e végre. 6.7. Feltételezések, elıfeltételek A következıkben felsoroljuk azon alapfeltételezéseket, melyek értelmezési környezetet nyújtanak az interoperabilitási tesztekhez. Ezen feltételezések összhangban vannak az EKK projekt tervezési szemléletével és egyértelmően azonosítható a tesztelés fázisa az adott komponens (szolgáltatás, folyamat) életciklusában. a) A komponensek közti kommunikáció rögzített módon történik. A rögzítés lehet szabvány általi, de mindenféleképpen formális módszerekkel leírt. Minden kommunikáció idıbeliségére térjen ki a szabályozás. b) Az interoperabilitási teszt az egyes szolgáltatások integrációja folyamán játszik szerepet. Az integráció az új komponens egy meglévı rendszerbe illesztését jelenti. Feltételezésünk, hogy a meglévı rendszer komponensei interoperábilisek egymással. (Inkrementális jelleg) Amennyiben a rendszer még túl kicsi, ez helyettesíthetı egy kompetencia központtal, amely fontos szerepet játszhat a komponensek komformancia tesztelésénél is. c) Az egyes (meglévı és új) komponensek dokumentációja adott, abból egyértelmően meghatározhatóak az adott komponens használati esetei. A használati eset egy szervezeti szintő leírásnak tekinthetı. d) A komponensek elıre egyértelmően meghatározott adatokon dolgoznak. Ezen adatok nem szükségszerően alacsony szintő típusok, akár összetett struktúrák is lehetnek. Feltételezésünk, hogy egy adott entitás többféle struktúrával is megadható, és ezen ekvivalens leírási módok rögzítettek. Ezen rögzített katalógus az adatkatalógus. Ezen adatkatalógusból csak azokra van szükség, amelyeket az új komponens dokumentációja szerint képes használni. Az adatok leírásánál elsıdlegesen a szabványt kell figyelembe venni, de az interoperabilitási vizsgálat során nagyobb hangsúlyt kap azoknak a már meglévı komponensek általi implementációja. Ezt a komponensek dokumentációja kell, hogy tartalmazza. e) Szükség van továbbá az új szolgáltatás által elvégezhetı folyamatok manuális ellenırizhetıségére E-közigazgatás keretrendszer kialakítása projekt 12

6.8. Vizsgálati dimenziók A teszteléseknek alapvetıen két csoportja van. Néhány problémát már a dokumentáció alapján ki lehet szőrni, viszont a komponensek közös tesztelése kihagyhatatlan két okból is: a) Általános probléma, hogy egy szövegszintő dokumentációnak több megfelelı, de egymással nem kompatibilis implementációja is létezhet, az elégtelen definíciók miatt. b) Egy komplex rendszer lehetséges közbensı állapotainak száma nagyon nagy lehet, amit elméleti okoskodással nem lehet áttekinteni. Az alábbiakban az egyes rétegek tesztelési módszereit részletezzük. 6.9. Technikai interoperabilitás tesztelése Általában ez a legegyszerőbb feladat. Mivel a komponensek jól definiált protokoll szerint kommunikálnak egymással, ezért általában, már a használt szoftverkomponensek dokumentációjából nyilvánvalóvá válik az interoperabilitás megléte. Nagy valószínőséggel létezik olyan hitelesített teszt, amely a szolgáltatások elkészítésénél használt implementációk interoperábilitását vizsgálja, ezért ezek vizsgálatával a problémák még a tervezési fázisban kiküszöbölhetık. Mivel a technikai szintő interoperabilitás hiánya az alap szintő kommunikációt is lehetetlenné teszi, ezért ez hamar kiderül. Amennyiben a tesztek során a kommunikáció nem jön létre, ezen a szinten van a hiba. A réteg külön tesztelését nem látjuk szükségesnek. 6.10. Szemantikai interoperabilitás tesztelése Ezen a szinten azt kell vizsgálni, hogy az új szolgáltatás és a meglévı rendszer adatai tényleg kompatibilisek egymással, illetve a megfelelı entitásokon ugyanazokat az adatokat érti-e, illetve fordítva, hogy a megfelelı adatokon ugyanazokat az adatokat érti-e. Ehhez természetesen nélkülözhetetlen egy jól definiált adatstruktúra megléte. A dokumentációk összehasonlításával a következı szempontok alapján kell elvégezni az interoperabilitási tesztet: a) Az adat leírás konzisztenciája. aa) Formai hibák ab) Ha az új rendszer szolgáltatásaihoz, illetve a létezı komponensekhez való hozzáféréshez olyan adatra lenne szükség, amivel a rendszer nem rendelkezik, akkor azt be kell tudni a többi komponenstıl szerezni. Az ehhez szükséges interfészeknek és folyamatoknak rendelkezésre kell állni. ac) Ha az új rendszer szolgáltatásaihoz szükséges adatokat, vagy adatrészeket a meglévı rendszerek nem tudják produkálni, akkor meg kell vizsgálni, hogy ezen adatok (adatrészek) nélkül is elvégezhetık-e a folyamatok, vagy a folyamat módosítására van szükség ad) Verzióbeli eltérések: elıfordulhat, hogy egyes adatoknak többféle verziója is létezik, ez esetben vizsgálni kell, hogy minden kapcsolódó rendszer érti-e az új szolgáltatás által használt verziókat, illetve a megfelelıt használja-e E-közigazgatás keretrendszer kialakítása projekt 13

b) Egy adott adatfolyam más entitást jellemez: Meg kell vizsgálni, hogy az adott entitás az új szolgáltatáson belül teljesen mást jelent-e, vagy esetleg ezen a kereten belül mégis egyértelmően azonosítható a másik szolgáltatáson belüli entitással. Amennyiben ez fennáll, akkor ez nem interoperabilitási probléma. A tényleges tesztelés a komformancia teszteken túl jelenthet még kompetencia központtal való összevetést, illetve valós folyamatakon szimulálását, melyeknél hibás mőködés esetén rögzítjük a kommunikációt a hiba felderítése érdekében. A tesztet tipikusan IT szakemberek végzik. 6.10.6. Kidolgozás: A folyamat bemeneteinek, kimeneteinek meghatározása. Az összes use-case végrehajtása, és a mőködés során felhasznált adatok regisztrálása. A regisztrálás történhet proxy szolgáltatókkal, a kommunikáció monitorozásával, illetve adatbázis mőveletek naplózásával. A teszt során minden használati esetben felhasznált adatot kategorizálni kell a bemenet, ill. kimenet osztályba. A tesztesetek minden elıforduló kimenet/bemenet variációt le kell fedjenek. A teszt során ezen adatokat kell monitorozni a változás tekintetében (változott-e vagy sem). 6.11. Folyamat szintő interoperabilitás A szervezeti szintő problémák áttekintése a legproblémásabb, hiszen itt a legnehezebb jól definiálható sztenderdek kialakítása és ez az a réteg, amely mőködés során is változni fog, a jogi szabályozásnak megfelelıen. Elterjedt interoperabilitási ajánlás, hogy minden bıvítést apró lépésenként kell végrehajtani. Ez azt jelenti, hogy elıször az új szolgáltatás mindössze igénybe veszi a létezı szolgáltatásokat, majd miután ez hibátlanul mőködik, lehet módosítani a régi szolgáltatásokat, hogy azok tudják használni az új szolgáltatás számukra is hasznos funkcionalitásait. új szolgáltatás új szolgáltatás szolgáltatás 3 szolgáltatás 3 szolgáltatás 1 szolgáltatás 2 javított verzió szolgáltatás 1 szolgáltatás 2 Az interoperabilitási vizsgálatnak két nagy területre kell kiterjednie. Egyrészt vizsgálnia kell, hogy az új szolgáltatás által hirdetett folyamatok végrehajthatók-e, illetve, hogy ezek végrehajtása nem okoz-e fennakadást a már mőködı rendszerben. A végrehajthatóság vizsgálatát nagyrészt el lehet végezni a dokumentáció alapján is. A legfontosabb szempontok: E-közigazgatás keretrendszer kialakítása projekt 14

a) Az új szolgáltatás által elvárt szolgáltatások léteznek-e, azok lehetséges kimenetele megegyezik-e az általunk elvárttal b) Az új szolgáltatáshoz szükséges adatokhoz és segédszolgáltatásokhoz való megfelelı jog (se nem túl tág, se nem túl szők), hozzáférés Az új szolgáltatás beillesztése során a régi rendszerben létrejövı problémák forrásai: a) Foglaltsági problémák: Az egyes események által létrehozott adatváltoztatási tilalmak, és azok feloldásának konzisztenciája b) Folyamatok konkurenciájából (idıbeli versengésébıl) származó problémák: párhuzamosan futó folyamatok adatintegritási problémával találkozhatnak. c) Egy régi alkalmazás egy implementált, de eddig folyamat hiányában nem tesztelt szolgáltatása. Folyamat szintő interoperabilitás esetén az elızıekben megvizsgált változás helyességének tényét kell megvizsgálni. 6.11.7. Kidolgozás: Bemenetek: Az egyes használati esetek, a használati eset által érintett adatok elıtte-utána adatleírási példái A kidolgozás során a komponens által képviselt folyamat helyessége kerül górcsı alá. A teszt során az adott folyamat minta adatokkal történı referencia végrehajtás által elıállított adatait kell összehasonlítani az adott komponensen keresztüli végrehajtás által létrehozott új adatállapotokkal. A teszt mindenképpen igényli a szakterület képviselıinek jelenlétét. 6.12. Tesztelés menetének összefoglalása a) A dokumentációk vizsgálata a kommunikációs problémák felderítésére az ott használt alkalmazások alapján b) ba) A dokumentációk vizsgálata alapján az adatok definíciójában fellépı különbségek, hibák felderítése, illetve annak vizsgálata, hogy minden szükséges adat elıállítható és megszerezhetı. bb) Az éles tesztelés ebben az esetben is elengedhetetlen, hiszen könnyen lehetnek értelmezési problémák a sztenderdek implementációja során. c) ca) A dokumentációk alapján vizsgálni kell, hogy a hivatkozott folyamatok megfelelıen vannak definiálva, az arra kapható válaszok megfelelnek-e az új rendszer elvárásaival. Vizsgálni kell, hogy az új rendszer mindig a megfelelı módon hozzáférhet-e a szükséges adatokhoz, de máshoz nem cb) Az éles tesztek alapján vizsgálni kell, hogy az új rendszer szolgáltatásai valóban együtt tudnak-e mőködni a régi rendszerrel, a kapott eredmény ugyanaz-e, mintha a mőveletet kézzel hajtottuk volna végre cc) Az éles tesztek közben hasonló módon tesztelni kell a régi rendszert is, hogy az új szolgáltatás megjelenésével nem történt-e változás E-közigazgatás keretrendszer kialakítása projekt 15

6.13. Az interoperabilitási vizsgálat lehetséges eredményei a) igen, az új komponens interoperabilis: Az új komponens a rendszerbe (rendszer határvonalai, rendszer komponenseinek verziószámai rögzítve) illesztve a dokumentációjában leírt use-case ekre nem produkált hibás eredményt. b) Nem, a rendszer nem interoperabilis: Az új komponens nem képes együttmőködni a régi rendszerrel. Az inkompatibilitás okát a megsértett IOP szintnek megfelelıen kell leírni: a) adat: aa) konformancia: Konkrét példa, mely a kommunikáció monitorozása során lehallgatott bájtfolyam, melléírva a szöveges értelmezés, és az adott kivétel általánosításából képzett formális leírás, ha szükséges. ab) adat ekvivalencia: Konkrét példa, szintén mellékelve a kommunikáció történetét, valamint hivatkozás az adatkatalógusra. b) szemantikai: ba) A dokumentációban meghatározott use -case. Hivatkozás a folyamatra, melyet az adott use-case meghatároz, és a kivételt okozó adatmódosítás c) Folyamati szintő: ca) Az adott folyamatra való hivatkozás, a nemmegfelelési példa. E-közigazgatás keretrendszer kialakítása projekt 16

7. Gyakorlati példa A következıben bemutatjuk egy konkrét interoperabilitási követelmény bevizsgálásának folyamatát. A folyamat az elektronikus aláírást, mint az egyik alapvetı fontosságú interoperabilitást igénylı megoldást vizsgálja, a BME Informatikai Központ és a Hunguard Kft. által kifejlesztett vizsgálati eljárással. A leírás közvetlenül alkalmazható ilyen jellegő vizsgálatra, illetve mintaként adaptálható más hasonló jellegő vizsgálathoz. A gyakorlati példa már egy konkrét elıírás (elektronikus aláírás formátum) betartásának ellenırzését mutatja be. Jelen esetben az aláírást elıállító és az ellenırzı alkalmazás közötti interoperabilitás megállapítása a cél. A kommunikációs folyamat egyszerő, ugyanis állományok átvitele történik. Ennek megfelelıen igen könnyő a kommunikáció megfigyelése. 7.14. Háttér Az elektronikus aláírás elterjedésének technológiai nehézségei között az együttmőködési képesség megteremtését szokták emlegetni. Az aláírás struktúráját meghatározó, a webes alapokhoz könnyebben illeszkedı XML elektronikus aláírás szabványai önmagában nem elegendık ezen együttmőködési képesség biztosításához, bár vitathatatlanul elengedhetetlen feltételei. Az alkalmazások mőködésének logikája, a szolgáltatói oldal és a fejlesztıkörnyezet adta lehetıségek komoly mértékben tudják befolyásolni a világmérető együttmőködés sikerét. A veszélyeket felismerve az IETF (Internet Engineering Task Force) és W3C (World Wide Web Consortium) nemzetközi szabványosító szervek bonyolították le az elsı, független vizsgálatokat több neves fejlesztı bevonásával. Az alkalmazások az XMLDSIG ([1], [2]) szabványon alapultak, vizsgálatuk több körben zajlott le 2000. márciusa és 2004. áprilisa között. http://www.w3.org/signature/2001/04/05-xmldsig-interop.html Az XMLDSIG szabvány hamar felkeltette az Európai Unió egyik szabványosító szerve, az ETSI (European Telecommunications Standards Institute) figyelmét. Az 1999-ben kiadott direktíva az elektronikus aláírásról a jogszabályi hátterét is megteremtette az amúgy 70-es évek második felében megszületett technológiának. Az ETSI szakemberei ehhez a jogi környezethez próbálták igazítani az XMLDSIG ([1], [2]) elektronikus aláírást, így ennek kiegészítéseként megszületett a XAdES ([3]) szabvány. A XAdES ([3]) szabványon alapuló fejlesztések az XMLDSIG ([1], [2]) szabványban leírtaknál összetettebb, a valós élethez, igényekhez jobban igazodó struktúrát kellett, hogy megvalósítsanak, ezért itt is felmerült az együttmőködési képesség vizsgálatának igénye. Az ETSI szakemberei 2003. novembere és 2004. október között több vizsgálatot is tartottak. A tapasztalatok alapján módosították, pontosították a XAdES szabványt. http://www.etsi.org/plugtests/history/history.htm Magyarországon is több fejlesztés indult el, hogy az információs társadalom számára elérhetıvé váljanak olyan szolgáltatások, amelyek alapvetı feltétele bizonyos biztonsági szempontok megvalósítása. Kiemelt szerepet kaptak ezek közül az eeurope 2005 Action Plan E-közigazgatás keretrendszer kialakítása projekt 17

dokumentumban taglalt elektronikus kormányzati szolgáltatások (12 + 8 közszolgáltatás), ahol külön felhívják a figyelmet a szabványosság, együttmőködı-képesség fontosságára. Interoperability. [...] It will be based on open standards and encourage the use of open source software. /forrás: [4]/ Magyarországon 2005. november 1-ével lépett hatályba a Ket. (2004. évi CXL. törvény a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól), amely értelmében már valóban szükségessé vált a szabványos, együttmőködésre képes alkalmazások fejlesztése. A téma hazai szakértıit tömörítı MELASZ (Magyar Elektronikus Aláírás Szövetség) idejében felismerte, hogy a késıbbiekben felmerülhetnek problémák, ezért az elektronikus aláírás-létrehozó és ellenırzı alkalmazások fejlesztıinek, illetve a hitelesítés-szolgáltatók képviselıivel együtt átfogó munkába kezdett. A megbeszélések során a vonatkozó szabványok egyes pontjait vették sorra: ahol nem volt teljesen egyértelmő a szöveg, ott pontosítottak rajta, ahol a jogi vagy más szabályozás miatt szükséges volt, ott szigorítottak az eredeti szabványon, ahol nem volt útmutatás a szabványban, ott kidolgoztak bizonyos követelményeket. A megbeszélések eredményeként született meg az Egységes MELASZ formátum elektronikus aláírásokra címet viselı dokumentum elsı változata, amely a jelen jegyzıkönyvben leírt együttmőködıképesség-vizsgálat egyik bemenete volt. Az együttmőködési képesség, a szabványosság az informatikai biztonság egyik alapvetı követelménye. Együttmőködésre képtelen, nem szabványos megoldásoknál azt tapasztalhatnánk, hogy ugyanazon bemenetre különbözı kimenetek születhetnek. Ezek az eredmények jelenthetik egy elektronikus aláírás elfogadását vagy visszautasítását, vagy más területen pl. egy bizalmas dokumentumhoz való hozzáférés engedélyezését vagy tiltását. Egy adott termék (pl. elektronikus aláírás létrehozó és ellenırzı alkalmazás) informatikai biztonsági követelményeknek való megfelelését több szempontból lehet vizsgálni. Az együttmőködıképesség-vizsgálat mellett a Common Criteria módszertanon alapuló hazai sémának (MIBÉTS) való megfelelés elvárt. A két vizsgálat egymást kiegészíti, a különbségre talán jó példával szolgál pl. az SHA-1 lenyomatképzı algoritmus elemzése. Az együttmőködés biztosított, ha a fejlesztıkörnyezet SHA-1 kriptográfiai függvénye pontosan betartja a szabványban leírtakat a mőködésnél, más szempontból megközelítve viszont azt kell vizsgálni, hogy az SHA-1 algoritmus megfelelı használatával érvényre jutnak-e a biztonsági szempontok. A jelen vizsgálat kizárólag az együttmőködı-képességre összpontosított. 8. Elızmények Napjaink biztonságos bizalmas, hiteles, sértetlen, letagadhatatlan kommunikációjának alapfeltétele, a kriptográfia és a ráépülı megoldások története a 70-es évekbe nyúlik vissza, amikor a matematikai értelemben vett nehéz problémákon (pl. prímfaktorizáción, azaz a prímtényezıkre való bontáson) alapuló elsı algoritmusok mint az RSA (R. Rivest, A. Shamir, L. Adleman) aszimmetrikus kódoló algoritmus megszülettek. E-közigazgatás keretrendszer kialakítása projekt 18

A TCP/IP protokollokon alapuló és más nem biztonságos hálózatokon szimmetrikus és aszimmetrikus kódoló algoritmusok révén lehet biztosítani a biztonságos kommunikáció feltételeit. Az informatikai háttér megteremtéséhez szükséges egy PKI (Public Key Infrastructure) megoldás, amelynek RA (Registration Authority) eleménél az ügyfél igényelhet tanúsítványt (az ügyfél megkülönböztetett nevének és nyilvános kulcsának összerendelés, amely alapján egyértelmően lehet azonosítani az elektronikus világban), a CA (Certification Authority) eleme kibocsátja és nyilvános adatbázisba (Directory) helyezi a tanúsítványt, amelyet bárki el tud érni. A szolgáltató által elıállított kriptográfiai kulcsok nyilvános fele a tanúsítványban található, míg a titkos fele olyan adathordozó eszközre kerül, amelybıl nem nyerhetı ki. Az intelligens kártyák (akár a SIM-kártyák is) képesek bizalmasan tárolni az adatokat, egy kriptográfiai mőveletnél a bemeneten megkapott adatok kódolása a chip belsejében a titkos kulcs kiadása nélkül megy végbe és a kimeneten a kódolt adat jelenik meg. Az ügyfél oldalán futó alkalmazás, az adathordozón (pl. intelligens kártya) tárolt titkos kulcs és a bárki által elérhetı tanúsítvány segítségével digitális aláírást (azaz kriptográfiai algoritmuson alapuló elektronikus aláírást) és rejtjelezett üzeneteket lehet elıállítani. Zárt csoportoknál, cégek berkein belül mőködı PKI megoldásoknál a kiszolgáló és az ügyfél oldalának termékei egy gyártótól származtak, így napjaink legnagyobb problémája, az együttmőködési képesség hiánya fel sem merült. Maga a kiszolgáló és az ügyfél oldala sem vált szét, hiszen a legtöbb esetben a böngészıbe vagy irodai alkalmazásokba beépülı elemek a PKI részét képezték, kevés olyan alkalmazás volt, amelyek jól elhatárolt, szabványos felületeken keresztül kizárólag létrehozták és ellenırizték a kriptográfiai eljárások révén elıállt adatokat, így a különbözı gyártóktól származó termékek különbözı módon állították elı és ellenırizték a digitális aláírással ellátott, rejtjelezett üzeneteket. Megszületett az Európai Unió 1999/93/EC jelöléső direktívája (amelyen a 2001. évi XXXV. és a 2004. évi LV. törvény alapul), amellyel kitárult a világ és az együttmőködési képesség alapvetı fontosságúvá vált azoknál, akik ki is akarták használni az elınyöket, azaz a külvilággal való kapcsolattartást biztonságos, gyors és költséghatékony alapokra akarták áthelyezni. 8.15. Együttmőködés a kiszolgálói oldalon A kiszolgálói oldalon problémák merültek fel a tanúsítványkérelmekkel, kereszttanúsításokkal, intelligens kártyák kezelésével kapcsolatban. A CA elemek által alkotott fastruktúrában, a CA-hierarchiában az egyes elemek alá-fölérendeltségi (root-ca és subordinate-ca) és mellérendeltségi viszonyban (cross-certification) helyezkedhetnek el. A hierarchiába való betagozódáshoz amely szükséges ahhoz, hogy egy adott felhasználói tanúsítvány tanúsítási láncolatát végig lehessen követni egymás tanúsítványait kell a megfelelı protokollok révén felültanúsítani, azonban az ehhez szükséges kommunikáció is több szabványon alapulhat. A tanúsítványkérelem elıállítása történhet az IETF RFC 2314 (IETF RFC 2986) szabvány szerint, amely PKCS#10 név alatt jobban ismert, illetve a CRMF (IETF RFC 2511) szabványban leírtak alapján is. Az üzenetek beágyazására is több megoldás E-közigazgatás keretrendszer kialakítása projekt 19

létezik, hiszen a CMC (IETF RFC 2797) mellett lehet használni a CMP (IETF RFC 2510) szabványon alapulót is. Problémák merültek fel az elıállított tanúsítvány felépítésével kapcsolatban is. A valós világban létezı objektumok (pl. természetes személyek) elektronikus világba történı egyértelmő leképezéséhez megfelelıen kell elıállítani a megkülönböztetett nevet (distinguished name), amely a tanúsítványba is bekerül, éppen ezért nem mindegy, hogy mely névelemeket tartalmazza, melyeket tudja értelmezni egy PKI megoldás. A tanúsítvány többi elemével (mezık, kiterjesztések) is voltak gondok, hiszen az eredeti ITU ajánlások és az IETF vonatkozó szabványai között is léteznek eltérések, illetve az Európai Unió jogi szabályozásának megfelelendı az ETSI szabványai is tartalmaznak kiegészítı elemeket. Az intelligens kártyákkal, kártyaolvasókkal való kommunikáció is nehézkesnek bizonyult, így külön projekt keretén belül kellett megvizsgálni az együttmőködési képesség hiányának okait. A PKCS szabványokkal kiegészített ISO/IEC 7816 szabványsorozat határozza meg többek közt a fizikai tulajdonságokat, a kommunikációhoz szükséges függvények, utasítások felépítését. Az intelligens kártyákon való bizalmas adatok elhelyezése a kiszolgáló oldalán történik, azonban az ügyfél használja, fér hozzá ezen adatokhoz, ezért az ügyfél oldalán is biztosítani kell az együttmőködési képességet. A névtár a PKI megoldások azon része, amely kívülrıl és a belsı elemek számára is elérhetı. Az eredeti elképzelések az ITU ajánlásai szerint világmérető mőködésrıl, elosztott rendszerekrıl, lekérdezésre optimalizált adatbázisokról szóltak. Az ITU-T X.500-as ajánlások követelményei mellett az egyszerősített elérési protokollt és felépítést LDAP leíró szabványok (pl. IETF RFC 2251) is megjelentek és termékeket is fejlesztettek ezen alapulva. A csökkentett képességekkel bíró névtárak nem tudnak elosztott rendszerként mőködni, hiszen az ITU-T X.500-as névtárak DSP (Directory System Protocol) protokollja hiányzik az LDAP szabványból, így ezen probléma kiküszöbölésére külön megoldást kellett a szakembereknek keresni. A kiszolgálói oldal együttmőködési képességét vizsgáló munkák között a pkic (PKI Challenge), Bridge-CA, European Bridge-CA, eesc (eeurope Smart Cards) projekteket érdemes megemlíteni. 8.16. Együttmőködés az ügyfél oldalán Az ügyfél oldalán futó alkalmazások késıbb kerültek terítékre, de a gondok is komolyabbak voltak az aláírás felépítésével, a tanúsítvány kezelésével kapcsolatban. A kezdeti idık ügyfél oldalán futó alkalmazásai inkább a PKI megoldások szerves részeként mőködtek, gyártónként változott, hogy milyen módon épültek be az egyes alkalmazásokba (irodai alkalmazásokba, böngészıkbe), milyen módon hozták létre és ellenırizték a digitális aláírást, az ellenırzés során hogy kezelték a tanúsítvány visszavonási adatokat, éppen ezért az együttmőködési képesség hiánya volt tapasztalható a különbözı termékek között. E-közigazgatás keretrendszer kialakítása projekt 20

Az S/MIME version 2 és version 3 változatokról, illetve a CMS üzenetekrıl (Cryptographic Message Syntax) szóló IETF szabványok megjelenése után nem sokkal adta ki a W3C és IETF az XML elektronikus aláírás felépítését meghatározó szabványát, amelyet a webes technológiák térhódításának köszönhetıen ma már alapkövetelményként határoznak meg a különbözı elektronikus kormányzati, elektronikus közigazgatási dokumentumokban. Az XML alapokon nyugvó elektronikus aláírás mellett szól, hogy az S/MIME szabványnak vannak hiányosságai (pl. nincs lehetıség idıbélyeg kezelésére a signingtime tulajdonságnál), illetve az, hogy az XML-es megoldás a jövıben könnyebben tud együttmőködni a webes megoldásokkal, a web service technológián alapuló szolgáltatások SOAP (Simple Object Access Protocol) révén történı elérésénél, amelyhez a WSDL (Web Services Description Language) leírás és az UDDI (Universal Description, Discovery and Integration) nyilvántartás is szükséges lehet. Az XML elektronikus aláírási séma legszőkebb halmazát az IETF RFC 3275 szabvány tartalmazza, azonban ezt az ETSI TS 101 903 szabvány kiegészítette. Az elmúlt csaknem 7 évben a W3C, az IETF, illetve az ETSI több vizsgálata (a 2003. és 2004. évben tartottak) alapján ma már kiforrott szabványról lehet beszélni, amelyek alapján együttmőködésre képes alkalmazásokat lehet fejleszteni. A szabványosító szervek által végzett vizsgálatok tapasztalatai alapján a MELASZ (Magyar Elektronikus Aláírás Szövetség) is hasonló vizsgálatot kezdeményezett Magyarországon. A vizsgálathoz szükséges közös szempontokat, követelményeket, az Európai Unió jogi feltételeinek megfelelı XML elektronikus aláírást az ETSI TS 101 903 szabvány határozta meg. The XAdES-BES satisfies the legal requirements for electronic signatures as defined in the European Directive on electronic signatures. /forrás: [3]/ Az együttmőködési képesség hiányosságai a szolgáltatótól kapott tanúsítvány feldolgozásánál már jelentkeztek. A megkülönböztetett nevek nem megfelelı kezelése révén elıfordulhatott, hogy egy alkalmazás e-mail cím alapján azonosította a felhasználót, azaz nem magát a felhasználót kezelte, hanem csak a postafiókját. Bár, az e-mail cím egyedi adat (kivéve, ha pl. nem használják fel újra egy webes, ingyenes levelezırendszernél a megszőnt azonosítót) a felhasználó megkülönböztetett nevét egyszer meghatározott és egyedi adatok alapján érdemes elıállítani (pl. felhasználó neve, születés helye és ideje, anyja neve), különben az értelmezésnél problémák merülhetnek fel. Az alkalmazásoknál súlyosabb problémát vetett fel a tanúsítványok keyusage és extkeyusage kiterjesztéseinek nem megfelelı kezelése, hiszen ezek révén lehet a kulcshasználatot meghatározni úgy, hogy az megfeleljen a jogi (pl. külön kulcsok rejtjelezésre és digitális aláírásra) és technológiai (pl. minısített tanúsítvány esetében letagadhatatlan digitális aláírás, amelynek ellenırzését szükség esetén megbízható harmadik fél által kell tudni biztosítani) szabályozásnak is. A tanúsítványok felhasználási feltételeinek ellenırzéséhez kapcsolódik a CP (Certificate Policy) dokumentum is, amelyben a szolgáltató meghatározza ezeket. A CP dokumentum certificatepolicies kiterjesztésben megadott elérhetıségét és azonosítóját az alkalmazásnak értelmezni kell tudnia. A tanúsítványok visszavonási adatainak beszerzése és értelmezése kritikus pontja az ellenırzésnek mégis nagyon sok alkalmazásnál lehet hibás mőködést tapasztalni. A tanúsítványban szereplı megkülönböztetett név alapján az elosztott adatbázisban, névtárrendszerben indított keresés mellett lehetıség van a crldistributionpoints kiterjesztésben megtalálható adatok alapján (pl. URL) megszerezni a legfrissebb tanúsítvány E-közigazgatás keretrendszer kialakítása projekt 21

visszavonási listát (CRL). A tanúsítvány visszavonási állapot lekérdezése egy másik protokoll, az OCSP (IETF RFC 2560) révén történhet meg. A mőveletet az ellenırzés pillanatában kell végrehajtani, a legfrissebb visszavonási adatok alapján folytatni, azonban sok alkalmazás már korábban letöltött, ütemezett letöltés révén megszerzett adatokat használ, de a régebbi fejlesztéseknél nem is volt kidolgozva a távoli szolgáltatás elérésének lehetısége. A tanúsítvány visszavonási adatok ellenırzésének fontossága kulcskérdés, hiszen mindennapi eset lehet, hogy a felhasználó elveszti intelligens kártyáját és azt be is jelenti a szolgáltatónál, amely visszavonási listára helyezi tanúsítványát. Az intelligens kártyát és a PIN kódot illetéktelen megszerzi, majd az átutaltat saját bankszámlájára pénzt. Az átutalási megbízás digitális aláírással van ellátva, azonban az alkalmazás nem tölti az ellenırzés pillanatában létezı legfrissebb tanúsítvány visszavonási adatot, így nem szerez tudomást arról, hogy az adott tanúsítvány vissza van vonva, és az átutalási kérelmet el kell utasítania. A nem megfelelı mőködés tehát felelıs lehet a hamis biztonságérzet kialakulásáért, amely nagyobb károkat okozhat, mintha a felhasználó tudatában lenne a veszélyeknek. A tanúsítványok és a tanúsítványi láncolatok vizsgálata is összetettebb a kriptográfiai adatok visszafejtésénél. A tanúsítványon elhelyezett digitális aláírás ellenırzése során fel kell térképezni az egész tanúsítványi láncolatot a végfelhasználótól egészen a megbízható pontig (root-ca), amelyek mindegyikét meg kell vizsgálni a kriptográfián túlmenıen is (pl. a subject elem a kibocsátó CA tanúsítványában megegyezik az issuer elem tartalmával a kibocsátottéban, a validity mezıben szereplı érvényességi határidıket is vizsgálni kell). Az ügyfél oldalán futó alkalmazásokkal kapcsolatban általánosságban el lehet mondani, hogy nem a digitális aláírás létrehozása a bonyolult mővelet, hanem annak ellenırzése, ennek ellenére a legtöbb terméknél az ellenırzı összetevık ingyenesen elérhetık az interneten. A tanúsítványok kezelésén túlmenıen az alkalmazások számára meg kellett határozni a kezelendı kriptográfiai algoritmusok körét is (pl. SHA-1 lenyomatképzı algoritmus és RSA aszimmetrikus kódoló algoritmus), hiszen az MD5 algoritmus révén képzett lenyomatot nem tudna egy az SHA-1 algoritmust használó alkalmazás érdemben kezelni, ezért ez is egy újabb lépés volt az együttmőködési képesség biztosítása felé vezetı úton. Az elıállítandó digitális aláírás formátuma is a bemenı adatok között kell, hogy szerepeljen, hiszen az XML elektronikus aláírás ellenırzésére képes alkalmazás nem tudná értelmezni az S/MIME version 3 szabványnak megfelelı üzenetet. A technológiai szabványok alapján fejlesztett alkalmazásoknál hiába állítja a gyártó, hogy megfelel a követelményeknek gyakran a termék megvásárlása és telepítése után derül ki a felhasználó számára, hogy az bár látszólag valóban teljesíti a szabvány által leírtakat, mégis hiba lép fel más termékekkel való együttmőködés közben. A hibák okaira alkalmazásszintő vizsgálat során gyakran csak következtetni lehet, a tényleges feltáráshoz és javításhoz forráskód szinten kell elemezni a mőködést. Az együttmőködési képesség vizsgálatainál gyakori hiba lehet ehhez elég a nyílt szövegként megjeleníthetı digitális aláírás felépítését elemezni az adatok szabványtól eltérı sémája (pl. más névelem használata az XML esetében, aláírt állomány beágyazása nem megfelelı módon, a szabványban kötelezıként megjelölt elemek kihagyása). 8.17. Szabványosító szervek vizsgálatai E-közigazgatás keretrendszer kialakítása projekt 22

Az IETF és W3C szabványosító szerv elsıként 2000. márciusában tartotta az elsı együttmőködési képességet vizsgáló rendezvényét. A 2001. áprilisában tartott rendezvényen részt vett a Baltimore, Ubisecure, Wedgetail, Fujitsu, GapXse, HP, IAIK, Infomosaic, IBM, Microsoft, NEC, Phaos, RSA, Apache, XMLSec és DataPower, amelyek termékei alapos vizsgálaton estek át. http://www.w3.org/signature/2001/04/05-xmldsig-interop.html A vizsgálatok alapját az IETF RFC 3275 szabvány adta, amely a W3C XML-Signature Syntax and Processing ajánlásán alapul. Az ETSI szabványa kiegészítette az XML elektronikus aláírás alapsémáját, amely a vizsgálati szempontok listáját is bıvítette. Az ETSI TS 101 903 szabványon (XAdES) alapuló elektronikus aláírás-létrehozó alkalmazások együttmőködésének vizsgálata címszóval 2003. novemberében, 2004. májusában és 2004. októberében tartottak rendezvényt. http://www.etsi.org/plugtests/ A vizsgálatok eredményein alapulva az ETSI TS 101 903 szabványt többször módosították, pontosították. A kifejlesztésre kerülı alkalmazásoknak a MELASZ Ready vizsgálatoknál meg kell felelniük a szabvány ezen változatának, és az esetleges késıbbi módosítások esetén is a v1.2.2 változatnak megfelelı XML elektronikus aláírást mindenképpen kezelnie kell tudni a különbözı termékeknek. Érdemes áttekinteni, hogy az elmúlt három évben milyen tapasztalatokkal lettek gazdagabbak a fejlesztık és a szabványosítók az ETSI TS 101 903 szabványon alapuló együttmőködési vizsgálatok során. Az együttmőködési problémák gyökereinek vizsgálatához hasznos lehet a fejlesztések során felmerülı kérdéseket, a fejlesztıi levelezılisták témáit is áttanulmányozni (pl. a kanonizáláshoz canonicalization és a névterek namespace megfelelı használatához is sok kérdés kapcsolódott). A Magyar Elektronikus Aláírás Szövetség (MELASZ) egységes formátumot meghatározó munkacsoportja több ülést is tartott, amelyen a vitás kérdéseket tisztázták. Az elsı megbeszélések és a közigazgatás számára korábban leadott irányelvek [7] alapján megszületett a MELASZ aláírási formátum dokumentum vázlatos anyaga [8]. A munkában résztvevık a MELASZ tagjai közül kerültek ki, és ilyen módon képviselve volt mind az ügyfél oldal, mind a szolgáltatói oldal több hitelesítés-szolgáltató, idıbélyegzı szolgáltató és alkalmazásfejlesztı révén. A megbeszéléseken az ETSI TS 101 903 v1.2.2 szabvány szövegét vették át a szakemberek, sorról-sorra értelmezték a leírtakat, a vitás pontoknál szavazással döntöttek a támogatandó megoldásról. A MELASZ Ready vizsgálathoz, a módszertan kidolgozásához alapvetı bemenetként szolgált ez a dokumentum. A tesztesetek elıkészítése során létre kellett hozni a minta-állományokat (pl. MELASZ Ready dokumentumnak megfelelı XAdES struktúra XML-sémája a séma-validálásokhoz, kanonikalizáció vizsgálatához kapcsolódó állományok), illetve átgondolni a vizsgálat lépéseit, kidolgozni a többi tesztesetet is. A vizsgálatoknál több struktúra, ennek megfelelıen a struktúrák közötti átmenetek (pl. XAdES-T struktúrából módosított XAdES-C létrehozása) is le lettek fedve. A módosított XAdES-C a közigazgatási E-közigazgatás keretrendszer kialakítása projekt 23

igények miatt született meg, ez a struktúra már tartalmazza a tanúsítványokat és visszavonási adatokat beágyazva, azaz ennyibıl hasonlít a XAdES-XL struktúrára, azonban hiányzik belıle referenciákra vonatkozó idıbélyeg. A vizsgálatokon résztvevı összes alkalmazás a kisebb-nagyobb javítások révén sikeresen teljesítette a MELASZ Ready követelményeit. E-közigazgatás keretrendszer kialakítása projekt 24

9. A mérés módszere 9.18. Bevezetés A mérés három nagy lépcsıbıl áll. Az elsı körös ellenırzés során az XML-elemzık (XML parser) és kanonikalizációs függvények szabványnak való megfelelıségét kell vizsgálni. A mérést végzık által szerkesztett és szétküldött minta-állományokra, mint bemenetekre kell választ kapni, mint kimenetet kell vizsgálni bit-szinten. Megjegyzés: A kanonikalizációs függvényeknél az elsı méréseknél feltárt hibák, eltérések már más együttmőködıképesség-vizsgálatnál is elıtérbe kerültek. Az IETF és W3C szakemberei hasonló tapasztalatokat szereztek, ezért az elektronikus aláíráshoz kapcsolódó vizsgálataik elıtt 2000. októberében a kanonikalizációs függvények mőködését is ellenırizték a különbözı alkalmazásoknál. http://www.w3.org/signature/2000/10/10-c14n-interop.html A kanonikalizációs függvények az XML állományokat készítik elı a további feldolgozáshoz (pl. white space karakterek, névterek kezelése). Az XMLDSIG ([1], [2]) és XAdES ([3]) elektronikus aláírásoknál kanonikalizálandó XML állományba ágyazódnak az adatok, amelyeken le kell futtatni a lenyomatképzı (hash) és aszimmetrikus kódoló függvényeket. Eltérı kanonikalizáció esetén változik bit-szinten is az adat, ami alapján teljesen más lenyomat áll elı. Az XMLDSIG ([1], [2]) szabvány kötelezıen elvárja a C14N ([5]) kanonikalizációs algoritmus támogatását. A második körös ellenırzés során egy tetszıleges, de legalább XAdES-C ([3]) XML elektronikus aláírást kell elıállítania a különbözı alkalmazásoknak, amelynél az XML állomány formázottságát (well-formedness) és az XMLDSIG ([1], [2]) és XAdES ([3]) sémán alapuló MELASZ sémának való megfelelıségét (valid) kellett vizsgálni. A mérést végzık által szerkesztett, módosított sémát hozzárendelve a fejlesztıktıl kapott XML állományokhoz bizonyosságot lehetett szerezni azok megfelelıségérıl. A MELASZ séma az eredeti sémában szereplı kötelezı elemeket változtatás nélkül átemeli, illetve ezek mellett néhány elemnél, attribútumnál szigorít a követelményeknél (pl. az Id attribútum sok helyen optional helyett required ). A harmadik körös ellenırzés során egységes szempontoknak megfelelı, az alkalmazások által elıállított aláírásokat kell a létrehozó és minden másik alkalmazással ellenıriztetni. A mérést végzık által szerkesztett követelményeknek megfelelı aláírásokat kell készíteni a különbözı alkalmazásoknál. Ennél a lépésnél már biztosított, hogy az esetleges eltérések nem a kanonikalizációs függvények hibáiból fakadnak, illetve az aláírások megfelelnek a MELASZ sémának. Megjegyzés: E-közigazgatás keretrendszer kialakítása projekt 25