EMV protokol u kartičnom poslovanju
Tomislav Slunjski - izvanredni student
Tomislav Stanić - izvanredni student
1.Uvod
EMV označava Europay, MasterCard i Visa, tri kompanije koje su originalno napravile standard. Standardom sada upravlja EMVCo, konzorcij s jednako podijeljenom kontrolom između Visa, MasterCard, JCB, American Express, China UnionPay i Discover
EMV je tehnički standard kartica za pametno plaćanje, terminala za plaćanje i automatiziranih blagajni koji ih prihvaćaju. EMV kartice su pametne kartice (također se nazivaju kartice s čipom ili IC kartice) koje pohranjuju podatke na integriranim krugovima umjesto magnetnih traka, iako mnoge EMV kartice imaju trake. Mogu biti kontaktne kartice koje se fizički moraju umetnuti u čitač, ili beskontaktne kartice koje se mogu čitati preko kratke udaljenosti koristeći radio frekvencijsku identifikaciju (RFID) tehnologiju. Kartice koje su u skladu s EMV standardom se često nazivaju čip i pin ili čip i potpis karticama, ovisno o načinu na koji se ovjeravaju prilikom korištenja.
Postoje standardi baziran na ISO/IEC 7816 za kontaktne kartice, i standardi bazirani na ISO/IEC 14443 za beskontaktne kartice (PayPass, PayWave, ExpressPay)
2. Autentikacija podataka
2.1. Statička autentifikacija podataka SDA
Lokalna statička autentifikacija podataka se vrši pomoću terminala koji koristi shemu digitalnog potpisa bazirano na tehnikama javnog ključa kako bi potvrdio legitimnost kritičnih ICC statičnih podataka. Ovo otkriva neautorizirane promjene podataka nakon personalizacije.
Jedina forma ovjeravanja offline statičkih podataka je Statička Ovjera (SDA – Static Data Authentication) koja verificira podatke koje identificira Application File Locator i opcionalno Static Data Authentication Tag List.
SDA zahtjeva postojanje certificiranja, od strane jako sigurnih kriptografskih ustanova koje potpisuju javne ključeve izdavača.
Svaki terminal u skladu s ovom specifikacijom mora sadržavati odgovarajuću certifikaciju javnog ključa(eve) za svaku uporabu prepoznatu od strane terminala.
Ova specifikacija dopušta da više AID-ova (Application Identifier) dijele isti set certificiranih javnih ključeva. Odnos između podataka i kriptografskih ključeva je prikazan na slici 1.
Kako bi podržavao SDA, svaki terminal će biti u mogućnosti pohraniti šest certificiranih javnih ključeva po RID-u (Registered Application Provider Identifier) i povezat će se sa svakim takvim ključem povezanu ključ informaciju koja se koristi s ključem (tako da se terminali u budućnosti mogu podržavati višestruke algoritme i omoguće evolucijsku tranziciji od jednog do drugog). Terminal će biti u mogućnosti locirati takav ključ (i ključ povezane informacije) s obzirom na RID i certificiranja indeksa javnog ključa koje osigurava ICC.
2.2.Lokalna Dinamička autentifikacija podataka DDA
Lokalnu dinamičku autentifikaciju podataka vrši terminal koristeći shemu digitalnog potpisa bazirano na tehnikama javnog ključa za autentificiranje ICC i potvrdu legitimnosti kritičnog ICC-stanovnik/generiranih podataka i podataka koji se primaju od terminala. To isključuje krivotvorenje bilo kakve kartice.
Postoje dva oblika lokalne dinamičke autentifikacije podataka: Dinamička autentifikacija podataka (DDA – Dynamic Data Authentication) koja se vrši prije analize akcije kartice, gdje čip generira digitalni potpis na podatcima koji se nalaze na čipu identificiranih od strane ICC Dynamic Data i podataka primljenih od terminala identificiranih od strane DDOL (Dynamic Data Authentication Data Object List). Dynamic Data Authentication/Application Cryptogram Generation izvršena na izdavanju prvog i drugog GENERATE AC naredbe. U slučaju Transaction Certificate (TC) ili Authorisation Request Cryptogram (ARQC), čip generira digiralni potpis na podatke koji se nalaze na čipu koje identificira ICC Dynamic Dana koji sadrži TC ili ARQC, i nepredviđeni broj kojeg generira terminal.
AIP označava opcije koje čip podržava.
Lokalna dinamička autentikacija podataka zahtjeva postojanje certificiranja, od strane jako sigurnih kriptografskih ustanova koje potpisuju javne ključeve izdavača. Svaki terminal u skladu s ovom specifikacijom sadržavat će prikladnu certifikaciju javnog ključa(eva) za svaku primjenu prepoznatu od terminala. Specifikacija dopušta više AID-ova da dijele isti set certificiranja javnih ključeva. Odnos između podataka i kriptografskih ključeva prikazan je na slici 2.
Kako bi podržavao SDA, svaki terminal će biti u mogućnosti pohraniti šest certificiranih javnih ključeva po RID-u (Registered Application Provider Identifier) i povezat će se sa svakim takvim ključem povezanu ključ informaciju koja se koristi s ključem (tako da se terminali u budućnosti mogu podržavati višestruke algoritme i omoguće evolucijsku tranziciji od jednog do drugog). Terminal će biti u mogućnosti locirati takav ključ (i ključ povezane informacije) s obzirom na RID i certificiranja indeksa javnog ključa koje osigurava ICC.
2.3.Kombinirana dinamička autentifikacija podataka/ Generiranje aplikacijskog kriptograma CDA
CDA se sastoji od dinamičnog potpisa kojeg generira čip (slično kao DDA li uključuje Application Cryptiogram (AC) generiranje) kojeg prati verificiranje potpisa od strane terminala. To je primjenjivo na obje prvu i drugu GENERATE AC naredbu i zahtjva pronalaženje relevantnih javnih ključeva. Budući da javni ključevi nisu potrebni sve dok se CDA potpis ne verificira kao dio procesuiranja odgovora na prvu GENERATE AC naredbu, pronalaženje javnih ključeva može se dogoditi u bilo koje vrijeme prije provjere CDA potpisa. Prilikom pronalaženja javnih ključeva, pogreške mogu dovesti do neuspjeha CDA. U ovim greškama je uključen, ali nije ograničeno na neuspjeh pronalaženja javnog ključa i nevažećim formatima zapisa koje treba autentificirati. Za prvu GENERATE AC naredbu, i za drugu GENERATE AC naredbu u slučaju kada nije moguće ići u online obradu, tip kriptograma zahtjevan od strane terminala je uvijek određen od strane finalnog Terminal Action Analysis koji prethodi GENERATE AC naredbu. Kada se GENERATE AC naredba izda sa CDA zahtjevom, i ako se naknadno otkriju bilo koje gornje greške, eventualni rezultat će bili lokalna odbijenica
2.4.Enkripcija osobnog identifikacijskog broja (PIN)
Ako je podržano, osobni identifikacijski broj (PIN – Personal Identification Number) enkripcija za loklanu PIN verifikaciju se vrši od strane terminala koristeći asimetričnu bazu enkripcijskog mehanizma kako bi osigurao siguran transfer PIN-a od sigurne podloge za pin u čip. Preciznije, čip će posjedovati par javnih ključeva povezanih s enkripcijom PIN-a. Javni ključ se koristi od strane podloge za PIN ili sigurne komponente terminala (koja nije podloga za pin) kako bi se enkriptirao PIN za verifikaciju.
Razmjena i provjera šifriranog PIN-a između terminala i čipa odvija se u sljedećim koracima.
1.PIN se unosu u plaintext formatu na PIN podlogu i PIN blok je konstruiran
2.Terminal izdaje GET CHALLENGE naredbu čipu kako bi dobio nepredviditi 8-bajtni nepredvidljiv broj sa čipa. Kada je odgovor na GET CHALLENGE naredbu bilo što drugo osim 8 bajtnog podatka s SW1 SW2 = '9000', onda terminal smatra da je lokalni šifrirani PIN CVM nije uspio. 3.Terminal generira nasumičnu postavu koja se sastoji od N – 17 bajtova, gdje je N dužina javnog ključa u bajtovima koji će se koristiti za šifriranje PIN. Vrijednost nasumične postave bit će nepredvidljiva iz perspektive napadača (čak i sa znanjem prethodnih pokušaja) a prije šifriranja postojat će samo u hardveru sposobnom za čuvanje plaintext PIN-a. ZA svako šifriranje sve vrijednosti bi trebale imati jednaku šansu za generiranje. To se može postići koristeći generatorom slučajnih brojeva koji je u skladu s ISO/IEC 18031 i testiran koristeći NIST SP 800-22A.
4.Koristeći PIN šifriranje javnog ključa ili dohvaćanje javnog ključa čipa, terminal primjenjuje RSA Recovery Function na podatke kako bi dobio šifrirane PIN podatke.
5.Terminal izdaje VERIFY naredbu uključujući i šifrirane PIN podatke dobivene u prethodnom koraku.
6.S privatnim ključem čipa, čip primjenjuje RSA Signing Function na šifrirane PIN podatke kako bi dobio natrag plaintext podatke.
7.Čip verificira je li čipov nepredvidljivi broj kojeg je dobio natrag jednak onome koje je čip generirao s GET CHALLENGE naredbom. Ako nije, lokalni šifrirani PIN nije uspio.
8.Čip verificira je li Dana Header kojeg je dobio natrag jednak '7F'. Ako nije, lokalni šifrirani PIN nije uspio.
9.Čip verificira je li PIN uključen u obnovljenom PIN bloku odgovara PIN-u pohranjenom u čipu. Ako nije, verifikacija pina nije uspijela.
Ako su svi gornji koraci uspješno izvršeni, šifrirana PIN verifikacija je uspješna.
2.5.Aplikacijski kriptogram i autentifikacija izdavača kartice
Generiranje aplikacijskog kriptograma
Odabir podataka
Aplikacijski kriptogram sastoji se od Message Authentication Code (MAC) generiranog preko podataka referenciranih u čipovim DOLs i odašiljane s terminala na čip u GENERATE AC ili nekoj drugoj naredbi, i pristupljeno interno od strane čipa.
Algoritam aplikacijskog kriptograma
Metoda za generiranje aplikacijskog kriptograma za ulaz uzima unikatni 16-bajtni čipov Application Cryptogram Master Key MKAC i podatke odabrane prema opisu u prethodnom odjeljku, i onda izračuna 8-bajtni aplikacijski kriptogram u dva koraka: 1. Uzme derivaciju sesije ključa da izvuče 16 – bajtni Application Cryptogram Session Key SKAC iz čipovog MKAC i čipov 2-bajtni Application Transaction Ccounter (ATC). 2. Generira 8-bajtni aplikacijski kriptogram primjenom MAC algoritma na podatke označene koristeći 16-bajtni Application Cryptogram Session Key izvućen u prethodnom koraku.
Autentifikacija izdavača kartice
Podržane su dvije metode za generiranje ARPC koje koristi autentifikacija izdavača kartice.
ARPC Metoda 1
ARPC Metoda 1 za generiranje 8-bajtnog ARPC sastoji se od primjene Triple-DES algoritma na: - 8-bajtni ARQC kojeg čip generira - 2-bajtni Authorisation Response Code (ARC)
Koristeći 16-bajtni Application Cryptogram Session Key SKAC na sljedeći način: 1. Obložiti 2-bajtni ARC sa šest nul bajtova kako bi dobili 8-bajtni broj X:=(ARC ||'00'||'00'||'00'||'00'||'00'||'00'||'00') 2. Izračunati Y:= ARQC + X. 3. I onda dobijemo 8-bajtni ARPC := DES3(SKAC)[Y]
ARPC Metoda 2
ARPC Metoda 2 za generiranje –bajtnog ARPC sastoji se od primjene MAC algoritma na: - 8-bajtni ARQC (kojeg čip generira) - 4-bajtni binarni Card Status Update (CSU) - 0-8 bajtni binarni Proprietary Authentication Data
Koristeći 16-bajtni Application Cryptogram seession key SKAC na sljedeći način: 1.Spojiti ARQC, CSU i Proprietary Authentication Dana
Y:=ARQC || CSU || Proprietary Authentication Dana
2. Generirati MAC preko podataka Y primjenom MAC algoritma na podatke definirane gore koristeći 16-bajtni Application Cryptogram Session Key izvedenog prilikom računanja ARQC. Za ovu primjenu MAC algoritma, MAC se računa prema ISO/IEC 9797-1 Algoritam 3, a parametar s je postavljen na 4, time dajući 4-bajtni MAC
ARPC :=MAC:=MAC algoritam(SKAC)[Y]
3. Podaci za autentifikaciju izdavača kartice se formiraju spajajući rezultate 4-bajtne ARPC, 4-bajtne CSU i Proprietary Authentication Data.
Podaci za autentifikaciju izdavača kartice := ARPC ||CSU ||Proprietary Authentication Data
2.6.Sigurno komuniciranje porukama
Ciljevi sigurnog slanja poruka su osiguravanje tajnosti podataka, integritet podataka i autenifikacija pošiljatelja. Integritet podataka i autentifikacija izdavača se postižu koristeći MAC. Povjerljivost podataka se postiže koristeći šifriranje polja podatka.
Formati sigurnog komuniciranja porukama
Format 1
Sigurno komuniciranje porukama prema ISO/IEC 7816-4, gdje se polje podataka zahvaćenog naredbom koristi Basic encoding Rules – Tag Length Value (BER-TLV) šifriranje i pravila šifriranja ASN.11/ISO 8825-1 strogo primijeniti.
Format 2
Format sigurnog komuniciranja porukama gdje se polje podataka zahvaćeno naredbom ne okoristi BER-TLV šifriranje za sigurno komuniciranje porukama, ali ga može koristiti za druge svrhe. U ovom slučaju, objekti podataka zadržani u polju podataka su odgovarajućih dužina od ovih objekata podataka i bit će znani od pošiljatelja naredbe koristeći sigurno komuniciranje porukama i znat će ga trenutno oznažena aplikacija. U skladu je s ISO/IEC 7816-4.
3. Infrastruktura javnog ključa izdavatelja certifikata
3.1.Životni ciklus javnog ključa
Životni ciklus certificiranja javnog ključa u normalnim okolnostima može biti podijeljeno na sljedeće faze:
- Planiranje
Tijekom faze planiranja, sustav za naplatu istražuje uvjete za uvođenje novih certificiranja javnih ključeva u bliskoj budućnosti. Ti uvjeti su povezani s brojem potrebnih ključeva i parametre tih ključeva. Važan dio faze planiranja e sigurnosni pregled kako bi se utvrdio životni vijek postojećih i novih ključeva.
- Generiranje
Ako rezultati faze planiranja zahtijevaju uvođenje novih parova certificiranih javnih ključeva, njih će generirati sustav za naplatu.
- Distribucija
U fazi distribucije ključeva, sustav za naplatu će distribuirati novo generirane certificirane javne ključeve svojim članovima.
- Korištenje ključa
Certificirani javni ključ se koristi u robnim terminalima za obavljanje lokalne statične ili dinamičke autentifikacije .
- Opoziv (planirano) Kada par certificiranih javnih ključeva dosegne svoj planirani datum isteka postavljen u fazi planiranje, mora ga se maknuti iz uporabe.
5.Sigurnost terminala i rukovanje ključevima
Ovo poglavlje opisuje zahtjeve vezane za rukovanje terminala osjetljivim podacima, kao što su kriptografski ključevi. Precizira zahtjeve za sigurnost tipkovnice za unošenje identifikacijskog broja i zahtjeve za rukovanje javnim ključevima za autorizaciju certifikata.
FIZIČKA SIGURNOST
Siguran uređaj mora biti dizajniran tako da onemogućuje fizički pristup interno-spremljenim osjetljivim podacima i da onemogućuje krađu, ne autoriziranu upotrebu ili ne autoriziranu modifikaciju opreme. Navedeni ciljevi zahtijevaju otpornost, detekciju ili mehanizme zaštite kao što su vizualni ili zvučni alarmi.
Siguran uređaj, kada ne obavlja nikakve operacije, ne bi smio sadržavati nikakve kriptografske ključeve ili druge osjetljive podatke (na primjer PIN-ove) koji su korišteni u nekoj od prethodnih transakcija. Probijanje u sistem može biti bez gubljenja sigurnosti tj. ne detektira ih uređaj, zato se takva probijanja moraju detektirati prije uređaja i prije nego što se kriptografski ključevi i osjetljivi podaci opet stave u operacijski sustav. Ako je uređaj dizajniran tako da je omogućen interni pristup, moraju se odmah osjetljivi podaci obrisati, čim dođe do probijanja u sistem. Sigurni uređaj je ovisan o fizičkoj sigurnosti što se tiče detekcije napada. Zato mora biti dizajniran tako da ima svojstva koja odmah vlasnika kartice ili trgovca upućuju na zločin.
Uređaj mora biti dizajniran i sastavljen tako da se:
- Ne može izvesti probijanje u uređaj u smislu izvođenja nekim promjena, dodataka ili zamjena sklopovske i programske opreme uređaja; ili promjene osjetljivih podataka i naknadno ponovno instaliranje uređaja bez upotrebne posebnih vještina i uređaja koji nisu generalno dostupni, i bez oštećenja uređaja tako da se ne bi moglo detektirati oštećivanje. - Svaki neautorizirani pristup ili izmjena osjetljivih podataka, koji se unose, spremaju ili obrađuju, se pripisuje samo aktualnom probijanju uređaja. - Nije omogućeno na bilo kakav način krivotvorenje i izrađivanje sličnih komponenti od kojih je uređaj sastavljen. - Kvar na bilo kojem dijelu uređaja ne smije prouzročiti oštećivanje tajnih i osjetljivih podataka. - Ako je uređaj dizajniran tako da dijelovi mogu biti fizički odvojeni od uređaja, svako obrađivanje podataka između vlasnika kartice i tih odvojenih dijelova mora imati istu razinu sigurnosti kao što je ima i cijeli, ne rastavljeni uređaj. - Integriranje drugačijih dijelova uređaja u kućište sigurnog uređaja je nužan uvjet za izmjenu osjetljivih podataka kao što je PIN.
LOGIČKA SIGURNOST
Siguran uređaj mora biti dizajniran tako da nijedna funkcija ili kombinacija funkcija ne prouzroči otkrivanje osjetljivih podataka, osim ako je to eksplicitno dozvoljeno od strane sigurnosti implementirane u terminalu. Logička zaštita mora uvijek štititi osjetljive podatke, pa i ako su samo upotrebljene legitimne funkcije. To svojstvo se može postići internim praćenjem statistike ili mjerenjem minimalnog vremena između poziva osjetljivih funkcija.
Ako terminal može doći u osjetljivo stanje (stanje u kojem se mogu pozivati funkcije koje nisu omogućene u normalnom načinu rada, na primjer, korisničko rukovanje kriptografskim ključevima), takav prijenos mora biti dodatno nadgledan od dviju ili više povjerljivih strana. Ako je lozinka ili drugi tekstualni podaci upotrebljena kod kontrole prijenosa u osjetljivom stanju, unos te lozinke ili tekstualnih podataka mora biti zaštićen na način kao i ostali osjetljivi podaci.
Za minimiziranje rizika koji rezultira ne autoriziranom upotrebom osjetljivih funkcija, osjetljivo stanje mora biti postignuto sa ograničenim brojem poziva funkcija (gdje je to prikladno) i vremenskim ograničenjem. Ako je neko od tih ograničenja postignuto, uređaj se mora vratiti u normalno stanje.
Siguran uređaj mora automatski isprazniti svoje unutrašnje spremnike (buffers) na kraju svake transakcije ili u time-out situaciji.
5.1.Sigurnosni zahtjevi za terminale
Sigurni uređaji moraju u normalnom radnom okruženju osigurati da uređaj ili njegovo sučelje ne otkriva ili mijenja osjetljive podatke koji ulaze ili izlaze iz uređaja te koji su spremljeni ili se obrađuju u uređaju.
Kada siguran uređaj radi u sigurnosno-kontroliranom okruženju, zahtjevi za karakteristike uređaja su reducirani jer se zaštita provodi sigurnosno-kontroliranim okruženjem i rukovanjem uređaja.
Tipkovnica za unos osobnog identifikacijskog broja (PIN Pad)
Tipkovnica za unos osobnog identifikacijskog broja mora biti siguran uređaj te mora podržavati unos 4-12 znamenki osobnog identifikacijskog broja. Ako je priložen i ispis uz tipkovnicu (display), vizualna i/ili zvučna indikacija unošenja pojedinog broja mora biti prikazana.
Stvarne vrijednosti brojeva se ne smiju vidjeti, već se smiju vidjeti samo oznake da su brojevi uneseni.
Kad terminal podržava off-line verifikaciju PIN-a, IFD (Interface Device) i tipkovnica za unos PIN-a mogu biti intergrirane u jedan uređaj ili IFD i tipkovnica mogu biti dva posebno odvojena uređaja.
Ako su IFD i tipkovnica integrirani i offline PIN se šalje kartici u obliku teksta, tipkovnica ne kriptira offline PIN kada je tekstualni PIN poslan od tipkovnice do IFD-a.
Ako su IFD i tipkovnica integrirani i offline PIN se šalje kartici u obliku teksta, ali offline PIN tekst nije poslan direktno od tipkovnice do IFD-a, tada tipkovnica mora kriptirati offline PIN za prijenos do IFD-a. U tom slučaju IFD dekriptira offline PIN za prijenos u tekstu do kartice.
Ako IFD i tipkovnica nisu integrirani zajedno, a offline PIN se mora poslati kartici u tekstualnom obliku, tipkovnica mora kriptirati offline PIN za prijenos do IFD-a. U tom slučaju IFD dekriptira offline PIN za prijenos u tekstu do kartice.
Ako se offline PIN šalje kartici u kriptiranom obliku, kriptiranje se provodi na:
- tipkovnici samog uređaja
- sigurnoj komponenti terminala
Ako terminal podržava on-line verifikaciju PIN-a, kada je PIN unesen mora biti zaštićen kriptiranjem unutar terminala i terminal mora slati kriptirani PIN u skladu s pravilima sustava plaćanja.
Ispis prompt-a za unos PIN-a mora biti generiran od same tipkovnice. To znači da se mogu ispisivati sve vrste poruka koje su autorizirane od strane tipkovnice, a ne samo koje su u vezi s PIN-om. Tipkovnica mora odbiti ispis bilo kakve neautorizirane poruke.
Za praćene terminale, unos iznosa mora biti separiran od unosa PIN-a da bi se izbjeglo nesretno ispisivanje PIN-a na terminalu. Ako se PIN i iznos unose sa iste tipkovnice, iznos mora biti provjeren od vlasnika kartice prije nego što se unosi PIN.
Tipkovnica mora biti dizajnirana tako da štiti privatnost i tajnost, tako da u normalnoj upotrebi samo vlasnik može vidjeti informacije ispisane na zaslonu terminala. Tipkovnica mora biti tako ugrađena da vlasnik kartice može unijeti PIN sa minimalnim rizikom da su taj unos vidjeli drugi.
Tipkovnica mora isprazniti svoje unutrašnje spremnike u slijedećim uvjetima:
- pri završetku transakcije
- u time-out situaciji, uključujući neodređeni period vremena otkako je unesen PIN
5.2.Zahtjevi za rukovanje ključevima
U ovome poglavlju specificirani su zahtjevi za rukovanje javnim ključem izdavatelja certifikata (Certification Authority public key) od strane acquirera. Zahtjevi pokrivaju sljedeće faze:
Objava CA javnog ključa u terminal
Kada se platni sustav odluči objaviti novi CA javni ključ, bitno je pokrenuti proces distribucije novog ključ prema svim acquirer-ima kako bi im bio na raspolaganju. Nakon toga, odgovornost je na acquirer-ima da ključ prenesu u do svakog terminala u svojoj mreži.
Primjenjuju se sljedeća pravila kod prijenosa ključa od acquirera prema terminalima:
- Terminal mora biti u mogućnosti verificirati da je zaprimio CA javni ključ bez ikakve greške
- Terminal mora biti u mogućnosti verificirati da je primljeni CA ključ dostavljen od strane legitimnog acquirer-a
- Acquirer mora biti u mogućnosti potvrditi da je novi CA ključ spušten uredno na sve terminale u njegovoj mreži
Pohrana CA javnog ključa u terminalu
Terminali koji podržavaju offline statičku ili dinamičku autentikaciju podataka morali bi biti u mogućnosti podržati šest CA javnih ključeva po RID za EMVCo člana debitne/creditne aplikacije bazirane na ovoj specifikaciji.
Svaki CA javni ključ je jedinstveno identificiran sa 5 bajtnim RIDom koji identificira platni sustav i sa 1 bajtom indeksom CA javnog ključa.
Integritet pohranjenog CA javnog ključa mora biti verificiran periodično.
Korištenje CA javnog ključa u terminalu
U specifikaciji EMV book 2 navedeno je kako se mora koristiti CA javni ključ prilikom transakcije.
Brisanje CA javnog ključa iz terminala
Kada platni sustav odluči povući svoj CA javni ključ, acquirer mora biti u mogućnosti osigurati da se ključ više ne može koristiti za offline statičnu i dinamičku autentikaciju podataka tokom transakcije nakon određenog datuma.
Preporuka je da acquireri ne implementiraju datum isteka u terminale nego da jednostavno maknu ključeve prema datumu isteka koji odrede platni sustavi.
6. Sigurnosni mehanizmi i algoritmi
6.1.Simetrični mehanizmi
6.1.1.Kriptiranje
Kod kriptiranja podataka kriptiraju se blokovi veličine n koristeći sljedeće načine kriptiranja(prema ISO/IEC 10116v standardu):
Electronic Codebook - ECB
Cipher Block Chaining - CBC
6.1.2. Message Authentication Code (MAC)
MAC algoritam za 8 bajtni blok
Računanje s bajtnog MAC-a (4<=s<=8) vrši se prema ISO/IEC 9797-1 koristeći kriptirajući algoritam 8 bajtnog (64-bitnog) bloka kao što je 3DES u CBC-u.
MAC algoritam za 16 bajtni blok
Računanje s bajtnog MAC-a (4<=s<=8) vrši se prema ISO/IEC 9797-1:2011 Algoritam 5 (CMAC) koristeći kriptirajući algoritam 16 bajtnog (128-bitnog) bloka kao što je AES u CBC-u.
6.1.3. Derivacija sesijskog ključa
Sesijski ključevi Ks deriviraju se iz jedinstvenog Master ključa Km mijenjajući podatke R na način:
Ks:= F(Km)[R]
Da se spriječe napadi ponavljanjem, promjena podataka R trebala bi imati veliku vjerojatnost razlike (podataka) u idućim sesijama derivacije ključa. Također, važan zahtjev za funkciju promjene podataka F je da su mogući rezultati funkcije dovoljno veliki i ravnomjerno raspoređeni kako bi spriječili iscrpnu potragu ključa na temelju sesijskog ključa.
6.1.4. Opcija česte derivacije sesijskog ključa
Generira se jedinstveni sesijski ključ za svaku transakciju odrađenu od strane aplikacije. Vrši se kriptiranjem različite vrijednosti duljine n bajtova sa Master ključem čipa kartice duljine k bitova kako bi dobili k bitni sesijski ključ čipa kartice (SK) koristeći n bajtni kriptirajući algoritam bloka podataka ECB-om.
Isti sesijski ključ koristi se za sve komande u pojedinoj transakciji.
6.1.5. Derivacija Master ključa
Postoje tri opcionalne metode za derivaciju k bitnog ICC Master ključa od strane izdavača kartice, koji se koristi za generiranje aplikacijskog kriptograma, autentikaciju izdavača i sigurnu razmjenu poruka. Prve dvije metode koriste 8 bajtni blok kriptirajućeg algoritma 3DES u ECB-u dok treća metoda koristi 16 bajtni blok kriptirajućeg algoritma AES u ECB-u. Ona ujedno podržava u 128, 192 i 256 bitni ključ.
Ove metode nisu mandatorne nego su opcionalne te izdavači kartica mogu koristiti i alternativne metode za ovu funkciju.
Ove metode za ulaznu varijablu uzimaju PAN i PAN Sequence Number zajedno sa k bitnim Master ključem izdavača i kao rezultat daju k bitni Master ključ čipa kartice.
6.2. Simetrični algoritmi
6.2.1. Data Encryption Standard (DES)
3DES kritpirajući algoritam dvostruke duljine (ISO/IEC 18033-3) je odobreni kriptografski algoritam koji se koristi kod kriptiranja i MAC mehanizama gdje se koristi 8 bajtni blok. Algoritam se bazira na (single) DES algoritmu standardiziranom u ISO 16609.
3DES kriptiranje uključuje kriptiranje 8 bajtnog bloka čistog teksta u 8 bajtni kriptirani blok sa tajnim ključem dvostruke duljine (128 bita) K = (KL||KR)
Kriptiranje Y = DES3(K)[X] = DES(KL)[DES-1(KR)[DES(KL)[X]]]
Dekriptiranje X = DES-1(KL)[DES(KR)[DES-1(KL)[Y]]]
6.2.2. Advanced Encryption Standard (AES)
AES kriptirajući algoritam je odobreni kriptografski algoritam koji se koristi kod kriptiranja i MAC mehanizama gdje se koristi 16 bajtni blok. Podržane duljne ključeva kod AESa su 128 bitni, 192 bitni i 256 bitni.
6.3.Asimetrični mehanizmi
6.3.1. Digitalni potpis sa oporavkom poruke
Algoritmi
Koriste se dvije vrste algoritma:
Reverzibilni asimetrični algoritam kojis se sastoji od potpisne funkcije Sign(SK)[] koji ovisi o privatnom ključu Sk i od povratne funkcije Recover(Pk)[] koja ovisi o javnom ključu Pk. Obje funkcije mapiraju n bajtne brojeve na n bajtne brojeve i imaju svojstvo povratne funkcije
Recover(Pk)[Sign(Sk)[X]] = X za bilokoj n bajtni broj X.
Hashing algoritam Hash[] koji mapira poruku proizvoljne duljine na 20 bajtni hash kod.
Generiranje potpisa
Izračun potpisa S na poruci MSG sastoji se od proizvoljnog broja L od najmanje N-21 bajtova koji zauzima mjesto na sljedeći način:
1) Izračunaj 20 bajtnu hash vrijednost H:= Hash[Msg] poruke M
2) Razdvoji MSG u dva dijela MSG=(MSG1 || MSG2) gdje se MSG1 sastoji od N-22 bajtova veće vrijednosti, a MSG2 od ostalih bajtova manje vrijednosti
L - N + 22 bajta od MSG
3) Definiraj bajt B:= '6A'
4) Definiraj bajt E:= 'BC'
5) Definiraj N bajtni blok X kao povezani lanac blokova B, MSG1, H, i E tako da:
X:=(B||MSG1||H||E)
6) Digitalni potpis S je tada definiran kao N bajtni broj
S:= Sign(Sk)[X]
Verifikacija potpisa
Verifikacija potpisa odvija se na sljedeći način:
1. Provjeri da li se digitalni potpis S sastoji od N bajtova
2. Vrati N bajtni broj X iz digitalnog potpisa S:
X= Recover(Pk)[S]
3. Razdjeli X kao X=(B||MSG1||H||E) gdje je:
B dužine jedan bajt
H dužine 20 bajta
E dužine jedan bajt
MSG1 se sastoji od ostatka N-22 bajta
4. Provjeri da li je bajt B jednak '6A'
5. Provjeri da li je bajt E jednak 'BC'
6. Izračunaj MSG = (MSG1||MSG2) i provjeri da li je H = Hash[MSG]
Jedino ako su sve ove provjere uredne poruka je izvorna.
6.4. Asimetrični algoritmi
6.4.1. RSA
RSA kriptirajući algoritam je odobreni kriptografski algoritam koji se koristi kod kriptiranja i generiranja digitalnog potpisa. Jedin dozvoljene vrijednosti za eksponent javnog ključa su 3 i 2^16+1
Algoritam generira kriptogram ili digitalni potpis čija je duljina jednaka veličini korištenog modula. Obavezna gornja granica modula određena je u tablici28:
Duljina Certification Authority Public Key Modula - NCA
Dulina Issuer Public Key Modul - NI
Duljina ICC Public Key Modulu - NIC
Duljina ICC PIN Encipherment Public Key Modula - NPE
moraju zadovoljavati sljedeći odnos:
NIC<=NI<=NCA i NPE<=NI<=NCA
U izboru duljina modula javnog ključa, treba uzeti u obzir životni vijek ključa u odnosu na očekivani napredak u korištenju ključa tijekom životnog ciklusa. Rasponi (gornja i donja granica) za duljine ključa obvezujući od strane svakog od platnih sustava specificiraju se u njihovim odgovarajućim vlasničkim specifikacijama.
Vrijednost Issuer Public Key eksponenta i ICC Public Key eksponenta određuje izdavač kartice, a Certification Authority, Issuer i ICC Public Key eksponenti moraju biti jednaki 3 ili 2^16+1.
U nastavku će biti specificirani ključevi, potpisne i povratne funkcije RSA algoritma sa neparnim brojem u eksponentu.
KLJUČEVI
Privatni ključ SK RSA digitalnog potpisa sheme sa neparnim brojem u eksponentu javnog ključa e sastoji se od dva prosta broja p i q takvih da su p-1 i q-1 relativno prosti u odnosu na e i tajni eksponent d kao:
ed= 1 mod (p-1)(q-1)
Javni ključ Pk sastoji se od javnog modula n=pq i javnog eksponenta e.
Potpisna funkcija
Potpisna funkcija za RSA algoritam sa neparnim brojem u eksponentu javnog ključa e definirana je:
S = Sign(Sk)[X] := X^d mod n, 0<X<n,
gdje je X skup podataka koji trebaju biti potpisani i S odgovarajući digitalni potpis.
Povratna funkcija
Povratna funkcija RSA algoritma sa neparnim brojem u eksponentu javnog ključa e odgovara:
X = Recover(Pj)[S]:= S^e mod n
Platni sustavi i izdavači kartica moraju biti odgovorni za sigurnost njihovih procesa za generiranje RSA javnih/privatnih ključeva.
6.4.2. Hash
Secure Hash Algoritham SHA-1
Ovaj algoritam standardiziran je u ISO/IEC 10118-3. SHA-1 pretvara ulaznu poruku proizvoljne duljine u 20 bajtnu hash vrijednost.
7. Zaključak
Od početka korištenja EMV standarda pa sve do danas isti je znatno napredovao, no nije u potpunosti zaživio u svim dijelovima svijeta.
Kako se broj transakcija tj. korištenje kartica kao platnih sredstava povećava tako se i budi svijest o potrebi za zaštitom korisnika. Zbog toga se velika većina kartičnih kuća odlučuje za uvođenje EMV standarda na svoje kartice jer s time dobivaju na sigurnosti poslovanja i povjerenju svojih korisnika, a i sebe osiguravaju od bespotrebnih gubitaka.
EMV standard pokazao se kao najsigurniji u kartičnom poslovanju, ali potrebno ga je dodatno poboljšavati kako bi se zadržao korak ispred ljudi koji se bave krađom i malverzacijama u kartičnom poslovanju.
Mjesta za napredak svakako ima, no bitno je zadržati zadovoljstvo i povjerenje korisnika te pratiti najviše tehničke standarde vezane za sigurnost.
8. Literatura
EMV book 2 - Security and Key Management_v4.3 - preuzeto sa EMVCo www.emvco.com
Materijali sa UL tečaja "EMV"
Seminarski rad EMV standard, Aleksandar Radovan
http://os2.zemris.fer.hr/pk/2003_radovan/ - pristupano 20.01.2016.
