Uslijed zahtjeva na sve široj primjeni pametnih kartica javila se potreba za bržim razvojem kartičnih aplikacija. Brži razvoj kartičnih aplikacija ne smije ugroziti temeljni razlog korištenja pametnih kartica, sigurno procesiranje. To je za razvojne programere pametnih kartica najvažnije pitanje, pitanje sigurnosti.

Java Card tehnologija omogućuje da se programi pisani u Java programskom jeziku izvode na pametnim karticama i drugim uređajima ograničenih sredstava. Nasljeđuje sigurnosna osobine Java jezika, istodobno pružajući još jedno svojstvo, neovisnost kartične aplikacije od operacijskog sustava pametne kartice. Dodatno svojstvo je i mogućnost učitavanja kartičnih aplikacija u korisničkoj fazi životnog ciklusa pametne kartice. Time pametna kartica postaje aktivni dio mrežne arhitekture.

Sigurnost se mora uzeti u obzir s točke gledanja ukupnog, općeg sustava. Java Card platforma je izgrađena na vrhu kartične platforme, koju sačinjava kartični hardver, izvorni operacijski sustav, terminal s kojim kartica komunicira i pozadinski sustav. O sigurnosti kartičnih sustava pisano je u prethodnim poglavljima a ovo poglavlje ističe dio sigurnosti kartične platforme kroz sigurnost Java Card platforme.

5.1 Pregled arhitekture

Pametne kartice danas predstavljaju jednu od najmanjih računarskih platformi. Njihova konfiguracija memorija prati otprilike ove brojke: 1K RAM-a, 16K EEPROM-a, 24K ROM-a. Najveći izazov oblikovanja Java Card tehnologije bio je kako smjestiti Java programski sustav na pametnu karticu, a istodobno očuvati dovoljno prostora za aplikacije. Rješenje se pronašlo na način da se podrži samo podskup osobina jezika Jave i da se primijeni podijeljeni model implementacije Java stogovnog stroja [1] .

Java Card stogovni stroj [2] podijeljen je na dva dijela: prvi koji se izvodi izvan kartice i drugi koji se izvodi na kartici. Zadaci koji nisu ograničeni vremenom izvođenja [3] , kao što je učitavanje klasa, provjera bajtkoda [4] , razlučivanje i povezivanje, optimizacija, obrađuju se u dijelu stogovnog stroja koji se nalazi izvan kartice, gdje resursi obično ne predstavljaju problem.

Da omogući podršku za Java programski jezik, Java Card tehnologija definira Java Card izvršnu okolinu [5] . Ona podržava kartičnu memoriju, komunikacijski model, sigurnost i aplikacijski izvršni model. Java Card izvršna okolina pridržava se međunarodnog standarda ISO 7816.

Jedno od najznačajnijih obilježja Java Card izvršne okoline je da mogućuje neovisnost kartične aplikacije od operacijskog sustava pametne kartice. Izvršna okolina enkapsulira složenost i detalje operacijskog sustava kartice. Aplikacije traže servise i resurse operacijskog sustava preko dobro definiranog programskog sučelja visoke razine.

Java Card tehnologija definira platformu za izvršavanje aplikacija pisanih u Java programskom jeziku (aplikacije pisane za Java Card platformu nazivaju se appleti). Zbog podijeljene arhitekture stogovnog stroja, platforma je raspodijeljena između pametne kartice i ostatka kartičnog sustava (npr. osobno računalo) i u vremenu i prostoru. Sastoji se od tri dijela, svaki definiran u svojoj specifikaciji:

Specifikacija Java Card 2.1 Virtual Machine – JCVM definira podskup programskog jezika Jave i definiciju stogovnog stroja prikladnog za kartične aplikacije.
Specifikacija Java Card 2.1 Runtime Environment – JCRE precizno opisuje Java Card izvršno ponašanje, uključujući upravljanje memorijom, upravljanje appletom i druge izvršne osobine.
Specifikacija Java Card 2.1 Java Card 2.1 Application Programming Interface – API opisuje jezgru i proširenja Java paketa i klasa potrebnih za programiranje kartičnih aplikacija.

5.2 Java Card jezični podskup

Zbog svojeg malog memorijskog kapaciteta, Java Card platforma podržava samo pažljivo odabrani, prilagođeni podskup osobina Java jezika. Taj podskup uključuje osobine koje su prilagođene pisanju programa za pametne kartice i druge male uređaje, istodobno čuvajući objektno-orijentirana osobine Java programskog jezika. Tablica 3.1 ističe neka bitna podržane i nepodržane osobine Java jezika.

Ključne riječi nepodržanih svojstava su također ispuštene iz jezika. Neke od naprednih Java kartica implementiraju mehanizam sakupljanja smeća, odnosno mehanizam brisanja objekata nasljeđen iz Java platforme.

Podržane osobine Jave

Nepodržane osobine Jave

· Mali primitivni tipovi podataka: boolean, byte, short

· Java paketi, klase, sučelja, iznimke

· Objektno-orijentirane osobine: nasljeđivanje, virtualne metode, nadjačavanje, dinamičko kreiranje objekta, opseg pristupa, pravila povezivanja

· Opcionalni su ključna riječ int i 32-bitni tip podatka

· Veliki primitivni tipovi podataka: long, double, float

· Znakovi i stringovi

· Višedimenzionalna polja

· Dinamičko učitavanje klasa

· Sigurnosni manager

· Sakupljanje smeća i finalizacija

· Dretve

· Serijalizacija objekata

· Kloniranje objekata

Tablica 3.1 Podržane i nepodržane osobine Jave

5.3 Java Card Stogovni Stroj

Osnovna razlika između Java Card stogovnog stroja (JCVM) i Java stogovnog stroja (JVM) je u tome što je JCVM implementiran u dva odvojena dijela (slika 3.1). Kartični dio Java Card stogovnog stroja uključuje Java Card bajtkod interpreter. Java Card konverter se izvršava na osobnom računalu. Konverter je izvan-kartični dio stogovnog stroja. Gledajući ih zajedno, oni implementiraju sve funkcije stogovnog stroja. Konverter učitava i procesira class datoteke koje čine Java paket i proizvodi CAP [6] datoteke. CAP datoteka se onda učitava u Java pametnu karticu i izvodi od strane interpretera. Kao dodatak prilikom procesa kreiranja CAP datoteke, konverter generira izvedenu datoteku [7] . Izvedena datoteka predstavlja javne API-je konvertiranog paketa.

