elektra hungaria 3 tudástár/eh3/v_elektra_3.0... · elektra hungaria 3.0 bemutatása huntrust...

Az ELEKTRA Hungaria v.3.0

közlekedési kártyarendszer alkalmazásának követelményei

(V. kötet)

Az ELEKTRA 3.0 bemutatása, rendszerszintű követelmények

HunTrust Kft.

2008. február 10.

V.

ELEKTRA Hungaria 3.0 Interoperábilis, érintkezésmentes intelligens közlekedési kártyát használó tömegközlekedési

jegykezelő rendszer bemutatása

HunTrust Kft.

2008.02.10.

Elektra Hungaria 3.0 bemutatása HunTrust Kft.

2


3

1 Vezetői Összefoglaló Elektronikus jegykezelő rendszerekre vonatkozó országosan interoperábilis követelmények meghatározása különös körültekintést igényel. Sok e-ticketing rendszer működik a világban, azonban rendkívül kevés olyan, ahol különböző szállítók által kiépített rendszerek lennének képesek egymással együttműködni. A lecserélhetetlen szállító monopolhelyzetbe hozásának veszélye és csapdája az, ami könnyen előállhat egy nem megfelelő követelményrendszer kiválasztása esetén.

A jelen közbeszerzési eljárás eredményeként átadásra kerülő dokumentumok lehetőséget biztosítanak arra, hogy elfogadásuk és hatályba helyezésük után további költségráfordítás és időveszteség nélkül azonnal indulhassanak az e-ticketing projektek.

Bemutatjuk, hogy ahhoz, hogy az országos interoperabilitás megvalósítható legyen, nem elegendő egy közlekedési kártyaspecifikáció, teljes rendszert lefedő specifikáció együttesre van szükség.

Több szolgáltatós környezetben az elszámolhatóság lényegi kérdés. Tranzakció szabvány hiányában, még azonos kártya layout esetén sem biztosítható, hogy a terminálokban hitelesített tranzakciók képezzék az egymás közötti elszámolás alapját, hiszen maguk a tranzakciók ez esetben minden rendszerben sajátságos formátumúak. Rendszerszinten egységes tranzakciók nélkül a szolgáltatóknak, illetve a központi támogatást nyújtónak ezek után el kell hinniük, hogy a többiektől kapott kimutatások valósak. Ez valójában a jelenlegi helyzet konzerválását is jelenti egyben.

Ami miatt a szállítók egy része nem, vagy csak részben teszi saját rendszerét teljes rendszer szinten nyílt szabványokban, specifikációkban elérhetővé, érthető, hiszen ahol megvetik a lábukat, ott már stratégiai előnyük van egy következő szolgáltató rendszerének kialakítása esetén, hiszen ekkor már csak úgy elérhető az interoperabilitás, ha ezt a rendszert is ők szállítják.

Jelen közbeszerzési eljárásban az ELEKTRA Hungaria rendszer továbbfejlesztésén, a teljes rendszert lefedő követelményrendszer kiválasztásán és beemelésén dolgozó szakértők munkájához kizárólag azon rendszerek szolgálhattak alapul, ahol a létező specifikációk nyíltan, nyílt szabványokból építkezve, szabvány szinten kidolgozva elérhetők.

A 6. fejezetben összegeztük az elektronikus jegykezelő rendszerekkel szembeni általános és honi követelményeket. Ezen követelményeknek maradéktalanul csak az Egyesült Királyságban kifejlesztett ITSO séma felel meg, ahol teljes rendszert lefedő specifikáció-együttes garantálja a rendszerszintű biztonság mellett a gyors kártyaműveleteket, a kártyaszállító függetlenséget több különböző kártyaplatform támogatásával, a terminálszállító függetlenséget, a központfejlesztő függetlenséget, valamint a szolgáltatói díjtermék stratégiák könnyű, gyors érvényre juttatását. Ez nem mondható el egyetlen általunk ismert más követelményrendszerről sem.

Elvben létezhet olyan e-ticketing séma, amely az ITSO mellett ugyancsak kielégíti a követelményeket. Ez esetben azonban a döntéshozók részére a követelményeknek történő megfelelés formális bizonyítása a szállító feladata.

Minden olyan erőfeszítés tehát, amely a minden elemében transzparens, kidolgozott, a teljes rendszert lefedő nyíltan elérhető szabvány rendszer helyett, valamely szállító, vagy csoportosulás saját koncepcióját kívánja támogatni, a valódi szállítói verseny elkerülését támogatja, valamint egyúttal a szállítói kiszolgáltatottság felé taszítja a közlekedési vállalatokat, a fővárost, vagy éppen az országot, esetleg kellő szakértelem hiányában egyidejűleg eliminálva az OKK-val kapcsolatos elképzeléseket is.

E-ticketing koncepciók kiválasztásánál figyelembe veendő szempont továbbá, hogy az adott rendszer bevezethetősége érdekében a mai magyar viszonyokat tökéletesen lefedő ELEKTRA Hungaria 2.3-ban definiált magyar díjtermékek, díjtermék csoportok egyáltalán leképezhetők e, ha igen, ki által és mennyi idő alatt. Rosszul megválasztott séma, vagy egy nem szabványos


4

egyedi szállítói rendszer beemelésének következtében akár évekig is eltarthat a rendszer adaptációja, ami a költségek jelentős emelkedésével jár és politikai feszültségkeltésre kiválóan alkalmas, ráadásul ekkor a rendszerelemek más gyártmányra már nem cserélhetők, csak a teljes rendszer. A kitűzött határidőt jelentősen, akár évekkel túllépő, sőt pereskedésbe torkollt e-ticketing projektekre számtalan nemzetközi példa van.

Az adott területen alkalmazott díjtermékek nem megfelelő leképezése még az egyik legkiválóbb tömegközlekedési rendszerintegrátor projektjének bukását is okozhatja, mint az Ausztráliában legutóbb megtörtént a Tcard projektben, ahol 95 millió ausztrál dollárt követel az állam vissza.

A hazai tömegközlekedési viszonyokat lefedő ELEKTRA Hungaria 2.3-ban leképezett díjtermékcsoportok ITSO leképezését külön dokumentumban átadjuk a javasolt ITSO elfogadása esetén a jelen közbeszerzési eljárást követően azonnal kiírható tenderek érdekében.

Az átadott dokumentumok alapján a következő döntési alternatívák racionálisak:

1, Az ITSO keretbe helyezett ELEKTRA Hungaria 3.0 elfogadása és nemzeti követelményrendszerként történő kihirdetése,

2, Az ELEKTRA Hungaria 2.3 teljes rendszert lefedő specifikációinak nyílt szabvány szintű elkészíttetése - ennek költségigényének pontos meghatározása üzleti tervben lehetséges projektterv alapján, időigénye minimálisan 6-8 hónap,

3, Jelen eljárás eredményeinek figyelmen kívül hagyása, az országos interoperábilis elektronikus jegykezelő rendszer létrehozási törekvés és egyben a tömegközlekedéshez nyújtott központi támogatások átláthatóvá tételi szándékának feladása a szállítói lobby érdekek érvényesíthetősége érdekében.

Amennyiben a döntés az 1. pontban leírtak mentén történik, azonnal több, ITSO tanúsított termékekkel rendelkező szállító képes valódi verseny alapján rendszert kiépíteni, megvalósítani, de további eldöntendő kérdés az ITSO alapú ELEKTRA Hungaria Magyar kulcsmenedzsmentjének felállítása az Egyesült Királyságban lévő kulcsmenedzsment helyett.

Erre a célra a MÁV Informatika Hitelesítés Szolgáltató a legalkalmasabb, akinél a szükséges infrastruktúra és környezeti garanciák rendelkezésre állnak. – Ennek időigénye 2-3 hónap, költségigénye 50-100 millió forint közé tehető, üzleti tervben meghatározható.

Megjegyezni kívánjuk, hogy a 2. pontban leírt, az ELEKTRA Hungaria 2.3 teljes rendszert lefedő licenszdíj-mentes és a magyar igényeket kielégítő specifikációinak elkészítése melletti döntés esetén ugyanúgy számolni kell a MÁV Informatikánál adódó költségekkel a központi kulcsmenedzsment létrehozása érdekében.

Megfontolásra javasolható a szállító semleges állami tulajdonban lévő KTI ITSO terméktanúsítási rendszerbe történő bevonása, az ITSO-val kialakítható akkreditációs folyamat eredményeként. Ez esetben a KTI is elvégezhetné a jövőben a Magyarországon tömegközlekedési infrastruktúrába telepíteni kívánt terminálok ITSO megfelelőségének bevizsgálását bármely szállító részére. Továbbá Magyarországon elegendő egy központi szervezetet definiálni és ez a szervezet (mint regisztrált National Issuer) sub-licenszeket bocsáthat ki a tömegközlekedésben résztvevő operátorok számára.


5

Tartalom 1 Vezetői Összefoglaló ............................................................................................................................. 3

2 Bevezetés ............................................................................................................................................... 7

3 A dokumentum célja, hatóköre .............................................................................................................. 9

4 A megcélzott hallgatóság ....................................................................................................................... 9

5 Az átadásra kerülő dokumentumok ........................................................................................................ 9

5.1 V. Az ELEKTRA Hungaria 3.0 bemutatása – jelen dokumentum ................................................. 9

5.2 V/1 Az ELEKTRA Hungaria 2.3 díjtermékcsoportok ITSO leképezése ..................................... 10

5.3 V/A melléklet: ITSO árképzési struktúra ..................................................................................... 10

5.4 V/B melléklet: Beszállítói nyilvántartási megállapodás............................................................... 10

5.5 V/3 melléklet: A kártyaműveleti eszközök követelményei – ITSO TS 1000-3 dokumentum fordítása .................................................................................................................................................... 10

5.6 VI/1 melléklet: ITSO üzenet adatelemek és struktúrák – ITSO TS 1000-6 dokumentum fordítása 10

5.7 VI/2 melléklet: Kommunikációs és interfész követelmények – ITSO TS 1000-9 dokumentum fordítása .................................................................................................................................................... 10

5.8 Az elektronikus adathordozón átadott dokumentumok ................................................................ 10

6 Elektronikus jegykezelő rendszerek kialakításának követelményei ..................................................... 13

6.1 Általános követelmények a Direktíva szerint ............................................................................... 13

6.2 E-ticketing rendszerekkel szembeni elvárások ............................................................................. 13

6.3 A követelmények lefedése a javasolt ITSO specifikációkkal és átadott dokumentumokkal az e-ticketing rendszerek architektúrája alapján ............................................................................................... 17

6.4 Felhasználói média ....................................................................................................................... 17

6.5 A kártyaműveleti eszközök (terminálok) ..................................................................................... 18

6.6 A Depo szint ................................................................................................................................ 18

6.7 A társasági feldolgozó központ .................................................................................................... 19

7 Az ITSO hatókörén túlnyúló kártyamenedzsment követelmények ...................................................... 19

7.1 Alapfogalmak ............................................................................................................................... 19

7.2 Kártyamenedzsment kialakítás követelményei ............................................................................ 21

I. Melléklet .............................................................................................................................................. 23

Az ITSO rendszerszemlélet és specifikációk bemutatása .............................................................................. 23

1. Az ITSO TS 1000 Specifikációk Hatóköre .......................................................................................... 23

1.1 A 0. rész hatóköre ........................................................................................................................ 24

2. Felhasználói Média (Customer Media - CM) ...................................................................................... 24

3. A CM architektúra ............................................................................................................................... 26

3.1 A CM és az ITSO Shell-ek .......................................................................................................... 26


6

3.2 Adatcsoportok .............................................................................................................................. 28

3.3 A Shell-ben levő termékek ........................................................................................................... 29

3.4 Naplók .......................................................................................................................................... 30

3.5 Megszakításmentesség ................................................................................................................. 32

4. Az ITSO Shell-ben tárolt Termék Adat Elemek .................................................................................. 32

4.1 ITSO Termék Entitások (ITSO Product Entities - IPEs). ............................................................. 33

1. IPE definíciók, megtestesítők /embodiments/, példányok és azonosítás. ..................................... 37

4.2 Átmeneti Jegy /Transient Ticket/ rekordok. ................................................................................. 37

5. A Szolgáltatási Pont Terminálja /Point of Service Terminal (POST)/ ................................................. 39

6. Az ITSO Back Office (HOPS) követelmények .................................................................................... 41

7. Biztonsági Architektúra ....................................................................................................................... 43

7.1 A biztonsági architektúra elemei .................................................................................................. 45

2. Számozás és gyökér ..................................................................................................................... 45

3. Pecsétek és kulcsok ...................................................................................................................... 46

4. Profilok ........................................................................................................................................ 47

5. Veszteségmentes tranzakció rekordok ......................................................................................... 47

6. CM birtokos személyiségi jogai ................................................................................................... 48

7. Új funkciók hozzáadása ............................................................................................................... 48

7.2 A biztonsági alrendszer (Security Sub-System - SSS) ................................................................. 48

8. Az ISAM ...................................................................................................................................... 49

8. Kommunikációk ................................................................................................................................... 51

9. ITSO adat üzenetek .............................................................................................................................. 53


7

2 Bevezetés

Az ELEKTRA Hungaria 3.0 az ELEKTRA Hungaria 2.2/2.3 elektronikus jegykezelő rendszer koncepcióra épül. Az abban definiált országos tömegközlekedési hálózat topológiai leképezésére, valamint a jelenleg Magyarország területén alkalmazott közforgalmú személyszállítási díjtermékek logikai leképezésére és a jelenleg hazánkban alkalmazott szociális kedvezmények összegzésére, mint speciális hazai tömegközlekedési tudásra építkezik, azok megváltoztatása nem célja és hatóköre.

Kifejezetten felvállalt célja és hatóköre azonban, hogy minimalizálja a tömegközlekedési szolgáltatók részére a bevételgyűjtés kockázatát, ezért olyan kártyaalkalmazás leképezésre törekszik, amelyhez a keretet egy teljes rendszerszintű specifikáció együttes biztosítja, áthidalva ezáltal az ELEKTRA Hungaria rendszer kidolgozásához rendelkezésre álló anyagi és humán erőforrások szűkössége miatt jelenleg még tettenérhető lefedetlen területeket. Hangsúlyozni kell, hogy az ELEKTRA Hungaria koncepció nélkül ma nem lenne realitása annak, hogy bármely rendszert záros időn belül adaptálni lehessen a hazai viszonyokra, tehát a javasolt megoldás erősíteni és bevezethetővé tenni igyekszik az ELEKTRA Hungariát.

Az ELEKTRA Hungaria koncepció logikailag teljes mértékben lefedi a Magyar igényeket, a fizikai kártyaalkalmazás leképezés evolúciója azonban nem tekinthető lezártnak. Az eddigi változások a megvalósítás során felmerült kérdések megoldhatósága céljából adódtak és folyamatosan adódnak, sajnálatosan az erőforrás hiányában választott merev kártyaszerkezet változtatását vonva magukkal, és nem a tömegközlekedés központi szabályozásában bekövetkezett változások – például átfogó jegyreform –, vagy új szolgáltatói díjtermékek igényének felmerülése miatt következtek és következhetnek be a jövőben.

Az ELEKTRA Hungaria 3.0 szkópja emiatt nem csak az ELEKTRA Hungaria 2.2/2.3 blokkszervezésű kártyaalkalmazás fájlrendszerű kártyákra történő leképezése a jelenlegi rendszerszintű biztonság változatlanul hagyása mellett, hanem teljes rendszerszintű garanciákat nyújtani képes e-ticketing szabvány keretbe történő beemelése, amely egyaránt képes blokkszervezésű és fájlszervezésű médiával működni.

Fenti kitűzött cél miközben lefedi a kiíró szándékát, jelen közbeszerzési eljárás keretei között kizárólag oly módon teljesíthető, hogy az elérhető, szabványos elemekből építkező elektronikus jegykezelő rendszerek közül a legteljesebb mértékben szabványosított és dokumentált, illetve legjobb referenciával rendelkező rendszerbe helyezi az ELEKTRA Hungariát az azonnali alkalmazhatóság érdekében, valamennyi szükséges díjtermék csoport leképezésével együtt. A javasolt rendszer még egy későbbi átfogó viteldíj és jegyreform esetén sem szorul átdolgozásra, bővítésre, mert minden bizonnyal ma is támogatja a majd ott megfogalmazott követelmények teljesítését.

