MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Systém elektronických plateb Diplomová práce
Bc. Lenka Zaoralová Brno, jaro 2009
Kopie listu zadání práce
Strana 2
Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracovala samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používala nebo z nich čerpala, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
V Brně dne 13. května 2009
__________________________ podpis
Strana 3
Tímto bych ráda poděkovala doc. RNDr. Václavu Matyášovi, M.Sc., Ph.D. za jeho čas, rady, trpělivost, vstřícnost a velmi rychlé reakce na mé dotazy při vedení této diplomové práce. Též bych chtěla poděkovat své rodině a přátelům za podporu, která mi ve všech stádiích mého studia pomohla zůstat životní optimistkou
Strana 4
Shrnutí Tato diplomová práce se zabývá problematikou elektronických plateb. V první části práce je podrobně popsán obsah EMV specifikace, což je de facto standard pro použití čipových platebních karet zajišťující interoperabilitu a přijímaní čipových karet na platebních terminálech v celosvětovém měřítku. Téma EMV specifikace je zpracováno formou vhodnou pro rychlé studium dané problematiky. V rámci praktické části je popsán princip fungování 3-D Secure systému a je implementován systém elektronických plateb ve webovém klientovi informačního
systému
pro
sportovní
centra
pracující
s
3-D
Secure
systémem
implementovaným Českou spořitelnou. V závěru práce je navrženo rozšíření této implementace takovým způsobem, aby vzniklý systém umožnil provádění elektronických plateb přes třetí stranu, která zprostředkovává platby mezi sportovním centrem a Českou spořitelnou.
Klíčová slova EMV specifikace, Visa International, MasterCard International, JBC International, Europay International, čipové karty, elektronické platby, online platby kartou, 3-D Secure, informační systém pro sportovní centra, Verified by Visa, MasterCard SecureCode, E-commerce.
Strana 5
Obsah 1 Úvod...................................................................................................................................................7 2 Úvod do EMV specifikace...............................................................................................................8 3 Kniha první: Požadavky kladené při použití čipové karty na rozhraní terminálu ...............10 3.1 Elektromechanické charakteristiky, logická rozhraní a přenosové protokoly................11 3.2 Soubory, příkazy a výběr aplikace.......................................................................................20 4 Kniha druhá: Bezpečnost a správa klíčů......................................................................................21 4.1 Bezpečnost a správa klíčů......................................................................................................22 5 Kniha třetí - Specifikace aplikačního protokolu..........................................................................32 5.1 Datové elementy a příkazy....................................................................................................33 5.2 Specifikace debetních a kreditních aplikací.........................................................................36 6 Kniha čtvrtá - Požadavky kladené na držitele karty, obsluhu a rozhraní nabyvatele ..........40 6.1 Obecné požadavky.................................................................................................................41 6.2 Architektura softwaru............................................................................................................45 6.3 Požadavky kladené na držitele karty, obsluhu a rozhraní nabyvatele............................47 7 Implementace elektronických plateb 3-D Secure do informačního systému pro sportovní centra....................................................................................................................................................50 7.1 Popis aplikací..........................................................................................................................50 7.2 3-D Secure................................................................................................................................51 7.3 Informační systém pro sportovní centra..............................................................................61 7.4 Implementace 3-D Secure řešení České spořitelny do systému Clubspire......................64 7.5 Návrh aplikace EPSYS............................................................................................................69 8 Závěr................................................................................................................................................72
Strana 6
1 Úvod Život bez takové samozřejmosti jakou je platební karta si v současné době většina z nás už ani neumí představit. Použití platební karty přináší jejímu majiteli celou řadu výhod. Ať už se jedná o pohodlí při jejím použití, možnost okamžitého disponování větším objemem finančních prostředků bez nutnosti mít tyto prostředky u sebe v hotovosti, možnost přečerpání účtu, či plateb v prostředí internetu a další. Masivní odklon od používání papírových bankovek a kovových mincí k platebním kartám je již dlouhou dobu stimulován jak ze strany finančních ústavů, tak i obchodníků, kterým použití elektronických peněz přináší mimo jiné nemalé úspory plynoucí z absence nutnosti manipulace s hotovými finančními prostředky. Nutno poznamenat, že tento trend s sebou nese pro všechny zúčastněné mnohá pozitiva, ale na druhou stranu přináší problémy, které je třeba efektivně řešit. Požadavek zajištění akceptace platebních karet na platebních terminálech v celosvětovém měřítku vedl tři největší karetní společnosti k vytvoření EMV specifikace, která se v oblasti čipových karet stala de facto standardem. Nutno zdůraznit, že EMV specifikace se zabývá „pouze“ problematikou použití čipových karet v platebních systémech a platební karty vybavené magnetickým proužkem jsou mimo doménu jejího zájmu, protože neumožňují stejnou míru zabezpečení jako karty s čipem. Větší část této diplomová práce se zaměřuje právě na EMV specifikaci, zmiňuje pozadí jejího vzniku, současný stav a ve čtyřech kapitolách shrnuje poznatky z jednotlivých knih EMV specifikace. Tato část poskytuje čtenáři možnost rychlého studia problémové oblasti pokryté EMV specifikací v českém jazyce. Ve druhé části této práce je popsána problematika 3-D Secure protokolu, který slouží pro eliminaci rizika zneužití platební karty neoprávněnou osobou v prostředí online plateb. Zároveň je popsána implementace online plateb v rámci 3-D Secure systému České spořitelny do informačního systému pro sportovní centra Clubspire a návrh možného budoucího rozšíření této aplikace tak, aby umožňovala provádění online plateb přes třetí stranu.
Strana 7
2 Úvod do EMV specifikace V únoru roku 1999 se společnosti VISA International, MasterCard International a Europay International rozhodly vytvořit společnost EMVCo LLC, která měla zastřešovat jejich společné aktivity zabývající se řízením, správou a rozšiřováním EMV specifikace. Samotná EMV specifikace čipových karet pro platební systémy (EMV Integrated Circuit Card Specifications for Payment Systems) - dále jen EMV specifikace, vznikla jako de facto standard těchto karetních společností, který zajišťuje interoperabilitu a přijímaní čipových karet na platebních terminálech v celosvětovém měřítku. EMVCo má v současné době tři členské společnosti: MasterCard Worlwide (vznikla spojením společností MasterCard International a Europay International v roce 2002), Visa International a JCB International, která se ke dvojici původních zakladatelských společností připojila v roce 2004. Každá z těchto společností vlastní třetinu EMVCo a jejich zástupci tvoří jednotlivé organizační složky a pracovní skupiny společnosti. EMVCo je též zodpovědná za aprobaci a testování kompatibility platebních terminálů a platebních karet s EMV specifikací. Důležitost testovacího procesu leží především v záruce, že konkrétní terminál a karta jsou vyvíjeny na úrovni, která zajistí požadovanou interoperabilitu v rámci (EMV kompatibilního) platebního systému. EMV specifikace byla tvořena na základě již existující řady standardů ISO 7816, což je série standardů pro čipové karty, konkrétně karty obsahující integrovaný obvod s (elektrickými) kontakty. Zatímco však tyto ISO standardy byly vytvořeny skupinou průmyslových partnerů a proto zahrnují prvky aplikovatelné pouze v určitém odvětví, při vytváření EMV specifikací probíhala čilá komunikace mezi reprezentanty EMVCo a autory ISO konceptů, aby byla zaručena plná kompatibilita mezi EMV specifikacemi a ISO standardy. EMV specifikace používá vybrané prvky standardu ISO 7816, které se vztahují k problematice finančnictví. V současné době (jaro roku 2009) je EMV specifikace dostupná v nejnovější verzi 4.2, která byla oficiálně publikována v červnu 2008. Samotná specifikace je rozdělena do 4 oddílů/knih. Každá z těchto knih pojednává o jedné samostatné oblasti popisované problematiky, kterou podrobně rozebírá. Konkrétně se jedná o následující knihy: •
Kniha první - Požadavky kladené při použití nezávislé čipové karty na rozhraní terminálu (Application Independent ICC to Terminal Interface Requirements).
Strana 8
•
Kniha druhá - Bezpečnost a správa klíčů (Security and Key Management).
•
Kniha třetí - Specifikace aplikačního protokolu (Application Specification).
•
Kniha čtvrtá - Požadavky kladené na držitele karty, obsluhu a rozhraní nabyvatele (Cardholder, Attendant, and Acquirer Interface Requirements).
Jednotlivým knihám jsou věnovány následující čtyři kapitoly. Každá kapitola obsahuje informace čerpané z odpovídající knihy EMV standardu.
Strana 9
3 Kniha první: Požadavky kladené při použití čipové karty na rozhraní terminálu Tato kniha [1] popisuje minimální množinu funkcí, které musí být poskytovány ze strany dvou základních stavebních prvků celého systému, a to čipové karty a terminálu. Tato množina funkcí je nutnou podmínkou jejich správné činnosti a interoperability nezávisle na aplikaci, která je použita. Kniha je rozdělena do pěti kapitol následujících kapitol: 1. Obecný úvod – obsahující terminologii a seznam použitých zkratek. 2. Elektromechanické charakteristiky, logická rozhraní a přenosové protokoly – tato kapitola
obsahuje
podrobné
informace
o
mechanických
a
elektrických
charakteristikách čipových karet a terminálů, dále popis karetních relací a detaily týkající se přenosu dat a přenosových protokolů. 3. Soubory, příkazy a výběr aplikace – kapitola pojednávající o souborovém systému, existujících příkazech. 4. Přílohy – příklady použití, tabulka datových elementů, příklady souborové struktury 5. Common Core Definitions – volitelná rozšíření. Protože kapitoly 2 a 3 obsahují stěžejní informace a požadavky týkající se EMV specifikace budou popsány v následujících samostatných kapitolách. Aby nedošlo k chybné interpretaci některých
základních
termínů,
považuji
za
důležité
uvést
následující
definice
4 nejdůležitějších hardwarových prvků dle EMV specifikace: ●
čip, též integrovaný obvod – v originále Integrated Circuit (IC) – elektronická komponenta, která je určena ke zpracování informací a (nebo) slouží jako paměť;
●
čipová karta – v originále Integrated Circuit(s) Card (ICC) – karta se zabudovaným čipem (popř. více čipy), který slouží k provádění operací a (nebo) jako paměť;
●
terminál – zařízení, které je spolu s čipovou kartou použito pro provedení finanční transakce. Terminál má v sobě zabudovanou čtečku čipových karet a může dále obsahovat další komponenty např. pro komunikaci s obsluhou je to typicky klávesnice;
●
čtečka čipových karet na terminálu – je to součást terminálu, do níž je vkládána čipová karta. Součástí čtečky mohou být jak mechanická, tak elektrická zařízení.
Strana 10
3.1
Elektromechanické charakteristiky, logická rozhraní a přenosové
protokoly 3.1.1
Elektromechanická rozhraní
Tato sekce obsahuje mechanické a elektrické charakteristiky čipových karet a terminálů. Splnění těchto charakteristik je základním předpokladem pro zapojení daného zařízení do EMV platebního systému, přičemž charakteristiky karet a terminálů se liší, tím vzniká bezpečnostní zóna, která předchází zničení čipové karty při jejím použití na terminálu v ne zcela standardních podmínkách. EMV charakteristiky čipových karet vychází ze série standardů ISO/IEC 7816. Kapitoly odkazované v následujícím textu jsou kapitoly EMV specifikace.
Přechod na čipové karty s nižším napájecím napětím V současné době probíhá přechod na čipové karty vyžadující nižší napájecí napětí. Přehled existujících tříd čipových karet relevantních z pohledu EMV specifikace je následující: ●
karta třídy A pracuje při napájecím napětí v rozmezí 4,5 – 5,5 V (tzn. 5 V ± 0,5 V),
●
karta třídy B pracuje při napájecím napětí v rozmezí 2,7 – 3,3 V (tzn. 3 V ± 0,3 V),
●
karta třídy C pracuje při napájecím napětí v rozmezí 1,62 – 1,98 V (tzn. 1,8 V ± 0,18 V).
Karty, které podporují pouze třídu A, budou staženy z oběhu do konce prosince 2013. Od ledna 2014 bude nutné, aby všechny karty v oběhu podporovaly třídu AB, popř. ABC. Od stejného data bude možné nasadit do ostrého provozu terminály akceptující pouze karty třídy B (k již existujícím terminálům třídy A). Je potřeba podotknout, že EMV specifikace nepočítá s existencí karet tříd B, C, BC, AC (z důvodů zpětné kompatibility nových čipových karet a starších terminálů).
Strana 11
Mechanické charakteristiky čipových karet Mechanické charakteristiky čipových karet popisují fyzikální charakteristiky, rozřazení kontaktů a jejich mechanickou odolnost. Kromě charakteristik explicitně definovaných v EMV specifikaci musí čipové karty též splňovat fyzikální parametry pro čipové karty definované ve standardu ISO/IEC 7816-1. EMV specifikace vyžaduje, aby každá čipová karta splňovala následující požadavky: ●
Nejvyšší a nejnižší bod embosovaného textu na čipové kartě nesmí být od povrchu karty vzdálen více než 0,10 mm.
●
Rozměry, umístění a přiřazení kontaktů musí odpovídat následujícímu obrázku, přičemž je nutné, aby byly kontakty C1, C2, C3, C5 a C7 pokryty vodivou vrstvou (v obrázku zvýrazněny orámováním). Je třeba ještě poznamenat, že kontakt C6 byl v ISO/IEC 7816-3:1997 rezervován pro programovací napětí třídy A.
Obrázek 3.1: Umístění a přiřazení kontaktů na čipové kartě (upraveno z [1])
Strana 12
Elektrické charakteristiky čipových karet Tato sekce je věnována elektrickým charakteristikám signálu, které jsou měřeny na kontaktech čipu karty. Pro veškerá měření je předpokládána teplota okolního prostředí v rozmezí 00 – 500 C, měření probíhá v místě dotyku uzemňovacího kontaktu čipové karty a rozhraní terminálu a čipová karta musí být při těchto teplotách schopna pracovat bezchybně. Jednou z podmínek, kterou musí čipové karty splňovat, je fakt, že čipové karty nesmí vyžadovat programovací napájení. Nutno ještě podotknout, že každý kontakt určený pro přijímaní popř. i vysílaní signálu (dat) musí být schopen rozlišovat dvě základní úrovně napětí, reprezentující používané logické hodnoty (0 a 1). V následujícím textu jsou tyto dvě úrovně napětí zmiňovány jako vysoká úroveň napětí a nízká úroveň napětí. Interpretace těchto hodnot na nuly a jedničky už je ovšem záležitostí rozhodnutí výrobce čipové karty. Jednou z důležitých skutečností, které jsou EMV specifikací verze 4.2 ošetřeny, je výše zmiňovaný přechod na čipové karty s nižším napájecím napětím. Pro tyto účely jsou některé charakteristiky uvedeny ve dvou verzích. První je platná pro karty třídy A s platností do konce prosince 2013, kdy by karty této třídy měly být definitivně staženy z oběhu a druhá hodnota je platná pro ostatní třídy karet(AB, ABC) a je závazná pro všechny karty od ledna roku 2014. Vstupně/výstupní (I/O) kontakt na čipu, jak sám název napovídá, je využíván k přenosu dat mezi čipovou kartou a terminálem. Pro přijímání a odesílání dat jsou nadefinovány dva režimy, a to přijímací a transportní režim. Během práce s čipovou kartou nesmí být v jednom okamžiku čipová karta i terminál v transportním režimu. Pokud taková situace nastane, stav (úroveň napětí) na kontaktu je detekován jako neurčitelný, zároveň nesmí v takovém případě dojít k jakémukoliv poškození čipové karty. Čipová karta nesmí být též poškozena, pokud vyskytne odchylka vstupního nebo výstupního signálu do ±0,3 Voltů. Dále je nutné, aby čas přechodu signálové amplitudy z 90 % na 10 % (fall time) a z 10 % na 90 % (raise time) trval maximálně 1 mikrosekundu. Přijímací režim – pokud je I/O kontakt čipu v přijímacím režimu, pak by čipová karta měla správně interpretovat signály přijímané z terminálu, které odpovídají nadefinovaným charakteristikám (kapitola 5.3.2.1 z [1]). Vysoká i nízká úroveň vstupního napětí jsou nadefinovány vzhledem k napájecímu napětí čipové karty, které je dáno její příslušností k určité třídě (A, B nebo C).
Strana 13
Transportní režim. Čipová karta, pokud je v transportním režimu, musí na rozhraní terminálu zasílat data splňující charakteristiky nadefinované v [1] v kapitole 5.3.2.2 opět vztažené k napájecímu napětí dané třídou karty. V některých případech jsou též omezeny výše výstupního el. proudu a kapacitní odpor terminálu. Kontakt na čipu určený pro hodiny musí pracovat se signálem splňujícím charakteristiky vysoké a nízké úrovně napětí uvedené v [1] v kapitole 5.3.4, přičemž čas přechodu signálové amplitudy z 90 % na 10 % (fall time) a z 10 % na 90 % (raise time) musí trvat maximálně 9 % hodinové periody. Čipová karta musí být schopná správného fungování při frekvenci signálu hodin od 1MHz do 5MHz a i při odchylce délky jednoho hodinového cyklu (tiku) do ± 6 % oproti běžnému hodinovému tiku. Signál přijatý na reset kontaktu čipové karty musí být správně interpretován, pokud odpovídá charakteristikám uvedeným v [1] v kapitole 5.3.5. A zároveň nesmí být karta poškozena pokud dojde k odchylce napětí ±0,3 V. Čipové karty na signál reset musí reagovat asynchronně s použitím „active low reset“ (tzn. terminál vyvolá reset karty přechodem z nízké úrovně napětí na kontaktu reset na vysokou úroveň). Dále je nutné, aby čas přechodu signálové amplitudy z 90 % na 10 % (fall time) a z 10 % na 90 % (raise time) trval maximálně 1 mikrosekundu. Kontakt napájecího napětí slouží pro přívod napájení umožňující fungování čipové karty. Dle úrovně napájecího napětí byly nadefinovány následující 3 třídy čipových karet: ●
Třída A – napájecí napětí v rozmezí 4,5 – 5,5 V (tzn. 5 V ± 0,5 V), max. elektrický proud 50 mA,
●
Třída B – napájecí napětí v rozmezí 2,7 – 3,3 V (tzn.3,0 V ± 0,3 V), max. elektrický proud 50 mA,
●
Třída C - napájecí napětí v rozmezí 1,62 – 1,98 V (tzn.1,8 V ± 0,18 V), max. elektrický proud 30 mA.
Maximální okamžitá spotřeba (horní limit napájecího napětí) platí pro fungování karty na všech povolených frekvencích hodin. Konkrétní čipová karta musí podporovat třídu A a případně i jednu nebo obě následující třídy (tzn. existující povolené kombinace jsou A, AB, ABC a žádné jiné). V případě, že karta podporuje vícero tříd může (ale nemusí) správně fungovat i při úrovni napětí ležící mezi povolenými intervaly (pro kombinaci tříd AB je toto „dobrovolné“ rozmezí 3,30 – 4,50 V (tzn. maximum třídy B – minimum třídy A). V případech, kdy čipová karta i terminál podporují více tříd, může terminál podporovat funkci Strana 14
vyjednávání ohledně úrovně napětí, která bude použita. Tato funkce není na straně karty ani terminálu v EMV specifikaci nijak podporována. Poslední požadavek týkající se elektrických charakteristik čipových karet se týká odporu. Vzájemný odpor kontaktů měřený mezi kontakty na čipu karty a kontakty čtečky terminálu musí být nižší než 500 mΩ.
Mechanické charakteristiky terminálu Čtečka na terminálu musí být schopná akceptovat čipové karty odpovídají standardu ISO/IEC 7816-1, jejíž kontakty jsou rozmístěny dle obrázku č. 3.1 (kontakty C1 a C8 nemusí být fyzicky přítomny) a jejíž embosovaný text odpovídá ISO/IEC 7811-1 a ISO/IEC 7811-3. Zároveň síla vyvíjená na kontakty čipové karty ve čtečce musí odpovídat rozmezí 0,2 N až 0,6 N a přiřazení kontaktů odpovídá přiřazení kontaktů na čipové kartě (obrázek č. 3.1).
Elektrické charakteristiky terminálu Vstupně/výstupní kontakt terminálu stejně jako u čipové karty podporuje přijímací a transportní režim. Terminál nesmí nastavit vysokou úroveň napětí na tomto kontaktu až do doby, kdy je napájecí napětí karty stabilně nastaveno na hodnotu spadající do rozmezí požadovaného pro danou třídu karet. Data zasílaná terminálem v transportním režimu na čipovou kartu musí odpovídat charakteristikám uvedeným v [1] v kapitole 5.5.2.1. Pokud terminál neposílá data, musí nastavit I/O kontakt do přijímacího režimu. Při přijímání dat je třeba, aby I/O kontakt terminálu byl schopen zpracovávat data odpovídající charakteristikám kapitoly 5.5.2.2 v [1]. Kontakt C6 rezervovaný pro budoucí použití musí být elektricky izolován od ostatních kontaktů (tzn. odpor mezi těmito kontakty při napájení 5 V musí být větší než 10 MΩ). Signál reset generovaný terminálem musí odpovídat popisu v kapitole 5.5.3 v [1]. Terminál musí generovat též hodinový signál, který odpovídá předpisu uvedeném v [1] v kapitole 5.5.4. Frekvence hodinového signálu musí v rozmezí od 1MHz do 5MHz a od vložení karty do čtečky (odpovědi na reset) do konce karetní relace se smí změnit jen o ±1 %. Kontakt pro napájení karty. Terminál musí být schopen generovat a čipové kartě dodávat stabilní napájecí napětí odpovídají třídě čipové karty. Pokud terminál podporuje více než jednu třídu, musí vždy generovat napájecí napětí třídy s nejvyššími požadavky. Dodávky Strana 15
napětí musí být chráněny proti rušení pocházejícímu jak zevnitř, tak z vnějšku terminálu. Rozmezí napájení poskytovaného jednotlivým třídám karet odpovídá intervalům, které jsou kartami očekávány s tím rozdílem, že maximální a minimální hodnota se o 2 % více blíží střední hodnotě. Toto opatření má za následek to, že čipové karty jsou schopné akceptovat širší interval hodnot napětí, než terminál generuj. Tím se vytváří malá bezpečnostní zóna pro případné anomality. Terminál nesmí být poškozen a nesmí přestat fungovat korektně ani v případě zkratu mezi libovolnými kontakty, přičemž zkrat se může vyskytovat po jakkoliv dlouhou dobu.
Strana 16
3.1.2
Karetní relace
Běžná karetní relace probíhající bez problémů se sestává z následujících kroků: 1. Vložení čipové karty do čtečky na terminálu, připojení a aktivace kontaktů. 2. Reset čipové karty a ustavení komunikace mezi čipovou kartou a terminálem 3. Provedení jedné případně i více transakcí. 4. Deaktivace kontaktů a vyjmutí čipové karty ze čtečky terminálu.
Vložení čipové karty do čtečky (na rozhraní) na terminálu, připojení a aktivace kontaktů. Při vložení čipové karty do čtečky terminál zajistí, aby všechny kontakty byly ve stavu nízké úrovně napětí, jehož hodnota odpovídá specifikaci karty. Když je čipová karta správně umístěna ve čtečce, terminál vyšle reset signál, čímž nastaví na všech kontaktech čipu karty nízkou hodnotu napětí a karta je připojena na zdroj napájení. Následuje terminálem prováděné ověření, že napájecí napětí je stabilní a má hodnotu odpovídající třídě karty, I/O kontakt terminálu je nastaven na přijímací režim a terminál začne vysílat hodinový signál.
Reset čipové karty Čipová karta musí na reset odpovědět asynchronně řetězcem bajtů, tento řetězec nese terminálu informace o tom, jak nastavit některé charakteristiky komunikace mezi jím a čipovou kartou. EMV specifikace rozlišuje dva typy resetu – studený a horký reset. Studený reset probíhá následovně: terminál v určitém okamžiku nastaví I/O na přijímací režim, poté vyšle signál reset (nastaví na kontaktu reset vysokou úroveň napětí) a do 400 až 40000 tiků hodin by karta měla začít odpovídat tzn. zasílat řetězec bajtů jako odpověď, přičemž I/O kontakt terminálu je schopen přijímat tento signál. V případě, že odpověď na reset od karty v daném čase nepřijde, provede se tzv. horký reset. Horký reset se vždy provádí až po neúspěšném provedení studeného resetu a liší se především v úrovni napětí na reset kontaktu. V okamžiku, kdy se napětí na reset kontaktu přepne zpět na nízkou úroveň napětí a nastaví se I/O terminálu na přijímací režim. Poté se reset v rámci 40000 – 45000 hodinových tiků opět přepne na vysokou úroveň napětí (vyšle signál reset kartě) a do 400 až 40000 tiků hodin by karta měla začít odpovídat.
Strana 17
Provedení transakce, deaktivace kontaktů a vyjmutí čipové karty ze čtečky Podrobný postup provádění transakcí je uveden až ve třetí knize EMV specifikace, zde je popsána pouze deaktivace kontaktů. Ta probíhá vždy jako poslední krok karetní relace, ať už relace proběhla běžným způsobem a skončila úspěšně nebo ne. Terminál iniciuje deaktivaci kontaktů nastavením resetu na nízkou úroveň napětí. Poté jsou stejným způsobem nastaveny kontakty hodin a I/O kontakt. Nakonec je vypnuto i napájení. Celý proces deaktivace musí proběhnout v rámci 100 ms od přepnutí resetu do vypnutí napájení. Po deaktivaci kontaktů může být čipová karta ze čtečky vyjmuta. V případě, že je karta nečekaně vyjmuta ze čtečky při provádění transakce (je vyjímána rychlostí do 1 m/s), terminál musí být schopen toto detekovat a deaktivovat všechny kontakty dřív, než se karta posune o 1 mm, přičemž nesmí dojít k žádnému poškození karty.
3.1.3
Fyzický přenos znaků
Při zpracování finanční transakce probíhá přenos dat mezi čipovou kartou a terminálem přes I/O kontakt s použitím střídavého obousměrného (half duplex) přenosu dat (tzn. v jednom okamžiku je vždy jedna strana přijímač a druhá vysílač). Časování přenosu má na starosti terminál, přičemž délka jednoho bitu je lineárně závislá na použité frekvenci. Při zpracování odpovědi na reset po vložení karty do čtečky je délka jednoho bitu nastavena na výchozí hodnotu, která je rovna podílu čísla 372 a použité frekvence v sekundách. Po zpracování odpovědi na reset od karty je tento čas upraven v závislosti na hodnotách, které přišly v odpovědi od karty. Samotný přenos dat probíhá v blocích délky 10 bitů, přičemž první bit je tzv. startovací bit, následuje posloupnost 8 bitů přenášených dat (1 znak) a nakonec 1 paritní bit (počet logických 1 musí být sudý, přičemž startovací bit není brán v potaz). Startovací bit na I/O lince je detekován pravidelným vzorkováním této linky (čas snímání vzorku musí být nejvýše 0,2násobek délky bitu). Poté následuje vlastní přenos dat (1 znaku), který je následován tzv. ochranným intervalem, kdy jsou jak karta, tak terminál nastaveni na I/O kontaktu na přijímací režim, aby nedocházelo k překrývání jednotlivých přenesených bloků.
Strana 18
3.1.4
Odpověď na reset
Poté, co provede terminál reset karty, musí karta poslat jako reakci na tento reset tzv. odpověď na reset, což je posloupnost znaků sloužící k nastavení některých volitelných parametrů jejich vzájemné komunikace. Tato odpověď musí být kartou kompletně odeslána nejpozději do limitu 19200 násobku výchozí délky bitu. Formát vlastní odpovědi je závislý na použitém přenosovém protokolu, který musí být dohodnut a podporován oběma stranami. Čipové karty mohou podporovat více přenosových protokolů, ale dle EMV specifikace právě jeden z nich musí být buď T=0, a nebo T=1. V případě, že je použit znakově orientovaný asynchronní přenosový protokol T=0, pak v odpovědi karty na reset jsou 2 nebo 4 znaky, z toho jeden znak pro určení pořadí bitů ve znaku, příznak pro existenci následujících dvou znaků, příznak indikující, že programovací napájení není vyžadováno, a příznak indikující požadavek na zvýšení ochranného intervalu. V případě použití blokově orientovaného asynchronního přenosového protokolu T=1 jsou první bity odpovědi stejné jako u protokolu T=0 a dále následuje 5 dalších znaků, z nichž za zmínku stojí znak pro nastavení délky bloku v rozmezí 16 – 256 bajtů a znak určení typu paritního testu. V [1] v kapitole 8.3 je možné nalézt podrobný soupis všech existujících znaků jejich význam a přípustné hodnoty. Terminál zpracovávající odpověď karty může tuto odpověď příjmout, popř. odmítnout, pokud se vyskytne paritní chyba nebo odpověď nepřijde celá včas. Pokud byla odpověď odmítnuta při studeném resetu provede se ještě horký reset. Pokud ani odpověď na horký reset nepřijde v pořádku, čipová karta je terminálem odmítnuta a jsou deaktivovány kontakty karty.
3.1.5
Přenosové protokoly (fyzická, datová vrstva, terminálová transportní
vrstva) Princip přenosu bitů platný na fyzické vrstvě byl již podrobně popsán v kapitole 3.1.1 Fyzický přenos znaků. Protokoly týkající se spojové vrstvy (Data link layer) se starají především o definování výměny znaků společných pro oba transportní protokoly T=0 i T=1, dále definování výměny znaků specifických pro každý ze z míněných protokolů a definování detekce a korekce chyb způsobených přenosem. Principy týkající se spojové vrstvy jsou na Strana 19
velmi nízké implementační úrovni (definice hodnot přenášených znaků apod.) a tudíž je ponechávám případnému zájemci k samostudiu (kapitola 9.2 v [1]). Transportní terminálová vrstva (Terminal Transport Layer) se stará o mechanismus zpracování příkazů posílaných terminálem čipové kartě, jejich zpracování čipovou kartou a odeslání odpovědi (aktuálního stavu) zpět na terminál. Základní princip fungování tohoto mechanismu je takový, že terminál řídí veškerou vzájemnou komunikaci a jako jediný smí zasílat příkazy. Poté, co terminál zašle příkaz v určeném formátu s případnými potřebnými parametry čipové kartě, karta příkaz zpracuje a poté zašle terminálu zprávu o svém stavu, pokud je vše v pořádku terminál zašle příkaz GET RESPONSE pro získání výsledku. Definice hlaviček zpráv obsahujících příkaz nebo odpověď jsou závislé na použitém transportním protokolu a EMV specifikace je podrobně definuje pro T=0 i T=1 v [1] v kapitole 9.3. Aplikační vrstva se skládá z uspořádané množiny zpráv zpráv typu příkaz-odpověď, které jsou Transportní terminálovou vrstvou přenášeny mezi kartou a terminálem. Každá zpráva reprezentující příkaz obsahuje povinnou hlavičku a případně nepovinné tělo zprávy, které obsahuje další informace potřebné pro provedení příkazu. Každá zpráva reprezentující odpověď se skládá z těla, obsahujícího přenášená data a traileru obsahujícího informaci o aktuálním stavu zpracování příkazu
3.2
Soubory, příkazy a výběr aplikace
Tato kapitola obsahuje podrobný popis organizace souborů na čipové kartě, detailní popis struktury zpráv obsahující jednotlivé příkazy (read record, select) a popis postupu při výběru aplikace. Výběr aplikace se prování vždy hned po vložení karty do čtečky na terminálu a probíhá následovně: terminál nejdřív vytvoří seznam aplikací, které jsou podporovány jak čipovou kartou, tak jím samotným a z tohoto seznamu vybere aplikaci, která bude použita pro povedení transakce. Samotná aplikace je tvořena daty uloženými na čipové kartě (závislé na vydavateli karty), daty uloženými na terminálu (data poskytnutá obchodníkem popř. nabyvatelskou bankou) a aplikačním protokolem dohodnutým mezi čipovou kartou a terminálem.
Strana 20
4 Kniha druhá: Bezpečnost a správa klíčů Tato kniha [2] popisuje minimální funkční požadavky týkající se bezpečnosti, které jsou od čipové karty a terminálu vyžadovány, aby bylo zajištěno správné fungování platebního systému a vzájemná interoperabilita různých typů karet a terminálů. Dále jsou zde uvedeny další požadavky a doporučení týkající se online komunikace čipové karty s jejím vydavatelem a správa kryptografických klíčů (z pohledu terminálu, vydavatele karty i celého platebního systému). Stejně jako předchozí je i tato kniha rozdělena do následujících 4 částí: 1. První část – Obecný úvod – obsahující reference, použité zkratky a terminologii. 2. Druhá část – Bezpečnost a správa klíčů – popisující používané bezpečnostní techniky (různé druhy autentizace, bezpečný přenos zpráv, principy správy veřejných klíčů, bezpečnost terminálů a na ně kladené požadavky týkající se správy klíčů). 3. Třetí část – Přílohy – specifikace bezpečnostních mechanismů a ověřených kryptovacích algoritmů potřebných pro implementaci výše uvedených funkcí. 4. Čtvrtá část – obsahuje definice volitelných rozšíření. Považuji za vhodné uvést vysvětlení několika stěžejních pojmů, jak je uvádí EMV specifikace: •
Klíč – sekvence symbolů (znaků) používaná při šifrování nebo dešifrování dat.
•
Privátní klíč – jeden z asymetrického páru klíčů, který je držený v tajnosti a používaný jen a pouze subjektem, který jej vlastní, pro vytváření digitálního podpisu.
•
Veřejný klíč – druhý klíč z asymetrického páru klíčů, který veřejně známý a je používaný příjemci dat pro ověřování digitálního podpisu. Veřejné klíče jsou v paměti ukládány jako dvojice čísel (modulo a exponent).
•
Certifikační autorita – důvěryhodná třetí strana (s velmi vysokou úrovní bezpečnosti), která se svým digitálním podpisem zaručuje za pravost totožnosti vlastníka páru asymetrických klíčů (tzn. veřejného a soukromého klíče).
•
Certifikát veřejného klíče – veřejný klíč digitálně podepsaný certifikační autoritou, která se svým podpisem zaručuje za pravost identity majitele klíče.
Strana 21
4.1 4.1.1
Bezpečnost a správa klíčů Princip fungování digitálního podpisu dle požadavků EMV specifikace
Dle následujícího popisu musí bezpodmínečně fungovat veškeré později zmiňované digitální podpisy používané čipovými kartami i terminály v rámci EMV platebních systémů. Princip fungování digitálního podpisu závisí na následujících algoritmech: •
Reverzibilní asymetrický algoritmus zahrnující v sobě podpisovou funkci (závisející na soukromém klíči) a obnovovací funkci (závisející na veřejném klíči). Obě tyto funkce mapují posloupnost bajtů na jinou posloupnost bajtů a to takovým způsobem, že platí: pokud libovolnou posloupnost bajtů (např. tělo zprávy) podepíšeme s použitím podpisové funkce a na výsledek aplikujeme obnovovací funkci, získáme opět původní posloupnost bajtů.
•
Hašovací algoritmus SHA-1, který mapuje libovolnou zprávu na 20-ti bajtový „haš kód“.
Generování vlastního digitálního podpisu probíhá v několika krocích. Z důvodů výpočetní náročnosti generování podpisu pro celou (potenciálně velmi obsáhlou) zprávu se volí následující postup. Nejdříve se s použitím algoritmu SHA-1 spočítá 20-ti bajtový haš kód originální zprávy. Poté se řetězec bajtů reprezentující zprávu rozdělí na dvě části: na X nejlevějších bajtů (dále jen LeftMSG) a zbytek zprávy. Následně se vytvoří následující reprezentativní řetězec určený k podpisu (pozn. podřetězce '6A' a 'BC' jsou konstanty). •
řetězec = '6A' + LeftMSG + haš kód + 'BC'.
Tento reprezentativní řetězec délky X + 22 bajtů (tzn. X je délka LeftMSG + 20 B haš + 2 B konstanty) se pomocí podpisové funkce s použitím soukromého klíče digitálně podepíše. Pro ověření podpisu se nejdříve zjistí délka podpisu v bajtech. Poté se na tento podpis aplikuje obnovovací funkce, která s použitím veřejného klíče podepisujícího získá zpět reprezentativní řetězec. Tento řetězec se opět rozdělí na jednotlivé složky a zkontrolují se hodnoty konstant. Dále se nahradí prvních X bajtů (délka podpisu – 22 B pro haš a konstanty) přijaté zprávy posloupností LeftMSG získanou z reprezentativního řetězce. Pro takto vzniklou posloupnost bajtů se spočítá haš kód a tento se porovná s haš kódem získaným z reprezentativního řetězce. Pouze v případě, že veškerá ověření proběhla v pořádku, jsou zpráva a podpis považovány za pravé. Strana 22
4.1.2
Statická autentizace dat (SAD)
Statická autentizace dat je jedinou EMV specifikací povolenou formou offline statické autentizace dat. SAD s použitím techniky digitálního podpisu používá terminál pro ověření autenticity (pravosti) kritických dat staticky uložených na čipové kartě. Použití techniky digitálního podpisu umožňuje detekovat jakoukoliv neoprávněnou změnu těchto dat. SAD pro svou činnost bezpodmínečně vyžaduje existenci certifikační autority a společnost, která kartu vydává – dále jen vydavatel karty, musí vlastnit pár veřejného a soukromého klíče spolu s certifikátem veřejného klíče. Certifikační autorita je potřebná z důvodu ověření identity vydavatele karty, neboť certifikační autorita mu jako jediná může vydat důvěryhodný certifikát veřejného klíče (tj. veřejný klíč vydavatele karty digitálně podepsaný certifikační autoritou, která se svým podpisem zaručuje za pravost identity majitele).
Obrázek 4.1 Statická autentizace dat – schéma rozmístění klíčů [5]
Samotný princip statické autentizace je takový, že statická data uložená na čipové kartě jsou spolu s identifikátorem použité hašovací funkce podepsána vydavatelem karty (s použitím jeho soukromého klíče), dále je v paměti karty uložen i výše zmíněný certifikát veřejného klíče vydavatele, příznak identifikující certifikační autoritu a typ použitého algoritmu, exponent a modulo veřejného klíče. Terminál, který ověřuje autenticitu dat uložených na kartě, nejdříve s použitím veřejného klíče certifikační autority, který má uložen ve své paměti, ověří certifikát veřejného klíče (identitu) vydavatele karty. Pokud je certifikát platný Strana 23
a v pořádku, terminál z něj získá veřejný klíč vydavatele karty. Poté se s použitím tohoto klíče provede ověření, zda byla data opravdu podepsána vydavatelem karty a zda jsou autentická (tzn. nebyla neoprávněně pozměněna). Postup vytváření a ověřování digitálního podpisu je podrobně popsán v předchozí podkapitole. Terminál pro možnost ověření certifikátu veřejného klíče vydavatele čipové karty musí být schopen uložit 6 veřejných klíčů certifikačních autorit spolu s dalšími informacemi používanými s těmito klíči pro každou aplikaci, kterou podporuje. Dále musí být schopen vyhledat veřejný klíč a k němu vztažená data dle kartou poskytnutého identifikátoru certifikační autority a odpovídajícího platebního systému. Mimo dvou výše zmíněných identifikátorů ukládá terminál pro každý klíč ještě identifikátor hašovací funkce (povolen pouze SHA-1 algoritmus), identifikátor algoritmu použitého pro digitální podpis (v současnosti je možné použít pouze RSA), hodnotu exponentu (musí být rovna 3 nebo 216 + 1) a modulu veřejného klíče certifikační autority a kontrolní součet. Terminál též může podporovat seznam revokovaných certifikátů, což je seznam veřejných klíčů vydavatelů karet, které byly platebním systémem revokovány. V takovém případě je při provádění SDA ověřeno, zda se aktuálně zpracovávaný certifikát nachází na seznamu revokovaných certifikátů. Pokud tomu tak je, SDA selže a transakce se neprovede. Seznam revokovaných certifikátů musí být udržován v aktuálním stavu a toto musí být zajištěno bezpečnou a spolehlivou cestou. Problematika aktuálnosti seznamu revokovaných certifikátů ovšem není součástí EMV specifikace a proto její případná implementace a její spolehlivost je záležitostí daného platebního systému.
Strana 24
4.1.3
Offline dynamická autentizace dat
Offline dynamická autentizace dat (dále jen ODAD) je prováděna terminálem s použitím techniky digitálních podpisů a slouží k autentizaci čipové karty (při tomto druhu autentizace je nutná čipová karta s koprocesorem) a k potvrzení autenticity kritických dat (uložených na kartě, kartou generovaných a dat přijatých od terminálu). Oproti SDA je při ODAD na čipové kartě uložen navíc ještě jeden dodatečný pár RSA klíčů určený pro kartu samotnou. Pomocí ODAD je bráněno padělání karet, neboť dodatečný soukromý klíč karty je nezkopírovatelně uložen přímo na čipu karty (zajištění této funkce je mimo doménu zájmu EMV specifikace a jeho implementace je ponechána na vydavateli karty). Tudíž zkopírování dat na kartě uložených neumožní získání soukromého klíče karty, a tak případná padělaná karta není schopna při komunikaci s terminálem generovat odpovídající digitální podpisy. ODDA stejně tak jako SDA pro svou činnost bezpodmínečně vyžaduje existenci spolehlivé certifikační autority, která se svým podpisem zaručuje za pravost certifikátu veřejného klíče vydavatele karty.
Obrázek 4.2 – Dynamická autentizace dat – schéma rozmístění klíčů (obrázek použit z [5])
Princip fungování ODAD je následující. Stejně jako u SDA na čipové kartě musí být uložen certifikát veřejného klíče vydavatele karty (tzn. veřejný klíč vydavatele karty digitálně Strana 25
podepsaný soukromým klíčem CA). Čipová karta má dále svůj vlastní pár RSA klíčů. Soukromý klíč z tohoto páru je nezkopírovatelně uložen na čipu karty a k veřejnému klíči existuje certifikát veřejného klíče tj. veřejný klíč spolu se statickými daty podepsaný soukromým klíčem vydavatele karty. Tento certifikát je poté použit terminálem k ověřování podpisů vygenerovaných kartou s použitím soukromého klíče karty pro data přenášená mezi oběma stranami. Terminál pro možnost ověření certifikátu veřejného klíče vydavatele čipové karty musí být schopen ukládat veřejné klíče CA spolu s dalšími informacemi používanými s těmito klíči. Minimální počet klíčů CA, které musí být terminál schopen uchovávat pro každou podporovanou aplikaci, je 6. Dále musí být terminál schopen vyhledat veřejný klíč CA a k němu vztažená data dle kartou poskytnutého identifikátoru platebního systému a certifikační autority. Terminál používá veřejné klíče CA pro ověření certifikátu veřejného klíče vydavatele karty. Po ověření tohoto certifikátu je veřejný klíč vydavatele karty použit pro ověření certifikátu veřejného klíče karty (tzn. zda byla statická data spolu s veřejným klíčem karty podepsána vydavatelem karty). Veřejný klíč karty se poté používá pro ověření podpisů, které karta generuje pro přenášená data. Existují 2 různé verze ODAD: •
Dynamická autentizace dat (dále jen DDA) – čipová karta generuje digitální podpisy pro přenášená data.
•
Kombinovaná dynamická autentizace dat (dále jen CDA) – čipová karta generuje jak digitální podpisy pro přenášená data, tak i aplikační kryptogram, který slouží k zajištění bezpečnějšího přenosu kritických dat o transakci mezi terminálem a kartou.
V případě DDA není možné zneužít kopii karty. Ale v praxi je možné, aby případný útočník zasáhl do komunikace mezi kartou a terminálem a tuto komunikaci pozměnil požadovaným způsobem tak, aby uskutečnil neoprávněnou transakci. Například pokud terminál požádá kartu o potvrzení transakce a karta se rozhodne k odmítnutí transakce, je možné změnit odpověď karty s použitím „útoku 2 čipů“ a vrátit terminálu potvrzující odpověď. Princip „útoku 2 čipů“ je takový, že podvržená karta obsahuje kromě běžného čipu ještě jeden další, který zprostředkovává výměnu informací mezi čipem karty a terminálem. Přičemž může dle libosti tuto výměnu pozměňovat (podvrhnout odpověď na ověření PINu, odpověď na ověření transakce). Při použití CDA je zneužití platební karty pomocí tohoto útoku znemožněno.
Strana 26
4.1.4
Dynamická autentizace dat (DDA) – dynamický podpis
Jak již bylo zmíněno výše DDA od čipové karty vyžaduje, aby data přenášená na terminál byla digitálně podepisována soukromým klíčem karty (tzv. dynamický podpis). Generování tohoto podpisu probíhá tak, že terminál zašle kartě příkaz „INTERNAL AUTHENTICATE“ následovaný seznamem datových elementů, které jsou od karty očekávány jako odpověď. Tento seznam by měl být uložen i na kartě, ale pro případ, že by to tak nebylo, je zasílán standardní seznam uchovávaný terminálem. V tomto seznamu se povinně musí vyskytovat položka odpovídající náhodnému číslu, které je generováno terminálem a zasíláno kartě. Karta jako odpověď na tento příkaz zašle terminálu zprávu obsahující odpovídající data spolu s náhodným číslem. Zpráva je samozřejmě před odesláním digitálně podepsána soukromým klíčem karty. Terminál po přijetí těchto dat provede ověření podpisu a poté vlastní zpracování dat. Před ověřením prvního dynamického podpisu musí terminál provést ověření certifikátu veřejného klíče vydavatele a následně ověření certifikátu veřejného klíče karty.
4.1.5
Kombinovaná dynamická autentizace (CDA) – generování aplikačního
kryptogramu CDA obdobně jako DDA vyžaduje, aby karta dynamicky podepisovala přenášená data. V případě CDA proces vytváření podpisu zahrnuje i generování tzv. aplikačního kryptogramu, který umožňuje detekovat podvržené zprávy v případě, že se útočník pokusí nabourat do komunikace mezi terminálem a kartou. Aplikační kryptogram (Application Cryptogram, AC) je 8-bajtový kryptogram generovaný kartou jako odpověď na příkaz GENERATE AC. Doporučená minimální množina dat, která musí být použita při generování aplikačního kryptogramu, musí obsahovat částku, kód země terminálu, výsledek ověření certifikátů karty, kód měny, datum transakce, typ transakce, náhodné číslo, čítač transakcí. AC v praxi je vygenerovaný autentizační kód zprávy (Message Authentication Code – MAC), což je vlastně haš kód generovaný nad výše uvedenou množinou dat s použitím tajného klíče vygenerovaného pro danou relaci. Autentizační kód zprávy zajišťuje integritu dat a zároveň autenticitu původce zprávy, který je spolu s příjemcem jediným subjektem, který zná tajný klíč. EMV specifikace umožňuje libovolnou implementaci AC, výše zmíněný MAC je jen doporučení.
Strana 27
EMV specifikace používá následující typy aplikačních kryptogramů: •
Transakční certifikát (Transaction Certificate, TC) aplikační kryptogram generovaný kartou v případě akceptace transakce.
•
Kryptogram s požadavkem o autorizaci (Authorisation Request Cryptogram, ARQC) kryptogram generovaný kartou v případě, že je požadována online autorizace transakce.
•
Kryptogram s výsledkem autorizace (Authorisation Response Cryptogram, ARPC) – Kryptogram generovaný vydavatelem karty s použitím Triple-DES popř. MAC algoritmu jako odpověď na ARQC.
•
Aplikační autentizační kryptogram (Application authentication cryptogram, AAC) – je kryptogram generovaný kartou při odmítnutí transakce.
Generování a ověřování CDA podpisu Nutno podotknout, že CDA musí být podporována jak na straně terminálu, tak na straně čipové karty. Samotné provádění CDA zásadním způsobem závisí na výsledku analýzy akcí terminálu. Při této analýze se totiž zjistí, zda je povoleno a je v aktuálním okamžiku možné provádět online autorizaci transakce a zda je vyžadován CDA podpis odpovědi. Vlastní průběh generování CDA podpisu se skládá z několika kroků. Nejdříve terminál pošle kartě příkaz pro generování aplikačního kryptogramu „GENERATE AC“ (s indikací požadavku, aby odpověď byla digitálně podepsána). Karta po přijetí tohoto příkazu může odpovědět následujícími způsoby: •
V případě odmítnutí transakce zašle terminálu zprávu obsahující AAC spolu s informací o typu kryptogramu a stavu čítače transakcí. EMV specifikace v tomto případě nevyžaduje, aby zpráva byla podepsána.
•
V případě přijetí transakce karta nejdříve vygeneruje TC nebo ARQC, který spolu s dalšími informacemi o kryptogramu a náhodným číslem připojí k datům, která jsou součástí odpovědi karty na příkaz. Takto vytvořená zpráva je poté digitálně podepsána, je k ní připojen indikátor typu kryptogramu a stav čítače transakcí a je odeslána na terminál.
Terminál po přijetí odpovědi nejdříve zjistí typ aplikačního kryptogramu. Pokud je typ kryptogramu AAC tzn. karta transakci odmítla, terminál odmítne provést transakci a ta je Strana 28
neúspěšně ukončena. Pokud je typ AC ARQC nebo TC, pak terminál provede ověření podpisu a haše. Pokud je vše v pořádku, tak v případě TC se transakce provede a nebo je ARQC odeslán k online ověření transakce.
4.1.6
Šifrování PINu
V případě, že je podporováno offline ověřování osobního identifikačního čísla – PINu, je třeba zajistit bezpečný přenos PINu ze zařízení, které je součástí terminálu a je určeno pro zadávání PINů (dále jen PIN pad), k čipové kartě. Bezpečnost při tomto přenosu je opět zajištěna šifrováním dat s pomocí asymetrického páru klíčů uloženého na kartě (buď má karta speciální pár klíčů pouze pro šifrování PINu, a nebo je použit pár klíčů určený pro generování dynamického podpisu). Terminál nejdříve získá od karty odpovídající veřejný klíč a od PIN padu PIN (jako textový řetězec). Poté požádá kartu o vygenerování náhodného čísla, které spolu s PINem zašifruje veřejným klíčem a vzniklou šifru zašle kartě. Čipová karta tato data po přijetí dešifruje s použitím soukromého klíče a ověří správnost náhodného čísla a PINu.
4.1.7
Principy a politiky správy veřejných klíčů certifikačních autorit
EMV specifikace definuje obecné principy a politiky správy veřejných klíčů CA, které jsou implementovány jednotlivými složkami konkrétního platebního systému jako konkrétní procedury, které představují aplikaci těchto principů v reálu. Základním principem je ustanovení, že všechny čipové karty musí podporovat revokaci klíčů CA tzn. musí mít určeno datum expirace. Krom zmíněných principů, které musí platební systém splňovat jsou v EMV specifikaci zmíněny i sdílené politiky, týkající se především sdílení informací v rámci EMV komunity apod. Životní cyklus veřejného klíče CA dle EMV specifikace je rozdělen do následujících fází: •
Fáze plánování – platební systém prozkoumá požadavky na vydání nových klíčů v blízké budoucnosti. Je provedena kontrola odolnosti existujících klíčů proti útoku a bezpečnostní revize, na jejímž základně jsou určeny platnosti nových klíčů popř. jsou upraveny expirace existujících klíčů a je vytvořen plán nahrazování klíčů. Z bezpečnostních důvodů musí být délky nových klíčů nastaveny na maximální Strana 29
možnou délku, kterou jsou POS terminály a čipové karty schopny v reálném čase zpracovat. •
Fáze generování klíčů – pokud je výsledkem plánovací fáze, požadavek na vygenerování nových klíčů, jsou páry klíčů bezpečným způsobem generovány CA platebního systému.
•
Distribuce klíčů – CA bezpečným způsobem distribuuje nové veřejné klíče (používané
pro
ověřování
certifikátů
vydávaných
CA)
vydavatelům
karet
a nabyvatelským institucím tzn. bankám (tyto redistribuují klíče provozovatelům POS terminálů), tak aby nedošlo k porušení integritu či autenticity klíčů. •
Užívání klíčů – veřejný klíč CA je používán terminálem při offline autentizaci dat (SDA i ODAD). Terminál tudíž musí být schopen ukládat, rušit a ověřovat integritu těchto klíče. Soukromý klíč CA je používán pro vytváření certifikátů veřejných klíčů vydavatelů karet (vydavatel karty si vygeneruje veřejný klíč a tento pošle CA platebního systému, CA podepíše tento klíč a takto vytvořený certifikát veřejného klíče zašle zpět vydavateli karty). Vydavatel s použitím veřejného klíče CA ověří správnost přijatého certifikátu. Pokud je vše v pořádku, může být certifikát používán při vydávání nových čipových karet.
•
Plánovaná revokace (zneplatnění) klíče – potřebnou dobu před expirací veřejného klíče CA je třeba, aby tento klíč již nebyl používán pro vytváření certifikátů veřejných klíčů vydavatelů karet, protože v okamžiku revokace klíče CA jsou zneplatněny všechny certifikáty tímto klíčem podepsané. Vydavatelé karet tedy musí toto zohlednit tím, že platnost vydávaných karet nesmí přesáhnout dobu platnosti certifikátu veřejného klíče vydavatele (tj. planost klíče CA). V okamžiku, kdy veřejný klíč CA skutečně expiruje, musí být smazán z paměti terminálů, které tento klíč používaly pro ověřování pravosti platebních karet.
Nové veřejné klíče CA jsou vydávány a distribuovány nabyvatelským subjektům zpravidla v lednu, přičemž do konce následujících 6 měsíců (do konce června) musí být klíče uloženy v POS terminálech. A od července začíná CA používat odpovídající soukromý klíč pro podepisování certifikátů veřejných klíčů vydavatelů, které jsou ukládány na nové čipové karty. Do 6 měsíců od data revokace musí být provozovatelé schopni též smazat revokované klíče CA ze všech svých terminálů. Strana 30
Kompromitace veřejného klíče CA EMV specifikace definuje kompromitaci klíče jako narušení bezpečnosti jeho použití, prolomení tajemství soukromého klíče z důvodů možnosti použití větší výpočetní síly a sofistikovanějších krypto-analytických algoritmů. V případě, že je veřejný klíč CA kompromitován, rozbíhá se pohotovostní proces, který může skočit až zrychlenou revokací klíče. Tento proces je rozdělen do následujících 4 fází: •
Detekce – v této fázi dochází ke zjištění jaké povahy je zjištěný problém. Zda se jedná o aktuálně zjištěné porušení bezpečnosti platebního systému, nebo byly zjištěny a ohlášeny podvody držiteli karet, případně bylo zjištěno potenciální riziko možného odtajnění soukromého klíče (především z důvodu aktuálního vývoje kryptoanalytických algoritmů).
•
Analýza a zhodnocení problému – zahrnuje především zjištění možných rizik a jejich (především ekonomický) dopadu na platební systém. Pokud je kompromitace potvrzena, jsou navržena možná protiopatření pro minimalizaci rizik a finančních ztrát.
•
Rozhodnutí – na základě výsledků předchozí fáze jsou přijata adekvátní opatření (v nejhorším případě může dojít k neplánované revokaci klíče před datem jeho expirace).
•
Zrychlená revokace klíče – rozhodnutí o zrychlené revokaci vede ke změně expiračního data klíče a tento fakt musí být oznámen všem zúčastněným subjektům (vydavatelům karet, provozovatelům terminálů apod.).
Strana 31
5 Kniha třetí - Specifikace aplikačního protokolu Třetí kniha EMV specifikace [3] popisuje procedury, které musí proběhnout na straně terminálu a čipové karty, aby mohla být uskutečněna finanční transakce v mezinárodním prostředí platebního systému. Je třeba ještě zmínit, že EMV specifikace se nezabývá průběhem zaúčtování či finančního vyrovnání transakcí mezi jednotlivými účastníky platebního systému. Též zpracování transakcí bez použití čipové karty je mimo doménu zájmu této specifikace. Tato kniha obsahuje následujících 5 kapitol: •
První část – Obecný úvod – obsahující reference, použité zkratky a terminologii.
•
Druhá část – Datové elementy a příkazy – a jejich funkce při zpracování finanční transakce.
•
Třetí část – Specifikace debetních a kreditních aplikací – popisuje průběh celé transakce ve formě posloupnosti událostí a příkazů), zpracování výjimek, definice dat zasílaných mezi čipovou kartou a terminálem.
•
Čtvrtá a pátá část – Přílohy a volitelná rozšíření – abecední přehled všech datových elementů spolu s podrobnými definicemi jejich kódování.
Obsahy druhé a třetí části jsou podrobně rozebrány v následujících dvou podkapitolách.
Strana 32
5.1 5.1.1
Datové elementy a příkazy Datové elementy, soubory, seznamy datových elementů
Datové elementy jsou dle EMV specifikace definovány jako nejmenší dále nedělitelné jednotky informace, které jsou určeny svým jménem, popisem logického významu obsahu, formátem a kódováním. Kompletní seznam všech existujících datových elementů potřebných pro provedení finanční transakce z pohledu EMV specifikace je ve [3] v příloze A (Annex A). Datové objekty se skládají ze jmenovky, hodnoty a délky (hodnoty objektu). Jmenovka slouží v rámci prostředí vybrané aplikace jako jedinečný identifikátor datového objektu. Hodnota datového objektu může být tvořena jedním datovým elementem (poté se jedná o tzv. jednoduchý datový objekt) nebo jedním či více datovými objekty (tzv. sestavený datový objekt). Hodnota datového objektu musí být na straně terminálu uložena do bufferu pro budoucí zpracování. Vzájemné mapování datových elementů na datové objekty je opět podrobně popsáno ve [3] v příloze A (Annex A). Datové objekty (obsahující aplikační data) musí být uloženy v souborech na čipové kartě takovým způsobem, aby bylo možné tato data číst. Struktura souboru a způsob reference závisí na významu daných dat. EMV specifikace popisuje možné metody, ale výběr konkrétního rozvržení souborů je ponechán na vydavateli karty. Jedinou výjimkou jsou elementární soubory aplikace, jejichž struktura musí být lineární. Tyto soubory obsahují pouze data neinterpretovaná kartou, tedy data která nejsou kartou používána v jejích vnitřních procesech. Soubory na čipové kartě mohou být odkazovány dvěma způsoby, buď s použitím jedinečných pojmenování souborů nebo v případě výše zmíněných elementárních souborů aplikace použitím tzv. jednoduchého identifikátoru souboru (JIS). JIS je 5bitové číslo jednoznačně identifikující soubor v rámci dané aplikace. JIS může nabývat hodnot 1 – 30, přičemž hodnoty 1 – 10 jsou rezervovány pro soubory přímo předepsané EMV specifikací, 11 – 20 jsou soubory specifické pro daný platební systém a 21 – 30 jsou soubory závislé na vydavateli karty. V rámci snižování výpočetní zátěže čipové karty jsou v případech, kdy je terminál kartou požádán o zaslání většího počtu datových elementů, používány tzv. seznamy datových objektů (SDO) namísto běžného kódování datového objektu(jmenovka, délka hodnoty,
Strana 33
hodnota). SDO je uložen na čipu karty a obsahuje seznam datových objektů (spolu s jejich formátem), které má terminál kartě zaslat. Terminál na základě takového SDO spojením požadovaných datových objektů vybuduje jediné pole a toto pošle kartě. SDO jsou používány při generování aplikačního kryptogramu, transakčního certifikátu a při provádění autentizace dat.
5.1.2
Příkazy
EMV specifikace předepisuje, že veškerá komunikace mezi terminálem a čipovou kartou je řízena terminálem a probíhá na principu příkaz – odpověď. Z toho vyplývá, že jsou rozlišovány 2 základní typy přenášených zpráv, a to: •
zpráva reprezentující příkaz – složená z povinné 4bajtové hlavičky, která obsahuje jednoznačný identifikátor příkazu o 2 bajtech a 2 případné parametry, a nepovinného těla, které obsahuje informaci o délce přenášených dat a přenášená data,
•
zpráva reprezentující odpověď – složená z nepovinného těla nesoucího data různé délky a povinné 2bajtové koncovky, která reprezentují aktuální stav zpracování probíhajícího příkazu (např. příkaz proveden bez problémů, příkaz proveden s varovným hlášením, provádění příkazu přerušeno apod.).
Nutno ještě poznamenat, že dle EMV specifikace nesmí čipová karta souběžně komunikovat s více než jednou aplikací na jednom terminálu.
EMV specifikace definuje následující příkazy (a možné odpovědi na ně): •
APPLICATION BLOCK (*) – zruší platnost aktuálně vybrané aplikace na kartě.
•
APPLICATION UNBLOCK (*) – obnoví platnost aktuálně vybrané aplikace na kartě.
•
CARD BLOCK (*) – příkaz, který trvale zablokuje všechny aplikace uložené na kartě (včetně implicitní aplikace).
•
EXTERNAL AUTHENTICATE – příkaz, kterým terminál požádá čipovou kartu o ověření kryptogramu (autentizaci vydavatele karty). Tento příkaz není podporován všemi aplikacemi.
Strana 34
•
GENERATE APPLICATION CRYPTOGRAM – spolu s tímto příkazem terminál pošle kartě data související s prováděnou transakcí. Karta s jejich použitím vygeneruje aplikační kryptogram, který zašle terminálu v odpovědi spolu s informací o jeho typu a stavem čítače transakcí.
•
GET CHALLENGE – příkaz používaný terminálem pro získání 8bajtového náhodného čísla generovaného kartou. Toto číslo bývá použito při aplikaci bezpečnostních procedur.
•
GET DATA – příkaz sloužící k získání jednoduchého datového objektu, a to buď čítače transakcí, registr poslední online transakce, čítač pokusů pro zadání PINu , či indikátor formátu logu (žurnálu). Karta v odpovědi terminálu zašle požadovaný objekt.
•
GET PROCESSING OPTIONS – tímto příkazem je iniciováno provádění transakce na čipové kartě. Karta jako odpověď zasílá informaci o podporovaných autentizačních metodách a umístění elementárních souborů aplikace.
•
INTERNAL AUTHENTICATE – příkaz, který iniciuje vytváření podpisu na statická data uložená na kartě a náhodné číslo s použitím odpovídajícího soukromého klíče. Tato data i s podpisem jsou poté zaslána terminálu v odpovědi na příkaz.
•
PIN CHANGE/UNBLOCK (*) - příkaz sloužící ke změně a odblokování PINu.
•
READ RECORD – příkaz slouží k přečtení záznamu z lineárního souboru. Tento záznam je poté poslán v odpovědi terminálu.
•
VERIFY – tímto příkazem terminál vyzve čipovou kartu k porovnání PINu zadaného na PIN padu terminálu a PINu uloženého na kartě. Výsledek je zaslán v odpovědi opět jako status zpracování příkazu, přičemž v případě nesprávnosti PINu je uveden i počet zbývajících pokusů.
Pokud u příkazu není podrobněji popsána odpověď na daný příkaz, tak karta vrací pouze status prováděného příkazu. Položky výše uvedeného seznamu označené hvězdičkou jsou příkazy, které jsou prováděny na popud vydavatele karty, který z daných příkazů vytvoří skript. Tyto skripty jsou poté distribuovány na terminály a jejich provedení neovlivní aktuálně prováděnou transakci, ale jsou důležité pro další fungování aplikace uložené na čipové kartě.
Strana 35
5.2
Specifikace debetních a kreditních aplikací
Typický průběh zpracování jedné transakce po výběru aplikace zachycuje následující obrázek.
Obrázek 5.1: Typický průběh transakce dle EMV
Jednotlivé fáze průběhu transakce: 1. Fáze výběru aplikace, která bude použita pro zpracování transakce, slouží pro informování karty o počínající transakci, na něž karta reaguje zasláním seznamu Strana 36
podporovaný funkcí (mj. podporované autentizační funkce) a přehledem souborů, které terminál potřebuje pro zpracování transakce. 2. Poté následuje fáze načtení aplikačních dat ze souborů na kartě, tato data si terminál ukládá do své paměti pro pozdější použití při zpracování transakce. 3. Autentizace načtených aplikačních dat probíhá poté, co je mezi kartou a terminálem dohodnuta autentizační metoda. EMV specifikace podporuje pouze offline autentizaci dat, přičemž je vždy vybrána nejbezpečnější možná metoda podporovaná jak terminálem, tak i kartou tzn. CDA, DDA či nejméně bezpečná SDA. Samotný průběh vybrané metody je podrobně popsán v druhé knize EMV specifikace [2]. 4. Fáze restrikce zpracování slouží k určení nakolik je kompatibilní aplikace na terminálu s aplikací uloženou na čipové kartě a popř. k provedení potřebných úprav (včetně případného zamítnutí transakce). Konkrétně se jedná o ověření verze aplikace, ověření omezení týkajících se použití aplikace (u některých aplikací je jejich použití limitováno geografickými podmínkami tzn. lze ji použít jen na území určitých států popř. povoluje provádění pouze některých typů transakcí) a nakonec ověření platnosti aplikace (tzn. zda je již aplikace platná a zároveň zda aktuální datum není vyšší než datum její expirace). 5. Autentizace držitele karty je prováděna kvůli ověření, zda osoba předkládající kartu k platbě je oprávněným držitelem karty. Pokud má čipová karta v paměti uložen seznam podporovaných verifikačních metod, pak je tento seznam procházen terminálem a v případě, že i terminál podporuje danou verifikační metodu je tato metoda provedena. Verifikační metody dle EMV specifikace jsou online a offline ověření PINu a metoda ověření podpisu držitele karty, popř. kombinace těchto tří metod. 6. Správa rizik na terminálu se sestává z 3 základních funkcí, a to: ◦
Kontrola celkového objemu transakcí – terminál si v logu ukládá seznam provedených transakcí s částkou transakce a datem uskutečnění, přičemž transakce jsou ukládány dle čísla účtu, ke kterému byla karta vydána tzv. PAN. V případě,
že
celková
částka
objemu
transakcí
jednoho
účtu
dosáhne
nadefinované hranice, probíhající transakce je zamítnuta. ◦
Náhodný výběr transakce (na základě náhodně generovaného čísla a popř. částky transakce) umožňuje terminálu náhodně volit transakce určené k online ověření. Strana 37
◦
Kontrola, která umožňuje vydavateli karty požadovat, aby po určitém počtu transakcích provedených offline následovala transakce provedená online, přičemž v případě, že daný terminál v dané době dočasně neumožňuje provádění online transakcí, může být ještě několik málo transakcí provedeno offline. Po překročení nastaveného limitu jsou další offline transakce zamítány až do doby, kdy je provedena online transakce.
7. Analýza akcí terminálu – je prováděna poté, co byly obchodníkem a popř. držitelem karty zadány informace o transakci. Na základě výsledku správy rizik učiní terminál rozhodnutí, zda bude transakce ověřena offline (karta bude vyzvána k vygenerování transakčního certifikátu), zamítnuta offline (karta bude vyzvána k vygenerování aplikačního autentizačního kryptogramu), popř. bude transakce odeslána k ověření online (karta bude vyzvána k vygenerování kryptogramu s požadavkem o autorizaci). 8. Analýza akcí karty – čipová karta může mít svou vlastní správu rizik, přičemž implementace této vlastnosti je záležitostí vydavatele karty a je mimo doménu zájmu EMV specifikace. Výsledkem správy rizik čipové karty může být povolení transakce offline, popř. online, a nebo odmítnutí transakce. 9. Zpracování transakce online se provádí proto, aby sám vydavatel karty měl možnost kontrolovat, autorizovat popř. odmítnout transakci. Online autorizace transakce probíhá tak, že čipová karta vygeneruje kryptogram s požadavkem o autorizaci (ARQC), terminál tento kryptogram odešle vydavateli karty. Vydavatel karty vyhodnotí transakci a odpoví terminálu pomocí kryptogramu s výsledkem autorizace (ARPC). Princip zpracování ARQC a generování ARPC na straně vydavatele karty je čistě jeho implementační záležitostí, která je mimo doménu zájmu EMV specifikace. 10. Zpracování skriptu – spolu s ARPC (kryptogram s výsledkem autorizace) může vydavatel karty zaslat na terminál i skript popř. několik skriptů, který má být proveden čipovou kartou. Terminál tento skript příjme a poté zasílá jednotlivé příkazy čipové kartě, přičemž terminál nemusí význam těchto příkazů znát. Samotné provedení skriptu neovlivní aktuálně prováděnou transakci, ale je důležité pro další fungování aplikace uložené na čipové kartě. 11. Dokončení transakce – je fáze, při níž se provádí funkce vedoucí k ukončení zpracování transakce. Dokončovací fáze musí být provedena ve všech případech, tedy i když zpracování transakce skončí neúspěšně popř. výjimkou.
Strana 38
Je potřeba ještě zdůraznit, že se jedná o typický průběh transakce, při němž je fáze správy rizik na terminálu zpracovávána paralelně s fázemi autentizace dat, restrikce zpracování a ověření držitele karty. V některých implementacích se může pořadí některých fází zpracování transakce mírně lišit.
Strana 39
6 Kniha čtvrtá - Požadavky kladené na držitele karty, obsluhu a rozhraní nabyvatele Čtvrtá kniha EMV specifikace [4] definuje povinné, doporučené a volitelné požadavky kladené na terminál, aby tento byl schopen přijímat čipové karty a mohl být obsluhován zástupcem provozovatele. Tato kniha obsahuje následujících 5 kapitol: •
První část – Obecný úvod – obsahující reference, použité zkratky a terminologii.
•
Druhá část – Obecné požadavky – obsahuje funkční a fyzické požadavky kladené na terminál.
•
Třetí část – Architektura softwaru – se zabývá architekturou softwaru včetně jeho správy a správy dat.
•
Čtvrtá část – Požadavky kladené na držitele karty, obsluhu a rozhraní nabyvatele – se zabývá požadavky kladenými na 3 v názvu uvedenými účastníky platebního systému.
•
Pátá část – Přílohy – obsahuje informace týkající se kódování datových elementů, příklady konverzí datových elementů apod.
Obsahy druhé, třetí a čtvrté části jsou podrobně rozebrány v následujících podkapitolách.
Strana 40
6.1 6.1.1
Obecné požadavky Typy terminálů
Protože EMV specifikace zahrnuje široké spektrum různých terminálů, jsou tyto kategorizovány z několika základních hledisek: •
•
Dle prostředí: ◦
Terminál obsluhovaný zaměstnancem obchodníka nebo nabyvatele.
◦
Terminál bez obsluhy.
Dle typu komunikace: ◦
Online
–
terminál
s požadavkem
o
při
zpracování
autorizaci
transakce
transakce.
vždy
Online
odesílá
zpracování
kryptogram transakce
bezpodmínečně vyžaduje možnost online komunikace s nabyvatelem, přičemž nabyvatel musí být schopen komunikovat s vydavatelem karty. ◦
Offline se schopností pracovat online – terminál je schopen zpracovávat transakce jak online, tak i offline.
◦ •
Offline – terminál je schopen zpracovávat transakce pouze offline.
Dle zodpovědnosti za činnost terminálu (v některých případech nemusí být vlastník terminálu stejný subjekt jako subjekt zodpovědný za činnost terminálu), za niž může být zodpovědná: ◦
Finanční instituce.
◦
Obchodník.
◦
Držitel karty.
Při běžném provozu terminálu je dále třeba, aby terminál dal nějakým způsobem najevo, které funkce podporuje a které nikoliv. EMV specifikace rozděluje funkce do následujících kategorií: •
Metody načítání dat z karty – terminál může podporovat načítání dat pomocí manuálního zadávání, čtením dat z karty vybavené magnetickým proužkem nebo čtením dat z karty s integrovaným čipem.
Strana 41
•
Metody verifikace držitele karty – terminál může podporovat hned několik z následujících možných metod verifikace držitele karty: PIN ověřovaný čipem karty, šifrovaný PIN ověřovaný online, vlastnoruční podpis držitele karty (možný jen v případě, že terminál má možnost tisku a je obsluhován zástupcem prodejce), šifrovaný PIN ověřovaný offline, popř. indikátor faktu, že verifikace držitele karty není vyžadována.
•
Bezpečnostní funkce – terminál může podporovat 3 metody autentizace dat na kartě (SDA, DDA, CDA) a případně funkci pro zadržení karty (typická vlastnost bankomatů).
•
Typy akceptovaných transakcí – dle EMV specifikace existují následující typy transakcí: výběr hotovosti, platba za zboží, platba za služby, výběr hotovosti při platbě (tzv. cashback), informace o účtu, převod mezi dvěma účty držitele karty, platba na cizí účet, administrativní transakce a uložení hotovosti na účet. Terminál může podporovat pouze některé z nich.
•
Metody zadávání vstupních dat týkajících se zpracovávané transakce na terminál – může být prováděno pomocí: numerických kláves, alfabetických kláves se speciálními symboly („*“, „#”), příkazových kláves (Cancel, Enter, Clear) a funkčních kláves (šipky, F1, F2, Backspace, Escape).
•
Výstupní zařízení terminálu – může být tiskárna popř. zobrazovací zařízení sloužící k zobrazení detailů transakce a to zvlášť obsluze a držiteli karty.
Terminál má pak ve své paměti uloženu posloupnost několika bajtů (tzv. Terminal Capabilities). Pro každou výše uvedenou kategorii (tzn. množinu funkcí) má terminál uložen jeden až dva bajty, přičemž každý bit indikuje, zda je konkrétní funkce (přiřazená danému bitu EMV specifikací) terminálem podporována či nikoliv.
Strana 42
6.1.2
Funkční požadavky na terminál
Tato kapitola pouze shrnuje požadavky vyplývající z předchozích 3 knih EMV specifikace týkající se terminálu, protože se ve valné většině případů jedná o opakování již zmíněných faktů popř. velmi obecné požadavky (např. terminál musí být schopen uchovávat datum ve formátu YYMMDD tzn. rok, měsíc, den, terminál musí být schopen uchovávat data potřebná pro provedení podporované metody autentizace dat apod.) ponechávám tuto část laskavému zájemci k samostudiu ([4] – kapitola 6).
6.1.3
Fyzické charakteristiky terminálu
Fyzické charakteristiky jednotlivých terminálů se mohou zásadním způsobem lišit dle účelu a konfigurace daného zařízení, popř. prostředí, ve kterém je provozováno. Klávesnice terminálu by měla obsahovat jeden popř. i více typů kláves, přičemž EMV specifikace rozlišuje následující typy kláves: •
numerické klávesy,
•
alfabetické klávesy se speciálními symboly („*“, „#”),
•
příkazové klávesy (Cancel, Enter, Clear),
•
funkční klávesy (šipky, F1, F2, Backspace, Escape).
Případně může terminál obsahovat další klávesy určené pouze pro určité akce (např. klávesy pro výběr jazyka apod.). Dotyková obrazovka je z pohledu EMV specifikace považována též za klávesnici. Každý terminál by měl být schopen nějakým způsobem nabídnout možnost ověření uživatele zadáním PINu. Pokud terminál není vybaven PIN padem z výroby, měl by mít alespoň sériový port pro připojení externího PIN padu, popřípadě může být použita i klávesnice sloužící k zadávání dat při zpracování transakce. Typické rozložení kláves ukazuje následující obrázek.
Strana 43
Obrázek 6.1 Typické rozvržení kláves PIN padu [4]
Klávesa s číslem 5 by měla být hmatem odlišitelná od ostatních kláves (např. pomocí vrypu nebo výstupku), aby usnadnila orientaci nevidomým držitelům karet. Displej slouží především k tomu, aby umožnil obsluze terminálu a popř. i držiteli karty sledovat průběh transakce, zadávat potřebné vstupy a vybírat z nabídky možností. Displej musí být schopen v jednom okamžiku zobrazit alespoň dva řádky textu po 16 znacích. Obsluhovaný terminál musí být vybaven displejem určeným pro obsluhující osobu a tento může být popř. doplněn dalším displejem určeným pro držitele karty. Terminál bez obsluhy může být vybaven pouze jedním displejem pro držitele karty. Hodiny s místním datem a časem musí být umístěny ve všech terminálech umožňujících offline transakce. Informace o aktuálním datu a čase je použita pro ověřování expiračních dat karet i aplikací, pro offline šifrování PINu, přesný čas může být také použit pro ověření jedinečnosti identifikátoru transakce a nebo jako vstupní informace pro generování aplikačních kryptogramů. Dle EMV specifikace je čtečka magnetických proužků nutnou součástí terminálu vybaveného čtečkou čipových karet, pokud to není v rozporu s pravidly stanovenými platebním systémem. Poslední EMV specifikací zmiňované zařízení – tiskárna není nutnou součástí terminálu, ale v případě, že je jí terminál vybaven, musí být tiskárna schopná tisknout min. 20 alfanumerických znaků na řádek.
Strana 44
6.2 6.2.1
Architektura softwaru Struktura softwaru na terminálu
Tato kapitola popisuje principy, kterými se bude vývoj terminálů ubírat. Tyto principy nemusí být nutně uplatněny a i bez nich může terminál v současné době fungovat, jejich implementace ovšem zaručuje delší životnost terminálu bez nutnosti radikálních úprav základních softwarových struktur. V současné době probíhá odklon od karet vybavených pouze magnetickým proužkem k čipovým kartám. Zásadní rozdíl, který tato změna přináší, je v tom, že magnetický proužek umožňuje ukládat řádově menší množství dat než čip. Tím pádem mohou čipové karty podporovat mnohem více aplikací a zároveň roste i počet možností (voleb), které musí terminál interpretovat. Zároveň je třeba brát v potaz fakt, že aplikace budou na terminál v průběhu jeho činnosti přidávány nebo aktualizovány, a to se musí dít takovým způsobem, který je efektivní a neznamená riziko pro již nahrané aplikace. EMV specifikace nabízí dvě alternativy řešení, a to aplikační rozhraní (Application Program Interface – API) a překladač. Obě řešení předpokládají existenci aplikačních knihoven, které představují v některých případech kompletní aplikační program, jindy zase pouze jednotlivé procedury, které jsou při zpracování transakce volány. V případě překladače jsou aplikační knihovny množiny instrukcí virtuálního stroje, v případě API se jedná o knihovny objektů. Terminál může mít v paměti uloženo několik takových knihoven, přičemž některé jsou dostupné ze všech aplikací a použití jiných je omezeno jen pro určité aplikace popř. platební systémy. Výhody API architektury: •
Umožňuje aplikačnímu programu využívat základní a často používané funkce poskytované terminálem přes standardizované rozhraní (API).
•
Jednotlivé funkce mohou být implementovány pouze jednou a používány hned několika různými aplikacemi. Nedochází k replikaci kódu, což je efektivní z pohledu paměťových nároků kladených na terminál.
•
Aplikační program nemusí brát v potaz hardwarové vybavení konkrétního terminálu, protože to je (dík API) transparentní.
•
V případě potřeby je možné přidat a certifikovat novou aplikaci na terminál, aniž by musela proběhnout opětovná certifikace již existujících aplikací. Strana 45
Implementace překladače definuje jedno softwarové jádro společné pro několik typů terminálů. Toto jádro vytváří virtuální stroj, který může být implementován pro každý typ řídící jednotky a poskytuje ovladače pro vstupní a výstupní zařízení a specifické funkce na velmi nízké úrovni. Aplikační programy na vyšší úrovni poté používají pouze standardizované funkce jádra. Výhody použití překladače: •
Na každém terminálu je nainstalováno pouze jedno jádro s obecnými funkcemi podporujícími přijímání čipových karet (životnost jádra 7 – 10 let).
•
Certifikace jádra probíhá nezávisle na certifikaci aplikací.
•
Jedna verze softwaru pro terminál může být použita na různých procesorech a různých typech terminálů.
6.2.2
Správa softwaru
Aktualizace softwaru na terminálu musí být dle EMV specifikace povolena, pokud není v přímém rozporu s právním systémem dané země. Aktualizace musí probíhat pod dohledem aplikace na terminálu, vlastníka terminálu či pověřené osoby nabyvatele. V případě, že probíhající aktualizace je prováděna pomocí aplikace na terminálu, musí dle EMV specifikace proběhnout ověření identity subjektu provádějícího aktualizaci, neboť pouze výrobce a vlastník terminálu (popř. jimi pověřené osoby) mají oprávnění k nahrávání softwaru na terminál. Je nutné též ověřit integritu nově nahraného kódu. Aktualizace prováděné jiným než výše zmíněným způsobem jsou mimo doménu zájmu EMV specifikace.
Strana 46
6.2.3
Správa dat
Z pohledu terminálu existují dva typy dat, a to data uložená v paměti terminálu, která jsou pod kontrolou výrobce terminálu (např. sériová čísla zařízení), nabyvatele nebo obchodníka, a data získaná v průběhu zpracování transakce. Kdykoliv dojde k inicializaci nebo aktualizaci dat, musí být zkontrolována jejich integrita. Zároveň musí být zvláštní pozornost věnována tzv. Terminal Capabilities (viz. kap. 6.1.1), které musí být inicializovány před uvedením terminálu do provozu a při každé změně musí být uvedeny do stavu odpovídajícímu skutečnosti. Též informace, které jsou pod kontrolou nabyvatele nesmí být upravovány nikým jiným než nabyvatelem (popř. jím pověřenou osobou). Dále je možno rozlišit data nezávislá na aplikaci (datum a čas, kód země terminálu, čítač transakcí, sériová čísla zařízení, schopnosti terminálu tzv. Terminal Capabilities, identifikace typu terminálu) a data aplikačně závislá (identifikátor nabyvatele, obchodníka, aplikace, verze aplikace, terminálu, měny, veřejný klíč certifikační autority apod.). Aktualizace aplikačně závislých dat musí být dle EMV specifikace povolena, pokud to není v rozporu s právním systémem dané země. Aktualizace může být prováděna jak přes síť, tak i lokálně.
6.3
Požadavky kladené na držitele karty, obsluhu a rozhraní
nabyvatele 6.3.1
Rozhraní obsluhy terminálu a držitele čipové karty
Výběr jazyka Terminál musí podporovat alespoň jazyk země, na jejímž území je provozován. V tomto jazyce jsou zobrazovány všechny zprávy určené obsluze terminálu. V závislosti na podmínkách a zvyklostech prostředí, ve kterém je terminál provozován, může terminál podporovat více jazyků, v nichž se zobrazují zprávy držiteli karty. V takovém případě je při vložení karty terminálem zkontrolována jazyková preference karty a v případě, že terminál daný jazyk podporuje, je tento nastaven jako jazyk zpráv zobrazovaných držiteli karty. V případě, že jazyk preferovaný kartou není na terminálu podporován, může držitel karty Strana 47
před provedením transakce sám zvolit preferovaný jazyk z nabídky terminálu. Pokud terminál podporuje pouze jeden lokální jazyk jsou v tomto jazyce zobrazovány všechny zprávy určené jak obsluze terminálu, tak i držiteli karty. Pro zobrazování zpráv musí terminál podporovat znakovou sadu ISC/IEC 8859 odpovídající zvolenému jazyku, popř. může být použita základní znaková sada anglické abecedy a zprávy mohou být zobrazovány v libovolném jazyce bez použití diakritiky, pokud odstraněním diakritiky nedojde k nečitelnosti či nesrozumitelnosti zpráv. Z důvodů zaručení konzistence zpráv zobrazovaných na terminálu popř. na PIN padu definuje EMV specifikace množinu standardních zpráv v angličtině. Každá zpráva je jednoznačně identifikována pomocí dvoumístného hexadecimálního čísla. Přičemž hodnoty identifikátoru v rozmezí „01“ - „13“ reprezentují základní zprávy definované EMV specifikací (např. částka, potvrzení částky, platba přijata, platba odmítnuta, zadejte PIN, PIN přijat, nesprávný PIN, vložte kartu apod.). Hodnoty identifikátorů zpráv v rozmezí „14“ „3F“ jsou rezervovány pro budoucí použití EMV specifikací, hodnoty „40“ - „7F“ jsou rezervovány pro zprávy daného platebního systému, „80“ - „BF“ jsou rezervovány pro nabyvatele a „C0“ - „FF“ jsou rezervovány pro vydavatele karet. V jednotlivých jazykových verzích jsou přirozeně tyto standardní zprávy překládány do odpovídajícího jazyka.
Výběr aplikace Terminál podporující více než jednu aplikaci musí provádět výběr aplikace, která bude pro danou transakci použita (podrobný popis v kapitole 3.2). Terminál podporující více různých aplikací může místo automatického výběru aplikace dle priorit držiteli karty nabídnout přehled aplikací podporovaných jak čipovou kartou, tak i terminálem a držitel karty si může z tohoto přehledu aplikací vybrat tu, která bude použita pro provedení transakce. V některých případech je proveden výběr aplikace automaticky dle priorit a držitel karty je poté požádán pouze o potvrzení výběru aplikace.
Strana 48
6.3.2
Rozhraní nabyvatele
Rozhraní nabyvatele slouží především v případě, kdy je vyžadována online autorizace transakce. Zprávy s informacemi o prováděné transakci jsou typicky posílány z terminálu nabyvateli a od nabyvatele následně vydavateli karty. Obsah těchto zpráv se různí případ o případu, neboť záleží na konkrétním nabyvateli, zda bude od terminálu vyžadovat zasílání veškerých informací o transakci, popř. zda bude mít u sebe pod identifikátorem terminálu uloženy některé velmi sporadicky se měnící informace (např. kód země terminálu, kategorie obchodníka, jemuž terminál patří, apod.). Obsah zasílaných zpráv též závisí na tom, jaké informace chce nabyvatel ukládat o každé transakci (i z důvodů možného auditu apod.). Vydavatel tyto informace nemusí od nabyvatele vyžadovat, neboť se předpokládá, že vydavatel karty má přístup ke všem datům uloženým na čipové kartě identifikovaným primárním číslem účtu (tzv. Primary Account Number). Kapitola 12.1 čtvrté knihy [4] podrobně popisuje jednotlivé povinné a volitelné datové elementy zpráv přenášených z terminálu na rozhraní nabyvatele a odpovědi na tyto zprávy, konkrétně se jedná o požadavek na autorizaci, požadavek o zpracování finanční transakce a odpovídající odpovědi, zpráva s potvrzením transakce apod.
Zpracování výjimek Při zpracování transakcí může dojít k následujícím výjimečným situacím: •
Terminál nemůže pracovat online – zkontroluje se, zda je terminál schopen zpracovávat transakce offline. Pokud ano, je vydán nový příkaz pro generování aplikačního kryptogramu. V opačném případě je transakce zamítnuta.
•
Chyby autorizace – v případě, že odpověď na požadavek o autorizaci neobsahuje požadovaná autentizační data vydavatele karty, je autorizace zpracována jako by odpověď byla nesprávná. V případě, že odpověď na požadavek o autorizaci nepřijde, přijde se zpožděním nebo přijde ve špatném formátu provede se ověření, zda je možné transakci zpracovat offline. Pokud není možné ji zpracovat offline (např. pokud je terminál typu „schopen pracovat pouze online“) je transakce zamítnuta.
•
Chybné skripty – v případě, že se vyskytne chyba ve formátu, syntaxi nebo je skript příliš dlouhý, terminál přeruší zpracování skriptu a zašle identifikátor chybného skriptu v odpovědi zaslané nabyvateli.
Strana 49
7 Implementace elektronických plateb 3-D Secure do informačního systému pro sportovní centra 7.1
Popis aplikací
Implementace elektronických plateb byla vyvíjena jako rozšiřující modul již existujícího informačního systému pro sportovní centra Clubspire. Na základě požadavků zákazníků sportovních center, kteří žádali možnost plateb online, se na nás obrátili jednatelé těchto center s požadavkem implementace elektronických plateb do webového klienta informačního systému. Po několika konzultacích a porovnávání různých přístupů bylo (z důvodů co možná nejvyšší míry bezpečnosti) zvoleno 3-D Secure řešení, které v dané době (počátek roku 2008) nabízela Česká spořitelna pod názvem E-commerce 3-D Secure (dále jen 3-D Secure). V první fázi bylo tedy ve webovém klientovi informačního systému implementováno 3D-Secure řešení dle požadavků České spořitelny. Samotný vývoj tohoto modulu je popsán v jedné z následujících kapitol. Toto řešení přineslo sportovnímu centru, které mělo o možnost online plateb zájem, i jednu nepříjemnou skutečnost. Konkrétně se jednalo o absolvování netriviálního množství schůzek s Českou spořitelnou a splnění celé řady jejích administrativních a technických požadavků. Protože tento administrativní kolotoč byl náročný především na čas zaměstnanců sportovního centra (od majitelů, vedoucích pracovníků, správců sítě, až po administrátory), představoval samozřejmě i značný finanční obnos, který musel být vynaložen. Navíc v poslední fázi před podpisem smlouvy o E-commerce probíhalo testování aplikace, což v tomto případě znamenalo, že se na půdě různých sportovních center testovala funkčnost stále stejné aplikace. S přihlédnutím k této skutečnosti byl ve druhé fázi proveden návrh samostatné aplikace s názvem EPSYS, která měla fungovat jako prostředník mezi webovým klientem informačního systému Clubspire a platebním systémem České spořitelny. Dík tomuto řešení by nebylo již nutné časově náročné sepisování zvláštní smlouvy mezi každým sportovním centrem a Českou spořitelnou, ale provedlo by se pouze rozšíření smlouvy existující mezi
Strana 50
sportovním centrem a společností, která informační systém dodala. Protože, jak webový klient informačního systému, tak i EPSYS jsou dílem této společnosti, bylo by i testování správné funkčnosti této aplikace na straně sportovního centra jednodušší. V následujících kapitolách je bližší popis 3-D Secure systému České spořitelny, informačního systému pro sportovní centra Clubspire a obou aplikací.
7.2
3-D Secure
3-D Secure (Three Domain Secure) protokol byl vyvinut společností VISA, která je největším provozovatelem platebních karet na světě. Vytvoření 3-D Secure bylo reakcí společnosti Visa na neustále se zvyšující objemy finančních prostředků převáděných online transakcemi. Tento trend s sebou bohužel přinesl nárůst počtu podvodných transakcí, kdy byly prováděny online platby pomocí ukradených či zkopírovaných platebních karet neoprávněnými osobami.
Protože
poměr
podvodných
transakcí
byl
v
online
platebním
styku
několikanásobně vyšší než při běžném obchodování tváří v tvář, bylo třeba tuto situaci rychle a efektivně vyřešit. Řešením byl právě 3-D Secure protokol založený na technologii XML, který slouží ke zvýšení bezpečnosti platebních transakcí online. Držitelům platebních karet Visa je implementace tohoto protokolu nabízena jako služba s názvem Verified by Visa. 3-D Secure protokol (konkrétně ve verzi 1.0.2) později přijala též druhá největší společnost zabývající se provozováním platebních karet MasterCard a implementovala jej pod názvem MasterCard SecureCode. Jak Verified by Visa, tak i MasterCard SecureCode bývají představovány ve spojení s EMV jako prostředek k bezpečnějšímu provádění online transakcí. Zároveň slouží jako prostředek přenesení odpovědnosti za podvodné transakce ze společností vydávajících kreditní karty na společnosti, které tuto technologii neimplementovaly. Odpovědnost za podvodné transakce s sebou samozřejmě nese i povinnost hradit finanční náklady spojené s takovými podvody. Při bližším popisu 3-D Secure protokolu a jeho implementace v následujících kapitolách vycházím z [6], neboť detaily k MasterCard SecureCode nejsou veřejně přístupné.
Strana 51
7.2.1
Základní aspekty 3-D Secure protokolu
Prvotním a základním stavebním kamenem celého protokolu jsou XML zprávy posílané přes SSL spojení. Toto SSL spojení je šifrované a s pomocí digitálních podpisů zaručuje autenticitu klienta i serveru, což výrazným způsobem snižuje možnost podvržení finanční transakce. 3-D Secure protokol pracuje s několika subjekty, které budou v následujícím textu této práce často zmiňovány, proto považuji za rozumné tyto subjekty blíže popsat, aby nedošlo k mylnému výkladu základních pojmů. Mezi subjekty 3-D Secure protokolu patří: •
Držitel karty – je fyzická osoba (popř. subjekt) vlastnící bankovní účet ve finanční instituci (např. v bance), která má k tomuto účtu zřízenou platební kartu Visa nebo MasterCard (popř. Visa Electron, Maestro) a je s touto kartou oprávněná provádět platby online.
•
Vydavatelská banka (banka držitele karty) – je finanční ústav, který vydal držiteli karty k jeho bankovnímu účtu platební kartu Visa nebo MasterCard (popř. Visa Electron, Maestro) s oprávněním pro provádění online plateb. Z bankovního účtu držitele karty, který má v této bance, jsou při platbě online převáděny finanční prostředky na bankovní účet obchodníka. Účet obchodníka nemusí být nutně ve stejném bankovním ústavu jako účet držitele karty.
•
Obchodník – je právnická osoba, která provozuje nějaký druh online obchodu, v němž nabízí svým zákazníkům možnost přímé platby za zboží či služby platební kartou online.
•
Nabyvatelská banka (banka obchodníka) – je finanční ústav, se kterým má obchodník sepsánu obchodní smlouvu, na jejímž základě poskytuje možnost platby online ve svém obchodě. Ve valné většině případů musí mít obchodník u tohoto bankovního ústavu zřízen bankovní účet, na nějž se převádí finanční prostředky, kterými bylo placeno online za zboží či služby v obchodníkově obchodě.
Základní koncepcí celého 3-D Secure protokolu je propojení autorizace finanční transakce s online autentizací držitele karty. Princip této koncepce je založen na modelu tří domén (Three Domain Model), který je popsán níže.
Strana 52
7.2.2
Model tří domén (Three domain model)
Model tří domén umožňuje vydavatelům karet autentizovat jednotlivé držitele karet během online nákupů. Nabyvatelské banky mají zase k dispozici framework, který zahrnuje celou škálu technických přístupů, jak nabídnout obchodníkům (potažmo jejich zákazníkům) bezpečnější a pohodlnější způsob plateb online. Jak sám název napovídá, tento model používá a rozděluje zodpovědnost za jednotlivé kroky finanční transakce mezi následující 3 domény: •
Doména vydavatele (Issuer Domain) – především držitel karty a jeho banka (vydavatelská banka). Tato doména je zodpovědná za správu přihlašování držitelů vydaných karet do 3-D Secure systému (včetně ověřování identity držitele karty) a autentizaci držitele karty během online nákupu.
•
Doména nabyvatele (Acquirer Domain) – především obchodník a jeho banka (nabyvatelská banka). Tato doména je zodpovědná za definování procesu, který slouží k prokázání identity nabyvatele. Tento proces slouží k tomu, aby si obchodník, účastnící se online transakcí, ověřil, že jedná s bankou s níž má sepsanou obchodní smlouvu. Dále je tato doména zodpovědná za zpracování autorizovaných transakcí.
•
Komunikační doména (Interoperability Domain) - zprávy, které jsou posílány mezi vydávající a nabyvatelskou společností. Tato doména usnadňuje přenos zpráv mezi předchozími dvěma doménami pomocí běžných protokolů a sdílených služeb.
Tyto tři domény názorně zachycuje následující obrázek.
Strana 53
Obrázek 7.1: Model tří domén (upraveno z [6])
Předchozí obrázek zároveň demonstruje základní směry předávání zpráv v rámci jednotlivých domén i mezidoménovou komunikaci. Konkrétně se jedná o zprávy zasílané mezi doménou vydavatele a nabyvatele v rámci komunikační domény přes internet (tyto zprávy obsahují požadavek k provedení autentizace a výsledek autentizace držitele karty). Dále zprávy posílané v rámci domény vydavatele mezi držitelem karty a vydavatelskou bankou, které umožňují vlastní provedení autentizace držitele karty. Poté též zprávy umožňující vlastní autorizaci a zpracování finanční transakce mezi obchodníkem a nabyvatelskou bankou v rámci domény nabyvatele. A nakonec zprávy umožňující autorizaci a zpracování finanční transakce mezi nabyvatelskou a vydavatelskou bankou, které v případě společnosti Visa putují v rámci komunikační domény přes síť s vysokou mírou zabezpečení VisaNet. Každá ze tří domén ve stejnojmenném modelu v sobě zahrnuje několik samostatných subjektů (entit). V předchozím obrázku byly pro přehlednost uvedeny jen ty nejdůležitější. V následujícím textu jsou entity jednotlivých domén popsány podrobněji spolu se stručným popisem jejich role v 3-D Secure.
Strana 54
Entity domény vydavatele a jejich funkce jsou následující: •
Držitel karty – nakupuje online, přičemž při zadávání platby poskytuje nabyvatelské bance informace o své platební kartě (číslo karty, datum expirace apod.). Dále pro autorizaci celé transakce musí zadat tajné informace, které jsou nutnou součástí autentizace držitele karty zapojené do 3-D Secure systému.
•
Webový prohlížeč držitele karty – vystupuje jako prostředník při transportu zpráv mezi webovým obchodem (webovou aplikací obchodníka, která patří do domény nabyvatele) a serverem pro kontrolu přístupu (na straně domény vydavatele).
•
Další komponenty spravované držitelem karty – v některých případech jsou možnosti prohlížeče podporovány ještě dalším hardwarovým zařízením, popř. softwarem. Například použití čipové karty vyžaduje další software na straně uživatele popř. čtečku karet. V případě implementace autentizace držitele karty pomocí hesla (což je v současné době nejrozšířenější způsob autentizace) by neměl být vyžadován žádný dodatečný software nebo hardware.
•
Vydavatelská finanční instituce (banka držitele karty), která vydala platební kartu Visa nebo MasterCard a je registrovaným členem odpovídající asociace (Visa nebo MasterCard). Tato instituce vstupuje do obchodního vztahu s (budoucím) držitelem karty pro možnost vydání platební karty, určuje způsobilost držitele karty k účasti v 3-D Secure službě, určuje rozsah identifikačních čísel platebních karet, které se mohou účastnit 3-D Secure, poskytuje data o výše zmíněných číslech platebních karet serverům karetních asociací (tzn. v případě společnosti Visa poskytuje tato data Visa Directory Serveru) a provádí registraci platebních karet do systému 3-D Secure.
•
Server pro kontrolu přístupu (Access Control Server) ověřuje, zda je pro konkrétní číslo platební karty nadefinován způsob 3-D Secure autentizace držitele karty, provádí autentizaci držitele karty pro konkrétní transakce nebo poskytuje důkaz o pokusu o autentizaci v případě, že autentizační služba není dostupná. Ačkoliv se může zdát, že výše popsané funkce jsou prováděny jedním (logickým) serverem pro kontrolu přístupu, v praxi je provádění těchto operací rozděleno dle jednotlivých funkcí (popř. dle rozsahů čísel platebních karet) mezi několik různých fyzických serverů.
Strana 55
Entity domény nabyvatele a jejich funkce jsou následující: •
Obchodník - webová aplikace obchodníka zpracovává celý průběh nákupu a poté předává podklady pro provedení platby své bance. Po autentizaci držitele karty, probíhá ověření správnosti odeslaných informací mezi obchodníkem a jeho bankou. Pokud jsou tyto informace v pořádku, proběhne autorizace celé transakce. Webová aplikace obchodníka poté musí zpracovat informaci o úspěšnosti (popř. neúspěšnosti) celé finanční transakce a výsledek celé transakce oznámit držiteli karty zobrazením odpovídající webové stránky.
•
Banka obchodníka (nabyvatelská banka) - finanční instituce (banka), která je registrovaným členem odpovídající asociace (Visa nebo MasterCard), vstupuje do obchodního vztahu s obchodníkem pro možnost přijímaní platebních karet, určuje, zda je obchodník způsobilý k účasti v 3-D Secure službě, přijímá požadavky k autorizaci od obchodníka a tyto předává autorizačnímu systému (v případě společnosti Visa je to VisaNet), poskytuje obchodníkovi výsledek autorizace a zasílá dokončené transakce k uložení do zálohovacího systému (což je v případě společnosti Visa VisaNet).
Entity operující v rámci komunikační domény jsou závislé na konkrétní implementaci protokolu 3-D Secure, v případě společnosti Visa jsou následující: •
Visa adresářový server (Visa Directory Server) – dostává zprávy s dotazem na určité číslo karty od obchodníků, určuje zda je dané číslo karty zapojeno do 3-D Secure systému, směruje požadavek na autentizaci držitele karty na příslušný server pro kontrolu přístupu (Access Control Server), získává odpověď od tohoto serveru (tzn. zda je dostupná autentizace pro držitele této karty) a odpověď přeposílá obchodníkovi.
•
Komerční certifikační autorita – generuje SSL/TLS klientské a serverové certifikáty.
•
Server historie autentizací (Authentication History Server) – získává zprávy od jednotlivých serverů pro kontrolu přístupu o každém pokusu o autentizaci platby (ať už byla autentizace úspěšná nebo ne) a tyto zprávy ukládá do datového skladu. Kopie těchto záznamů jsou k dispozici vydavatelské i nabyvatelské bance při řešení případných sporů.
Strana 56
•
Visa certifikační autorita – generuje vybrané certifikáty pro jednotlivé entity v 3-D Secure např. podpisový certifikát a Visa kořenový certifikát.
•
VisaNet – dostává požadavky k autorizaci od nabyvatelské banky, přeposílá je vydavatelské bance. Nabyvatelské bance poskytuje odpověď na tento požadavek k autorizaci od vydavatelské banky. Poskytuje podklady týkající se finančního vyrovnání nabyvatelské i vydavatelské bance a provádí bezpečné uložení dat týkajících se veškerých transakcí, které se v systému vyskytly.
7.2.3
Průběh finanční transakce v 3-D Secure
Běžný průběh jedné konkrétní finanční transakce v rámci 3-D Secure se sestává z posloupnosti samostatných po sobě následujících kroků, které přehledně zobrazuje následující obrázek.
Obrázek 7.2: Průběh finanční transakce v 3-D Secure systému (upraveno z [6])
Strana 57
Jednotlivé kroky průběhu jedné finanční transakce jsou následující (pořadové číslo konkrétního kroku v seznamu odpovídá číslu šipky na výše uvedeném obrázku): 1. Držitel platební karty si online vybírá zboží z nabídky obchodníka, který se účastní 3-D Secure. Poté, co nákup dokončí, má obchodník k dispozici veškeré potřebné informace, včetně čísla platební karty. 2. Plugin na serveru obchodníka poté pošle číslo karty a další informace týkající se částky, měny apod. na Visa adresářový server. 3. Visa adresářový server vyhledá příslušný server kontroly přístupu a dotáže se ho, zda je nadefinován nějaký způsob autentizace pro danou kartu. 4. Server pro kontrolu přístupu zašle Visa adresářovému serveru odpověď, zda je nadefinován nějaký způsob autentizace pro dané číslo karty. 5. Visa adresářový server přepošle tuto odpověď na plug-in na serveru obchodníka. 6. Plugin na serveru obchodníka poté pošle serveru pro kontrolu přístupu požadavek k provedení autentizace držitele karty. 7. Server pro kontrolu přístupu obdrží tento autentizační požadavek. 8. Server pro kontrolu přístupu autentizuje nakupujícího způsobem, který byl dohodnut (heslo, pin, čip apod.) 9. Server pro kontrolu přístupu poté přepošle výsledek autentizace zpět na plug-in na serveru obchodníka a zároveň provede záznam podrobností o průběhu transakce. 10. Plugin na serveru obchodníka obdrží výsledek autentizace. 11. Zkontroluje digitální podpis připojený k této zprávě. 12. Obchodník poté zpracuje výměnu autorizačních zpráv s nabyvatelskou bankou.
Strana 58
7.2.4
Registrace držitele karty do 3-D Secure
Registrace držitele platební karty je u jednotlivých provozovatelů platebních mírně karet liší. Společnost Visa dle [7] zvolila aktivní strategii přímého nabízení registrace zákazníkům při online nákupu (tzv. Activation during shopping), kdy je držiteli karty před provedením platby u autorizovaných prodejců nabídnut dialog pro registraci jeho karty do 3-D Secure systému. Vlastní průběh registrace karty do 3-D Secure se poté sestává z několika jednoduchých kroků. •
Držitel karty klikne na odkaz vedoucí k registračnímu formuláři, zobrazí se mu první část registračního dialogu. Zde musí držitel karty zadat číslo karty, platnost, bezpečnostní kód, který se nachází poblíž podpisové části karty, a emailovou adresu. Na této stránce bývá též odkaz vedoucí k vysvětlení výhod 3-D Secure nebo přímo stručný výtah z podmínek 3-D Secure a odkaz s vysvětlením bezpečnosti přenosu citlivých dat (pomocí SSL šifrovaného spojení), která jsou po držiteli karty požadovány. Pokud držitel karty požadované údaje odešle kliknutím na potvrzovací tlačítko, je ověřena korektnost těchto údajů.
•
Pokud jsou zadané údaje v pořádku je držiteli karty zobrazena stránka s výzvou k vytvoření bezpečnostního hesla spolu s návodem, jak má takové heslo vypadat (tzn. heslo by mělo být alfanumerickou posloupností bez mezer s možností zadávání i speciálních symbolů jako např. "@", "#","." apod.).
•
Poté, co si držitel karty zvolí a dvakrát po sobě zadá toto bezpečnostní heslo (dvojnásobné zadávání hesla je standardním způsobem kontroly možného překlepu), je požádán o zadání osobního pozdravu. Tento pozdrav je běžný textový řetězec, který slouží k ujištění držitele karty, že při zadávání hesla opravdu komunikuje se svou bankou. V první implementaci 3-D Secure společností Visa tento pozdrav chyběl, a protože dialog pro zadání tajného hesla potřebného k autorizaci celé transakce se zobrazoval jako jednoduché pop up okno, které se zobrazilo po zadání čísla účtu, budilo to u mnoha uživatelů nedůvěru a obavy, zda se nejedná o pokus zcizit citlivé informace. Tento problém byl vyřešen pomocí zobrazování výše zmíněného tajného pozdravu.
•
Po zadání a odeslání hesla a pozdravu je platební karta zařazena do 3-D Secure systému a tím pádem je i mnohem lépe chráněna před možným zneužitím při
Strana 59
platbách online. Zároveň pokud chce kartou online platit osoba, která není oprávněným držitelem karty, povede se jí to jen v případě, že má kartu u sebe (nebo má zkopírované veškeré informace na kartě uvedené) a zároveň zná tajné heslo.
Dle oficiálních stránek společnosti MasterCard [8] držitelé karet této společnosti musí sami projevit zájem o registraci do 3-D Secure a najít si příslušný odkaz vedoucí k registračnímu formuláři na stránkách společnosti, která kartu vydala. Nutno poznamenat, že ne všechny finanční instituce vydávající platební karty jsou zapojeny do 3-D Secure systému a nabízejí možnost zapojení konkrétní karty do 3-D Secure systému.
Strana 60
7.3 7.3.1
Informační systém pro sportovní centra Stručný popis funkčnosti informačního systému
Informační systém pro sportovní centra Clubspire je komplexní informační systém, který byl navržen speciálně pro správu chodu sportovních center (golfových klubů, wellness center, fitness center apod.). V průběhu času byl a je neustále rozšiřován o další moduly dle potřeb a požadavků sportovních zařízení, které jej používají. Na přiloženém CD je ukázka uživatelského rozhraní Clubspiru (soubor CLUBSPIRE.png). Mezi hlavní moduly tohoto informačního systému v současné době patří: •
pokladní systém – evidující veškeré finanční operace na pokladnách,
•
rezervační systém – umožňující zadávání zákaznických rezervací pro jednotlivá sportoviště centra,
•
evidence zákazníků – umožňující evidenci informací o jednotlivých zákaznících sportovního centra a jejich aktivitě v centru,
•
skladové hospodářství – evidující pohyby skladových zásob a tisky přehledů,
•
manažerské výstupy (různé přehledy pohybů financí, skladových zásob apod.) – umožňují lepší plánování a efektivnější řízení,
•
správa uživatelských účtů – umožňující přesně nadefinovat skupiny uživatelů a těmto skupinám přiřadit přístupová práva dle potřeb centra,
•
ovládání zařízení – umožňující automatické ovládání některých zařízení (mimo jiné např. spuštění solária, vířivé vany, šuplíku pokladny, otevírání vstupních dveří a rozsvěcení světel na kurtu),
•
ovládání vstupů – umožňující automatické odbavení zákazníka bez obsluhy, neboť umožňuje nadefinovat akce (např. zaúčtování vstupu, vygenerování rezervace apod.), které se provedou při průchodu osoby vybraným turniketem,
•
systém čipových karet a klíčenek – umožňující přiřazování klíčenky či čipové karty zákazníkovi, což slouží především ke zrychlení odbavení zákazníka,
•
podpora účtování plateb v několika různých měnách (např. v korunách i v eurech).
Strana 61
Na základě požadavků sportovních center byl v informačním systému implementován systém tzv. depozitu, který bude v následujících kapitolách neustále zmiňován. Depozit zde představuje kredit (finanční částku), který si zákazník centra předplatil (nakoupil). Při platbě účtu za služby sportovního centra je pak zákazníkovi tento kredit snížen o odpovídající částku. Informační systém též umožňuje nadefinovat slevy a výhody, které zákazník získá v případě, že depozit v určité výši.
7.3.2
Technická specifikace informačního systému Clubspire
Informační systém Clubspire je informační systém vytvořený na platformě Java, tudíž je možné jej provozovat na libovolných operačních systémech, které mají nainstalovánu Javu (testován na OS Windows, Linux, Mac OS). Použití Java platformy (konkrétně J2EE – Java 2 Enterprise Edition) spolu s architekturou klient – server zajišťuje dostatečnou robustnost, bezpečnost a zároveň umožňuje vytvořit příjemné prostředí pro pohodlné ovládání při práci uživatele. Clubspire je aplikace typu klient – server, což znamená, že vlastní systém Clubspire je rozdělen na 2 samostatné aplikace, a to server a klient. Server obsluhuje veškerou aplikační logiku a pracuje s databází PostgreSQL, která obsahuje veškeré informace zpracovávané systémem. Clubspire server je nasazen a běží v aplikačním serveru JBoss, který bývá nainstalován na počítači mimo dosah obsluhy sportovního centra. Na počítačích, které má k dispozici obsluha centra, např. recepce, jsou nainstalováni pouze klienti (konkrétně Grafical User Interface klienti), což jsou grafická rozhraní sloužící především k zobrazování informací ze serveru a zadávání jednotlivých akcí obsluhou. Klientský počítač musí být síťově propojen se počítačem, na kterém běží server. Klienti se po svém spuštění připojují k běžícímu serveru Dík tomuto rozdělení je zamezeno tomu, aby obsluha nějakým nežádoucím způsobem zasáhla do chodu informačního systému. Pro možnost snadného přístupu zákazníků k aktuálním informacím o sportovním centru existuje i webový klient. Webový klient je webové rozhraní, které zákazníkovi slouží především k přehledu obsazenosti jednotlivých sportovišť sportovního centra. Pokud má zákazník zřízen uživatelský účet k přihlášení do webového klienta, může též prohlížet a případně měnit své rezervace, zadávat nové apod. Po implementaci elektronických plateb může přihlášený zákazník též provádět nákup depozitu a jeho platbu online kartou.
Strana 62
Minimální hardwarové požadavky informačního systému Clubspire Pro běh systému Clubspire je třeba, aby hardware, na nějž bude systém nainstalován, splňoval alespoň následující kritéria: •
instalace serveru - PC Pentium 2.8GHz, 1GB RAM, 2x80 GB pevný disk;
•
instalace klienta - PC Pentium 2.0GHz, 0,5 GB RAM, 40 GB pevný disk;
•
přístup do webovému klientu - PC s webovým prohlížečem (MS Internet Explorer 5.5, Mozilla Firefox 1.0, Opera 8.0 a novější verze).
Zároveň musí být na počítači klienta i serveru nainstalována odpovídající verze Javy. Pro možnost připojení ovladačů externích zařízení (ovladače solárií, vířivek, pokladních šuplíků, turniketů, světel na kurtech) musí být serverový počítač vybaven dostatečným počtem COM portů.
Strana 63
7.4
Implementace 3-D Secure řešení České spořitelny do systému
Clubspire Princip zpracování elektronických plateb v 3-D Secure systému České spořitelny je oproti výše uvedenému oficiálnímu postupu dle společnosti Visa poněkud změněn. Změny jsou směrovány především k omezení funkčnosti, která musí být implementována na straně obchodníkova serveru. Důvodem k těmto změnám je snížení pravděpodobnosti výskytu chyby, což by při zpracování online plateb mohlo znamenat nemalé finanční škody. Samozřejmě důležité je i snížení přísných bezpečnostních požadavků kladených na provozovatele online obchodu oproti případu, že by zpracovával natolik citlivá osobní data, jako je číslo platební karty apod.
7.4.1
Průběh online platby v 3-D Secure systému České spořitelny
Na rozdíl od výše uvedeného možného obecného postupu průběhu finanční transakce Česká spořitelna zvolila postup méně náročný na zpracování ze strany internetového obchodníka. Nutno podotknout, že veškerá komunikace mezi webovou aplikací obchodu a platební bránou České spořitelny probíhá šifrovaným SSL spojením spolu s použitím digitálních podpisů na obou stranách je zaručen bezpečný přenos informací a autenticita obou účastníků. Vlastní princip zpracování online platby v 3-D Secure systému České spořitelny z pohledu internetového obchodníka je následující: •
Zákazník provádí běžný online nákup, jak je zvyklý. Když nákup dokončí, klikne na odkaz k zaplacení, který mu umožní provést online platbu.
•
Zobrazí se mu stránka s možností výběru typu platební karty, kterou chce platbu provést. Česká spořitelna nabízí možnost přijímaní karet Visa, VisaElectron, MasterCard a Maestro, přičemž je otázkou obchodní smlouvy sepisované mezi obchodníkem a Českou spořitelnou, které karty bude moci obchodník přijímat. Na webové stránce s možností výběru typu karty musí též být zobrazena loga Verified by Visa a MasterCard SecureCode a text poskytovaný přímo Českou spořitelnou, který má zákazníka seznámit s výhodami a bezpečností online plateb v 3-D Secure systému.
•
Po výběru typu karty je na platební bránu České spořitelny odeslán formulář s podrobnostmi o platbě (typ karty, částka k převodu, identifikační číslo obchodníka, měna, jazyk a další.), zároveň musí být proveden záznam do obchodníkovy databáze Strana 64
o probíhající transakci. Zákazník je přitom přesměrován na stránky České spořitelny a je požádán o zadání podrobností týkající se jeho karty (číslo karty, datum expirace apod.). Zákazník při zadávání informací o kartě nemůže měnit částku převodu, ta je zaslána ze strany webového obchodu dle výše zákazníkovy objednávky. •
V případě, že je zákazníkova karta zapojena do 3-D Secure systému, je požádán o vyplnění údajů týkajících se procesu autentizace držitele karty. Autentizaci uživatele provádí vydavatelská banka, přičemž Česká spořitelna hraje roli prostředníka. Komunikace mezi vydavatelskou bankou a Českou spořitelnou je uživateli skryta.
•
Zatímco držitel karty vyplňuje údaje na stránkách České spořitelny proběhne křížová kontrola informací o platbě. Česká spořitelna zašle informace, které získala z formuláře zaslaného webovým obchodem, zpět na adresu skriptu na straně obchodníka, který provede automatickou kontrolu, zda tyto informace odpovídají těm, které původně zaslal.
•
Pokud je vše v pořádku, pošle skript na straně webového obchodu zprávu České spořitelně o výsledku ověření a zpracování transakce pokračuje dál, v opačném případě je transakce zrušena a zákazník je informován o výskytu chyby.
•
Po této křížové kontrole provede Česká spořitelna výměnu informací s finanční institucí, která kartu vydala. Jedná se především o kontrolu dostatečného objemu finančních prostředků na účtě držitele karty.
•
Pokud proběhne autentizace držitele karty i autorizace platby v pořádku, je provedena poslední křížová kontrola údajů o platbě na straně webového obchodu a zároveň je provedena úprava databáze obchodníka ohledně úspěšnosti či neúspěšnosti online transakce. Tato kontrola a úprava je opět prováděna skriptem na straně obchodníka.
•
Pokud i poslední kontrola proběhne v pořádku je platba autorizována, zákazník je o této situaci informován a poté je přesměrován na stránky webového obchodu, kde je zobrazena stránka s informací o úspěšnosti (popř neúspěšnosti) provedené platby s případnými detaily této transakce.
Zpracování transakce je v případě výskytu chyby v přenosu, chybné autentizace držitele karty nebo nesrovnalostí při křížových kontrolách dat okamžitě přerušeno, platba je označena za neúspěšnou a zákazník i obchodník jsou o této situaci informováni. Strana 65
7.4.2
Implementace online plateb kartou v Clubspire
Protože informační systém Clubspire je primárně určen pro správu chodu nejrůznějších sportovních center, tak i možnost plateb online nebyla primárně určena pro platby objednaného zboží (jako je tomu u běžného online obchodu), ale pro nákup depozitu. Depozit zde představuje kredit (finanční částku), který si zákazník v daném sportovním centru předplatil (nakoupil a zaplatil na pokladně ve sportovním centru). Při platbě účtu za služby sportovního centra je pak zákazníkovi tento kredit snížen o odpovídající částku. Implementace elektronických plateb kartou je v tomto systému určena jen a pouze pro nákup depozitu, přičemž zákazník si sám může zvolit částku, kterou má zájem nakoupit a zaplatit online. Implementace 3-D Secure řešení České spořitelny do informačního systému Clubspire si vyžádala implementaci následujících funkčních jednotek: •
Implementace entity EPlatba (Enterprise java bean 2.0 třída EPlatbaBean.java) reprezentující konkrétní online platbu v databázi Clubspire spolu s funkcemi týkajícími se vytváření, ukládání a úprav jednotlivých online plateb a generování seznamů úspěšně dokončených EPlateb pro různé přehledy týkající se tržeb centra.
•
Panel (třída PrehledEPlateb.java) pro zobrazování přehledu uskutečněných online plateb dle uživatelem zvolených parametrů v GUI klientovi, spolu s generováním podkladů pro tisk tohoto přehledu. V přehledu uskutečněných online plateb v GUI klientovi se zobrazují úspěšně dokončené e-platby. Je možné si vybrat období popř. konkrétního zákazníka, pro nějž chceme EPlatby vypsat. Dále je možné vypsaný seznam EPlateb setřídit dle jednotlivých sloupců popř. vytisknout. Pokud je v seznamu vybrána 1 konkrétní položka (EPlatba) zobrazí se v kontextovém okně (v pravé části okna Clubspire) detaily konkrétního pokladního účtu, který se k dané platbě vztahuje. Pokud je účet vztahující se k dané e-platbě smazán, nezobrazí se nic. V ostatních přehledech tržeb se EPlatby zobrazují mezi ostatními platbami kartou.
•
Dialog OnlinePlatbySettingPanel.java v GUI klientovi Clubspire umožňující nastavení parametrů, které jsou závislé na obchodní smlouvě mezi sportovním centrem (provozovatelem informačního systému) a Českou spořitelnou. Jednotlivé parametry jsou ukládány do databáze a je možné je dle potřeby měnit.
Strana 66
Obrázek 7.3: Dialog pro nastavení parametrů online plateb ◦
Parametr "Povolit online platby" ovlivňuje jednak zobrazování odkazů vedoucích ke stránce určené pro nákup depozitu ve webovém klientovi a též ovlivňuje možnost editace ostatních atributů v tomto dialogu.
◦
Parametry "Identifikační číslo obchodního partnera", "Potvrzovací heslo" a "Přijímané karty" odpovídají jednotlivým položkám obchodní smlouvy o přijímaní platebních karet, kterou sepisuje dané sportovní centrum s Českou spořitelnou. Tyto parametry ovlivňují jednak zobrazování typů platebních karet, ze kterých si zákazník může při platbě online vybírat, a zároveň se tyto parametry automaticky vyplňují do formuláře odesílaného na platební bránu České spořitelny.
◦
Parametr "Pokladna , na kterou budou účtovány online platby" musí být zvolena jedna z pokladen evidovaných v Clubspire, protože každá finanční transakce mezi sportovním centrem a zákazníkem musí být vztažena ke konkrétní pokladně (z důvodů generování veškerých přehledů týkajících se tržeb centra).
◦
Parametr "Při platbě depozitu online provést následující:" umožňuje zvolit, zda při nákupu depozitu online bude zákazníkovi pouze navýšena částka depozitu nebo se mu zároveň i prodlouží jeho platnost a aplikují se odpovídající výhody a slevy Strana 67
spojené s nákupem depozitu v určité výši. ◦
Poslední parametr "Po provedení platby pošle banka zákazníkovi potvrzující email" je opět součástí výše zmiňované obchodní smlouvy.
•
Jsp stránky a odpovídající aplikační logika, jež umožňuje zobrazení výběru typu kreditní karty, kterou bude placeno (přičemž nabízené typy karet jsou zobrazovány dle nastavení provedeném v GUI klientovi), a zadání částky depositu. Dále stránka zobrazující zadanou částku a typ platební kartu pro kontrolu překlepu, která při odsouhlasení zadaných údajů uživatelem provádí zaslání formuláře s podrobnostmi o platbě na platební bránu České spořitelny. A stránky zobrazující zprávu o úspěšnosti a neúspěšnosti platby. Jedná se o soubory ve složce „web“ na přiloženém CD.
•
Dva
kontrolní
skripty
–
Validation
a
Confirmation
skript
(soubory
ConfirmationServlet.java a ValidationServlet.java) provádějící křížovou kontrolu dat uložených v databázi oproti datům obdrženým Českou spořitelnou. Přičemž Confirmation skript provádí i generování odpovídající objednávky depozitu v systému Clubspire, úpravu parametrů entity EPlatba a uložení těchto změn do databáze. Zdrojové kódy výše zmíněných funkčních jednotek spolu s výslednou podobou webových stránek jsou uloženy na přiloženém CD ve složce „online platby“. V současné době jsou online platby distribuovány jako rozšiřující modul Clubspire, který si v případě zájmu sportovní centrum aktivuje a samozřejmě zaplatí. Online platby využívá asi 7 z 22 sportovních center v České republice, které používají systém Clubspire.
Strana 68
7.5
Návrh aplikace EPSYS
Důvody rozšíření implementace online plateb v systému Clubspire tak, aby se jich účastnila třetí strana jako prostředník mezi Českou spořitelnou a informačním systémem vybraného sportovního centra (dále jen asistované online platby), byly již vysvětleny na začátku 7. kapitoly. Projekt asistovaných online plateb dostal pracovní název EPSYS (SYStém Elektronických Plateb). Předem nutno poznamenat, že tento projekt měl za cíl především umožnit provádění online plateb i sportovním centrům, která používají informační systém Clubspire, ale zároveň nechtějí podstoupit časově náročné uzavírání smlouvy s Českou spořitelnou. V některých případech se totiž předpokládalo, že objem prostředků převáděných online nebude nijak zvlášť velký, tudíž bylo záhodno zvolit nějakou finančně i časově méně náročnou variantu implementace online plateb. Pro zjednodušení následujících textů považuji za vhodné zavést definice následujících 3 entit, které budou často zmiňovány: •
Distributor systému Clubspire – je právnická osoba, firma (popř. touto firmou pověřená osoba), která systém Clubspire vytvořila a distribuuje jej sportovním centrům.
•
Provozovatel systému Clubspire – je právnická osoba, která provozuje sportovní centrum, v němž je instalován a používán informační systém Clubspire.
•
Manažer systému EPSYS – je osoba pověřená distributorem systému Clubspire ke spravování chodu aplikace EPSYS.
Základní myšlenka byla taková, že EPSYS bude plně pod kontrolou distributora systému Clubspire. Proto bylo rozhodnuto, že systém EPSYS bude provozován jako samostatná webová aplikace, které budou přeposílány požadavky pro provedení online plateb z jednotlivých instalací Clubspire provozovaných v jednotlivých sportovních centrech. Jednou z podmínek kladených na systém EPSYS bylo, že umožní provádění asistovaných online plateb takovým způsobem, který si bude vynucovat co nejmenší zásah do informačního systému Clubspire. Systém Clubspire zároveň musí umožňovat provádění jak přímých online plateb směrovaných na bránu České spořitelny, tak i asistované online platby. Veškeré obrázky týkající se návrhu aplikace EPSYS jsou na přiloženém CD ve složce EPSYS. Z důvodů velikosti obrázků není možné je vytisknout v čitelné formě na stránku formátu A4, Strana 69
proto jsou k dispozici pouze na CD a nikoliv v přílohách práce. Po konzultaci se zadavateli projektu byl vytvořen diagram případů užití, který názorným způsobem zachycuje, jaká funkčnost je od výsledné aplikace očekávána (soubor UseCaseDiagram.png). Na základě tohoto diagramu byl vytvořena základní databázová struktura entit a digram tříd (obrázek ClassDiagram.png). Navržený princip fungování aplikace EPSYS názorně zachycuje diagram aktivit modelovaný, jehož obrázek je na přiloženém CD v soubor ActivityDiagram.png. Samotný průběh jedné konkrétní transakce je znázorněn sekvenčním diagramem (soubor PaymentProcessingSequenceDiagram.png). Z vytvořeného modelu chování vyplývá, že platba v systému EPSYS se může nacházet ve 4 stavech, které znázorňuje obrázek v souboru EPSYSPaymentStateDiagram.png. Co se týče zabezpečení aplikace EPSYS, pak je předpokládáno, že jednotliví účastníci komunikace budou používat zabezpečený https protokol a budou komunikovat pomocí digitálně podepisovaných zpráv (podpisový certifikát bude vydáván spolehlivou certifikační autoritou). Z důvodů zvýšení bezpečnosti je u každého sportovního centra evidovaného v EPSYSu uvedena i url adresa, z níž budou přicházet požadavky na provedení online plateb. V případě, že dojde k výpadku spojení mezi EPSYSem a webovým klientem Clubspire v situaci, kdy je již platba zpracována EPSYSem (tzn. platba byla Českou spořitelnou přijata, EPSYS provedl úpravu databáze, ale sportovní centrum se prozatím nezaslalo zprávu o přijetí výsledku transakce, bude v databázi EPSYSu skript, který každých 10 minut projde tabulku všech EPSYS plateb a u těch plateb, které budou potvrzeny bankou, ale zatím nepotvrzeny sportovním centrem provede opětovné zaslání požadavku na potvrzení přijetí výsledku platby sportovním centrem. Ohledně finančního vyrovnání mezi provozovatelem systému EPSYS a provozovateli sportovních center, bylo dohodnuto, že EPSYS má být schopen na základě požadavku manažera systému EPSYS automaticky generovat podklady pro tyto převody. Navržený systém je též nenáročný na úpravy potřebné v systému Clubspire. Pro implementaci asistovaných online plateb bude stačit upravit parametry dialogu pro nastavení parametrů online plateb (přidat volbu pro asistované online platby a url adresu EPSYSu). Ve webovém klientovi Clubspire bude cílová adresa, na níž jsou odesílány detaily online platby, nastavována dle voleb z tohoto dialogu. Tzn. v případě přímých plateb budou požadavky zasílány na platební bránu České spořitelny a v případě asistovaný online plateb budou zasílány na odpovídající adresu systému EPSYS, který tento požadavek zpracuje a poté přepošle na bránu České spořitelny. Zákazník pak běžným způsobem vyplní požadované Strana 70
údaje ze své platební karty a výsledek autorizace transakce bude z České spořitelny opět zaslán do systému EPSYS, který odpověď zpracuje a výsledek zašle webovému klientovi Clubspire, který zákazníkovi zobrazí stránku s informací o přijetí popř. zamítnutí platby.
Strana 71
8 Závěr Problematika bezpečného placení platebními kartami je stále aktuálním tématem. Odklon od používání karet s magnetickým proužkem k čipovým kartám umožňuje zaručení mnohem vyšší míry bezpečnosti zpracovávaných transakcí. Trend masivního šíření čipových platebních karet přináší celou řadu pozitiv. Není tak jednoduché čipovou kartu zkopírovat a čip umožňuje použití bezpečnějších autentizačních metod. Ale na stranu druhou je třeba zajistit kompatibilitu jak na straně čipových karet, tak na straně platebních terminálů a to v celosvětovém měřítku. Z tohoto důvodů vznikla EMV specifikace, která je v oblasti čipových platebních karet považována za de facto standard. Tato diplomová práce si kladla za cíl poskytnout čtenáři možnost rychlého studia obsahu EMV specifikace v českém jazyce, proto se i větší část této práce podrobně věnuje této specifikaci. Další kapitolou týkající se elektronických plateb platebními kartami jsou platby online. Z důvodů eliminace velkého množství podvodů v tomto typu platebního styku vytvořila společnost Visa International protokol 3-D Secure, který spojuje autorizaci finanční transakce s autentizací držitele karty. Tento protokol zamezuje zneužití karty pouhým zkopírováním údajů na ní uvedených (tzv. skimming), což výrazným způsobem snižuje riziko zneužití platební karty neoprávněnou osobou. 3-D Secure protokol byl implementován společností Visa International (je nabízen jako služba Verified by Visa) i společností MasterCard International jako MasterCard SecureCode. V závěrečné části této práce je uveden bližší popis fungování 3-D Secure systému v praxi, popis konkrétní implementace plateb online v rámci toho systému nabízeného Českou spořitelnou a popis návrhu aplikace EPSYS, která umožňuje provádění asistovaných online plateb. Detailní studium EMV specifikace v rámci zpracování této diplomové práce mi umožnilo se seznámit s tím, jakou netriviální množinu vlastností na různých úrovních abstrakce je třeba podrobně nadefinovat v případě, že chceme zajistit kompatibilitu a správnou funkčnost dvou hardwarových zařízení. Jako majitelku několika čipových platebních karet mě oslovila především otázka zabezpečení finančních transakcí. Poněkud mě zneklidňuje, že výběr autentizační metody držitele karty je z velké části závislý platebním systému a na rozhodnutí provozovatele terminálu, který nemusí vyžadovat žádnou formu autentizace, což samozřejmě výrazným způsobem zjednodušuje případné zneužití odcizené platební karty neoprávněnou osobou. Na druhou stranu musím uznat, že při svých cestách po Evropě jsem Strana 72
nikdy nenarazila při placení kartou na problém týkající se kompatibility. Což může znamenat, že jsem měla štěstí, ale spíše to znamená, že EMV specifikace je ve svém oboru natolik výraznou „kapacitou“, že většina platebních systémů splňuje požadavky tímto standardem kladené a tudíž umožňuje držitelům čipových karet provádět bezproblémové platby z nejrůznějších koutů světa. Při zpracování praktické části jsem si měla možnost na vlastní kůži vyzkoušet jaký je rozdíl mezi programováním běžné aplikace a programováním kódu, který v případě chyby může způsobit nemalé finanční škody. Též jsem se detailně seznámila s protokolem 3-D Secure, který výrazným způsobem znesnadňuje zneužití platebních karet v online styku. Navíc je tento protokol navržen jako výrazně uživatelsky „přítulný“ a jednoduchý ke zvládnutí i běžným uživatelem. Samozřejmě jsem do tohoto systému chtěla zapojit i své platební karty. Mé nadšení bohužel poněkud opadlo po zjištění, že ani jeden ze dvou bankovních ústavů, u nichž mám zřízen bankovní účet s platební kartou, není do tohoto systému zapojen, anebo přinejmenším nenabízí registraci platební karty do tohoto systému. Možná by stálo za to zjistit, které z českých bankovních ústavů kromě České spořitelny v současné době tento systém podporují a nabízí obchodníkům a především zda umožňují držitelům karet zapojení do tohoto systému, protože články, které jsou na toto téma na webu k dispozici, jsou všechny již několik let staré, tudíž poněkud neaktuální.
Strana 73
Literatura [1] EMVCo: EMV Integrated Circuit Card Specifications for Payment Systems, Book 1 Application Independent ICC to Terminal Interface Requirements, verze 4.2, 2008, dokument dostupný na http://www.emvco.com/specifications.aspx?id=155. [2] EMVCo: EMV Integrated Circuit Card Specifications for Payment Systems, Book 2 Security
and
Key
Management,
verze
4.2,
2008,
dokument
dostupný
na
http://www.emvco.com/specifications.aspx?id=155. [3] EMVCo: EMV Integrated Circuit Card Specifications for Payment Systems, Book 3 Application
Specification,
verze
4.2,
2008,
dokument
dostupný
na
http://www.emvco.com/specifications.aspx?id=155. [4] EMVCo: EMV Integrated Circuit Card Specifications for Payment Systems, Book 4 Cardholder, Attendant, and Acquirer Interface Requirements, verze 4.2, 2008, dokument dostupný na http://www.emvco.com/specifications.aspx?id=155. [5] Krhovják, H., Matyáš, V., Říha, Z.: Autentizace v příkladech, Masarykova univerzita, 2007, dokument dostupný na
[6]VISA International Service Association: Verified by Visa System Overview External Version 1.0.2, 2006, dokument dostupný na: [7]Visa Europe: Activation during shoping, 2005, dokument dostupný na: [8]MasterCard: MasterCard SecureCode - Credit Card Security: Safe & Secure Online Shopping, 2009, dokument dostupný na:
Strana 74
Přílohy
Obsah přiloženého CD Přiložené CD obsahuje: •
složku „obrázky“ – obsahující veškeré obrázky obsažené v této práci, popř. z této práce odkazované;
•
složku „online platby“ – obsahující soubory implementace online plateb. Nutno podotknout, že jsou zde pouze ukázkové zdrojové kódy, kterou jsou součástí komerčního informačního systému, který nelze jako celek na CD zařadit;
•
složku „EPSYS“ - obsahující obrázky návrhu aplikace EPSYS, která je rozšířením implementace online plateb;
•
soubor DiplomovaPrace.pdf – obsahující text této práce.
Strana 75