Slika 3.1 Java Card stogovni stroj

Java Card tehnologija podržava samo podskup osobina jezika Jave. Sve nepodržane jezične oblike korištene u appletu otkriti će konverter.

5.3.1 CAP datoteke i izvedene datoteke

Java Card tehnologija uvodi dva nova formata binarne datoteke koji omogućuju platformsku neovisnost razvoja, distribucije i izvršavanja Java Card programa. CAP datoteka sadrži izvršnu binarnu prezentaciju klasa Java paketa. Format JAR [8] datoteke se koristi kao kontejner CAP datoteka. Format CAP datoteke optimiran je za male memorije korištenjem kompaktnih struktura podataka. Definira skup bajtkod instrukcija, temeljen i optimiran nad skupom instrukcija Java bajtkoda.

Svojstvo Java programa “napiši jednom, izvodi svugdje” je možda i najvažnija osobina Java platforme. U Java tehnologiji centralni dio Java arhitekture je class datoteka. Ona definira standard binarne kompatibilnosti Java platforme. Zbog raspodijeljenih karakteristika Java Card sistemske arhitekture, standard binarne kompatibilnosti Java Card platforme definira CAP datoteka. Što znači, da je format CAP datoteke oblik u kojem se programi učitavaju na Java pametnu karticu. Otuda je i došao naziv CAP datoteke - converted applet file.

Izvedene datoteke se ne učitavaju na pametnu karticu, stoga njih direktno i ne koristi interpreter. Njih proizvodi ali i korist konverter prilikom procesa provjere i povezivanja, a mogu se predočiti kao zaglavlja datoteka u C jeziku. Jedna izvedena datoteka sadrži javne API informacije za jedan paket klasa. Ona definira ime klase i njen opseg pristupa [9] , definira metode i polja klase i njihov opseg pristupa. Izvedena datoteka također sadrži informacije o povezivanju koje se koriste na kartici prilikom razlučivanja međupaketnih referenci.

Izvedena datoteka ne sadrži nikakvu implementaciju, odnosno ne sadrži bajtkod. Stoga izvedenu datoteku razvojni programer appleta slobodno distribuira do potencijalnih korisnika appleta bez otkrivanja detalja unutarnje izvedbe.

5.3.2 Java Card konverter

Za razliku od Java stogovnog stroja koji procesira jednu klasu, pretvaračka jedinica konvertera je paket. Prevoditelj [10] iz izvornog koda producira class datoteke. Zatim konverter pretprocesira sve class datoteke koje čine Java paket i konvertira ih u CAP datoteku.

Za vrijeme te konverzije, konverter izvodi zadaće koje Java stogovni stroj izvodi za vrijeme učitavanja klasa [11] :

· Potvrđuje da su učitane Java klase ispravno formirane.

· Provjerava odstupanja od Java Card jezika.

· Izvodi inicijalizaciju statičkih varijabli.

· Razrješuje simboličke reference na klase, metode i polja u jedan zbijeniji oblik kojim se može efikasnije rukovati na kartici.

· Optimira bajtkod uzimajući kao prednost informaciju dobivenu za vrijeme učitavanja klasa i procesa povezivanja.

· Alocira memoriju i kreira podatkovne strukture stogovnog stroja koje predstavljaju klase.

Konverter uzima kao ulaz ne samo class datoteke koje će se konvertirati već također jednu ili više izvedenih datoteka. Osim produciranja CAP datoteka, konverter generira i izvedenu datoteku za dotični konvertirani paket. Slika 3.2 pokazuje kako se konvertira paket. Konverter učitava sve klase u Java paket. Ako paket uvozi klase iz drugih paketa, konverter također učitava izvedene datoteke dotičnih paketa. Izlaz iz konvertora je CAP datoteka i izvedena datoteka konvertiranog paketa.

Slika 3.2 Konverzija paketa

5.3.3 Java Card interpreter

Java Card interpreter predstavlja izvršnu podršku Java jezičnog modela i time omogućava neovisnost appleta o platformi. Interpreter izvodi sljedeće zadatke:

· izvršava bajtkod instrukcije, time i applete

· kontrolira alokaciju memorije i kreiranje objekata

· igra ključnu ulogu u sigurnosti prilikom izvršavanja kartične aplikacije

Do sada smo pod pojmom Java Card stogovnog stroja uključivali interpreter i konverter. Međutim Java Card stogovni stroj se definira kao kartični dio stogovnog stroja – što je u našem slučaju interpreter. Termini Java Card interpreter i Java Card stogovni stroj se često koriste kao sinonimi, ali kada uspoređujemo Java Card platformu s Java platformom treba biti svjestan da se funkcije izvršavanja Java class datoteka postižu zajednički i kroz konverter i kroz interpreter.

5.4 Java Card instalator i izvan kartična instalacija programa

Java card interpreter ne učitava CAP datoteke. On samo izvršava kod pronađen u CAP datoteci. U Java Card tehnologiji su mehanizmi preuzimanja i instaliranja datoteka utjelovljeni u jedinici koju nazivamo instalator.

Slika 3.3 Java Card instalator i izvan kartični instalacijski program

Java Card instalator se nalazi unutar kartice. On surađuje s izvan kartičnim instalacijskim programom. Izvan kartični instalacijski program šalje kartici CAP datoteku preko uređaja za prihvat kartice, CAD uređaja. Unutar CAP datoteke nalazi se binarni kod kojeg instalator upisuje u memoriju pametne kartice, povezuje ga s ostalim klasama koje se već nalaze na kartici, kreira i inicijalizira sve podatkovne strukture koje interno koristi Java Card izvršna okolina. Na slici 3.3 prikazani su instalator, instalacijski program i njihov odnos s ostatkom Java Card platforme.

Podjela funkcionalnosti između interpretera i instalatora CAP datoteka čini interpreter malim i omogućava fleksibilnost implementacije instalatora. Detaljnije o instalatoru će biti rečeno u poglavlju vezanom za instalaciju appleta.

5.5 Java Card izvršna okolina

