---

Autor: Hrvoje Palčić (m.br. 36358792)
e-mail: hrvoje.palcic@fer.hr

1. Uvod.. 3
2. Osnovni princip komunikacije. 3
3. Fizički prijenosni sloj. 5
4. Odgovor na resetiranje ATR.. 7
4.1 ATR Karakteri 8
5. Protokol za selekciju tipova (PTS) 14
6. Protokol za prijenos podataka.. 18
6.1 Sinkroni podatkovni prijenos. 19
6.2 T=0 prijenosni protokol 20
6.3 T=1 prijenosni protokol 24
7. Struktura poruka: APDUs. 32
7.1 Struktura naredbe APDU.. 33
7.2 Struktura odgovora APDU.. 35
8. Sigurni prijenos podataka.. 36
8.1 Procedura autentični mod. 39
8.2 Procedura kombinirani mod. 40
8.3 Brojač poslanih nizova. 42
9. Zaključak.. 43
10. Dodatak: Standardi 44
11. Literatura.. 45

 
Komunikacijski model pametnih kartica

1. Uvod

Iste veličine kao kreditne kartice, pametne kartice spremaju i procesiraju informacije kroz elektroničke sklopove izrađene u siliciju u plastičnom kućištu. Pametna kartica je prijenosno i na napade otporno računalo. Za razliku od magnetskih kartica, pametne kartice mogu osim čuvanja i obrađivati podatke. Tato one ne zahtijevaju pristup udaljenoj bazi za vrijeme transakcije.

Pametne kartice dijelimo u nekoliko grupa. Mogu biti podijeljene na memorijske kartice i mikrokontrolerske kartice. Mogu također biti podijeljene na kontaktne i bez kontaktne kartice bazirane na razlici u kartičnom pristupnom mehanizmu.

Pametne kartice stavljaju se u uređaj za prijem kartica CAD (card acceptance device), koji možemo spojiti na drugo računalo. CAD možemo klasificirati na dva tipa: čitače i terminale.

Čitač je spojen preko serijskog, paralelnog ili USB pristupa na računalo, kroz koje komunicira pametna kartica. Čitač ima utor u koji se stavlja kartica, ili može razmjenjivati podatke preko elektromagnetskog polja kod bez kontaktnih kartica. Nakon uključivanja kartice, čitač uspostavlja podatkovni komunikacijski put u kojem pametna kartica može komunicirati s računalom spojenim na čitač. Iako obični čitači nemaju inteligenciju da obrađuju podatke, mnogi imaju funkcije za detekciju grešaka i ispravljanje ako preneseni podaci nisu u skladu s prijenosnim protokolom.

S druge strane, terminali su kao samostalna računala. Terminal integrira čitač pametnih kartica kao jednu od svojih komponenata. Uz to što imaju funkciju čitača pametne kartice, terminali također imaju sposobnost za obradu podataka izmijenjenih s pametnom karticom.

U kasnijem tekstu radi jednostavnosti korišten je izraz terminal koji je sinonim za čitač i za terminal.

2. Osnovni princip komunikacije

Mogućnost dvosmjerne komunikacije je preduvjet za sve interakcije između pametnih kartica (smart card) i Terminala. Bilo kako bilo samo je jedna linija dostupna. Digitalni podaci se izmjenjuju između kartice i terminala putem električke veze. Budući da postoji samo jedna linija, kartica i terminal se moraju izmjenjivati u slanju podataka, dok se druga stranka ponaša kao primalac. Naizmjenično slanje i primanje podataka zove se Half-Duplex procedura.

Full-Duplex procedura, u kojoj obje strane mogu slati i primati simultano, trenutno nije implementirana za pametne kartice. Kako većina procesora pametnih kartica ima dva I/O porta, i dva od 8 kontaktna polja su rezervirana za buduće aplikacije (kao druga I/O linija), Full-Duplex operacija bi bila sigurno tehnički moguća. Prosječnim jezikom, ovo će sigurno biti implementirano u hardware i operacijske sisteme, jer je to jedini način da se podaci kriptiraju u stvarnom vremenu unutar kartice. Preliminarni zahtjevi za standardizaciju ovog postupka su dostupni.

Komunikaciju s karticom uvijek pokreče terminal. Kartica uvijek odgovara komandama terminala, što znači da kartica nikad ne šalje podatke bez vanjskog zahtjeva. To rezultira odnosom Master-Slave gdje je terminal Master, a kartica Slave.

Nakon što se kartica umetne u terminal, njeni se kontakti prvo mehanički povežu s terminalom. Pet aktivnih kontakata se tada električki spaja u pravilnom redoslijedu. Slijedeći to kartica automatski izvršava Power on Reset i tada šalje odgovor na Reset (ATR) terminalu. Terminal evaluira ATR što rezultira različitim parametrima koji se odnose na karticu i na prijenose podataka i tada šalje prvu komandu. Kartica procesira komandu i generira odgovor kojeg šalje natrag do terminala. Ova naprijed/nazad izmjena komandi i odgovora nastavlja se dok se kartica ne deaktivira.

Slika 1. Inicijalni prijenos podataka između pametne kartice i terminala

Između ATR i prve komande poslane kartici terminal može isto poslati protokol za selekciju tipova (PTS) (protocol type select) komandu. Terminal može koristiti ovu komandu koja je kao ATR neovisna o prijenosnom protokolu, da sastavi različite parametre prijenosa za protokol kartice.

Čitav proces prijenosa od i s pametne kartice može se prikazati koristeći OSI layer model. Ovako se između električnih događaja na I/O liniji razlikuju, logički procesi u stvarnom protokolu prijenosa i ponašanja aplikacija koje iskorištavaju ove procese. Način rada interakcije unutar i između ovih slojeva su određeni u nekoliko internacionalnih standarda. Ove veze su na slici 2.

 

Slika 2. OSI model za komunikaciju između terminala i pametne kartice

Ovi asinkroni protokoli prijenosa o kojima se govori opisani su u terminima svojih funkcija i s uvažavanjem relevantnih standarda. Svi dozvoljeni parametri i konfiguracije unutar konteksnog protokola su određeni. U praksi pak često se događa da pametne kartice ne podržavaju sve opcije protokola prijenosa zbog ograničenosti raspoložive memorije.

S funkcionalnog stajališta različite opcije su zapravo jednostavno sklop mogućnosti iz kojih se može odabrati optimalni set za određenu aplikaciju ili pametnu karticu. Treba uvažiti da odabrani parametri ne budu previše različiti da bi kartica mogla komunicirati s što je više moguće različitih tipova terminala.

3. Fizički prijenosni sloj

Fizički prijenosni sloj (Physical Transmision Layer) sa svim svojim parametrima specificiran je međunarodnim Smart Card standardom ISO/IEC 7816-3. To je osnovni standard za sve aspekte komunikacije na fizičkoj razini.

Čitava razmjena podataka s pametnom karticom je digitalna. Naponski nivo čine konvencionalne vrijednosti za digitalnu tehnologiju, tj. 0V i +5V. Novi mikrokontroleri koji rade s 3V naponom također podržavaju ove vrijednosti. Izbor naponskog nivoa za logičko 1 je proizvoljan i može biti 0V ili 3V/5V (obrnuto od logičke 0), što određuje sama kartica kod uključivanja u prvom ATR bajtu. U skladu s time, 'direct conversion' znači da je "1" predstavljena s +3/+5V, a 'inverse conversion' znači da +3/+5V predstavlja "0". U oba slučaja, nivo I/O linije je uvijek visoko u stanju mirovanje.

Komunikacija između pametne kartice i vanjskog dijela odvija se serijski. Podaci koji se procesiraju u bajtovima moraju se promijeniti u serijski slijed. Zatim se bitovi slažu u pakete od po osam i šalju se jedan iza drugog. Redoslijed bitova ovisi o korištenoj konvenciji. Kod 'direct convetion' prvi bit iza početka je najmanje značajan, a kod 'inversion convention' to je najznačajniji bit.

Slika 3. Konvencije prijenosa podataka: (a) direct convention; (b) inverse convention

Prijenos između kartice i terminala je asinkron, to znači da svaki poslani bajt mora biti popraćen s dodatnim pratećim bitovima. Svakom bajtu dodaje se jedan početni bit koji indicira početak prijenosa, te se na kraj dodaje bit pariteta i još jedan ili dva stop bita. Vrijeme predviđeno za stop bitove je određeno kao ''čuvano vrijeme'' (guard time) u T=0 protokolu. Prijemnik i predajnik mogu koristiti ovo vrijeme da se pripreme za sljedeći transfer. Paritetnim bitom određujemo da u ukupnom slijedu ima parni broj 1.

Slika 4. Struktura prijenosnih podataka

Budući da vremenski sklopovi u mikrokontrolerima pametnih kartica ovise o clock signalima, nije moguće odrediti apsolutni vremenski interval za pojedini podatak. To se čini određivanjem vrijednosti djelitelja što je zapravo broj taktova/interval. Trajanje jednog bita je etu - elementarna vremenska jedinica (elementary time unit). Znači nema smisla odrediti prijenosni omjer s pametnim karticama kao fiksnu vrijednost (kao 9600 bit/s), budući da je proporcionalan sa stupnjem sata. Trenutno su u upotrebi dvije osnovne vrijednosti djelitelja: 372 i 512. U porastu su čak i manje vrijednosti djelitelja da se poveća stupanj prijenosa.

Bit interval računa se iz omjera sata i vrijednosti djelitelja. S frekvencijom 3.56712MHz i djeliteljem 372, održat ćemo bit interval od 104 μs što je jedan etu za ovu vrijednost djelitelja.

Slika 5. Primjer trostrukog uzrokovanja prijemnog bita

Vrijeme serijskog prijenosa ne mora biti strogo kontrolirano. Zbog tehničkih razloga tolerira se odstupanje. Budući da mnogi mikrokontroleri pametnih kartica nemaju sklopovsko sučelje, ponekad je potrebno to implementirati programski. Vremenska devijacija između kraja start bita i finalnog prijenosa n-tog bita ne smije priječi ±0.2 etu. Zbroj odstupanja za grupu bitova ne smije priječi dozvoljenu vrijednost.

Tri uzorka trebaju biti jednako raspoređena na primljene bit intervale sa svrhom da se što bolje nadomjeste kratki "dropouts". To se postiže skupljanjem uzoraka u sredini intervala i na krajevima test zone, što je određeno prihvatljivim odstupanjem prijenosa. Optimalni uzorci su određeni granicama test zone i središtem bit intervala. No to nije određeno standardom. Uzorkovanje unutar zone prijelaza nije dopušteno jer razina signala nije valjana.

4. Odgovor na resetiranje ATR

Kod uključivanja, sat i reset signal su izvršeni, pametna kartica šalje odgovor na resetiranje ATR (answer to reset) putem I/O. Ovaj niz podataka koji sadrži najviše 33 bajta, uvijek se šalje s vrijednošću djelitelja od 372 u skladu s ISO/IEC 7816-3 standardom. On sadrži različite podatke koji su važni za prijenosni protokol i karticu. Ova vrijednost djelitelja treba se koristiti i kada protokol prijenosa korišten poslije ATR-a imaju različite vrijednosti djelitelja npr. 512. To osigurava da ATR s bilo koje kartice bude uvijek primljen neovisno o parametrima protokola prijenosa.

