MIGRACJA NA STANDARD EMV W POLSCE ASPEKTY ORGANIZACYJNO - TECHNICZNE

Transkrypt

1 MIGRACJA NA STANDARD EMV W POLSCE ASPEKTY ORGANIZACYJNO - TECHNICZNE Wersja 1.0 Związek Banków Polskich Forum Technologii Bankowych Grupa Robocza ds. EMV/mobilnych płatności Styczeń 2005 Grupa robocza ds. EMV / mobilnych płatności przewodniczący: Bartłomiej Śliwa (wiceprzewodniczący Prezydium FTB) sekretarz koordynator FTB RBE: Remigiusz Kaszubski (członek Prezydium FTB RBE) sekretarz grupy: Paweł Widawski (Związek Banków Polskich) kontakt: pawel.widawski@zbp.pl Copyright by Forum Technologii Bankowych, Związek Banków Polskich

2 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 2 Spis treści 1. Co to jest standard EMV Aspekty migracji EMV Aspekty migracji dla wydawcy Aspekty migracji dla akceptanta Schemat transakcji Answer To Reset ATR Application selection wybór aplikacji Initiate application inicjowanie aplikacji Read application data czytanie danych aplikacji (Offline) Data authentication (offline owa) autentykacja danych Processing restrictions walidacja aplikacji Cardholder verification weryfikacja posiadacza karty Terminal risk management zarządzanie ryzykiem przez terminal Terminal action analysis - propozycja transakcji Card action analysis wykonanie transakcji Issuer authentication autentykacja wystawcy Script processing wykonywanie skryptów Completion zakończenie Elementy standardu EMV M/Chip a VIS Zawartość aplikacji EMV Informacje związane z posiadaczem karty Informacje związane z wystawcą karty Informacje związane z bezpieczeństwem Informacje związane z zarządzaniem ryzykiem Informacje związane z obsługą transakcji Fallback RSA Tagi Bezpieczeństwo SDA a DDA Przykładowy plan projektu wdrożenia EMV - Akceptant... 37

3 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE Co to jest standard EMV Wypracowany w latach 90 przez trzy organizacje systemów płatniczych Europay, MasterCard i VISA (stąd skrót EMV) - standard technicznej kompatybilności dla kart płatniczych tych trzech organizacji opiera się na wykorzystywaniu w kartach elektronicznych z mikroprocesorem uzgodnionych parametrów i działających w szerokich, globalnych ramach współpracujących ze sobą aplikacji. Opracowanie tego standardu to praktyczny przykład wpływu globalizacji wymuszającej strategiczną współpracę konkurujących ze sobą instytucji, świadomych konieczności zawierania tego rodzaju aliansów niezbędnych dla utrzymania ich dominacji w dotychczasowej sferze ich ogólnoświatowej działalności. Wyrażona przez standard EMV technologiczna ucieczka do przodu wiodących organizacji systemów płatniczych, a w praktyce banków zrzeszonych w tych organizacjach nie dokonała się tak szybko, jak oczekiwali twórcy i promotorzy tego standardu. Niedostateczne tempo procesu migracji na EMV dotyczy zarówno jego czysto technologicznej, inżynierskiej platformy, jak i płaszczyzny biznesowej, czyli budowania przez banki nowych produktów kartowych o funkcjonalnościach znacznie bogatszych aniżeli tylko klasyczna funkcja płatnicza. Często używany przez organizacje płatnicze argument potrzeby wdrożenia standardu EMV jakim jest zmniejszenia skali nadużyć okazał się na przestrzeni minionych lat i w odniesieniu do konkretnych krajów lub regionów świata zbyt mało przekonujący. Niska dynamika migracji na standard EMV w sektorze bankowym nie byłaby faktem niepokojącym, gdyby nie dokonujący się równolegle proces ekspansji firm telekomunikacyjnych i użytkowanych przez nie specjalistycznych urządzeń zwanych często już tylko z przyzwyczajenia aparatami telefonicznymi, w których w coraz większym stopniu wykorzystuje się podobne do EMV globalne standardy techniczne. Skutkiem ich niebywale dynamicznego wdrażania i permanentnego udoskonalania jest coraz większe prawdopodobieństwo zdetronizowania przez telekomy tradycyjnych banków w roli podmiotów dostarczających usługi płatnicze oraz czerpiących z tego tytułu określone dochody.