Java Card izvršnu okolinu sačinjavaju Java Card sistemske komponente unutar pametne kartice. JCRE je odgovorna za upravljanje kartičnim resursima, mrežnom komunikacijom, za izvršavanje appleta, za sigurnost kartičnih programa. No njezina osnovna uloga je uloga operacijskog sustava pametne kartice.

Kao što je prikazano na slici 3.4, JCRE se nalazi iznad hardvera pametne kartice i iznad izvornog operacijskog sustava. JCRE se sastoji od Java Card stogovnog stroja (bajtkod interpreter), Java Card osnovnih aplikacijskih klasa (Java Card application framework classes), industrijsko-specifičnih proširenja i JCRE sistemskih klasa. JCRE elegantno odvaja applete od vlasničkih tehnologija izdavača pametnih kartica i osigurava standardizirani sustav i API sučelje za applete. Kao rezultat, applete je jednostavnije i lakše pisati, i prenosivi su na različite kartične arhitekture.

Donji sloj JCRE čine Java Card stogovni stroj (JCVM) i izvorne metode. JCVM izvršava bajtkod, kontrolira alokaciju memorije, upravlja objektima i nameće sigurnosne mehanizme prilikom vremena izvođenja, što je i prije već navedeno. Izvorne metode predstavljaju podršku JCVM-u i sljedećem sloju sistemskih klasa. One su odgovorne za rukovanje nisko-razinskim komunikacijskim protokolima, upravljaju memorijom, osiguravaju kriptografsku podršku, itd.

Sistemske klase su izvršni alat Java Card izvršne okoline. One su analogija jezgri operacijskog sustava. Sistemskim klasama upravlja se transakcijama, one su u službi upravljanja komunikacijom između aplikacija domaćina (host application, host applications are the applications running at the terminal side with which applets communicate) i Java Card appleta, kontroliranja kreiranja appleta, selekcije i deselekcije appleta. Da izvrše svoje zadaće, sistemske klase u pravilu pozivaju izvorne metode.

Slika 3.4 JCRE arhitektura

Java Card aplikacijsko sučelje [12] definira sučelje za programiranje aplikacija. Sučelje se sastoji od osnovnih i dodatnih API paketa. Klase API paketa su prilagođene razvoju kartičnih appleta. Glavna prednost ovog sučelja je da čini relativno lakim proces kreiranja appleta. Razvojni programeri mogu usredotočiti većinu svojih napora na detalje vezane uz applet, radije nego na detalje vezane uz infrakstuturu kartičnog operacijskog sustava. Kroz API klase appleti pristupaju JCRE servisima.

Specifične industrije opskrbljuju se dodatnim bibliotekama što im omogućava nove servise i poboljšava sigurnosni i sistemski model. Kao primjer možemo navesti biblioteke specifikacije Open Platform koje proširuju JCRE servise da zadovolje specifične sigurnosne potrebe financijske industrije. Između ostalog one nameću kontrolu kartica od strane izdavača i određuju standardni skup naredbi za personalizaciju kartica.

Instalator omogućuje sigurno preuzimanje sofvera i appleta na karticu nakon što je kartica proizvedena i izdana nositelju kartice. Instalator surađuje s izvan kartičnim instalacijskim programom. Zajedno, ispunjavaju zadatak učitavanja binarnog sadržaja CAP datoteka. Sam instalator je opcijska JCRE komponenta. Bez njega, sav kartični softver, uključujući applete, mora biti upisan u kartičnu memoriju za vrijeme procesa proizvodnje kartice.

Java Card appleti su korisničke aplikacije na Java Card platformi. Oni su dakako pisani u podskupu Java programskog jezika i kontrolirani i upravljani od strane JCRE-a. Appleti se mogu učitati Java pametnu karticu i u korisničkoj fazi životnog ciklusa kartice.

5.5.1 Vrijeme života Java Card izvršne okoline

Java stogovni stroj izvršava se na osobnom računalu ili radnoj stanici kao proces operacijskog sustava. Podaci i objekti se kreiraju u RAM-u. Kada se ubije OS proces, Java aplikacije i njihovi objekti su automatski uništeni.

Na Java pametnoj kartici, Java stogovni stroj se izvršava unutar Java Card izvršne okoline. JCRE se inicijalizira za vrijeme inicijalizacije kartice. Inicijalizacija JCRE se izvodi samo jednom u životnom ciklusu kartice. Za vijeme tog procesa JCRE inicijalizira stogovni stroj i kreira objekte koji omogućavaju JCRE servise i upravljanje appletima. Nakon učitavanja appleta, JCRE kreira njihove instance a appleti kreiraju svoje objekte za pohranu podataka.

Većina informacija na kartici mora biti očuvana čak i kad se kartica ukloni s napajanja. U tu svrhu se koristi ispisna (perzistentna) memorijska tehnologija (kao što je EEPROM). U perzistentnoj memoriji se kreiraju podaci i objekti. Vrijeme života JCRE je ekvivalentno kompletnom vremenu života kartice. Kad se ukloni napajanje zaustavlja se stogovni stroj ali stanje JCRE-a i objekti kreirani na kartici ostaju sačuvani.

Sljedeći put kad se na karticu dovede napajanje, JCRE ponovno pokreće izvršavanje stogovnog stroja učitavanjem podatka iz perzistentne memorije. Treba napomenuti da JCRE ne nastavlja operacije stogovnog stoja na mjestu na kojem je stogovni stroj stao kad je kartica ostala bez napajanja. Stogovni stroj se ponovno pokreće i izvršava od početka glavne petlje. Prekid sjednice JCRE-a se razlikuje se od JCRE inicijalizacije u tome što appleti i objekti kreirani na kartici ostaju sačuvani. Za vrijeme nove sjednice, ako transakcija prethodno nije završila, JCRE izvodi potrebno čišćenje da dovede JCRE u konzistentno stanje.

5.5.2 Kako JCRE funkcionira za vrijeme CAD sjednice?

Razdoblje između vremena kad je kartica stavljena u CAD uređaj i priključena na napajanje, i vremena kad se kartica ukloni iz CAD-a, naziva se CAD sjednica. Za vrijeme CAD sjednice JCRE radi kao obična pametna kartica – podržava APDU I/O komunikaciju s aplikacijom terminala (slika 3.5). APDU–ovi su paketi podataka koje izmjenjuju appleti s aplikacijom terminala (host application). Svaki APDU sadrži ili naredbu terminala ili odgovor appleta (vidi poglavlje 2.3.6).