Vrlo se rijetko događa da ATR ima maksimalnu dopuštenu duljinu. ATR najčešće sadrži samo par bajtova. Posebno kod aplikacija gdje se kartica koristi vrlo brzo nakon aktiviranja, ATR mora biti kratak.

Početak ATR prijenosa mora biti između 400 i 40000 taktova nakon što terminal razmotri reset signal. Takt od 3.5712 MHz odgovara intervalu od 112 μs do 11.2 ms, dok kod 4.9152 MHz interval bude 81.38 μs do 8.14 ms. Ako terminal ne primi ATR u ovom intervalu, ponavlja aktiviranje nekoliko puta (obično do tri puta) pokušavajući dobiti ATR. Ako ovi pokušaji ne uspiju terminal pretpostavlja da kartica ima grješku.

Slika 6.  Vremenski dijagram reset signala i početka ATR-a, prema ISO/IEC 7815-3

Za vrijeme ATR-a, vrijeme između dva uzastopna bajta može biti do 9600 etu prema ISO/IEC 7816-3. To je početno vrijeme čekanja. To je točno jedna sekunda s taktom od 3.5712 MHz. To znači da se dopušta odgoda od jedne sekunda između pojedinačnih bajtova koji se šalju terminalu. Kod nekih operacijskih sistema pametnih kartica, ovo vrijeme se koristi za unutarnje izračunavanje i pisanje u EEPROM.

Tablica 1. Podatkovni elementi ATR i njihovo značenje prema ISO/IEC 7816-3 standardu

Osnovni ATR format opisan je u tablici 1 i slici 7. Prva dva bajta, TS i T0 određuju mnoge osnovne parametre prijenosa i prisustvo popratnih bajtova. Karakteri sučelja (interface characters)određuju posebne parametre prijenosa za protokol, koji su važni za slijedeće prijenose podataka. Povijesni karakteri (historical characters) opisuju opseg osnovnih funkcija pametne kartice. Check karakter, koji je checksum prethodnih bajtova može se slati kao zadnji bajt ATR-a ovisno o protokolu.

4.1 ATR Karakteri

Inicijalni karakter

Ovaj bajt označen kao TS, specificira konvenciju koja se koristi za sve podatke u ATR-u i narednim komunikacijskim procesima. TS bajt sadrži karakteristične ""(BIT OBRASCE)"" koje terminal koristi da bi odredio vrijednost djelitelja. Terminal mjeri vrijeme između prva dva padajuća brida u TS-u i dijeli s tri. Rezultat je trajanje jednog etu-a. No kako je djelitelj za ATR fiksan, 372, terminal obično ne može proračunati sinkronizirani blok. Prvi bajt je bajt koji predstavlja ATR komponentu i uvijek mora biti poslan. Samo dva koda su dozvoljena za ovaj bajt: '3B' za direktnu konvenciju ili '3F' za inverznu.

Slika 7.  Osnovne strukture i podatkovni elementi ATR-a

Slika 8.  Vremenski dijagram inicijalnog karaktera TS u direct convention ('3B')

Slika 9.  Vremenski dijagram inicijalnog karaktera TS u inverse convention ('3F')

Tablica 2. Inicijalni karakter (TS) kod

Direktna konvencija se obično koristi u Njemačkoj, a inverzna konvencija je uobičajena u Francuskoj. Konvencija ne utječe na sigurnost prijenosa. Naravno svaki proizvođač operacijskih sistema daje prednost jednoj ili drugoj zbog povijesnih razloga, ali svi terminali i mnoge pametne kartice podržavaju obje konvencije.

Format karakter

Drugi bajt, T0, sadrži bit polje koje pokazuje koji će karakteri sučelja biti poslani. Također pokazuje broj narednih karaktera. Kao TS ovaj bajt mora biti prisutan u svakom ATR-u.

Karakteri sučelja

Karakteri sučelja (interface characters) određuju sve parametre prijenosa koji se u protokolu koriste. Sastoje se od bajtova TAi, TBi , TCi i TDi. No ovi bajtovi su opcionalni u ATR-u i mogu se ispustiti. Budući da su definirane osnovne vrijednosti za sve parametre protokola, karakteri sučelja s obično ne traže u ATR-u za obične komunikacijske procese.

Tablica 3. Kodiranje u T0 format karakteru

Karakteri sučelja mogu biti podijeljeni u opće i posebne karaktere sučelja. Opći određuju osnovne parametre protokola prijenosa kao što je vrijednost djelitelja što se primjenjuje u svim narednim protokolima. Posebni naprotiv određuju parametre za vrlo specifične protokole prijenosa. Vrijeme čekanja za T0 protokol je tipični primjer takvog parametra. Opći karakteri sučelja primjenjivi su u svim protokolima. Zbog povijesnih razloga (jer je jedino T=0 protokol bio uključen u ISO standard) samo su neki od ovih karaktera relevantni za T=0 protokol. T=0 nije implementiran mogu se ispustiti i u tom slučaju pojavljuju se vrijednosti po osnovi.

TDi bajt koristi se smo u svrhu zaštite linkova do narednih karaktera sučelja. Gornja riječ sadrži uzorak koji pokazuje prisutnost narednih karaktera sučelja. Ovo je analogno kodiranju format karaktera T0. Donja riječ TDi bajta identificira trenutno dostupni protokol prijenosa. Ako TDi bajt nije prisutan TAi+1, TBi+1, TCi+1 i TDi+1 se ne prenose.

Drugi karakteri sučelja (TAi, TBi i TCi), koji se ne koriste za povezivanje, određuju dostupni prijenosni protokol ili protokole. Njihovo značenje prema ISO/IEC 7816-3 standardu je kako slijedi.

Tablica 4. Kodiranje TDi bajta

Opći karakter sučelja TA1 djelitelj (clock rate conversion factor F) se prepoznaje u gornjoj riječi kao FI. Bit faktor prilagodbe D dekodira se u donjoj riječi kao DI.

Tablica 5. TA1 kodiranje

Tablica 6. FI kodiranje

Tablica 7. DI kodiranje

Dekodiranje djelitelja F i prilagodba faktora D dopušta da se specificiraju stope prijenosa u skladu sa standardom. Sljedeće veze se primjenjuju:

- bit interval za ATR i PTS koji se zove inicijalna vremenska jedinica (initial etu), određen je

- prijenosni protokol koji slijedi ATR i PTS definira bit interval neovisno o ATR-u. Ovaj interval koji se zove radna vremenska jedinica (work etu), određen je:

Ovi dva parametra bit rate adjustment factor D i clock rate convension factor F, omogućuju da se stupanj prijenosa prilagodi u pojedinačnim slučajevima. Frekvencija u formulama je označena kao f, s jedinicom Hz.

Opći karakter sučelja TB1 Bitovi b7 i b6 ovog bajta dekodiraju naponski faktor za programiranje koji se zove "II". Bitovi od b5 do b1 određuju parametar "PI1".  Najznačajniji bit b8 je uvijek 0, što znači da se ne koristi. Ovi parametri su bili potrebni u prvoj generaciji pametnih kartica koje su koristile EPROM za pohranu podataka umjesto EEPROM, što je trenutni standard. Potrebni visoki napon za EPROM programiranje dopremao je terminal putem Vpp kontakta. No, kako pametne kartice bez unutarnje strujne pumpe više ne postoje možemo ignorirati detaljno kodiranje ovog bajta.

Tablica 8. TB1 kodiranje

Parametri PI1 i II stoga uvijek imaju vrijednost 0, što pokazuje da nema potrebe za vanjskim naponom potrebnim za programiranje. Ako je podatkovni element TB1 ispušten u ATR-u, osnovna napon Vpp je 5v s 50mA, prema standardu.

Opći karakter sučelja TC1 On određuje ekstra čuvano vrijeme (extra guard time) označeno s N, ne predznačni heksadecimalni integer. Ova vrijednost određuje broj etu za proširivanje čuvanog vremena. TC1 se interpretira linearno, s izuzetkom kada je N='FF', tada se standardno čuvano vrijeme reducira na 11 etu u T=1 protokolu. U T=0 protokolu ekstra čuvanog vremena je 12 etu s dopuštenjem grješke koju može prepoznati niska razina unutar čuvanog vremenskog intervala. U praksi smanjivanje čuvanog vremena na 11 etu rezultira porastom brzine oko 10% u T=1 protokolu, jer se šalje jedan bit manje.

Tablica 9. TC1 kodiranje

Opći karakter sučelja TB2 Ovaj bajt čuva vrijednost od PI2. Parametar određuje vanjski napon programiranja u desetima volti. Stoga se obično ne koristi u ATR-u iz istog razloga kao i TB1.

Tablica 10. TB2 kodiranje

Specifični karakter sučelja za T=0 prijenosni protokol

Specifični karakter sučelja TC2  Posljednji podatkovni element u T=0 protokolu određuje 'work waiting time'. Work waiting time je najveći vremenski interval između uzlaznih bridova dva uzastopna bita:

 work waiting time=(960·D·W1) work etu

Ako TC2 karaktera nema u ATR-u, koristi se osnovna vrijednost za work waiting time (W=10).

Tablica 11. TC2 kodiranje

Specifični karakteri sučelja za T=0 prijenosni protokol

Sljedeći dodatni bajtovi su definirani za T=1 prijenosni protokol u skladu s ISO/IEC 7816-3 Amd 1. Ovdje se karakter sučelja propisan za T=0 koristi prema zahtjevu. Za ovaj protokol indeks i podatkovnog elementa mora uvijek biti veći od 2. U ovom slučaju specifični karakteri sučelja TAi, TBi i TCi (i>2) uvijek se primjenjuju u prijenosnom protokolu određenom s TD_(i-1).

Specifični karakter sučelja TAi (i>2)  Taj bajt sadrži najveću dužinu polja podataka koje se mogu primiti karticom (IFSC). Ova vrijednost mora biti između 1 i 254. Osnovna vrijednost IFSC je 32 bajta.

Tablica 12. TAi kodiranje za i>2

Specifični karakter sučelja TBi (i>2)  Donja riječ (četiri bita od b4 do b1) sadrže kod CWI za karakter waiting time CWT, koje se računa:

work etu

Gornja riječ sadrži BWI, s kojom se block waiting time BWT može izračunati kako slijedi:

  work etu

Tablica 13. TBi kodiranje za i>2

Specifični karakter sučelja TCi (i>2)  Bit b1 određuje metodu koja se koristi za izračunavanje detekcije grješaka. Kako standard koji se odnosi na podatkovne elemente ATR-a ne definira sve moguće parametre prijenosnog protokola u terminima karaktera sučelja, različite implementacije mogu koristiti dodatne karaktere sučelja.

Tablica 14. TCi kodiranje za i>2

Tipičan je primjer iz Njemačkog nacionalnog T=14 protokola. Nekoliko dodatnih ATR bajtova je definirano za ovaj protokol da bi se zadovoljile specifične potrebe. Mogu ih dekodirati samo korisnici ovog protokola jer samo oni znaju primjenjivu specifikaciju.

Opći karakter sučelja TA2 Ovaj bajt prikazuje dopuštene modove za PTS.

Tablica 15. TA2 kodiranje

Povijesni karakter

Povijesni karakter (historical characters) dugo vremena, nisu bili definirani u standardu. Kao posljedica sadržavali su velik broj podataka ovisno o proizvođaču operacijskog sistema.