A javasolt szabvány rendszer lehetőséget biztosít minden tömegközlekedési szolgáltató, illetve a tömegközlekedésért felelős szervezet és hatóság részére a kockázatmentes és költséghatékony e-ticketing rendszerek akár azonnali létrehozására. A javasolt


8

rendszerben valamennyi szükséges specifikáció készen van. Valamennyi rendszerkomponens több gyártótól is elérhető a költséghatékony rendszerkialakítás érdekében. Azonnal rendelkezésre áll több különböző felhasználói média specifikációja, és a jegyárbevétel biztonságát garantáló biztonsági modulok specifikációi. Maguk a biztonsági modulok beszerezhetők, kidolgozott és működik a teljeskörű kulcsmenedzsment, a kártyaműveleti eszközök adott díjtermék feldolgozási képességét garantáló terméktanúsítási rendszer, léteznek a központi feldolgozásokhoz szükséges modulok funkcionális specifikációi, létezik rendszerszintű üzenet és tranzakció szabvány, illetve specifikálásra kerültek a tranzakciók attribútumainak feldolgozási és elszámolási szabályai.

A javasolt rendszer átvételével a szolgáltatók által saját hatókörben egyedileg megvalósítható e-ticketing rendszerek garantáltan országosan interoperábilisak lesznek.

Ennek a komplexitásnak az elérése az ELEKTRA Hungaria 2.3 alkalmazása esetén minimálisan fél éves szakértői munkát tenne szükségessé a biztonsági modulok értékelése nélkül, amennyiben annak finanszírozása biztosítható.

Az az elektronikus jegykezelő rendszer koncepció, amely a kívánt garanciákat felmutatni képes, az Egyesült Királyság (UK) Integrált Közlekedési Intelligens Kártya Szervezete /Integrated Transport Smartcard Organisation (ITSO)/ által közzé tett és karbantartott ITSO TS 1000 szabvány együttes. Az ITSO alapú rendszerek és kártyák napi több millió utazási tranzakció referenciát képesek felmutatni multimodális környezetben.

Az ITSO alapú rendszer megvalósítása licenszdíj köteles, de az egy-egy szolgáltató, illetve a rendszerüket megvalósító közlekedési rendszerintegrátor által fizetendő licenszdíj eltörpül egy esetlegesen biztonsági garanciákat nyújtani nem képes rendszer megvalósítása esetén nagy valószínűséggel bekövetkező bevételkiesés, rendszerszintű fennakadás, illetve utólagos fejlesztések, javítások, a kártyaműveleti eszközök szoftvereinek folyamatos ráfejlesztési költségeihez képest. Nem beszélve arról, hogy a tömegközlekedési rendszerintegrátorok kizárólag a tömegközlekedési vállalatok saját felelősségére és kockázatára hajlandók egyedi rendszert megvalósítani, amint az a BKV több fázisban is eredménytelen korábbi tendere folyamán a pályázók ajánlataiból tapasztalható volt.

A hazai kártyaműveleti eszköz gyártók, illetve tömegközlekedési rendszerintegrátorok részére a nyílt ITSO specifikációkon kívül elérhetők a fejlesztői dokumentumok is, melyek segítségével néhány hónapon belül képesek lehetnek ITSO kompatibilis kártyaműveleti eszközök előállítására, beleértve a szükséges ITSO tanúsítást is. ITSO tanúsítvánnyal rendelkező termékeik pedig nem csak hazánkban lesznek versenyképesek és eladhatók.

Az ITSO nyilvános és transzparens licensz árazása alapján külön fejezetben adjuk meg a licensz költségeket, valamint az ITSO-hoz történő csatlakozás formanyomtatványát a hazai eszközgyártók részére.


9

3 A dokumentum célja, hatóköre

Jelen dokumentum két célt tűzött ki. Egyrészt bemutatni a tömegközlekedési jegykezelő rendszerek architektúráján keresztül a rendszerszintű szabályozási, szabványosítási igényeket, amelyek a tömegközlekedési szolgáltatók jegyárbevétel gyűjtési biztonsága és az országos interoperabilitás biztosíthatósága szempontjából a legfontosabb, másrészt bemutatni, hogy a javasolt ITSO alapú ELEKTRA Hungaria 3.0 rendszer mindezen követelményeket hogyan elégíti ki.

Tette mindezt azért, hogy a döntéshozók részére valós alternatívát legyen képes felmutatni egy bevezethető rendszer melletti döntés meghozatalára. Amennyiben ITSO alapú ELEKTRA Hungaria 3.0 döntés születik, a külön dokumentumban leképezett magyar díjtermékcsoportok, az ITSO specifikációk, valamint a rendszerhez történő csatlakozás dokumentáltsága lehetőséget ad azonnali rendszer, illetve termék beszerzésekre.

A dokumentum hatóköre tehát kiterjed a teljes elektronikus jegykezelő rendszer megvalósításának valamennyi biztonságot és interoperabilitást érintő kérdéseire, amelyeket csak a bemutatás szintjén részletez a rendszerszintű követelmények és az ezt kielégítő ITSO specifikációk bemutatásával.

4 A megcélzott hallgatóság

Jelen dokumentum elsősorban a Budapesti Közlekedésszervező Kht. pályázat értékelő bizottsága részére készült, azonban alkalmas arra, hogy a GKM illetve a Főváros minden érintett döntéshozója, illetve a tömegközlekedési szolgáltatók elektronikus jegykezelő rendszer megvalósításában érintett vezetői, szakértői és munkatársai részére rövid áttekintést adjon.

5 Az átadásra kerülő dokumentumok

Az ELEKTRA 3.0 rendszer létrehozását célzó javaslat keretében a következő dokumentumokat adjuk át:

5.1 V. Az ELEKTRA Hungaria 3.0 bemutatása – jelen dokumentum A dokumentum leírja, hogy milyen követelmények alapján született az a szakmai javaslat, hogy az ELEKTRA Hungaria 3.0 ne az ELEKTRA Hungaria 2.3 blokkszervezésű kártyaalkalmazás fájlrendszerű kártyára történő leképezését tartalmazza csupán, hanem egy lényegesen szélesebb, a teljes rendszert lefedő követelményrendszer szkóppal közelítse a feladat végrehajtását, illetve a honosításra javasolt specifikáció együttes az ITSO és nem más. Az ITSO specifikációk hatókörén túlmenően a GKM Országos Közlekedési Kártyaközpont létrehozására irányuló terveinek elősegítése céljából az ITSO hatókör alá nem tartozó kártyamenedzsment rendszer kialakításának legfontosabb követelményeit is leírjuk.

Az ITSO rendszer bemutatása az I. mellékletben található az ITSO TS 1000-0 dokumentum


10

alapján.

5.2 V/1 Az ELEKTRA Hungaria 2.3 díjtermékcsoportok ITSO leképezése Ez a dokumentum a Magyar közforgalmú személyszállításban alkalmazott díjtermék csoportok ITSO formátumra történő leképezését tartalmazza. Enélkül a dokumentum nélkül az ITSO specifikációk rendszerszintű alkalmazása a mai hazai viszonyok között átfogó viteldíj reform nélkül belátható időn belül nem volna reális. A leképezett díjtermék csoportok alapján bármely tömegközlekedési szolgáltató akár azonnal megkezdheti saját rendszerének kiépítését hosszas implementációs fázis nélkül, miközben kiépülő rendszere az ITSO specifikációknak köszönhetően bizonyosan interoperábilis lesz a többi szolgáltató rendszerével.

5.3 V/A melléklet: ITSO árképzési struktúra Ez a melléklet tartalmazza az ITSO-hoz történő csatlakozás költségeit illetve a licensz díjakat leíró „Pricing” dokumentum fordítását.

5.4 V/B melléklet: Beszállítói nyilvántartási megállapodás Ez a melléklet tartalmazza a Magyar fejlesztők részére a fejlesztői dokumentumok elérése érdekében fontos „Supplier Registration Aggrement” fordítását.

5.5 V/3 melléklet: A kártyaműveleti eszközök követelményei – ITSO TS 1000-3 dokumentum fordítása

Ez a dokumentum megkönnyítve az ITSO tudás elsajátítását magyar nyelven teszi elérhetővé a terminálfejlesztők, illetve terminál hálózatot üzemeltetők részére az ITSO POST-ok specifikációját.

5.6 VI/1 melléklet: ITSO üzenet adatelemek és struktúrák – ITSO TS 1000-6 dokumentum fordítása

Ez a dokumentum a rendszerkomponens fejlesztésében érdekeltek, illetve a tömegközlekedési szolgáltatók rendszerintegrátorainak feladatát igyekszik megkönnyíteni az ITSO sémában értelmezett üzenet adatelemek és struktúrák magyar nyelvű tálalásával.

5.7 VI/2 melléklet: Kommunikációs és interfész követelmények – ITSO TS 1000-9 dokumentum fordítása

Ez a dokumentum tartalmazza az ITSO sémán belüli tranzakciószabványt. Fontossága miatt magyar nyelven is átadjuk, könnyítve az értelmezést.

5.8 Az elektronikus adathordozón átadott dokumentumok Elektronikus adathordozón adjuk át az előző pontokban felsorolt dokumentumokon kívül a nyíltan, bárki által letölthető eredeti ITSO specifikációkat angol nyelven. A specifikációk rövid ismertetése:

A 0. rész hatóköre

Az ITSO TS 1000-0 az ITSO TS 1000 2-10 szerzői által biztosított szinopszisainak szerkesztői összesítése. A Specifikáció vonatkozó normatív jellegű részeinek csak egy tisztán leíró jellegű áttekintését tartalmazza.

Az 1.rész hatóköre

Tartalmazza az ITSO TS 1000 specifikációk hivatkozásait, a terminológia összefoglalóját, az adat típus


11

definíciók teljes készletét, valamint a referenciaként használt dokumentumok felsorolását.


A felhasználói media (CM) adatok és felhasználói média architektúra

Meghatározza az ITSO shell-t és az adattárolást, valamint részletesen definiálja:

— az ITSO Shell architektúrát

— a felhasználói média architektúrát;

— az ITSO Shell környezet adatcsoportot;

— a könyvtár adatcsoportot;

— az IPE adatcsoportot;

— az érték rekord adatcsoportot;

— a napló könyvtár belépési pontjait.


Ez a rész definiálja a kártyaműveleti eszközökre – terminálokra (POST) vonatkozó követelményeket acélból, hogy a terminálok képesek legyenek az interoperábilis felhasználói média kezelésére ITSO környezetben.

Az ITSO TS 1000-3 csak azokat a követelményeket definiálja, amelyek az interoperábilis felhasználói média (CM) használatra és az ITSO környezet egyéb részeivel történő interfész kapcsolatokra vonatkoznak.

A POST követelmények csoportosítva a következők:

— POST- CM interfész;

— POST- HOPS interfész;

— POST - ISAM interfész;

— Humán interfész;

— A POST funkcionális követelményei.


Az ITSO TS 1000-4-ben definiált koncepcionális ITSO Back Office entitás a Host Üzemeltető, illetve Feldolgozó Rendszer (Host Operator or Processing System - HOPS).

Az ITSO TS 1000-4 a Back Office-nak csak azokat a szempontjait fedi le, amelyek a HOPS-al kapcsolatos interoperabilitásra hatást gyakorolnak, lehetővé téve azt, hogy a HOPS a lehető legnagyobb rugalmasságot valósítsa meg, amennyiben az nem érinti az interoperabilitást.

Az ITSO az alábbi HOPS funkcionális követelményeket definiálta:

— Veszteségmentes kommunikációkezelés (az Üzenet Processzor);

— Üzenet adattárolás;

— Az ITSO Shell és IPE számla kezelése:

• Beleértve a Forrólista (Hotlist) és az Akciólista Feldolgozást;

— Eszközkezelés;

— Szolgáltatások:

• Audit nyom + Napló (Journal),

• Szabályoknak történő megfelelőség,

• Biztonság monitorozása,

• Backup,


12

• Archívum.

Az 5. rész hatóköre

Az ITSO TS 1000-5 írja le és definiálja az ITSO díjtermék entitásokat (ITSO Product Entity – IPE) különös tekintettel:

• az IPE-k adattartalmára és

• a tranziens jegy napló adattartalmára


Az ITSO TS 1000-6 definiálja az ITSO üzenet adatelemeket és üzenetstruktúrát, az ITSO Biztonsági Menedzsment Rendszer (ITSO Security Management System - ISMS) és az ITSO SAM modulok (ISAM) közötti üzenetek kivételével.


Az ITSO TS 1000-7 definiálja az ITSO POS terminálok és a feldolgozó központ (Head Office Processors – HOPS) között értelmezett biztonsági alrendszer követelményeit.


Az ITSO TS 1000-8 az ISAM modulok általános specifikációja. Tartalmazza az ISAM funkciókat és parancs interfészt, az ISAM-ok átvételi és képességi kritérium táblázatát és fáljait, valamint az addicionálisan használható parancsokat.

E dokumentum kizárólag regisztrált tagok részére, titoktartási nyilatkozat ellenében elérhető, ezért az elektronikus adathordozón nem szerepel.


Az ITSO TS 1000-9 a kommunikációs és interfész követelményeket határozza meg. Konkrétan az alábbiakat definiálja:

— Általános kommunikációs alapelvek és követelmények 2. pont;

— Veszteségmentes adatátvitel 3. pont;

— Alkalmazás szintű üzenet struktúra 4. pont;

— Alkalmazás üzenet osztályok 5. pont;

— Átviteli módszerek és adatformátumok 6. pont;

— A POST és a HOPS közti kommunikáció 7. pont;

— HOPS és HOPS közti kommunikáció 8. pont;

— Az ISMS és a HOPS közti kommunikáció 9. pont;

— XML támogatási követelmények 10. pont;

— VPN támogatási követelmények 11. pont;

— Kommunikációs biztonság 12. pont.


Az ITSO TS 1000 tartalmazza a felhasználói média definíciókat (Customer Media Definitions-CMD). A CMD leírja a logikai adatelemek elhelyezkedését egy adott fizikai platformon. Ez a dokumentum a következő platformokra ad CMD-ket:

— Mifare® standard 1K CMD1;

— Generic micro-processor CMD2;

— Mifare® standard 4K CMD3;

— Mifare® ultra light CMD4;

— Innovision Jewel-0301/70 CMD5;


13

— London Oyster CMD6;

— Mifare® DESFire CMD7;

— Calypso CMD8.

6 Elektronikus jegykezelő rendszerek kialakításának követelményei

6.1 Általános követelmények a Direktíva szerint

A Direktíva szerint: „Az e-jegyrendszereknek (beleértve a rendszerek koncepcióit és a megoldásokat) robosztusnak kell lenniük, de egyben a bővíthetőségüket is biztosítaniuk kell, hogy azokat illeszteni lehessen az új felhasználói igényekhez, illetve követelményekhez. Az általános rendszerkövetelmények az alábbiak:

a) Adaptálhatóság (az a képesség, hogy ki tudja elégíteni a felhasználói igények változó jellegét) b) Folytonosság (az a képesség, hogy egy szolgáltatást időben és térben folytonosan fenn lehessen tartani) c) Karbantarthatóság (az a képesség, hogy a karbantartást, javítást, módosítást, illetve bővítést minimális

zavar mellett lehessen elvégezni) d) Robosztusság (az a képesség, hogy kielégítően tudjon működni minden várható feltétel esetén) e) Bővíthetőség (az a képesség, hogy bővíthető legyen berendezésekkel és funkciókkal) f) Skálázhatóság (az a képesség, hogy egy nagyobb számú ügyfélbázist be tudjon fogadni) g) Biztonság (a rendszernek azon képessége, hogy meg tudja magát védeni az engedély nélküli

hozzáféréstől, illetve a kritikus jelentőséggel bíró hibáktól)

A rendszer biztonsága az alábbi területeken történő speciális intézkedéseken keresztül biztosítható:

a) a rendszer és az adatok megvédése a külső támadástól, illetve beavatkozástól b) a rendszereken belül és a rendszer komponenseken belül biztonságos feldolgozó eljárások lehetővé

tétele c) annak lehetővé tétele, hogy a karbantartási, javítási, módosítási, illetve bővítési munkálatok a minimális

