View
1
Download
0
Category
Preview:
Citation preview
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
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
2
Spis treści
1. Co to jest standard EMV......................................................................................... 3 2. Aspekty migracji EMV............................................................................................. 6 2.1 Aspekty migracji dla wydawcy .................................................................................... 6 2.2 Aspekty migracji dla akceptanta ................................................................................. 9
3. Schemat transakcji ............................................................................................... 11 Answer To Reset – ATR................................................................................................... 11 Application selection – wybór aplikacji ........................................................................... 12 Initiate application – inicjowanie aplikacji ...................................................................... 13 Read application data – czytanie danych aplikacji....................................................... 13 (Offline) Data authentication – (offline’owa) autentykacja danych ............................ 13 Processing restrictions – walidacja aplikacji ................................................................. 14 Cardholder verification – weryfikacja posiadacza karty .............................................. 15 Terminal risk management – zarządzanie ryzykiem przez terminal ......................... 15 Terminal action analysis - propozycja transakcji ......................................................... 16 Card action analysis – wykonanie transakcji ................................................................ 16 Issuer authentication – autentykacja wystawcy ............................................................ 16 Script processing – wykonywanie skryptów .................................................................. 17 Completion – zakończenie ............................................................................................... 17 Elementy standardu EMV................................................................................................. 18
4. M/Chip a VIS ........................................................................................................ 20 5. Zawartość aplikacji EMV....................................................................................... 23 Informacje związane z posiadaczem karty.................................................................... 23 Informacje związane z wystawcą karty .......................................................................... 24 Informacje związane z bezpieczeństwem ..................................................................... 24 Informacje związane z zarządzaniem ryzykiem ........................................................... 25 Informacje związane z obsługą transakcji ..................................................................... 27
6. Fallback ................................................................................................................ 28 7. RSA ..................................................................................................................... 29 8. Tagi ...................................................................................................................... 31 9. Bezpieczeństwo – SDA a DDA............................................................................. 32 10. Przykładowy plan projektu wdrożenia EMV - Akceptant ..................................... 37
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
3
1. 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.
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”.
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.
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
6
2. 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ą.
VisaMasterCard
Domestic Network
Back-Office System
Front-End System
CardsPersonalization
Cards
Management
CardholdersManagement
FraudManagement
DisputesManagement
MerchantContracts
Management
Clearing & Settlement
Authorization
POS ATM Imprinter(manual)
Cards
Host
Switching
Device Handler
HSM
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.
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.
Visa
MasterCardDomestic Network
Cards
Personalization
Cards
Management
CardholdersManagement
FraudManagement
DisputesManagement
MerchantContracts
Management
Clearing & Settlement
Authorization
POS ATM Imprinter(manual)
Cards
Host
Switching
Device Handler
HSM
Diagram 2. Migracja na EMV od strony wydawcy kart
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.
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.
Visa
MasterCardDomestic Network
CardsPersonalization
CardsManagement
CardholdersManagement
FraudManagement
DisputesManagement
MerchantContracts
Management
Clearing & Settlement
Authorization
POS ATM Imprinter
(manual)
Cards
Host
Switching
Device Handler
HSM
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).
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.
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
11
3. 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 2000. 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.
Terminal risk mngt
Terminal action analysis
Completion
Application selection
Initiate application
Read application data
Data authentication
Processing restrictions
Cardholder verification
Card action analysis
Issuer authentication
Script processing
Answer To Reset
Online processing
Offline 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ę.
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ę
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):
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
14
- 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
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.
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
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
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.
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
19
4. 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 (www.emvco.com) 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).
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
20
4. 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ą toLower & 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
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
21
nie roszczą sobie ani MasterCard ani VISA, to jest faktem, że każda z tych
organizacji wspiera tylko, „swoją” ulubioną platformę. Konsekwentnie za
organizacjami płatniczymi poszły firmy produkujące karty elektroniczne zgodne ze
standardem EMV. Idąc śladem organizacji płatniczych MasterCard i VISA dostawcy
kart oferują odpowiednie, dedykowane i certyfikowane, zgodnie z określoną
specyfikacją produkty kartowe.
Jak już wcześniej wspomniano, obecnie mamy do czynienie z dwoma
szczegółowymi specyfikacjami M/Chip i VIS, które na przestrzeni kilku lat istnienia
standardu EMV (pierwsze, oficjalne dokumentacje standardu EMV pojawiły się w
roku 1998), doczekały się już kilku wersji. Obecnie dla standardu M/Chip
obowiązującymi wersjami są: M/Chip 2.1 z roku 2000 i M/Chip 4.0 z roku 2001, przy
czym M/Chip występuje w dwóch odmianach M/Chip Lite i M/Chip Select. Natomiast
w przypadku standardu VIS, obowiązującymi wersjami są: VIS 1.3.2 i VIS 1.4.0
(jakkolwiek istnieje jeszcze wersja 1.3.1, to nie można jej stosować do nowych
produktów). Celem zobrazowania, jak na tle specyfikacji ogólnej EMV, posadowione
są specyfikacje szczegółowe M/Chip i VIS, podaje się dwa poniższe diagramy.
M/Chip ProgramInteroperability Specifications
EMVInteroperability Specifications
Implementation specifications
Terminal Requirements Minimum Card Requirements
EMV 2000Book 1,2,3 and 4
M-Chip LiteM-Chip Select
CB5 OTA
Diagram 5. Specyfikacja MasterCard na tle specyfikacji EMV
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
22
Diagram 6. Specyfikacja VISA na tle specyfikacji EMV
EMVInteroperability Specifications
EMV 2000Book 1,2,3 and 4
VIS 1.4Card Specification
ImplementationSpecifications VIS 1.4
Terminal SpecificationVIS 1.4
Application
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
23
5. Zawartość aplikacji EMV
W przeciwieństwie do kart z paskiem magnetycznym, które są praktycznie
pasywnym elementem dostarczającym niektóre dane dla przeprowadzenia transakcji
(głównie Cardholder Name oraz PAN i PAN S/N), karty zgodne ze standardem EMV
biorą aktywny udział w transakcji i decyzje przez nie podejmowane wpływają
bezpośrednio na to czy transakcja w ogóle będzie wykonana i w jakim trybie (on-line
lub off-line). De facto, ostatni głos w sprawie trybu obsługi transakcji ma karta, a nie
terminal.
Z punktu widzenia pełnionych funkcji, informacje przechowywane przez kartę
elektroniczną zgodną ze standardem EMV można przyporządkować do jednej z
następujących kategorii:
a. Informacje związane z posiadaczem karty
b. Informacje związane z wystawcą karty
c. Informacje związane z bezpieczeństwem
d. Informacje związane z zarządzeniem ryzykiem
e. Informacje związane z obsługą transakcji
Poniżej podano konkretne przykłady informacji należących do poszczególnych
kategorii, dokładne opisy i znaczenie pól wraz z ich etykietami znajdują się w
specyfikacji EMV 2000.
Informacje związane z posiadaczem karty
Są to przede wszystkim dane, które są niezbędne do personalizacji tradycyjnej karty
z paskiem magnetycznym. Tak więc są to m.in.
- Imię i nazwisko posiadacza karty (Cardholder Name),
- PAN (Primary Account Number)
- PAN SN (Primary Account Number Sequence Number)
Oprócz powyższych danych na karcie zapisywane są wprost informacje, które byłyby
zapisane na pasku magnetycznym, są to:
- Zawartość 1 ścieżki paska (Track 1 Discretionary Data),
- Zawartość 2 ścieżki paska (Track 2 Equivalent Data)
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
24
Dane należące do tej kategorii mogą być swobodnie czytane przez terminal, bez
spełnienia jakichkolwiek warunków wstępnych związanych z kontrolą dostępu.
Informacje związane z wystawcą karty
Ta kategoria danych pozwala jednoznacznie określić wystawcę karty i sprawdzić, czy
informacje zapisane w chwili personalizowania karty nie zostały zamienione
(zmienione) w trakcie jej użytkowania. Dane tej kategorii to przede wszystkim:
- Certyfikat klucza publicznego wystawcy nadany przez centrum
certyfikacji systemu płatniczego (Issuer Public Key Certificate),
- Wykładnik klucza publicznego (Issuer Public Key Exponent)
- Pozostała część klucza - jeśli występuje (Issuer Public Key Remainder)
- Podpisane przez wystawcę dane (Signed Static Application Data)
- Indeks klucza publicznego centrum certyfikacji systemu płatniczego
(Certification Authority Public Key Index)
Ponadto na karcie mogą być przechowywane inne dane pozwalające na identyfikację
wydawcy karty. Do tych danych należą m.in.:
- BIC (Bank Identifier Code),
- Certyfikat wystawiony przez wystawcę karty dla publicznego klucza
służącego do szyfrowania PIN (ICC PIN Encipherment Public Key
Certificate),
- Certyfikat wystawiony przez wystawcę karty dla klucza publicznego
samej karty (ICC Public Key Certificate)
Ostatnie dwie informacje plus dodatkowe dane związane z certyfikatami (eksponent i
pozostałość) występują tylko w przypadku kart typu DDA (Dynamic Data
Authenetication) lub CDA (Combined Dynamic Data Authentication).
Dane należące do tej kategorii mogą być swobodnie czytane przez terminal, bez
spełnienia jakichkolwiek warunków wstępnych związanych z kontrolą dostępu.
Informacje związane z bezpieczeństwem
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
25
Ta kategoria informacji zawiera dane, które są dostępne tylko dla systemu
operacyjnego karty i jako takie nie mogą być ani czytane przez terminal, ani też
eksportowane poza kartę.
Do danych tej kategorii należą:
- Wartość PIN (Personal Identification Number),
- Klucze 3DES dywersyfikowane per karta z kluczy-matek danego
wystawcy. Klucze te są wykorzystywane do szyfrowania kryptogramów,
uwierzytelnienia wystawcy oraz dla „secure messaging”. W zależności
od konfiguracji i zgodności ze specyfikacją M/Chip lub VIS, kluczy tych
może być od jednego do czterech na każdej karcie.
- Prywatne klucze karty dla szyfrowania PIN i dla obsługi DDA lub CDA
Dane tej kategorii są wykorzystywane do wewnętrznych obliczeń i porównań
wykonywanych przez kartę procesorową zgodną z EMV. Do świata zewnętrznego
(terminal, host w banku) przekazywane są tylko wyniki operacji na tych danych, a nie
same dane. Ze względów bezpieczeństwa również dane te, za wyjątkiem PIN, nie
mogą być zmieniane w trakcie życia karty.
Informacje związane z zarządzaniem ryzykiem
Podobnie jak w przypadku informacji związanych z bezpieczeństwem, również dane
związane z tą kategorią wykorzystywane są w większości tylko przez system
operacyjny karty. Jakkolwiek w odróżnieniu od poprzedniej kategorii dane te mogą
być w większości przypadków czytane przez terminal (funkcja GET DATA), a
dodatkowo niektóre z danych mogą być zmieniane w trakcie on-line’owego
połączenia z hostem bankowym (SCRIPT PROCESSING). To, które z danych tej
kategorii mogą być zmieniane, zależy od konkretnej implementacji systemu
operacyjnego karty i nie jest przedmiotem standardu EMV. Do danych tej kategorii,
zwanej CRM (Card Risk Management) należą m.in.:
- Licznik transakcji - ATC (Application Transaction Counter),
- Wartość ostatniego ATC, dla którego transakcja była wykonana w
trybie on-line - LATC (Last Online Application Transaction Counter),
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
26
- Liczba maksymalnie dopuszczalnych sekwencyjnie transakcji w trybie
off-line w przypadku wykonania transakcji w terminalu mającym
możliwość pracy w trybie on-line – LCOL (Lower Consecutive Offline
Limit),
- Liczba maksymalnie dopuszczalnych sekwencyjnie transakcji w trybie
off-line w przypadku wykonania transakcji w terminalu nie mającym
możliwość pracy w trybie on-line – UCOL (Upper Consecutive Offline
Limit)
Niezależnie od powyższych danych tak M/Chip, jak i VIS specyfikuje własne
dodatkowe dane należące do tej kategorii. I tak dla M/Chip (wer. 2.1) mamy
dodatkowo:
- Lower Maximum Offline Cumulative Amount,
- Upper Maximum Offline Cumulative Amount.
Natomiast w przypadku VIS 1.3.2 pojawiają się dodatkowo limity:
- CTL I (Consecutive Transaction Limit – International),
- CTL I-C (Consecutive Transaction Limit – International –Country),
- CTTAL (Cumulative Total Transaction Amount Limit),
- CTTAL Dual Currency (Cumulative Total Transaction Amount Limit),
I odpowiednio do nich liczniki :
- CTC I (Consecutive Transaction Counter – International),
- CTC I-C (Consecutive Transaction Counter – International –Country),
- CTTA (Cumulative Total Transaction Amount),
- CTTA Dual Currency (Cumulative Total Transaction Amount),
Jak widać z powyższego karta może przechowywać dużo informacji, które służądo
konfigurowania profilu karty pod potrzeby konkretnego użytkownika; np. poprzez
zmianę odpowiednich limitów. Można tego dokonać na etapie personalizacji karty
lub, co jest wygodniejsze i bardziej elastyczne z punktu widzenia zarządzania
klientami, w trakcie wykonywania transakcji on-line poprzez mechanizm SCRIP
PROCESSING.
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
27
Informacje związane z obsługą transakcji
Ta kategoria dotyczy danych, które są niezbędne do tego, aby transakcja mogłaby
być przeprowadzona. Informacje z tej kategorii są czytane w pierwszej kolejności
przez terminal celem przygotowania niejako gruntu pod przyszłą transakcję. Tutaj
można znaleźć zarówno informacje, określające rodzaj, typ i ilość aplikacji
oferowanych przez kartę, jak i parametry tychże aplikacji. Tak więc w tej kategorii
znajdziemy:
- Identyfikator aplikacji –AID (Application Identifier), i jak się aplikacja
nazywa, jakie są preferencje językowe posiadacza karty,
- Datę od której aplikacja jest ważna (Application Effective Date),
- Datę do której aplikacja jest ważna (Application Expiration Date),
- Kod waluty i jej eksponet dla danej aplikacji
- Informację o plikach, w których przechowywane są dane aplikacji –AFL
(Application File Locator),
- Informację jaką, dodatkową funkcjonalność obsługuje karta – AIP
(Application Interchange Profile),
- W jaki sposób(y) można zweryfikować czy osoba podająca się za
właściciela karty jest nią w rzeczywistości – CVML (Cardholder
Verification Method List),
- Informację, w jaki sposób ma zachować się karta w przypadku
konkretnej sytuacji, tzn. czy transakcja ma być odrzucona czy też karta
ma wymusić transkację w trybie on-line – IAC (Issuer Action Code:
Denial, Online, Default)
Jak z powyższego wynika karta elektroniczna zgodna z EMV przechowuje dość dużą
ilość różnych informacji. Szacuje się, ze dla zapamiętania i przetwarzania danych
potrzebnych do obsługi aplikacji EMV zgodnej z metodą SDA (Static Data
Authentication) potrzeba jest ok. 1,1 KB pamięci EEPROM. W przypadku karty typu
DDA lub CDA potrzebna pamięć ulega zwiększeniu i może wynosić nawet 2 KB.
Oczywiście dużo zależy od tego na ile bogaty będzie dany profil, jak długie klucze
RSA i ile tych kluczy będzie na karcie , itd.
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
28
6. Fallback
W okresie przejściowym standard EMV dopuszcza współistnienie na karcie
mikroprocesora i paska magnetycznego. Zapis na pasku magnetycznym ma
umożliwiać akceptację kart EMV w środowiskach jeszcze nie dostosowanych do
EMV. W urządzeniach zdolnych do przeprowadzenia transakcji EMV użycie paska
magnetycznego winno skutkować natychmiastowym rozpoczęciem wymiany danych
z procesorem, lub przynajmniej żądaniem włożenia karty do czytnika kart
procesorowych.
Niemniej jednak, w przypadku problemów z wymianą danych z procesorem standard
EMV w pewnych szczególnych przypadkach opcjonalnie zezwala na powrót do
paska magnetycznego. Ustępstwo to, mające na celu zabezpieczenie interesów
wystawcy karty w okresie przejściowym wdrażania EMV jest jednak zdecydowanym
osłabieniem bezpieczeństwa. W opinii grupy należy zrezygnować z możliwości
Fallback w urządzeniach gotowych do akceptacji kart EMV.
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
29
7. RSA
Standard EMV stanowi, że urządzenia inne niż bankomaty (czyli obsługowe i
bezobsługowe terminale POS) mają obowiązek przeprowadzić Offlinową
Autentyfikację Danych. Proces ten jest zdefiniowany przez standard EMV w dwóch
wariantach: Static Data Authentication i Dynamic Data Authentication. Pierwszy
wariant został przewidziany dla początkowej fazy rozwoju kart procesorowych, w
której to fazie karty nie mają możliwości obliczeń algorytmu RSA. DDA z kolei
wymaga nowocześniejszych kart wyposażonych w koprocesor kryptograficzny, co
oczywiście wpływa na ich cenę.
Offlineowe uwierzytelnienie danych ma na celu zabezpieczenie karty przed
nieautoryzowanymi modyfikacjami danych. Należy jednak stwierdzić, że SDA
zabezpieczając przed modyfikacją danych nie zabezpiecza przed swoistym
„skimmingiem”, mającym na celu spreparowanie fałszywej karty, która w środowisku
off-lineowym (tylko) będzie zachowywać się tak jak karta oryginalna.
Nasza rekomendacja: rozważyć stosowanie kart wyposażonych w możliwość
obliczeń RSA.
Standard EMV definiuje dodatkowe sposoby weryfikacji tożsamości posiadacza
karty. Technologia kart elektronicznych umożliwia bezpieczne przechowywanie na
karcie kodu PIN, a co za tym idzie weryfikację kodu PIN bez konieczności łączenia
się z wydawcą karty. Offlineowe sprawdzanie PINu możliwe jest w dwóch
wariantach: postaci tekstu jawnego (ang. Plaintext) i postaci zaszyfrowanej (ang.
Encrypted). Wersja z postacią jawną jest przewidziana dla kart, które nie są
wyposażone w możliwości obliczeń RSA (analogia do SDA). Weryfikacja PINu w
postaci zaszyfrowanej polega na zakodowaniu wartości kodu PINu kluczem
publicznym karty i przesłaniu tak zakodowanej wartości PIN w sposób bezpieczny do
karty celem weryfikacji.
Niestety, tak jak przechowywanie kodu PIN w karcie zapewnia wymagany poziom
bezpieczeństwa, tak sam proces weryfikacji PINu w postaci jawnej wymaga
przesłania jego wartości do karty w „czystej” postaci. Powoduje to, że PIN w czystej
postaci opuszcza de facto bezpieczne urządzenie, jakim jest PINPad, i pojawia się
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
30
na stykach karty elektronicznej. Styki te są stosunkowo łatwo dostępne, a
podsłuchanie transmisji danych pomiędzy urządzeniem, a kartą nie jest sprawą
skomplikowaną.
Dodatkowo należy mieć świadomość, że podsłuchanie wymiany danych z kartą
elektroniczną w trakcie transakcji EMV zawsze umożliwia uzyskanie numeru PAN,
daty ważności, czy wręcz odpowiednika ścieżki 2 karty magnetycznej (!).
Nasza rekomendacja: zdecydowanie stosować karty wyższej generacji, wyposażone
w możliwość obliczeń RSA.
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
31
8. Tagi – znaczniki
Transakcja płatnicza przeprowadzana przy użyciu karty magnetycznej różni się
zasadniczo od transakcji za pośrednictwem karty elektronicznej. Tak jak w
pierwszym przypadku karta jest tylko biernym dostawcą podstawowych danych
takich jak numer karty, data ważności czy tzw. service code i po dostarczeniu tych
danych nie pełni już żadnej (technologicznej) roli, tak karta elektroniczna jest
aktywnym (tzn. podejmującym istotne decyzje) współuczestnikiem w procesie
realizacji transakcji. Znacząco większa pojemność karty elektronicznej powoduje, że
karty EMV przechowują znacznie więcej danych, niż prosta karta magnetyczna.
Wszystkie te dane podstawowe posiadają nadane przez standard EMV identyfikatory
zwane znacznikami. Są jedno lub dwubajtowymi wartościami jednoznacznie
określającymi daną podstawową. Tak na przykład numer karty jest przechowywany
w znaczniku o wartości 0x5A, a imię i nazwisko posiadacza karty w znaczniku o
wartości 0x5F20.
Jednocześnie standard EMV stanowi, że w sytuacji napotkania nieznanego
identyfikatora znacznika, aplikacja akceptująca karty jest zobowiązana do
zignorowania go.
W związku z powyższym proponuje się zdefiniowanie dodatkowych identyfikatorów
danych, które użyte w procesie personalizacji karty mogłyby wspomóc/uprościć
realizację niektórych transakcji, jak np. usprawnić proces wystawiania faktur w
przypadku kart korporacyjnych. Umieszczenie przez wydawcę karty poniżej
wyspecyfikowanych znaczników w rekordach aplikacji EMV (odczytywanych
rozkazem ReadRecord) jest opcjonalne.
Znacznik Znaczenie
0xDF01 Nazwa organizacji posiadacza karty, dla potrzeb wystawienia faktury
0xDF02 Adres organizacji/posiadacza karty, dla potrzeb wystawienia faktury 0xDF03 Identyfikator podatkowy organizacji/posiadacza karty (tu. NIP) 0xDF04 Numer rejestracyjny pojazdu posiadacza karty 0xDF05 Identyfikator „obywatelski” posiadacza karty (np. PESEL) 0xDF06 Identyfikator posiadacza karty dla celów ubezpieczeniowych
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
32
9. Bezpieczeństwo – SDA a DDA
Jednym z ważniejszych etapów transakcji EMV jest offlineowe uwierzytelnienie karty.
Proces ten (obowiązkowy dla urządzeń, które mogą realizować transakcje w trybie
offline) ma na celu upewnienie się, że biorąca udział w transakcji karta nie została
zmodyfikowana/sfałszowana po jej wydaniu przez wydawcę. Offlineowe
uwierzytelnienie karty bazuje na kryptografii asymetrycznej (dziś jedynym
dopuszczonym algorytmem jest RSA), a jej mechanizm sprowadza się do weryfikacji
podpisu elektronicznego dostarczanego przez kartę. Pozytywna weryfikacja podpisu
oznacza uwierzytelnienie karty.
Offlineowe uwierzytelnienie karty dostępne jest w trzech wariantach: SDA (Static
Data Authentication), DDA (Dynamic Data Authentication), CDA (Combined Data
Authentication)
SDA
SDA jest najprostszą metodą uwierzytelnienia karty, w której karta nie musi być
wyposażona w możliwości obliczeń algorytmu RSA. Metoda ta pozwala nie tyle
uwierzytelnić samą kartę, co raczej dane zapisane na karcie. Cel ten jest realizowany
poprzez podpisanie przez wydawcę karty istotnych danych na karcie, przy użyciu
klucza prywatnego wydawcy karty. Wyliczony w ten sposób podpis jest umieszczony
na karcie w plikach o swobodnym dostępie. Wraz z podpisem na karcie jest
umieszczany klucz publiczny wydawcy karty w formie certyfikatu (a nie w czystej
formie). Certyfikat taki musi być uzyskany z organizacji płatniczej, której logo będzie
nosić karta po przedstawieniu w tej organizacji klucza publicznego wydawcy karty.
Uwierzytelnienie karty w trybie SDA jest realizowane w dwóch krokach:
- pierwszy krok zmierza do wyliczenia klucza publicznego wydawcy karty. Dane
konfiguracyjne urządzenia zawierają m. in. klucze publiczne organizacji płatniczych
(CA Public Key). Klucze te służą do „ekstrakcji” (drogą transformacji RSA) klucza
publicznego wydawcy karty z zawartego na karcie certyfikatu (CA IssPK certificate).
W przypadkach, gdy cały klucz publiczny wydawcy karty nie „mieści” się w
certyfikacie do rozkodowanej części klucza dodawany jest pobierany z karty IssPK
remainer.
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
33
- po uzyskaniu klucza publicznego wydawcy, urządzenie przystępuje do właściwego
uwierzytelnienia danych z karty. Realizowane jest to metodą „spotkania w środku”. Z
jednej strony z danych, które zostały podpisane, wylicza tzw. hash – funkcję skrótu
podpisanych danych. Z drugiej strony terminal (znów drogą transformacji RSA)
rozkodowuje podpis danych pochodzących z karty. Po rozkodowaniu podpisu
uzyskuje się tę samą funkcję skrótu, na tych samych danych, tyle tylko, że w tym
wypadku funkcja ta była wyliczona przez wydawcę karty w procesie personalizacji.
Jeśli te dwie wartości (wyliczona przez terminal i wyliczona przez wydawcę) są
identyczne to oznacza to, że nikt nie zmodyfikował danych na karcie od momentu jej
wydania.
Poniższy diagram przedstawia proces SDA:
Diagram 7. proces SDA
Należy jednak zauważyć, że jakkolwiek SDA uwierzytelnia dane pochodzące z karty,
to metoda ta nie zabezpiecza wydawców przed oszustwami w 100 procentach.
Symulacja (np. drogą skopiowania danych z prawdziwej karty do sprzętowego
CA IssPK certificate CA PublicKey
IssPK Remainder Podpis IssPublic Key
POS wylicza RSA
Data Hash 1
POS wylicza RSA
Data Hash 2 Dane do podpisania POS wylicza
hash
Hash1 = Hash2 ? Brak uwierzytelnienia Dane karty uwierzytelnione
Dane
Dane
z terminala POS
z karty
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
34
symulatora) zachowania prawdziwej karty w środowisku offlineowym umożliwia
realizację transakcji oszukańczych na kwoty poniżej floor-limitu terminala.
DDA
Aby zabezpieczyć się przed takim scenariuszem wystawcy kart muszą sięgnąć po
karty wyposażone w możliwość obliczania algorytmu RSA. A nie jest to proste.
Algorytm RSA mimo wszystkich swoich zalet wymaga długotrwałych obliczeń, a co
za tym idzie szybkich, czyli drogich procesorów na karcie. Karta wyposażona w
kryptoprocesor RSA będzie zawierać również klucz prywatny właściwy dla danej
karty. Klucz ten jest przechowywany w zabezpieczonej pamięci karty i nigdy nie
zostanie wydany na zewnątrz. Klucz publiczny karty (ICC Public Key) też jest i
udostępniony jest na karcie jako dana o swobodnym dostępie w formie Certyfikatu
Klucza Publicznego Karty (ICC PK Issuer Certificate). Certyfikat klucza publicznego
karty jest sporządzany w banku wydawcy przy użyciu klucza prywatnego wydawcy
karty. Tak więc dla wszystkich swoich kart (a raczej kluczy publicznych tych kart)
bank – wydawca karty pełni rolę lokalnego centrum certyfikacyjnego.
DDA wymaga trzech kroków:
- pierwszy krok, identyczny jak w SDA ma na celu uzyskanie klucza publicznego
wydawcy karty (IssPublic Key)
- po uzyskaniu klucza publicznego wydawcy karty terminal przystępuje do
dynamicznego uwierzytelnienia karty. Terminal wylicza funkcję skrótu na
podpisanych przez wydawcę danych oraz na danych dynamicznych,
unikalnych dla transakcji, których źródłem jest terminal. Jednocześnie
powyższe dane dynamiczne są przekazywane do karty. Karta również wylicza
funkcję skrótu (na podpisanych przez wydawcę danych i na danych
dynamicznych) i koduje jej wartość przy użyciu klucza prywatnego karty (ICC SK).
Tak zakodowaną wartość karta zwraca do terminala. Terminal rozkodowuje
wartość funkcji skrótu (hash). Jeśli hash otrzymany z karty jest tożsamy z tym
wyliczonym przez terminal to oznacza to dwie rzeczy:
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
35
• Dane nie zostały zmienione od momentu wydania karty (bo hash jest
zgodny)
• Karta nie została sklonowana (bo udało się rozkodować kryptogram
pochodzący z karty, co w kontekście prawidłowych certyfikatów oznacza,
że kartę wydał uprawniony do tego bank).
Schemat DDA jest przedstawiony na poniższym diagramie.
Diagram 8. Schemat DDA
CDA
Dynamiczne i statyczne uwierzytelnienie karty jest procesem niezależnym od decyzji
karty dotyczącej rezultatu transakcji (co nie oznacza, że wyniki takiego
uwierzytelnienia nie są brane pod uwagę). Jednak wobec faktu, że SDA i DDA jest
realizowane przed decyzją transakcyjną (Card Action Analysis) istnieje teoretyczna
możliwość podmienienia karty (trudne, ale możliwe) tak, aby SDA/DDA było
wykonywane przez oryginalną kartę, a decyzja (pozytywna) była podejmowana przez
kartę sfałszowaną.
Aby ustrzec się przed takim scenariuszem, twórcy standardu opracowali nową
metodę uwierzytelnienia karty : Combine Data Authentication.
CA IssPK certificate CA PublicKey
IssPK Remainder ICC PK Issuer certificate IssPublic Key
POS wylicza RSA
ICC Public Key
POS wylicza RSA
data Hash2 POS wylicza hash
Hash1 = Hash2 ? Brak uwierzytelnienia Karta i dane uwierzytelnione
Dan
Dan
z terminala POS z karty
Dynamiczny podpis karty
data Hash 1
POS wylicza RSA
terminal dynamic data
ICCdynamic data
karta wylicza RSA
ICC SK
terminal dynamic data
ICC dynamic data
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
36
Idea jest prosta: decyzja transakcyjna i uwierzytelnienie karty odbywa się w jednym
kroku, tak aby niemożliwe było podmienienie karty pomiędzy tymi dwoma procesami.
Karta informuje o rezultacie transakcji w dwóch „formach”: zakodowanej kluczem
publicznym karty i czystym tekstem. Jeśli po rozkodowaniu dynamicznego podpisu,
przesłanego z karty okaże się, że wartość funkcji skrótu jest taka sama jak wartość
wyliczona przez terminal to zyskuje się ten sam poziom zaufania do karty co w DDA.
Biorąc pod uwagę, że w CDA uwierzytelnienie karty odbyło się w tym samym kroku i
„zakodowana” decyzja karty jest tożsama z decyzją zakomunikowaną terminalowi w
„czystej” postaci terminal ma pewność, że karta nie została podmieniona po
uwierzytelnieniu karty a przed decyzją transakcyjną.
Schemat CDA przedstawia poniższy diagram:
Diagram 9. Schemat CDA
CA IssPK certificate CA
IssPK Remainder ICC PK Issuer certificate IssPublic
POS wylicza RSA
ICC Public
POS wylicza RSA
data
POS wylicza hash
Brak uwierzytelnienia Karta i decyzja karty uwierzytelniona
Dane
Dane
z terminala
z karty
ICC dynamic
data Hash
POS wylicza RSA
termina dynami dat
IC dynami dat
karta wylicza RSA
ICC
terminal dynamic data
ICC data
CID = CID
ICC
ICC
Hash1 =Hash2
GenAC 1 &
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
37
10. Przykładowy plan projektu wdrożenia EMV - Akceptant
ETAP 1: Identyfikacja wymagań (3-4 miesiące)
1.1. Powołanie przez dostawcę i klienta zespołu wdrożeniowego, w skład którego
wchodzą „sponsorzy” projektu, kierownicy projektu, konsultanci oraz
deweloperzy i administratorzy.
1.2. Pozyskanie wiedzy o EMV u klienta drogą szkoleń.
1.3. Określenie celu projektu i określenie zakresu odpowiedzialności stron za
poszczególne elementy projektu (przy uwzględnieniu testów końcowych,
serwisu posprzedażnego i ewentualnych możliwości konsultacji, w
przypadkach szczególnych).
ETAP 2: Specyfikacja, Umowy, Plan projektu (3- 4 miesiące)
2.1. Inwentaryzacja sprzętu (terminale, bankomaty) po stronie klienta, pod kątem
zgodności z EMV (poziom 1).
2.2. Inwentaryzacja oprogramowania hosta autoryzacyjnego: zapewnienie
interfejsów do urządzeń akceptujących karty (terminale, bankomaty) oraz
interfejsów do organizacji płatniczych.
2.3. Specyfikacja wymagań dotyczących aplikacji EMV – typy transakcji, obsługa
advice’ów, wybór funkcjonalności opcjonalnej.
2.4. Przygotowanie i podpisanie umowy na wdrożenie EMV (dopiero teraz !).
2.5. Przygotowanie planu projektu i określenie kamieni milowych (od strony
technicznej)
ETAP 3: Tworzenie oprogramowania EMV (6-30 miesięcy!)
3.1. Przygotowanie bibliotek EMV dla każdej z platform sprzętowych klienta (12-18
miesięcy), o ile biblioteki takie jeszcze nie są stworzone.
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
38
3.2. Certyfikacja bibliotek EMV dla każdej z platform sprzętowych klienta (3 - 6
miesięcy), o ile biblioteki takie jeszcze nie są certyfikowane
3.3. Integracja bibliotek EMV w aplikacji płatniczej, dla każdej z platform
sprzętowych klienta (4- 8 miesięcy)
3.4. Testy wewnętrzne dostawcy(1-2 miesiące)
3.5. Testy wewnętrzne klienta/odbiorcy (User Acceptance Tests 1-2 miesiące).
ETAP 4: Testy i certyfikacje End-to-End. (1-5 miesięcy)
4.1. Uzyskanie „slotów” testowych w organizacjach płatniczych, których karty będą
akceptowane
4.2. Testy zestawami kart dostarczonymi przez organizacje płatnicze, których karty
będą akceptowane.
4.3. Uzyskanie dokumentów potwierdzających fakt uzyskania certyfikacji End-To-
End.
ETAP 5: Wdrożenie aplikacji
5.1. Przeprowadzenie instalacji pilotażowych.
5.2. Roll-out aplikacji EMV.
ETAP 6: Eksploatacja aplikacji
6.1. Obsługa sytuacji standardowych, z uwzględnieniem specyfiki EMV
(dodatkowe sytuacje, przed jakimi staje posiadacz karty lub akceptant,
poszerzone możliwości analizy danych będących rezultatem działania EMV)
6.2. Obsługa sytuacji specyficznych, których charakter jest incydentalny i
nieprzewidywalny.
MIGRACJA NA STANDARD EMV W POLSCE, ASPEKTY ORGANIZACYJNO – TECHNICZNE.
39
UWAGA: Czasochłonność (tzn. koszt) rozwiązywania problemów problemów
punktow 6.1 i 6.2 jest uzależniony od wiedzy zdobytej w trakcie szkoleń w etapie 1.
Recommended