Mnoge tvrtke koristile su dostupne bajtove za identificiranje operacijskog sistema i popratne verzije u ROM maski. Ovo se obično dekodira u ASCII da bi se lakše tumačilo. Prisutnost povijesnih karaktera unutar ATR-a nije propisana pa je moguće ispustiti ih. U nekim slučajevima to može biti pozitivno jer je ATR kraći i brže se šalje.

ISO/IEC 7816-4 standard omogućuje ATR datoteku kao dodatak povijesnom karakteru. Ova datoteka s rezerviranim FID '2F01' sadrži dodatne podatke o ATR-u. Namjera je da to bude proširenje povijesnog karaktera koji su ograničeni na 15 bajtova. Sadržaj ove datoteke, čija struktura nije definirana standardom, je ASN.1 kodirano.

Podatkovni elementi u ATR datoteci ili povijesni karakteri, mogu sadržavati kompleksne informacije u vezi pametne kartice i operacijskom sistemu. Npr. on može biti korišten za spremanje funkcija u datoteku i implicitnih funkcija koje podržava pametna kartica kao i informacije o logičkom kanalnom mehanizmu. Isto mogu biti korištene za pohranu dodatnih informacija o kartičnim svojstvima, o kartični i čip serijskim brojevima, i verzijama ROM maske, čipa i operacijskog sistema. Kodiranje relevantnih podatkovnih objekata je definirano u ISO/IEC 7816-4 i -5 standardu.

Kontrolni znak

Posljednji bajt u ATR-u je XOR kontrolna suma od bajta T0 do zadnjeg bajta prije ček karaktera (TCK). Ta kontrolna suma može biti korišten kako dodatak u paritetnom testiranju da se verificira točnost ATR prijenosa. No, usprkos naizgled jednostavnoj konstrukciji i izračunavanju ove kontrolne sume, postoji nekoliko značajnih razlika među različitim prijenosnim protokolima.

Ako je samo T=0 prijenosni protokol indiciran u ATR-u , TCK kontrolna suma ne mora biti prisutna na kraju ATR-a. U ovom slučaju se uopće ne šalje, jer detekcija grješke poslanih bajtova koristi paritetnu provjeru i ponavljanje krivog bajta zastupljenog u T=0 protokolu. Suprotno TCK bajt mora biti prisutan zajedno s T=1 protokolom. Kontrolna suma se izračunava počevši s T0 bajtom i završno s posljednjim karakterom sučelja, ili posljednjim povijesnim karakterom ako je prisutan.

5. Protokol za selekciju tipova (PTS)

Pametna kartica prikazuje mnoge parametre prijenosa podataka u karakterima sučelja ATR-a kao što je protokol prijenosa i karakter čekanog vremena. Ako terminal želi modificirati jedan ili više ovih parametara, protokol za selekciju tipova (protocol type selection) PTS mora biti primijenjen prije stvarnog izvršenja protokola prema ISO/IEC 7816-3 standardu. Terminal to može koristiti da modificira određene parametre protokola sve dok to kartica dozvoljava. PTS se ponekad zove i protokol za selekciju parametara (protocol parameter selection) PPS.

PTS može biti izvršen u dva različita moda. U pregovaračkom modu, standardne vrijednost djelitelja F i faktora prilagodbe prijenosa D ostaju ne promijenjene sve dok PTS ne bude uspješno izvršen. S druge strane, ako kartica koristi posebni mod vrijednosti za F i D date u ATR-u su predstavljene za PTS prijenos također. TA2 bajt prikazuje koji od ova dva moda kartica podržava.

Slika 10.  Dijagram stanja dva PTS moda

Tablica 16. PTS podatkovni elementi i njihov opis prema ISO/IEC 7816-3

PTS zahtjev mora biti izvršen odmah nakon što je terminal primio ATR. Ako kartica zabrani zatražene izmjene parametara protokola poslat će primljene PTS bajtove natrag terminalu. U principu to je kao eho primljenih podataka. Drukčije, kartica ništa ne šalje i terminal izvršava novi reset niz da bi kartica izašla iz ovog stanja. PTS može biti izvršen samo jednom odmah nakon ATR-a. Ponovljeni PTS prijenosi su zabranjeni standardom.

Slika 11.  Osnovna struktura i podatkovni elementi PTS-a

U praksi, je veoma rijetko korištenje PTS-a jer su parametri prijenosa na pametnim karticama koji se trenutno koriste, točno povezani s terminalom.

Prvi bajt je inicijalni karakter (PTSS), koji nedvosmisleno upućuje karticu da će terminal uputiti PTS zahtjev odmah nakon ATR-a. Stoga uvijek ima vrijednost 'FF' i mora biti poslana u svakom PTS-u. Podatkovni element koji slijedi PTSS je format karakter (PTS0). To je također obavezni dio svakog PTS-a. Opcionalno ga mogu slijediti do tri bajta, koji se zovu parametar karakteri i to su PTS1, PTS2 i PTS3. Oni kodiraju različite parametre za prijenosni protokol koji će se koristiti nakon PTS-a. Podatkovni element PTS3 je rezerviran za buduću upotrebu. Posljednji bajt u PTS-u se zove kontrolni karakter PCK (control character). Sadrži XOR kontrolnu sumu svih prethodnih bajtova, počevši s PTSS. Kao i PTSS i PTS0, obavezni je dio PTS-a za razliku od drugih opcionalnih podatkovnih elemenata.

Tablica 17. PTS0 kodiranje

Ako kartica može interpretirati PTS i u skladu s tim modificirati prijenosni protokol, to će objaviti tako da pošalje primljeni PTS natrag terminalu. Ako PTS zahtjev sadrži elemente koje kartica ne može izvršiti, jednostavno čeka dok terminal ne izvrši resetiranje. Glavni nedostatak ove procedure je veliki gubitak vremena do stvarne komunikacije.

Tablica 18. PTS1 kodiranje

Upravo opisani PTS neće raditi za protokol koji koristi terminale koji ne mogu izvršiti PTS. Ovo je točno slučaj kao i kod Njemačkih telefonskih kartica. Postoje posebna procedura kako bi se dopustilo mijenjanje protokola usprkos ovom ograničenju.

Tablica 19. PTS2 kodiranje

Kako svi terminali izvode višestruko resetiranje ako ne prepoznaju ATR, odlučeno je da pametna kartica mijenja prijenosne protokole nakon svakog resetiranja. Ovo je najbolje prikazati primjerom. S prvim resetiranjem, kartica šalje ATR za T=14 i tada je spremna za komunikaciju s T=14 protokolom. Nakon drugog resetiranja, šalje ATR za T=1 i može komunicirat koristeći T=1 protokol. Nakon trećeg resetiranja ponovno radi prema T=14 protokolu. Ovo nije idealno tehničko rješenje, jer bi se uređaj uvijek trebao ponašati isto nakon svakog resetiranja, ali je praktično rješenje za svijet različitih terminala.

Slika 12.  Tipična PTS procedura kod GSM

Moguće je umanjiti ovaj nedostatak tako da pametna kartica uvijek odgovara istim ATR-om nakon power-on reset (hladni reset). Kartica uvijek izvršava hladni reset odmah nakon što je umetnuta u čitač kartica i aktiviranje je završeno. Reset koji je okinut s kartičnom reset linijom (topli reset), s druge strane uključuje prijenosni protokol. Kartica se stoga ponaša isto nakon svakog stvarnog resetiranja i svako dodatno okidanje reseta uzrokuje uključivanje prijenosnog protokola.

Slika 13.  Tipična PTS reset procedura

6. Protokol za prijenos podataka

Nakon što je pametna kartica poslala ATR i izvršen je PTS, čeka prvu naredbu od terminala. Sljedeći procesi uvijek odgovaraju principu master/slave, gdje je terminal master, a kartica je slave. Jednostavnije, terminal šalje naredbu kartici a ona je izvršava i šalje odgovor. Ova među izmjena naredbi i odgovora nikad se ne mijenja.

Slika 14.  Klasifikacija prijenosnih protokola korištenih kod pametnih kartica

Postoje različiti načini na koje se može uspostaviti komunikacija s pametnom karticom. Postoji također i veliki broj različitih procesa za resinhronizaciju komunikacija ako se pojavi smetnja. Točne implementacije naredbi odgovarajući odgovori i postupci korišteni u slučaju grješki pri prijenosu definirani su u obliku protokola prijenosa.

Na raspolaganju je 15 protokola za koje su definirane osnovne funkcije. Ovi protokoli, koji su označeni kao T=(za 'prijenosni protokol') plus sekvencijalni broj, navedeni su u tablici 20.

Tablica 20. Pregled prijenosnih protokola definiranih u ISO/IEC 7816-3

Dva od ovih protokola dominiraju u internoj upotrebi. Prvi je T=0 protokol, koji je standardiziran 1989. (ISO/IEC 7816-3). Drugi je T=1 koji je uveden 1992 kao proširenje međunarodnom standardu. Dvosmjerni prijenos T=2 se bazira na T=1 i trenutno je u pripremi i bit će dostupan za nekoliko godina.

U Njemačkoj se koristi treći protokol T=14 za raširene telefonske kartice. Određen je u međunarodnoj specifikaciji Deutsche Telekom.

Jedinice podataka koje se prenose zovu se prijenosni protokol podatkovnih jedinica TPDUs (transmision protocol data units). One su spremnici koji ovise o protokolu i prenose podatke od i prema kartici. Stvarna primjena podataka je ugrađena u tim spremnicima.

Kako dodatak ovim tehnički kompleksnim prijenosnim protokolima pametnih kartica, postoji dodatni set jednostavnih protokola za memorijske kartice. Oni se obično koriste s telefonskim karticama i karticama zdravstvenog osiguranja te sličnim. No oni nemaju mehanizme za ispravljanje grješaka i baziraju se na visokoj logici na čipu.

6.1 Sinkroni podatkovni prijenos

Sinkronizirani prijenos podataka se ne koristi s pametnim karticama koje se baziraju na mikrokontrolerima, budući da oni komuniciraju s terminalom samo asinkrono. No to je standardni proces kod memorijskih kartica koje se koriste u velikom broju.

Kod memorijskih kartica sinkronizirani prijenos podataka je povezan sa sklopovljem čipa i dizajniran je da bude što jednostavniji. Nema odvajanja slojeva u prijenosnom protokolu niti logičkog adresiranja, pa aplikacije u terminalu moraju direktno pristupati memorijskim adresama u čipu. Protokol omogućuje da se podaci pohranjeni na čipu fizički adresiraju a zatim čitaju ili pišu. To znači da je stvarni prijenos podataka također povezan s funkcijama memorijskog adresiranja i upravljanjem.

Također nema postupaka za detektiranje ili ispravljanje grješaka tijekom prijenosa, a valja reći da se takve grješke između kartice i terminala javljaju rijetko. No ako aplikacija terminala uoči grješku kod prijenosa, relevantno područje u kartičnoj memoriji se ponovno čita. Sva ova ograničenja služe prijenosu podataka na visokoj razini uz korištenje male količine logičkog sklopovlja.

Budući da se sinkronizirani prijenos podataka koristi samo da se prijenos pojednostavi (što znači s minimalnim brojem logičkog sklopova), neizbježna je posljedica velika ovisnost o hardveru. To znači da sinkronizirani protokoli nisu specificirani, i ponekad puno variraju od čipa do čipa. Samo je ATR standardiziran. Terminal koji komunicira s različitim tipovima memorijskih kartica mora stoga uključiti nekoliko različitih implementacija protokola sinkroniziranog prijenosa podataka.