működés zavarral/költséggel járjanak.” Ezen megfogalmazott alapkövetelmények a következő konkrét követelményeket jelentik, amelyek kielégíthetősége képezte az általunk javasolt szabvány rendszerre történő építkezést.

6.2 E-ticketing rendszerekkel szembeni elvárások

Az alábbiakban a legfontosabb követelményeket foglaljuk össze csoportosítva.

Nemzeti követelmények 1, Az alkalmazott hazai, az ELEKTRA Hungaria 2.3-ban definiált díjtermékek azonnali, viteldíj reform nélküli leképezhetősége,

Miért: Alapvető elvárás, hogy egy nemzeti követelményrendszert kielégítő e-ticketing rendszer képes legyen elhúzódó díjtermék leképezési próbálkozások nélkül a hazai díjtermékeket azonnal implementálni. Ellenkező esetben a projektek határozatlan ideig, akár


14

évekig elhúzódhatnak, vagy az országnak kell a teljes támogatási és kedvezményrendszerét egy átfogó viteldíjreform keretében egy szállító kénye-kedvéhez igazítani. Döntéshozók részére figyelmeztetők kell, hogy legyenek a nemzetközi rossz tapasztalatok, ahol megfelelő követelmények hiányában engedtek egy-egy szállítói nyomásnak és ez a döntés minden esetben a projektek elhúzódásához, jelentős költségnövekedéshez, vagy éppen a projekt teljes bukásához vezettek.

A javasolt rendszer hogyan felel meg: Az ITSO-ban az ELEKTRA Hungaria díjtermékcsoportok leképezése megtörtént, amelyet átadunk. Jelen követelményt az ELEKTRA Hungaria 2.3 is kielégíti.

2, A hazai szabályozási környezethez illeszkedés képessége az adott kedvezményrendszer szerint,

Miért: Az adott kedvezményrendszer átvételi képességének hiánya ugyanúgy elhúzódó implementációhoz, vagy átfogó viteldíj és támogatási rendszer megváltoztatáshoz vezet, mint az előző követelmény nem teljesítése.

A javasolt rendszer hogyan felel meg:

Az ITSO-ban az ELEKTRA Hungariában definiált valamennyi kedvezmény átvétele az ITSO leképezés során megtörtént, az átadásra kerülő dokumentum ezt is tartalmazza. Jelen követelményt az ELEKTRA Hungaria 2.3 is kielégíti.

3, A hazai információs társadalmi követelményekhez történő alkalmazkodás képessége – kártyaplatform függetlenség, kártya és kártyaalkalmazás kibocsátó elválaszthatóságának követelménye

Ezen követelmény az ISO 14443-4-es szintű, fájlrendszerű kártyák támogatási képességét követeli meg elsősorban.

Miért:

Az elektronikus jegykezelő rendszernek a csak közlekedési kártyaként kibocsátott kártyákon kívül támogatni kell tudniuk a harmadik fél (például kormányzat) által kibocsátott kártyákat, mint például egy multifunkciós állampolgári kártya (Citizen card), vagy eSZIG, egy multifunkciós városi kártya, például Budapest kártya, vagy éppen egy multifunkciós egészségügyi kártya. Megadva ezáltal a lehetőséget a központi támogatások átláthatóvá tételéhez az állam által kibocsátott kártyák esetén, vagy lehetővé téve, hogy egy adott Önkormányzat egyéb társadalmi, üzleti célokat is megvalósító duálinterfészes kártyán tegye lehetővé a tömegközlekedési kártyaalkalmazást. Ennek a követelménynek történő nem megfelelés esetén a kizárólag egy kártyaplatformot támogatni képes e-ticketing rendszerszállítók beszűkítik más kártyakibocsátók kártyaplatform szállító kiválasztási függetlenségét, ha egyáltalán képesek nem általuk kibocsátott kártyára közlekedési kártyaalkalmazást telepíteni, vagy az általuk támogatott egyetlen platform (pl. MIFARE DesFire) egyáltalán duálinterfészes fájlrendszerű kártyán profilként létezik e több szállító esetében. Ellenkező esetben a harmadik fél kártyakibocsátóknak az e-ticketing szállító rendszerének hiányosságai miatt le kell mondani terveikről.

Fel kell hívni a figyelmet, hogy ennek a követelménynek a figyelmen kívül hagyása magát az OKK létrehozását is ellehetetlenítheti, ami túl azon, hogy utólag eliminálja jelen közbeszerzési eljárás egyik fontos célkitűzését, kihatással lehet más kiemelt operatív programra is, ahol számoltak a közlekedési kártyaalkalmazásokkal.


Az ITSO modell szinten, a CMD réteg definiálásával teszi lehetővé bármely kontaktus nélküli média alkalmazását a közlekedésben. A CMD réteg a közlekedés számára jelenleg alkalmas kártyák, illetve médiák esetében kidolgozásra került, de legalább ilyen fontos, hogy a CMD réteg segítségével a jövőbeni médiák támogatását is elvileg oldja meg. Egyenszilárd módon


15

kezeli a blokk-, illetve fájlszervezésű médiákat, úgy, hogy közben egyéb alkalmazások telepítését is lehetővé teszi pl. elektronikus pénztárca, hűség pontok, parkolás, stb. céljára, illetve harmadik fél kibocsátású kártyákra is telepíthető.

Biztonsági követelmények 4, A közlekedési funkcionalitásra is értékelt SAM modulok megléte

Miért:

Amennyiben a terminálokban nem valamennyi érzékeny művelet a SAM modulokban kerül végrehajtásra, magának a terminálnak kell biztonságos, a „secure token”-nel azonos környezeti követelményeknek megfelelni - ami jelentősen drágíthatja a terminálokat -, mert a tranzakciók feldolgozása közben pl. az adatreprezentánsok előállítása és hitelesítésre küldése ugyanolyan érzékeny művelet, mint a hitelesítésük, valamint ez esetben megnő a terminál és SAM modul közötti kommunikációs igény, amely növeli a tranzakciók végrehajtási idejét, függetlenül az alkalmazott kriptográfiától.


Az ITSO sémán belül az ISAM modulok saját CC EAL 4+ védelmi profillal szembeni tanúsítással rendelkeznek. Ezek az ISAM modulok részt vesznek a tranzakciók összeállításában, 4 MB RAM memóriával rendelkeznek, ami rendkívül gyors és biztonságos tranzakciókezelést tesz lehetővé.

5, A terminálok és a központi feldolgozás között értelmezett biztonsági rendszer specifikáció követelménye

Miért:

A rendszerszintű egyenszilárdság biztosítása érdekében a teljes rendszerben értelmezett biztonsági rendszert, beleértve a biztonsági modulokat és a tranzakciók feldolgozásában résztvevő komponenseket is specifikálni kell. Ellenkező esetben ellenőrizhetetlenül kell elfogadni, hogy egy adott rendszerintegrátor valamilyen módon gondoskodott a biztonságról saját rendszerében.


Az ITSO TS 1000-7 definiálja az ITSO POS terminálok és a feldolgozó központ (Head Office Processors – HOPS) között értelmezett biztonsági alrendszer követelményeit, valamint az ITSO TS 1000-8 az ISAM modulok általános specifikációja.

Interoperabilitási követelmények 6, A teljes e-ticketing rendszert lefedő specifikációk megléte

Miért:

A szállítói kiszolgáltatottság akkor és csak akkor szüntethető meg, ha minden, a tranzakciók előállításában és feldolgozásában érintett rendszerkomponens funkcionalitása, a rendszeren belüli üzenetek és maguk a tranzakciók specifikálásra kerülnek, valamint ezen specifikációk alapján képes bármely döntéshozó eldönteni, hogy az ajánlott rendszer valóban megfelel a követelményeknek, illetve ezen specifikációk alapján lesz képes bármely gyártó az adott rendszerkomponens előállítására.


Az ITSO TS 1000 2-10 specifikációk a teljes rendszert lefedik.

Tömegáteresztő-képesség - performancia követelmények


16

7, A terminál előtt tartózkodási időtartam követelményei a média kezelésekor Miért:

A nemzetközi elvárás a másodpercenkénti 3 utas átbocsátó képesség. Ez 300 ms-on belüli felhasználói média - kártyaművelet, valamint a két média kiszolgálása közötti maximum 100 ms-os terminál feldolgozási időt feltételez. Ez a követelmény akkor teljesíthető, ha az alkalmazott követelményrendszer –séma- definiálja az általa támogatott felhasználói médiákat, majd minden támogatott média esetében ún. benchmark-okat tesz közzé.


Az ITSO TS 1000-10 definiálja valamennyi támogatott platform esetén a benchmark tranzakciókat és végrehajtási időket.

8, A terminál előtt tartózkodás időtartam követelményei díjtermék feltöltésekor Miért:

Díjtermékek feltöltésekor is lényeges a lehető legrövidebb médiakezelési idő elérése, még akkor is, ha az interaktív automatákon az utas több másodpercet is eltölthet a megfelelő menüpont kiválasztásával, mert kártyaművelet közben a kártyát folyamatosan energiaközelben – az érintőfelületen – kell tartani, ellenkező esetben rendkívül sok sikertelen tranzakció keletkezik. Az elfogadott időtartam maximum 1 másodperc, ellenkező esetben az alacsony tömegmegelégedettségi index a teljes rendszer ellehetetlenítéséhez vezethet.


Az ITSO TS 1000-10 definiálja valamennyi támogatott platform esetén a benchmark tranzakciókat, amelyek a díjtermék feltöltést is lefedik, valamint a végrehajtási időket.

Felhasználói média függetlenség követelmények 9, Média – kártyaszállítói függetlenség követelménye

Miért:

Az egyetlen platformot támogató (Pl. Philips MIFARE) rendszerek az interoperabilitási követelményeknél leírt fájlrendszerű kártyák szállítófüggetlenségi követelményének nem képesek megfelelni, az egyetlen szállítóhoz köthető (Pl. SONY FeliCa) rendszerek pedig szállítói kiszolgáltatottsághoz vezetnek, beszerzésük nem versenyeztethető.


Az ITSO modell szinten, a CMD réteg definiálásával teszi lehetővé bármely kontaktus nélküli média alkalmazását a közlekedésben. A CMD réteg a közlekedés számára jelenleg alkalmas kártyák, illetve médiák esetében kidolgozásra került, de legalább ilyen fontos, hogy a CMD réteg segítségével a jövőbeni médiák támogatását is elvileg oldja meg. Egyenszilárd módon kezeli a blokk-, illetve fájlszervezésű médiákat, úgy, hogy közben egyéb alkalmazások telepítését is lehetővé teszi, illetve harmadik fél kibocsátású kártyákra is telepíthető.

Az elfogadott Európai szabványoknak történő megfelelés követelménye 10, Az elfogadott Európai ISO 14443 protokoll támogatási képessége a terminálokban

Miért:

Az Európai Unió az európai termékeket és technológiákat támogatja. EU támogatás nem érhető el olyan projektek esetén, amelyek pl. Ázsiában kifejlesztett és alkalmazott protokollon álló termékeket feltételeznek és rendszer szinten kizárnak más európai gyártót, vagy szállítót.


17

Ilyen lehet például a kizárólag az egyébként kiváló és CC EAL 4 tanúsítvánnyal rendelkező SONY FeliCa kártyát és protokollt megkövetelő rendszer kialakítása.


Az ITSO TS 1000-3 specifikálja a terminálok kötelező protokoll támogatási képességét – ISO 14443 A és B. Az ITSO TS 1000-10 pedig specifikálja a támogatott EU követelményeknek megfelelő kártyaplatformokat.

6.3 A követelmények lefedése a javasolt ITSO specifikációkkal és átadott dokumentumokkal az e-ticketing rendszerek architektúrája alapján

Azért, hogy a követelményeket egy kiépített rendszerhez lehessen kötni, az alábbiakban architektúrális megközelítésben is bemutatjuk azokat.

Nemzetközi szinten elfogadott a négyszintű e-ticketing rendszerarchitektúra megközelítés, ahol a 0-s szint a felhasználói média, mert az nem az architektúra része:

• Az 1-es szint a járműfedélzeten, megállókban, peronokon elhelyezett kártyaműveleti eszközök szintje, • A 2-es szint a garázsok, remizek adatgyűjtő és továbbító berendezéseinek szintje, • A 3-as szint a társasági eszközmenedzsment és tranzakció feldolgozás szintje, • A 4-es szint a tranzakciók elszámolását is tartalmazó társasági, vagy külső feldolgozó központ szintje

A következőkben ezen architektúrális modell alapján soroljuk fel a szabályozással lefedendő kapcsolódó felületeket és feladatokat, valamint ehhez hozzárendeljük az ITSO TS 1000 specifikációkat, kulcsmenedzsmentet, illetve tanúsítási rendszert.

6.4 Felhasználói média

A felhasználói médián kell a helyi tömegközlekedési viszonyokat lefedő valamennyi díjterméket, a közlekedési díjtárcát, az igénybe vehető külső díjtárca elérhetőségét, a kedvezmények rendszerét, a hálózat topológiai hivatkozásait, a tömegközlekedési szolgáltatókat, a terminálokat, az éppen aktuális az utazási viszonylatot térben és időben egy adott médián leképezni. Mindezt úgy, hogy a médiával minden a rendszeren belül értelmezett kártyaműveleti eszköz – terminál képes legyen kapcsolatfelvételre, valamint az ábrázolt adatattribútumok hitelesítésre kerüljenek. Az utazáshoz szükséges és a hitelesítő attribútumokat az interoperabilitás biztosíthatósága érdekében a bevont szolgáltatók teljes körében azonosan értelmezni kell tudni, továbbá választási szabadságot kell biztosítani a tömegközlekedési szolgáltatók részére a céljaiknak leginkább megfelelő média kiválasztása terén.

• Fenti követelményeket az ITSO TS 1000 – 2 specifikáció, • Az ITSO Product Entity (IPE) definíciókat tartalmazó ITSO TS 1000-5 specifikáció, • A hitelesítő attribútumokat előállító biztonsági modulokat az ITSO TS 1000 – 8, • A média választékot az ITSO TS 1000-10 specifikáció elégíti ki. • A mai magyar viszonyokat lefedő ELEKTRA Hungaria 2.3 díjterméktípus-csoportok és

díjtermékektípusok ITSO-ra történő konkrét leképezését pedig a HunTrust


18

által készített „ELEKTRA Hungaria díjtermékcsoportok ITSO leképezése” dokumentum tartalmazza.

6.5 A kártyaműveleti eszközök (terminálok)

A felhasználói médiával történő kommunikáció, az ábrázolt attribútumok értelmezése, a médián megváltoztatandó adatok visszaírása, valamint a hiteles tranzakciók előállítása a felettes szinteken keresztül a 4-es szint részére a kártyaműveleti eszközök feladata.

Miután a kártyán lévő attribútumok értelmezése egységesen kell, hogy történjen bárki is fejlesztette a terminálokat, valamint nem minden terminál jogosult azonos funkcionalitásra (pl. elektronikus pénztárca feltöltése egészen más jogosultságot igényel, mint lefogyasztása), ezért meg kell tudni határozni az egyes kártyaműveleti eszköz csoportok kötelező funkcionalitását. A kötelező funkcionalitás meghatározása után minőségbiztosítási – értékelési, tanúsítási – rendszert kell létrehozni és működtetni a különböző gyártók termékeinek bevizsgálására és tanúsítvánnyal történő ellátására, mert ez garantálja, hogy a termék arra és csak arra a funkcionalitásra képes, amire tanúsítványát kapta, egyébként megfelelő működése nem garantálható.

A kártyaműveleti eszközök tartalmazzák azokat a SIM kártya formátumú biztonsági modulokat (SAM), amelyek rendszerszinten adott funkcionalitásra képesek, kialakításuknak meg kell felelni egy megfogalmazott követelményrendszernek (védelmi profil), minőségbiztosításuk érdekében bevizsgálással és tanúsítvánnyal kell, hogy rendelkeznek, a kártyaműveleti eszközökkel történő együttműködésük miatt rendelkezniük kell külső interfész specifikációval, valamint a működésükhöz szükséges kulcsokat az interoperabilitás biztosíthatósága érdekében a megfelelő biztonsági követelmények szerint kialakított központi kulcsmenedzsmentből kell, hogy kapják.