4 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 4 Przykład ekonomicznego sukcesu telekomów to równocześnie dowód skuteczności ich biznesowej strategii i taktyki: efektywnego mariażu nowoczesnej, stale doskonalonej technologii i bardzo agresywnego marketingu (od badania rynku po kreowanie rynku nowych potrzeb konsumentów). W takim kontekście ewolucyjne dochodzenie większości banków do stosowania standardu EMV oznaczać będzie nie tylko zaprzepaszczenie efektów wspomnianej ucieczki do przodu światowych organizacji płatniczych, ale może wręcz narazić zarówno te organizacje, jak i stowarzyszone w nich banki, na postępującą marginalizację ich roli i funkcji w nowoczesnej, coraz szybciej elektronizującej się cywilizacji. Świadomość takiego scenariusza nieodległych wydarzeń powinna pobudzić aktywność większości banków do wdrażania w standardu EMV, tym bardziej, że dostępne już przykłady aktywności banków-pionierów w tym zakresie są również w większości zachęcające. Jeżeli zatem na problem wdrażania standardu EMV trzeba patrzeć nie w kategoriach odpowiedzi na pytanie czy wdrażać? lecz jak wdrażać skutecznie? to w rzeczy samej dokonaliśmy już właściwego wyboru i tej kwestii należy poświęcić większość uwagi. Przy czym znowu nie ulega wątpliwości, że ciężar tego zagadnienia nie sprowadza się do kwestii natury technicznej, gdyż pod tym względem standard EMV jest wystarczająco jednoznacznie opisany w stosownych opracowaniach inżynierskich i regulacjach wspomnianych organizacji, co służbom technicznym banków i firmom informatycznym wystarczy do podjęcia w każdej chwili odpowiednich działań na miarę przyznanych na ten cel środków finansowych. Problem leży przede wszystkim w edukacji służb marketingowych banków oraz ich biznesowego i prawnego otoczenia, w zakresie nowych możliwości jakie otworzy przed nimi technika ukryta w skrócie-zaklęciu Standard EMV. Albowiem tylko w przypadku posiadania wyedukowanych w tym kierunku pracowników, banki będą potrafiły w krótkim czasie zaoferować klientom i partnerom nowe, atrakcyjne produkty płatnicze generujące obrót finansowy uzasadniający wydatki poniesione przez bank przy przechodzeniu na produkty zgodne ze standardem EMV. Przy czym dla banków-maruderów kwestia wdrożenia EMV będzie już w pewnym momencie nie problemem efektywności ekonomicznej tego przedsięwzięcia, lecz dylematem typu być albo nie być w sytuacji ostrej walki konkurencyjnej z innymi bankami lub np. telekomami.

5 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 5 W intencji promowania edukacyjnego podejścia banków do tematyki EMV, kształcenia w tym kierunku własnych pracowników z wielu działów, pracujący w ramach Forum Technologicznego zespół ds. EMV prezentuje niniejszy raport.

6 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE Aspekty migracji EMV Migracja EMV jest procesem złożonym, obejmującym szereg obszarów, które wydawałoby się, że mają niewiele lub nic wspólnego z wydawnictwem kart i obsługą transakcji kartowych. Na poniższym diagramie przedstawiono schematycznie zagadnienia związane z działalnością hipotetycznej instytucji finansowej, która jest jednocześnie wydawcą i akceptantem kart płatniczych. W dalszej części omówione zostaną te obszary działalności, którym należy poświęcić należytą uwagę podczas procesu migracji na EMV, tak z punktu widzenia wydawcy (ang. issuer), jak i akceptanta (ang. acquirer). Na wszystkich diagramach umieszczono angielskie nazwy dla zachowania przejrzystości i zgodności z ogólnie rozumianą nomenklaturą. Cards Cards Personalization Fraud Management Host Cards Management Cardholders Management Disputes Management Merchant Contracts Management Back-Office System HSM Clearing & Settlement Authorization Switching Device Handler Visa MasterCard Domestic Network Front-End System POS ATM Imprinter (manual) Diagram 1. Obszary działania związane z wydawnictwem i obsługą kart 2.1 Aspekty migracji dla wydawcy Na Diagramie 2 zaznaczono innym kolorem te obszary związane z migracją na EMV, które szczególnie powinny zainteresować wydawcę kart.

