Smart Card Penositelji Podataka

1. Uvod

Pametna kartica (eng. smard card) je prijenosno i na napade otporno računalo. Pametne kartice spremaju i procesiraju informacije, te su istih fizičkih dimenzija kao kreditne kartice. Za razliku od magnetskih kartica, mogu osim čuvanja i obrađivati podatke.

Izmjena podataka između terminala i pametne kartice bazira se na digitalnim električnim impulsima na U/I liniji pametne kartice. Komunikacija kartice i terminala je dvosmjerna, što je preduvjet za sve interakcije između pametnih kartica i terminala. Komunikacija se obavlja naizmjenično slanjem i primanjem podataka. Trenutno je u uporabi poludupleks komunikacija iz razloga što postoji samo jedna linija za komunikaciju. Potpuna dupleks komunikacija trenutno nije ostvarena, ali postoji mogućnost. Potpuna dupleks komunikacija je preduvjet za kriptiranje podataka unutar pametne kartice u stvarnom vremenu.

Umetanjem kartice u čitač, obavlja se reset kartice, nakon čega kartica šalje odgovor na reset (ATR - Answer To Reset). Odgovor ATR sadrži različite podatke koji su važni za prijenosni protokol i karticu. Postoje različiti načini na koji se može uspostaviti komunikacija s pametnom karticom, što je definirano prijenosnim protokolima. Na raspolaganju je 15 prijenosnih protokola za koje su definirane osnovne funkcije. Dva protokola dominiraju u uporabi, a to su T=0 i T=1 prijenosni protokoli. Izmjena podataka između terminala i kartice obavlja se u cijelosti putem APDU naredbi (eng. Application Protocol Data Unit).

Podaci na pametnoj kartici smješteni su u datotečni podsustav koji se nalazi na stalnom spremniku, obično električki izbrisivom i programski čitljivom spremniku (EEPROM). Datotečni podsustav je definiran kao hijerarhijska struktura usmjerena ravno naprijed koja obuhvaća tri osnovna elementa: MF korijenski zapis, DF direktorij i EF krajnji element tj. datoteka. U praktičnom radu ostvaren je program kojim se čitaju dostupni podaci iz datotečnog podsustava pametne kartice.

2. Pametna Kartica