• A kártyaműveleti eszközök követelményeit az ITSO TS 1000-3 specifikáció, • A terminálokat is lefedő biztonsági alrendszert az ITSO TS 1000-7 specifikáció, • A terminálok által készített tranzakciókat az ITSO TS 1000-9 specifikáció tartalmazza. • A terminálok adott funkcionalitásra megfelelésének bizonyítására az ITSO

terméktanúsítási rendszert működtet. • Az ITSO SAM modulokkal (ISAM) szembeni követelményekre védelmi profilt hoztak létre,

valamint az ISAM-ok Common Criteria EAL 4+ szinten tanúsítottak. • Az ISAM modulok kulcsokkal történő ellátására az Egyesült Királyságban központi kulcs

menedzsment (KMC) üzemel. (Lehetőség van Magyarországi kulcsmenedzsment felállítására is célszerűen egy szállító független intézményben, mint pl. a KTI, vagy egy tömegközlekedéshez közeli Hitelesítés Szolgáltatónál, mint pl. a MÁV Informatika.)

• Az ISAM modulok látják el a tranzakciók hitelesítését.

6.6 A Depo szint

Ez a közbülső, általában adatgyűjtést végző szint felel a járművekről érkező tranzakció kötegek fogadásáról és továbbításukról a központ irányába, illetve ez a szint látja el a járművek üzemkezdetekor, indításakor a terminálok megfelelő adatokkal történő ellátását, amelyet az eszközmenedzsment biztosít részükre. AZ ITSO a lehető legnagyobb gyártófüggetlenség érdekében azokat az üzeneteket definiálta, amelyek a Terminál – Feldolgozó központ, illetve entitás között értelmezettek. A Depo szintet ez akkor érinti, ha


19

feldolgozás is történik, pl. különböző kimutatások készítése céljából. • A rendszerben értelmezett üzeneteket az ITSO TS 1000-6 specifikáció tartalmazza. • Az ITSO Security Management System és a terminálok ISAM moduljai közötti üzeneteket

az ITSO TS 1000-8 specifikáció tartalmazza.

6.7 A társasági feldolgozó központ A tranzakciókban szereplő adatok, attribútumok feldolgozási szabályait rendszer szinten szabványosítani kell, mert eltérő esetben a különböző fejlesztők, szállítók rendszere által végzett feldolgozások eltérő eredményre juthatnak. Ez nem csak a pénzügyi elszámolás terén jelent problémát, hanem előfordulhatnak másképpen értelmezett jelentéskészítéshez szükséges attribútumok, illetve olyanok, amelyek nem értelmezhetők egyaránt, ami ezen tranzakciók sorbanállását fogja eredményezni, amely végső soron rendszerszintű leálláshoz is vezethet. Ez a kérdéskör elsődlegesen olyan nagy szolgáltatók (pl. BKV), illetve országos központ (OKK) rendszereit érinti, ahol a napi több millió tranzakció feldolgozása közben elvi esély sincs, akár a tranzakciók néhány százalékának kézi feldolgozására, míg ez egy kisebb társaság esetén még megoldható lenne.

• A központi feldolgozó rendszerekre vonatkozó követelményeket az ITSO TS 1000-4 specifikáció tartalmazza.

7 Az ITSO hatókörén túlnyúló kártyamenedzsment követelmények

A csak közlekedési kártyák, rajtuk a közlekedési kártyaalkalmazások – általában shell alkalmazás – kibocsátására és menedzselésére minden tömegközlekedési rendszerintegrátor ad valamilyen megoldást. Az alábbiakban az olyan multifunkciós kártyák legfontosabb kibocsátási és menedzselhetőségi követelményeire térünk ki, amelyek képesek közlekedési alkalmazás hordozására, de kibocsátásuk nem a közlekedési társaság által, hanem az Országos Közlekedési Kártyaközpont, a Regionális Fejlesztési Holding, vagy az MFB keretében létrehozandó Hungarocard ZRt. keretében történik.

Az a kártyakibocsátó és az alkalmazás-kibocsátó közötti megállapodás kérdése, hogy a különböző kártyaalkalmazások menedzselése a kártyaalkalmazás kibocsátónál, vagy a kártyakibocsátónál történik.

7.1 Alapfogalmak

Kártyamenedzsment: a kibocsátandó kártyák életciklusának menedzselését végzi a központi kártyamenedzsmentből. A kártyák életciklus menedzselése a kártyák megrendelésekor kezdődik és a kártyák visszavonásáig, megsemmisítéséig, vagy az elveszett, ellopott kártyák letiltásáig tart.

Kártyaalkalmazás menedzsment: a kártyák élettartamán belül a kártyaalkalmazások életciklusa a kártyák életciklusától független. Egy kártyaalkalmazás deaktiválható, letiltható különböző okok miatt, például nem fizetés következtében, vagy támadási kísérlet észlelése következtében, míg a kártya érvényes marad. A kártyákat a kártyamenedzsment, míg a kártyaalkalmazásokat a kártyaalkalmazás menedzsment képes menedzselni.


20

Tárolt érték, vagy más néven adattartalom menedzsment: a kártyák valamely alkalmazásában tárolt adatok, jogosultságok erkölcsi, vagy anyagi értéket képviselnek, a kártyák elvesztése, ellopása esetére ezért lehetőség van a kártyaalkalmazásban tárolt adatok összeszinkronizálására a kártyamenedzsment adott felhasználóhoz tartozó rekordjával. Ilyen tipikus alkalmazás például az elektronikus pénztárcában lévő elektronikus pénz nyilvántartása a kártyabirtokos kérelme alapján, azért, hogy a kártya elvesztése, ellopása esetén a pénztárcában tárolt érték visszaállítható legyen a pótolt kártyán. Az alkalmazásban tárolt érték, a kártyaalkalmazás és a kártya menedzselése egymástól független szolgáltatások, melyeket a kártyakibocsátó és menedzsment központ képes ellátni.

Kártya aktiválás/deaktiválás: a kártya első felhasználása előtt, vagy azzal egyidejűleg a kártyát aktiválni kell. A magát más úton azonosító felhasználó (kártyabirtokos) bejelentésére a Kártyakibocsátó és Menedzsment Központ Help Desk szolgáltatása az elveszett, ellopott kártyát deaktiválja. A deaktivált kártya később, a szabályozásban adott időkereten belül visszaállítható, újraaktiválható (például a kártyabirtokos megtalálja az elveszettnek, vagy ellopottnak hitt kártyát).

Kártyaalkalmazás aktiválása/deaktiválása: egy kártyaalkalmazást felhasználása előtt, vagy azzal egyidejűleg aktiválni kell. Valamely szolgáltatásban történő részvétel nem fizetése, vagy egyéb okból – például jogosultság megvonása – az adott kártyaalkalmazást kezelő terminálok jogosultak az általuk kezelt kártyaalkalmazás deaktiválására. A szolgáltatás ismételt megfizetése, vagy a szükséges jogosultság visszanyerése esetén a kártyaalkalmazás újraaktiválható.

A tipikus kártyamenedzsment egyszerűsített architektúráját és kapcsolatait a következő ábra szemlélteti:


21

Az alábbi követelmények betartására létezik Európa Tanácsi ajánlás (05 számon 2005. november 25), ami ugyan nem kötelező, de betartása minden „Trust Center” üzemeltetőnek saját jól felfogott érdeke:

• a kérelmező személynek legalább egyszer személyesen meg kell jelennie a hatóság előtt;

• a kérelmező adatait ellenőrizni szükséges egy rendszeresen karbantartott hiteles adatbázishoz képest, mely lehet a népesség nyilvántartás, útlevél nyilvántartás, személyazonosító igazolvány nyilvántartás vagy akár a vezetői engedélyek nyilvántartása is;

• A kibocsátás teljes menetének szigorú monitorozása szükséges az alvállalkozók munkájára is kiterjedősen, és rendszeres auditokat kell végrehajtani;

• A kibocsátás folyamatát úgy kell megszervezni, hogy ne fordulhasson elő, hogy a személyzet egyetlen tagja képes legyen önállóan (megfelelő kontroll nélkül) lebonyolítani a megszemélyesítés bármely lépését;

• Biztosítani kell mind az adatok, mind az elkészült dokumentumok megfelelő biztonságú transzportját, kezelését.

7.2 Kártyamenedzsment kialakítás követelményei A kártyamenedzsment legfontosabb követelményei a következők:

- kártya platform függetlenség (Java, MULTOS, ISO-7816 natív kártyák támogatása), - kártya alkalmazás függetlenség, - host platform függetlenség, - kliens platform függetlenség,

Kártyabirtokos adat

Web szerver

Kártya és Alkalmazás Menedzsment

Központi Rendszer

Kulcsmenedzsment

SOAP Client

Hitelesítés Szolgáltató

Kártya megszemélyesítés

Notification szerver

Egyéb

kártyaalkalmazás

Egyéb rendszerek

PIP

Kibocsátás utáni megszemélyesítés PIP


22

- HSM függetlenség, - HA, valamint horizontális skálázhatóság, - GlobalPlatform megfelelés (szereplők, profilok, szkriptek, protokoll), - Post Issuance Personalization (kibocsátás utáni alkalmazástelepítés, megszemélyesítés) képesség, - több független kártyakibocsátó támogatása, - több független alkalmazás-kibocsátó támogatása, - saját kulcs menedzsment, - együttműködés más (esetleg meglévő) rendszerekkel (RA, CA, kártya gyártás/megszemélyesítés alkalmazás menedzsment, ...) - bővíthetőség, testreszabhatóság, - szerep alapú hozzáférés kontroll, - kártya életciklus menedzsment, - alkalmazás életciklus menedzsment, - elveszett, meghibásodott kártyák kezelési képessége (visszavonás, csere, ...), - 24x7 órás HelpDesk szolgáltatás működtetése.

ITSO TS 1000-0 2007-06 © HMSO Kontroller, 2007

23

I. Melléklet

Az ITSO rendszerszemlélet és specifikációk bemutatása

Az alábbi fejezetek az ITSO TS 1000 dokumentumok részei, melyeket az Integrált Közlekedési Intelligens Kártya Szervezet /Integrated Transport Smartcard Organisation (ITSO)/ tett közzé és tart karban. Az ITSO tagsága közlekedési vállalatokból, berendezés és rendszer szállítókból, helyi és országos kormányzatokból áll. Az aktuális taglista az ITSO www.itso.org.uk című weboldalán található.

Az ITSO TS 1000 a közlekedési szolgáltatók, szponzorok, rendszer beszállítók és gyártók közti széleskörű konzultáció eredménye. A Közlekedési Minisztérium /Department for Transport (DfT)/ finanszírozással és tapasztalattal is hozzájárult a folyamathoz.

Az ITSO TS 1000 eredeti célja az volt, hogy platformot és eszközkészletet biztosítson az interoperábilis érintkezésmentes intelligens felhasználói média /Customer Media – CM/ tömegközlekedési jegyrendszerek és a kapcsolatos szolgáltatások kivitelezéséhez az Egyesült Királyságban oly módon, hogy azok végpontok közötti veszteségmentes adatátvitelt és biztonságot tesznek lehetővé. Az ITSO TS 1000 amennyire csak lehetséges nyitott előírás, a kialakulóban levő nemzeti, európai és nemzetközi szabványok korlátain belül a rendszerek és összetevők beszállítása terén levő verseny maximálása érdekében a teljes ipar kereskedelmi előnyét szolgálva. Általában a nyitott szabványokat szorgalmazza, de nem tiltja az egyedi (proprietory) megoldásokat sem, amennyiben azok ésszerű, diszkrimináció mentes feltételek mellett kerülnek felajánlásra és hozzájárulnak az interoperabilitás végső céljához.

Az ITSO-t azért hozták létre, hogy elkészítse és fenntartsa az interoperabilitást elősegítő műszaki specifikációkat és üzleti szabályokat. Az ITSO akkreditálja is a résztvevőket és az interoperábilis berendezéseket. Az ITSO az interoperabilitás elősegítője, a szükséges részvétel minimális szintje mellett. Az ITSO saját maga nem fog részt venni egy adott jegyrendszer semmilyen kereskedelmi döntésében, illetve megoldásában, és nem is fogja azt sem felállítani, sem üzemeltetni. Azonban az ITSO "nyilvántartásba fogja venni" azokat a szükséges interoperabilitási szolgáltatások biztosítása érdekében (például az egyedi rendszer azonosítók, tanúsítások és akkreditáció kibocsátása és kontrollja, biztonsági áttekintés).

Ebből következően a jelen Specifikáció adoptálása konkrét jegyrendszerekre a szponzorok/résztvevők kereskedelmi megítélésének kérdése, éppen úgy, ahogy a részletes üzleti szabályok és a pontos partneri konstrukciók is.

1. Az ITSO TS 1000 Specifikációk Hatóköre

Az ITSO TS 1000 az interoperabilitás biztosításához szükséges kulcsfontosságú műszaki tételeket és interfészeket határozza meg. Ebből a célból részletesen meghatározásra került a végpontok közti biztonsági rendszer és shell elrendezés; míg az egyéb elemek (például terminálok, back-office adatbázisok) leírására csak interfészeik vonatkozásában kerül sor. A


24

műszaki követelményeket kiegészítő üzleti szabályok máshol vannak meghatározva.

Megjegyzés: Az alábbi felsorolásban használt kifejezések definícióit az ITSO TS 1000-1 tartalmazza.

1.1 A 0. rész hatóköre Az ITSO TS 1000-0 az ITSO TS 1000 2-10 szerzői által biztosított szinopszisainak szerkesztői összesítése. A Specifikáció vonatkozó normatív jellegű részeinek csak egy tisztán leíró jellegű áttekintését tartalmazza.

2. Felhasználói Média (Customer Media - CM)

A Felhasználói Média kifejezés (rövidítve CM) azt az elektronikus platformot jelöli, amelyet az utasok ITSO jegyrendszerbeli termékeiknek tárolására használják. Jelenleg a legtöbb rendszer intelligens kártya platformot használ CM-ként, de ez a jövőben megváltozhat – ezért használunk egy általánosabb kifejezést.

Az ITSO TS 1000-ben megadott követelményeknek történő megfeleléshez a CM-nek támogatnia kell egy olyan érintkezésmentes áram és adat interfészt, amely megfelel az ISO/IEC 14443 vonatkozó részeinek. A CM-en jelen lehetnek egyéb adat interfészek is, de azokra nem terjed ki az ITSO TS 1000 hatóköre.

A CM-től a POST felé irányuló interfész az interoperabilitás szempontjából egy kritikus interfész, és az ITSO TS 1000 ennek az interfésznek a következő kulcsfontosságú attribútumait határozza meg:

— Fizikai;

— áram átviteli mechanizmusok;

— adat átviteli mechanizmusok;

— adat elrendezés;

— adat hozzáférés és biztonság;

— benchmark tranzakció idők.

Ezek számos platformra meghatározásra kerültek. Az ITSO TS 1000-10-ben minden egyes támogatott platform típus rendelkezik egy CM definícióval (Customer Media Definition - CMD). E CMD lefedi a platform összes meghatározott attribútumát, beleértve a fizikai formatényezőt és az adatelrendezést.

Igen valószínű, hogy az eltérő fizikai formatényezőkkel rendelkező platformok ugyanazt az elektronikus készüléket fogják használni és ezért ugyanazzal az adatelrendezéssel fognak rendelkezni. Erről a Formátum Verzió Kód (Format Version Code - FVC) használata gondoskodik, amely a médián az ITSO adatok részeként van eltárolva. A POST-ok el tudják olvasni ezt az adatelemet, és meg tudják határozni a szükséges, megfelelő adatfeldolgozási


25

szabályokat.

Amennyiben egy platform típus nincs definiálva az ITSO TS 1000-10-ben, akkor az nincs támogatva, ITSO szerint nem akkreditálható és nem használható ITSO Környezetben.

A CMD egyik legfontosabb funkciója az, hogy leképezi a logikai ITSO adat struktúrákat a média által biztosított fizikai, elektronikus tárolásra. Egyes esetekben ez a leképezés fizikai bit és byte szintre történik (például egy memóriakártyán), míg más esetekben a média által biztosított logikai tárolási elemekre fog történni (például egy operációs rendszer és adatállomány tároló képességgel rendelkező processzor alapú platform esetében).