Slika 3.5 APDU I/O komunikacija

Ponovnim uspostavljanjem sjednice (JCRE reset) JCRE ulazi u petlju, i čeka APDU naredbu od terminala. Terminal šalje APDU naredbe Java Card platformi koristeći sučelje serijske komunikacije kartičnog ulaznog/izlaznog kontakta.

Kad stigne naredba, JCRE ili odabire applet za izvođenje, na što ju upućuje pristigla naredba, ili prosljeđuje naredbu trenutno aktivnom, selektiranom appletu. Selektirani applet tada preuzima kontrolu i procesira APDU naredbu. Kad završi šalje odgovor terminalu i predaje kontrolu JCRE-u. Taj proces se ponovi kad stigne sljedeća naredba.

5.5.3 Svojstva Java Card izvršne okoline

Osim što podržava izvršni model Java jezika, JCRE podržava tri dodatne osobine vremena izvođenja:

· perzistentni i tranzijentni objekti – Standardno, Java Card objekti su perzistentni i kreirani su u perzistentnoj memoriji. Prostor i podaci takvih objekata traju, odnosno premošćuju više CAD sjednica. Zbog sigurnosnih razloga i razloga vezanih za učinkovitost, appleti mogu kreirati objekte i u RAM memoriji. Takvi objekti se nazivaju tranzijentni objekti. Tranzijentni objekti sadrže privremene podatke koji ne perzistiraju kroz više CAD sjednica.

· Atomarne operacije i transakcije – Java Card stogovni stroj osigurava da je svaka operacija pisanja u pojedinačno polje objekta ili klase atomarna. Ažurirano polje ili dobiva novu vrijednost ili mu se vraća prethodna vrijednost. Dodatno, JCRE pruža transakcijske API-je. Applet može uključiti nekoliko operacija pisanja u transakciju. Ili su sva ažuriranja u transakciji završena ili (ako se dogodi pogreška usred transakcije) se niti jedno ne provodi.

· Vatrozid [13] appleta i mehanizmi dijeljenja – Vatrozid appleta izolira applete. Svaki applet se izvodi unutar označenog prostora. Postojanje i operacije jednog appleta nemaju utjecaja na druge applete na kartici. Vatrozid appleta nameće Java Card stogovni stroj dok izvršava bajtkod. U situacijama kad appleti žele dijeliti podatke ili pristupati JCRE servisima, stogovni stroj dopušta takve funkcije kroz sigurne mehanizme dijeljenja.

5.6 Java Card API

Java Card API se sastoje od skupa prilagođenih klasa za programiranje pametnih kartičnih aplikacija prema ISO 7816 modelu. API-ji sadrže tri osnovna paketa i jedan dodatni. Tri osnovna paketa su java.lang, javacard.framework i javacard.security. Dodatni paket je java.cardx.crypto.

Mnoštvo Java platformskih klasa nije podržano u Java card API-jima. Na primjer nisu podržane Java platformske klase za GUI [14] sučelja, klase za mrežni I/O, klase za datotečni I/O. Razlog je u tome što pametne kartice nemaju zaslon, koriste drugačiji mrežni protokol i drugačiju strukturu datotečnog sustava. Također, da se udovolji strogim memorijskim zahtjevima, nije podržano mnoštvo Javinih uslužnih klasa.

Klase u Java Card API-jima su cjelovite i zbijene. Osim što sadrže klase preuzete od Java platforme, također sadrže i klase specijalno stvorene za pametne kartice kompatibilne sa standardom ISO 7816.

5.6.1 java.lang paket

Java Card java.lang paket je podskup odgovarajućeg java.lang paketa Java platforme. Podržane klase su Object, Throwable i neke klase vezane uz iznimke stogovnog stroja. Za podržane klase mnoštvo Java metoda nije dostupno, npr. klasa Java Card Object definira samo standardni konstruktor i equals() metodu.

Paket java.lang pruža osnovnu podršku Java jeziku. Klasa Object predstavlja korijen u hijerarhiji Java Card klasa, a klasa Throwable zajedničkog pretka svih kartičnih iznimaka. Podržane klase iznimaka osiguravaju nepromijenjenu semantiku prilikom pojave greške. Kao primjer može poslužiti iznimka NullPointerException, javlja se zbog dohvata null reference, koju izbacuje i Java stogovni stroj i Java Card stogovni stroj kad dohvate null referencu.

5.6.2 javacard.framework paket

Paket javacard.framework je središnji paket koji sa svojim klasama i sučeljima omogućuje osnovnu funkcionalnost Java Card appleta. Što je još važnije, on definira bazičnu klasu Applet, koja za vrijeme života appleta predstavlja sučelje za izvođenje appleta i sučelje za interakciju appleta s JCRE-om. Odnos te klase i JCRE-a je sličan odnosu Java Applet klase i preglednika na računalu. Korisnička applet klasa mora nasljediti bazičnu Applet klasu, a da implementira funkcionalnost appleta mora nadjačati [15] metode u Applet klasi.

Druga važna klasa u javacard.framework paketu je APDU klasa. APDU paketi se prenose transportnim protokolom. Postoje dva standardizirana transportna protokola, protokol T=0 i protokol T=1. APDU klasa je tako osmišljena da bude neovisna o korištenom transportnom protokolu. Drugim riječima ona je pažljivo dizajnirana tako da sakrije zamršenosti i razlike T=0 i T=1 protokola. Programeri mogu puno lakše rukovati APDU naredbama koristeći metode koje pruža APDU klasa. Appleti rade ispravno neovisno o transportnom protokolu kojeg podržava platforma.

Nije podržana klasa Java platforme java.lang.System. Umjesto nje, kao sučelje sustava, Java Card platforma sadrži klasu javacard.framework.JCSystem. Ona uključuje skup metoda za kontrolu izvođenja appleta, za upravljanje resursima, za upravljanje transakcijama i metode za dijeljenje objekata između appleta na Java Card platformi.

Druge klase podržane u javacard.framework paketu su PIN, iznimke i uslužne klase. PIN se često koristi kod pametnih kartica kao lozinka za autentikaciju vlasnika kartice.

