DIPLOMSKI RAD br. 1546

SIGURNOSNI MEHANIZMI JAVA PAMETNE KARTICE

1. Uvod

U današnjem prenapučenom dinamičnom svijetu stari principi birokracije postaju neprikladni i javlja se potreba za razvijanjem novih tehnologija koje približavaju digitalni svijet računala pojedincu. Jedna od takvih tehnologija je pametna mikroprocesorska kartica čija primjena može u potpunosti ukloniti potrebu za nošenjem i posjedovanjem više papirnatih dokumenata.

U svijetu gdje uvijek postoji želja za prevarom i krađom ova nova tehnologija morala je od svojih začetaka imati dobro riješenu sigurnost. Mikroprocesorske pametne kartice imaju vrlo dobro riješene sklopovske sigurnosne aspekte, dok programski sigurnosni aspekti prvenstveno ovise oprogrameru koji stvara kartične aplikacije. Ovo znatno otežava i produljuje razvoj kartičnih aplikacija i ukazuje na potrebu razvijanja zasebnih programskih modula koji bi se brinuli o sigurnosti i bili transparentni aplikacijama.

Cilj ovog rada bio je razviti jedan takav programski modul koji bi pružao transparentnu sigurnost između aplikacije na terminalu i kartične aplikacije. Razvijen programski modul je korišten na primjeru implementacije Java pametne kartice kao napredne zdravstvene iskaznice (Pametna zdravstvena iskaznica).

Rad sadrži opis ostvarenog modula i svih korištenih mehanizama.

2. Pametne kartice

2.1 Što su pametne kartice?

Pametne kartice su plastične kartice koje imaju ugrađeni čip. Prve pametne kartice su se pojavile 1984. u Francuskoj, 14. godina nakon što je ideju patentirao dr. Kunitaka Arimura. Slika 2.1. prikazuje osnovnu podjelu kartica.

Od njihova početka, pametne kartice se koriste u mnoge svrhe kao što su: telefonske čip kartice, GSM SIM kartice, kartice za skladištenje podataka itd... Pametne kartice dijelimo na memorijske i mikroprocesorske.

Memorijske kartice susrećemo svakodnevno u obliku telefonskih čip kartica, GSM SIM kartica u današnjim mobilnim telefonima ili kartica u raznim MP3 player-ima i digitalnim fotoaparatima.

Pametne kartice s mikroprocesorom su danas vrlo rijetke i skupe, ali s najviše mogućnsti te će biti predmet daljnjeg razmatranja.

Pametne kartice su malo računalo bez ulazno izlaznih naprava. Imaju mikroprocesor, ponekad kriptografski koprocesor, trajnu memoriju (engl. Read Only Memory - ROM), izbrisljivu memoriju (engl.Electronically Erasable Programmable ROM – EEPROM) koja preuzima funkciju tvrdog diska, radnu memoriju (engl. Random Access Memory - RAM) i standardiizirano sučelje za komunikaciju s vanjskim svijetom. Mikroprocesorske pametne kartice se danas najviše koriste u bankarstvu, npr. American Blue kartica (slika 2.4.).

2.2. Kako izgledaju pametne kartice?

Pametne kartice najčešće dolaze u tri formata : ID-0 (85.6mm x 54mm x 0.76mm), ID-00 (66mm x 33mm x 0.76mm ) i ID-000 (25mm x 15 mm x 0.76mm). ID-0 (slika 2.5.) je format kreditnih kartica, a ID-000 je format GSM SIM kartica. Format ID-0 je najčešći te ga osim kod kreditnih kartica (slika 2.4.) susrećemo kod osobnih iskaznica (slika 2.6.).

2.2.1. Kontaktne pametne kartice

Kontaktne pametne kartice komuniciraju s okolinom putem fizičkog komunikacijskog sučelja koje čini 8-pinski metalni kontakt prema ISO 7816-2 standardu (slika 2.2.).

Slika 2.2. Metalni kontakt pametnih kartica

Kontakti i raspored su prikazani na slici 2.3.

Slika 2.3. Raspored 8-pinskog kontakta pametnih kartica

Kontakti su sljedeći:

• Vcc – napajanje 3V ili 5V s dozvoljenim odstupanjem od 10%

• Vpp – napajanje koje se koristilo kod starijih modela

• Ground – referentna naponska razina (najčešće 0V)

• Reset – signal za tzv. topli reset (hladni je ponovno umetanje kartice)

• Clock – signal vremenskog vođenja

• I/O - obostrani (ne istovremeni) prijenos podataka

• RFU - engl. Reserved for Future Use – rezervirano

Pristup kontaktnim pametnim karticama se ostvaruje uređajem za prihvat kartica (engl. card acceptance device – CAD). Primjer jednog takvog uređaja je čitač pametnih kartica (slika 2.7.).

Slika 2.7. Čitač pametnih kartica

2.2.2. Bezkontaktne pametne kartice

Bezkontaktne pametne kartice nemaju kontakt već imaju skrivenu antenu pomoću koje komuniciraju s okolinom (slika 2.8.). Napajanje je ostvareno pomoću baterije ugrađene u karticu ili se elektromagnetskom indukcijom u anteni inducira sav napon potreban za njezin rad. Podaci se do CAD uređaja prenose elektromagnetskim valovima.

Bezkontaktne pametne kartice su osjetljivije na torzije od kontaktnih. Također postoji potencijalna opasnost da se bez znanja vlasnika presretnu podaci ili izvedu neke kartične transakcije.

Slika 2.8. Troslojna građa bezkontaktne pametne kartice

2.3. Sigurnost pametnih kartica

2.3.1. Sigurnosna svojstva sklopovlja pametnih kartica

Sklopovi pametnih kartica se nikad ne proizvode od standardnih ćelija i često posjeduju lažne strukture čija je jedina svrha zbunjivanje potencijalnog napadača. Sabirnice unutar pametne kartice koje povezuju procesor, ROM, EEPROM i RAM su interne sabirnice, što znači da nikad ne izlaze iz čipa. Time je onemogućeno direktno priključivanje na linije sabirnice. Kako bi se spriječilo bezkontaktno prisluškivanje ili interakcija s podacima na sabirnici, promet preko sabirnica često se kriptira, a sabirničke linije su isprepletene.

Kako se sadržaj ROM-a može čitati bit po bit uz pomoć optičkog mikroskopa, u pametnim karticama se koristi specijalni ionski usađeni ROM čiji se sadržaj ne može pročitati niti uz pomoć ultraljubičaste svjetlosti.

Informacije sakupljene analizom električnog potencijala aktivnog čipa moguće je iskoristiti u svrhu izvođenja zaključaka o trenutnom sadržaju RAM-a. Iznad memorisjkih ćelija smješteni su vodljivi metalnih slojevi. Ako se ti slojevi uklone (npr. kemijskim urezivanjem), čip postaje neupotrebljiv. Osim toga prati se njihov električni otpor tako da čip automatski prestaje s radom ako dođe do oštećenja zaštitnog sloja. Ispod zaštitnih slojeva nalaze se i fototranzistori koji dodatno detektiraju njihovo uklanjanje.

Postoji mogućnost čitanja RAM ćelija bez napajanja, ali to zahtjeva prethodno hlađenje ćelija na temperaturu ispod –60°C. Zbog hlađenja sadržaj RAM ćelija ostaje trajan. Stoga se tajni ključevi ne bi trebali nepotrebno držati u RAM-u. Nakon njihovog pohranjivanja memorija se treba obrisati ili prepisati novim vrijednostima.

U pametnim karticama slijed memorijskih lokacija RAM-a nikada nije linearan kao u ostalim računalnim sustavima. Fizički bliske memorijske ćelije nisu susjedne logičke lokacije. Zbog toga nije dovoljno znati samo sadržaj ćelija već je potrebno znanje i o načinu adresiranja. Način adresiranja može biti unaprijed određen i strogo tajan ili programski riješen i promjenjiv.

Pametne kartice nadziru naponsku razinu kako bi onemogućili DFA (engl. Differential Fault Analysis) napade, frekvenciju radnog takta koja je dovedena izvana kako bi se onemogućilo drastično usporavanje rada kartice čime praćenje internih promijena postaje jednostavnije. Kako bi se onemogućili DPA napadi (engl. Differential Power Analysis) pametne kartice potrošnju električne energije reguliraju i održavaju stalnom.

2.3.2. Sigurna programska svojstva pametnih kartica

S programske strane, pametne kartice također se odlikuju zavidnom razinom sigurnosti. Kao što je opisano u odlomku 2.3.1., vrlo je teško iz pametne kartice “izvući” korisne informacije, što odmah upućuje na mogućnost prisluškivanja informacija koje kartica prima ili odašilje. Dok su gore navedene sklopovske zaštite implementirane u tvornici i ne mogu se isključiti, programska zaštita najviše ovisi o programeru koji implementira kartične aplikacije. Mikroprocesorske pametne kartice dijelimo na one s kripto-koprocesorom i one bez kripto-koprocesora.Kripto-koprocesor je sklopovska podrška kriptiranju. Neke pametne kartice podržavaju samo simetrične kripto-algoritme (najčešće DES), bolje kartice podržavaju još i asimetrične (najčešće RSA), a najbolje još i funkcije za izračunavanje sažetka (engl. Digest ili engl. Hash). Ovisno o vrsti kartice postoji standardizirano programsko sučelje koje omogućuje iskorištavanje implementiranih kripto algoritama. Pametne kartice koje nemaju kripto-koprocesor zahtjevaju od programera, koji želi stvoriti sigurni komunikacijski kanal, samostalno programsko implementiranje potrebnih algoritama ili nabavu nekih drugih implementacija. Radi velike ograničenosti memorijskog prostora na pametnim karticama (tipično 32 KiB ROM-a, 16 KiB EEPROM-a i 1 KiB RAM-a), često se ne implementiraju svi potrebni algoritmi čime se znatno umanjuje sigurnost pametnih kartica. Zbog toga se, za bilo kakvu primjenu u kojoj je potrebna veća razina sigurnosti, pametne kartice bez kripto-koprocesora ne upotrebljavaju.

3. Java pametne kartice