7 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 7 Cards karty Karty są najważniejszym elementem migracji EMV i trzeba je po prostu wymienić. Tradycyjne karty z paskiem magnetycznym muszą zostać zastąpione przez karty elektroniczne zgodne ze standardem EMV. Przy okazji wymiany kart można zrewidować aktualna politykę ich wydawnictwa: ilość produktów oraz ilość różnych wzorców graficznych. Cards personalisation personalizacja kart Jeśli dana instytucja finansowa (bank) posiada własne centrum personalizacji kart tradycyjnych, to należy rozważyć przy okazji migracji na EMV, czy nie zmienić tego faktu i nie zlecić personalizacji wyspecjalizowanym centrum lub producentowi kart (ang. outsourcing). Personalizacja kart EMV wymaga dość dużych zmian w konfiguracji maszyn do personalizacji - dochodzi bowiem moduł odpowiedzialny za kodowanie układu elektronicznego karty EMV. Z faktem dołożenia nowego modułu wiąże się również konieczność aktualizacji oprogramowania personalizującego. Cards Cards Personalization Fraud Management Cards Management Merchant Contracts Management Host Cardholders Management Disputes Management HSM Clearing & Settlement Authorization Switching Device Handler Visa MasterCard Domestic Network POS ATM Imprinter (manual) Diagram 2. Migracja na EMV od strony wydawcy kart

8 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 8 Cards management zarządzanie kartami Migracja na EMV wymusza także zmiany w stosunku do tradycyjnego podejścia do generacji danych niezbędnych do personalizowania karty płatniczej. Obok tradycyjnych danych związanych z kodowaniem ścieżki I i II paska magnetycznego oraz informacji wytłaczanych na karcie, dochodzi nowa grupa danych związanych z EMV (zob. pkt 4 Zawartość aplikacji EMV). Niezbędnym staje się zatem dostosowanie istniejącego oprogramowania do zarządzania kartami do wymogów stawianych przez EMV (profile kartowe). Disputes management obsługa reklamacji Przejście z kart tradycyjnych do kart elektronicznych wprowadza także nowe elementy do procesu weryfikacji transakcji, co do których okoliczności ich wykonania lub sam fakt ich wystąpienia, są przedmiotem reklamacji. Wraz z EMV pojawiają się nowe informacje; tzw. kryptogramy, które są generowane nie przez terminal, ale przez kartę. Clearing and settlement rozliczenie transakcji Wraz z wprowadzeniem kart EMV pojawiają się nowe informacje związane z transakcjami dokonywanymi tymi kartami. Trzeba te informacje uwzględniać w raportach rozliczeniowych, szczególnie dla transakcji dokonywanych kartami innych wydawców. Authorization autoryzacja transakcji EMV to również zmiany w procesie autoryzacji transakcji online owych. To również możliwość dokonywania zmian niektórych parametrów na karcie (ang. script processing) w trakcie wykonywania operacji online. To również możliwość zablokowania/odblokowania karty.

9 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 9 Switching obsługa transakcji kart obcych Podobnie jak dla autoryzacji transakcji: nowe dane i możliwości. 2.2 Aspekty migracji dla akceptanta Na Diagramie 3 zaznaczono kolorem te obszary migracji na EMV, które szczególnie powinny zainteresować akceptanta kart. Cards Cards Personalization Fraud Management Cards Management Merchant Contracts Management Host Cardholders Management Disputes Management HSM Clearing & Settlement Authorization Switching Device Handler Visa MasterCard Domestic Network POS ATM Imprinter (manual) Diagram 3. Migracja na EMV od strony akceptanta kart. Jak widać z porównania Diagramów 2 i 3, niektóre aspekty migracji na EMV są istotne zarówno dla wystawcy, jak i akceptanta. Ponadto dla akceptanta transakcji EMV dochodzą nowe pozycje, które nie są istotne dla wydawcy kart (pod warunkiem, że wydawca nie jest także akceptantem).