5.6.3 javacard.security paket

Paket javacard.security predstavlja sučelje za kriptografske funkcije podržane na Java Card platformi. On je baziran na paketu java.security.

Paket javacard.security definira klasu za proizvodnju ključeva keyBuilder i različita sučelja koja predstavljaju kriptografske ključeve korištene u simetričnim (DES) i asimetričnim (DSA i RSA) algoritmima. Kao dodatak podržava i bazične apstraktne klase RandomdData, Signature i MessageDigest, koje se koriste prilikom generiranja slučajnih brojeva, izračunavanja sažetka poruke [16] i digitalnog potpisivanja.

5.6.4 javacardx.crypto paket

Paket javacardx.crypto je dodatni paket. Sadrži kriptografske klase i sučelja koje podliježu izvoznim zahtjevima SAD-a. Definira bazičnu apstraktnu klasu Chipher koja je podrška funkcijama enkripcije i dekripcije.

Paketi javacard.security i javacardx.crypto definiraju API sučelja koja zovu appleti kad potražuju kriptografske servise. Međutim, ti paketi ne predstavljaju implementaciju. Izdavač kartica, odnosno proizvođač kartica koji vrši implementaciju JCRE-a dužan je dopuniti skup klasa koje implementiraju sučelja za ključeve a nasljeđuju apstraktne klase RandomData, MessageDigest, Signature i Chiper. Obično na pametnoj kartici postoji i odvojeni koprocesor koji izvodi zahtjevnije kriptografske funkcije.

5.7 Java Card Appleti

Java Card appleti ne smiju se zamijeniti s Java appletima samo zato što se i jedni i drugi nazivaju appletima. Java Card applet je Java program koji zadovoljava skup konvencija koje mu omogućuju izvođenje u Java Card izvršnoj okolini. On nije namjenjen izvođenju unutar preglednika. Razlog zašto je izabran naziv applet za Java Card aplikacije dolazi od toga što se Java Card appleti mogu učitati u Java Card izvršnu okolinu nakon što je kartica proizvedena. Odnosno, za razliku od kartičnih aplikacija u mnoštvu postojećih sustava, appleti se ne moraju upisati u ROM prilikom proizvodnje, jer se mogu nakon što je kartica proizvedena, dinamički učitati na karticu.

Appletova klasa mora nasljediti klasu javacard.framework.Applet, stoga je klasa Applet nadklasa svih appleta koji se nalaze na Java kartici. Ona je okvir koji definira appletove metode i varijable. Applet koji se izvodi na kartici je instanca klase Applet, objekt klase applet. Kao svaki perzistentni objekt, jednom kreiran, applet zauvijek živi na kartici.

Java Card izvršna okolina podržava postojanje više appleta na istoj kartici, dakle multi-aplikacijsko okruženje. Osim toga jedan applet može imati više instanci. Na primjer, možemo kreirati instancu appleta koji implementira novčanik s valutom američkog dolara i drugu instancu s valutom hrvatske kune.

5.8 Dogovor vezan uz pridruživanje imena paketu i appletu

Paketi i programi se unutar Java platforme jedinstveno indentificiraju koristeći Unicode stringove i nacrt nazivlja baziran na imenima internet domena. Kod Java Card platforme svaka se instanca appleta jedinstveno identificira i selektira korištenjem aplikacijskog identifikatora - AID [17] . Svakom se Java paketu također dodijeljuje AID. Kad se učita na karticu, paket se povezuje s drugim paketima na kartici pomoću njihovih AID-ova.

ISO 7816 opisuje izgled AID-a i korisit ga za jedinstvenu identifikaciju kartičnih aplikacija i nekih vrsta datoteka u kartičnim datotečnim sustavima. Sam AID je polje bajtova koje se može predočiti kroz dva odvojena dijela (slika 3.6). Prvi dio je 5-bajtovna vrijednost nazvana identifikator izvora – RID [18] . Drugi dio je varijabilne duljine a zove se identifikator vlasničkog proširenja - PIX [19] . PIX može biti dugačak 2 do 12 bajtova. Zbog toga AID može u ukupnoj duljini varirati od 5 do 16 bajtova.

RID ( 5 bajtova )

PIX ( 0 - 11 bajtova )

Slika 3.6 Aplikacijski identifikator

ISO kontrolira pridjeljivanje RID-ova kompanijama; svaka kompanija mora imati jedinstveni RID. Pridjeljivanje PIX-ova ostavljeno je na upravljanje kompanijama. Detalji vezani uz AID mogu se naći u ISO 7816-5, AID Registration Category D Format.

Kod Java Card platforme AID paketa se konstruira ulančavanjem RID-a kompanije i PIX-a za dotični paket. Slično se konstruira i AID appleta. Ulančava se RID izdavača appleta i PIX dotičnog appleta. Appletov AID ne smije imati vrijednost jednaku vrijednosti nekog AID paketa ili vrijednost jednaku vrijednosti AID-a nekog drugog appleta. Dakako, kako RID u AID-u određuje izdavača appleta, AID paketa i AID-ovi appleta definiranih u paketu moraju dijeliti isti RID.

AID paketa i standardni appletov AID, za svaki applet definiran u dotičnom paketu, specificirani su u CAP datoteci. Oni se isporučuju konverteru kad generira CAP datoteku.

5.9 Razvojni proces appleta

Programiranje Java Card appleta počinje kao sa svakim Java programom. Razvojni programer piše jednu od Java klasa i prevodi izvorni tekst s Java prevoditeljem [20] , producirajući tako jednu ili više class datoteka. Slika 3.7 pokazuje appletov razvojni proces.

Sljedeći korak je izvođenje appleta u simulacijskom okruženju. Tu ispitujemo ponašanje appleta u radu, pronalazimo i ispravljamo pogreške. Simulator na osobnom računalu oponaša Java Card izvršnu okolinu. U simulacijskom okruženju applet se izvodi na Java stogovnom stroju odnosno njegove class datoteke izvršava Java stogovni stroj.

Na taj način simulator može iskoristiti mnoštvo Java razvojnih alata i omogućiti razvojnom programeru ispitivanje ponašanja appleta i brzo sagledavanje rezultata njegovog izvođenja, bez da prolazi kroz proces pretvorbe. Dakako, neka svojstva vremena izvođenja Java Card stogovnog stroja, kao što je vatrozid appleta i ponašanje tranzijentnih i perzistentnih objekata, ne mogu se proučiti.