Rastom tržišta pametnih kartica postalo je potrebno “brzo” i “jednostavno” razvijati kartične aplikacije koje bi trebale biti u “duhu” pametnih kartica – sigurne. Jedna tehnologija se nametala kao vrlo pogodna, Java! Java programi se prevode iz izvornog teksta programa u sklopovski neovisan međukôd, Java Byte kôd. Java Byte kôd se izvodi u virtualnom stogovnom stroju (engl. Java Virtual Machine - JVM). Ideja je bila odrediti podskup jezika Java koji bi se mogao izvoditi na samoj pametnoj kartici. Taj podskup je definiran Java Card platformom.

3.1. Java Card platforma

Java Card platforma sastoji se od tri dijela:

1. Java Card Virtual Machine (JCVM) - definira podskup programskog jezika Java i definiciju virtualnog stogovnog stroja,

2. Java Card Runtime Enviroment (JCRE) - opisuje Java Card izvršnu okolinu, upravljanje memorijom, kartičnom aplikacijom (engl. Java Card appletom, negdje Java cardlet - dalje u tekstu applet) i druge izvršne osobine,

3. Java Card Application Programming Interface (API) - opisuje jezgru i Java pakete (engl. package) i razrede (engl. class) potrebne za programiranje kartičnih aplikacija.

Slika 3.1. prikazuje osnovnu strukturu Java Card platforme.

Slika 3.1. Osnovna struktura Java Card platforme

3.1.1. Java Card virtualni stogovni stroj

Java Card virtualni stogovni stroj podijeljen je na dva dijela:

• prvi dio koji se ne izvodi na kartici i obavlja vremenski zahtjevnije zadatke kao što su provjera Java Byte kôda, povezivanje, optimizacija, učitavanje razreda i slično,

• drugi dio koji se izvodi na kartici i obavlja samo izvođenje Java Byte kôda.

JCVM definira podskup Java programskog jezika po broju i složenosti paketa i po broju podržanih primitivnih tipova (engl. value type) podataka. Nepodržane osobine Jave su:

• primitivni tipovi: long, float, double, char, String

• višedimenzionalna polja

• dinamičko učitavanje razreda

• upravljanje sigurnošću (engl. security manager)

• dinamičko upravljanje memorijom (engl. finalization i engl. garbage collection)

• dretve(engl. threads)

• serijalizacija objekata (engl. object serialization)

• kloniranje objekata

3.1.2. Java Card izvršna okolina

Jedno od najznačajnijih obilježja Java Card izvršne okoline je da omogućuje neovisnost kartične aplikacije od operacijskog sustava pametne kartice. Sve što je bitno programeru kartične aplikacije je da postoji JCRE koji sadrži JCVM koji će izvoditi njegov applet i preko kojega se uz pomoć dobro definiranog programskog sučelja (API) pristupa sredstvima pametne kartice.

3.1.3. Java Card API

Java Card programsko sučelje definira standardizirano sučelje za programiranje appleta. Java Card API inačica 2.1.1 definira pakete navedene u tablici 3.1.

Tablica 3.1. Java Card 2.1.1 API paketi

Kako je ovdje predmet razmatranja sigurnost i sigurnosni mehanizmi u daljem tekstu biti će opisani paketi javacard.security ijavacardx.crypto. Treba naglasiti da se u sljedećim poglavljima nalazi samo opis mogućnosti određen Java Card specifikacijom i da stvarna Java pametna kartica ne mora nužno implementirati sve ove mogućnosti.

3.1.3.1. Paket javacard.security

Sadrži razrede, sučelja i iznimke koje sadrže javno dostupnu funkcionalnost potrebnu za implementaciju osnovnog skupa sigurnosnih i kriptografskih alata za Java Card platformu. Razredi u paketu javacard.security pružaju definiciju algoritama koji obavljaju sigurnosne i kriptografske funkcije kao što su:

• implementacija raznih kriptografskih ključeva (DES, DSA i RSA),

• mogućnost stvaranja (razred KeyBuilder) ključeva (DES/64, Triple DES/128/192,DSA/512/768/1024 i RSA/512/768/1024/2048),

• izračunavanjekriptografskog sažetka poruke (razred MessageDigest) pomoću nekoliko algoritama (MD5, RIPEMD-160 i SHA),

• generiranje slučajnih brojeva (razred RandomData),

• digitalno potpisivanje (razred Signature) pomoću cijelog niza kombinacija algoritama (DES/MAC4, DES/MAC8, DSA/SHA, RSA/MD5, RSA/RIPEMD160 i RSA/SHA).

Paketjavacard.securitysadrži sučelja, razrede i iznimke opisane u tablicama 3.2,3.3 i 3.4.

Tablica 3.2. Sučelja javacard.security paketa

Tablica 3.3. Razredi javacard.security paketa

Tablica 3.4. Iznimke javacard.security paketa

3.1.3.2. Paket javacardx.crypo

Paket koji sadrži funkcionalnost, koja može biti podložna pravilima izvoza, potrebnu za implementaciju osnovnog skupa sigurnosnih i kriptografskih alata za Java Card platformu. Razredi koji sadrže sigurnosnu i kriptografsku funkcionalnost, a nisu podložni pravilima izvoza nalaze se u paketu javacard.security. Paket javacardx.crypto sadrži razred Cipher i sučelje KeyEncryption.

Tablica 3.5. Sučelja javacardx.crypto paketa

Tablica 3.6. Razredijavacardx.crypto paketa

Razred Cipher pruža metode za kriptiranje i dekriptiranje poruka pomoću niza algoritama u raznim načinima rada sa više načina nadopune.

• DES/Triple DES u CBC (engl. Cipher Block Chaining ) načinu rada sa nadopunom prema prvoj metodi definiranoj sa ISO 9797,