10 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 10 Device handler drivery urządzeń Transakcje EMV dostarczają nowych danych, które trzeba odebrać, np. z terminala POS, przetworzyć i dalej przesłać. Dlatego też należy sprawdzić czy obecne drivery są przygotowane do obsługi tego typu transakcji, i jeśli nie, to je zaktualizować. POS ATM software and hardware gotowość terminali i bankomatów Migracja na EMV to także zmiany w wyposażeniu terminali POS i bankomatów. To wymiana urządzeń lub ich dostosowanie do obsługi transakcji dokonywanych kartami EMV (czytnik kart elektronicznych). To także wymiana oprogramowania w terminalach POS i bankomatach na takie, które obsługują transakcje zgodnie ze standardem EMV.

11 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE Schemat transakcji Przebieg typowej transakcji EMV przedstawiono schematycznie na diagramie 1. Poniżej omówiono pokrótce poszczególne etapy transakcji, w której udział bierze karta i terminal (POS lub inne urządzenie). Więcej informacji można znaleźć w specyfikacji EMV Na schemacie blokowym użyto nazw poszczególnych etapów w języku angielskim w celu zachowania przejrzystości i zgodności z nomenklaturą EMV. Answer To Reset Application selection Initiate application Data authentication Processing restrictions Cardholder verification Read application data Terminal risk mngt Terminal action analysis Online processing Card action analysis Offline processing Completion Issuer authentication Script processing Diagram 4. Ogólny schemat typowej transakcji EMV Answer To Reset ATR Jest to de facto etap nie związany z transakcją EMV (w sensie obsługi aplikacji), lecz został umieszczony na tym diagramie w celu zobrazowania całego przebiegu transakcji począwszy od włożenia karty do czytnika terminala. Z chwilą włożenia karty do czytnika (terminal POS czy inne urządzenie wyposażone w czytnik kart EMV), następuje podanie napięcia (tzw. cold reset) na styki kontaktu karty i karta odpowiada ciągiem bajtów ATR, z których każdy niesie określoną informację.