Slika 3.7 Razvojni proces appleta

Treći korak je da se class datoteke appleta koje sačinjavaju Java paket pretvore u CAP datoteku korištenjem Java Card konvertera. On uzima kao ulaz ne samo class datoteke predodređene za pretvorbu, već i jednu ili više izvedenih datoteka. Kad je paket appleta pretvoren, konverter kao izlaz može dati i izvedenu datoteku za dotični paket. CAP datoteka i izvedena datoteka predstavljaju jedan Java paket. Ako applet obuhvaća nekoliko paketa, za svaki paket biti će kreirana izvedena datoteka i CAP datoteka.

U četvrtom koraku se CAP datoteka/e koja predstavljaju applet učitavaju i testiraju u emulacijskom okruženju. Emulator također simulira Java Card izvršnu okolinu na osobnom računalu ili radnoj stanici. Međutim, emulator je sofisticiraniji alat za testiranje jer sadrži implementaciju Java Card stogovnog stroja. Ponašanje appleta prilikom izvršavanja u emulatoru trebalo bi biti jednako njegovom ponašanju na kartici. Dakle, u ovoj fazi razvoja mjerimo i testiramo ponašanje appleta prilikom izvođenja.

Većina Java Card simulatora i emulatora dolazi s ugrađenim programom za ispitivanje pogrešaka [21] . On omogućuje programeru postavljenje ispitnih točki u programski tok i izvršavanje programa korak po korak, gdje onda programer, u simuliranoj ili emuliranoj Java Card izvršnoj okolini, promatra promjene stanja appleta u izvođenju.

Konačno, posljednji korak u razvoju appleta, nakon što je applet testiran i doveden u oblik da je predstavljen s jednom ili više CAP datoteka, je učitavanje i instalacija appleta na karticu.

5.10 Instalacija appleta

Kartični operacijski sustav, koji je obično specifičan za pojedinog proizvođača, i Java Card izvršna okolina – uključujući i izvorne metode [22] , Java Card stogovni stroj, API klase i biblioteke – upisuju se u ROM prilikom proizvodnje kartice. Taj proces pisanja stalnih komponenti u ispisnu neprogramirljivu memoriju čipa naziva se maskiranje i varira od proizvođača do proizvođača.

5.10.1 ROM appleti

Klase Java Card appleta mogu se za vrijeme procesa proizvodnje kartice maskirati u ROM zajedno s JCRE-om i drugim sistemskim komponentama. Instance appleta se stvaraju u EEPROM-u od strane JCRE-a za vrijeme JCRE inicijalizacije ili u kasnijim fazama proizvodnje. Takvi appleti se nazivaju ROM appleti.

ROM appleti su predefinirani appleti koji dolaze s karticom a izdaju ih kartični izdavači. Zbog toga što sadržaj appleta kontrolira izdavač, Java Card tehnologija dopušta ROM appletima da deklariraju izvorne metode čija implementacija može biti u drugim programskim jezicima, kao što su C ili strojni jezici. Izvorne metode ne podliježu sigurnosnim mehanizmima koje nameće Java Card stogovni stroj.

5.10.2 Predizdani i postizdani appleti

Alternativno, nakon što je kartica proizvedena, mogu se klase Java Card appleta i pripadne klase biblioteka učitati, odnosno upisati u ispisnu programirljivu memoriju (kao što je EEPROM) Java pametne kartice. Takvi appleti se mogu dalje dijeliti na predizdane i postizdane applete. Nazivi predizdani i postizdani dolaze iz činjenice da se appleti mogu učitati prije ili nakon izdavanja kartice. Predizdani appleti tretiraju se na isti način kao i ROM appleti; i jedni i drugi su kontolirani od izdavača.

Za razliku od ROM ili predizdanih appleta, postizdanim appletima nije dozvoljena deklaracija izvornih metoda. Razlog tome je što JCRE ne može kontrolirati sadržaj appleta i dozvoljavajući učitanim appletima da sadrže izvorni kod postojala bi mogućnost narušavanja Java Card sigurnosti [23] .

Podpoglavlja koja slijede koncentrirati će se na instalaciju postizdanih appleta. Obično se predizdani appleti učitavaju korištenjem istih mehanizama za učitavanje postizdanih appleta, no Java Card tehnologija ostavlja tu odluku kartičnim izdavačima.

5.10.3 Instalacija postizdanih appleta

Instalacija appleta se odnosi na proces učitavanja appletovih klasa u CAP datoteku, njihovog spajanja sa stanjem izvođenja Java Card izvršne okoline i na proces kreiranja instance appleta, da se omogući dovođenje appleta u stanje selektiranosti a zatim i u stanje izvođenja.

Kod Java Card platforme osnovna jedinica koja se učitava i instalira je CAP datoteka. CAP datoteka se sastoji od klasa koje čine Java paket. Najmanji applet predstavljen je s Java paketom koji sadrži jednu klasu, koja nasljeđuje klasu javacard.framework.Applet. Složeniji appleti s većim brojem klasa mogu biti organizirani u jedan Java paket ili skup Java paketa.

Da učita applet, izvan kartični instalacijski program uzima CAP datoteku i transformira je u slijed APDU naredbi koje sadržavaju CAP datoteku. Kartični instalator, izmjenjujući APDU naredbe s izvan kartičnim instalacijskim pogramom, upisuje sadržaj CAP datoteke u perzistentnu kartičnu memoriju i povezuje klase iz CAP datoteke s ostalim klasama koje se nalaze na kartici. Instalator također kreira i inicijalizira sve podatke koje interno koristi JCRE da podrži applet. Ako applet zahtijeva za svoje izvođenje nekoliko paketa svaka se dotična CAP datoteka učita na karticu.

Kao posljednji korak u instalaciji appleta instalator stvara instancu appleta i registrira je kod JCRE-e. Da to učini poziva install metodu:

public static void install (byte[] bArray, short offset, byte length)