• DES/Triple DES u CBC načinu rada sa nadopunom prema drugoj metodi definiranoj sa ISO 9797 (ISO 7816-4, EMV'96),

• DES/Triple DES u CBC načinu rada bez implicitne nadopune,

• DES/Triple DES u CBC načinu rada sa nadopunom prema PKCS#5 (engl. Password-Based Cryptography Standard),

• DES/Triple DES u ECB (engl. Electronic Codebook) načinu rada sa nadopunom prema prvoj metodi definiranoj sa ISO 9797,

• DES/Triple DES u ECB načinu rada sa nadopunom prema drugoj metodi definiranoj sa ISO 9797 (ISO 7816-4, EMV'96),

• DES/Triple DES u ECB načinu rada bez implicitne nadopune,

• DES/Triple DES u ECB načinu rada sa nadopunom prema PKCS#5,

• RSA sa nadopunom prema ISO 14888,

• RSA sa nadopunom prema ISO 9796 (EMV'96),

• RSA bez implicitne nadopune,

• RSA sa nadopunom prema PKCS#1 (v1.5) (engl. RSA Cryptography Standard).

4. Java platforma

Java platforma sadrži mnoge pakete koji omogućuju sigurnu komunikaciju. Osnovna podjela sigurnosnih mehanizama Java platforme od inačice 1.4.1 je:

1. Osnovna sigurnost (engl. General Security),

2. Certifikacijski putevi (engl. Certification Path),

3. Java^TM Secure Socket Extension (JSSE),

4. Java^TM Authentication and Authorization Service (JAAS),

5. Java^TM Generic Security Services (JGSS),

6. Java^TM Cryptography Extension (JCE).

4.1. Osnovna sigurnost

Osnovnu sigurnost čine sljedeći paketi:

• java.security,
• java.security.cert,
• java.security.interfaces,
• java.security.spec.

4.1.1. Paket java.security

Paket java.security pruža osnovni skup razreda i sučelja potreban za implementaciju sigurnosti.

Uključuje:

• razrede koji implementiraju lako ostvarivu, sitno zrnatu, arhitekturu kontrole pristupa,

• podršku za generiranje i spremanje parova asimetričnih kriptografskih ključeva kao i niz kriptografskih operacija koji nemaju ograničenja izvoza kao što su generiranje kriptografskih sažetka i digitalnih potpisa,

• razrede koji podržavaju potpisane/čuvane objekte te generiranje kriptografski sigurnih pseudo slučajnih brojeva.

Veliki broj razreda (pogotovo onih kriptografskih i za generiranje pseudo slučajnih brojeva) predstavljaju samo programsko sučelje bez stvarne implementacije pojedinih algoritama. Implementacija se ostavlja nekoj trećoj stranki. Zbog toga se razredima koji koriste određene algoritme predaju imena tih algoritama kao znakovne konstante. Java 2 SDK Security API zahtjeva i koristi skup standardnih imena za algoritme, digitalne certifikate i repozitorije ključeva i digitalnih certifikata, ali to ne sprečava neku treću stranku da implementira neki novi algoritam i definira vlastito ime za njega. Na taj naćin omogućena je jednostavna nadogradnja sigurnosnih mehanizama Java platforme.

Java 2 SDK Security API definira sljedeći skup imena:

• za generiranje kriptografskih sažetka: MD2, MD5,SHA-1, SHA-256, SHA-384, SHA-512,

• za generiranje para asimetričnih ključeva: RSA, DSA,Diffie-Hellman,

• za generiranje digitalnih potpisa: MD2withRSA,MD5withRSA, SHA1withDSA, SHA1withRSA,

• za generiranje kriptografski sigurnih pseudo slučajnih brojeva: SHA1PRNG,

• za digitalne certifikate X.509,

• za repozitorij ključeva: JKS, PKCS12.

Tablice4.1, 4.2, 4.3 prikazuju neka zanimljivija sučelja, razrede i iznimke paketa java.security.

Tablica 4.1. Zanimljivija sučelja java.security paketa

Tablica 4.2. Zanimljiviji razredi java.security paketa

Tablica 4.3. Zanimljivije iznimke java.security paketa

4.1.2. Paket java.security.cert

Pruža razrede i sučelja potrebne za parsiranje i korištenje digitalnih certifikata (engl. digital certificate), lista opozvanih certifikata (engl. certificate revocation lists – CRL), certifikacijskih puteva (engl. certificate path, certificate chain) te repozitorija digitalnih certifikata i CRL-ova. Sadrži podršku za treću inačicu X.509 digitalnih certifikata i drugu inačicu X.509 CRL-a. Java 2 SDK Security API ne podržava generiranje digitalnih certifikata već samo čitanje i spremanje već generiranih. Uz standardnu instalaciju Java 2 (RE,SDK, JDK,...) dobije se i konzolni program keytool koji omogućuje stvaranje samo-potpisanih digitalnih certifikata (digitalni certifikat koji sadrži korisnikov javni ključ potpisan sa korisnikovim privatnim ključem), njihovo spremanje u datoteku koja predstavlja repozitorij digitalnih certifikata (KeyStore), generiranje zahtjeva za potpisivanje digitalnog certifikata (engl. Certificate Signing Request – CSR), te uvoz digitalnog certifikata od nekog certifikacijskog centra (engl. Certificate Authority - CA). Java 2 SDK Security API ima ugrađenu podršku za dvije vrste repozitorija digitalnih certifikata i CRL-ova: “LDAP” i “Collection”.

Tablice 4.4, 4.5,4.6 prikazuju neka zanimljivija sučelja, razrede i iznimke paketa java.security.cert.

Tablica 4.4. Zanimljivija sučelja java.security.cert paketa

Tablica 4.5. Zanimljiviji razredi java.security.cert paketa

Tablica 4.6. Zanimljivije iznimke java.security.cert paketa

4.1.3. Paket java.security.interfaces

Pruža sučelja za generiranje RSA (engl. Rivest, Shamir i Adleman) ključeva definiranih prema PKCS#1 i DSA (engl. Digital Signature Algorithm) ključeva prema FIPS-186 (engl. Federal Information Processing Standards).

4.1.4. Paket java.security.spec

Pruža razrede i sučelja za specifikaciju ključeva i parametara raznih algoritama. Specifikacija ključeva je transparentna reprezentacija materijala koji predstavlja ključ. Ključ može biti specificiran ovisno o algoritmu ili neovisno o algoritmu u nekom zapisnom formatu npr. ASN.1 (engl. Abstract Syntax Notation One). Ovaj paket sadrži specifikacije DSA i RSA javnih i privatnih ključeva, PKCS#8 privatnih ključeva u DER (engl. Distinguished Encoding Rules) zapisnom formatu i X.509 javne i privatne ključeve u DER zapisnom formatu. Specifikacija parametara algoritama je transparentna reprezentacija skupa parametara korištenih u nekom algoritmu. Ovaj paket sadrži specifikaciju parametara DSA algoritama.

4.1.5. Davatelji kriptografskih usluga

Prema Java kriptografskoj arhitekturi (engl. Java Cryptography Architecture - JCA) postoji samo niz apstraktnih razreda i sučelja koji omogućuju rad s kriptografskim algoritmima, ali ne pružaju samu implementaciju. Implementacija kriptografskih algoritama prepuštena je drugim tzv. “davateljima kriptografskih usluga” (engl. Java^TM Cryptographic Service Provider). Termin “Cryptographic Service Provider” ili samo “provider” koristi se i kao ime niza paketa koji implementiraju te mehanizme.

Postoje mnogi davatelji. Između ostalog i sama tvrtka Sun. Sun s Javom daje svog davatelja – SUN. SUN je besplatan i dolazi inicijalno s Javom 2 SDK inačica 1.4, ali podržava relativno malo sigurnosnih mehanizama. SUN podržava sljedeće mehanizme i algoritme sa sljedećim ograničenjima:

• za asimetrične algoritme: DSA prema NIST FIPS 186,

• za izračunavanje kriptografskog sažetka: MD5 prema RFC 1321, SHA-1 NIST FIPS 180-1,

• za generiranje asimetričnih ključeva: DSA,

• za generiranje kriptografski sigurnih pseudo slučajnih brojeva: SHA1PRNG prema preporuci u IEEE P1363 standardu,

• za certifkacijske puteve: PKIX prema “Internet X.509 Public Key Infrastructure Certificate” i “CRL Profile”

• za repozitorij digitalnih certifikata i CRL-ova: Collection, LDAP koristeći “PKIX LDAP V2 Schema” (RFC 2587),

• za digitalne certifikate i CRL-ove: X.509,

• za repozitorij ključeva: JKS.

Kako bi se određeni davatelj mogao koristiti mora se instalirati i registrirati.

4.1.6. Instalacija i registracija Java davatelja

Instalacija se obavlja ili presnimavanjem JAR (engl. Java Archive) datoteke koja sadrži “davatelja” u <JavaRE-home>\lib\ext direktorij ili stavljanjem dotične datoteke u putanju razreda (engl. class path). Registracija može biti statička ili dinamička. Statička registracija se obavlja izmjenom <JavaRE-home>/lib/security/java.security datoteke tako da se doda jedna “security.provider.n=imeGlavnogRazredaDavatelja” linija za novog davatelja, gdje je broj n broj za jedan veći od broja u zadnjoj takvoj liniji (n ujedno označava prioritet prilikom pretraživanja, manji broj znači veći prioritet). Dinamička registracija se obavlja iz samog Java programa pomoću metoda “addProvider” ili “insertProviderAt” razreda Security. Ova vrsta registracije nije trajna i može biti obavljena samo iz Java programa kojem je eksplicitno dopušteno direktivom :

java.security.SecurityPermission "insertProvider.{ime}",

gdje je {ime} ime stvarnog davatelja. Na primjer ako se davatelj zove “MojNajdražiDavatelj” i ako se izvorni tekst programa koji dinamički registrira ovog davatelja nalazi u MojApp.jar datoteci u direktoriju /lokalniPosao, onda se u datoteci
<JavaRE-home>/lib/security/java.policy treba nalaziti sljedeća naredba eksplicitne dozvole dinamičke registracije :

grant codeBase "file:/lokalniPosao/MojApp.jar" {
  permission java.security.SecurityPermission
   "insertProvider.MojNajdražiDavatelj";
};

Jednom instaliran i registriran davatelj se može eksplicitno koristiti tako da se pri pozivu metoda getInstance (metode koje obavljaju funkcije konstruktora), razreda za generiranje ključeva, kriptografskih sažetaka, digitalnih potpisa, metoda za kriptiranje/dekriptiranje, itd..., navede točno koji davatelj se želi koristiti. Ukoliko se ne navede Java RE koristi davatelja sa najvećim prioritetom (najmanji n) ukoliko on podržava traženi mehanizam. Ukoliko traženi mehanizam nije podržan sa davateljem koji ima najveći prioritet onda se pretražuju ostali registrirani poslužitelji sve dok se na pronađe adekvatni. Ako adekvatni davatelj nije po nađen baca se iznimka java.security.NoSuchAlgorithmException. Svaki Java program može koristiti proizvoljan broj davatelja bez ograničenja, eksplicitnim navođenjem davatelja ili automatskim pronalaženjem odgovarajućega.

4.2. Certifikacijski putevi

Sučelja, razredi i iznimke za rad sa certifikacijskim putevima su prikazani u tablicama 4.7, 4.8, 4.9.

Tablica 4.7. Sučelja za rad sa certifikacijskim putevima

Tablica 4.8. Razredi za rad sa certifikacijskim putevima

Tablica 4.9. Iznimke za rad sa certifikacijskim putevima

Certifikacijski putevi nisu korišteni u implementaciji sigurnosnih mehanizama napredne zdravstvene iskaznice (pametna zdravstvena iskaznica, dalje u tekstu PZI) zato što je hijerarhija certifikata iznimno plitka (2 razine).

4.3. Java^TM Secure Socket Extension

Java^TM Secure Socket Extension predstavlja implementaciju SSL (engl. Secure Sockets Layer) i TLS (engl. Transport Layer Security) protokola čime omogućuje sigurnu Internet komunikaciju. Omogućuje kriptiranje podataka, autentifikaciju poslužitelja, očuvanje i provjeru integriteta poruka i neobveznu autentifikaciju klijenta. Koristeći JSSE programer može pružiti sigurnu komunikaciju, povrh TCP protokola, između klijenta i poslužitelja neovisno o aplikacijskom protokolu (HTTP, Telnet, FTP,...) koji se koristi. JSSE je postao sastavni dio Java^TM 2 SDK Standard Edition platforme od inačice 1.4.

JSSE implementacija koja dolazi s Java^TM 2 SDK Standard Edition 1.4 platformom pruža “jaku” kriptografiju, ali zbog izvoznih pravila SAD-a (Sjedinjene Američke Države) ne dopušta zamjenu sa alternativnim SSL/TLS implementacijama.

JSSE nije korišten u implementaciji sigurnosnih mehanizama PZI.

4.4. Java^TM Authentication and Authorization Service

JAAS se može koristiti za potrebe autentifikacije korisnika tj. pouzdano i sigurno određivanje tko trenutno izvodi Java kôd i za autoriziranje korisnika tj. provjeravanje da li korisnik ima potrebne dozvole za obavljanje određene operacije.

JASS nije korišten u implementaciji sigurnosnih mehanizama PZI.

4.5. Java^TM Generic Security Service

Java GSS-API se koristi za sigurnu razmjenu poruka među aplikacijama. GSS-API omogućuje aplikacijskom programeru jedinstven pristup sigurnosnim uslugama povrh čitavog niza sigurnosnih mehanizama uključujući i Kerberos.

GSS nije korišten u implementaciji sigurnosnih mehanizama PZI.

4.6. Java^TM Cryptography Extension

JCE pruža mogućnosti kriptiranja podataka, generiranje simetričnih kriptografskih ključeva, sjedničke razmjene ključeva te generiranje MAC-ova (engl. Message Authentication Code). Podrška za kriptiranje podataka uključuje simetričnu i asimetričnu kriptografiju, blokovsko orijentirano kriptiranje i kriptiranje toka podataka (oktetno orijentirano).

JCE se sastoji od tri paketa:

• javax.crypto,
• javax.crypto.interfaces,
• javax,crypto.spec.

4.6.1. Paket javax.crypto

Pruža razrede i sučelja potrebne za kriptografske operacije kao što su kriptiranje, generiranje simetričnih ključeva, sjedničke razmjene ključeva, te generiranje MAC-ova. Podrška za kriptiranje podataka uključuje simetričnu i asimetričnu kriptografiju, blokovsko orijentirano kriptiranje i kriptiranje toka podataka (oktetno orijentirano). Ovaj paket omogućuje korištenje sigurnih tokova podataka i zapečaćenih objekata. Zanimljivija sučelja, razredi i iznimke prikazani su tablicama 4.10,4,11 i 4.12.

Tablica 4.10. Sučelja paketa javax.crypto

Tablica 4.11. Zanimljiviji razredi paketa javax.crypto

Tablica 4.12. Zanimljivije iznimke paketa javax.crypto

Razredi predstavljaju samo programsko sučelje bez stvarne implementacije pojedinih algoritama. Implementacija se ostavlja nekoj trećoj stranki. Zbog toga se razredima koji koriste određene algoritme predaju imena tih algoritama kao znakovne konstante. Java 2 SDK Security API zahtjeva i koristi skup standardnih imena za algoritme, načine kriptiranja, mehanizme nadopune, protokole razmjene ključeva, generiranje ključeva i MAC-ova, ali to ne sprečava neku treću stranku da implementira neki novi algoritam i definira vlastito ime za njega. Na taj način omogućena je jednostavna nadogradnja sigurnosnih mehanizama Java platforme. Java 2 SDK Security API definira sljedeći skup imena:

• za generiranje kriptografskih algoritama: AES,Blowfish,DES, DESede, PBEWith<algoritamSažimanja>And<kriptoAlgoritam> ili PBEWith<generatorPseudoSlučajnihBrojeva>And<kriptoAlgoritam> (npr. PBEWithMD5AndDES, PBEWithHmacSHA1AndDESede) RC2, RC4, RC5, RSA,

• za način kriptiranja: NONE, CBC,CFB, ECB, OFB, PCBC

• za mehanizam nadopune: NoPadding, OAEPWith<algoritamSažimanja>And<funkcijaGeneriranjaMaske>Padding,PKCS5Padding, SSL3Padding,

• za protokole razmjene ključeva: DiffieHellman,

• za generiranje simetričnih ključeva: AES,Blowfish,DES, DESede, HmacMD5, HmacSHA1,

• za stvaranje ključeva sa SecretKeyFactory: AES,DES, DESede, PBEWith<algoritamSažimanja>And<kriptoAlgoritam> ili PBEWith<funkcijaGeneriranjaMaske>And<kriptoAlgoritam>,

• za MAC: HmacMD5, HmacSHA1,PBEWith<mac>.

4.6.2. Paket javax.crypto.interfaces

Pruža sučelja za Diffie-Hellman ključeve definirane sa PKCS#3.

4.6.3. Paket javax.crypto.spec

Pruža razrede i sučelja za specifikaciju ključeva i parametara raznih algoritama. Specifikacija ključeva je transparentna reprezentacija materijala koji predstavlja ključ. Ključ može biti specificiran ovisno o algortimu ili neovisno o algoritmu u nekom zapisnom formatu npr. ASN.1. Ovaj paket sadrži specifikacije Diffie-Hellman javnih i privatnih ključeva, DES, Triple DES i PBE tajnih ključeva (kriptiranje zasnovano na zaporci, engl. Password-Based Encryption). Specifikacija parametara algoritama je transparentna reprezentacija skupa parametara korištenih u nekom algoritmu. Ovaj paket sadrži specifikaciju parametara Diffie-Hellman, DES, Triple DES, PBE, RC2 i RC5 algoritama.

4.6.4. Davatelji Java kriptografskih proširenja

JCE je podložan izvoznim pravilima SAD-a. U Javi 1.4 postoji “jaka”, ali ograničena kriptografska podrška koja, za razliku od prošlih verzija Jave, ima dinamičku politiku. Dinamička politika znači da više nema nekoliko izdanja Jave ovisno o mjestu prebivališta već jedna jedinstvena, koja ovisno o “java.policy” datoteci, pruža više ili manje kriptografskih algoritama. Kako bi se mogli koristiti svi kriptografski algoritmi koji su navedeni u Java specifikaciji (vidi [3]), potrebno je s http://java.sun.com/products/jce/index-14.html skinuti “policy” datoteke s neograničenom jačinom (engl. unlimited strength).

Prema Java specifikaciji postoji samo niz apstraktnih razreda i sučelja koji omogućuju rad s kriptografskim algoritmima, ali ne i sama implementacija. Implementacija kriptografskih algoritama prepuštena je drugim tzv. “davateljima Java kriptografskih proširenja” (engl. Java^TM Cryptography Extension Provider – JCE Provider). Termin “JCE Provider” koristi se i kao ime niza paketa koji implementiraju JCE.

Postoje mnogi davatelji JCE-a. Između ostalog i sama tvrtka Sun. Sun s Javom daje svoj JCE Provider – SunJCE. SunJCE je besplatan i dolazi inicijalno s Java 2 SDK 1.4 platformom, ali podržava relativno malo kripto algoritama sa ograničenim veličinama ključeva. SunJCE podržava sljedeće algoritme sa sljedećim ograničenjima:

• simetrični ključevi: DES/56, Triple DES/112/168, Blowfish/32/40/48/.../448, AES/128/192/256,

• za kriptiranje zasnovano na zaporkama: PBEWithMD5AndDES,PBEWithHmacSHA1AndDESede

• MAC: HmacMD5/64, HmacSHA1/64,

• asimetrični: DiffieHellman/512/576/640/.../1024.

Primjer jednog besplatnog, ali vrlo moćnog, davatelji JCE-a je “The Legion Of The Bouncy Castle” (http://www.bouncycastle.org).

Kako bi se određeni davatelj JCE-a mogao koristiti mora se instalirati i registrirati (vidi poglavlje 4.1.3 Instalacija i registracija Java davatelja).       

5. Sigurnosni mehanizmi pametne zdravstvene iskaznice

Za potrebe sigurne komunikacije između terminala pametne zdravstvene iskaznice (dalje u tekstu T-PZI) i kartične aplikacije (Java Card applet) pametne zdravstvene iskaznice (dalje u tekstu A-PZI) ostvareni je niz razreda i sučelja prikazanih bijelom bojom na UML razrednom dijagramu (engl. UML class diagram) sustava pametne zdravstvene iskaznice (slika 5.1).

Slika 5.1. UML razredni dijagram sustava pametne zdravstvene iskaznice

Sigurnosni mehanizmi PZI su podijeljeni u dva Java paketa:

• hr.fer.zemris.diplomski.pametnaZdravstvenaIskaznica,
• hr.fer.zemris.diplomski.terminalPZI.
  

5.1. Paket pametnaZdravstvenaIskaznica

Paket pametnaZdravstvenaIskaznica sadrži jedno sučelje SuceljeSigurnosti i jedan razred UslugaSigurnosti koji ostvaruju sigurnost.

5.1.1. Sučelje SuceljeSigurnosti

SučeljeSuceljeSigurnosti predstavlja zajedničko sučelje za terminal i applet i definira bitne konstante za rad sigurnosnih mehanizama, kao što su:

• kôdovi razreda ADPU zaglavlja (oktet u skladu sa ISO 7816-4),

• kôdovi instrukcija ADPU zaglavlja (oktet u skladu sa ISO 7816-4),

• veličina PIN-a (8-bitni broj u dvojnom komplementu),

• statusne riječi (16-bitni broj u skladu sa ISO 7816-4).

5.1.2. Razred UslugaSigurnosti

Razred UslugaSigurnosti implementira sučelje SuceljeSigurnosti i sve sigurnosne mehanizme A-PZI. Razred pruža:

• provjeru konzistentnosti podataka pomoću 16-bitne zaštitne sume (engl. checksum),

• sigurnu razmjenu sjedničkog kriptografskog ključa,

• trorazinsku autorizaciju pomoću PIN-a,

• promjenuPIN-a,

• tajnost podataka kriptiranjem podataka Triple DES simetričnim kriptografskim algoritmom sa 2 ključa (112 bita),

• neporecivost i integritet podataka provjerom i generiranjem digitalnog potpisa (SHA-1/160 bita i RSA/1024 bita),

• digitalno potpisivanje podataka na zahtjev (SHA-1/160 bita i RSA/1024 bita).

Tablice5.1, 5.2 i 5.3 ukratko opisuju ne privatne članove razreda.

Tablica 5.1. Varijable i konstante razreda UslugaSigurnosti

Tablica 5.2. Konstruktori razreda UslugaSigurnosti

resetiraj(byte[] buffer) 

Tablica 5.3. Ne privatne metode razreda UslugaSigurnosti

5.1.2.1. Korištenje razreda UslugaSigurnosti

Kako bi se koristio razred UslugaSigurnosti potrebno je jednim od konstruktora stvoriti primjerak razreda. Opisi konstruktora se nalaze u tablici 5.2. Prvi konstruktor (podrazumijevani) jednostavno poziva drugi na način prikazan slikom 5.2.

Slika 5.2. Podrazumijevani konstruktor razreda UslugaSigurnosti

Podrazumijevani konstruktor inicijalizira PIN korisnika kartice na unaprijed određenu vrijednost “11223344”.

Konstruktor UslugaSigurnosti(byte[] PIN, short offset, byte duljina) inicijalizira sve sigurnosne mehanizme (PIN, kriptiranje, generiranje kriptografskih sažetaka i stvaranje generatora pseudo slučajnih brojeva) te stvara objekte koji će sadržavati sve potrebne kriptografske ključeve (slika 5.3). PIN-ovi izdavača kartice i izdavača kartične aplikacije se inicijaliziraju redom na unaprijed definirane vrijednosti 87654321 i 12345678. Razred UslugaSigurnosti koristi sljedeće kriptografske algoritme i ključeve:

• za simetrično kriptiranje: Triple DES u CBC načinu rada sa nadopunom prema drugoj metodi definiranoj sa ISO 9797 (ISO 7816-4, EMV'96),

• 112 bitni Triple DES ključ (dva DES ključa),

• za asimetrično kriptiranje: RSA sa nadopunom prema PKCS#1 (v1.5),

• 1024 bitni RSA ključ,

• za kriptografske sažetke: SHA.

Slika 5.3. Osnovni konstruktor razreda UslugaSigurnosti

Javno sučelje razreda UslugaSigurnosti sastoji se od 8 metoda:

• Autoriziraj(short),

• isAuthenticated(short),

• isChannelSecure(byte),

• isCommandSecure(byte),

• postprocesirajAPDU(byte[]),

• predprocesirajAPDU(byte[]),

• procesirajAPDU(byte[]),

• resetiraj(),

kojekartičnoj aplikaciji pružaju potpuno transparentnu sigurnost, ali bez mogućnosti uplitanja u rad sigurnosnih mehanizama.

Javno dostupne metode možemo podijeliti u tri skupine:

• metode za procesiranje ADPU naredbi:

• predprocesirajAPDU(byte[]),

• procesirajAPDU(byte[]),

• postprocesirajAPDU(byte[]),

• metode za ispitivanje određenih uvjeta
  

• Autoriziraj(short),

• isAuthenticated(short),

• isChannelSecure(byte),

• isCommandSecure(byte),

• metoda za poništavanje sigurnosnog komunikacijskog kanala:

• resetiraj().

5.1.2.2. Metoda predprocesirajAPDU

Metoda predprocesirajAPDU(byte[]) provjerava i miče 16-bitnu zaštitnu sumu, te potom ako je uspostavljen sigurni komunikacijski kanal obavlja dekriptiranje pristigle APDU naredbe ili provjerava digitalni potpis, ovisno da li je pristigla kriptirana naredba ili digitalni potpis.

Zaštitna suma je 16-bitna suma svih okteta podatkovnog dijela APDU naredbe, osim Lc polja, prikazana u dvojnom komplementu (2'k). Slika 5.4. prikazuje izvorni tekst programa zaštićene (engl. protected) metode

boolean provjeriMakniChecksum(byte [] buffer)

koja provjerava i miče zaštitnu sumu APDU naredbe.

Slika 5.4. Zaštićena metoda provjeriMakniChecksum

Dekriptiranje obavlja metoda zaštićena metoda

void dekriptirajAPDU(byte[] buffer)

čiji je izvorni tekst programa prikazan na slici 5.5.

Slika 5.5. Zaštićena metoda dekriptirajAPDU

Provjeru digitalnog potpisa obavlja privatna metoda

koja prvo na temelju primljenih podataka (podaci) izračunava SHA-1 kriptografski sažetak, potom kriptira sažetak pomoću RSA algoritma s primljenim ključem (kljuc), te na kraju uspoređuje generirani digitalni potpis sa primljenim (potpis).

Metoda predprocesirajAPDU vraća tip boolean kojim ukazuje da li je potrebno dolaznu APDU naredbu dodatno procesirati ili ne. Ako vrati true onda je procesiranje gotovo, što znači da je APDU naredba zapamćena i da se očekuje digitalni potpis. Ukoliko vrati false procesiranje se može nastaviti na nizu koji je predan metodi. Ovaj niz sada sadrži cijelu dekriptiranu ADPU naredbu zajedno sa zaglavljem.

5.1.2.3. Metoda procesirajAPDU

Metoda procesirajAPDU(byte[]) podržava sljedeće funkcije:

• inicijalizacija sigurnosnih mehanizama kartice,

• uspostava sigurnog komunikacijskog kanala,

• provjeraPIN-a,

• promjenaPIN-a,

• potpisivanje podataka.

Ovisno o CLA (razred pripadnosti) i INS (instrukcija) poljima ADPU naredbe pozivaju se razne, inače javno nedostupne, metode (slika 5.6.).

Slika 5.6. Metoda procesirajAPDU razreda UslugaSigurnosti

5.1.2.4. Inicijalizacija sigurnosnih mehanizama

Inicijalizacija sigurnosnih mehanizama se obavlja pomoću metode init(). Inicijalizira se javni i privatni ključ kartice i identifikator kartice (serijski broj digitalnog certifikata).

Za cijeli postupak inicijalizacije potrebne su četiri poruke. Šalje se:

1. Eksponent javnog ključa kartice

2. Eksponent privatnog ključa kartice

3. Modul ključeva kartice

4. Identifikator kartice

Postupak se obavlja samo jednom prije prve upotrebe kartice. Pokušaj reinicijalizacije kartice završiti će greškom.

5.1.2.5. Uspostava sigurnog komunikacijskog kanala

Svrha protokola je dogovor tajnog sjedničkog ključa između terminala i kartice i autentifikacija kartice. Terminal posjeduje svoj javni ključ, svoj privatni ključ i certifikat izdavača kartice. Kartica posjeduje svoj javni ključ, svoj privatni ključ i serijski broj svog digitalnog certifikata. Pretpostavlja se da terminal može na temelju serijskog broja certifikata kartice dohvatiti i provjeriti njen digitalni certifikat. Zbog toga što kartica nema mogućnosti provjere terminala (prvenstveno zato što Java Card platforma ne podržava korištenje digitalnih certifikata), protokol pretpostavlja povjerenje u terminal.

Uspostava sigurnog komunikacijskog kanala se odvija prema sljedećem protokolu koji je inspiriran preporučenim X.509 autentifikacijskim protokolom s tri poruke:

1. Terminal kartici šalje svoj javni ključ (K_E^Terminala ) te jedan 16 bitni slučajni broj N_t (engl. Number used only once – nonce) potpisan svojim privatnim ključem (K_D^Terminala). Slučajan broj se koristi kako bi uveo dodatnu komponentu slučajnosti u protokol i osigurava da poruka nije ponovljena. Digitalnim potpisom osigurava se integritet, autentičnost i neporecivost poruke.

   M₁=[K_E^Terminala, E(N_t,K_D^Terminala)]

2. Kartica pomoću javnog ključa terminala dekriptira N_t. Nakon toga terminalu šalje, kriptirano terminalovim javnim ključem i potpisano svojim privatnim ključem ( K_D^Kartice), N_t, novi 16 bitni slučajni broj N_k i svoj identifikator ID_k, pomoću kojeg će terminal dohvatiti kartičin digitalni certifikat. Kriptiranjem poruke postiže se tajnost, tj. nitko osim terminala ne može doznati sadržaj poruke. Digitalnim potpisom postiže se integritet, autentičnost i neporecivost poruke, tj. terminal može biti siguran da je primljene podatke poslala kartica:

   M₂=[E((N_k, N_t, ID_k),K_E^Terminala), E(H(N_k, N_t, Id_k),K_D^Kartice)]

3. Terminal dekriptira svojim privatnim ključem prvi dio poruke i doznaje N_t', N_k, ID_k. Provjerava N_t' sa N_t koji je on generirao. Ako su slučajni brojevi isti terminal zna da kartica odgovara na zadnje poslanu poruku. Korištenjem slučajnih brojeva onemogućuje se ponavljanje poruka. Na temelju ID_k terminal doznaje kartičin digitalni certifikat iz kojeg saznaje javni ključ kartice (K_E^Kartice ). Pomoću tog ključa provjerava digitalni potpis poruke, a time autentificira digitalni potpis poruke. Terminal potom generira tajni sjednički ključ K i šalje ga kriptiranog javim ključem kartice i digitalno potpisanim svojim privatnim ključem. Šalje i N_k koji je digitalno potpisao svojim privatnim ključem. Kriptiranje sjedničkog ključa s javnim ključem kartice osigurava se da ključ može saznati jedino dotična kartica. Provjerom digitalnog potpisa ključa kartica može biti sigurna da je ključ poslao terminal.

   M₃=[E(N_k,K_D^Terminala), E(K,K_E^Kartice),E(H(K),K_D^Terminala)]

4. Kartica po primitku ove zadnje poruke doznaje N_k' te ga provjerava sa N_k koji je ona generirala. Ako su slučajni brojevi isti kartica zna da terminal odgovara na zadnje poslanu poruku. Doznaje tajni sjednički ključ K koji će koristiti za kriptiranje svih poruka do kraja sjednice.

Slika 5.7. prikazuje opisani protokol.

Slika 5.7. Protokol uspostave sigurnog komunikacijskog kanala

Navedeni protokol je otporan na pasivno prisluškivanje jer napadač ne može saznati tajni sjednički ključ. Napadač može doznati javni ključ terminala (K_E^Terminala), N_t, N_k, H(K) i identifikator kartice (ID_k), koji predstavlja serijski broj digitalnog certifikata kartice.

Što se tiče aktivnih napada kao što je napad čovjekom u sredini (engl. man in the middle), napadač bi mogao “glumiti” terminal kada se obraća kartici (pod uvjetom da napadač može doznati digitalni certifikat kartice na temelju njegovog serijskog broja), jer kartica nema mogućnosti provjere terminala, ali da bi se predstavio pravom terminalu kao kartica morao bi i sam biti u sustavu zdravstva sa valjanim digitalnim certifikatom koji je potpisao dotični osiguravajući zavod. Zbog nemogućnosti kartice da provjeri terminal, lažni terminal bi mogao uspostaviti sigurnu komunikacijski kanal sa karticom. Zato se predpostavlja povjerenje u terminal i ne preporuča korištenje bezkontaktnih kartica.

Navedeni problemi su prisutni samo uz pretpostavku da napadač može doznati digitalni certifikat kartice na temelju njegovog serijskog broja. Ukoliko bi osiguravajući zavod koristio digitalne certifikate svojih osiguranika samo u svrhu pametnih zdravstvenih iskaznica i time ih učinio javno nedostupnim navedeni problemi bi nestali. Naravno ovo bi bilo u suprotnosti s osnovnim načelima digitalnih certifikata koji nalažu javnu dostupnost.

PZI koristi autorizaciju pomoću PIN-a, koju pruža razred UslugaSigurnosti, tako da svaka naredba mora biti adekvatno autorizirana bilo PIN-om korisnika, izdavača kartice ili izdavača kartične aplikacije. Mogući problem koji proizlazi iz korištenja ove vrste autorizacije je sličan problemu koji se često susreće u bankarstvu prilikom korištenja bankomata, tj. svaki korisnik treba biti siguran u autentičnost terminala prije upisivanja PIN-a.

Sustav PZI koristi potpisivanje svih uputnica i recepata tako da niti jedan recept ili uputnica neće biti izdan dok se ne uspostavi da je digitalno potpisan od strane liječnika.

5.1.2.6. Provjera PIN-a

Zaštićena metoda

void provjeriPIN(byte [] buffer)

obavlja funkciju provjere primljenog PIN-a (podatkovni dio APDU naredbe predstavljene sa byte [] buffer) sa tri raspoloživa PIN-a:

• korisnika kartice,

• izdavača kartice,

• izdavača kartične aplikacije.

Ukoliko je primljeni PIN kraći od očekivanog metoda baca iznimku javacard.framework.UserException sa razlogom “KRIVI PIN” definiranim u sučelju SuceljeSigurnosti. Ukoliko primljeni PIN odgovara jednom od PIN-ova metoda uspješno završava i postavlja se određena razina autorizacije koja je prisutna tijekom sjednice. Ukoliko primljeni PIN ne odgovara niti jednom PIN-u umanjuje broj preostalih pokušaja unosa PIN-a korisnika kartice, ukoliko taj PIN nije već zaključan. Ukoliko je zaključan umanjuje se broj pokušaja PIN-a izdavača kartice. Ukoliko je on također zaključan umanjuje se broj pokušaja PIN-a izdavača kartične aplikacije. Na ovaj način uspostavljena je trorazinska autorizacija PIN-om.

5.1.2.7. Promjena PIN-a

Zaštićena metoda

void promijeniPIN(byte [] buffer)

omogućuje promjenu bilo kojeg PIN-a tijekom normalnog rada PZI. Promjena dotičnog PIN-a mora biti autorizirana PIN-om te ili više razine, što omogućuje izdavaču kartice da mijenja PIN korisnika, ali istovremeno onemogućuje korisniku kartice da mijenja bilo koji PIN osim vlastitog. Izvorni tekst programa je prikazan na slici 5.8.

5.1.2.8. Potpisivanje podataka

Zaštićena metoda

void potpisiPodatke(byte [] buffer)

omogućuje digitalno potpisivanje podataka s ključem kartice (slika 5.9).

Slika 5.9. Zaštićena metoda potpisiPodatke

5.1.2.9. Metoda postprocesirajAPDU

Metoda

void  postprocesirajAPDU(byte[])

ako je uspostavljen sigurni komunikacijski kanal obavlja kriptiranje odlaznog APDU odgovora ili generira digitalni potpis (ovisno o fazi odgovora u kojoj se nalazi), te neovisno o sigurnosti komunikacijskog kanala stavlja 16-bitnu zaštitnu sumu na kraj APDU paketa.

Kriptiranje obavlja zaštićena metoda

void kriptirajAPDU(byte[] buffer)

čiji je izvorni tekst programa prikazan na slici 5.10.

Slika 5.10. Zaštićena metoda kriptirajAPDU

Izračunavanje digitalnog potpisa obavlja privatna metoda

koja prvo na temelju primljenih podataka (inBuffer) izračunava SHA-1 kriptografski sažetak, potom kriptira sažetak pomoću RSA algoritma sa primljenim ključem (kljuc).

Zaštitna suma je 16-bitna suma svih okteta podatkovnog dijela APDU odgovora, prikazana u dvojnom komplementu (2'k). Slika 5.11. prikazuje izvorni tekst programa zaštićene (engl. protected) metode

void staviChecksum(byte [] buffer)

koja izračunava i stavlja zaštitnu sumu.

Metoda postprocesirajAPDU mijenja primljeni međuspremnik koje se po povratku iz metode može proslijediti terminalu.

5.1.2.10. Metode za ispitivanje određenih uvjeta

Metoda

void Autoriziraj(short razinaOvlastenja)

provjerava da li je uspostavljen sigurni komunikacijski kanal, da li su primljeni podaci konzistentni i da li je naredba ovlaštena. U slučaju da podaci nisu konzistentni, nije ostvaren sigurni komunikacijski kanal ili naredba nije ovlaštena baca se javacard.framework.UserException iznimka redom sa sljedećim razlozima: SuceljePZI.KORUPTIRANI_PODACI, SuceljePZI.ZAHTJEV_ODBIJEN, SuceljePZI.ZAHTJEV_ODBIJEN. Slika 5.12 prikazuje izvorni tekst programa metode.

Metoda

boolean isCommandSecure(byte trazenaSvojstva)

provjerava da li su primljeni podaci konzistentni. Metoda

boolean isChannelSecure(byte trazenaSvojstva)

provjerava da li postoji sigurni kanal između kartice i terminala. Navedene metode provjeravaju uvjete bitovno (engl. bit-wise), tj. sve konstante koje se koriste kao uvjeti koji se predaju ovim metodama imaju samo jednu jedinicu u svom binarnom zapisu (potencije broja 2) tako da metode daju kao rezultat istinu ako je u zapamćenoj privatnoj varijabli sigurnost “uključen” određeni bit. Metoda

boolean isAuthenticated(short razina)

provjerava da li je tražena razina ovlaštenja autorizirana PIN-om, tako da usporedi da li je razina s kojom se korisnik autorizirao pomoću PIN-a veća ili jednaka traženoj razini ovlaštenja. Slika 5.13. prikazuje izvorni tekst programa ovih metoda.

Engleski nazivi objašnjenih metoda kao i engleski nazivi nekih konstanti preuzeti su iz paketa javacard.framework.service koji postoji u specifikaciji Java Card 2.2.1 platforme (pri implementaciji ovih sigurnosnih mehanizama korištena je Java Card 2.1.1 platforma).

5.2. Paket terminalPZI

Paket terminalPZI sadrži jedno sučelje DohvatacCertifikata i dva razreda DatotecniDohvatacCertifikata i SigurnaAPDUVeza koji ostvaruju sigurnost. Osnovi razred ovog paketa je SigurnaAPDUVeza koji proširuje razred hr.fer.zemris.diplomski.terminalPZI.APDUVeza i implementira sigurnosne mehanizme oka što su: zaštitna suma, kriptiranje/dekriptiranje i digitalno potpisivanje,....

5.2.1. Razred SigurnaAPDUVeza

Razred SigurnaAPDUVeza je apstraktan i predstavlja osnovu za daljnje razvijanje aplikacija koje moraju sigurno komunicirati sa kartičnom aplikacijom. Razred je zamišljen kao neka vrsta sigurnosnog međusloja (engl. middleware) pomoću kojeg se će davatelj kartične aplikacije napraviti razred za pristup mogućnostima kartične aplikacije i tako u potpunosti sakriti detalje sigurnosti i kartične aplikacije od aplikacijskog programera koji će razvijati aplikaciju s grafičkim korisničkim sučeljem (engl.Graphical User Interface - GUI) namijenjenu korisniku. Razred nasljeđuje razred APDUVeza čime nasljeđuje sve metode nužne za rad sa kartičnom aplikacijom. Razred pruža:

• inicijalizaciju sigurnosnih mehanizama appleta,

• provjeru konzistentnosti podataka pomoću 16-bitne zaštitne sume,

• generiranje i sigurnu razmjenu sjedničkog kriptografskog ključa,

• identifikaciju pomoću PIN-a,

• tajnost podataka kriptiranjem podataka,

• neporecivost i integritet podataka provjerom i generiranjem digitalnog potpisa (SHA-1/160 bita i RSA/1024 bita),

• čitanje digitalnih certifikata i privatnih ključeva iz datoteke,

• dohvaćanje digitalnih certifikata pomoću razreda DatotecniDohvatacCertifikata

Tablice5.4, 5.5 i 5.6 ukratko opisuju ne privatne članove razreda.

Tablica 5.4. Varijable i konstante razreda SigurnaAPDUVeza

Tablica 5.5. Konstruktori razreda SigurnaAPDUVeza

dekriptirajAPDU(byte[]buffer)

identificirajKorisnika(byte[] PIN) 

initKarticu(java.security.PublicKey Ke, java.security.PrivateKey Kd, java.math.BigInteger Id)

initSigurnost(java.lang.String algoritam, java.lang.String nacin, java.lang.String nadopuna, int velicnaKljuca) 

izmijeniAPDU(byte[] inBuffer)

kriptirajAPDU(byte[]buffer)

ostvariSigurniKanal() 

potpisiAPDU(byte[] buffer) 

procitajPrivatanKljuc( java.lang.String imeDatoteke ) 

provjeriMakniChecksum(byte[] buffer) 

provjeriPotpis(byte[] podaci, byte[] potpis, int brojCertifikata) 

staviCheckSum(byte[] buffer) 

traziPotpisPodataka(byte[] podaci, int offset, int duljina) 

vezaSigurna() 

Tablica 5.6. Ne privatne metode razreda SigurnaAPDUVeza

5.2.1.1. Korištenje razreda SigurnaAPDUVeza

Razred SigurnaAPDUVeza je apstraktan tako da ga je potrebno naslijediti da bi se mogao koristiti. Svaki nasljeđujući razred mora pozvati jedan od konstruktora kako bi inicijalizirao objekt razreda opencard.core.service.CardService iz osnovnog razreda (APDUVeza) pomoću koga se komunicira sa karticom. Postoje dva konstruktora. Prvi konstruktor jednostavno proslijeđuje primljenu referencu konstruktoru osnovnog razreda. Drugi dodatno pamti referencu na dodatnu vezu prema kartičnoj aplikaciji za potrebe digitalnog potpisivanja podataka. Nakon poziva konstruktora i stvaranja primjerka razreda potrebno je pozvati metodu initSigurnost (detaljno objašnjena u poglavlju 5.2.1.2) kojom se inicijaliziraju sigurnosni mehanizmi npr.:

void odaberiApplet(byte[] AID)

iz osnovnog razreda APDUVeza te uspostavljanje sigurnog komunikacijskog kanala metodom

void ostvariSigurniKanal().

Uspostava sigurnog komunikacijskog kanala je detaljno objašnjena u poglavlju 5.1.2.5.Ukoliko se radi o neinicijaliziranoj kartici umjesto metode ostvariSigurniKanal bilo bi logično pozvati metodu

koja će inicijalizirati karticu sa njenim parom asimetričnih ključeva i serijskim brojem njenog digitalnog certifikata.

Javno sučelje razreda sastoji se od 9 metoda:

• identificirajKorisnika(byte[]),

• initKarticu(PublicKey,PrivateKey, java.math.BigInteger),

• initSigurnost(String, String, String, int),

• ostvariSigurniKanal(),

• procitajCertifikat(String),

• procitajPrivatanKljuc(String),

• provjeriPotpis(byte[], byte[], int),

• traziPotpisPodataka(byte[], int, int),

• vezaSigurna(),

koje omogućuju:

• identifikaciju pomoću PIN-a,

• inicijalizaciju sigurnosnih mehanizama appleta,

• inicijalizaciju lokalnih sigurnosnih mehanizama,

• generiranje i sigurnu razmjenu sjedničkog kriptografskog ključa,

• čitanje digitalnih certifikata i privatnih ključeva iz datoteke,

• provjeru digitalnog potpisa,

• slanje zahtjeva kartici za generiranje digitalnog potpisa,

• provjeru uspostave sigurnog komunikacijskog kanala.

Najvažnija metoda ovog razreda je :

protected byte[] izmijeniAPDU(byte[] inBuffer).

To je zaštićena metoda koja šalje APDU naredbu kartici te prima APDU odgovor (detaljno objašnjena u poglavlju 5.2.1.4).

5.2.1.2. Metoda initSigurnost

Metoda initSigurnost inicijalizira sve potrebne kriptografske mehanizme. Metoda prima sljedeće parametre sa sljedećim značenjima:

• algoritam - ime algoritma za koji se radi ključ,
• nacin - određuje način rada algoritama,
• nadopuna - određuje algoritam nadopune,
• velicinaKljuca - veličina ključa koji će se koristiti za kriptiranje podataka.

Vrijednosti parametara algoritam,nacin,nadopuna,velicinaKljuca su definirani sa Java 2 SDK Security API (vidjeti poglavlje 4.6.1 ili "Java Cryptography Extension Reference Guide, Appendix A: Standard Names"). Metoda initSigurnost inicijalizira generator simetričnih ključeva ovisno o parametru algoritam, veličinu budućeg simetričnog sjedničkog ključa na velicinaKljuca, objekt za simetrično kriptiranje prema parametrima algoritam, nacin,nadopuna, objekt za asimetrično kriptiranje RSA algoritmom sa nadopunom prema PKCS#1 i generator kriptografskih SHA-1 sažetaka. Metoda potom poziva privatnu metodu void procitajConfigDatoteku() koja čita konfiguracijsku datoteku u potrazi za putanjima prema datotekama koje sadrže digitalni certifikat izdavača, digitalni certifikat terminala, privatni ključ terminala te direktorijima koji sadrže ključeve i digitalne certifikate. Format konfiguracijske datoteke je sljedeći:

• ključna riječ,

• bilo koji prazni znak (engl. whitespace),

• proizvoljni niz ne praznih znakova, npr. =, -,

• bilo koji prazni znak (engl. whitespace),

• putanja do imena datoteke ili direktorija (ne smije sadržavati prazan znak),

primjer konfiguracijske datoteke je:

RootCER = certifikati/CER_HZZO_HZZO.pem
TermCER = certifikati/CER_term1_HZZO.pem
TermKey = kljucevi/Kd_term1_PKCS8.der
KeyDIR = kljucevi
CERDIR = certifikati

Nakon čitanja konfiguracijske datoteke čitaju se digitalni certifikati izdavača i terminala te privatni ključ terminala. Digitalni certifikati moraju biti u ASN.1 DER,PKCS#10 kompatibilnom formatu zapisani u Base64 formatu. Privatni ključevi moraju biti u binarnom nekriptiranom PKCS#8 formatu. Veličina asimetričnih ključeva nije uvjetovana, ali radi kompatibilnosti sa kartičnom aplikacijom koriste se 1024 bitni ključevi.

Zadnja stvar koju metoda obavlja je stvaranje repozitorija digitalnih certifikata, koji će se koristiti prilikom dohvaćanja digitalnog certifikata kartice pri uspostavi sigurnog komunikacijskog kanala, te pri provjeri digitalnog potpisa uputnica i recepata. Repozitorij je primjerak razreda DatotecniDohvatacCertifikata. Taj razred implementira sučelje DohvatacCertifikata koje definira sve potrebne metode za dohvat digitalnih certifikata prema određenom kriteriju. Na ovaj način je postignuto da se jednostavno može zamijeniti datotečni dohvatać sa nekim drugim promjenom samo jedne linije izvornog teksta programa. Sučelje DohvatacCertifikata je detaljnije opisano u poglavlju 5.2.2 a razred DatotecniDohvatacCertifikata u poglavlju 5.2.3.Slika 5.14. prikazuje izvorni tekst programa metode initSigurnost.

T-PZI koristi sljedeće kriptografske algoritme i ključeve:

• za simetrično kriptiranje: Triple DES u CBC načinu rada sa nadopunom prema ISO 7816-4,

• 112 bitni Triple DES ključ (dva DES ključa),

• za asimetrično kriptiranje: RSA sa nadopunom prema PKCS#1 (v1.5),

• 1024 bitni RSA ključ,

• za kriptografske sažetke: SHA.

Neki od ovdje navedenih mehanizama nisu podržani od strane JCE davatelja koji dolaze sa Sun-ovom instalacijom Java platforme. Konkretno SunJCE ne podržava nadopunu prema ISO 7816-4 i kriptiranje RSA algoritmom. Zato je potrebno instalirati i registrirati (poglavlje 4.1.6) JCE davatelja (davatelje) koji podržava navedene mehanizme.

U razvojnoj i testnoj okolini PZI-a korišten je besplatni i vrlo moćni “The Legion Of The Bouncy Castle” (http://www.bouncycastle.org)JCE davatelj.

5.2.1.3. Metoda initKarticu

Metoda

initKarticu( java.security.PublicKey Ke,java.security.PrivateKey Kd, java.math.BigInteger Id)

inicijalizira javni i privatni ključ kartice i identifikator kartice (serijski broj digitalnog certifikata). Metoda prima tri parametra: javni ključ kartice, privatni ključ kartice i serijski broj digitalnog certifikata kartice predstavljen kao BigInteger. Metoda je prilagođena 1024-bitnim RSA ključevima, a serijski broj certifikata može biti maksimalno 32-bitni 2'k cijeli broj. Ograničenja prvenstveno postoje zbog ograničenosti kartične aplikacije. Za cijeli postupak inicijalizacije potrebne su četiri poruke. Šalje se:

1. Eksponent javnog ključa kartice

2. Eksponent privatnog ključa kartice

3. Modul ključeva kartice

4. Identifikator kartice

5.2.1.4. Metoda izmijeniAPDU

Metoda izmijeniAPDU je osnovna komunikacijska metoda ovog razreda. Ona šalje primljenu APDU naredbu i vraća odgovor. Prilikom slanja prvo obavlja svo potrebno predprocesiranje poruke, a po primitku odgovora svo potrebno postprocesiranje. Slanje poruke se obavlja na sljedeći način: ukoliko je CLA polje APDU naredbe 0x00 ne obavlja se nikakvo predprocesiranje niti se odgovor postprocesira. Ovo omogućuje slanje naredbi koje neće biti procesirane od strane sigurnosno osviještenog appleta već neke treće strane. Primjer je APDU naredba za odabiranje appleta sa APDU zaglavljem : 0x00, 0xA4, 0x04, 0x00. Ovakvo ponašanje je zapravo ekvivalentno ponašanju orginalne metode izmijeniAPDU iz razreda ADPUVeza. Ukoliko CLA polje nije jednako 0x00 obavlja se barem minimalno predprocesiranje. Minimalno predprocesiranje predstavlja stavljanje 16-bitne zaštitne sume. Ukoliko je ostvaren sigurni komunikacijski kanal i veličina poruke je veća od 0 obavlja se dodatno predprocesiranje koje uključuje kriptiranje sjedničkim ključem i digitalno potpisivanje poruke. Zbog ograničenja maksimalne veličine ADPU poruke definirane sa ISO7816-4 od 255 okteta, kriptirana poruka se šalje odvojeno od digitalnog potpisa. Nakon slanja svakog dijela poruke čeka se odgovor o uspješnosti slanja i procesiranje poruke na kartici. Slanje zadnjeg dijela poruke ujedno označava početak primanja odgovora na poslanu APDU naredbu.

Postprocesiranje se obavlja slično kao predprocesiranje, ali donekle obrnutim postupkom. Ukoliko je CLA polje poslane APDU naredbe bilo 0x00 postprocesiranje se preskače. U suprotnom se prvo miče i provjerava 16-bitna zaštitna suma. Ukoliko zaštitna suma ne odgovara primljenim podacima baca se iznimka java.io.IOException sa razlogom “KORUPTIRANI PODACI”. Ukoliko je ostvaren sigurni komunikacijski kanal i veličina primljenih podataka je veća od 0 obavlja se dodatno postprocesiranje (prvi oktet primljenog odgovora određuje veličinu odgovora – karakteristično za PZI) koje uključuje dekriptiranje poruke i provjera primljenog digitalnog potpisa. Primitkom prvog odgovora, koji predstavlja kriptiranu poruku sjedničkim ključem, obavlja se dekriptiranje i pamćenje dekriptirane poruke. Potom se od kartične aplikacije traži digitalni popis, slanjem orginalnog zaglavlja, ali bez tijela poruke. Primitkom drugog odgovora provjerava se digitalni potpis i u slučaju neispravnosti baca iznimka java.security.SignatureException sa razlogom "KRIVI DIGITALNI POTPIS".

Metoda izmijeniAPDU vraća dekriptirani APDU odgovor bez ikakvih dodataka i time ostvaruje transparentnost sigurnosnih mehanizama.

Na slici 5.15 prikazan je protokol izmjene APDU paketa u slučaju kada je ostvaren sigurni komunikacijski kanal.

Slika 5.15. Protokol razmjene podataka

5.2.1.5. Metoda traziPotpisPodataka

Metoda traziPotpisPodataka šalje kartici podatke na potpisivanje. Metoda šalje APDU naredbu s poljem CLA postavljenim na vrijednost SuceljeSigurnosti.CLA_SIGN što uzrokuje metodu procesirajAPDU (poglavlje 5.1.2.3) da pozove metodu potpisiPodatke (poglavlje 5.1.2.8) koja će generirati digitalni potpis podataka pomoću privatnog ključa kartice. U sklopu PZI metoda se koristi prilikom digitalnog potpisivanja uputnica i recepata. Slika 5.16 prikazuje izvorni tekst programa metode.

Slika 5.16. Metoda traziPotpisPodataka

5.2.1.6. Metoda identificirajKorisnika

Metoda identificirajKorisnika služi za identifikaciju korisnika pomoću PIN-a. Metoda šalje ADPU naredbu sa CLA poljem SuceljeSigurnosti.CLA_AUTH i INS poljem SuceljeSigurnosti.INS_AUTH. Metoda vraća logičku istinu ukoliko je cijeli proces prošao bez pogrešaka. U slučaju da nastane bilo koja pogreška tj. ukoliko se uhvati bilo koja iznimka metoda vraća logičku laž. Slika 5.17 prikazuje izvorni tekst programa metode.

Slika 5.17. Metoda identificirajKorisnika

5.2.1.7. Metoda provjeriPotpis

Metoda

boolean provjeriPotpis( byte[] podaci, byte[] potpis,int brojCertifikata)

dohvaća digitalni certifikat serijskog broja određenog parametrom brojCertifikata iz repozitorija digitalnih certifikata te sa javnim ključem iz tog digitalnog certifikata provjerava digitalni potpis primljenih podatka. Metoda se koristi u T-PZI prilikom poništavanja uputnica i recepata. Slika 5.18 prikazuje izvorni tekst programa metode.

5.2.2. Sučelje DohvatacCertifikata

Sučelje koje definira opčenito sučelje za dohvaćanje traženih digitalnih certifikata. Sučelje definira dvije metode: dohvatiCertifikate i dohvatiProvjereneCertifikate.

Metoda

java.util.Collection dohvatiCertifikate (java.security.cert.CertSelector uvjet)

dohvaća sve digitalne certifikate koji zadovoljavaju navedeni uvjet. Uvjet se zadaje objektom razreda java.security.cert.CertSelector (pogledati 4.1.2). Metoda vraća sve digitalne certifikate koji zadovoljavaju naveden uvjet u obliku objekta razreda java.util.Collection. Ukoliko nastane pogreška prilikom dohvaćanja digitalnih certifikata baca se iznimka java.security.cert.CertStoreException.

Metoda

java.util.Collection dohvatiProvjereneCertifikate (java.security.cert.CertSelector uvjet, java.security.PublicKey javniKljuc)

dohvaća sve provjerene (točan potpis i važeće) digitalne certifikate koji zadovoljavaju navedeni uvjet. Sve navedeno za prethodnu metodu (dohvatiCertifikate) vrijedi i ovdje. Metoda prima javni ključ s kojim se provjeravaju digitalni certifikati.

5.2.3. Razred DatotecniDohvatacCertifikata

Razred DatotecniDohvatacCertifikata implementira sučelje DohvatacCertifikata i pruža mogućnost dohvaćanje digitalnih certifikata iz u memoriji napravljenog repozitorija. Datotečni dohvatać certifikata, kao što mu ime govori, je razred koji čita digitalne certifikate iz datoteka sa tvrdog diska, te ih sprema u repozitorij u memoriji računala. Razred sadrži jedan javno dostupan konstruktor koji prima putanju do direktorija gdje se nalaze digitalni certifikati. Konstruktor čita sve datoteke sa ekstenzijom "pem" (eng. Privacy-enhanced Electronic Mail) iz navedenog direktorija u nastojanju da stvori digitalne certifikate. Svi digitalni certifikati moraju biti u tipa X.509 u ASN.1 DER, PKCS#10 java.security.cert.CertStore kompatibilnom formatu zapisani u Base64 formatu. Jednom pročitani digitalni certifikati spremaju se u repozitorij tipa (poglavlje 4.1.2). Slika 5.19 prikazuje izvorni tekst programa konstruktora.

Razred implementira dvije metode definirane sučeljem DohvatacCertifikata: dohvatiCertifikate i dohvatiProvjereneCertifikate. Funkcionalnost metoda je objašnjena u predhodnom poglavlju. Slike 5.20 i 5.21 prikazuju izvorni tekst programa metoda.

6. Zaključak

Ovaj diplomski rad pokazuje kako su Java i Java Card platforme pogodne za implementaciju raznih i sigurnih kartičnih sustava.

Jedan od većih problema implementacije ovog sigurnosnog modula bilo je usklađivanje kriptografskih algoritama između terminala i kartice. Terminal s jedne strane koristi Java RE koji inicijalno ne dolazi s potpunom kriptografskom podrškom zbog izvoznih pravila SAD-a pa je potrebno nabaviti dodatne module koji će se koristiti pri razvitku ovog sigurnosnog modula. Korištene kartice (Axalto Cyberflex Access 64K) s druge strane implementiraju samo podskup sigurnosnih mehanizama definiranih Java Card platformom 2.1.1 što dodatno otežava usklađivanje sigurnosnih mehanizama kartice i terminala.

Najveći problem implementacije ovog sigurnosnog modula bilo je korištenje, inače zahtjevnih, sigurnosnih mehanizama na vrlo ograničenoj platformi kao što je Java Card. Upotreba kriptografskih mehanizama uzrokovala je potrebu prijenosa velike količine podataka što se pokazalo kao velik problem i drastično usporilo komunikaciju terminala s karticom.

Kako raste tržište pametnih kartica tako će se poboljšavati svojstva čipova koji se ugrađuju u pametne kartice te je za očekivati da će u bliskoj budućnosti pametne kartice imati jednako brze procesore kao današnja slabija ručna računala (PDA - engl. Personal Digital Assistant), a da će se kartični protokoli adekvatno modificirati da omoguće brži prijenos većih količina podatka.

7. Literatura

1. Java^TM 2 SDK, Standard Edition Documentation, version 1.4.2, 1.4.1

2. “Java^TM 2 Platform, Standard Edition, v 1.4.2 API Specification”, “Java 2 Platform, Standard Edition, v 1.4.2 Software Development Kit (SDK)”, dostupno na Internet adresi: http://java.sun.com/j2se/1.4.2/download.html

3. “ Java^TM Cryptography Extension Reference Guide for the Java^TM 2 SDK, Standard Edition, v 1.4”, “Java 2 Platform, Standard Edition, v 1.4.2 SDK”

4. Java Card™ 2.1.1 Application Programming Interface

5. “ISO/IEC 7816 Part 4: Interindustry command for interchange”, http://www.ttfn.net/techno/smartcards/iso7816_4.html

6. A. Galinović, Pametna turistička kartica, Seminarski rad, Fakultet elektrotehnike i računarstva, Zagreb, 2004. http://sigurnost.zemris.fer.hr/pk/2004_galinovic/index.html

7. L. Budin, Operacijski sustavi II, predavanja iz predmeta Operacijski sustavi, pp 11.8, 2003./2004.

Dodatak: Kazalo pojmova i korištenih kratica

2'k - broj prikazan u dvojnom komplementu

A-PZI - Applet Pametne Zdravstvene Iskaznice

AES - Advanced Encription Standard, tj. Rijndael

AID - Application Identifier

API - Application Programming Interface

APDU - Application Protocol Data Unit

ASN.1 - Abstract Syntax Notation One

bit - Binary Digit

CA - Certificate Authority

CAD - Card Acceptance Device

CBC - Cipher Block Chaining

CEI - Commission Electrotechnique Internationale

CFB - Cipher Feedback Mode

CRL - Certificate Revocation Lists

CSR - Certificate Signing Request

DER - Distinguished Encoding Rules

DES - Data Encription Standard

DES3 - Triple DES

DESede - Triple DES EDE

DFA - Differential Fault Analysis

DPA - Differential Power Analysis

DSA - Digital Signature Algorithm

ECB - Electronic Codebook

EDE - Encrypt Decrypt Encrypt

EEPROM - Electronically Erasable Programmable ROM

EMV'96 - Europay MasterCard VISA

FIPS - Federal Information Processing Standards

FTP - File Transfer Protocol

GSM - Global System for Mobile Communications

GUI - Graphical User Interface

HMAC - Keyed-Hash MAC

HTTP - Hypertext Transfer Protocol

IEEE - Institute of Electrical and Electronics Engineers

IEC - International Electrotechnical Commission

ISO - International Standardization Organization

JAR - Java Archive

JASS - Java Authentication and Authorization Service

Java Byte kôd - sklopovski neovisan međukôd specifičan za Javu

Java RE - Java Runtime Environment

Java SDK - Java Software Development Kit

JCA - Java Cryptography Architecture

JCAPI - Java Card API

JCE - Java^TM Cryptography Extension

JCRE - Java Card Runtime Environment

JCVM - Java Card Virtual Machine

JDK - Java Development Kit

JGSS - Java Generic Security Services

JKS - Java Key Store, Sun-ovo ostvarenje repozitorija ključeva

JSSE - Java Secure Socket Extension

JVM - Java Virtual Machine

KiB - Kibi Byte, 1024 okteta, prema CEI/IEC 60027-2, siječanj 1999.

LDAP - Lightweight Directory Access Protocol

MAC - Message Authentication Code

MD2 - Message Digest 2

MD5 - Message Digest 5

MP3 - MPEG 1 sloj 3

MPEG - Moving Picture Experts Group

NIST - National Institute of Standards and Technology

OAEP - Optimal Asymmetric Encryption Padding

OFB - Output Feedback Mode

OFB - Output Feedback Mode

PBE - Password-Based Encryption

PCBC - Propagating Cipher Block Chaining

PDA - Personal Digital Assistant

PEM - Privacy-enhanced Electronic Mail

PIN - Personal Identification Number

PKCS - Public-Key Cryptography Standards

PKCS#1 - RSA Cryptography Standard

PKCS#3 - Diffie-Hellman Key Agreement Standard

PKCS#5 - Password-Based Cryptography Standard

PKCS#8 - Private-Key Information Syntax Standard

PKCS#10 - Certification Request Syntax Standard

PKCS#12 - Personal Information Exchange Syntax Standard

PKIX - Public-Key Infrastructure X.509 group

PZI - Pametna Zdravstvena Iskaznica

RACE - Research and Development in Advanced Communications Technologies in Europe

RAM - Random Access Memory

RC2 - Rivest Cipher 2 ili alternativno Ron's Code 2

RC4 - Rivest Cipher 4 ili alternativno Ron's Code 4

RFC - Request for Comments

RFU - Reserved for Future Use

RIPEMD - RACE Integrity Primitives Evaluation Message Digest

ROM - Read Only Memory

RSA - Rivest, Shamir, Adleman

SAD - Sjedinjene Američke Države

SDK - Software Development Kit

SIM - Subscriber Identity Module

SHA - Secure Hash Algorithm

SPI - Service Provider Interface

SSL - Secure Sockets Layer

SunJCE - Sun's Java Cryptography Extension

T-PZI - Terminal Pametne Zdravstvene Iskaznice

TCP - Transmission Control Protocol

TLS - Transport Layer Security

UML - Unified Modeling Language

Program

1. izvorni tekst terminala pametne zdravstvene iskaznice

2. izvorni tekst appleta pametne zdravstvene iskaznice

3. aplikacija terminala pametne zdravstvene iskaznice

4. API dokumentacija