Točni naziv prijenosa podataka koji se koristi za memorijske kartice je 'clock-synchronous serial data transmission' ovo jasno naglašava osnovne značajke ovog tipa komunikacije. Kao kod asinkrone komunikacije podaci se šalju između kartice i terminala serijski bit po bit. No bitovi se šalju sinkronizirano sa signalom sata. Zato je prijenosa start i stop informacije nepotreban.

Kod jednostavne memorijske kartice također nema informacija o detekciji grješaka, što znači da se ne šalju niti paritetni bit niti dodatna kontrolna suma. Stoga je mala vjerojatnost grješaka zahvaljujući malom taktu sata koji varira između 10kHz i 100kHz. Budući da se 1bit šalje za svaki takt sata, takt sata od 20kHz omogućuje prijenos od 20kBit/s. Kapacitet kanala nije iskoristiv u potpunosti jer se prenose i adrese za memorijsku karticu.

Osnovne značajke memorijske kartice: u svom najjednostavnijem obliku ove kartice imaju memoriju koja je podijeljena u dva djela u ROM i EEPROM. Obje memorije mogu se bit adresirati i slobodno čitati, a u slučaju EEPROM pisati i čitati.

Master/slave odnos je tu čak i više naglašen nego kod pametnih kartica s mikrokontrolerima. Npr. terminal potpuno preuzima fizičko adresiranje memorije. Kartica sama može jedino blokirati pojedina polja protiv brisanja. Ovo kontrolira visoka logika. Ta logika isto upravlja vrlo jednostavnim prijenosima podataka.

6.2 T=0 prijenosni protokol

Ovaj protokol je prvo korišten u Francuskoj tijekom početnog razvoja pametnih kartica i prvi je međunarodno standardiziran protokol za pametne kartice. Kreiran je u ranim danima tehnologije pametnih kartica i dizajniran za korištenje minimalne memorije, a pritom je maksimalno jednostavan. Ovaj protokol koristi se širom svijeta u GSM kartici i najpopularniji je protokol. T=0 protokol standardiziran je u ISO/IEC 7816-3. Dodatne kompatibilne specifikacije sadržane su u GSM 11.11 i EMV specifikacijama.

T=0 protokol je bajt orijentiran što znači da je najmanja jedinica prijenosa bajt. Jedinica podataka koja se prenosi sadrži zaglavlje koje se sastoji od class bajta, komandnog bajta i tri bajta parametra. Ovo može slijediti opcionalni dio podataka. Suprotno APDUs standardiziranom u ISO/IEC 7816-4 standardu, dužina informacije omogućena je samo parametrom P3. To indicira duljinu ili komandnog podatka ili odgovora. To je također specificirano ISO/IEC 7816-3 standardom.

Zahvaljujući bajt orijentaciji T=0 protokola, ako se detektira grješka u prijenosu odmah se zahtjeva ponovni prijenos netočnog bajta. Kod blok protokola, suprotno, čitav se blok (slijed bajtova) mora ponovno prenijeti ako se pojavi grješka. Detekcija grješaka kod T=0 se bazira isključivo na paritetnom bitu koji se dodaje svakom poslanom bajtu.

Slika 15.  Struktura T=0 komande

Ako primalac detektira grješku u prijenosu, mora staviti I/O liniju na nisku razinu u trajanju od jednog etu-a, s početkom na polovici prvog bit intervala čuvanog vremena krivog bajta. Ovo indicira drugoj strani da se posljednji bajt mora ponovno prenijeti. Ovaj mehanizam je veoma jednostavan i ima prednost da je selektivan budući da se ponavljaju samo neispravni bajtovi. No ovaj proces ima nekoliko nedostataka. Većina sučelja ICs uzimaju etu kao najmanju jedinicu za detektiranje pa ne mogu prepoznati nisku razinu na I/O liniji koja se šalje polovično kroz stop bit. Zato standardno sučelje ICs nisu pogodni za T=0 protokol. No ako se svaki bit prima odvojeno preko softvera ovaj se problem ne javlja.

Slika 16.  Bajt prijenos kroz I/O sučelje bez grješke s T=0 protokolom

Kod T=0 protokola moguće je uključiti ili isključiti vanjsko napajanje za programiranje u EEPROM-u ili EPROM-u. To je moguće tako da se dodaje '1' primljenom komandnom bajtu koji se šalje natrag terminalu kao potvrđeni bajt. Stoga su samo komande s parnim vrijednostima dozvoljene, jer u suprotnom ovaj mehanizam ne bi funkcionirao, no uključivanje odnosno isključivanje vanjskog napajanja za programiranje je sada tehnički zastarjelo, jer svi moderni mikrokontroleri pametnih kartica generiraju napajanje za programiranje u samom čipu.

Slika 17.  Grješka kod prijenosa je indicirana kod T=0 protokola s niskom razinom na I/O sučelju kroz čuvano vrijeme

Glavna funkcija čuvanog vremena (guard time) je da odjeljuje pojedinačne bajtove tijekom prijenosa. Tada i pošiljatelj i primalac imaju više vremena da izvrše funkcije protokola prijenosa.

Pretpostavimo da terminal šalje kartici naredbu sa skupom podataka, i tada kartica odgovara s podatkom i povratnim kodom. Terminal prvo šalje kartici zaglavlje veličine 5 bajtova, koje se sastoji od class bajta, naredbenog bajta, P1, P2 i P3 bajtova. Ako je to ispravno primljeno, kartica šalje potvrdu primitka (ACK) u obliku Procedure bajt (PB). Ova potvrda primitka je kodirana isto kao i primljeni komandni bajt. Po primitku procedure bajt, terminal šalje točno broj podatkovnih bajtova koji su navedeni u P3 bajtu. Sada je kartica primila potpunu naredbu te može proslijediti te generirati odgovor.

Ako odgovor sadrži podatak kao dodatak povratnom kodu od 2 bajta, kartica obavještava terminal putem posebnog povratnog koda, s količinom podataka prikazanom u SW2. Nakon primanja ovog odgovora, terminal šalje kartici komandu GET RESPONSE (daj odgovor), koja se sastoji samo od komandnog zaglavlja s količinom podataka koju treba poslati. Kartica sada šalje terminalu podatke generirane nakon prve komande sa zahtijevanom duljinom i odgovarajućim povratnim kodom. Ovim je završen slijed jedne komande.

Ako se kartici šalje naredba, a kartica samo generira povratni kod bez skupa podataka, tada se ne javlja komanda GET RESPONSE. Budući da je za izvršavanje potrebna i dodatna komanda od aplikacijskog sloja (koja se odnosi na pristup podacima iz prethodne komande) naravno više ne postoji stroga podjela između slojeva protokola. Komanda aplikacijskog sloja (GET RESPONSE) mora se koristiti da podrži sloj za povezivanje podataka koji ima utjecaj na ovu aplikaciju.

Slika 18. Tipična T=0 komunikacijska procedura s podacima u komandi i odgovoru

T=0 protokol omogućuje kartici da pojedinačno prima bajtove u skup podataka nakon što je primljeno zaglavlje. Da bi to funkcioniralo samo mora poslati invertirani komandni bajt terminalu kao procedure bajt i tada terminal šalje jedinični podatkovni bajt. Sljedeći podatkovni bajt slijedi naredni procedure bajt s kartice. Ovaj prijenos bajtova odjednom nastavlja se sve dok kartica ne primi sve bajtove iz skupa podataka ili dok ne pošalje ne invertirani komandni bajt terminalu kao procedure bajt. Nakon primanja ne invertiranog komandnog bajta, terminal šalje sve preostale podatkovne bajtove kartici koja je sada primila kompletnu naredbu.

Što se tiče protokola prijenosa, korisnik je prvobitno zainteresiran  za stupanj prijenosa podataka i detekciju grješaka, te korekciju mehanizma. Šaljući bajt koji se sastoji od 8 bitova, traži se prijenos 12 bitova, uključujući i 1 startni bit, 1 paritetni bit i 2 etu-a za čuvano vrijeme. Pri frekvenciji od 3.5712 MHz i vrijednosti djelitelja od 372, prijenos 1 bajta traje 12 etu-a ili 1.25 ms.

Stupanj prijenosa pada ako se jave grješke. No, ovaj mehanizam ponavljanja jediničnih bajtova ima svojih prednosti, budući da samo neispravno primljeni bajtovi moraju biti ponovo preneseni.

Tablica 21.  Vrijeme prijenosa podataka za neke tipične komande za T=0, s frekvencijom sata 3.5712 MHz, vrijednosti djelitelja 372, 2 stop bita i 8 podatkovnih bajtova po komandi

Mehanizam za detekciju grješaka T=0 protokola sastoji se samo od provjere pariteta na kraju svakog bajta. Ovo omogućuje pouzdano prepoznavanje grješaka pojedinačnih bitova, ali grješke dva bita se ne mogu detektirati. Nadalje ako se bajt izgubi tijekom prijenosa između terminala i kartice to će rezultirati beskonačnim petljom (dead lock) na kartici, budući da se čeka na određeni broj bajtova i nije moguć prekid. Jedini praktični način na koji terminal može izaći iz beskonačne petlje je da resetira karticu i počne ispočetka.

Slika 19. Prijem jediničnog bajta s T=0 (UPDATE BINARY)

U uobičajenoj komunikaciji neadekvatna separacija linka i prijenosnog sloja ne uzrokuje nikakve teškoće.

Slika 20. Stanje mašine komunikacijskog procesa pametne kartice za T=0 komunikacijski protokol, bez ispravljanja pogrješke

a procesiranje komande

1 Ne radi ništa

2 Prijem zaglavlja s CLA, INS, P1, P2 i  P3

3 Čekanje na podatkovni odjeljak (P3=broj bajtova)

4 Čekanje komande (zaglavlje s CLA, INS, P1, P2 i P3) (P3= suma primljenih podataka)

5 SW1, SW2 slanje i prijem GET RESPONSE

A Prijem zaglavlja (5 bajtova)

B Koristan podatak (P3>0)?

C Dio korisnog podatka; pošalji procedure bajt terminalu

D Prijem odjeljka podataka (P3=broj bajta)

E Da li komanda sadrži podatkovni odjeljak? (tada izvrši C i D)

F Da li postoji podatak odgovor (bez javljanja grješke)?

G Pošalji SW1 i SW2

H Pošalji koristan podatak odgovor i SW1 + SW2

I Pošalji SW1 i SW2 (SW2= broj primljenih podataka)

J Prijem komande (zaglavlje=5 bajta)

K Da li je primljena komanda GET RESPONSE?

6.3 T=1 prijenosni protokol

T=1 protokol prijenosa je asinkroni half-duplex protokol za pametne kartice. Bazira se na međunarodnom ISO/IEC 7816-3 standardu. Za ovaj protokol važna je specifikacija EMV. T=1 protokol je blok orijentiran. To znači da je najmanja podatkovna jedinica blok.

Ovaj protokol ima strogo odijeljene slojeve i može biti klasificiran u OSI reference model kao podatkovni link sloj. U ovom kontekstu odvajanje sloja također znači da podaci namijenjeni za više slojeve kao što je aplikacijski sloj mogu biti procesirani potpuno transparentno putem podatkovnog link sloja. Nije potrebno da slojevi koji nisu direktno uključeni interpretiraju ili modificiraju sadržaj prenesenih podataka.