2.1 Uvod u pametne kartice

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 prihvat kartica CAD (eng. 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 grješ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.

Na slici 2.1 vidimo put razvoja kartica. Prvo su se koristile reljefne kartice, podaci na njima su čuvani u obliku "reljefa" tj. slova i brojke su otisnuti tako da ih prelaskom kroz aparat možemo preslikati na papir. Zatim slijede takozvane magnetske kartice, to su kartice na kojima je sa zadnje strane dodana magnetska traka sa podacima koji se čitaju u odgovarajućem čitaču. Nedostatak ovih kartica je mala količina spremljenih informacija, slaba zaštita podataka (lako se kopiraju) i sl. Kasnije razvojem slijede memorijske kartice, a to su kartice koje imaju čip na sebi sa spremnikom ali nemaju procesor za obradu podataka te nisu same u stanju obrađivati podatke. Slijedeća razvojna stepenica bile su tzv. pametne kartice. Pametne kartice pružaju puno veću sigurnost od prethodnih, u stanju su same izvoditi aplikacije pisane za njih, čuvaju podatke. Mada danas postoje razno razne kombinacije ovih prethodnih kartica npr. pametne i magnetska, reljefna i magnetska itd. Glavni razlog ovih kombinacija je kompatibilnost prema dolje.

Slika 2.1. Razvoj kartica i struktura pametne kartice

Pametna kartica se sastoji od ovih elemenata:

CPU - Danas uglavnom 8-bit mikroprocesori, ali kod high-end kartica možemo naći 16-bit i 32 bit procesore, neke kartice imaju ugrađen crypto-coprocesor da ubrza kriptografske operacije (Cryptoflex Schlumberger).

ROM – Informacije se u ROM spremaju kod proizvodnje i iste su kod svih čipova u seriji. Obično je to kartični operacijski sistem, neka aplikacija i sl.

EEPROM - se uzima za permanentno spremanje podataka. Podaci se čuvaju i kada je kartica isključena. Tu se spremaju naše aplikacije koje, ključevi i sl.

RAM – To je kratkotrajni spremnik u kojoj se čuvaju podaci za vrijeme dok je kartica uključena.

2.2 Standardi pametnih kartica

2.2.1 ISO/IEC

International Organization for Standardization izdala je standard ISO/IEC 7816 (Identification cards – Integrated circuit cards with contacts). Standard definira najvažnija svojstva kontaktnih čip kartica:

ISO/IEC 7816

- 1. dio – fizička svojstva

- 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

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

2.2.3 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

3. Komunikacijski mehanizmi

3.1 Osnovni princip komunikacije

Mogućnost dvosmjerne komunikacije je preduvjet za sve interakcije između pametnih kartica 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 postoji samo jedna linija, kartica i terminal se moraju izmjenjivati u slanju podataka, dok se druga strana ponaša kao primalac. Naizmjenično slanje i primanje podataka zove se poludupleks (eng. Half-Duplex) protokol.

Potpuna dupleks (eng. Full-Duplex) protokol, u kojoj obje strane mogu slati i primati simultano, trenutno nije implementirana za pametne kartice. Kako većina procesora pametnih kartica ima dva U/I porta, i dva od 8 kontaktna polja su rezervirana za buduće aplikacije (kao druga U/I linija), Potpuna dupleks operacija bi bila sigurno tehnički moguća. Prosječnim jezikom, ovo će sigurno biti implementirano u sklopovlje 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 Gospodar-Sluga (eng. Master-Slave) gdje je terminal Gospodar, a kartica Sluga.

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 - Answer To Reset) 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 3.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) (eng. 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 sloj model. Ovako se između električnih događaja na U/I 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. Te veze prikazane su na slici 3.2.

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

Navedeni 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živog spremnika.

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 kako bi kartica mogla komunicirati s što je više moguće različitih tipova terminala.

3.2 Fizički prijenosni sloj

Fizički prijenosni sloj (eng. 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.

Razmjena podataka s pametnom karticom je isključivo 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, direktna konvencija (eng. direct conversion) znači da je "1" predstavljena s +3/+5V, a inverzna konvencija (eng. inverse conversion) znači da +3/+5V predstavlja "0". U oba slučaja, nivo U/I 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 direktne konvencije prvi bit iza početka je najmanje značajan, a kod inverzne konvencije to je najznačajniji bit.

Slika 3.3 Konvencije prijenosa podataka: (a) direktna konvencija; (b) inverzna konvencija

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'' (eng. 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 3.4 Struktura prijenosnih podataka

Budući 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 (eng. elementary time unit - etu). Znači nema smisla odrediti prijenosni omjer s pametnim karticama kao fiksnu vrijednost (kao 9600 bit/s), budući je proporcionalan sa stupnjem sata. Trenutno su u uporabi 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 3.5 Primjer trostrukog uzorkovanja prijemnog bita

Vrijeme serijskog prijenosa ne mora biti strogo kontrolirano. Zbog tehničkih razloga tolerira se odstupanje. Budući 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.

3.3. Odgovor na resetiranje ATR

Kod uključivanja, sat i reset signal su izvršeni, pametna kartica šalje odgovor na resetiranje ATR (eng. Answer To Reset) putem U/I. 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 3.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 3.1 Podatkovni elementi ATR i njihovo značenje prema ISO/IEC 7816-3 standardu

Podatkovni elementi	Opis
TS	Inicijalni Znakovi
T0	Znakovi Veličine
TA1, TB1, TC1, TD1,…	Znakovi Sučelja
T1, T2, …,TK	Povijesni Znakovi
TCK	Kontrolni Znakovi

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

3.4 ATR Znakovi

3.4.1 Inicijalni znakovi

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 kako 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 3.7 Osnovne strukture i podatkovni elementi ATR-a

Slika 3.8 Vremenski dijagram inicijalnog znaka TS u direktnoj konverziji ('3B')

Slika 3.9 Vremenski dijagram inicijalnog znaka TS u inverznoj konverziji ('3F')

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.

Tablica 3.2 Inicijalni znak (TS) kod

b8 b7 b6 b5 b4 b3 b2 b1	Značenje
'3B₁₆'	direktna konverzija
'3F₁₆'	inverzna konverzija

3.4.2 Znakovi veličine

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

3.4.3 Znakovi sučelja

Znakovi sučelja (eng. 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 su definirane osnovne vrijednosti za sve parametre protokola, znakovi sučelja se obično ne traže u ATR-u za obične komunikacijske procese.

Tablica 3.3 Kodiranje u T0 formatu znakova

b8 b7 b6 b5 b4 b3 b2 b1	Značenje
… … … … X X X X	Broj povijesnih znakova (0 do 5)
… … … 1 … … … …	TA1 poslan
… … 1 … … … … …	TB1 poslan
… 1 … … … … … …	TC1 poslan
1 … … … … … … …	TD1 poslan

Znakovi sučelja mogu biti podijeljeni u opće i posebne znakove 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 znakovi 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 znakova relevantni za T=0 protokol. Pošto nisu implementirani u T=0 protokol, 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 znakova sučelja. Gornja riječ sadrži uzorak koji pokazuje prisutnost narednih znakova sučelja. Ovo je analogno kodiranju format znakova 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 znakovi 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 prikazano u tablici 3.4.

Tablica 3.4 Kodiranje TDi bajta

b8 b7 b6 b5	b4 b3 b2 b1	Značenje
… … … …	X	Prijenosni protokol broj (0 do 15)
… … … 1	…	TAi+1 poslan
… … 1 …	…	TBi+1 poslan
… 1 … …	…	TCi+1 poslan
1 … … …	…	TDi+1 poslan

Opći znakovi 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 3.5 TA1 kodiranje

b8 b7 b6 b5	b4 b3 b2 b1	IFSC
X	…	FI
…	X	DI

Tablica 3.6 FI kodiranje

internal clock 372 558 744 1116 1488 1860 RFU

0000 0001 0010 0011 0100 0101 0110 0111

RFU 512 768 1024 1536 2048 RFU RFU …

1000 1001 1010 1011 1100 1101 1110 1111 …

Tablica 3.7 DI kodiranje

RFU 1 2 4 8 16 RFU RFU

0000 0001 0010 0011 0100 0101 0110 0111

RFU 1/2 1/4 1/8 1/16 1/32 1/64 …

1001 1010 1011 1100 1101 1110 1111 …

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 izrazom 3.1.

(3.1)

- 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 izrazom 3.2.

(3.2)

Ova 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 znakovi 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 3.8 TB1 kodiranje

b8 b7 b6 b5 b4 b3 b2 b1	IFSC
0 X … … … … …	II
0 … X X X X X	PI1

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, osnovni napon Vpp je 5v s 50mA, prema standardu.

Opći znakovi sučelja TC1

On određuje posebno čuvano vrijeme (eng. extra guard time) označeno s N, ne predznačni heksadecimalni cjelobrojni broj. 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 posebno č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 3.9 TC1 kodiranje

b8 b7 b6 b5 b4 b3 b2 b1	IFSC
X = 255, T = 0	N = 12 etu
X = 255, T =1	N = 11 etu

Opći znakovi 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 3.10 TB2 kodiranje

b8 b7 b6 b5 b4 b3 b2 b1	IFSC
X	PI2

Specifični znakovi sučelja za T=0 prijenosni protokol 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, prikazano u izrazu 3.3

work waiting time=(960·D·W1) work etu (3.3)

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

Tablica 3.11 TC2 kodiranje

b8 b7 b6 b5 b4 b3 b2 b1	Značenje
X	W1

Specifični znakovi sučelja za T=1 prijenosni protokol

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

Specifični znak sučelja TAi (i>2) 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 3.12 TAi kodiranje za i>2

b8 b7 b6 b5 b4 b3 b2 b1	Značenje
X	IFSC

Specifični znak sučelja TBi (i>2), donja riječ (četiri bita od b4 do b1) sadrži kod CWI za character waiting time CWT, koje se računa prema izrazu 3.4.

work etu (3.4)

Gornja riječ sadrži BWI, s kojom se block waiting time BWT može izračunati prema izrazu 3.5.

work etu (3.5)

Tablica 3.13 TBi kodiranje za i>2

b8 b7 b6 b5	b4 b3 b2 b1	Značenje
…	X	CWI
X	…	BWI

Specifični znak 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 znakova sučelja, različite implementacije mogu koristiti dodatne znakove sučelja.

Tablica 3.14 TCi kodiranje za i>2

b8 b7 b6 b5 b4 b3 b2 b1	Značenje
… … … … … … … 0	uzet LRC
… … … … … … … 1	uzet CRC
0 0 0 0 0 0 0 …	Rezerviran za buduće aplikacije

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

Opći znakovi sučelja TA2

Ovaj bajt prikazuje dopuštene modove za PTS.

Tablica 3.15 TA2 kodiranje

b8 b7 b6 b5	b4 b3 b2 b1	Značenje
0 … … …	…	Prebacivanje između prohodnog moda i specifičnog moda je moguć
1 … … …	…	Prebacivanje između prohodnog moda i specifičnog moda nije moguć
… 0 0 …	…	Rezervirano za kasnije aplikacije
… … … 0	…	Stalni prijenos eksplicitno definiran u znakovima sučelja
… … … 1	…	Stalni prijenos implicitno definiran u znakovima sučelja
… … … …	X	Protokol T=X se koristi

3.4.4 Povijesni znakovi

Povijesni znakovi (eng. 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 kako bi se lakše tumačilo. Prisutnost povijesnih znakova 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 znaku. Ova datoteka s rezerviranim FID '2F01' sadrži dodatne podatke o ATR-u. Namjera je da to bude proširenje povijesnog znaka 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 znakovi, 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.

3.4.5 Kontrolni znak

Posljednji bajt u ATR-u je XOR kontrolna suma od bajta T0 do zadnjeg bajta prije kontrolnog znaka (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 znakom sučelja, ili posljednjim povijesnim znakom ako je prisutan.

3.5 Protokol za selekciju tipova (PTS)

Pametna kartica prikazuje mnoge parametre prijenosa podataka u znakovima sučelja ATR-a kao što je protokol prijenosa i znak čekanog vremena. Ako terminal želi modificirati jedan ili više ovih parametara, protokol za selekciju tipova (eng. 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 (eng. 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 3.10 Dijagram stanja dva PTS moda

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

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

Data element	Značenje
PTSS	Initial Character
PTS0	Format Character
PTS1, PTS2, PTS3	Parameter Character
PCK	Check Character

Slika 3.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 znak (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 znak (PTS0). To je također obavezni dio svakog PTS-a. Opcionalno ga mogu slijediti do tri bajta, koji se zovu parametar znakovi 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 znak PCK (eng. 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.

b8 b7 b6 b5	b4 b3 b2 b1	Značenje
… … … …	X	Prijenosni protokol uzet
… … … 1	…	PTS1 moguć
… … 1 …	…	PTS2 moguć
… 1 … …	…	PTS3 moguć
0 … … …	…	Rezervirano za buduću upotrebu

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 3.18 PTS1 kodiranje

b8	b7 b6 b5 b4 b3 b2 b1	Značenje
X	…	FI
…	X	DI

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 3.19 PTS2 kodiranje

b8	b7	b6	b5	b4	b3	b2	b1	Značenje
…	…	…	…	…	…	0	0	Nije potrebno dodatno čuvanje vremena
…	…	…	…	…	…	0	1	N=255
…	…	…	…	…	…	1	0	Potrebno dodatno vrijeme za 12 etu
X	X	X	X	X	X	…	…	Rezervirano za buduću uporabu

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 3.12 Tipična PTS procedura kod GSM

Moguće je umanjiti ovaj nedostatak tako da pametna kartica uvijek odgovara istim ATR-om nakon hladnog reseta (eng. power-on 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 3.13 Tipična PTS reset procedura

4. Protokol za prijenos podataka

4.1 Uvod u podatkovni prijenos

Nakon što je pametna kartica poslala ATR i izvršen je PTS, čeka prvu naredbu od terminala. Sljedeći procesi uvijek odgovaraju principu gospodar/sluga, pri čemu je terminal gospodar, a kartica je sluga. Jednostavnije, terminal šalje naredbu kartici a ona je izvršava i šalje odgovor. Među izmjena naredbi i odgovora nikad se ne mijenjaju.

Slika 4.1 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. Protokoli, koji su označeni kao T=(za 'prijenosni protokol') plus sekvencijalni broj, navedeni su u tablici 4.1.

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

Prijenosni protokol	Značenje
T=0	Asinkrono, half duplex, bajt orijentirano, podržano od ISO/IEC 7816-3
T=1	Asinkrono, half duplex, blok orijentirano, podržano od ISO/IEC 7816-3 Amd 1
T=2	Asinkrono, full duplex, blok orijentirano, podržano od ISO/IEC 10536-4
T=3	Full duplex, nije još podržano
T=4	Asinkrono, half duplex, bajt orijentirano, proširenje T=0, nije još podržano
T=5 do T=13	Rezervirano za buduće funkcije, nije još podržano
T=14	Za nacionalne funkcije, nije ISO standard
T=15	Rezervirano za buduće funkcije, nije još podržano

Dva od ovih protokola dominiraju u internoj uporabi. Prvi je T=0 protokol, koji je standardiziran 1989. (ISO/IEC 7816-3). Drugi T=1 uveden je 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 TPDU (eng. Transmision Protocol Data Units). Jedinice podataka su spremnici koji ovise o protokolu i prenose podatke od i prema kartici. Stvarna primjena podataka je ugrađena u tim spremnicima.

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

4.2 Sinkroni podatkovni prijenos

Sinkronizirani prijenos podataka ne koristi se kod mikrokontrolerskih kartica, budući kartice 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čnom spremniku 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 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 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 prijenos 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 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 kartice imaju spremnik koji je podijeljen na dva djela u ROM i EEPROM. Oba spremnika mogu se bit adresirati i slobodno čitati, a u slučaju EEPROM pisati i čitati.

Gospodar/sluga 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, što kontrolira visoka logika. Ta logika isto upravlja vrlo jednostavnim prijenosima podataka.

4.3 T=0 prijenosni protokol

T=0 prijenosni 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 minimalnog spremnika, a pritom je maksimalno jednostavan. T=0 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 koje može slijediti opcionalni dio podataka. Suprotno APDU 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 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 4.2 Struktura T=0 komande

Ako primalac detektira grješku u prijenosu, mora staviti U/I liniju na nisku razinu u trajanju od jednog etu-a, s početkom na polovici prvog bit intervala čuvanog vremena krivog bajta, što indicira drugoj strani da se posljednji bajt mora ponovno prenijeti. Mehanizam je veoma jednostavan i ima prednost da je selektivan budući 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 U/I 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 4.3 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 4.4 Grješka kod prijenosa je indicirana kod T=0 protokola s niskom razinom na U/I sučelju kroz čuvano vrijeme

Glavna funkcija čuvanog vremena (eng. 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 kôdom. Terminal prvo šalje kartici zaglavlje veličine 5 bajtova, koje se sastoji od class bajta, naredbenog bajta, P1, P2 i P3 bajta. Ako je to ispravno primljeno, kartica šalje potvrdu primitka (ACK) u obliku Procedure bajt (PB). 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 kôda, 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 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.

Pametna kartica		Terminal
	←	5-baytno naredbeno zaglavlje [CLA, INS, P1, P2, P3]
zaglavlje primljeno bez grješke, zahtijeva prijenos podatkovnog dijela [ACK]	→
	←	[podatkovni dio] s brojem podatkovnih bajtova=P3
obrada naredbe naredba izvršena i podaci dostupni; podatkovna veličina je SW2 [SW1][SW2]	→
	←	GET RESPONSE P3 = količina podataka koja se šalje [CLA, INS, P1, P2, P3]
[padci][SW1][SW2]	→	naredba – odgovor slijed kompletno gotov

Slika 4.5 Tipična T=0 komunikacijska procedura s podacima u naredbi i odgovoru

T=0 protokol omogućuje kartici da pojedinačno prima bajtove u skup podataka nakon što je primljeno zaglavlje. Kako bi to funkcioniralo, 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. 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. Š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 samo neispravno primljeni bajtovi moraju biti ponovo preneseni.

Tablica 4.2 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

Naredba	Koristan podatak	Protokol podatak	Vrijeme prijenosa podatka
READ BINARY	C: 5 bajta R: 2+8 bajta	-	18.75 ms
UPDATE BINARY	C: 5+8 bajta R: 2 bajta	-	18.75 ms
ENCRYPT	C: 5+8 bajta R: 2+8 bajta	C: 5 bajta R: 2 bajta	37.50 ms

Mehanizam za detekciju grješaka T=0 protokola sastoji se samo od provjere pariteta na kraju svakog bajta. Provjera pariteta omogućuje pouzdano prepoznavanje grješaka pojedinačnih bitova, ali grješke dva bita se ne mogu detektirati. Ako se bajt izgubi tijekom prijenosa između terminala i kartice to će rezultirati beskonačnim petljom (dead lock) na kartici, budući se čeka na određeni broj bajtova te 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.

Pametna kartica		Terminal
	←	5-baytno naredbeno zaglavlje [CLA, INS, P1, P2, P3]
"pošalji jedan podatkovni bajt"	→
	←	[podatkovni bajt 1]
"pošalji jedan podatkovni bajt"	→
	←	[podatkovni bajt 2]
prihvati buduće jednostruke bajtove		prihvati buduće jednostruke bajtove
"Pošalji sve ostale podatkovne bajtove"	→
	←	[Podatkovni bajtovi n-P3] P3 = količina podataka koja se šalje
obrada naredbe
[SW1][SW2]	→	naredba – odgovor slijed kompletno gotov

Slika 4.6 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 4.7 Stanje komunikacijskog procesa pametne kartice za T=0 komunikacijski protokol, bez ispravljanja pogrješke

4.4 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 T=1 protokol važna je specifikacija EMV. T=1 protokol je blok orijentiran. To znači da je najmanja podatkovna jedinica blok.

T=1 protokol ima strogo odijeljene slojeve i može biti klasificiran u OSI reference model kao podatkovni link sloj. U 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 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.

Tablica 4.3 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

Naredba	Koristan podatak	Protokol podatak	Vrijeme prijenosa podatka
READ BINARY	C: 5 bajta R: 2+8 bajta	-	28.75 ms
UPDATE BINARY	C: 5+8 bajta R: 2 bajta	-	23.00 ms
ENCRYPT	C: 5+8 bajta R: 2+8 bajta	C: 5 bajta R: 2 bajta	38.75 ms

4.4.1 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 4.8 Struktura T=1 prijenosnog bloka

4.4.2 Početno polje

Početno polje (eng. 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.

Adresa čvora (NAD)

Adresa čvora 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. Zbog kompatibilnosti sa starim mikrokontrolerima osigurana je kontrola napajanja za EEPROM ili EPROM programiranje. Ne postoji praktična primjena, budući svi mikrokontroleri pametnih kartica sada imaju strujnu pumpu u čipu.

Tablica 4.4 Node address (NAD polje)

b8	b7	b6	b5	b4	b3	b2	b1	Značenje
X	…	…	…	X	…	…	…	Vpp kontrola
…	X	X	X	…	…	…	…	DAD (adresa odredišta)
…	…	…	…	…	X	X	X	SAD (adresa izvorišta)

Protocol contol byte (PCB)

PCB je pod polje koje slijedi adresu čvora (eng. 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 4.5 PCB polje za I blok

b8	b7	b6	b5	b4	b3	b2	b1	Značenje
0	…	…	…	…	…	…	…	I blok identifikator
…	N(S)	…	…	…	…	…	…	Poslan slijed brojeva
…	…	X	…	…	…	…	…	Slijed podataka bit M
…	…	…	X	X	X	X	X	Rezervirano

Length (LEN)

LEN je kao polje dužine jednog bajta. LEN pokazuje duljinu informacijskog polja u heksadecimalnom obliku. LEN vrijednost može biti od '00₁₆' do 'fe₁₆'. Kôd 'ff₁₆' je rezerviran za buduća proširenja i trenutno se ne bi trebao koristiti.

Tablica 4.6 PCB polje za R blok

b8	b7	b6	b5	b4	b3	b2	b1	Značenje
1	0	…	…	…	…	…	…	R blok identifikator
…	…	0	N(R)	0	0	0	0	Bez grješke
…	…	0	N(R)	0	0	0	1	EDC ili paritetna grješka
…	…	0	N(R)	0	0	1	0	Druga grješka

Tablica 4.7 PCB polje za S blok

b8	b7	b6	b5	b4	b3	b2	b1	Značenje
1	1	…	…	…	…	…	…	S blok identifikator
…	…	0	0	0	0	0	0	Zahtjev za re-sinkronizacijom (samo od terminala)
…	…	1	0	0	0	0	0	Zahtjev za re-sinkronizacijom (samo od pametne kartice)
…	…	0	0	0	0	0	1	Zahtjev za promjenu veličine informacijskog polja
…	…	1	0	0	0	0	1	Odgovor na zahtjev za promjenu veličine informacijskog polja
…	…	0	0	0	0	1	0	Zahtjev za prekid
…	…	1	0	0	0	1	0	Odgovor na zahtjev za prekid
…	…	0	0	0	0	1	1	Zahtjev za promjenu vremena čekanja (samo od pametne kartice)
…	…	1	0	0	0	1	1	Odgovor na zahtjev za promjenu vremena čekanja (samo od terminala)
…	…	1	0	0	1	0	0	Vpp eror odgovor (samo od pametne kartice)

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

4.4.4 Završno polje

Ovo polje, koje je preneseno na kraj bloka, sadrži kôd za detekciju grješaka koji je izračunan iz svih prijašnjih bajtova u bloku. Izračunavanje obavlja ili LRC longitudinalna kontrola redundancije (eng. Longitudinal Redundancy Check) ili CRC ciklička kontrola redundancije (eng. Cyclic Redundancy Check). Metoda koja se koristi mora biti specificirana u sučeljima znakova 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 vidi izraz 4.1. Oba koda za detekciju grješaka mogu se koristiti samo u tu svrhu, ne mogu ispravljati grješke u bloku.

g(x)=x¹⁶+x¹²+x⁵+1 (4.1)

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. Završno polje mora biti prošireno do dva bajta, što dodatno smanjuje stupanj prijenosa.

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

4.4.6 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 vremena u standardu, ali to se može modificirati kako bi se povećao stupanj prijenosa. Modificirane vrijednosti su prikazane u posebnim sučeljima znakova ATR-a.

4.4.7 Vrijeme čekanja znaka (CWT)

Vrijeme čekanja znaka je maksimalni interval između uzlaznih bridova dvaju uzastopnih znakova u bloku. Primatelj aktivira odbrojavajući sat na svakom uzlaznom bridu s vremenom čekanja znaka (eng. 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 se može koristiti 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 4.9 Definicija vremena čekanja znakova (CWT)

CWT se izračunava korištenjem podatkovnog elementa CWI koji je sadržan u ATR-u prema izrazu 4.2.

(4.2)

Osnovna vrijednost za CWI je 13, iz čeka po izrazu 4.3 proizlazi vrijednost za CWT.

(4.3)

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

CWI 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 znakovi 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 tom slučaju bi primalac čekao na dodatne znakove koji nikada ne bi stigli, to bi blokiralo protokol prijenosa i takvo stanje može se ispraviti jedino 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. Vrijeme čekanja bloka je najveći dozvoljeni interval između uzlaznog brida posljednjeg bajta u bloku poslanog kartici i uzlaznog brida poslanog natrag od kartice.

Slika 4.10 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 znakova u ATR-u određuju BWT koji je kodiran u skraćenom obliku BWI.

(4.4)

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, prema izrazu 4.5.

(4.5)

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)

Čuvano vrijeme bloka je najmanji interval između vodećeg brida posljednjeg bajta i vodećeg brida prvog bajta u suprotnom smjeru. Ovo 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 4.11 Definicija čuvanog vremena bloka (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.

4.4.8 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. Ovo vrijedi samo za posljednji poslani I blok.

Pametna kartica		Terminal
	←	I blok
S blok (zahtijevanje proširenja vremena čekanja)	→
	←	S blok (potvrđeno proširenje vremena čekanja)
I blok	→

Slika 4.12 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čenog kapaciteta spremnika 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čen spremnik 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 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 4.13 Primjer ulančavanja bloka za prijenos podataka od terminala ka pametnoj kartici

4.4.9 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 4.8 Stanja kod T=1 rukovanja grješkama

Koraci sinkroniziranja	Mehanizam
Korak 1	Ponovi pogrešan blok
Korak 2	Ponovno se sinkroniziraj i ponovi pogrešan blok
Korak 3	Resetiraj pametnu karticu i ponovno uspostavi vezu

5. Struktura poruka: APDU

5.1 Uvod u strukturu podataka APDU

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

APDU 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 odnosi na dva standardizirana protokola T=0 i T=1. Zahtjev za neovisnošću protokola utjecao je i na dizajn APDU, budući treba biti moguće transparentno ih prenositi korištenjem oba protokola, bajt orijentiranog T=0 i blok orijentiranog T=1.

5.2 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, što 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 5.1 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 5.1 Najznačajniji class bajt (CLA) kodovi određeni u ISO/IEC 7816-4

b8 do b5	b4	b3	b2	b1	Značenje
…	…	…	X	X	logički broj kanala
…	0	0	…	…	nije sigurna poruka
…	0	1	…	…	sigurna poruka nije kompatibilna s ISO, uzeta vlastita procedura
…	1	0	…	…	sigurna poruka je kompatibilna s ISO, zaglavlje nije autentično
…	1	1	…	…	sigurna poruka je kompatibilna s ISO, zaglavlje je autentično
'0'	…	…	…	…	strukture i kodiranje kompatibilno s ISO/IEC 7816-4
'8','9'	…	…	…	…	strukture kompatibilne s ISO/IEC 7816-4, korisnik određuje kodove i značenje komandi i odgovora
'A'	…	…	…	…	strukture i kodovi kompatibilni s ISO/IEC 7816-4, specificirano u drugom dokumentu (GSM 11.11)
'F'	1	1	1	1	rezervirano za PTS

Tablica 5.2 Kratak pregled prijenosa class bajta u aplikaciju

Class	Aplikacija
'0X'	standardne komande kompatibilne s ISO/IEC 7816-4
'80'	elektronički valjan kompatibilan s EN 1546-3
'8X'	aplikacijski određene i određene od strane tvrtki komande
'8X'	kreditne kartice sa čipovima, kompatibilne s EMV-2
'A0'	GSM kartica kompatibilna s prETS 300 608 / GSM 11.11 i standardizirane komade kompatibilne s EN 726-3

Slika 5.2 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. 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 još ne može biti implementirano zbog ograničenja trenutno dostupnog spremnika. Prethodno opisani dijelovi komande APDU mogu se kombinirati tako da rezultiraju s četiri opća slučaja koja su opisana na slici 5.3.

slučaj 1	zaglavlje

slučaj 2	zaglavlje	Le polje

slučaj 3	zaglavlje	Lc polje	podatkovno polje

slučaj 4	zaglavlje	Lc polje	podatkovno polje	Le polje

Slika 5.3 Četiri moguće komande APDU

5.3 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 5.4. 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.

tip 1	SW1 SW2

tip 2	podatkovno polje	SW1 SW2

Slika 5.4 Dva tipa odgovora APDU, SW1 i SW2 predstavljaju obavezno polje, a podatkovno polje 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 32.

Slika 5.5 Shema klasifikacije povratnih kodova definirana s ISO/IEC 7816-4 standardom.

Povratni kodovi '63XX₁₆' i '65XX₁₆' indiciraju da su podaci u neizbrisivom spremniku (EEPROM) promijenjeni, kod preostali '6X₁₆' kod indicira da je spremnik nepromijenjen.

Ako se nakon izvršene komande natrag šalje povratni kod '63xx₁₆' ili '65xx₁₆' to znači da je stalni spremnik kartice (obično EEPROM) modificiran. Ako je vraćen neki drugi kod koji počinje s ''6x₁₆'' naredba je izvršena bez modificiranja stalnog spremnika.

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 specifikaciju da budemo sigurni u njihovo pravo značenje.

6. Sigurni prijenos podataka

6.1 Sigurnosni mehanizmi

Izmjena podataka između terminala i pametne kartice bazira se na digitalnim električnim impulsima na U/I liniji pametne kartice. Shvatljivo je i tehnički izvedivo povezati žicu na U/I 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 U/I 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 U/I 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. To su sve jednim zajedničkim imenom sigurne poruke. Ovi mehanizmi nisu određeni na pametnoj kartici, budući 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 kako bi se slagale s mogućnostima pametne kartice bez ugrožavanja njene sigurnosti.

Sigurnosni mehanizmi

		kriptografski algoritam


		ključ


		argument


		početni podaci (opcionalno)

Slika 6.1 Sigurnosni mehanizmi definirani kao funkcija elemenata

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. Sigurne poruke 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 kako 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 do standardizacije fleksibilnih (ali i skupih i složenih) 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.

6.1.1 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 6.1. Bit 1 svakog kôda 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 6.1 Kodovi za podatkovne objekte običnog teksta

Kodovi	Značenje
'B0','B1'	BER-TLV kodirano; sadržava podatkovni element srodan sigurnoj poruci
'B2','B3'	BER-TLV kodirano; sadržava podatkovni element koji nije srodan sigurnoj poruci
'80','81'	nije BER-TLV kodiran podatak
'99'	informacija stanja za sigurnu poruku

6.1.2 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 6.2 i 6.3 navedeni su identifikacijski kôdovi koji se koriste u ovu svrhu.

Tablica 6.2 Kodovi za autentičnost podatkovnih objekata

Kodovi	Značenje
'8E'	kriptografska kontrolna suma
'9A','BA'	inicijalna vrijednost digitalnog potpisa
'9E'	digitalni potpis

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 6.3 Kodovi za povjerljive podatkovne elemente

Kodovi	Značenje
'82,'83'	kriptogram, obični tekst je BER-TLV kodiran i uključuje podatkovne objekte za sigurne poruke
'84','85'	kriptogram, obični tekst je BER-TLV kodiran i ne uključuje podatkovne objekte za sigurne poruke
'86','87'	inducira da je uzeta metoda za punjenje '01' – punjeno s '80 00 …' '02' – nema punjenja

6.1.3 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 (eng. authentic mode) je procedura koja koristi kriptografsku kontrolnu sumu (CCS ili MAC) radi zaštite aplikacijskih podataka (APDU) od manipulacije tijekom prijenosa. Kombinirani mod (eng. 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 APDU da izgledaju različiti. Ovo je tzv. razlika (eng. diversity).

6.2 Procedura autentični mod

Procedura autentični mod garantira autentični prijenos APDU, što znači da APDU ne mogu biti izmijenjene tijekom prijenosa. Primalac APDU koji može značiti naredbu ili odgovor, može odrediti dali 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. APDU 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. To nije nužno nedostatak, jer i onako nije preporučeno slati povjerljive podatke preko javnog kanala. Korisnik kartice bar teoretski može vidjeti podatke koji se izmjenjuju između pametne kartice i terminala.

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 cjelobrojnog tipa pomnoženog s 8 bajta, što se zove punjenje (eng padding). U ovom procesu, podatkovni objekti koji su već cjelobrojni 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 suma je 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. 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 metoda punjenja koristi. Pretpostavit ćemo, 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 cjelobrojnog tipa 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.

Kako 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 (eng. 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 procjena bi bila pretpostaviti da će stupanj biti za pola manji nego kod nezaštićenog običnog teksta.

Slika 6.2 Generiranje komande APDU s procedurom autentični mod.

Slučaj 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 cjelobrojnim tipom pomnoženim s 8 bajtova

Korak 3 Izračunat je CCS

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

6.3 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, podatkovni objekti koji trebaju biti zaštićeni s kriptografskom kontrolnom sumom, prvo se pune do cjelobrojnog tipa pomnoženog s 8 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 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 6.3 Kreiranje komande APDU s procedurom kombinirani mod.

Slučaj 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 U/I, 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 APDU. No veći stupanj sigurnosti popraćen je sa smanjenjem stupnja prijenosa.

Dobra procjena razlike u stupnju prijenosa između nezaštićenih APDU i zaštićenih kombiniranom 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.

6.4 Brojač poslanih nizova

Korištenje ovog mehanizma za sigurne poruke nije samo po sebi sigurna procedura. Brojač poslanih nizova ima smisla smo kad se brojač poslanih nizova (eng. 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.

Brojač radi na principu da svaki APDU ima svoj redni broj koji ovisi o vremenu kad je poslan. Što 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).

Funkcija je bazira na brojaču sa slučajnim brojem. Broj se š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. Na slici 6.4 uzeta je duljina od dva bajta mada se koriste i dulji brojači.

Slika 6.4 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 APDU. 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 6.5 Prenošenje APDU s brojačem poslanih nizova(SSC)

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 dali 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 APDU koji su prethodno poslani, i brisanja APDU.

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.

6.5 Sigurnosne naredbe

Povezano sa svakom komponentom datotečnog sustava je lista pristupnih svojstava. Kroz ta pristupna svojstva, pristupa se sustavu pametne kartice prije nego što se može pristupiti samoj komponenti datotečnog podsustava. Na najnižoj razini operacije koje treba izvršiti na datotečnom podsustavu je odabir određene datoteke i zatim pisanje informacije toj datoteci ili čitanje informacije iz te datoteke. Pristupna svojstva mogu biti: vrlo jednostavna kao što je zahtjev čitaču da omogući predefinirani pin ili vrlo kompleksna kao što čitač dokazuje da dijeli neki tajni ključ sa karticom.

6.5.1 Verify naredba

Verifiy je naredba poslana od strane čitača prema sigurnosnom sistemu na kartici da se provjeri sa ključem pohranjenim na kartici. Ova naredba se koristi da aplikacija od strane čitača uvjeri karticu da ona (aplikacija čitača) zna ključ zadržan na kartici te da ograniči pristup informacijama na kartici.

Tablica 6.4 Struktura Verify naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	20₁₆	00₁₆	00₁₆	03₁₆	53₁₆61₁₆53₁₆

Informacije u obliku ključa mogu biti dodane u specifičnu datoteku na kartici ili cijeloj datotečnoj hijerarhiji na kartici. Uspješno izvršenje ove komande pokazuje da je aplikacija čitača znala točan ključ i stavlja karticu u stanje da čitač može doći do informacije na kartici.

6.5.2 Internal Authenticate naredba

Internal Authenticate je naredba koju šalje aplikacija čitača sigurnosnom sistemu na kartici da dopusti kartici da dokaže kako posjeduje tajni ključ koji dijeli s aplikacijom čitača. Da pripremi ovu naredbu, aplikacija čitača kreira niz podataka (prije svega aplikacija čitača odabire slučajni broj). Ovaj broj se tada kodira pomoću dogovorenog algoritma (s karticom), te ovo stvara kodirani upit kartici.

Tablica 6.5 Struktura Internal Authenticate naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	88₁₆	00₁₆	00₁₆	03₁₆	02₁₆01₁₆03₁₆

Nakon što dobije naredbu, kartica tada otključa kodirane podatke pomoću tajnog ključa pohranjenog u datoteci na kartici. Informacija koja se dobije pomoću dekodiranja se tada šalje natrag aplikaciji čitača kao odgovor na naredbu. Ukoliko kartica stvarno ima ispravni tajni ključ, tada će uzvraćena informacija biti slučajan broj generiran od strane aplikacije čitača prije korištenja te naredbe (eng. internal authenticate).

Naredba se koristi od strane aplikacije čitača za utvrđivanje identiteta kartice. Tj. kad se uspješno izvrši aplikacija čitača zna identitet kartice i može dati kartici pristup informacijama ili usluge unutar aplikacije čitača.

6.5.3 External Authenticate naredba

External Authenticate je naredba uzeta od strane čitača povezana sa Get Challenge naredbom da se dopusti aplikaciji čitača da potvrdi svoj identitet kartici.

Tablica 6.6 Struktura External Authenticate naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	82₁₆	00₁₆	00₁₆	03₁₆	03₁₆02₁₆01₁₆03₁₆

Putem Get Challenge naredbe aplikacija čitača prima niz kodiranih podataka s kartice (slučajni broj koji generira kartica). Aplikacija čitača tada kodira ovu informaciju s tajnim ključem. Tada su to kodirani podaci koji se šalju kartici putem External Authenticate naredbe. Ako aplikacija čitača zna isti tajni ključ koji je pohranjen na kartici, tada će kad kartica dekodira kodirane podatke, pronaći isti slučajni broj generiran posljednjom Get Challenge naredbom. Kartica sada zna identitet aplikacije čitača i može joj dati pristup podacima na kartici.

Sa sigurnosnog stajališta dobra je strana ovog načina to što tajni ključ korišten za utvrđivanje identiteta između aplikacije i kartice nije nikad prenesen iz kartice.

6.5.4 Get Challenge naredba

Get Challenge naredbu koristi aplikacija čitača da dobije informaciju koja se koristi za formuliranje kodiranih podataka za karticu i koji se provjeravaju putem External Autehenticate naredbe. Rezultat ove naredbe je generiranje slučajnog broja od strane aplikacije, koji se tada prenosi natrag do aplikacije čitača.

Tablica 6.7 Struktura Get Challenge naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	84₁₆	00₁₆	00₁₆	06₁₆	ništa

7. Datotečni podsustav

7.1 Svojstva datotečnog podsustava

Središnja aplikacija za pametne kartice definirana ISO/IEC 7816-4 standardom je datotečni podsustav. Datotečni podsustav se zapravo primjenjuje na stalni (nepromjenjiv) spremnik na pametnoj kartici, obično električki izbrisiv i programski čitljiv spremnik (EEPROM). Datotečni podsustav je definiram kao hijerarhijska struktura usmjerena ravno naprijed koja obuhvaća tri osnovna elementa:

- master file (MF) komponentu

- directory file (DF) komponentu

- elementary file (EF) komponentu

MF komponenta je osnova datotečne hijerarhije; postoji samo jedan MF na pametnoj kartici. Jedan MF može sadržavati elemente kao što je DF, ili čak više DF, te može sadržavati nijedan EF do više EF. DF komponenta je osnovna mapa (direktorij) za EF komponente, jedan DF može sadržavati nijedan do više EFs. Jedna EF komponenta može sadržavati samo podatke. Ova jednostavna hijerarhijska struktura prikazana je slikom 7.1.

Slika 7.1 Arhitektura datotečnog podsustava pametne kartice

Nekoliko svojstava datotečnog podsustava pametne kartice se značajno razlikuju od tipičnih datotečnih sustava (npr. koji se baziraju na disku). Ove razlike gotovo isključivo postoje zbog fizičkih svojstava EEPROM spremnika, činjenice da EEPROM spremnik može biti izložen samo skromnom broju ciklusa brisanja i pisanja, te da je značajno brže pisati EEPROM memoriji na kumulitativan način nego na način samo brisati a zatim pisati. Ovo prvo svojstvo rezultira definiranjem jedne prilično jedinstvene strukture koju zovemo cyclic file. Drugo svojstvo rezultira u prilično jedinstvenim definicijama različitih datotečnih naredbi pisanja.

Cyclic datoteka je zapravo ring buffer fizičkih datoteka koje se adresiraju i kojima se pristupa kao jednoj samoj datoteci. Po sukcesivnim pisanim operacijama, pristupa se sljedećoj fizičkoj datoteci (u krugu fizičkih datoteka). Sljedeći je rezultat da se operacije brisanja i pisanja mogu proširiti kroz širi izbor lokacija EEPROM spremnika. Ovo ublažava ograničenje (općenito niz od 100,000 ciklusa) koliko puta specifična lokacija EEPROM spremnika može biti izbrisana i ponovno upisana.

EEPROM spremnik ima dodatno zanimljivo svojstvo da je značajno brže smjestiti dodatne bitove na lokaciju spremnika nego izbrisati sve trenutno smještene bitove i zatim ih ponovo prepisati. Ova činjenica postaje korisna u nekim operacijama (npr. manipuliranje novčanim vrijednostima na pametnoj kartici) gdje se zahtijeva da operacije na datoteci budu izvedene na takav način da se vrijednosti pohranjene u datoteci mogu dobro razumjeti u svako vrijeme, čak i kada pametna kartica bude isključena usred operacije. Da se iskoristi prednost ovih svojstava pisane operacije za datoteku pametne kartice su tipične bit-set operacije, dok su update operacije zapravo izbriši i piši operacije, što obično povezujemo s operacijama za pisanje datoteke.

7.2 Svojstva korijenskog zapisa MF

Svaki datotečni podsustav pametne kartice ima točno jedan MF. Taj MF služi kao osnova hijerarhijske strukture datoteka. Govoreći općenito o datotečnom sustavu, MF je mapa ili direktorij, može sadržavati druge podređene mape DF ili može sadržavati EF.

Svaku datoteku prepoznaje datotečni identifikator od 2 bajta. Datotečni identifikator 3F00₁₆ je rezerviran za MF, to jest, postoji samo jedna datoteka s datotečnim identifikatorom 3F00₁₆, a to je MF.

7.3 Svojstva zapisa direktorija DF

DF je također mapa ili direktorij kao i MF. DF čini poddirektorij u hijerarhiji datoteka čija je osnova MF. DF se isto može prepoznati putem datotečnog identifikatora. DF mora imati jedinstveni datotečni identifikator unutar DF (ili MF) koji ga sadrži. To dozvoljava kreiranje jedinstvene staze za datoteku (staza je jednostavno zbir datotečnih identifikatora određenih datoteka, te svih DF između određenih datoteka i DF ili MF koje sadrži).

DF se također može odrediti imenom koje može biti dugačko od 1 do 16 bajtova. Konvencije koje se trebaju poštivati prilikom imenovanja su određene u ISO/IEC 7816-5 specifikaciji.

7.4 Svojstva datoteka EF

EF je krajnji element u datotečnoj hijerarhiji. To je datoteka koja zapravo sadrži podatke. Postoje dvije varijante EF; interni EF, koji je predviđen za korištenje putem aplikacija na kartici, te radni EF koji se koristi kao mehanizam pohrane za informacije koje se koriste za izvankartične aplikacije.

Unutar određenog DF, EF se prepoznaje pomoću kratkog (5-bit) identifikatora. Postoje četiri varijante EF kao što je prikazano na slici 7.2:

- transparentna datoteka

- linearni, s fiksnom duljinom datoteka

- linearni, s promjenjivom duljinom datoteka

- ciklični, s fiksnom duljinom datoteka

Transparentna datoteka može se promatrati kao niz bajtova. Kada se naredba koristi za čitanje ili pisanje informacije s transparentne datoteke, potrebno je omogućiti pomak bajtova (od početka datoteke) prema određenom bajtu (unutar transparentne datoteke) gdje bi čitanje ili pisanje trebalo početi. Naredba za čitanje ili pisanje informacije od/prema transparentnoj datoteci će također sadržavati brojač ili duljinu bajt znakovnog niza kojeg treba čitati ili pisati u datoteku.

Slika 7.2 Tipovi datoteka pametne kartice

Datoteke fiksne ili promjenjive duljine podataka su kao što samo ime kaže datoteke koje sadrže podjele zvane podaci. Podaci (unutar datoteke) se prepoznaju pomoću slijednog broja. Kod datoteke s fiksnom duljinom podataka, svi podaci sadrže isti broj bajtova. Kod datoteka s promjenjivom duljinom podataka, svaki podatak u datoteci može sadržati različit broj bajtova. Kao što se može pretpostaviti, datoteka s promjenjivom duljinom podataka općenito ima značajno veće vrijeme pristupa čitanja/pisanja i veća je količina administrativnih podataka o pohrani koji su potrebni za datotečni podsustav.

Ciklička datoteka je prilično jedinstvena struktura (u datotečnom podsustavu pametnih kartica). Omogućuje da aplikacije pristupaju datoteci na dosljedan, transparentan način, te da istovremeno datotečni sustav bilježi ovaj pristup u različite fizičke datoteke. To omogućuje da se ublaže ograničenja ciklusa brisanja i pisanja u EEPROM spremnik.

Ciklička datoteka se može najbolje zamisliti kao prsten podataka. Svako sljedeće pisanje u datoteku izvodi operaciju na slijedećem fizičkom podatku u prstenu. Operacije čitanja se izvode na posljednjem fizičkom podatku na kojem se pisalo.

7.5 Naredbe pristupa datotekama

Kako bi se moglo upravljati datotečnim sustavom na pametnoj kartici, određen je protokol na razini aplikacija u obliku niza funkcija za odabir, čitanje i pisanje datoteka.

7.5.1 Select File naredba

Select file naredba se koristi za uspostavljanje logičkog pokazivača prema određenoj datoteci u datotečnom sustavu na pametnoj kartici. Nakon što je odabrana datoteka pomoću ove naredbe, bilo koje sljedeće naredbe, kao što su one za čitanje ili pisanje, će raditi na datoteci koja je označena ovim logičkim pokazivačem. Pristup datotečnom sustavu na pametnoj kartici nije višenitni (sa stajališta kartice), ali je moguće umnožiti takve logičke pokazivače u bilo koje vrijeme. To se postiže korištenjem Manage Channel naredbe, kako bi ustanovili višestruke logičke kanale između aplikacija na strani čitača i kartice. Naredbe za pristupanje različitim datotekama tada mogu biti uvećane (pomoću aplikacije na strani čitača) dopuštajući različitim datotekama na kartici da budu u različitom stanju pristupanja pomoću aplikacija na strani čitaća u isto vrijeme.

Tablica 7.1 Struktura Select File naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	A4₁₆	00₁₆	00₁₆	02₁₆	3F₁₆00₁₆

Primarni dio informacije koji naredba mora promijeniti (od aplikacije na strani čitača prema APDU procesoru pametne kartice) je prepoznavanje datoteke koji ovaj logički pokazivač mora pokazati. Ovo prepoznavanje je moguće na tri načina (pomoću specifičnog mehanizma adresiranja koji je označen u podatkovnom polju Select File naredbe APDU):

- datotečni identifikator (2-bajtna vrijednost)

- pomoću DF imena (znakovnog bajta koji označava DF)

- pomoću staze (niz identifikatora podataka)

7.5.2 Read Binary naredba

Read Binary naredbu koristi aplikacija od strane čitača kako bi učitala neke segmente EF na kartici. EF kojem se pristupa mora biti transparentna datoteka, tj. ne može biti datoteka usmjerena zapisima. Ako se Read Binary naredba uputi na EF koji je usmjeren zapisima, naredba će se prekinuti sa pokazivačem grješke vraćenim od kartice do aplikacije čitača.

Tablica 7.2 Struktura Read Binary naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	B0₁₆	00₁₆	00₁₆	10₁₆	prazno

Dva parametra se prenose od strane čitača prema kartici za ovu komandu: jedan pomaknuti pokazivač s početka datoteke do inicijalnog bajta za čitanje, te broj bajtova koje treba pročitati i vratiti do aplikacije čitača.

7.5.3 Write Binary naredba

Write Binary naredbu koristi aplikacija čitača kako bi smjestila informaciju u segment EF na kartici. Datoteka kojoj se pristupa mora biti transparentna, tj. to ne može biti datoteka usmjerena na zapise. Ako se Write Binary naredba uputi prema EF usmjerenom na zapise, naredba neće raditi i kartica će vratiti grješku aplikaciji čitača.

Tablica 7.3 Struktura Write Binary naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	D0₁₆	01₁₆	01₁₆	01₁₆	FF₁₆

Ovisno o atributima koji su poslani od aplikacije čitača kartici putem Write Binary, naredba se može koristiti za smještanje serije bajtova na EF (postavlja odabrane bitove unutar označenih bajtova na vrijednost "1"), za brisanje serije bajtova na EF (postavlja odabrane bitove unutar označenih bajtova na vrijednost "0") ili jednokratno zapiše seriju bajtova na EF.

7.5.4 Update Binary naredba

Update Binary naredbu koristi aplikacija od strane čitača da direktno izbriše i pohrani niz podataka (bajtova) na segment EF na kartici. Datoteka kojoj se pristupa mora biti transparentna, tj. ne može biti datoteka usmjerena zapisima. Ako se Update binary naredba uputi EF usmjerenom zapisima, naredba se neće izvršiti s pokazivačem grješke koji se vraća od kartice do aplikacije čitača.

Tablica 7.4 Struktura Update Binary naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	D6₁₆	01₁₆	01₁₆	01₁₆	FF₁₆

Update Binary naredba omogućuje funkcije koje bi normalno bile povezane s datotečnom naredbom zapisivanja. Tj. niz znakova u naredbi se zapravo zapisuje u EF na kartici, s pozicijama bajtova u datoteci na kartici koji su prvo izbrisani. Rezultat je da je niz znakova pronađen na označenoj poziciji unutar EF na kartici isti znakovni niz poslan putem aplikacije čitača putem Update Binary naredbe.

Ulazni parametri za naredbu uključuju jedan pomaknuti pokazivač s početka datoteke i jedan bajt brojač ukupnog broje bajtova koje treba zapisati.

7.5.5 Erase Binary naredba

Erase Binary naredbu koristi aplikacija od strane čitača za brisanje (podešava vrijednost na "0") niz znakova unutar EF na kartici. Datoteka kojoj se pristupa mora biti transparentna, tj. ne može biti datoteka usmjerena zapisima. Ako je Erase Binary naredba usmjerena na EF orijentirana zapisima, naredba se neće izvršiti s pokazivačem grješke koji se vraća od kartice do aplikacije čitača.

Tablica 7.5 Struktura Erase Binary naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	0E₁₆	01₁₆	01₁₆	01₁₆	06₁₆

Dva parametra su određena kao dio naredbe: jedan pomak od početka EF prema segmentu bajtova unutar datoteke koje treba izbrisati i broja bajtova unutar tog segmenta.

7.5.6 Read Record naredba

Read Record je naredba koju šalje aplikacija čitača da čita i vrati sadržaj jednog ili više zapisa u EF na kartici. Naredba mora biti izvršena na zapisom orijentiranom EF. Ako se primjeni na transparentni EF naredba se neće izvršiti i pokazivač grješke će biti poslan od kartice natrag prema aplikaciji čitača.

Tablica 7.6 Struktura Read Record naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	B2₁₆	06₁₆	04₁₆	14₁₆	prazno

Ovisno o parametrima poslanim putem naredbe, jedan označeni zapis se čita i vraća, ili se svi zapisi s početka datoteke do označenog zapisa čitaju i vraćaju, ili se svi podaci od označenog zapisa do kraja datoteke čitaju i vraćaju.

7.5.7 Write Record naredba

Write Record je naredba koju šalje aplikacija čitača za upisivanje zapisa unutar EF na kartici. Ta naredba mora biti izvršena na zapisom orijentiranom EF. Ako se primjeni na transparentni EF naredba se neće izvršiti i pokazivač grješke će biti poslan od kartice natrag prema aplikaciji čitača. U ovakvoj naredbi jednostavnog slijeda, 14 heksa znakova biti će zapisano u trenutno odabran zapis počevši od pozicije šestog znaka u tom zapisu. Znakovi koji trebaju biti zapisani sadržani su u podatkovnom polju (primjer zapisa "Sally Green").

Tablica 7.7 Struktura Write Record naredbe

CLA

INS

Data

C0₁₆

D2₁₆

06₁₆

04₁₆

14₁₆

53₁₆61₁₆6C₁₆6C₁₆79₁₆20₁₆47₁₆

72₁₆65₁₆65₁₆6E₁₆00₁₆00₁₆00₁₆

00₁₆00₁₆00₁₆00₁₆00₁₆00₁₆

Kao i Write Binary naredba se može koristiti za postizanje jednog od tri rezultata: jednokratno pisanje zapisa unutar EF, postava specifičnih bitova unutar specifičnog zapisa na EF, ili brisanje specifičnih bitova unutar specifičnog zapisa u EF.

Nekoliko adresiranih prečica se može koristiti u ovoj naredbi da se pobliže odredi zapis koji će se upisati, uključujući prvi zapis u EF, zadnji zapis u EF, sljedeći zapis u EF, prethodni zapis u EF, ili određeni zapis (određen pomoću broja) unutar EF.

7.5.8 Append Record naredba

Append Record je naredba koju šalje aplikacija čitača da ili doda novi zapis na kraj linearnog zapisno orijentiranog EF na kartici ili da zapiše prvi zapis u cikličkom zapisom orijentiranom EF na kartici. Ako se primjeni na transparentni EF naredba se neće izvršiti i pokazivač grješke će biti poslan od kartice natrag prema aplikaciji čitača.

Tablica 7.8 Struktura Append Record naredbe

CLA

INS

Data

C0₁₆

E2₁₆

00₁₆

14₁₆

53₁₆61₁₆6C₁₆6C₁₆79₁₆20₁₆47₁₆

72₁₆65₁₆65₁₆6E₁₆00₁₆00₁₆00₁₆

00₁₆00₁₆00₁₆00₁₆00₁₆00₁₆

Kao što vidimo u tablici 7.8, P1 se ne koristi i uvijek je 00h. P2 je kratki pokazivač datoteke na koju će se dodatni zapis primijeniti. Lc određuje broj znakova u zapisu koji se dodaje i podatkovno polje sadrži znakove koje treba dodati – u ovom slučaju heksadecimalni oblik "Sally Green". To znači, ova naredba proširuje riječi "Sally Green" u zapis odabrane datoteke.

7.5.9 Update Record naredba

Update Record je naredba koju šalje aplikacija čitača za pisanje zapisa u EF na kartici. Naredba mora biti izvršena na zapisom određenom EF. Ako se primjeni na transparentni EF naredba se neće izvršiti i pokazivač grješke će biti poslan od kartice natrag prema aplikaciji čitača.

Tablica 7.9 Struktura Update Record naredbe

CLA

INS

Data

C0₁₆

DC₁₆

06₁₆

04₁₆

14₁₆

53₁₆61₁₆6C₁₆6C₁₆79₁₆20₁₆47₁₆

72₁₆65₁₆65₁₆6E₁₆00₁₆00₁₆00₁₆

00₁₆00₁₆00₁₆00₁₆00₁₆00₁₆

Kao i kod Update Binary naredbe, naredba se koristi za pisanje određenog zapisa u EF. Rezultat operacije je da se određeni zapis u EF briše i novi se zapis određen u naredbi piše u EF.

7.6 Administrativne naredbe

U gospodar/sluga naredbenom protokolu, određenom standardom, ISO/IEC 7816-4 je prilično ograničen u svojoj sposobnosti da služi mnoštvu različitih naredbi kojim se želi pristupiti na pametnoj kartici. U pokušaju da se kompenziraju neki sintaktični nedostaci, ISO/IEC 7816-4 također definira više administrativnih naredbi koje omogućuju širi opseg naredbi i odgovora.

7.6.1 Get Response naredba

Get Response je još jedna naredba koja omogućuje korištenje T=0 prijenosnog protokola za povezivanje kompletne širine APDU. Iznimno, case 4 APDU ne može podržati T=0 protokol. Tj. ne može poslati tijelo podataka na karticu i primiti tijelo podataka natrag kao direktan odgovor na tu naredbu. Kod ovog tipa naredbe, korištenjem T=0 protokola, početna naredba rezultira odgovorom koji pokazuje da više podataka čeka na kartici. Get Response se onda koristi da uzme podatke koji su na čekanju.

Tablica 7.10 Struktura Get Response naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	C0₁₆	00₁₆	00₁₆	14₁₆	prazno

Treba napomenuti da ni jedna druga naredba ne može biti između originalne naredbe i Get Response.

7.6.2 Manage Channel naredba

Manage Chanel koristi aplikacija čitača da otvori i zatvori logičke kanale između sebe i kartice. Kada kartica početno uspostavi protokol na razini aplikacija s aplikacijom čitača (slijedeći ATR slijed) otvara se osnovni komunikacijski kanal. Taj kanal se tada koristi za otvaranje i/ili zatvaranje dodatnih logičkih kanala putem Manage Channel naredbe.

Tablica 7.11 Struktura Menage Channel naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	70₁₆	00₁₆	01₁₆	00₁₆	prazno

7.6.3 Envelope naredba

Envelop je naredba koja podržava korištenje sigurnog prenošenja poruka putem T=0 prijenosnog protokola. Kod sigurnog slanja poruka, kompletna naredba treba biti kodirana. Ipak pošto CLA i INS bajtovi iz APDU pokrivaju elemente podatkovnih jedinica prijenosnih protokola (TPDU), bajtovi (iz TPDU) ne mogu biti kodirani tako kako bi vezni protokol ispravno radio. Zato Envelope naredba omogućuje da kompletna APDU naredba bude kodirana i tada uključena u podatkovni dio tog APDU. Kartični APDU procesor može tada izdvojiti pravu naredbu i izvršiti je.

Tablica 7.12 Struktura Envelope naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	C2₁₆	00₁₆	00₁₆	07₁₆	C0₁₆A4₁₆00₁₆00₁₆02₁₆3F₁₆00₁₆

7.6.4 Get Data naredba

Get Data je naredba poslana od aplikacije čitača da čita i vraća sadržaj podatkovnog objekta pohranjenog unutar datotečnog sustava na kartici. Ova je naredba prije svega komplement Put Dana naredbi. Ova naredba je vrlo specifična u svojoj unutrašnjoj implementaciji. Ipak, semantika kartice je vrlo dobro definirana. Tj. definicija toga što čini podatkovni objekt varira široko od kartice do kartice, ali što se naredbom izvršava mora biti dosljedno od kartice do kartice. Zato, za pronalaženje malog broja informacija, ova naredba će preferirati da pronađe informacije u određenoj datoteci.

Tablica 7.13 Struktura Get Data naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	CA₁₆	02₁₆	01₁₆	14₁₆	prazno

7.6.5 Put Data naredba

Put Data je naredba koju šalje aplikacija čitača da stavi informacije u podatkovni objekt pohranjen unutar datotečnog podsustava na kartici. Naredba je vrlo specifična u svojoj unutrašnjoj implementaciji, ipak relativno je općenita u svojoj specifikaciji. Činjenica da je definicija onoga što čini podatkovni objekt varira široko od kartice do kartice, ne znači nužno da i semantika naredbe varira od kartice do kartice. Zapravo pozitivna svojstva naredbe su činjenica da nije potrebno poznavati identitet određene datoteke u koji će se podaci pohraniti. To čini ovu naredbu sličnom na različitim pametnim karticama. Ako aplikacija treba pohraniti samo skroman broj informacija to može učiniti sa ovom naredbom uz priličnu sigurnost da će naredba raditi na većini različitih kartica.

Tablica 7.14 Struktura Put Data naredbe

CLA	INS	P1	P2	Lc	Data
C0₁₆	DA₁₆	02₁₆	01₁₆	01₁₆	FF₁₆

8. Praktični rad

8.1 Programsko okruženje

Zadatak praktičnog dijela rada je program za pregled dostupnih podataka na pametnoj kartici. Program je pisan u programskom jeziku Javi verzija j2sdk1.4.2. Operacijski sustav je Windows XP sp2. U izradi programa korišteni su OpenCard Framework 1.2 izdan od strane IBM-a, Java Card kit 2.1.2 izdan od strane Sun-a, Java Communications API 2.0, Schlumberger Cyberflex Access SDK 4.1. Od sklopovskih zahtjeva korišten je Schlumberger Reflex Lite čitač, te pametna kartica Schlumberger Cyberflex Access 16k.

8.2 Instalacija potrebnih programa

Navedena instalacijska procedura je samo za Windows operacijski sustav.

Postavljanje varijabli okoline se može osim naredbom set iz komandne linije, postaviti unošenjem imena varijabli i njihovih vrijednosti u datoteku autoexec.bat za Windows 95/98/Me, odnosno imena varijabli i njihovih vrijednosti u Control Panel/ System/Advanced/ Environment Variables u Windows NT4.0/2000/Xp.

Koraci su:

1. Kreirati direktorij c:\ocf

2. Instalirati Java Development Kit sa http://java.sun.com/j2se

- pokrenuti j2sdk-1_4_2-win.exe

3. Skinuti i instalirati Comm API za javu, Java Communications API 2.0 sadržava paket javax.comm. Paket se može naći na http://java.sun.com/products/javacomm

- instalirati Comm API u c:\ocf\commapi,

1. pokrenuti javaxcomm20-win32.zip

2. otvoriti datoteku u c:\ocf (on će sam stvoriti c:\ocf\commapi direktorij)

3. tada u MS-DOS naredbenom retku napisati:

   > cd C:\ocf\commapi\

   > copy comm.jar C:\j2sdk1.4.2\lib\ext\

   > copy comm.jar C:\j2sdk1.4.2\jre\lib\ext\

   > copy javax.comm.properties C:\j2sdk1.4.2\lib\

   > copy javax.comm.properties C:\j2sdk1.4.2\jre\lib\

   > copy win32com.dll C:\j2sdk1.4.2\bin\

   > copy win32com.dll C:\j2sdk1.4.2\jre\bin\

- provjeri da li je sve dobro instalirano u MS-DOS naredbenom retku

   > cd C:\ocf\commapi\samples\BlackBox\

   > java -cp BlackBox.jar BlackBox

to će testirati sve portove koje može naći na računalu

OPASKA! ukoliko ne može naći port ili vrati iznimku "port in use" vjerojatno je instaliran PC/SC na računalu (posebno to vrijedi ako se radi o Win 2000 i Win Xp gdje on dolazi po osnovi instaliran), isključiti taj driver u Contol Panelu i pokušajti ponovno.

4. Skinuti i instalirati OpenCard Framework koji se nalazi na http://www.opencard.org/index-downloads.shtml

- skinuti "OpenCard Framework Base"

- skinuti "The OpenCard Framework Reference Implementaion V1.2"

- instalirati OCF 1.2 jezgru:

1. pokrenuti java BaseOCF, instalirati u direktorij c:\ocf\OCF1.2

2. pokrenuti java Reference_Impl, instalirati u direktorij c:\ocf\OCF1.2

- instalirati OCF 1.2 JAR datoteke u Javu u MS-DOS naredbenom retku napisati:

   > cd C:\ocf\OCF1.2\lib\

   > del gemplus-terminals.jar  (to take the last version!)

   > copy *.jar C:\j2sdk1.4.2\lib\ext

   > copy *.jar C:\j2sdk1.4.2\jre\lib\ext

   > copy OCFPCSC1.DLL C:\j2sdk1.4.2\bin

   > copy OCFPCSC1.DLL C:\j2sdk1.4.2\jre\bin\

5. Kreirati datoteku opencard.propertis u direktoriju c:\j2sdk1.4.2\jre\lib sa sljedećim sadržajem:

# Configuring the CardServiceRegistry

OpenCard.services = opencard.opt.util.PassThruCardServiceFactory

# Configuring the CardTerminalRegistry

# The parameters after the class name are:

# name, type, and address of the card terminal

OpenCard.terminals = com.ibm.opencard.terminal.pcsc10.Pcsc10CardTerminalFactory|my|OCFPCSC1|COM1

# Configuring Tracing

OpenCard.trace = opencard.core:2 opencard.opt:0 com.ibm.opencard:3 \

reflex

6. Instalirati Java Card Development Kit 2.1.2 koji se nalazi na http://java.sun.com/products/javacard/dev_kit.html

- skinuti "Download Java Card 2.1.2 Development Kit:"

- instalirati Java Card 2.1.2 :

1. instalirati Java Card 2.1.2 u c:\ocf\java_card_kit-2_1_2

2. podesiti varijable okoline:

set JC21_HOME=c:\ ocf\java_card_kit-2_1_2

@echo off

set JC21_HOME=C:\ocf\java_card_kit-2_1_2

set JAVA_HOME=d:\j2sdk1.4.2

  set PATH=.;%JC21_HOME%\bin;%PATH%

8.3 Program za čitanje sadržaja podataka pametnih kartica

Program za čitanje sadržaja podataka kartica ima mogućnost iščitati ATR umetnute kartice, podatke o mogućnosti instaliranog terminala i iščitati dostupne podatke s pametne kartice.

Slika 8.1 Izgled pokrenutog programa za čitanje podataka sa kartice i terminala

Program pokrenuti iz MS-DOS komandne linije naredbom:

> java CitanjeKartica

Naravno za ispravno pokretanje treba biti ispravno instalirani i konfigurirani: Java, OpenCard Framework, Javacomm API, pogonski programi za čitač (terminal).

Program radi s čitačem Slumberger Reflex Lite i pametnom karticom Slumberger Cyberflex Access.

Na slici 8.1 vidimo izgled sučelja pokrenutog programa, bez ikakvih pročitanih podataka.

Kao što se vidi postoje tri gumba kojima se bira što želimo pročitati s pametne kartice. Gumbom "Čitaj karticu" stvaramo upit kartici da nam odgovori sa ATR znakovima, te od dobivenih podataka dekodira ID kartice, povijesne znakove, tip konvencije koja se koristi, frekvenciji koja se koristi na kartici, koeficijentima prilagodbe, naponskom faktoru za programiranje i sl.

Slika 8.2 Pročitani podaci Čitaj karticu i O terminalu

Gumbom "O terminalu" dobiva se informacija o ugrađenom čitaču pametnih kartica. Ispisuje koliko postoji instaliranih čitača, naziv terminala, kojeg je tipa terminal, da li je kartica trenutno umetnuta u čitaču i sl.

Gumbom "Datoteke" dobiva se informacija o dostupnim podacima na pametnoj kartici. Pokretanjem niza APDU naredbi i odgovora dobiva se stablo koje odgovara onome na pametnoj kartici. U stablu su redom zapisani podaci onako kako se i nalaze na samoj kartici. Korijenski direktorij na pametnoj kartici je '3f00₁₆'. Nazivi datoteka na kartici su predstavljeni sa četiri heksa znaka.

Za svaku datoteku ispisuje se:

- naziv datoteke

- veličina datoteke

- tip (radi li se o datoteci, aplikaciji ili direktoriju)

U donjem APDU prozoru ispisuju se sve APDU naredbe poslane kartici i odgovori kartice poslani čitaču. Tim naredbama vršena je kompletna komunikacija kojom se došlo do svih dostupnih podataka na kartici.

Slika 8.3 Izgled programa kod čitanja datoteka sa pametne kartice

8.4 Programsko rješenje komunikacije

Kao što je već opisano program je napisan u programskom jeziku Javi. Programsko rješenje se jednim dijelom oslanja na gotove klase OpenCard Framework 1.2.

import opencard.core.service.SmartCard;

import opencard.core.service.CardRequest;

import opencard.opt.iso.fs.FileAccessCardService;

import opencard.opt.iso.fs.CardFile;

public class ReadFile {

public static void main(String[] args)

{

System.out.println("reading smartcard file...");

try {

SmartCard.start();

// čekaj na pametnu karticu s podrškom za pristup datotekama

CardRequest cr =

new CardRequest(CardRequest.NEWCARD, null, FileAccessCardService.class);

SmartCard sc = SmartCard.waitForCard(cr);

// ovdje se vrši komunikacija s pametnom karticom

sc.close();

} catch (Exception es) {

System.err.println("Ulovljena iznimka '" + es.getClass() + "' - " + es.getMessage() );

} finally { // u slučaju greške ...

try {

SmartCard.shutdown();

} catch (Exception es) {

System.err.println("Ulovljena iznimka '" + es.getClass() + "' - " + es.getMessage() );

}

System.exit(0);

}

Slika 8.4 Ispis općenitog osnovnog sučelja za komunikaciju s pametnom karticom

try {

System.out.println("aktiviraj Pametnu Karticu");

SmartCard.start(); // aktiviraj pametnu karticu

CardRequest cr = new CardRequest(CardRequest.ANYCARD, null, PassThruCardService.class);

cr.setTimeout(IFD_TIMEOUT); // vrijeme koje se čeka za karticu

// čekaj na pametnu karticu umetnutu u terminal

System.out.println("Čekaj na pametnu karticu");

SmartCard sc = SmartCard.waitForCard(cr);

if (sc != null) { // ako nema greške pametna kartica je u terminalu

byte[] MF = {(byte) 0x3f, (byte) 0x00}; //postavljanje osnovnog MF kartice

ArrayList hierarchy = direktorij(MF, sc); //metoda kojom prolazimo kroz karticu

System.out.println("\nDeaktiviraj Pametnu Karticu");

root = processHierarchy(hierarchy);

this.jTree1 = new JTree(root);

jTree1.setShowsRootHandles(true);

jScrollPane3.getViewport().add(jTree1);

SmartCard.shutdown();

} // if

else System.out.println("ne mogu kreirati smart card object ");

} // try

catch (Exception es) {

System.err.println("Ulovljena iznimka '" + es.getClass() + "' - " + es.getMessage() );

} // catch

Slika 8.5 Ispis dijela teksta izvornog programa CitanjeKartica za komunikaciju s pametnom karticom

Na slici 8.5 i slici 8.6 vidimo primjer otvaranja komunikacijskog kanala s pametnom karticom, poziv metode direktorij kojom komuniciramo s pametnom karticom pomoću APDU naredbi.

PassThruCardService ptcs = (PassThruCardService) sc1.getCardService(PassThruCardService.class, true);

String s = new String();

CommandAPDU command = new CommandAPDU(MAX_APDU_SIZE); // kreiranje APDU spremnika

//----- pripremanje naredbe APDU - SELECT FILE

command.setLength(0);

//priprema naredbe SELECT FILE sa nazivom trenutnog dira

command.append(SELECT_FILE);

// pošalji komandu i primi odgovor

ResponseAPDU response = ptcs.sendCommandAPDU(command);

Slika 8.6 Ispis komunikacije APDU naredbom i prihvaćanje odgovora APDU

Prilikom rješavanja problema komunikacije najviše se vremena potrošilo na uspostavljanje osnovne komunikacije. Slijedeći problem je bio kod komunikacije s naredbama APDU. Kao osnovne APDU naredbe koje su korištene u komunikaciji Select File, Get Response i Directory uzete su iz literature te kao takve nisu odgovarale dotičnoj pametnoj kartici koja je korištena. Problem je bio u zaglavlju APDU naredbe u CLA polju koje nije bilo kao u literaturi C0₁₆ nego kod CyberflexAccess 16k kartice 00₁₆ . Za rješenje ovog problema izgubljeno je dosta vremena na testiranje i pronalaženje grješke.

Usporedba dobivenih rezultata programa za Čitanje Kartica uspoređena je s programom Schlumberger Smart Card Toolki 4.1 i odgovara u potpunosti. No postoji jedna iznimka, a to je se u datotečnom sustavu u MF direktoriju nalazi datoteka ffff₁₆ čija veličina odgovara ustvari praznom prostoru na pametnoj kartici.

9. Zaključak

U ovom radu 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. Opisane su osnovne sigurnosne naredbe kojima se utvrđuje identitet kartice. Datotečni podsustav pametne kartice je vrlo sličan datotečnom sustavu na računalu ali s nekim posebnostima. Te razlike postoje isključivo zbog fizičkih svojstava EEPROM spremnika i ograničenog broja ciklusa brisanja i pisanja u EEPROM spremnik. Prva posebnost rezultira definiranjem jedne prilično jedinstvene strukture koju zovemo cyclic file. Druga posebnost rezultira u prilično jedinstvenim definicijama različitih datotečnih naredbi pisanja.

Najveći problem kod komunikacijskih standarda je njihova neusklađenost. Svaka pametna kartice komunicira s terminalom pomoću APDU naredbi koje su u osnovi standardizirane ali se ipak razlikuju, stoga program napisan za jedan tip kartica ne mora odgovarati i nekoj drugoj.

Svrha praktičnog rada je čitanje dostupnih podataka sa datotečnog podsustava pametne kartice. U izradi najveći dio vremena potrošen je na uspostavu komunikacije između kartice i terminala, podešavanju komunikacijskih klasa s upravljačkim programa na računalu. Vjerojatni razlog tome je nepostojanje novijih dostupnih inačica komunikacijskih klasa. Drugi problem je bio slanje APDU naredbe kraće od definirane standardom, pri čemu kartica stane i čeka ostatak naredbe. Ukoliko ne primi ostatak naredbe u definiranom vremenu, kartica vrati grješku. Nakon što su riješeni osnovni problemi, daljnja izrada praktičnog rada bila je trivijalna. Izrada je obuhvaćala: uspostavu komunikacije, slanje APDU naredbi, prihvat i obradu APDU odgovora, te kreiranje nove APDU naredbe na osnovi obrađenog APDU odgovora.

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

4. U.Hansmann, M.S.Nicklous, T.Schack, F.Seliger: Smart Card Application Development Using Java

5. S.B.Guthery, T.M.Jurgensen: Smart Card Developer's Kit

6. Schlumberger: http://www.schlumberger.com

7. OpenCard consortium: OpenCard Framework 1.2 — Programmer’s Guide

8. Sun microsystems: JavaCard^TM Development Kit User's Guidle

9. Schlumberger: Cyberflex Access Softvare Developer s Kit – Release 2

Hrvoje Palčić