12 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 12 Generalnie ciąg tych bajtów powinien być zgodny ze specyfikacją EMV, jeśli nie jest czytnik powinien wykonać jeszcze jedną próbę tzw. warm reset. Jeśli i tym razem odpowiedź nie jest zgodna z wymaganiami EMV terminal powinien zaprzestać dalszej obsługi takiej karty. Application selection wybór aplikacji Ten etap także jest elementem przygotowawczym przed właściwą realizacją transakcji. Niemniej jednak jest on ważny dla zrozumienia złożoności całości procesu EMV. Generalnie selekcji aplikacji roboczej dokonuje się na podstawie wyboru z tzw, listy kandydatów aplikacji (ang. candidate list), które dostępne są na karcie i są obsługiwane przez dany terminal (lub inne urządzenie symulujące pracę terminala). EMV przewiduje dwa sposoby budowy listy kandydatów: Pierwszy sposób oparty jest o ideę PSE (Payment System Environment). PSE jest specyficzną, uniwersalną aplikacją, która może znajdować się na karcie a jej podstawą funkcją jest przechowywanie nazw, a raczej identyfikatorów AID, aplikacji użytkowych znajdujących się na karcie. Jeśli terminal posiada funkcjonalność PSE, to powinien, przede wszystkim, wykonać próbę selekcji z karty aplikacji, pod nazwą 1PAY.SYS.DDF01. Jeśli próba ta się powiedzie to lista kandydacka jest budowana na bazie informacji zapisanych w terminalu (identyfikatory aplikacji) i tych przeczytanych z karty. Drugi sposób to sekwencyjne przeszukiwanie karty pod kątem zawartości określonych aplikacji (AID), które obsługiwane są przez dany terminal. Jeśli lista kandydacka zawiera tylko jedną pozycję, to wybór aplikacji następuje automatycznie. Jeśli natomiast lista ta zawiera więcej niż jedną pozycję to lista ta może być wyświetlona na ekranie terminala i wybór aplikacji roboczej dokonywany jest przez operatora lub wybierana jest automatycznie aplikacja o najwyższym priorytecie. To czy wybór będzie automatyczny czy manualny zależy od konfiguracji aplikacji w terminalu. Oczywiście w przypadku, gdy lista kandydacka jest pusta, terminal przerywa pracę z kartą. W odpowiedzi na wybór aplikacji roboczej, karta przesyła do terminala szereg danych zawierających nie tylko informacje o samej aplikacji (AID, nazwę, nazwę

13 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 13 preferowaną, język preferowany przez posiadacza karty), ale również to czego karta spodziewa się ze strony terminala po to by transakcja mogłaby być wykonana. Informacje takie, o ile istnieją, zawarte są w PDOL (Processing Options Data Object List). Initiate application inicjowanie aplikacji Etap ten jest de facto pierwszym elementem transakcji EMV. Na tym etapie terminal dostarcza karcie informacje, które zostały zgłoszone przez kartę jako niezbędne do wykonania transakcji (PDOL), jak również otrzymuje z karty dodatkowe informacje o logicznej strukturze aplikacji (AFL - Application File Locator) oraz o funkcjonalności związanej ze wsparciem dla uwierzytelnienia karty i jej użytkownika oferowanej przez daną aplikację (AIP - Application Interchange Profile). Read application data czytanie danych aplikacji Na tym etapie terminal dokonuje odczytu wszystkich danych z karty, których lokalizacja została zdefiniowana w parametrze AFL, przekazanym przez kartę w poprzednim etapie. Terminal czyta tylko te rekordy z określonych plików, które zostały opisane w AFL. (Offline) Data authentication (offline owa) uwierzytelnienie danych Etap ten jest wykonywany tylko wtedy, gdy taka dana (aplikacja) oferuje określoną funkcjonalność. Informacja o tym jaki typ uwierzytelnienia danych może być wykonany jest zapisana w parametrze AIP (patrz wyżej). Oczywiście w tym przypadku ten sam typ uwierzytelnienia musi być dostępny zarówno z poziomu terminala, jak i karty. W standardzie EMV wyróżnia się trzy typy uwierzytelnienia (czwarty typ to jego brak):

14 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE CDA (Combined Dynamic Data Authentication), - DDA (Dynamic Data Authentication) - SDA (Static Data Authentication). Podane powyżej typy uwierzytelnienia zostały uszeregowane w kolejności zaawansowania i skomplikowania algorytmów, przy czym CDA zajmuje najwyższą pozycję. Specyfikacja EMV nie podaje w jakiej kolejności ma być wykonane uwierzytelnienie, podaje natomiast, że musi to nastąpić po odczytaniu danych z karty i przed zakończeniem transakcji. Każdy z typów uwierzytelnienia ma za zadanie zabezpieczyć dany system płatniczy przed fałszerstwami. I tak SDA ma na celu przede wszystkim sprawdzenie czy nie wystąpiła nieautoryzowana zmiana wartości ważnych dla bezpieczeństwa systemu płatniczego parametrów zapisanych na karcie w trakcie jej personalizacji. DDA ma na celu zapewnienie i potwierdzenie autentyczności danych znajdujących się na karcie oraz danych wygenerowanych przez kartę i danych otrzymanych z terminala w trakcie transakcji EMV. CDA dodatkowo ma zapewnić, że dane transakcji nie zostały zamienione (zmienione) w trakcie jej wykonywania. Operacje wykonywane na tym etapie bazują na kryptografii asymetrycznej RSA i w związku z tym zarówno karta, jak i terminal muszą być odpowiednio do tego przygotowane. Data Authentication wykorzystuje w praktyce ideę PKI (Public Key Infrastructure), bowiem niezależnie od typu uwierzytelnienia, do jego realizacji wymagane są klucze publiczne i prywatne oraz certyfikaty kluczy publicznych wystawione przez centra certyfikacji systemów płatniczych lub/i wydawcy karty (w zależności od typu uwierzytelnienia). Processing restrictions walidacja aplikacji Ten etap transakcji ma na celu przede wszystkim sprawdzenie przez terminal pewnych dodatkowych informacji odczytanych z karty. Sprawdzeniu poddawane są między innymi daty od kiedy (Effective Date) i do kiedy (Expiration Date) aplikacja jest aktywna (ważna). Czy wersja aplikacji obsługiwana przez kartę zgadza się z wersją aplikacji rezydującą w terminalu. Sprawdzane jest też czy dana aplikacja z