Sigurno slanje poruka posebice zahtijeva strogu podjelu slojeva. Samo tada kodirani korisnički podaci mogu biti preneseni sučeljem bez složenih metoda ili trikova. T=1 protokol je trenutno jedini međunarodni protokol za pametne kartice koji omogućuje sigurni prijenos podataka bez ikakvih teškoća.

Proces prijenosa počinje nakon što kartica šalje ATR ili nakon što je završen uspješan PTS. Terminal šalje prvi blok, a sljedeći šalje kartica. Komunikacija se nastavlja prema ovom obrascu, a pošiljatelj su naizmjence terminal i kartica.

Iz toga proizlazi da korištenje T=1 protokola nije ograničeno na komunikaciju pametne kartice i terminala. Koriste ga mnogi terminali za izmjenjivanje korisnih podataka i kontrolnih podataka s računalom na koji su spojeni.

Stupanje prijenosa podataka je jedan od najznačajnijih aspekata svakog protokola.

Tablica 22.  Vrijeme prijenosa podataka za neke tipične komande za T=1, s frekvencijom sata 3.5712 MHz, vrijednosti djelitelja 372, XOR detekcija grješke, 2 stop bita i 8 podatkovnih bajtova po komandi

Struktura bloka

Blokovi koje se prenose imaju dvije prvobitne namjene. Prva je transparentni prijenos podataka specifičnih za aplikaciju, a druga je prijenos podataka za kontrolu protokola i postupak pri pojavi grješaka.

Prijenosni blok sastoji se od inicijalnog početnog polja, informacijskog polja i finalnog završnog polja. Početno i završno polje su obavezni i uvijek moraju biti poslani. No suprotno, informacijsko polje je opcionalno, koristi podatke za aplikacijski sloj. To je ili komanda APDU poslana pametnoj kartici ili odgovor od kartice APDU.

Postoje tri osnovna različita tipa blokova u T=1: informacijski blokovi, blokovi primanja i potvrde i sistemski blokovi. Informacijski blokovi (Iblocks) se koriste za transparentnu razmjenu podataka aplikacijskog sloja. Blokovi od primanja i potvrde (Rblocks) ne sadrže polja podataka i koriste se za pozitivnu ili negativnu potvrdu primitka. Sistemski blokovi (Sblocks) koriste se za kontrolne informacije povezane sa samim protokolom. Ovisno o kojim se kontrolnim podacima radi, oni mogu imati informacijsko polje.

Slika 21.  Struktura T=1 prijenosnog bloka

Početno polje

Početno polje (prologue field) sastoji se od tri pod polja adrese čvora NAD (Node Address), protokol kontrol bajt (PCB) i duljina (LEN). Dugačko je tri bajta i sadrži osnovne kontrolne podatke i pokazivačke podatke za stvarne prijenosne blokove.

Tablica 23. Node address (NAD polje)

Adresa čvora (NAD) To je prvi bajt u početnom polju. Sadrži odredište bloka i adrese izvora. Svaka je kodirana uz korištenje tri bita. Ako se adresa ne koristi, određeni bitovi su nula. Nadalje zbog kompatibilnosti sa starim mikrokontrolerima osigurana je kontrola napajanja za EEPROM ili EPROM programiranje. No ne postoji praktična primjena za ovo budući da svi mikrokontroleri pametnih kartica sada imaju strujnu pumpu u čipu.

Tablica 24. PCB polje za I blok

Protocol contol byte (PCB) To je pod polje koje slijedi adresa čvora (node address). Kao što samo ime kaže služi za kontrolu i nadzor protokola prijenosa. Ovo povećava količinu zahtijevanog kodiranja. PCB polje primarno kodira blok tip kao i povezane dodatne informacije.

Tablica 25.  PCB polje za R blok

Length (LEN) To je kao polje dužine jednog bajta (LEN) pokazuje duljinu informacijskog polja u heksadecimalnom obliku. Njegova vrijednost može biti od 00 do fe. Kod ff je rezerviran za buduća proširenja i trenutno se ne bi trebao koristiti.

Tablica 26.  PCB polje za S blok

Informacijsko polje 

U I bloku informacijsko polje služi kao spremište za podatke aplikacijskog sloja (OSI layer 7). Sadržaj ovog polja je kompletno transparentno prenesen putem protokola prijenosa bez ikakve analize ili evaluacije.

U S bloku ovo polje prenosi podatke za protokol prijenosa. Ovo je jedini slučaj u kojem je sadržaj ovog polja korišten od strane prijenosnog sloja.

Prema ISO standardu veličina informacijskog polja može varirati od '00' do 'FE' (254 bajta). Vrijednost od 'FF' (255) rezervirana je za buduću upotrebu. Terminal i kartica mogu imati I polja različite duljine. Osnovna veličina terminalskog polja je 32 bajta (IFSD=information field size for the interface device (informacija veličine polja za sučelje uređaja)), ovo se može modificirati pomoću posebnog S polja. Ova osnovna vrijednost 32 bajta također odgovara kartici (IFSC=information field size for the card (informacija veličine polja za karticu)) ali to može biti modificirano putem parametara u ATR-u. U praksi veličina I polja za terminal i karticu je između 50 i 140 bajtova.

Završno polje

Ovo polje, koje je preneseno na kraj bloka, sadrži kod za detekciju grješaka koji je izračunan iz svih prijašnjih bajtova u bloku. Izračunavanje obavlja ili LRC longitudinalna kontrola redundancije (longitudinal redundancy check) ili CRC ciklička kontrola redundancije (cyclic redundancy check). Metoda koja se koristi mora biti specificirana u sučeljima karakterima ATR-a. Ako nije specificirana konvencijom koristi se LRC metoda. Drukčije se izvršava CRC izračunavanje prema ISO 3309. Polinom koji se koristi isti je kao i za CCITT preporuku V.41 g(x)=x¹⁶+x¹²+x⁵+1. Oba koda za detekciju grješaka mogu se koristiti samo u tu svrhu, ne mogu ispravljati grješke u bloku.

Jednobitna longitudinalna redundantna kontrolna suma se izračunava putem XOR povezivanja svih prethodnih bajtova u bloku. Ovo izračunavanje može biti izvršeno veoma brzo i njegova implementacija nije kodirana. Uobičajeno se izvodi između slanja ili primanja podataka. To je standardizirani dio praktički svih T=1 implementacija.

Pri korištenju CRC procedure za generiranje detekcije grješaka veća je vjerojatnost detekcije grješaka nego kod XOR provjere. No ovaj se postupak trenutno rijetko koristi u praksi jer su te implementacije ovisne o kodu i spore. Dalje, završno polje mora biti prošireno do dva bajta, što dodatno smanjuje stupanj prijenosa.

Slanje i primanje slijeda brojača 

Svaki blok informacija u T=1 protokolu sad ima broj slanja niza koji se sastoji od samo jednog bita smještenog u PCB bajtu. To je uvećan modulo 2 što znači da varira između 0 i 1. Brojač poslanog slijeda je također označen N(S). Početna vrijednost protokola je inicijalizirana na 0. Brojač kod terminala i pametne kartice uvećava se neovisno jedan o drugome.

Vrijeme čekanja 

Različita vremena čekanja definirana su da omoguće pošiljatelje i primatelje s točno određenim minimalnim i maksimalnim vremenskim intervalima za različite radnje tijekom prijenosa. Također usmjeravaju komunikaciju sa svrhom da se spriječi deadlocks u slučaju grješki. Osnovne vrijednosti su definirane za sva ova vremena u standardu, ali to se može modificirati kako bi se povećao stupanj prijenosa. Modificirane vrijednosti su prikazane u posebnim sučeljima karaktera ATR-a.

Vrijeme čekanja karaktera (CWT) 

To je maksimalni interval između uzlaznih bridova dvaju uzastopnih karaktera u bloku. Primatelj aktivira odbrojavajući sat na svakom uzlaznom bridu s vremenom čekanja karaktera (character waiting time) kao inicijalnom vrijednošću. Ako vrijeme istekne a nije detektiran uzlazni brid novog bita, primalac pretpostavlja da je prijenosni blok u potpunosti primljen. CWT prijemni kriterij stoga se može koristiti općenito za detekciju kraja bloka. No značajno smanjuje stupanj prijenosa, jer se vrijeme za svaki blok povećava za trajanje CWT-a. Zato je bolje detektirati kraj bloka brojanjem primljenih bajtova.

Slika 22.  Definicija vremena čekanja karaktera (CWT)

CWT se izračunava korištenjem podatkovnog elementa CWI koji je sadržan u ATR-u prema sljedećoj formuli:

Osnovna vrijednost za CWI je 13, iz čeka proizlazi sljedeća vrijednost  za CWT:

S frekvencijom od 3.5712 MHz i vrijednošću djelitelja od 372 interval je 0.85 s.

Ovaj interval koji je u standardu specificiran kao interval po osnovnoj vrijednosti je previsok za brze prijenose podataka. U praksi raspon CWI je od 3 do 5. To znači da za normalni slijed prijenosa, u kojem karakteri slijede jedan drugog bez odgode vremena primalac čeka 1 ili 2 bajta prije nego što se detektira kraj bloka ili komunikacije.

Uobičajeno, primalačka rutina detektira kraj bloka iz informacije duljine bloka u LEN polju. No ako je sadržaj ovog polja pogrešan, CWT se koristi kao dodatni način za završavanje primanja. Ovaj problem se javlja samo kad je informacija predugačka, jer u ovom slučaju bi primalac čekao na dodatne karaktere koji nikada ne bi stigli, to bi blokiralo protokol prijenosa i takvo stanje može se ispraviti jedini resetiranjem kartice. CWT mehanizam nadilazi ovaj problem.

Vrijeme čekanja bloka (BWT) Svrha vremena čekanja bloka (block waiting time) je da završi komunikaciju ako pametna kartica ne šalje odgovor. To je najveći dozvoljeni interval između uzlaznog brida posljednjeg bajta u bloku poslanog kartici i uzlaznog brida poslanog natrag od kartice.

Slika 23.  Definicija vremena čekanja bloka (BWT)

U okviru konvencionalnog T=1 bloka, to je maksimalni interval koji je dozvoljen između vodećeg brida u XOR bajtu završnog polja komandnog bloka i vodećeg brida u NAD bajtu u odgovoru kartice. Ako ovaj period čekanja istekne bez primljenog odgovora kartice terminal može pretpostaviti da je kartica s grješkom i inicirati prikladnim odgovorom. To npr. može biti resetiranje kartice koju slijedi novi pokušaj da se uspostavi komunikacija.

Sučelje karaktera u ATR-u određuju BWT koji je kodiran u skraćenom obliku BWI.

Ako vrijednost BWI nije definirana u ATR-u koristi se osnovna vrijednost 4 kod 3.5712 MHz i vrijednosti djelitelja od 372, BWT je 1.6s:

Kao što se može vidjeti ova je vrijednost prilično velika. U praksi često se koristi vrijednost 3 za BWI i tada je BWT 0.8 s. Tipična vremena za izvršenje komande na kartici je oko 0.2 s. BWT navedenog trajanja je zapravo kompromis između normalnog vremena i brze detekcije pametne kartice da više ne odgovara na komande.

Čuvano vrijeme bloka (BGT) To je najmanji interval između vodećeg brida posljednjeg bajta i vodećeg brida prvog bajta u suprotnom smjeru. Ono je suprotno BWT koji je definiran kao maksimalno vrijeme između dva definirana vodeća brida. Druga razlika je ta što je BGT obavezan za obje strane i mora biti promatrano, dok BWT je značajno samo za pametnu karticu. Svrha BGT je da opskrbi blok pošiljatelja s minimalnim vremenskim intervalom u kojem se može prebacivati između slanja i primanja.