A CMD meghatározza azokat az utasításokat is, amelyre a médián levő adatok eléréséhez szükség van, illetve hivatkozik azokra. Az ISO/IEC 14443 megengedi a proprietory utasítások használatát is bizonyos körülmények között, és a POST-oknak képesnek kell lenniük arra, hogy támogassák az ilyen utasításokat azon platformok esetében, amelyek használják azokat.

Az ITSO TS 1000-10-ben két fő média osztály van meghatározva:

— az olyan média platformok, amelyek egy Teljes ITSO Shell-t hordoznak;

— az olyan média platformok, amelyek egy Compact ITSO Shell-t hordoznak.

Azok a platformok, amelyek egy teljes ITSO Shell-t hordoznak, számos ITSO Jegyrendszer Terméket képesek befogadni egyidőben, és képesek egy olyan Ciklikus Naplót befogadni, amelyben elhelyezhetők az Ideiglenes Jegyek (Transient Tickets).

A korlátozott memóriával rendelkező platformok (pl. MIFARE Ultralight) Compact ITSO Shell-t használnak, mely csak egyetlen ITSO Jegyrendszer Terméket képes egyidőben befogadni. A Compact ITSO Shell nem képes Ciklikus Napló befogadására és számos egyéb korlátozással is rendelkezik, mely korlátozásokat az ITSO TS 1000-10 teljes körűen meghatározta.

A CM-en levő adatok biztonsága kritikus jelentősséggel bír az ITSO Rendszerek sikeres működése szempontjából. A média adatbiztonságának biztosítására számos mechanizmust használnak, a fő mechanizmusok közé tartoznak többek között az alábbiak:

— megszakítás-mentességet biztosító mechanizmusok, melyek megvédik az adatok sértetlenségét az olyan szituációkban, amikor a médiát eltávolítják a kártyaműveleti eszköz (POST) rádiófrekvenciás (RF) energia teréből, mielőtt az összes szükséges adat felírásra kerülne;

— ISAM által generált Pecsétek használata az adatok hitelességének biztosítása érdekében;

— média hozzáférési Kulcsok használata a CM-hez írás céljából történő hozzáférés ellenőrzés alatt tartása érdekében, és ezáltal az adatok sértetlenségének védelme céljából;

— A CM esetében egy egyedi rögzített szám használata a kulcsok és a pecsétek média

példányának specifikussá tétele érdekében;

Általában az összes ITSO médiának olvashatónak kell lennie anélkül, hogy szükség lenne Biztonsági Alrendszerekre, illetve ISAM-okra.

Az egy adott tranzakció végrehajtásához szükséges idő általában több ok miatt is fontos. A legnyilvánvalóbb ok az utas-áteresztő képesség. A próbák kimutatták, hogy a hosszú tranzakciós idők növelik annak kockázatát, hogy a CM-et idő előtt eltávolítják, még mielőtt az adat aktualizálás befejeződne. Azon hatás miatt, amelyet a tranzakciós idő a rendszer működésére és megbízhatóságára gyakorol, az ITSO TS 1000-10 minden egyes CFD-re meghatároz egy benchmark tranzakciót, azzal a maximális idővel együtt, amely az illető tranzakció végrehajtására megengedett.

3. A CM architektúra

Az ITSO CM architektúra úgy van megtervezve, hogy lehetővé tegye, hogy sok különböző ITSO Termék Entitást hordozzon sok különböző típusú CM, és azok használhatóak legyenek az összes POST eszközön ITSO környezet esetén.

3.1 A CM és az ITSO Shell-ek

A CM kifejezés használatát azért részesítjük előnyben a "kártya" kifejezéssel szemben, hogy lefedjük az olyan készülékek jövőbeli használatát, mint például a mobiltelefonok és a PDA-k, amelyeket lehet, hogy használni fognak az olyan fogyasztók, akik egy ITSO rendszert szeretnének igénybe venni.

Az ITSO architektúra támogatja a Termékek logikai elkülönítését attól a médiától, amely az ITSO Alkalmazást hordozza.

Tehát az intelligens kártyák kontextusában az ITSO hozzáad egy további harmadik réteget, nevezetesen a Termékeket, a kártya plusz Alkalmazás hagyományos kétrétegű modelljéhez. Ezt szemlélteti az 1. ábra.


26


27

1. ábra – Az ITSO három rétegű modellje

Generic description Általános leírás Card or other device Kártya, illetve egyéb eszköz One or more Applications Egy vagy több Alkalmazás One or more products in each Application Egy vagy több termék minden egyes Alkalmazásban Card layer Kártya réteg Application layer Alkalmazás réteg Product layer Termék réteg ITSO equivalent ITSO megfelelő

Ez azt jelenti, hogy egy ITSO Alkalmazás1 (ITSO Shell) több terméket tud támogatni, illetve egy ITSO Termék létezhet egyedül is, valaki másnak az alkalmazásában. Továbbá egy CM platform dedikálva lehet egy ITSO Shellnek, illetve az ITSO Shell "ITSO Alkalmazásként" rátehető más alkalmazásokkal együtt egy több alkalmazásos CM platformra. Ez a rugalmasság maximálissá teszi azon módok számát, melyek révén elérhető az interoperabilitás.

Az ITSO TS 1000-2 specifikálja minden egyes CM általános architektúráját, míg a támogatott CM különböző változatait az ITSO TS 1000-10 specifikálja.

Minden egyes ITSO tanúsítvánnyal rendelkező POST kötelező minimumként támogatja az ISO/IEC 14443 proximity kártya interfészt, valamint a Mifare Classic™ interfész értelmezésének képességét. Az összes ITSO CM használható bármely, az ITSO által arra tanúsított ITSO POST-on.

Az ITSO tagoknak lehetőségük van arra, hogy a megfelelő médiák széles köréből válasszák ki azt, amelyen szállítani szeretnék Termékeiket.

E médiák köre kiterjed az olyan CM média típusoktól kezdve, amelyek csak egy kompakt ISO Shell-t és egyetlen Terméket képesek tárolni az olyan CM-ekig, amelyek képesek egy teljes körű ITSO Shell, valamint több Termék tárolására, ahogyan azt a 2. ábra szemlélteti.

1 Az ITSO Shell-nek keresztelte ezt át annak érdekében, hogy elkerülje a hagyományos modellel történő keverést.

3. ábra – Többféle CM választási lehetőség

Card domain Kártya domén Application domains Alkalmazás domének Products Termékek Single product only Csak egyetlen termék Multiple application layer multiple products Több alkalmazási réteg, több termék Single application layer, Multiple products Egyetlen alkalmazási réteg, több termék

3.2 Adatcsoportok

Az egy ITSO Shell-ben tárolt összes adat adatcsoportokba van csoportosítva. A különböző Adatcsoportok az alábbiakat tartalmazzák

— azon adatok, amelyek leírják az ITSO Shell-t és a CM-et, amelyen az ITSO Shell található;

— azon adatok, amelyek leírják a Könyvtárt és annak tartalmát;

— egy ITSO Termék Entitás (ITSO Product Entity - IPE) rögzített és változó részeit.

A Könyvtár és az IPE Adatcsoportok oly módon vannak lepecsételve, hogy hitelességük ellenőrizhető legyen és kapcsolható legyen ahhoz a CM Típushoz, amelyen a Termék van. Az Adatcsoport általános struktúráját a 3. ábra szemlélteti.


28

3. ábra – Adatcsoportok

Label Címke The label: Identifies the owner and type of content of the Data Group

A címke: Beazonosítja az adatcsoport tartalom tulajdonosát és típusát

Set of structures Struktúrák halmaza The Dataset: The content of the Data Group

Adathalmaz: Az Adat Csoport tartalma

Instance Identifier Példány azonosító The Instance Identifier: Identifies and instance of a Data Group

A Példány Azonosító: Beazonosítja egy Adat Csoport egy példányát

Seal Pecsét The Seal: Provides a means of verifying the authenticity of all the data in the Data Group.

A Pecsét: Az Adat Csoportban levő összes adat hitelességének ellenőrzéséhez egy eszközt biztosít.

3.3 A Shell-ben levő termékek

Egy ITSO Shell számos Terméket tud befogadni. Minden egyes Termék tartalmaz egy Címkét, amely leírja a Termék Tulajdonost, a Termék típusát és altípusát, valamint lejárati dátumát. A címkék fel vannak sorolva egy Könyvtárban, mely könyvtár a Logikai Szektor információk egy tömbjét is tartalmazza, melyet a POST Alkalmazás értelmez annak érdekében, hogy megtalálja, hogy a Termékek pontosan hol is vannak tárolva a CM-ben.

A POST Alkalmazás használja a Könyvtárt abból a célból, hogy meghatározza, hogy a Shell-ben található Termékek közül melyiket fogadja el a POST, ha van ilyen. Bizonyos egyszerű Alkalmazások esetében magának a Könyvtár információknak a használata elegendő lehet egy tranzakció végrehajtásához, mely esetben a tranzakció időtartamok minimalizálhatók.

Az ITSO Shell, Könyvtár és az IPE-k a CM-en találhatók, az ITSO TS 1000-10-ben szereplő definícióknak megfelelően.

Az összes Termék és a Könyvtár tartalmaz Pecséteket, mely egy olyan eszközt biztosít, melynek segítségével a POST Alkalmazás ellenőrizni tudja a hitelességet. A Pecsétek a CM-


29

hez kriptográfiai módszerekkel is kötve vannak. A Címkék, Termékek és a Könyvtár közti kapcsolatot szemlélteti a 4. ábra.

4. ábra – A Könyvtár szerkezete és kapcsolata a Termékekhez

Product(s) Termék(ek) Seal Pecsét Instance identifier Példány azonosító Fixes structures Rögzített struktúrák Directory Könyvtár Dataset Header Adathalmaz Fejléc Product Label Termék Címke Seq# and SCT Sorszám és SCT Variable structures Változó struktúrák

3.4 Naplók

A Shell kétféle napló nyilvántartást támogat, az Alapvető Naplót és a Normál Naplót.

Az Alapvető Napló csak egy, a Könyvtárban szereplő adat, mely felhasználható a visszaadási (pass-back) idők és az alapvető belépési/kilépési adatok tárolásával, melyek szükségesek bizonyos Check-in/Check-out rendszerek számára.

A Normál Napló egy Ciklikus Napló, amely néhány sokkal nagyobb rekord tárolására képes,


30

alkalmas esemény és/illetve átmeneti jegyinformációk tárolására. A Könyvtárban rögzített adat egyik speciális formája beazonosítja a napló legaktuálisabb rekordját.

Amennyiben a Normál Naplóban levő rekordokat meg kell őrizni egy ésszerű időtartamra, illetve amíg egy másik esemény be nem következik, akkor azok félig-állandóként megjelölhetők. A napló ciklikus jellege biztosítja azt, hogy amennyiben az új rekordok megszakadnak, az nem érinti a korábbi rekordokat.

Azon Átmeneti Jegy rekordok tartalmát, melyek tárolásra kerülnek a normál naplóban, az ITSO TS 1000-5 határozta meg, és minden egyes rekord Árva IPE Adatcsoportokba (Orphan IPE Data Groups) van beépítve az ITSO TS 1000-2-ben meghatározottaknak megfelelően. Az Árva IPE Adatcsoportok egy egyedi azonosítót és egy Pecsétet adnak hozzá a rekordokhoz. Az ily módon lepecsételt rekordok felhasználhatók jegyekként és azokat hitelesíteni tudja bármelyik ITSO POST.

A Ciklikus Naplót és az Árva IPE Adatcsoportok használatát szemlélteti az 5. ábra.

5. ábra - A Ciklikus napló és az Árva IPE

Group as Sealed or verified by ISAM Csoport, az ISAM által lepecsételt, illetve ellenőrzött formában Label Címke Dataset header Adathalmaz fejléc Transient Ticket Record Átmeneti Jegy Rekord Padding Kitöltés Instance IDentifier Példány azonosító Seal Pecsét Label added to Dataset for creating and verifying then removed from Dataset when writing to Log

Az Adathalmazhoz létrehozatal és ellenőrzés céljából hozzáadott címke, mely eltávolításra kerül az Adathalmazból Naplózáskor

Label held in POST as Global constant A POST-ban, Globális állandóként levő címke Entry 1 1. tétel Entry 2 2. tétel Entry Normal Log Normál napló tétel SCT and Seq# SCT és sorszám Directory Instance IDentifier Könyvtár Példány Azonosító next következő previous előző


31


32

Dataset detached from Label Címkétől leválasztott adathalmaz Then written to next log slot Ekkor beírásra kerül a következő napló rovatba Log cycles through 2 sectors as pointed to by the directory Napló ciklusok 2 szektoron keresztül, a könyvtár által megadottak

szerint

3.5 Megszakításmentesség

Amikor a CM-re változó információk kerülnek felírásra, miközben a CM mozgásban van, a folyamat esetenként nem végzi el az írást korrekt módon. Az ITSO előírja azt, hogy ebben az esetben, lehetséges a média használatának folytatása minden korlátozás nélkül. Az ITSO TS 1000-10-ben meghatározott különböző CM-függő megszakításmentességi módszerekre kiterjed az ITSO TS 1000.

Azokat a CM-eket, amelyek az Alkalmazás számára transzparens, hardveres megszakításmentes rendszereket támogatják, az ITSO elfogadja azokkal a rendszerekkel egyetemben, amelyek Alkalmazás szoftver alapú megoldások használatát igénylik. Két különböző szoftveralapú megszakításmentes módszert specifikál az ITSO a CM kapacitásával kapcsolatosan. Ezek a következők:

— azon CM-ek esetében, melyeknél a memóriaterület korlátozott, egy olyan módszer használatos, amely csak a pillanatnyi értékek tárolását duplikálja.

— azon CM-ek esetében, melyeknél több hely áll rendelkezésre, egy olyan módszer van előírva, amely hatékonyan felhasznál egy olyan duplikált másolatot, amely automatikusan naplózza az utolsó néhány tranzakciót, a korrekt működés fenntartása mellett.

Mindkét esetben és különösen akkor, amikor több Érték Rekord Adatcsoport módosítása történik ugyanazon CM munkaszakasz során, a Könyvtár Adatcsoport az utolsó módosítandó Adatcsoport.

A Könyvtár aktualizálása után a Logikai Szektor információ minden egyes módosított Érték Rekord Adatcsoport utolsó verziójára fog mutatni. Amennyiben a Könyvtár aktualizálása meghiúsul, akkor az az Érték Rekord Csoportok összes utolsó verziójára fog mutatni, mintha semmisem történt volna.

4. Az ITSO Shell-ben tárolt Termék Adat Elemek

A termék adat elemeket az ITSO TS 1000-5 határozza meg.

Két adatosztály van meghatározva:

— ITSO Termék Entitások (IPE-k);


33

— Átmeneti Jegy rekordok.

Az IPE-k az olyan Termékek tárolását szolgálja, mint például a jegyek, a kedvezményekre való jogosultság, a Tárolt Utazási Jogok (Stored Travel Rights - STR), ami a közlekedési díjtárca, illetve a kuponok. Az IPE használatára akkor kerül sor, amikor a Termékeket az utazás előtt adják el, illetve amikor a Terméket egy bizonyos időtartamig fenn kell tartani. A jellemző példák közé tartoznak a vasúti jegyek és a szezonális jegyek. Az IPE-k részletesebb leírása az alábbiakban található.

Átmeneti Jegy rekordok használatára akkor kerül sor, amikor egy jegyet az utazás pontján értékesítenek, és nincs szükség arra, hogy azt az utazás végénél tovább tárolják. Egy jellemző példa erre egy kedvezmény jogosultság, illetve díjtárca (Tárolt Utazási Jogok) használata egy buszjegy megvásárlására. Az Átmeneti Jegyek használatának részletesebb leírása az alábbiakban található.

4.1 ITSO Termék Entitások (ITSO Product Entities - IPEs).

Az ITSO az IPE-knek számos különböző típusát határozza meg, minden egyes típust egy TYP szám jelöl.

A jelenleg meghatározott IPE-ket az 1. táblázat foglalja össze.

1. táblázat - IPE típusok

TYP kód IPE cím Jellemző felhasználás

0 Az ITSO Könyvtáron belül, az ITSO TS 1000-2 szerint meghatározott magán entitás

