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:


2

1. Metaadat-táblázat Megnevezés Cím (dc:Title) Kulcsszó (dc:Subject) Leírás (dc:Description)

Típus (dc:Type) Forrás (dc:Source) Kapcsolat (dc:Relation) Terület (dc:Coverage) Létrehozó (dc:Creator) Kiadó (dc:Publisher) Résztvevı (dc:Contributor) Jogok (dc:Rights) Dátum (dc:Date) Formátum (dc:Format) Azonosító (dc:Identifier) Nyelv (dc:Language) Verzió (dc:Version) Státusz (State) Fájlnév (FileName) Méret (Size) Ár (Price) Felhasználási jogok (UserRights)

Leírás Interoperabilitási bevizsgálási módszertan interoperabilitás; módszertan; bevizsgálás 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. Szöveg . . Magyarország e-Közigazgatási Keretrendszer Kialakítása projekt Miniszterelnöki Hivatal BME Informatikai Központ . 2008. MS-Word . HU V2.0 Kötelezı EKK_ekozig_IOPbevizsgalasmodszertan_080813_V2 516KB . .


3

2. Verziókövetési táblázat A dokumentum neve A dokumentum készítıjének neve A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma Verziószám Összes oldalszám A projekt azonosítója

2.1. Verzió V1 V2 V3

Interoperabilitási bevizsgálási módszertan BME Informatikai Központ

2008.08.13. V2 34 E-közigazgatás keretrendszer kialakítása

Változáskezelés Dátum 2008.07.27. 2008.08.13.

A változás leírása MeH-nek átadott végleges verzió. Minıségbiztosító javaslatainak átvezetése.


4

3. Szövegsablon Megnevezés 1. Elıszó (Foreword) 2. Bevezetés (Preamble) 3. Alkalmazási terület (Scope) 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)

Leírás . . IOP követelmények . . . . . . . . . . .


5

Tartalomjegyzék 1. 2.

Bevezetés....................................................................................................................................................... 7 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


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


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.


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


9

Tesztesetek

Teszt koordinátor

Jelentés

Naplózás

Tesztesetek

Tesztelt rendszer Tesztelı

Tesztelt rendszer

Referencia rendszer

Tesztelı

Kommunikációs kapcsolat

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


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.


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


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


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 1

szolgáltatás 2 javított verzió

szolgáltatás 3

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:


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


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.


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


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.


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


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.


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


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


22

Az IETF és W3C szabványosító szerv elsıként együttmőködési képességet vizsgáló rendezvényét. A részt vett a Baltimore, Ubisecure, Wedgetail, Fujitsu, Microsoft, NEC, Phaos, RSA, Apache, XMLSec és vizsgálaton estek át.

2000. márciusában tartotta az elsı 2001. áprilisában tartott rendezvényen GapXse, HP, IAIK, Infomosaic, IBM, DataPower, amelyek termékei alapos

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


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.


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:


25

Eltérések így is szép számmal jelentkeztek, amelyek mögött a különbözı alkalmazások mőködési logikája (pl. elektronikus aláírás ellenırzésénél a különbözı tanúsítványok megtalálása, tanúsítványlánc felépítése) mellett a szolgáltatói oldalon felfedezett hiányosságok, pontatlanságok húzódtak meg.