Ta metoda predstavlja početnu metodu za applet, ulaznu točku, slično main metodi u Java aplikaciji. Applet mora implementirati install metodu. U njoj zove appletov konstruktor da kreira i inicijalizira instancu appleta. Preko parametra bArray prenose se u install metodu instalacijski parametri. Oni se mogu koristiti prilikom inicijalizacije appleta. Instalacijski parametri šalju se kartici zajedno s CAP datotekom. Razvojni programer appleta definira format i sadržaj instalacijskih parametara.

Nakon inicijalizacije appleta i njegove registracije kod JCRE-a, on se može selektirati i izvršiti. JCRE identificira trenutno izvršavani applet, odnosno njegovu instancu, koristeći njegov AID. Applet se može registrirati kod JCRE koristeći svoj predodređeni AID nađen u CAP datoteci, ili može izabrati drugi, alternativni AID. U tu svrhu se mogu koristiti, da pruže izbor alternativnog AID-a, instalacijski parametri.

U kreiranju višestrukih instanci appleta potrebno je za svaku instancu pozvati install metodu. Svaka instanca appleta se identificira jedinstveni AID-om.

Java Card okolina omogućava da applet bude napisan i izvršen a da ne zna kako su njegove klase učitane. Jedina appletova obaveza u procesu instalacije je implementacija install metode.

5.10.4 Oporavljanje od pogreške za vrijeme instalacije appleta

Proces instalacije ima svojstvo transakcije. U slučaju pogreške, kao što je nedostatak memorije, fizičko oštećenje kartice i niz drugih pogrešaka, instalator odbacuje CAP datoteku i sve applete stvorene za vrijeme instalacije te obnavlja prostor i prijašnje stanje JCRE-a.

5.10.5 Instalacijska ograničenja

Treba napomenuti da se instalacija appleta razlikuje od dinamičkog učitavanja klasa za vrijeme izvođenja, koje podržava Java stogovni stroj na osobnom računalu. Instalacija Java Card appleta jasno označuje preuzimanje i učitavanje klasa kroz instalacijski proces nakon što je kartica proizvedena.

Zbog toga u instalaciji Java Card appleta treba istaći dvije činjenice. Prvo, izvršavanje appleta na kartici odnosi se samo na klase koje već postoje na kartici jer ne postoji način da učitavamo klase za vrijeme normalnog izvršavanja appletovog koda (izvršnog teksta).

Drugo, redoslijed učitavanja mora jamčiti da svaki novo učitani paket referencira samo one pakete koji se nalaze na kartici. Kao primjer uzmimo instalaciju appleta. Da bi instalacija bila moguća na kartici se mora nalaziti paket javacard.framework, jer sve klase appleta nasljeđuju klasu javacard.framework.Applet. U slučaju kružnih, unakrsnih referenci, npr. paket A i paket B referenciraju jedan drugoga, instalacija rezultira pogreškom.

5.11 Sigurnosne osobine Java Card platforme

Sigurnosne osobine Java Card platforme kombinacija su osnovnih sigurnosnih osobina jezika Jave i dodatne sigurnosne zaštite definirane Java Card platformom.

5.11.1 Sigurnosne osobine Java jezika

Java Card platforma podržava podskup programskog jezika Jave i specifikaciju stogovnog stroja prilagođenu aplikacijama pametnih kartica. Zbog toga Java Card platforma nasljeđuje sigurnosne osobine ugrađene u podržani podskup jezika Jave (osobine su navedene i ukratko opisane u listi koja slijedi). Sigurnost jezika Jave tvori temelje sigurnosti Java Card platforme:

· Java jezik je strogo tipiziran. Ne može se učiniti niti jedna ilegalna konverzija podataka, kao što je pretvorba cjelobrojnog tipa podatka u pokazivač [24] .

· Java jezik nameće provjeru granice, duljine polja, prilikom pristupanja polju podataka.

· Java jezik ne poznaje aritmetiku pokazivača. Zbog toga ne postoji mogućnost krivotvorenja pokazivača s ciljem da se dozvoli zlonamjernim programima njuškanje po sadržaju memorije.

· Incijalizacija varijabli mora biti provedena prije korištenja istih.

· Razina pristupa svim klasama, metodama i poljima je strogo kontrolirana. Na primjer, privatna metoda ne može biti pozvana izvan njezine definirajuće klase.

5.11.2 Dodatne sigurnosne osobine Java Card platforme

U izrazito sigurnosno-osvještenom svijetu pametnih kartica, želja je izdavača kartica imati sigurnu računarsku platformu koja će zadovoljiti specijalne zahtjeve kartičnih sustava. Slijede dodatne sigurnosne osobine definirane u Java Card platformi:

· Tranzijentni i perzistentni objektni modeli – Na Java Card platformi objekti se standardno pohranjuju u perzistentnoj memoriji. Iz sigurnosnih razloga i razloga vezanih uz performance, Java Card platforma dopušta da se privremeni podaci, kao što su ključevi sjednica, pohrane kao tranzijentni objekti u RAM memoriju. Životno vrijeme takvih objekata može biti deklarirano kao CLEAR_ON_RESET ili CLEAR_ON_DESELECT. Što znači da se sadržaj tranzijentnog objekta postavlja na predefiniranu vrijednost (zero, false, null) svaki put kad kartica uspostavi novu sjednicu (reset) ili kad se deselektira trenutno označeni, selektirani applet.

· Atomarnost i transakcije – Na Java Card platformi podaci se pohranjuju kao objekti u perzistentnu memoriju. Nad njima vršimo operacije pisanja i čitanja. Za vrijeme operacije pisanja može doći do hardverske pogreške ili do gubitka napajanja. Da u takvim slučajevima osigura integritet podataka Java Card tehnologija definira tri sigurnosna svojstva. Kao prvo, Java Card platforma jamči atomarnost u pojedinačnom ažuriranju elementa perzistentnog objekta ili klase. Što znači da, kad dođe do pogreške za vrijeme ažuriranja elementa, platforma osigurava da se sadržaj elementa obnovi na prijašnju vrijednost. Drugo, metoda arrayCopy u klasi javacard.framework.Util jamči atomarnost blokovskog ažuriranja višestrukih podatkovnih elemenata u polju. Ovdje atomarnost znači da će svi bajtovi biti ili ispravno kopirani ili će kompletno odredišno polje biti obnovljeno na prijašnje vrijednosti. Treće, Java Card platforma podržava transakcijski model u kojem applet atomarno ažurira nekoliko različitih elemenata unutar različitih perzistentnih objekata. Ili se sva ažuriranja unutar transakcije moraju izvesti ispravno i konzistentno ili se svi perzistentni elementi vraćaju u prijašnja stanja.