15 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 15 karty może być obsłużona w tym urządzeniu (parametr AUC Application Usage Control), np. czy aplikacja na karcie pozwala na wypłatę gotówki w bankomacie lub czy może być użyta tylko na rynku wewnętrznym. Cardholder verification weryfikacja posiadacza karty Przeprowadzenie tego etapu ma na celu zweryfikowanie czy osoba, która posługuje się daną karta, jest osobą dla której ta karta (aplikacja) została spersonalizowana. O tym w jaki sposób, np. weryfikacja kodu PIN, podpis; i w jakiej kolejności ma następować weryfikacja posiadacza karty w przypadku, gdy nie udało się zweryfikować kodu PIN, ponieważ urządzenie nie jest wyposażone w PIN-pad, decydują dane zapisane na karcie w parametrze CVM (Cardhoder Verification Method list). CVM może wskazywać na konieczność szyfrowania lub nie PINu w trakcie przesyłania jego wartości do karty. To karta weryfikuje poprawności wprowadzonego kodu PIN, a nie terminal czy host w Banku. Terminal risk management zarządzanie ryzykiem przez terminal Wykonanie tego etapu zależy poniekąd od informacji zapisanych w karcie, bowiem jeden z parametrów AIP, jeśli jest ustawiony, informuje o tym, że terminal ma wykonać ten etap procesowania transakcji EMV. Jeśli parametr ten jest nieustawiony, wówczas terminal nie ma obowiązku wykonywania tego etapu, jakkolwiek zaleca się jego wykonywanie niezależnie od tego co jest zapisane na karcie. Z uwagi na niejednoznaczność zapisów w standardzie EMV, etap ten został umieszczony niejako z boku głównego nurtu przebiegu transakcji. Zarządzanie ryzykiem przez terminal sprowadza się głównie do analizy zapisów logu transakcji (jeśli istnieje) wykonanych dla tego samego numeru PAN, losowego wymuszania transakcji w trybie on-line, wymuszania transakcji on-line w przypadku, gdy przekroczone zostały liczniki dopuszczalnej liczby transakcji w trybie off-line.

16 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 16 Terminal action analysis - propozycja transakcji W tej fazie na bazie informacji przeczytanych z karty, wprowadzonych danych przez sprzedawcę (kwota, waluta itp.), wyników przeprowadzonej analizy ryzyka, weryfikacji posiadacza karty i uwierzytelnienia danych karty, terminal podejmuje wstępną decyzję co do dalszego sposobu procesowania transakcji. Terminal może zaproponować wykonanie transakcji w trybie off-line, wykonanie transakcji w trybie on-line lub odrzucenie transakcji. Swoją decyzję terminal przekazuje do karty za pośrednictwem komendy GENERATE AC. Card action analysis wykonanie transakcji Propozycja terminala wykonania transakcji, przesłana do karty w postaci parametrów komendy GENERATE AC, jest poddawana obróbce przez samą kartę. Ma to na celu zweryfikowanie zasadności decyzji terminala, co do trybu wykonania transakcji. Karta EMV bazując na tych danych oraz na wynikach analizy ryzyka przeprowadzonej przez samą kartę jest w stanie zmienić decyzję terminala na inną. Standard EMV precyzuje, które decyzje terminala mogą być zmienione przez kartę i na jakie. Jeśli decyzja terminala była transakcja w trybie on-line, to karta może ją zaakceptować lub zmienić na odrzucenie danej transakcji. Jeśli decyzja terminala była transakcja w trybie off-line, to karta może zmienić ją na on-line lub odrzuć ją. Karta nie może zmienić decyzji terminala o odrzuceniu transakcji. Issuer authentication uwierzytelnienie wydawcy Jeśli zapadła decyzja, że transakcja ma być realizowana w trybie on-line, to musi wystąpić faza związana z wzajemnym uwierzytelnieniem karty i hosta w banku (instytucji występującej w imieniu banku lub innego wydawcy karty). Jeśli chodzi o sam proces uwierzytelnienia wystawcy, to w swej idei jest on podobny do procesu wykorzystywanego przy on-line owych transakcjach dokonywanych kartami z paskiem magnetycznym. Z tą wszakże istotna różnicą, że w przypadku kart EMV, to