9.19. Elsı körös ellenırzés Az elsı minta-állomány a C14N szabványból ([5]) lett kiemelve. Elınye, hogy a szabvány megadja a bemenetet és az elvárt kimenetet, hátránya, hogy ezek csak „karakter-szinten” adottak, holott a hibák a legtöbb esetben „bit-szinten” jelentkezhetnek. Az elsı mintaállomány célja a „white space” karakterek, a nyitó- és záróelemek kezelésének, a névterek és attribútumok sorrendezésének, a névterek többszörös megadásának, illetve „kimozgatásának” és a fejrészben megadott adatok kezelésének vizsgálata. Az elsı minta-állomány megtalálható a Függelékben (ld. 1. számú függelék). A második minta-állomány egy „lecsupaszított” XML elektronikus aláírás, amelynél a gyökérelemben meg van adva az összes névtér („xmlns”). A C14N szabványban ([5]) leírtaknak megfelelıen ha az XML struktúrából ki kell emelni egy részhalmazt („subset of the nodes”), akkor a szülıelemek névtereinek a megfelelı helyekre kell kerülniük. Ennél a mintánál az egész készletbıl a „ds:SignedInfo” elemet kell kivenni kanonikalizálva. A második minta-állomány megtalálható a Függelékben (ld. 2. számú függelék). A harmadik minta-állomány is a névterek kezelését vizsgálja, de kiemel egy fontos szempontot. A C14N szabvány ([5]) szerinti kanonikalizálás a névterek kezelése szempontjából lényegesen eltér az „exclusive” C14N szabványtól ([6]). A különbség abban mutatkozik meg, hogy a kanonikalizálás során a szülıelemekben megadott névtereket is figyelni kell-e, vagy elég a részhalmazban megadottakat jól elhelyezni. Ennél a mintánál az egész készletbıl a „b:” elıtagú (prefix) névtérbe tartozó elemet tartalmazó „ds:Object” elemet kell kivenni kanonikalizálva. A harmadik minta-állomány megtalálható a Függelékben (ld. 3. számú függelék).

9.20. Tapasztalatok, tanácsok az elsı körös ellenırzéshez kapcsolódóan • kanonikalizációs függvény paraméterezése: be kell állítani megfelelıen a „white space” karakterek kezelését (pl. tag-eken belül), a „without comments” jelleget; • a sortörések karakter kezelése: a C14N szabványban ([5]) leírtak szerint a sortöréseknél a hex „0A” (Line Feed, ASCII 10) és hex „0D” (Carriage Return, ASCII 13) karakterek közül ki kell szőrni az utóbbiakat (hex „0D”); • a hex „0D” (Carriage Return, ASCII 13) karakterek kiszőrése: bizonyos esetekben a hex „0D” (Carriage Return, ASCII 13) karakterek kiszőrés helyett „ ” elemként jelenhetnek meg, ami nem megengedett;


26

• a kanonikalizált adat utolsó karaktere: bizonyos esetekben egy hex „00” karakter csatolódhat a kanonikalizáció során az adathoz utolsó karakterként, ami nem megengedett; • karakterek összevonása: bizonyos esetekben három hex „20” (SPACE) karakter össze lehet vonva egy hex „09” (TAB) karakterré, illetve a hex „0A0A090909” sorozat hex „0A09” sorozattá, ami nem megengedett; • XML elemek részhalmazának kezelése („subset of the nodes”): XML elemek részhalmazának kanonikalizálásakor a C14N szabványban ([5]) leírtak szerint a szülıelemekben szereplı összes névtérnek meg kell jelennie a gyökér-elemben; • a fejrész („!DOCTYPE”) kezelése: bizonyos esetekben a fejrészben megadott értékek nem lehet feldolgozva (pl. attr=”default” nem illesztıdhet be); • UTF-8 ékezetes karakterek kezelése: megfelelıen kell kezelni az UTF-8 ékezetes karaktereket.

9.21. Második körös ellenırzés A vizsgálathoz el kellett készíteni az XMLDSIG ([1], [2]) és XAdES ([3]) szabványokon alapuló séma „MELASZ Ready” szerint módosított változatát. A két séma a legtöbb helyen szigorítást tartalmaz (pl. az „Id” attribútum sok helyen „optional” helyett „required”), lényegi elemekben nem tér el az XMLDSIG ([1], [2]) és XAdES ([3]) szabványban leírtaktól. A vizsgálat során a fejlesztıktıl kapott aláírásokhoz kell hozzárendelni a módosított sémákat, és egy XML elemzıvel az ellenırzést elvégezni. A módosított sémák létrehozásakor problémát okozott, hogy az ETSI honlapjáról letölthetı séma több helyen is eltért a XAdES szabványtól ([3]). Bizonyos attribútumok (pl. „Id”, „Encoding”) és elemek (pl. „AttributeCertificateRefs”, „AttributeRevocationRefs”) hiányoztak az eredeti sémából, ezeket is javítani kellett. A két, módosított séma (XMLDSIG és XAdES „EPES”, „T”, „C”, „C verified” típusai) megtalálható a Függelékben (ld. 4. számú függelék).