Nem interoperábilis Termékek2 tárolására, valamint más felhasználás céljából történő CM memória terület lefoglalására használják.

1 RFU (jövőbeli használatra lefoglalva)

ITSO által lefoglalva jövőbeli használat céljából.

2 Az ITSO nem ösztönzi a sajátos entitások használatát. Amikor egy Termék potenciálisan interoperábilis, akkor előnyben részesítendő az ITSO által definiált IPE a jövőbeli interoperabilitás alapjaként.


34


2 Tárolt Utazási Jogok

(Stored Travel Rights - STR)

EH 3.0: Díjtárca

Azon utazási jogok tára, melyek felhasználhatók utazás beszerzésére.

Biztosítva van az akció lista aktualizálása és automatikus megújítása. Az akció listák lehetővé teszik, hogy a back office aktualizálja a Terméket, amikor a CM-et bemutatják egy POST-nál.

Az automatikus megújítás lehetővé teszi, hogy a POST automatikusan aktualizálja a Terméket, amikor azt bemutatják egy POST-nál, de az utazási jogok tára elégtelennek bizonyul a javasolt utazáshoz, illetve egy küszöbértékbe ütközik. Az automatikus megújítás után a rendszer egy üzenetet küld a back office-nak, amely beindít egy fizetés beszedési eseményt.

3 1. hűség típus (CM alapú)

EH 3.0: Pontgyűjtő 1 (kártyán)

Egy hűség termék, mely esetében a hűség pontokat a Termékben tárolják.

4 Számlára történő felszámítás (Charge to Account - CTA) 1. módozata (korlátozás az elköltött értékre vonatkozóan)

EH 3.0: Utas Szerződés (érték alapú)

Egy utó-fizetéses Termék, amely felhasználható utazás beszerzésére. A kockázatot az határolja be, hogy az a teljes összeg korlátozva van, amely lekölthető mielőtt a fizetés beszedésre kerül a Vásárlótól.

5 Számlára történő felszámítás (CTA) 2. módozata (a felszámítási időszakonkénti tranzakciók mennyiségére vonatkozó korlátozás)

EH 3.0: Utas Szerződés (utazás alapú)

Egy utó-fizetéses Termék, amely felhasználható utazás beszerzésére. A kockázatot az határolja be, hogy azon tranzakciók mennyisége korlátozva van, amely lebonyolítható egy felszámítási időszakban (jellemzően egy hét), valamint minden egyes tranzakció maximális értéke is korlátozva van.

6 – 13 RFU ITSO által lefoglalva jövőbeli használat céljából.

14 Jogosultság EH 3.0: Kedvezményes Díjtermék 2

Egy Termék, amelyet a Vásárlónak egy szolgáltatásra, illetve privilégiumra vonatkozó jogosultságának tárolására használnak, például egy kedvezményes utazásra való jogosultságot.

15 RFU ITSO által "lefoglalva jövőbeli használat céljából".

16 ITSO ID & jogosultság

EH 3.0: Kedvezményes Díjtermék 1

Egy több célú Termék, amely felhasználható az alábbiak tárolására:

Vásárlóval kapcsolatos azonosítási információk;

Vásárló jogosultsága egy szolgáltatásra, illetve privilégiumra, például egy kedvezményes utazásra való jogosultság;

Az ITSO Shell részére fizetett letéttel kapcsolatos információk.

17 2. hűségtípus (Központilag Elszámolva)

EH 3.0: Pontgyűjtő 2 (központban)

Egy Hűség Termék, mely esetében a pontokat csak a back office tárolja, és a pontok nincsenek tárolva a Termékben.


35


18 – 21 RFU ITSO által "lefoglalva jövőbeli használat céljából".

22 Előre meghatározott jegy (területi alapú) a napok kiválasztásával, Akció Lista módosítási és automatikus megújítási képesség opciókkal

EH 3.0: Általános Jegy

Terület alapú Időszaki bérlet, illetve szezonális jegy Termékek.

Tartalmaz egy Tárolt Jegy funkciót, melynél a Tárolt Jegyek igény szerint aktiválhatók. E funkció kiszolgálja a napok kiválasztását lehetővé tevő Termékeket, például 7 egynapos időszakra szóló megvásárolt bérletet, melyek esetében minden egyes bérlet egy adott napon történő első használatkor kerül aktiválásra.

A Termék módosítható akció listák és automatikus megújítás révén. Az Akció Listák lehetővé teszik a back office számára, hogy aktualizálja a Terméket, amikor az bemutatásra kerül egy POST-nál. Az automatikus megújítás lehetővé teszi a Termék aktualizálását, például az érvényesség kiterjesztésével történő megújítását, amikor az bemutatásra kerül egy POST-nál, és kiderül, hogy a Termék lejárt. Az automatikus megújítás után a rendszer egy üzenetet küld a Back Office-nak, amely beindít egy fizetés beszedési ciklust.

23 Előre meghatározott konkrét útra szóló jegy járműváltási /multi-ride/, automatikus megújítási és akció lista módosítási képesség opciókkal

EH 3.0: Viszonylati Jegy

A konkrét utazási jegyek felhasználhatók egyszeri, retúr, illetve időszakos jegyekhez.

Tartalmaz egy Tárolt utazási jegy funkciót, melynél a tárolt utazások igény szerint aktiválhatók. E funkció be tudja fogadni a több-útra /multi-ride/ szóló jegyeket.

A Termék akció listák és automatikus megújítás révén módosítható. Az Akció Listák lehetővé teszik, hogy a back office aktualizálja a Terméket, amikor azt bemutatják egy POST-nál. Az automatikus megújítás lehetővé teszi a Termék aktualizálását, például az érvényesség kiterjesztésével történő megújítását, amikor azt bemutatják egy POST-nál és kiderül, hogy a Termék lejárt. Az automatikus megújítást követően egy üzenetet küld el a rendszer a back office-nak, amely beindít egy fizetés beszedési ciklust.

24 Előre meghatározott konkrét utazásra szóló jegy, foglalásokkal és speciális korlátozásokkal, akciólista módosítási és automatikus megújítási képesség opciókkal

EH 3.0: Szolgáltatáshoz Kötött Viszonylati Jegy

A Konkrét Utazási Jegyek egyszeri, retúr, illetve időszakos jegyekhez használhatók fel.

Foglalási és speciális korlátozási opciókat biztosít.

Tartalmaz egy Tárolt Utazás jegy funkciót, melynél a Tárol Utazások igény szerint aktiválhatók. A funkció be tudja fogadni a több útra /multi-ride/ szóló jegyeket.

A Termék akció listák és automatikus megújítás révén módosítható. Az Akció Listák lehetővé teszik, hogy a Back Office aktualizálja a Terméket, amikor az bemutatásra kerül egy POST-nál. Az automatikus megújítás lehetővé teszi a Termék aktualizálását, például az érvényesség kiterjesztésével történő megújítását, amikor a Termék bemutatásra kerül egy POST-nál és kiderül, hogy lejárt. Az automatikus megújítást követően a rendszer egy üzenetet küld a back office-nak, mely beindít egy fizetés beszedési ciklust.


36


25 Utazásra vonatkozó Kupon többszöri felhasználási, akciólista módosítási és automatikus megújítási képesség opciókkal

EH 3.0: Utazási Kupon

A Termék használható kuponok tárolására, melyeket például arra használhatnak, hogy eseményekhez, illetve olyan szolgáltatásokhoz hozzáférést biztosítsanak, mint például az ingyen üdítőitalok. Előreláthatólag ezen kuponok használata kapcsolva lesz valamilyen módon az utazáshoz.

Tartalmaz egy Tárolt Kupon funkciót, a Tárolt Kuponok igény szerinti aktiválásával.

A Termék akció listák és automatikus megújítás révén módosítható. Az Akció Listák lehetővé teszik, hogy a Back Office aktualizálja a Terméket, amikor az bemutatásra kerül egy POST-nál. Az automatikus megújítás lehetővé teszi a Termék aktualizálását, például rendelkezésre álló felhasználások számának kiterjesztésével történő megújítását, amikor a Termék bemutatásra kerül egy POST-nál és kiderül, hogy lejárt. Az automatikus megújítást követően a rendszer egy üzenetet küld a Back Office-nak, mely beindít egy fizetés beszedési ciklust.

26 Nyitott rendszerű díjbeszedés, többszöri felhasználási, akciólista módosítási és automatikus megújítási képesség opciókkal

EH 3.0: Egyszerű Jegy

A szezonális Termék alkalmas út, illetve átjáró rendszerek esetében történő használatra, amikor egyösszegű útidíj fizetendő.

Tartalmaz egy Tárolt használat funkciót, a tárolt felhasználások igény szerinti aktiválásával.

A Termék akció listák és automatikus megújítás révén módosítható. Az Akció Listák lehetővé teszik, hogy a Back Office aktualizálja a Terméket, amikor az bemutatásra kerül egy POST-nál. Az automatikus megújítás lehetővé teszi a Termék aktualizálását, például az érvényesség kiterjesztésével történő megújítását, amikor a Termék bemutatásra kerül egy POST-nál és kiderül, hogy lejárt. Az automatikus megújítást követően a rendszer egy üzenetet küld a Back Office-nak, mely beindít egy fizetés beszedési ciklust.

27 Időszaki bérlet (helytakarékos)

EH 3.0: Helytakarékos Időszaki Jegy

Időszaki bérlet, illetve szezonális jegy Termékek.

Felhasználható a CM-ben abban az esetben, ha a memória terület korlátozott, például a kis memóriájú, illetve az eldobható Intelligens Kártyák esetében, illetve például több-funkciós Intelligens Kártyák esetében, amikor a memória terület szintén korlátozott.

28 Carnet (helytakarékos)

EH 3.0: Helytakarékos Napi Tömbjegy

Carnet.

Felhasználható a CM-ben, amikor a memória terület korlátozott, például kis memóriájú, illetve eldobható Intelligens Kártyák esetében, illetve például a több-funkciós Intelligens kártyák esetében, amikor a memória terület szintén korlátozott.

29 Többszöri utazásra szóló jegy (helytakarékos)

EH 3.0: Helytakarékos Multi-jegy

Több Útra szóló jegyek.

Felhasználható a CM-ben, amikor a memória terület korlátozott, például kis memóriájú, illetve eldobható Intelligens Kártyák esetében, illetve például a több-funkciós Intelligens kártyák esetében, amikor a memória terület szintén korlátozott.

30 – 31 RFU ITSO által "lefoglalva jövőbeli használat céljából".

32 ITSO shell környezet csoport Az ITSO Shell adatai


37


33 ITSO Könyvtár csoport Az ITSO Könyvtár

34 ITSO átmeneti jegycsoport

EH 3.0: Átmeneti Jegy

Az ITSO Átmeneti Jegy adatai

35 és afelett RFU ITSO által "lefoglalva jövőbeli használat céljából".

Figyelem, a 31-nél nagyobb TYP számmal rendelkező IPE csoportok esetében a Könyvtárban rögzített tételeknél nem kerül felhasználásra a TYP érték.

1. IPE definíciók, megtestesítők /embodiments/, példányok és azonosítás.

Az IPE-k azonosítása a 2. táblázatban bemutatottak szerint történik.

2. táblázat – IPE azonosítás

Kategória Leírás Beazonosítás módja3:

IPE definíció Egy IPE típus definíciója az ITSO Specifikáción belül

TYP

IPE megtestesítő Egy IPE Termék Példány létrehozásához szükséges utasítások (egy Termék Definíció)

Termék tulajdonos IIN +4

Termék tulajdonos OID +

TYP +

PTYP (a Termék Tulajdonos által definiált érték)

IPE példány Egy CM-en belül levő ITSO Shellre töltött IPE tényleges példánya (egy Termék Példány)

Termék tulajdonos IIN +

Termék tulajdonos OID +

TYP +

PTYP +

ISAM ID + létrehozása

ISAM Seq# létrehozása

4.2 Átmeneti Jegy /Transient Ticket/ rekordok.

3 Minden esetében az azonosító sztring a beazonosított entitásra vonatkozóan egyedi lesz. 4 Ebben a kontextusban a ‘+’ szimbólum láncolást jelent.


38

Az Átmeneti Jegy rekordok az ideiglenes jegyek és az egyéb, specifikált események rekordjainak tárolására használják:

— eladott jegyek, amikor nincs létrehozva IPE:

például amikor a kedvezményes félárú jegyet egy, a shell-ben levő kedvezmény jogosultság alapján adják el, akkor hozzá lesz adva egy rekord az átmeneti jegy naplóhoz az esemény rögzítése érdekében;

— zártrendszer belépési rekordok:

a zárt rendszer egy olyan rendszer, mely esetében a felhasználó felmutatja a CM-jét mind a rendszerbe történő belépéskor, mind a rendszerből történő kilépéskor, és kilépéskor fizet;

— több szakaszból álló út rekordok:

kumulatív viteldíj és az utazási szakaszok száma tárolható, ami lehetővé teszi egy viteldíj felső határ kivitelezését a több szakaszból álló utazások5 esetén;

— STR hozzáadására vonatkozó rekordok.

Több Átmeneti Jegy rekord tárolható. A tényleges mennyiség a CM memória kapacitásától és az ITSO Shell konfigurálásától függ.

Egy olyan módszer van biztosítva a zárt rendszerbe történő belépési rekordok megőrzésére, melyben a belépési rekord nem kerül felülírásra mindaddig, ameddig egy másik esemény be nem következik, például a Vásárló elhagyja a zárt rendszert. Azonban az ilyen jellegű rekordok csak 48 óráig lesznek megőrizve.

5 Bizonyos Termékek tartalmazzák ezen adatelemeket is. Amikor ez az eset áll fenn, akkor nem kerül sor átmeneti jegy rekord létrehozatalára, hanem a rendszer a Termék alapú adatelemeket használja.


39

5. A Szolgáltatási Pont Terminálja /Point of Service Terminal (POST)/

Az ITSO környezeten belül a POST definíció szerint a berendezéseknek egy olyan együttes osztálya, amely lehetővé teszi, hogy a CM-en levő adatentitásokkal tranzakciókat hajtsanak végre.

Az ITSO környezetben az alábbi résztvevők jellemzően POST felhasználók:

— Termék Kiskereskedők (Az IPE példányok eladása és feltöltése egy ITSO Shell-re);

— Szolgáltatás Üzemeltetők (Az IPE példányok validálása és használata);

— Vásárló (Felügyelet nélküli tranzakciók esetében);

— Shell Kiskereskedők (Egy ITSO Shell eladása és médiára történő feltöltése).

A POST biztosítja a média platform számára azt a hozzáférési mechanizmust, mely támogatja az ITSO azon célkitűzését, hogy lehetővé tegye a jegyrendszer Termékek egy olyan körének interoperábilis használatát, amelyet a platformok egy körén értékesítenek és használnak, és különböző kibocsátóktól származnak, a több Termék tulajdonosai nevében.

A POST kifejezés által lefedett berendezések köre tág és változatos. Azonban az összes POST rendelkezik az alábbi kulcsfontosságú attribútummal:

— képesek adatok olyan érintkezésmentes médiáról történő olvasására és arra történő írására, amely megfelel az ITSO Specifikációnak;

— időközönként adatot cserélnek a HOPS rendszerrel;

— tartalmaznak egy ISAM-ot, amely a POST-ra vonatkozóan egyedi és amely nincs megosztva más POST-okkal.

Az ITSO TS 1000-3 csak azokat a követelményeket definiálja, amelyek az interoperábilis CM használatra és az ITSO környezet egyéb részeivel történő interfész kapcsolatokra vonatkoznak. Ezeket a követelményeket a jegyrendszer terminál háttérben levő specifikációja felett egy interoperábilis rétegként kell alkalmazni. Ebből következően a POST-nak ITSO Megfelelőségi akkreditációja csak erre a felső rétegre vonatkozik, és nem jelent semmit a háttérben levő jegyrendszer terminál specifikáció megfelelőségét, illetve más vonatkozását illetően.

Az összes POST támogatja az ITSO TS 1000-10-ben definiált teljes CM platform sorozatot, és használja minden egyes platformtípus esetében a megfelelő megszakítás-mentességet biztosító mechanizmusokat. Határozottan ajánlott, hogy a POST olyan szoftver architektúrát használjon, amely lehetővé teszi további CM platformok hozzáadását a konfiguráció paraméterek segítségével.