· Vatrozid appleta – On čuva kako sigurnost i integritet sustava (JCRE) tako i sigurnost i integritet svakog appleta koji se nalazi na Java pametnoj kartici. Vatrozid appleta provodi izolaciju appleta i odvaja sistemski prostor od appletovog prostora. U nacrtu vatrozida svaki se applet izvodi unutar konteksta [25] (prostor objekta) a sam vatrozid predstavlja granicu među njima. Appleti ne mogu međusobno pristupati svakom objektu osim ako su definirani unutar istog paketa (time dijele isti kontekst) ili ako za pristup objektu koriste dobro definirane, sigurne mehanizme dijeljenja objekata podržane platformom.

· Dijeljenje objekata – Dijeljenje objekata je u Java Card sustavu postignuto na sljedeće načine. Prvo, JCRE je povlašten korisnik s mogućnošću pristupa svim appletima i svim objektima kreiranim od strane appleta. Drugo, applet potražuje pristup JCRE servisima i resursima kroz tzv. ulazne točke, ulazne objekte JCRE-a. Treće, appleti koji pripadaju različitim kontekstima mogu dijeliti objekte ako su oni instance klasa koje implementiraju sučelje za dijeljenje objekata. Takvi objekti nazivaju se dijeljeni objekti [26] . I konačno, appleti i JCRE mogu dijeliti podatke preko globalno definiranih polja.

· Izvorne metode u appletima – Izvorne metode ne izvršava Java Card stogovni stroj i kao takve nisu predmet sigurnosne zaštite Java Card platforme. Zbog toga je postizdanim appletima (appleti koji su učitani na karticu nakon što je kartica izdana) zabranjeno sadržavati izvorne metode. ROM appleti i predizdani appleti su kontrolirani od strane izdavača te se njima dopušta korištenje izvornih metoda. U takvim appletima je sučelje izvornog koda predstavljeno vlasničkom tehnologijom kartičnog izdavača.

5.11.3 Sigurnost appleta

Općenito, sigurnost aplikacije određena je sigurnošću platforme na kojoj se aplikacija izvodi, te sigurnosnim osobinama implementiranim u sam dizajn aplikacije. Java Card platforma dizajnirana je na načina da pruži izgradnju, instalaciju i izvođenje appleta u visoko zaštićenom okruženju.

Određenu razinu sigurnosti potrebno je ugraditi u dizajn appleta. Zbog prisutnosti sigurnosnih osobina u samoj platformi, razvojni programeri appleta mogu usredotočiti svoje napore na definiranje strategije zaštite appleta, radije nego na programiranje appleta na način da appleti kompenziraju nesigurnost platforme.

Dobro definirana strategija zaštite mora zadovoljiti sljedeća svojstva:

· Autentikacija – pristup funkcijama i podacima appleta mora biti strogo kontroliran. Nužno je provesti proceduru autentikacije u cilju provjere identiteta aplikacije terminala. Također prilikom dijeljenja objekata applet server mora provjeriti identitet appleta klijenta prije nego što mu dozvoli korištenje svojih dijeljenih objekata.

· Tajnost – nužna je zaštita privatnosti appletovih podataka. Onemogućiti pristup zaštićenim podacima, kao što su broj računa i iznos kredita, bez prethodno izvršene autenitkacije. Tajni podaci, PIN i tajni kriptografski ključevi, ne smiju nikad napustiti karticu.

· Integritet – potrebno je osigurati ispravnost appletovih podataka. Podaci appleta ne smiju biti mijenjani bez prethodno izvršene procedure autentikacije. Promjena podataka štiti se i provjerom potencijalnih pogreški, npr. iznos e-novčanika ne smije prijeći maksimalni iznos niti postati negativan.

Različiti appleti zahtijevaju različite razine sigurnosti. Implementirani sigurnosni mehanizmi često nameću zahtjeve na računarske resurse, smanjujući time perfomanse izvođenja appleta. Zbog toga je potrebno za svaki applet odrediti njegove sigurnosne zahtjeve i prema njima implementirati odgovarajuće sigurnosne mehanizme da se zadovolji željena razina sigurnosti.

Literatura

1. Wolfgang Rankl, Wolfgang Effing: Smart Card Handbook, second edition, John Wiley & Sons, rujan 2000

2. Zhiqun Chen: Java Card Technology for Smart Cards: Architecture and Programmer´s Guide, The Java Series, lipanj 2000

3. Paul C. Kocher, Joshua Jaffe, Benjamin Jun: Introduction to Differential Power Analysis and Related Attacks, internet, 1998

4. Ross J. Anderson, Markus G. Kuhn: Improved Differential Fault Analysis, internet, studeni 1996

5. Ross J. Anderson, Markus G. Kuhn: Tamper Resistance – a Cautionary Note, USENIX Workshop, studeni 1996

6. Schlumberger: Cyberflex Access Programmer`s Guide, Release 3C, srpanj 2000

7. Schlumberger: A Developer`s Guide to Schlumberger Smart Card Middleware, Release 3C, srpanj 2000

8. Schlumberger: CyberflexAccess Software Developer`s Kit Guide, Release 3C, srpanj 2000

[1] engl. Java Virtual Machine, JVM

[2] engl. Java Card Virtual Machine, JCVM

[3] engl. runtime

[4] engl. bytecode

[5] engl. Java Card Runtime Environment, JCRE

[6] engl. Converted APplet, CAP

[7] engl. export file

[8] engl. Java Archive, JAR

[9] engl. access scope

[10] engl. compiler

[11] engl. class-loading time

[12] engl. Java Card Application Framework

[13] engl. firewall

[14] engl. Graphical User Interface

[15] override

[16] engl. message digest

[17] engl. Application Identifier, AID

[18] engl. Resource Identifier, RID

[19] engl. Proprietary Identifier Extension, PIX

[20] engl. java compiler, javac

[21] engl. debugger

[22] engl. native methods

[23] engl. Java Card Security

[24] engl. pointer

[25] engl. context

[26] engl. shareable interface objects