Slika 24.  Definicija block guard time (BGT)

BGT ima fiksnu vrijednost a to je standardizirano na 22 etu. Kod pametne kartice koja radi s 3.5712 MHz i s vrijednošću djelitelja od 372 ovaj interval je oko 2.3 ms.

Mehanizmi protokola prijenosa

Proširenje vremena čekanja Ako kartica treba više vremena da generira odgovor no što maksimalno dopušta BWT, može zatražiti proširenje vremena čekanja od terminala. Pametna kartica to radi tako da šalje posebni S blok koji traži proširenje i prima odgovarajući S blok kao potvrdu primitka od terminala. Terminalu nije dopušteno da odbije ovaj zahtjev.

Bajt u informacijskom polju obavještava terminal o duljini proširenja. Ovaj bajt, pomnožen s BWT daje novi BWT. No ovo vrijedi samo za posljednji poslani I blok.

Slika 25.  Procedura za proširenje vremena čekanja

Ulančavanje bloka Jedna od najvažnijih značajki u izvedbi T=1 protokola je funkcija ulančavanja bloka. Ona omogućuje objema stranama slanje blokova podataka koji su veći od poslanih ili primljenih spremnika. Ovo je posebno korisno zbog ograničenih kapaciteta memorije pametnih kartica. Ulančavanje je dozvoljeno samo za informacijske blokove, jer samo takvi blokovi mogu sadržavati velike količine podataka. U procesu ulančavanja, aplikacijski podaci su podijeljeni u pojedinačne blokove koji se šalju primaocu jedan za drugim.

Aplikacijski slojevi podataka moraju biti podijeljeni tako da niti jedan od gotovih segmenata ne bude veći od bloka primaoca maksimalne veličine. Prvi se segment smješta u informacijsko polje u skladu s T=1 protokolom, dodaje mu se početno i završno polje te se šalje primaocu. U PCB polju bloka smješta se M bit (more data bit) koji primaocu indicira da se koristi funkcija ulančavanja bloka, i da su ulančani podaci smješteni u slijedeće blokove.

Kada primalac primi informacijski blok s prvim segmentom korisničkih podataka, on indicira da je spreman primiti slijedeći ulančani I blok tako što vrati R blok čiji je broj slijeda N(R) koji je poslani zbroj slijeda N(S) slijedećeg I bloka. Zatim se slijedeći blok šalje primaocu.

Ovaj naizmjenični prijenos I i R blokova nastavlja se dok pošiljatelj ne dođe do bloka čiji M bit indicira da je to zadnji blok u lancu (M bit=0). Nakon što je ovaj blok primljen, primalac ima sve podatke aplikacijskog sloja i može procesirati potpuni blok podataka.

Postoji jedno ograničenje koje se odnosi na rutinu ulančavanja bloka. Unutar jednog kruga naredba/odgovor, ulančavanje se može nastaviti samo u jednom smjeru. Npr. ako terminal šalje ulančane blokove, kartica ne može slati ulančane blokove u odgovoru.

Postoji dodatno ograničenje koje nema veze s protokolom, već se odnosi na ograničenu memoriju kartice. Implementacija mehanizma ulančavanja bloka podrazumijeva određenu količinu dodatnog softvera, dok je korisnost veoma ograničena, jer naredbe i odgovori nisu tako dugački i obično ne zahtijevaju ulančavanje. Ako prijemni spremnik kod kartice nije dovoljno velik da pohrani sve podatke prenesene u ulančavanju potrebno je smjestiti ovaj spremnik u EEPROM. No tada dolazi do velikog smanjenja stupnja prijenosa, jer se u EEPROM-u (što je suprotno RAM-a) ne može pisati pri punoj brzini procesora.

Stoga mnoge T=1 implementacije nemaju ovu funkciju budući da je troškovi i korisnost ne opravdavaju. Ovo je tipični primjer činjenice da se standardi često interpretiraju veoma slobodno u praksi. U ovom slučaju to blok ulančavanje može biti dodatna opcija T=1 ali nije nužno potrebna.

Slika 26.  Primjer ulančavanja bloka za prijenos podataka od terminala ka pametnoj kartici

Rukovanje grješkama

T=1 protokol ima visoko razvijenu detekciju grješaka i mehanizme za rukovanje. Kod primanja krivih blokova protokol će nastojati povratiti komunikaciju bez grješaka putem točno definiranih postupaka.

S aspekta terminala postoje tri povezana stupnja. Na prvom stupnju, pošiljatelj pogrešnog bloka prima R blok koji indicira EDC/paritetnu bit grješku ili opću grješku. Primalac ovog R bloka mora tada ponovno poslati posljednji blok.

Ako se pokaže da je nemoguće povratiti vezu bez grješaka prelazi se na sljedeći stupanj. To znači da pametna krtica prima preusklađeni zahtjev od terminala u obliku S bloka. Terminal očekuje ispravljeni odgovor. Terminal i kartica tada oboje resetiraju svoje brojače primanja i slanja na nulu, što odgovara statusu protokola odmah nakon ATR-a. Na osnovi ovoga terminal pokušava uspostaviti novu vezu.

Stupnjevi jedan i dva tiču se samo slojeva protokola. Oni nemaju utjecaja na samu aplikaciju. No treći stupanj tiče se svih slojeva na pametnoj kartici. Ako terminal ne može uspostaviti vezu bez grješaka korištenjem prva dva stupnja uključuje resetiranje pametne kartice putem reset voda. No ovo znači da su svi tekući podaci izgubljeni. Nakon resetiranja komunikacije se moraju ponovno uspostaviti od početka.

Ako ni ova procedura ne pomogne u uspostavljanju radne veze terminal deaktivira karticu nakon tri pokušaja. Korisnik tada obično prima poruku o grješki da je kartica neispravna.

Tablica 27. Stanja kod T=1 rukovanja grješkama

7. Struktura poruka: APDUs

Čitava izmjena podataka između terminala i pametne kartice događa se putem APDUs. Termin APDU je skraćenica za podatkovnu jedinicu aplikacijskog protokola (application protocol data unit). To označava međunarodnu standardiziranu podatkovnu jedinicu u aplikacijskom sloju, a to je layer 7 u OSI modelu. Ovaj sloj je smješten direktno iznad razine protokola prijenosa na pametnoj kartici. TPDUs podatkovna jedinica prijenosnog protokola (transport protocol data units) je ovisna o protokolu i suprotno prethodnom to su podatkovne jedinice sloja koji je direktno ispod. Postoji razlika između naredbe APDUs, koja predstavlja naredbe kartice, i odgovora APDUs koji su odgovori kartice na ove naredbe. Jednostavnim riječima APDUs je neka vrsta spremnika koja sadrži čitave naredbe za karticu ili kompletni odgovor od kartice. APDUs se transparentno prenose protokolom prijenosa, a to znači bez modifikacije ili interpretacije.

APDUs koji surađuju s ISO/IEC 7816-4 standardom su dizajnirani da budu neovisni o protokolu prijenosa. Sadržaj i format APDU se ne smije mijenjati kada se koriste različiti protokoli prijenosa. To se iznad svega odnosi na dva standardizirana protokola T=0 i T=1. Zahtjev za neovisnošću protokola utjecao je i na dizajn APDUs, budući da treba biti moguće transparentno ih prenositi korištenjem oba protokola, bajt orijentiranog T=0 i blok orijentiranog T=1.

7.1 Struktura naredbe APDU

Naredba APDU je sastavljena od zaglavlja i tijela. Tijelo može biti različite duljine ili ga ne treba biti ako je određeno podatkovno polje prazno. Zaglavlje se sastoji od četiri elementa: class bajt (CLA), instrukcijski bajt (INS) i dva parametar bajta (P1 i P2). Class bajt se još uvijek koristi za identificiranje aplikacija i njihovih posebnih setova naredbi. Npr. GSM koristi class bajt A0, dok se kod 8X vrlo rašireno koristi za posebne naredbe (privatna upotreba). Suprotno, ISO bazirane naredbe se kodiraju bajtom 0X. Standardom se dodatno određuje koji se class bajtovi koriste za identifikaciju sigurnog slanja poruka i logičkih kanala. Ovo je još uvijek kompatibilno s korištenjem class bajta kao aplikacijskog identifikatora kao što je prethodno navedeno.

Sljedeći bajt u naredbi APDU je instrukcijski bajt koji kodira stvarnu naredbu. Gotovo čitav adresni prostor ovog bajta može biti iskorišten s jedinim ograničenjem da samo parni kodovi mogu biti korišteni. To je zato što T=0 protokol dopušta aktiviranje programskog napajanja tako da se vrati instrukcijski bajt uvećan za jedan u procedure bajtu. Instrukcijski bajt zato uvijek mora biti paran.

Dva parametarska bajta se primarno koriste da daju više informacija o naredbi koju je izabrao instrukcijski bajt. Stoga oni uglavnom služe kao prekidači koji odabiru različite opcije naredbi.

Slika 27.  Struktura komande APDU

Odjeljak koji slijedi zaglavlje je tijelo, i nije potreban s iznimkom oznake za duljinu. Tijelo ima dvostruku ulogu. Prvo određuje duljinu dijela podataka poslanih kartici (u Lc polju) kao i duljinu odjeljka podataka koji će biti poslani natrag od kartice (u Le polje). Drugo sadrži podatke povezane s naredbama poslanim kartici. Ako je vrijednost Le polja ''00'', terminal očekuje da kartica pošalje maksimalnu količinu podataka koji su dostupni za ovu naredbu. Ovo je jedina iznimka numeričkoj oznaci duljine.

Tablica 28. Najznačajniji class bajt (CLA) kodovi određeni u ISO/IEC 7816-4

Tablica 29. Kratak pregled prijenosa class bajta u aplikaciju

Slika 28.  Struktura proširenog Lc ili Le polja

Le i Lc polja su obično dugačka 1 bajt. Moguće ih je promijeniti u polja dugačka tri bajta. Ona se mogu koristiti da zastupaju duljine do 65.536, jer prvi bajt sadrži escape sequence ''00''. Standard već definira ovu oznaku duljine od tri bajta za buduće aplikacije, ali ovo još ne može biti implementirano zbog ograničenja trenutno dostupne memorije. Prethodno opisani dijelovi komande APDU mogu se kombinirati tako da rezultiraju s četiri opća slučaja koja su opisana na slici 29.

Slika 29.  Četiri moguće komande APDU

7.2 Struktura odgovora APDU

Odgovor APDU, koji kartica šalje kao odgovor na komandu APDU sastoji se od opcionalnog tijela i obaveznog polja kao što je pokazano na slici 30. Tijelo se sastoji od podatkovnog polja, čija je duljina specificirana s u Le bajtu prethodne naredbe APDU. Duljina podatkovnog polja može biti 0, bez obzira na vrijednost specificiranu u naredbi APDU, ako pametna kartica završi procesiranje naredbe zbog neispravnih parametara. To se indicira riječima u dva pojedinačna bajta SW1 i SW2 u obaveznom polju.

Slika 30.  Dva tipa odgovora APDUs, SW1 i SW2 predstavljaju obavezno polje, a data field je opcionalno polje