Az összes POST képes az ITSO TS 1000-2-ben definiált összes ITSO adat entitás parszolási (parsing) műveletére és feldolgozására. Minden egyes POST típus támogatja az IPE-knek


40

azt a halmazát, amely alkalmas interoperábilis környezetben történő használatra. A megfelelő IPE halmazokat az ITSO üzleti szabályok definiálják.

Az ITSO környezetben működő minden egyes POST példányban van egy ISAM. Az ISAM fizikai elérése addig a mértékig korlátozva van, hogy valamilyenféle eszközre szükség legyen, de nem feltörés-biztos (tamper-proof), illetve a jótállási pecséteket fel kell törni.

Az ITSO a POST emberi interfészének bizonyos jellemzőit előírja annak érdekében, hogy egy következetes és bizalmat kiváltó alapvető felhasználói tapasztalat legyen biztosítva az olyan ITSO szerinti POST-ok körében, amelyekkel a vásárló találkozhat. Ezen ITSO specifikus jellemzők a berendezés általános emberi interfészének csak egy részét képezik és a háttérben levő terminál specifikáció kiegészítéseként használandó.

Az interoperabilitás megfelelő szintjének biztosítása érdekében az ITSO TS 1000-3 előírja a POST-ra vonatkozó, alábbiakkal kapcsolatos funkcionális követelményeket:

— Média kezelés:

• Az ITSO Shell felismerése és validálása;

• A Könyvtár validálása;

• A Termékek kiválasztása;

• A megszakítás-mentesség kezelése;

• A média ismételt megjelenítése;

• Tranzakciós idő;

— Az IPE kezelése:

• Általános IPE példány feldolgozás;

• IPE példány létrehozatala;

• IPE példány törlése;

• Ciklikus Napló aktualizálása;

• Automatikus megújítás;

• Tárolt Utazási Jogok (STR) feldolgozása;

• Jegy nullázása;

• Jegyek és nyugták nyomtatása;

— Üzenet generálás és feldolgozás;

— Konfiguráció kezelés:

• Forró listák;

• Akció listák;

• Interoperabilitási listák.


41

6. Az ITSO Back Office (HOPS) követelmények

Az ITSO TS 1000-4-ben definiált koncepcionális ITSO Back Office entitás a Host Üzemeltető, illetve Feldolgozó Rendszer (Host Operator or Processing System - HOPS).

Az ITSO TS 1000-4 a Back Office-nak csak azokat a szempontjait fedi le, amelyek a HOPS-al kapcsolatos interoperabilitásra hatást gyakorolnak, lehetővé téve azt, hogy a HOPS a lehető legnagyobb rugalmasságot valósítsa meg, amennyiben az nem érinti az interoperabilitást.

A HOPS definíciója nem tartalmazza az alábbiakat:

— nem fedi le a tömegközlekedési rendszer back office összes szempontját, csak azokkal a szempontokkal foglalkozik, amelyek az interoperabilitásra vannak hatással;

— nem definiálja, hogy a HOPS megvalósítása hogyan történjék, hanem a funkcionális követelmények definiálásával foglalkozik inkább, azzal a kivétellel, hogy bizonyos konkrét példányok esetében a funkcionalitást kötelezően elő kell írni az interoperabilitás biztosítása érdekében.

Az ITSO az alábbi HOPS funkcionális követelményeket definiálta: — Veszteségmentes kommunikációkezelés (az Üzenet Processzor);

— Üzenet adattárolás;

— Az ITSO Shell és IPE számla kezelése:

• Beleértve a Forrólista (Hotlist) és az Akciólista Feldolgozást;

— Eszközkezelés;

— Szolgáltatások:

• Audit nyom + Napló (Journal),

• Szabályoknak történő megfelelőség,

• Biztonság monitorozása,

• Backup,

• Archívum.

Most ezekkel a funkcionális követelményekkel fogunk foglalkozni részletesen.

A veszteségmentes kommunikáció kezelés (az Üzenet Processzor) egy olyan folyamat, amely az ITSO TS 1000 által előírt veszteségmentes kommunikációs módszert kezeli.

Az üzenet adattárolás az összes továbbított és fogadott adat biztonságos tárolása, adat-visszanyerési és audit célokból történő megőrzés céljából.


42

Az ITSO Shell és IPE számlakezelés az alábbiakat biztosítja: — Számlák (adat “adatállományok”) minden egyes Shell-re és IPE-re vonatkozóan;

— A Forrólisták és Akciólisták létrehozásának és kezelésének egy módszere;

Az Eszköz Menedzser /Asset Manager/ az alábbi eszközöket menedzselő szolgáltatás: — POST;

— HOPS;

— ISAM-ok;

— HSAM-ok.

Az Eszköz Menedzser nem csak beazonosítja az eszközöket, állapotukat és helyüket, de azt a célt is szolgálja, hogy eljuttassa a biztonsági és egyéb konfigurációs adatállományokat a megfelelő eszközre.

Az összes HOPS-nak tartalmaznia kell egy biztonságkezelő készüléket, egy HSAM-ot, mely funkcionalitása azonos egy ISAM-mal. Valójában legegyszerűbb formájában a HSAM egyetlen ISAM-ból áll, ahogyan azt a POST-ok használják.

Nyilvánvaló, hogy a HOPS definíciója nem fedi le az összes olyan funkciót, amelyre szükség van egy teljes körűen működő Back Office-hoz, és ezért e funkciókat a rendszer megvalósítója, illetve beszállítója fogja előírni. Például az alábbi funkciókat nem tartalmazza az ITSO HOPS specifikáció: — Pénzügyi rendezés;

— Visszatérítés;

— Termék kezelés;

— CM kezelés.

Az, hogy a CM kezelés hiányzik a HOPS specifikációból szándékos. Az ITSO TS 1000 saját maga nem foglalkozik a tényleges CM-mel, csak a médián levő ITSO Alkalmazással (az ITSO Shell-lel). Ezért előírja a Shell Számlán keresztül az ITSO Shell-ek kezelését, de nem írja elő a tényleges CM kezelését.

Minden egyes ITSO-nak megfelelő rendszernek tartalmaznia kell minimum egy HOPS-ot, de a HOPS funkcionalitás megvalósításának módszere nincs kötelezően előírva. Egy kis rendszer esetén előfordulhat, hogy egy harmadik fél szolgáltató tulajdonában levő és általa futtatott HOPS-on vásárol megosztott kapacitást, míg a másik véglet egy nagy rendszer, mint például az Egyesült Királyság nemzeti vasúti rendszere, számos HOPS-ot tartalmazhat.

Az ITSO TS 1000 nem írja kötelezően elő, hogy a HOPS-ot hogyan kell megvalósítani. Egyetlen számítógép is elegendő lehet, illetve a szükséges funkcionalitás számos számítógépre is leosztható, amelyek elképzelhető, hogy távol vannak egymástól. Az összes ITSO-nak megfelelő rendszernek tartalmaznia kell az összes HOPS funkcionalitást, de az nem szükségszerű, hogy mindezt egyetlen számítógépen tartalmazza. Azonban az összes HOPS-nak tartalmaznia kell bizonyos alapvető funkciókat, beleértve az alábbiakat:

— Üzenet feldolgozás;

— Üzenet tár;

— HSAM;

— Szolgáltatások.

7. Biztonsági Architektúra

Az ITSO biztonsági architektúrát úgy tervezték, hogy minden egyes ITSO Tag és CM birtokos bízhasson abban, hogy a megfelelő Üzemeltetők csak valódi ITSO Termékeket fognak elfogadni. Továbbá a generált tranzakciók, amikor azokat bármilyen bevétel, követelés, illetve bevételmegosztás alapjaként használják, a Termék, illetve Shell tulajdonosok által hitelesíthetők, illetve auditálhatók a CM birtokos nevében.

A biztonsági architektúrát úgy tervezték továbbá, hogy egyenlő módon biztosítsa az interoperabilitás elérését, azáltal, hogy felkínálja a tagoknak azt a lehetőséget, hogy több, eltérő képességekkel/költséggel rendelkező különböző CM platformokat használhassanak, amelyek az igényeiknek megfelelő Termék(ek)et tartalmazzák. Miközben azt is biztosítja, hogy a többi ITSO tagtól származó termékekre vonatkozó interoperabilitás ellenőrzött módon úgy és akkor legyen megvalósítva, ahogyan és amikor arra szükség van.

A Termékek és Tranzakciók létrehozatalukkor egész élettartamukra le vannak pecsételve. Bármely ITSO rendszer tag hitelesítheti azt, hogy az illető termék, illetve tranzakció nem lett módosítva és valódi. Az ITSO kidolgozott a rendszer tagok által történő használat céljából egy olyan Biztonsági Alrendszert (Security Sub-system - SSS), mely biztosítja a biztonság következetes kezelését az összes tag megelégedésére, függetlenül szerepkörüktől. Az ITSO biztonság egy végpontok közti (“End-to-End”) architektúra, amely felöleli mind a felhasználói médiát (CM platformot), a kártyaműveleti eszközöket (POST-ot) és a központi back-office elemeket (HOPS-ot), ahogyan azt a 6. ábrában a pontozott vonal szemlélteti.

6. ábra – Végpontok közti biztonság

Customer Media CM Product Termék Security Sub-system Biztonsági Alrendszer

Az SSS-t egy ITSO Rendszeren belül bármilyen entitás használhatja szerepkörtől függetlenül. A 7. ábra egy jellemző ITSO rendszer biztonsági alrendszereinek szerepköreit, elsődleges


43

kapcsolatait és helyszíneit szemlélteti.

7. ábra – Biztonsági alrendszerek egy jellemző ITSO rendszerben

Certification Tanúsítás Audit Audit Specifications Specifikációk Regulations Rendeletek Security management Biztonság kezelése ISAMs ISAM-ok Registrar Nyilvántartó Product Owners Termék Tulajdonosok Shell Owners Shell Tulajdonosok Collection and Forwarding Operators Beszedő és továbbító üzemeltetők Licensed Members Jogosítvánnyal rendelkező tagok Shell Retailers Shell kiskereskedők Service Operators Szolgáltatás Üzemeltetők Product Retailers Termék Kiskereskedők Customers Vásárlók Mediaholders Média birtokosok


44

7.1 A biztonsági architektúra elemei

A biztonsági architektúra az alábbiakat tartalmazza: — az ITSO egyedi számozását; Shell-ek, Termékek és Tranzakciók;

— egy olyan számozási rendszert és gyökér nyilvántartást, amely interoperábilis a többi üzleti szektorral;

— Élettartamra szóló termék Pecsétek a szolgáltatás üzemeltető bizalmának megnyerése érdekében;

— Olyan kulcs letöltés, illetve átadás (rollover), mely szükséges tudni alapon engedélyezhető;

— Az off-line kiskereskedői kockázat kezelésére vonatkozó profilok;

— Veszteségmentes Tranzakció Kezelés;

— CM birtokos személyiségi jogai;

— új funkciók jövőben történő hozzáadási szolgáltatása.

Az alábbi alpontok egyesével leírják az architektúra minden egyes jellemzőjét.

2. Számozás és gyökér

Az összes ITSO Shell és az abban levő összes Termék, valamint az összes Tranzakció Rekord egyedileg van számozva a teljes ITSO Rendszerben. Ez az interoperábilis környezetben biztosítja az elszámoltathatóságot és a hihető audit nyomot. Az alkalmazott számozási rendszer gyökere egy Nemzetközi Kibocsátói Szám (International Issuer Number - IIN), mely nyilvántartásba van véve az ISO szabványoknak megfelelően. Ez biztosítja az ITSO egyediségét világszerte arra az esetre, ha az együtt szeretne működni hasonló rendszerekkel (az IOPTA ernyő alatt), illetve sok más olyan üzleti szektorral, amelyek használják már ezt a rendszert. Az ITSO számozás hierarchiáját szemlélteti a 8. ábra.

8. ábra – az ITSO számozás hierarchiája

Shell reference number world wide uniqueness Shell hivatkozási szám, világszerte egyedi Shells Shell-ek Serial number Sorozatszámok Check digit Ellenőrző számjegy


45

IPE reference number world wide uniqueness IPE referenciaszám, világszerte egyedi Products Termékek Product sequence number Termék sorszám Product owner ID Termék tulajdonos azonosító Transaction record world wide uniqueness Tranzakció rekord, világszerte egyedi Transactions Tranzakciók Transaction sequence number Tranzakció sorszám Service operator ID Szolgáltatás üzemeltető azonosító

3. Pecsétek és kulcsok

Minden egyes Termék legalább egy Pecsétet hordoz. A kriptográfiai “hitelességi garancia” hozzáadásra kerül a Termékhez annak első létrehozatalakor, és az a Termékkel együtt él a Termék egész életciklusa alatt. A Terméktulajdonos ellenőrzése alatt áll az, hogy mely tagok hozhatnak létre, illetve adhatnak hozzá Pecséteket a Termékekhez (kiskereskedők), és hogy mely tagok fogadhatják el és ellenőrizhetik a Termékeket (szolgáltatás üzemeltetők) azáltal, hogy utasítják a Biztonság Kezelő Szolgáltatást (Security Management Service - SMS) arra, hogy letöltse a szükséges kulcsokat. A Pecsétnek a használat időpontjában történő hitelesítése lehetővé teszi, hogy a szolgáltatás üzemeltető meggyőződjön arról, hogy a Termék valódi és azt jogtalanul nem módosították.

Megjegyzés: A rendszerszerte a különböző CM platformok eléréshez és a Könyvtár hitelesítéséhez használatos kulcsok terjesztése hasonló módon történik, azonban ez az ITSO Shell tulajdonosának rendelkezése alapján kerül kivitelezésre.

Az összes ITSO Termék és Könyvtár adatelem és struktúra össze van gyűjtve Adatcsoportokba, mely ezt követően kriptográfiailag le van pecsételve. Pecséteket csak az SSS generálhat. A pecsétet tartalmazó Adatcsoport struktúrát a 9. ábra szemlélteti.

9. ábra – Pecsétet tartalmazó adatcsoport struktúra

Label Címke The label: Identifies the owner and content of the Data Group

A címke: Beazonosítja az Adat Csoport tulajdonosát és tartalmát

Set of structures Struktúrák halmaza


46

Instance identifier Példány azonosító The Instance Identifier: Uniquely Identifies an instance of a Data Group (in a directory group it identifies the entity that last modified the directory)

A Példány Azonosító: Egyedileg beazonosítja egy Adat Csoport egy példányát (egy könyvtár csoporton belül beazonosítja azt az entitást, amely legutoljára módosította a könyvtárt)

Seal Pecsét The Seal: Provides a means of verifying the authenticity of all the other data in the Data Group, shown inside the dotted outline.

A Pecsét: Az Adat Csoport minden egyéb adata hitelességének ellenőrzésére egy eszközt biztosít, a pontozott körvonalon belül látható

Abban az esetben, amikor a Termékek tartalmaznak mind normál esetben rögzített, mind gyakran változó adatokat, a rögzített és változó adatstruktúrák külön-külön le vannak pecsételve, de egy közös Címkén osztozkodnak, ahogyan azt a 10. ábra szemlélteti.

10. ábra – Mind rögzített, mind változtatható adat struktúrákkal rendelkező Termék

Covered by Seal Pecséttel lefedve Seal Pecsét Instance identifier Példány azonosító Fixed structures Rögzített struktúrák Product Label Termék Címke Variable structures Változtatható struktúrák Covered by Seal Pecséttel lefedve

4. Profilok

A termék használati profilokat biztonságosan karbantartja minden egyes POST és letölthető egy HOPS-ról. E mechanizmus képessé teszi a Termék tulajdonosokat és a szolgáltatás üzemeltetőket, hogy egy adott POST ne legyen korlátozva, hanem például képes legyen arra, hogy:

— egyes Termékek kiskereskedőjeként járjon el, míg más termékek esetében nem;

— létrehozzon egy maximális számú szezonális jegyet újraindításig (reset);

— rendelkezzen engedéllyel ahhoz, hogy értéket adjon hozzá az STR Termékhez;

— értéket adjon hozzá az STR Termékhez egy maximális összesített értékig, újraindításig (reset).

Ez a mechanizmus biztosítja a nagy értékű termékek kiskereskedésére vonatkozó off-line műveletekkel, valamint az STR Termékhez történő érték hozzáadással járó kockázatok korlátozhatóságát.