9.22. Tapasztalatok, tanácsok a második körös ellenırzéshez kapcsolódóan • ETSI által kiadott XAdES séma: az ETSI honlapján elérhetı séma állomány hiányos, amelyre figyelni kell a fejlesztés során; • módosított sémák használata: alapvetıen érdemes a módosított sémákat már a fejlesztés során is használni megfelelıségi ellenırzéshez a hibák elkerülése végett; • névtér elıtagok („prefix”) megadása: a XAdES szabvány ([3]) ajánlja (a sémában is ez szerepel „beégetve”) a „ds:” elıtag használatát az XMLDSIG szabvány ([1], [2]) elemeihez és a „default” elıtagot a XAdES szabvány ([3]) elemeihez kapcsolódóan, amelyeket az együttmőködés biztosítása érdekében kötelezı jelleggel kell figyelembe venni (elképzelhetı ugyanis olyan alkalmazás, amely az ETSI által kiadott sémát használja az aláírás struktúrájának megfelelıségi vizsgálatához); • a „ds:Object” elem tartalma: a „ds:Object” tetszıleges tartalmat kaphat (pl. aláírandó adat, XAdES szabványban ([3]) szereplı elemek) és tetszıleges mennyiségben


27

fordulhat elı a „ds:Signature” elemen belül, de más esetben a saját elemek („tag”) beillesztésénél ügyelni kell arra, hogy ne sérüljön a séma.

9.23. Harmadik körös ellenırzés Az együttmőködıképesség-vizsgálat legfontosabb lépése a különbözı alkalmazások összeeresztése. Minden alkalmazással az egységes peremfeltételeknek megfelelı aláírást kell létrehoznia a mérést végzıknek. Az „aláírás létrehozása”, a „kezdeti ellenırzés” és az „utólagos ellenırzés” elkülönülnek egymástól a vizsgálat során. A peremfeltételek: • XAdES-EPES, XAdES-T és módosított XAdES-C formátum (ez utóbbi tartalmazza a „SignatureTimeStamp”, „CompleteCertificateRefs”, „SignaturePolicyIdentifier” elemet, tartalmazhatja a „CertificateValues” elemet) • „enveloping signature” aláírást kellett létrehozni; • az aláírandó adatot base64 kódolva kell beágyazni, és meg kellett adni a base64 dekódoló átalakítást a „ds:Transform” elemben (nyitó- és záróelem elhagyása, az aláírandó adat base64 dekódolása a lenyomatképzés elıtt); • a „DataObjectFormat” elemben a „MimeType” elem megadása minden aláírandó adat esetében; • idıbélyeg válaszokba beágyazott tanúsítvány kell; • az aláírói, szolgáltatói, idıbélyegzı tanúsítványok beágyazása, hivatkozásaik létrehozása („ds:KeyInfo”, „SigningCertificate”, „CompleteCertificateRefs” elem az aláírás létrehozásakor); • a visszavonási adatok közül CRL-eket (Certificate Revocation List) kell használni, az OCSP (Online Certificate Status Protocol) válaszok nem képzik a vizsgálat tárgyát; • az adott alkalmazás által készített aláírást („aláírás létrehozása”) kell a többi alkalmazással ellenıriztetni a kivárási idı („grace period”) után; • az aláírás létrehozásához használt titkos kulcs „soft token” is lehet .pfx vagy .p12 kiterjesztéső állományban (az intelligens kártyák tehát nem feltétlenül képzik részét a vizsgálatnak); • UTF-8 ékezetes karaktereket mellızni kell a vizsgált aláírásoknál (pl. tanúsítványban szereplı neveknél, aláírási szabályzatnál); • egy aláírást kell létrehozni (tehát nem volt „CounterSignature” elem és más aláírás).