Kartica uvijek mora poslati SW1 i SW2 kao odgovor na komandu. Dva bajta SW1 i SW2 koji se također zovu povratni kod, kodiraju odgovor na komandu. Npr. povratni kod ''9000'' znači da je komanda potpuno izvršena i to uspješno. Osnovna shema klasifikacije više od pedeset različitih kodova prikazana je na slici 31.

Slika 31.  Shema klasifikacije povratnih kodova definirana s ISO/IEC 7816-4 standardom. Povratni kodovi '63XX' i '65XX' indiciraju da su podaci u neizbrisivoj memoriji (EEPROM) promijenjeni, kod preostali '6X' kod indicira da je memorije nepromijenjena

Ako se nakon izvršene komande natrag šalje povratni kod ''63xx'' ili ''65xx'' to znači da je stalna memorija kartica (obično EEPROM) modificirana. Ako je vraćen neki drugi kod koji počinje s ''6x''  naredba je izvršena bez modificiranja stalne memorije.

Treba naglasiti da iako postoji standard za povratne kodove, mnoge aplikacije koriste nestandardne kodove. Jedina iznimka je kod ''9000'' koji gotovo univerzalno indicira uspješno izvršenje. Kod drugih kodova je uvijek potrebno pogledati podcrtanu specifikaciju da budemo sigurni u njihovo pravo značenje.

8. Sigurni prijenos podataka

Čitava izmjena podataka između terminala i pametne kartice bazira se na digitalnim električnim impulsima na I/O liniji pametne kartice. Shvatljivo je i tehnički izvedivo povezati žicu na I/O kontakt, snimiti sve komunikacije koje su bile u jednom navratu i kasnije ih analizirati. Na ovaj način moguće je nešto naučiti iz podataka koji su preneseni u oba smjera.

Mnogo je teže električki izolirati I/O kontakt, ugraditi lažni kontakt na vrh toga, i onda koristiti tanke žice da se povežu oba kontakta s računalom. Na ovaj načina, lako je dopustiti da samo određene naredbe dođu do kartice ili umetnuti svoje vlastite naredbe.

Oba ova tipična načina napada mogu uspjeti samo ako tajni podaci prođu nezaštićeni preko I/O linije. Prijenos podataka stoga treba biti u osnovi dizajniran tako da ako je i neki napadač sposoban uči u prijenos podataka i umetnuti svoje vlastite blokove podataka, neće moći iskoristiti tu prednost.

Postoje različiti mehanizmi i procedure koji se mogu koristiti kao zaštita protiv ovakvih napada, i protiv mnogo složenijih napada napada. To su sve jednim zajedničkim imenom sigurne poruke. Ovi mehanizmi nisu određeni na pametnoj kartici, budući da se koriste već duže vrijeme u komunikaciji podataka na velikim udaljenostima. Što je posebno u domeni pametne kartice je da nisu posebno visoki niti stupanj prijenosa niti moć proračuna nad stranama komunikacije. Često korištene standardne procedure su posložene tako da bi se slagale s mogućnostima pametne kartice bez ugrožavanja njene sigurnosti.

Slika 32. Podaci i funkcije potrebne za sigurnosni mehanizam

Svrha sigurnih poruka je osigurati autentičnost i ako je moguće povjerljivost dijela ili svih prenesenih podataka. Postoje različiti mehanizmi koji se koriste u tu svrhu. Sigurnosni mehanizam je definiran kao funkcija koja podrazumijeva sljedeće elemente: kriptografski algoritam, ključ, argument i početni podatak ako je potrebno. Mora biti zadovoljen i opći uvjet, a to je da svi sigurnosni mehanizmi moraju biti potpuno transparentni s prisutnim protokolnim slojevima. Time se osigurava da sigurne poruke neće štetno djelovati na već standardizirane i dostupne procedure. Ovo se posebno tiče prijenosnih protokola T=0 i T=1, kao i standardiziranih naredaba pametne krtice.

Prije izvršenja procedure sigurne poruke obje strane moraju se složiti koji će kriptografski algoritam koristiti te koji tajni ključ. Prema Kerkhoffom principu sigurnost čitave procedure ovisi o ključu. Ako je otkriven, sigurne poruke su zapravo opće poznate.

Postoji nekoliko tipova sigurnih poruka koje se koriste već godinama. One su sve relativno stroge i namijenjene određenim aplikacijama. Većinu njih je vrlo teško probiti kada je sigurnost u pitanju. No nijedna nije postala međunarodno dominantna ili se pokazala dovoljno fleksibilna da bi je uključili u tekući standard.

Zbog zahtjeva za transparentnošću s postojećim naredbama, te da podrže dva osnovna različita protokola prijenosa i budu maksimalno prilagodljive, došlo je standardizacije fleksibilnih (ali i skupih i kompliciranih) procedura sigurnih poruka u ISO/IEC 7816-4 standardu s proširenim funkcijama koje su definirane u ISO/IEC 7816-8. Ta se procedura bazira na povezivanju svih korisnih podataka u TLV-kodiranim podatkovnim elementima. Definirani su tri različita tipa podatkovnih objekata:

- za obični tekst podaci u običnom tekstu(tj. podatkovni odjeljak APDU)

- za sigurnosne mehanizme rezultati sigurnosnog mehanizma (tj. MAC)

- za pomoćne funkcije kontrolne informacije za sigurne poruke (tj. Padding metode)

Class bajt indicira koristi li se sigurna poruka za naredbu. Dva preostala bajta mogu kodirati da li procedura specificirana u ISO/IEC 7816-4 i je li iskorištena, te je li kriptografska kontrolna suma pokrila zaglavlje. Zaglavlje je autentično ako je uključeno u izračunavanje i ne može biti mijenjano tijekom prijenosa a da se to ne primijeti.

Podatkovni objekti za običan tekst

Prema standardu svi podaci koji nisu BER- TLV kodirani moraju biti ugrađeni u podatkovne objekte. Postoje različiti kodovi za identifikaciju koji su prikazani u tablici 30. Bit 1 svakog koda indicira da su podatkovni objekti uključeni u izračunavanje kriptografske kontrolne suma. Ako je ovaj bit postavljen (tj. ''B0''), podatkovni objekti nisu uključeni u kalkulaciju.

Tablica 30. Kodovi za podatkovne objekte običnog teksta

Podatkovni objekti za sigurnosne mehanizme

Podatkovni objekti koji se koriste kod sigurnosnih mehanizama se dijele na one koji se koriste za autentičnost i na one koji se koriste za povjerljivost. U tablicama 31 i 32 navedeni su identifikacijski kodovi koji se koriste u ovu svrhu.

Tablica 31. Kodovi za autentičnost podatkovnih objekata

Općenito, pojam autentičnost odnosi se na sve podatkovne objekte koji su povezani s kriptografskim kontrolnim sumama i digitalnim potpisima. Kriptiranje podataka i informacije koje su potrebne za prepoznavanje takvih kriptiranih podataka unutar sigurnih poruka pripadaju unutar rubrike ''povjerljivo''. Ovisno o tome koja se procedura koristi, treba potražiti prikladne kodove u tablicama i koristiti ih za sigurne poruke.

Tablica 32. Kodovi za povjerljive podatkovne elemente

Podatkovni objekti za pomoćne funkcije

Podatkovni objekti za pomoćne funkcije koriste se u sigurnim porukama radi usklađivanja općih uvjeta. Dvije strane koriste ove podatkovne objekte da izmijene informacije o kriptografskim algoritmima i ključevima koji se koriste, o početnim podacima i sl. U principu, ovo može varirati sa svakim prenesenim APDU ili čak između naredbe i odgovora. No u praksi ovi se podatkovni objekti rijetko koriste, jer su svi opći uvjeti za sigurne poruke implicitno definirani. To znači da oni ne trebaju biti posebno definirani u svrhu komunikacije.

Na osnovi mogućnosti koje nude sigurne poruke, kao što je specificirano prema ISO/IEC 7816-4 standardu, možemo opisati dvije osnovne procedure. Visok stupanj fleksibilnosti znači da postoje mnoge kombinacije sigurnosnih mehanizama od kojih su neki veoma složeni. Dvije procedure koje su ovdje opisane predstavljaj kompromis između jednostavnosti i sigurnosti.

Autentični mod (authentic mode) je procedura koja koristi kriptografsku kontrolnu sumu (CCS ili MAC) radi zaštite aplikacijskih podataka (APDU) od manipulacije tijekom prijenosa. Kombinirani mod (combined mode) je procedura koja se, suprotno, koristi za potpuno kriptiranje aplikacijskih podataka, tako da napadač ne može ništa zaključiti o podacima iz komandi i odgovora koji se izmjenjuju. U kombinaciji sa samo jednom od ovih procedura može se koristiti brojač poslanih nizova. Ovaj brojač, čija je početna vrijednost slučajni broj, je uvećan za svaku naredbu i za svaki odgovor. Ovo omogućuje objema stranama da odrede jesu li naredba ili odgovor bili izgubljeni ili umetnuti. Kad se koristi sa 'combined' procedurom, ovaj brojač čini identične APDUs da izgledaju različiti. Ovo je tzv. razlika (diversity).

8.1 Procedura autentični mod

Ova procedura garantira autentični prijenos APDUs, što znači da APDUs ne mogu biti izmijenjene tijekom prijenosa. Primalac APDUa koji može značiti naredbu ili odgovor, može odrediti jeli APDU promijenjen tijekom prijenosa. Zato je nemoguće da napadač modificira podatke unutar APDU a da to primalac ne zamijeti.

Činjenicu da se ova procedura koristi indicirani bit u class bajtu, tako da primalac zna da može provjeriti autentičnost primljenog APDU. APDUs se šalju u običnom tekstu i nisu kriptirani. Preneseni podaci su zato javni, i odgovarajućom manipulacijom prijenosnog kanala napadač ih može presresti i evaluirati. Ovi nije nužno nedostatak, jer i onako nije preporučeno slati povjerljive podatke preko javnog kanala. Nadalje, korisnik kartice bar teoretski može vidjeti podatke koji se izmjenjuju između pametne kartice i terminala.

U principu, svaki algoritam blok enkripcije može se koristit za izračunavanje kriptografske kontrolne sume. Iz praktičnih razloga ovdje se pretpostavlja korištenje DES s fiksnom duljinom bloka od 8 bajta. Pojedinačni podatkovni objekti moraju sa zato uvećati do veličine integer pomnoženog s 8 bajta, što se zove punjenje (padding). U ovom procesu, podatkovni objekti koji su već integeri pomnoženi s 8 bajtova se proširuju za 1 blok. Nakon punjenja, kriptografska kontrolna suma (CCS) čitavog APDU izračunava se pomoću DES algoritma u CBC modu. Ova 8 bajtna kontrolna sumaje pridodana direktno na APDU kao TLV kodirani podatkovni objekt, i 4 najmanje značajna bajta su izostavljena. Svi punjeni bajtovi su izbrisani nakon što se izračuna kontrolna suma. Modificirani APDU se tada šalje putem sučelja. Ova procedura povećava duljinu APDU za 8 bajtova koji samo okvirno smanjuju stupanj prijenosa ako se koriste blokovi normalnog prijenosa.

Podatkovni objekti za kontrolne strukture mogu eksplicitno indicirati koji se algoritam i punjenja metoda koristi. Ovdje ćemo opet pretpostaviti, zbog jednostavnosti da pametna kartica i terminal implicitno znaju sve parametre sistema sigurnih poruka koji se koriste.