5. Veszteségmentes tranzakció rekordok


47


48

A Tranzakció Rekord be van csomagolva és egyedileg van számozva egy Adat Kereten belül, majd le van pecsételve. Minden egyes Tranzakció Rekord hordozza a pecsételő készülék azonosítóját és egy sorozatszámot, amely eggyel növekszik minden egyes lepecsételt Tranzakció Rekorddal. A keretet fogadó HOPS ily módon ellenőrizheti a pecsétet az üzenet “hitelességének garanciájaként”. Biztonságosan karban van tartva egy Tranzakció Rekord köteg fejléc minden egyes létrehozott Tranzakció Rekord kötegre vonatkozóan, és meg van őrizve mindaddig, amíg egy “köteg törlése” kriptogram nem érkezik. A nem törölt kötegek azt jelzik, hogy a vonatkozó Tranzakció Rekordot újból el kell küldeni mindaddig, amíg a fogadó entitás nem lesz abban a helyzetben, hogy elfogadja a köteget. E mechanizmus segítségével felismerhető a hiányzó, módosított, duplikált és nem a sor szerint következő Tranzakció Rekordok. A “Nincs nálunk” üzeneteket a rendszer továbbítja a többi HOPS-hoz, ebben az esetben az eredeti Pecsét sértetlensége fenntartásra kerül auditálási célokból, és a továbbított Adat Keretet magát is lepecsételi a forrás HOPS.

6. CM birtokos személyiségi jogai

Azokban az esetekben, amikor az ITSO Shell Környezet Azonosító Szám (ITSO Shell Environment Identification Number - ISRN) a Tranzakció Rekord részét képezi, akkor az oly módon van titkosítva, hogy biztosítva legyen az, hogy csak az ITSO Shell tulajdonos tudja a Tranzakció Rekordot egy adott személyhez kapcsolni.

7. Új funkciók hozzáadása

Az SMS ki tudja osztani azokat a konfigurációs adatokat és programkódokat, amelyek lehetővé teszik a biztonsági környezet aktualizálását az alábbi események bekövetkeztekor:

— új CM hozzáférési módszerek hozzáadására kerül sor;

— új IPE változatok (design) bevezetésére kerül sor.

E mechanizmus biztonságos üzenetküldést használ a jogtalan (rossz-szándékú, illetve véletlen) módosítás felismerésének és annak biztosítása érdekében, hogy az információkat ne lehessen értelmezni a biztonságos környezeten kívül.

7.2 A biztonsági alrendszer (Security Sub-System - SSS)

A kívánt biztonsági architektúra megvalósítása érdekében az ITSO SSS-nek képesnek kell lennie arra, hogy megnyerje az összes rendszertag bizalmát és az alábbi jellemzőkkel kell bírnia: — Képesnek kell lennie kulcsok titokban tartására:

• a Termékek létrehozatala és ellenőrzése céljából;

• a Tranzakciók Lepecsételése céljából;

• a CM platformokhoz történő hozzáférés céljából;


49

• más entitásokkal történő biztonságos üzenetváltás végrehajtása céljából.

— Képesnek kell lennie arra, hogy olyan sorszám számlálókat tartalmazzon, amelyeket a POST nem tud módosítani, az alábbiak számára:

• Tranzakció Rekordok;

• az IPE-k érték rekordjainak aktualizálásai;

• biztonság monitorozás.

— Képesnek kell lennie arra, hogy konfigurációs és korlátozási adatokat tartalmazzon az alábbiak interoperabilitásának biztosítása céljából:

• Tranzakció köteg feldolgozás;

• off-line Termék létrehozatala és érték hozzáadása;

• alapvető POST funkcionalitás.

Ezeknek a követelményeknek csak oly módon lehet megfelelni, hogy az SSS egy feltörés-biztos készülékben van elhelyezve.

8. Az ISAM

Az ITSO SSS egy Biztonságos Alkalmazás Modul formájában kerül leszállításra, mely egy bővített memóriával rendelkező programozható intelligens kártya chipmodulból áll.

Az ITSO Biztonságos Alkalmazás Modul (ITSO Secure Application Module - ISAM) egy, a hagyományos bankkártyával azonos méretű kártya formájában kerül leszállításra, mely azonban rendelkezik a chipet tartalmazó eltávolítható résszel, melynek formája ugyanaz, mint az összes európai digitális mobiltelefonban található előfizető azonosító modul (SIM kártya). Ez pedig beilleszthető egy olyan szabvány aljzatba, amely kötelezően elő van írva az ITSO rendszer minden egyes POST-ja és HOPS-a számára.

Az ISAM formálisan értékelt és tanúsított Common Criteria EAL 4+ szinten, feltörés-biztos intelligens kártya és alkalmazás szempontjából.

Az ISAM modulok a POST, illetve a HOPS alkalmazás ellenőrzése alatt állnak, és az ITSO Alkalmazás biztonságos részét valósítják meg a CM-ek, Termékek, SMS üzenetek és HOPS üzenetek kezelésekor.

7.2.1.1 CM kezelés

Az ISAM a CM-mel a POST Alkalmazáson keresztül működik együtt az alábbiak biztosítása érdekében: — az ITSO által specifikált CM platformok megnyithatók legyenek hozzáférés céljából;

— a CM platformnak megfelelő kommunikációs munkaszakasz bekövetkezhessen;

— az ITSO Shell a munkaszakasz kezelés szerves részét képezze.


50

7.2.1.2 Termék kezelés

Az ISAM együttműködik a POST Alkalmazással az alábbiak biztosítása érdekében: — az ITSO Könyvtár hitelesség szempontjából ellenőrizhető legyen;

— bármely használatra szánt ITSO Termék hitelesség szempontjából ellenőrizhető legyen;

— az ITSO Termékek (például STR értékek) bárminemű módosítása csak engedély esetén legyen lehetséges, és az ilyen változtatások be legyenek azonosítva a POST szolgáltatás üzemeltető azonosítójával és újból le legyenek pecsételve;

— minden olyan ITSO Termék, melynek létrehozatala engedélyezett, egyedileg be legyen azonosítva a Termék tulajdonosok OID-jével, valamint egy sorszámmal, majd le legyen Pecsételve;

— az egy Termék kezeléséből eredő Könyvtár módosításokat le lehessen pecsételni.

7.2.1.3 SMS üzenet kezelés

Az ISAM együttműködik az SMS-sel a POST Alkalmazáson keresztül, egy biztonságos üzenetváltó rendszer felhasználásával. Ezek az üzenetek, amelyeket csak az SMS tud generálni, továbbításra kerülnek az ISAM-hoz, amikor az alábbiakra van szükség: — új, illetve megváltoztatott, a CM hozzáféréshez, illetve adatcsoport hitelesítéshez/Pecsét létrehozásához

használt kulcsok hozzáadása;

— a tranzakció információk generálásához használt kulcsok megváltoztatása;

— új, illetve módosított létező SSS funkciók hozzáadása;

— az SSS kiiktatása.

Az ISAM visszaigazolja belső konfigurációjának ezen változtatásait egy saját biztonságos üzenetével, amelyet ezt követően visszaküld az SMS-nek.

7.2.1.4 Az ISAM szerepe a POST üzenet kezelésben

Az egy POST-ba telepített ISAM együttműködik a HOPS-sal a POST Alkalmazáson keresztül többféle üzenetváltó rendszer felhasználásával.

Az ISAM az alábbi szolgáltatásokat biztosítja: — gondoskodik arról, hogy az egy ITSO Termék kezeléséből eredő minden egyes tranzakció rekord

beazonosításra kerüljön a POST üzemeltető azonosítója, valamint egy sorszám segítségével, és az le legyen pecsételve;

— konfigurációjától függően képes legyen arra, hogy tárolja ezeket a Tranzakció Rekordokat;

— gondoskodik a köteg fejlécek korrekt kezeléséről;

— a HOPS-tól származó utasítások alapján:

• új Termékek hozzáadhatók, illetve eltávolíthatók,

• változtatások eszközölhetők a Termékekkel használt elfogadási és kapacitási kritériumokat illetően;


51

— visszaigazolja a HOPS utasításaiból eredően a belső konfigurációjában történő változásokat, egy biztonságos üzenettel;

— gondoskodik arról, hogy a POST által kapott forró/akció lista üzenetek hitelesíthetők legyenek;

— képes tárolni forró/akció listákat;

— gondoskodik arról, hogy az általános olyan belső rendtartási üzenetek lepecsételhetők legyenek, amelyek nem képezik a Tranzakció Rekord üzenetváltó rendszer részét.

7.1.2.5 Az ISAM szerepe a HOPS üzenetkezelésben

Az egy HOPS-ba telepített ISAM együttműködik a POST-tal, illetve egy másik HOPS-sal, a HOPS Alkalmazáson keresztül.

Az ISAM gondoskodik az alábbiakról: — a POST-nak elküldésre kerülő, a Tranzakció Rekordok egy teljes kötegének fogadását visszaigazoló és a

köteg törlését kiváltó kriptográfiai törlési üzenetek generálhatók legyenek;

— a POST-nak küldött forró/akció lista üzenetek lepecsételhetők legyenek;

— a POST-nak küldött egyéb általános üzenetek lepecsételhetők legyenek;

— a POST-tól küldött általános üzenetek hitelesíthetők legyenek;

— a többi HOPS-nak küldött üzenetek lepecsételhetők legyenek;

— a többi HOPS-tól kapott üzenetek hitelesíthetők legyenek.

Emellett, amennyiben a HOPS Alkalmazás támogatja az eszközkezelési funkciót, az ISAM gondoskodik az alábbiakról: — a Termékek hozzáadását, illetve eltávolítását szolgáló biztonságos üzenetek generálhatók legyenek;

— a Termékkel használt elfogadási és kapacitási kritériumok változtatására vonatkozó üzenetek generálhatók legyenek;

— a POST-októl kapott biztonságos üzenet visszaigazolások hitelesíthetők legyenek.

8. Kommunikációk

Az ITSO környezeten belüli különböző entitások közti adatkommunikáció alapvető az ITSO által célul kitűzött interoperabilitás támogatásához. Az ITSO TS 1000-9 az adat és kommunikációs mechanizmusok számára egy olyan szintet definiál, amely lehetővé teszi robosztus, biztonságos és interoperábilis rendszerek létrehozását, leszállítását. A kötelezően előírt követelmények minimum szinten vannak tartva, ami a lehető legnagyobb teret biztosítja a berendezés szállítók számára, hogy felhasználják a létező technológiájukat és kommunikációs infrastruktúrájukat.

Az egyik legfontosabb definiált követelmény az, hogy az összes ITSO adatátvitelnek Alkalmazás szinten veszteségmentesnek kell lennie. Ez megköveteli azt, hogy egy üzenet küldőjének meg kell őriznie a továbbított adatokat, amíg egy pozitív visszaigazolást nem kap az üzenetre vonatkozóan. Amennyiben egy előírt időtartamon belül ilyen visszaigazolás nem érkezik, az eredeti üzenet ismételten továbbításra kerül.


52

Az ITSO üzenetek adattartalmát az ITSO TS 1000-6 definiálja. Az ITSO TS 1000-9 által teljes körűen definiált szabványos adatátviteli formátum az XML, bár ez nincs kötelezően előírva a POST és a HOPS közti kommunikációkra. A HOPS-ok peer-to-peer módon vannak hálózatba kötve, Virtuális Magán Hálózat (Virtual Private Network - VPN) felhasználásával. A VPN biztosítja a HOPS és az ITSO Biztonság Kezelő Rendszer (ITSO Security Management System - ISMS) közti kommunikációs infrastruktúrát is.

Az ITSO TS 1000-9 meghatározza az ITSO Alkalmazási Üzenetek struktúráját és elrendezését. Négy Alkalmazás Üzenet osztály van definiálva: — 0. osztály Pozitív visszaigazolási üzenet

— 1. osztály Köteg-orientált POST-tól HOPS-nak üzenet

— 2. osztály Általános keret-orientált üzenet

— 3. osztály ISAM biztonsági üzenet

A különböző üzenet osztályok használatára és feldolgozására vonatkozó szabályokat az ITSO TS 1000-9 definiálja.

A kommunikációs mechanizmusokat úgy tervezték, hogy lekezeljék az üzenetek biztonságos végpontok közti továbbítását, még akkor is, amikor az üzeneteknek rendszer-specifikus kommunikációs rétegeken keresztül kell áthaladniuk. A mechanizmusok megvédik az üzeneteket akkor is, amikor azok közbenső HOPS-okon keresztül kerülnek továbbításra végső célállomásukhoz.

A HOPS-ok között továbbított adatok titkosságát egy VPN használata biztosítja. A VPN szabványos adattitkosítást biztosít az összes rajta keresztül áthaladó adat számára. Azokban az esetekben, amikor a HOPS-ok közti kommunikáció nem használ VPN-t, a rendszer tulajdonos/üzemeltető felelőssége az, hogy gondoskodjék arról, hogy a HOPS-ok között továbbított adatok titkossága biztosítva legyen. A POST és a hozzátartozó HOPS közti szokásos üzemeltetési adatcsere szempontjából, a rendszer üzemeltető a felelős az adatok titkosságának biztosításáért.

A továbbított adatok sértetlenségét az biztosítja, hogy minden egyes olyan Adat Keret esetében Pecsét használatára kerül sor, amely egy Alkalmazás Üzenetet alkot.

Az átvitt adatok hitelességét az biztosítja, hogy minden egyes olyan Adat Keret esetében egy Sorozatszám, egy Pecsét Azonosító (SealerID) és egy Pecsét kerül alkalmazásra, amely egy Alkalmazás Üzenetet alkot.

Az átvitt adatok letagadhatatlanságát az biztosítja, hogy minden egyes olyan Adat Keret esetében egy Időbélyegző, egy Pecsét Azonosító és egy Pecsét kerül felhasználásra, amely egy Alkalmazás Üzenetet alkot.


53

A kommunikációs architektúra lehetővé teszi kulcsok és egyéb biztonsággal kapcsolatos adatok biztonságos átvitelét az ISMS, az Eszköz Kezelő Rendszerek (Asset Management Systems - AMS) és az ISAM-ok között.

9. ITSO adat üzenetek

Az Adat Üzenet definíciókat általánosságban a specifikáció 6. része tartalmazza. Azonban a biztonságos kezeléssel kapcsolatos üzeneteket a specifikáció 8. része definiálja.

A 3. táblázat a 6. részben definiált üzenet típusokat foglalja össze.

3. táblázat - ITSO üzenet típusok

Üzenet típus Üzenet Csoport

Tranzakció Rekord adatok ITSO shell, IPE Adminisztráció, Kártya kibocsátó üzenetek

Tranzakció Rekord adatok Tárolt Utazási Jogok, CTA

Tranzakció Rekord adatok ITSO ID, hűség, IPE létrehozatala, illetve módosítása, utazási rekord, akció lista visszaigazolás

Tranzakció Rekord adatok Törlések és visszatérítések, egyéb, lista párosító esemény rekordok (list match event records)

Egyéb Üzenet Adatok Kivételek és CM Tranzakció hibaüzenetek (POST-tól a HOPS felé)

Egyéb Üzenet Adatok POST-tól a HOPS felé irányuló lekérdezések

Egyéb Üzenet Adatok HOPS-tól HOPS felé irányuló üzenetek

Egyéb Üzenet Adatok Olyan AMS – ISMS üzenetek, amelyeket az ITSO TS 1000-8 definiál

HOPS-tól POST/HOPS-nak üzenetek

Egyéb üzenetek


Üzenetek kontrollja


Paraméter táblázatok


Paraméter táblázatok


Interoperabilitási lista, Képesség lista, Forró Lista, Akció Lista, Adat Kapcsolat rekord


54


POST lekérdezésekre vonatkozó HOPS Válasz

Felhasználó által definiált rendszer specifikus üzenetek

Az üzeneteket a felhasználó definiálja és a küldő felelőssége az, hogy gondoskodjék arról, hogy a címzett értelmezni tudja az üzenetet.

Mind az adatformátumot, mind a tartalmat a felhasználó határozza meg.

elektra hungaria 3 tudástár/eh3/v_elektra_3.0... · elektra hungaria 3.0 bemutatása huntrust...

Documents