Migracja na standard EMV w Polsce aspekty organizacyjno ... · (manual) Cards Host Switching Device Handler HSM Diagram 1. Obszary działania związane z wydawnictwem i obsługą

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: [email protected] ©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


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.


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

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

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.


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


FraudManagement

DisputesManagement

MerchantContracts

Management


Authorization

POS ATM Imprinter(manual)

Cards

Host

Switching

Device Handler

HSM

Diagram 2. Migracja na EMV od strony wydawcy kart


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

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


FraudManagement

DisputesManagement

MerchantContracts

Management


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).


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

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ę.


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

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

- 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

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

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

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

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

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).


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


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


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


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)


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


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),


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.


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.


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.


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ę


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.


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


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.


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


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:


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


ICC dynamic data


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


ICC data

CID = CID

ICC

ICC

Hash1 =Hash2

GenAC 1 &


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.


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.


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.

Documents

Migracja na standard EMV w Polsce aspekty organizacyjno ... · (manual) Cards Host Switching Device Handler HSM Diagram 1. Obszary działania związane z wydawnictwem i obsługą