Kad zaštićeni APDU stigne do primaoca on ga puni do integera pomnoženog s 8 bajtova i tada izračunava vlastiti MAC za APDU. Uspoređujući svoj MAC s MAC-om od pošiljatelja, primalac može odrediti jeli APDU promijenjen tijekom prijenosa. Preduvjet za izračunavanje kriptografske kontrolne sume je tajni DES ključ koji je poznat objema stranama. Kad ovaj ključ ne bi bio tajni napadač bi mogao upasti u autentični mod komunikacijske procedure tako da presretne APDU, modificira ga kako želi i izračuna novi ''ispravni'' MAC. Nakon toga samo mora zamijeniti originalni MAC s novim i poslati novi kreirani APDU.

Da bi se bolje zaštitili ključevi koji se koriste da generiraju MAC od napada koji se baziraju na poznatim obični tekst – jeftin tekst (plain text – chiper text) parovima, obično se koriste dinamički ključevi. Oni se generiraju tako da se kriptira slučajni broj koji je prethodno izmijenjen između terminala i kartice. Za ovo kriptiranje koristi se tajni ključ koji je poznat objema stranama.

Dodatni koraci koji su potrebni za prijenos i primanje APDU koji je zaštićen autentičnom mod procedurom smanjuju efektivni stupanj prijenosa podataka. Prosječno dobra bi procjena bila pretpostaviti da će stupanj biti za pola manji nego kod nezaštićenog običnog teksta.

Slika 33. Generiranje komande APDU s procedurom autentični mod. Slučaj 3 komande (UPDATE BINARY) je ovdje uzet, sa zaglavljem uključenim u kriptografsku kontrolnu sumu (CCS). Odgovor APDU može biti generiran na jednostavan način. 'PB' indicira punjene bajtove.

Korak 1 Osnovni APDU format

Korak 2 Podatkovni odjeljak je pokriven u TLV kodiranim podatku, i podatkovni objekt je punjen s integer pomnoženim s 8 bajtova

Korak 3 Izračunat je CCS

Korak 4 TLV-kodirani podatkovni objekt sadržava CCS dodan APDU

8.2 Procedura kombinirani mod

U usporedbi s procedurom autentični mod, ova procedura predstavlja viši stupanj sigurnosti. Tu se podatkovni odjeljak APDU više ne prenosi kao obični tekst, već u kriptiranom obliku. To je zapravo proširenje procedure autentični mod.

Kod obje procedure, oni podatkovni objekti koji trebaju biti zaštićeni s kriptografskom kontrolnom sumom se prvo pune do integera pomnoženog s osam bajtova, a zatim kriptiraju putem DES u CBC modu. Zbog kompatibilnosti s T=0 protokolom, zaglavlje se ispušta iz ovog procesa. Ako se želi kriptirati također i zaglavlje, tako da kartica ne može prepoznati naredbu koja joj se šalje, mora se koristiti naredba T=0 ENVELOPE. Korištenje sigurnih poruka indicira jedan bit u class bajtu. Podaci se prenose preko sučelja nakon što su kriptirani. Budući da primalac zna tajni ključ koji je korišten za enkripciju on može dekriptirati APDU primalac tada provjerava točnost dekripcije ponovnim izračunavanjem proširene kriptografske kontrolne sume na istoj razini kao i transformacijski sloj.

Slika 34. Kreiranje komande APDU s procedurom kombinirani mod. Slučaj 3 komande (UPDARE BINARY) je ovdje uzet, sa zaglavljem uključenim u kriptografsku kontrolnu sumu (CCS). Odgovor APDU je kreiran na jednostavan način. 'PB' indicira punjene bajtove.

Korak 1 Osnovni APDU format

Korak 2 Podatkovni odjeljak je pokriven u TLV kodiranim podatku, i podatkovni objekt je punjen s integer pomnoženim s 8 bajtova

Korak 3 Izračunat je CCS

Korak 4 TLV-kodirani podatkovni objekt sadržava CCS dodan APDU

Korak 5 APDU podatkovni odjeljak je kriptiran

Kad se koristi ova procedura, napadač koji prisluškuje na I/O liniji ne može otkriti koji se podaci izmjenjuju između kartice i terminala u naredbama i odgovorima. Isto je nemoguće zamijeniti jedan od kriptiranih blokova unutar APDU, jer su blokovi povezani jedan s drugim putem DES u CBC modu. Svaku zamjenu bi primalac odmah uočio.

Zahvaljujući kriptografskom algoritmu, isti komentari u opisu procedura autentični mod mogu se i ovdje primijeniti. Ključevi bi trebali biti dinamični kao i kod autentičnog moda tako da se derivirani ključ koristi za svaku sesiju.

Ako se uzmu u obzir stupanj sigurnosti, može se preporučiti upotreba ove procedure za sve APDUs. No veći stupanj sigurnosti popraćen je s smanjenjem stupnja prijenosa.

Dobra procjena razlike u stupnju prijenosa između nezaštićenih APDUs i zaštićenih kombiniranim modom je faktor veličine četiri. Razlika između autentičnog i kombiniranog moda može se izraziti faktorom veličine dva. Zato je potrebno pregledati svaki slučaj da se utvrdi koji će se podaci prenositi ovako sigurno ali i sporije.

8.3 Brojač poslanih nizova

Korištenje ovog mehanizma za sigurne poruke nije samo po sebi sigurna procedura. To ima smisla smo tada kad se brojač poslanih nizova (send sequence counter) SSC koristi u kombinaciji s autentičnim ili kombiniranim modom, jer bi u svakom drugom slučaju bilo kakva napadačeva modifikacija brojača ostala neprimjećena.

Ovaj brojač radi na principu da svaki APDU ima svoj redni broj koji ovisi o vremenu kad je poslan. Ovo omogućuje da se odmah uoči ako se otkloni ili umetne APDU u tijek procedure, tako da primalac može poduzeti određene mjere (koje prekidaju vezu).

Ova se funkcija bazira na brojaču sa slučajnim brojem. Ovaj se broj šalje terminalu od kartice na početku komunikacijskog procesa, kao odgovor na zahtjev terminala. Brojač se uvećava svaki put kad se šalje APDU. Brojač ne bi trebao biti previše kratak, ali ni predugačak, zbog dodatnog punjenja u prijenosu. U slijedećem opisu uzeta je duljina od dva bajta mada se koriste i dulji brojači.

Slika 35. Dva načina uključivanja brojača poslanih nizova u komandi APDU. U prvom tipu, brojač poslanih nizova je TLV-kodiran podatkovni objekt u podatkovnom odjeljku. U drugom tipu, brojač poslanih nizova je povezan s APDU podatkom ako je XOR operacija uzeta za izračunavanje CCS.

Postoje dva osnovna načina da se redni broj ugradi u naredbe i odgovore APDUs. Vrijednost brojača može se direktno smjestiti u APDU kao brojčana vrijednost u podatkovnom objektu, ili vrijednost brojača može biti XOR s odgovarajućom količinom podataka u APDU, a zatim se izračunava kriptografska kontrolna suma i modificirani podaci se vračaju APDU. Primalac ovog APDU zna očekivanu vrijednost brojača i može koristiti ovu vrijednost da modificira APDU na isti način kao i pošiljatelj. Nakon toga može izračunati kriptografsku kontrolnu sumu i provjeriti ispravnost primljenog APDU.

Slika 36.  Prenošenje APDUs s brojačem poslanih nizova(SSC)

Proces koji se događa tijekom komunikacije ide ovako. Terminal prvo traži početnu vrijednost brojača od pametne kartice. Pametna kartica vraća slučajni broj od dva bajta terminalu. Terminal tada šalje prvu sigurnu naredbu kartici s rednim brojem. Mogu se koristiti autentični ili kombinirani mod da zaštite brojač i tijelo. Kartica prima zaštićeni APDU i prvo provjerava jeli autentični ili kombinirani mod indicirao bilo kakve neovlaštene promjene. Zatim uspoređuje vrijednost brojača s očekivanom vrijednošću. Ako se to poklapa, tijekom prijenosa se neće umetati niti brisati APDU.

Očito je da je zgodno koristiti ovaj brojač ne samo kad treba izvršiti nekoliko naredbi u određenom slijedu, već i kod pojedinačnih naredbi, jer je tada svaka sesija jedinstvena kada se koristi brojač. Korištenje brojača primarno daje zaštitu od ponavljanja APDUs koji su prethodno poslani, i brisanja APDUs.

Ako se brojač koristi zajedno s procedurom kombinirani mod, svaki kriptirani blok je jedinstven, što dovodi do uvjeta koje zovemo razlika. Ovo je posljedica toga što se brojač uvećava svaki put kada se izmjenjuje APDU, i činjenice da dobar algoritam enkripcije pri promjeni jednog bita u običnom tekstu utječe na izgled čitavog jeftinog takst bloka.

9. Zaključak

U ovom pregledu obrađen je osnovni način komunikacije na vrlo niskoj razini između terminala i pametne kartice. Opisani su najčešće korišteni protokoli za prijenos podataka T=0 i T=1, te sigurni prijenos podataka koji se oslanja na DES algoritam kriptiranja.

Ovdje nije obrađena komunikacije terminal računalo. Također nije obrađeno kako sam operacijski sustav komunicira s terminalom. Najveći problem koji sam primijetio kod komunikacijskih standard je njihova relativna nestandardnost, koja dosta ovisi o proizvođaču i njegovoj definiciji vlastitih procedura.

10. Dodatak: Standardi

ISO/IEC

International Organization for Standardization izdala je standard ISO/IEC 7816 «Identification cards – Integrated circuit cards with contacts». On definira najvažnije karakteristike kontaktnih čip kartica:

ISO/IEC 7816

- 1. dio – fizičke karakterisitike

- 2. dio – dimenzije i položaj kontakata

- 3. dio – električni signali i transportni protokoli

- 4. dio – međuindustrijske naredbe

- 5. dio – identifikator aplikacije

- 6. dio – međuindustrijski podatkovni elementi

- 7. dio – međindustrijske SCQL naredbe

GSM

European Telecommunications Standards Institute (ETSI) izdao je standard koji pokriva korištenje pametnih kartica u javnim i mobilnim telefonskim sustavima. Global System for Mobile Communications GSM definiran od ETSI, je standardna specifikacija međunarodnog zemaljskog mobilnog telefonskog sustava. Značajni GSM standardi su :

- GSM 11.11 – specifikacija SIM modula

-  GSM 11.14 – specifikacija alata za razvoj aplikacija SIM modula

- GSM 03.48 – sigurnosni mehanizmi alata za razvoj aplikacija SIM modula

- GSM 03.19 – SIM API za Java Card platformu. SIM API je proširenje Java Card 2.1 API.

EVM

Europay, MasterCard i Visa definirale su EMV specifikaciju. Ona je nastala kao proširenje ISO 7816 standarda u smjeru specifičnih potreba financijske industrije. Zadnja verzija specifikacije, EMV 96 verzija 3.3.1, izdana je u svibnju 1998 i dolazi u tri dijela:

- EMV ´96 Integrated Circuit Card specifikacija

-  EMV ´96 Integrated Circuit Card Terminal specifikacija

- EMV ´96 Integrated Circuit Card Application specifikacija

11. Literatura

1.                  Zhiqun Chen Java Card Technology for Smart Cards 

2.                  W. Rankl, W. Effing Smart Card Handbook Second Edition

3.                  OpenCard consortium, http://www.opencard.com