17 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 17 karta posiada niezbędne informacje (klucze) i możliwości ich generowania (kryptogramy), a nie terminal, jak to ma miejsce dla kart z paskiem magnetycznym. Dla on-line owej transakcji EMV, terminal realizuje jedynie funkcję przekaźnika, który odbiera dane od hosta i przekazuje do karty lub odbiera od karty, a przekazuje do hosta. Script processing wykonywanie skryptów Jest to etap, który nie jest de facto częścią składową transakcji EMV, ale został tu umieszczony po to, by wskazać na dodatkowe możliwości karty elektronicznej. Idea script processing polega na tym, aby dać wydawcy karty możliwość dokonywania zmian pewnych parametrów na karcie w trakcie on-line owej sesji z hostem i bez konieczności odbycia przez posiadacza karty wizyty u jej wystawcy. Jakie dane (parametry) mogą być zmieniane i jakie funkcje mogą być wykonywane za pomocą tego narzędzia, nie jest przedmiotem specyfikacji EMV. Jest to raczej domena poszczególnych implementacji. Przeważnie script processing wykorzystuje się do: - blokowania/odblokowania aplikacji, - blokowania karty, - zmiany/odblokowania PIN, - zmiany parametrów związanych z CRM (Card Risk Management), - zmiany zapisów w rekordach aplikacji. Podobnie ja w przypadku Issuer Authentication, ta faza realizowana w bezpośredniej komunikacji karta host, a terminal jest tylko przekaźnikiem. Completion zakończenie Jest to ostatnia faza wykonywania transakcji EMV. Faza ta jest obowiązkowa niezależnie od tego, jak toczyły się wcześniej losy danej transakcji. Jedynym powodem, dla którego etap ten może być nie wykonany, jest błąd aplikacji. Wynikiem tego etapu jest albo TC (Transaction Certificate) w przypadku pomyślnego

18 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE. 18 zakończenia transakcji lub AAC (Application Authentication Cryptogram) w przypadku odrzucenia transakcji. Elementy standardu EMV Specyfikacja EMV (w wersji 4.0) składa się z czterech podstawowych części zwanych księgami (Book). 1. Application Independent ICC to Terminal Interface Requirements Pierwsza księga (część I i II) zawiera wymogi dotyczące fizycznych i elektromechanicznych parametrów karty i czytnika. Specyfikuje protokoły przesyłania danych pomiędzy czytnikiem i kartą. Część III opisuje struktury na karcie, rozkazy karty i algorytmy dotyczące wyboru aplikacji. 2. Security and Key Management Druga księga zawiera wymagania dotyczące bezpieczeństwa kart i urządzeń akceptujących płatności kartami. W szczególności określa ona mechanizmy offlineowej weryfikacji karty, offlineowej weryfikacji kodu PIN, mechanizmy zarządzania kluczami, generowania kryptogramów transakcyjnych oraz mechanizmy szyfrowania i uwierzytelnienia danych dla potrzeb przesyłania do karty skryptów wydawcy. 3. Application Specification Najważniejsza księga opisująca szczegółowo przebieg transakcji EMV, wraz z rozkazami przesyłanymi do karty oraz strukturami danych na karcie niezbędnymi do przeprowadzenia transakcji EMV. Zawiera szczegółową listę wszystkich znaczników danych (tagów), które mogą występować na karcie wraz z opisem ich formatów i znaczenia poszczególnych wartości.