9.24. Tapasztalatok, tanácsok a harmadik körös ellenırzéshez kapcsolódóan • rugalmasság: alapvetıen azt kell megvizsgálni az alkalmazásnál, hogy aláírás létrehozásánál lehetıség szerint minden – akár nem kötelezı („optional”) – elemet, attribútumot is beletesz-e az aláírásba, ellenırzésnél pedig kizárólag a kötelezı


28

• • •

• •

•

•

•

•

•

•

elemek, attribútumok alapján is képes-e lefutni (pl. jellemzıen az „URI” attribútumok, illetve általános esetben az „Id” attribútumok hiánya okozhat komoly gondot); base64 kódolás: a base64 kódolásnál (pl. tanúsítványok) az alkalmazásnak rugalmasan kell kezelnie az adatot (pl. sortörések, „-----BEGIN CERTIFICATE-----”) a nem XMLDSIG ([1], [2]) és XAdES ([3]) elemek („tag”) kezelése: a fejlesztık által létrehozott saját elemek, saját névterek vizsgálata ne képezze részét az ellenırzési folyamatnak (különben az együttmőködésben felléphetnek problémák); lenyomatok létrehozása: a XAdES szabványban ([3]) leírtakat pontosan kell követni (pl. a „SignatureTimeStamp” idıbélyeg bemenete a „ds:SignatureValue” kanonikalizált alakja, a tanúsítványok DER kódolt változatán kell lefuttatni a lenyomatképzést); aláírás létrehozása: RSASSA-PKCS1-v1_5 típusú aláírást kell létrehozni („http://www.w3.org/2000/09/xmldsig#rsa-sha1”), amely az EMSA-PKCS1-v1_5ENCODE algoritmus kiegészítése; ASN.1 adatok beágyazása: a tanúsítvány, visszavonási adat beágyazásánál az ASN.1 struktúrának való megfelelıséget érdemes ellenırizni (pl. ezzel kiszőrhetı, ha véletlenül egy hex „0A” kerül a tanúsítvány végére, amely a megjelenítésnél nem okoz problémát, de a lenyomatképzés során más érték áll elı); a tanúsítvány „issuer” és „subject” eleme (RFC 2253 szabvány szerint): futtatási és fejlesztıi környezettıl függıen másképp nyerıdnek ki ezek a névelemek, így alkalmazástól függıen más jelenhet meg a „ds:X509IssuerName” elemnél (pl. e-mail cím lehet „E”, „emailAddress” vagy a névelem OID-jével jelezve), éppen ezért az aláírások ellenırzésénél más tulajdonságra kell támaszkodni az aláírói tanúsítvány megtalálásánál, tanúsítványlánc felépítésénél (pl. tanúsítványok lenyomatai jó támpontul szolgálhatnak); szabványos struktúra: ha valamilyen elem, attribútum szerepel a struktúrában (pl. XAdES állományban, idıbélyegben, tanúsítványban), akkor az a szabványokban leírtaknak megfelelıen legyen kitöltve, vagy legyen inkább kihagyva (pl. ha nincs OCSP válasz, akkor a „” páros használata nem megengedett); aláírói tanúsítvány: az alkalmazásnak rugalmasan kell viselkednie az aláírói tanúsítvány keresésénél, hiszen a „ds:KeyInfo” elemen belüli „ds:X509Certificate” elemnek nincs „Id” attribútuma, így a „SigningCertificate” elem „URI” attribútuma sem tud arra mutatni, pedig elsıdlegesen a „ds:KeyInfo” elemben kell keresni az aláírói tanúsítványt; szolgáltatói tanúsítványok: az alkalmazásnak rugalmasan kell viselkednie a szolgáltatói tanúsítványok keresésénél, hiszen míg az „intermediate” tanúsítványokat be kell ágyazni, bizonyos esetekben a „root” tanúsítványokat külsı forrásból lehet csak beszerezni; idıbélyegzı tanúsítványok: az alkalmazásnak rugalmasan kell viselkednie az idıbélyegzı tanúsítvány keresésénél, hiszen a „SignatureTimeStamp” elemnél még a tanúsítványok beilleszthetık a „CertificateValues” elembe, de az n. archív idıbélyegnél („ArchiveTimeStamp”) már ez nem oldható meg, így mindenképpen az idıbélyeg válaszból kell kinyerni a szükséges adatokat; tanúsítványok tartalma: a minısített és fokozott biztonságú tanúsítványok közötti eltérések egyike a „keyUsage” kiterjesztés értékében van, azonban a több, gyakran egymásnak ellentmondó szabályozás interoperabilitási problémához vezethet, ezért figyelni kell a „digitalSignature”, illetve „nonRepudiation” bit megfelelı beállítására;


29

• kezdeti ellenırzés: az alkalmazásnak rugalmasan kell viselkednie a kezdeti ellenırzéshez kapott aláírás kiegészítésénél (pl. elıfordulhat, hogy már az aláírás létrehozásakor beillesztıdnek visszavonási adatok – CRL-ek –, amelyek kibocsátási idıpontja korábbi, mint az aláírás létrejötte, ezeket a kezdeti ellenırzéskor megfelelı módon kell kezelni, az aláírást a megfelelı visszavonási adatokkal kiegészíteni). • „grace period”: az archív esetek kivételével a „grace period” csak a végfelhasználói tanúsítványoknál tartandó szem elıtt, mivel az „intermediate” és „root” tanúsítványok idıbélyeg utáni CRL-jére akár éveket is kellhet várni. A XAdES-A létrehozásakor azonban minden érvényes visszavonási adatot be kell győjteni, amihez legegyszerőbb OCSp válaszokat használni vagy a KGyHSz (Közigazgatási Gyökér Hitelesítésszolgáltató) 35 naponta frissülı CRL-jét letölteni; • XML formázása: többször elıjött a tesztek során a probléma, hogy az egyik alkalmazás által készített struktúrát a másik alkalmazás ellenırizte és egészítette ki, és ilyenkor megváltozott az adatok lenyomata, sérült az aláírás. A különbözı lépéseknél figyelni kell arra, hogy a kanonikalizálás (pl. „white space” karakterek kezelése), base64 kódolás-dekódolás (pl. sortörések) során ne változzanak meg a már lenyomattal, digitális aláírással védett tartalmak; • idıbélyeg struktúra: a XAdES idıbélyegeinél (az ArchiveTimeStamp elemnél mindenképpen) megjelenhet a „referencedData” (referencedData=”true”) attribútum, amely megfelelı alkalmazására ügyelni kell.

9.25. Tapasztalatok, tanácsok az átfogóbb ellenırzéshez kapcsolódóan Az együttmőködıképesség-vizsgálat kis lefedettsége miatt érdemes felsorolni néhány olyan helyzetet, esetet – a teljesség igénye nélkül –, ami a valós életben is elıfordulhat, viszont jelen vizsgálatnál nem volt lehetıség kitérni rájuk. A „MELASZ Ready” tanúsításon átesett alkalmazásoknál komolyabb probléma (pl. kriptográfiai, kanonikalizációs) nagy valószínőséggel nem merül fel, legfeljebb a mőködési logikában lehet szükséges minimális változtatás (pl. ne csak a CRL-ek között keresgéljen visszavonási adatokat, hanem az OCSP válaszok között is). Egy esetleges nemzetközi együttmőködıképesség-vizsgálatnál a még nagyobb rugalmasság lehet szükséges, hiszen bizonyos elemek, attribútumok a „MELASZ Ready” esetében kötelezı jelleggel elvártak voltak, viszont amúgy nem feltétlenül kell szerepelniük a struktúrában (pl. a különbözı elemek „Id” attribútumai). Az alkalmazásoknak fel kell készülniük: • kezdeti ellenırzésnél esetleg „SignatureTimeStamp” beillesztésére, a korábban csatolt CRL-ek felülvizsgálatára, szükség esetén a megfelelı CRL-ek letöltésére, OCSP válaszok kezelésére, hiányzó tanúsítványok kezelésére (pl. külsı forrásból származó „root” tanúsítvány URL segítségével megadva), más protokollok kezelésére (pl. HTTPS, LDAP); • a „MELASZ Ready” keretein belül nem megengedett, de amúgy esetleg elıforduló elemekre (pl. a „ds:KeyInfo” elemen belül a „ds:X509Data” elem mellett más is szerepelhet); • „enveloped signature” és „detached signature” aláírások kezelésére;


30

• az „Id” attribútumok hiányára (pl. a tanúsítványok, tanúsítványlánc felépítésénél okozhat gondot); • többszörös aláírásra (pl. „CounterSignature” elem használata vagy párhuzamos aláírás); • archív idıbélyegek (XAdES-A) létrehozására, ellenırzésére, ahol az egyenként kanonikalizált bemeneteket össze kell főzni (pl. a nem feltétlenül szereplı „Id” attribútumokat létre tudja-e hozni az alkalmazás az archív idıbélyeg „Include” elemeihez kapcsolódóan); • UTF-8 ékezetes karakterek kezelésére (pl. lenyomatképzésnél okozhat gondot).

9.26. Tapasztalatok, tanácsok a szolgáltatói oldalhoz kapcsolódóan Az együttmőködıképesség-vizsgálat során számos olyan problémával szembesültek a mérést végzık, amelyek nem az alkalmazások, hanem a szolgáltatói oldal esetleges hibáiból fakadtak. Az alkalmazások „MELASZ Ready” tanúsításai éppen ezért csak abban az esetben állják meg a helyüket, ha olyan tanúsítványokkal, visszavonási adatokkal, idıbélyegekkel dolgoznak, amelyek szintén megfelelnek a vonatkozó szabványoknak. A szolgáltató oldalnál felfedezett hiányosságok, pontatlanságok bizonyos esetekben a jogi szabályozásra vezethetık vissza, ezért szükséges • az aláírói, idıbélyegzı tanúsítványokhoz tartozó visszavonási adatok a mindenkori kivárási idınek („grace period”) megfelelıen kerüljenek kibocsátásra (ennél gyakoribb kibocsátás is engedélyezett); • az idıbélyegzı tanúsítványában szerepelnie kell az „extKeyUsage” kritikus („critical”) kiterjesztésben („extension”) a „timeStamping” értéknek az RFC 3161 szabványnak megfelelıen; • a kibocsátott tanúsítvány feleljen meg pontosan az ASN.1 leírásnak (pl. ne legyen az adat végéhez csatolódott hex „0A”, ne legyen benne létrehozott, de kitöltetlen mezı, kiterjesztés); • a különbözı szabályozások, szabványok egymásnak ellentmondó követelményei kavarodást okoznak a „keyUsage” kiterjesztés tartalmához kapcsolódóan („digitalSignature” bit és/vagy „nonRepudiation” bit legyen beállítva); • a rejtjelezés és aláírás a jogszabályi háttér miatt elkülönítendı (pl. nemzetbiztonsági okok miatt), azonban ennek megvalósítása nem egységes (pl. van olyan szolgáltató, ahol a „keyUsage” kiterjesztésben több, egymást kizáró bit is be van állítva és a szolgáltató szabályzatában van kimondva, hogy az adott tanúsítványt rejtjelezésre nem, csak aláírásra lehet használni); • a szolgáltatók által használt algoritmusok csak az engedélyezettek körébıl kerülhet ki (a régebben kibocsátott „root” tanúsítványoknál található olyan, ahol „md5RSA” algoritmust alkalmaztak, noha az MD5 lenyomatkészítı algoritmus nem engedélyezett); • az alkalmazások mőködéséhez szükséges a visszavonási adatok beszerzése, amelyhez – az elterjedt gyakorlat szerint – a tanúsítványból lehet kinyerni a különbözı címeket, ezért az aláírói, idıbélyegzı, „intermediate” tanúsítványok esetében ezeket fel kell tüntetni (az ITU szakembereinek eredeti elképzelése szerint a megkülönböztetett név


31

elegendı lett volna az elosztott X.500-as névtárrendszerben történı kereséshez tanúsítványok, visszavonási adatok esetében, azonban napjainkban a HTTP kapcsolaton keresztül letölthetı állományok használatosak, ezekhez viszont elengedhetetlen a „cRLDistributionPoints” kiterjesztés a tanúsítványban); • a pontos dátumok és idıpontok beállítása szükséges nemcsak az idıbélyegzı szolgáltatóknál, hanem a PKI rendszer összes eleménél a szolgáltatói oldalon (CRL kibocsátó CA, OCSP-szolgáltató), hiszen minden idıadatot az idıbélyegben szereplı értékhez kell viszonyítani, ugyanakkor elıfordulhat, hogy az OCSP-szolgáltató néhány másodperces eltérése is teljesen más eredményt szolgáltat egy aláírás ellenırzésnél (pl. idıbélyeg válasz megkapása után azonnal történnek lekérdezések a tanúsítványokra vonatkozólag).


32

10. Irodalomjegyzék [1] W3C Recommendation: XML-Signature Syntax and Processing [2] IETF RFC 3275: (Extensible Markup Language) XML-Signature Syntax and Processing [3] ETSI TS 101 903 v1.2.2: XML Advanced Electronic Signatures (XAdES) [4] eEurope 2005: An information society for all [5] W3C Recommendation: Canonical XML - Version 1.0 [6] W3C Recommendation: Exclusive XML Canonicalization - Version 1.0 [7] IHM – IBM a magyar közigazgatás elektronikus kommunikációjához készített dokumentumai (IAS projekt) [8] Egységes MELASZ formátum elektronikus aláírásokra (verzió: 1.0)


33

11. Függelékek Megjegyzés: Az oktettként (hex) megjelenített állományokat a méréshez létrehozott segédalkalmazással is át lehet alakítani. 1.

számú függelék

Az elsı minta-állomány oktettként (hex) megjelenítve. bemenet (eredeti): 1.hex

kimenet (kanonikalizált): 2.hex

2.

számú függelék

A második minta-állomány oktettként (hex) megjelenítve. bemenet (eredeti): 3.hex

kimenet (kanonikalizált): 4.hex

3.

számú függelék

A harmadik minta-állomány oktettként (hex) megjelenítve. bemenet (eredeti): 5.hex

kimenet (kanonikalizált):

4.

6.hex

számú függelék

XMLDSIG_MELASZ.xsd állomány oktettként (hex) megjelenítve.

7.hex

XAdES_MELASZ_EPES.xsd állomány oktettként (hex) megjelenítve.

8.hex


34

XAdES_MELASZ_T.xsd állomány oktettként (hex) megjelenítve.

9.hex

XAdES_MELASZ_C.xsd állomány oktettként (hex) megjelenítve.

10.hex

XAdES_MELASZ_C_verified.xsd állomány oktettként (hex) megjelenítve.

11.hex


35

INTEROPERABILITÁSI BEVIZSGÁLÁSI MÓDSZERTAN

Recommend Documents