19 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE Cardholder, Attendant, and Acquirer Interface Requirements Księga uzupełniająca, zawierająca wymagania ogólne dotyczące urządzeń akceptujących karty EMV (funkcjonalne i fizyczne np. rozkład klawiszy PINPada). Ta część standardu zawiera również propozycje architektury oprogramowania obsługującego akceptację kart EMV. Rozdział IV zawiera wymogi dotyczące interfejsu użytkownika narzucone na aplikację akceptującą karty EMV, jak również interfejsu do hosta transakcyjnego (standard nie specyfikuje tu protokołów, lecz tylko zawartość informacyjną komunikatów wymienianych z hostem). Jak każdy dokument, także specyfikacja EMV nie ustrzegła się pewnych błędów lub nieścisłości. Dlatego też EMVCo, jako organ odpowiedzialny za utrzymanie i rozwój standardu, publikuje na stronach WWW ( uzupełnienia i poprawki do specyfikacji (Specification Updates). Jednocześnie publikowane są biuletyny informacyjne i poddawane pod dyskusję propozycje rozszerzeń funkcjonalności standardu. Od roku 2000 wygenerowane zostało w ten sposób ok. 30 poprawek. W roku 2004 EMVCo opublikowało specyfikację w wersji 4.1, która stanowi kompilację specyfikacji 4.0 i obowiązujących poprawek (Specification Updates).

20 MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO TECHNICZNE M/Chip a VIS Standard EMV, który z jednej strony dobrze opisuje wymagania dla środowiska oraz przebieg transakcji, głownie na poziomie komunikacji karta terminal celem zachowania international interoperability, daje dość dużo swobody w zakresie tego jak ma wyglądać wewnętrzna struktura karty i jak karta ma obsługiwać pewne zdarzenia, z drugiej strony. Fakt ten został skrzętnie wykorzystany przez organizacje płatnicze MasterCard i VISA, które na bazie standardu EMV stworzyły własne, szczegółowe specyfikacje dotyczące struktury danych na karcie oraz niektórych algorytmów wykorzystywanych do generacji i weryfikacji kryptogramów. Konsekwencją działania MasterCard i VISA jest fakt, że dzisiaj mamy do czynienie z dwoma specyfikacjami: M/Chip dla MasterCard i VIS dla VISA. Jednak przed podaniem szczegółów dotyczących obowiązujących wersji specyfikacji M/Chip i VIS wydaje się rozsądnym, aby w kilku słowach przedstawić podstawowe różnice pomiędzy nimi. Generalnie różnice te dotyczą obszaru zarządzania ryzykiem przez samą kartę (z angielskiego Card Risk Management CRM) oraz akcji, które powinna podjąć karta w wyniku przeprowadzonej analizy ryzyka. Jeśli chodzi o różnice związane z CRM, to w specyfikacjach pojawiają się dwa nowe parametry, ponadto co jest opisane w standardzie EMV, dla M/Chip są to Lower & Upper Maximum Offline Cumulative Amount, natomiast dla VIS są to Cumulative Total Transaction Amount Limit i Cumulative Total Transaction Amount Upper Limit. Jeśli natomiast chodzi o różnice związane z tym, jak karta ma reagować na określone sytuacje, które zdarzyły się bądź to w trakcie obsługi bieżącej transakcji, bądź w trakcie poprzedniej, przerwanej transakcji, to w przypadku specyfikacji VIS jest to sterowane przez parametr, który nazywa się ADA (Application Default Action), natomiast w przypadku M/Chip jest to zestaw parametrów zawartych w CIAC (Card Issuer Action Codes). Więcej informacji na temat tego, jakie znaczenie mają poszczególne bajty i bity zarówno dla ADA, jak i dla CIAC można znaleźć w dokumentacji technicznej poszczególnych standardów. Różnice pomiędzy M/Chip a VIS były (i są nadal) na tyle istotne, że obie organizacje płatnicze MasterCard i VISA, zdecydowały się na wspieranie innych, dedykowanych otwartych systemów operacyjnych na karty elektroniczne. W przypadku MasterCard jest to system MULTOS, natomiast w przypadku VISA powstała szczególna specyfikacja Java: VISA Open Platform (VOP). Jakkolwiek oba ww specyfikacje są specyfikacjami publicznymi, do których własności