Način ljudske komunikacije je kroz povijest poprimao različite oblike, od razgovora "uživo", dimnih signala, do goluba pismonoša. Također, od najranijih vremena je postojala potreba da neki dijelovi komunikacije ostanu tajni, odnosno dostupni samo određenim osobama. I taj je problem ljudska civilizacija na razne načine vješto rješavala.

Vremena su se promijenila. Danas se veliki dio komunikacije odvija uz pomoć računala. Ubrzanim razvojem tehnologije, cijena računalne opreme se smanjuje te danas gotovo svako domaćinstvo ima snažan alat. Osim toga, znanje potrebno za napredan rad na računalu dostupno je na Internetu.

Nova su vremena donijela i ekonomske sustave u kojima se svaki dan okreće velika količina novca, a dio se transakcija obavlja preko Interneta.

Posljednji element čitave priče, koji će i ovom uvodu dati smisao, je ljudska narav. Bez potrebe za detaljnijim obrazlaganjem, dio ljudske vrste će bez puno premišljanja uzeti nešto što mu ne pripada; jedan manji dio će se jako potruditi da dođe do sredstava na ilegalan način.

Vrijeme u kojem živimo i okolnosti koje ono donosi, nalaže da se moraju pronaći odgovarajuće metode koje će uspješno štititi ljudsku komunikaciju (u nekim slučajevima i same živote ljudi), ali i sredstva kojima se trguje. Budući je ulog jako velik, postoji više zainteresiranih strana koje su spremne uložiti sredstva u razvoj takvih metoda.

Cilj ovog diplomskog rada je proučavanje sustava infrastrukture javnog ključa, te izrada aplikacije koja se koristi za stvaranje digitalnog potpisa. Kako aplikacija ima mogućnost stvaranja digitalnog potpisa, ona postaje sastavni dio infrastrukture javnog ključa. U radu je opisan sustav infrastrukture javnog ključa, te neke od postojećih normi. U posljednjem dijelu rada opisana je aplikacija od samog izvornog teksta programa do uputstava za instalaciju i upotrebu.

2. Računalna sigurnost

2.1 Uvod

Sigurnost kojom se ovo poglavlje bavi jest računalna sigurnost (eng. computersecurity). U ranim danima računalne znanosti, računalna sigurnost je bila jedna od manjih briga. Broj računala i ljudi kojima su računala bila dostupna bio je ograničen. Prvi su problemi sigurnosne prirode u računalnom sustavu bili zapažani već u 1950-im godinama, kada su se računala počela koristiti za obradu povjerljivih podataka. Povjerljivost ili tajnost je bila primarni sigurnosni problem. Najveću opasnost je predstavljala špijunaža i invazija na privatne podatke. Od tog trenutka, sve do nedavno, računalna sigurnost je bila primarno vojni problem, koji je bio razmatran esencijalno kao sinonim za računalnu sigurnost. Iz te perspektive, visok stupanj sigurnosti se postizao štiteći samu informaciju.

Do kasnih 1960-tih, razmjena računalnih resursa i informacija u računalu, odnosno preko mreže, predstavljala je dodatni sigurnosni problem. Računalni sustavi s više korisnika zahtijevali su operacijske sustave koji su sprječavali korisnike od namjernog ili slučajnog interferiranja s drugim korisnicima. Pojavom mrežnih veza nastao je još jedan put za potencijalni napad koji nije mogao biti fizički spriječen. Od tada odavanje informacije nije bio jedini sigurnosni problem – pojavio se i problem održavanja integriteta podataka. Konvencionalna mudrost iz tog vremena bila je da vlade primarno brinu o štićenju informacija, a primarna je briga poslovnih krugova bila očuvanje integriteta podataka.

U popularnom tekstu o sigurnosti Interneta i sigurnosnim stijenama, Cheswick i Bellovin definiraju računalnu sigurnost kao zadržavanje svih [osoba, programa] od obavljanja radnje koje ne želite da se obavljaju. Koristeći tu definiciju, računala su mete koje se mogu napasti ("od obavljanja"), ili alati koji se mogu koristiti. Iz te perspektive, računalna je sigurnost odvojena od informacijske sigurnosti: Računalna sigurnost nije cilj, nego oruđe prema cilju informacijske sigurnosti[15].

Definiciju su s operativne strane prezentirali Garfinkel i Spafford u svom tekstu "Unix i Internet sigurnost": Računalo je sigurno ukoliko se možete osloniti na njega i njegovu programsku opremu da se ponaša kako to očekujete ... taj koncept se često zove povjerenje: vjerujete sustavu da pohranjuje i čuva vaše podatke. Autori su namjeravali uključiti prirodne katastrofe i problematičnu programsku opremu kao sigurnosne probleme, ali isključiti razvoj i test programske opreme[16].

Postoji mnogo događaja koji rezultiraju oštećenjem ili gubitkom računalnih podataka koji su uključeni u generalnoj, informativnoj definiciji računalne sigurnosti, ali su prikladnije za razmatranje u drugim granama sigurnosti. Na primjer, krađa računalne opreme sigurno može rezultirati gubitkom podataka, ali taj tip krađe je sličan krađi faks uređaja, telefona, vrijednosti ili bilo kojeg drugog fizičkog objekta. Metode osiguravanja fizičkih objekata su dobro razvijene te nisu jedinstvene za računalnu opremu. Isto tako, elementarne nepogode, kao potresi, poplave, udari groma, fluktuacije napajanja, itd., također mogu rezultirati oštećenjem računalnih podataka.

Definicija računalne sigurnosti, o kojoj će u ovom radu biti riječi, odnosi se na sigurnost koja pripada u jednu od tri navedene kategorije:

o Povjerljivost (tajnost) – informacija treba biti dostupna samo onima koji imaju dozvolu.

o Integritet – zahtijeva zaštitu od slučajne ili namjerne promjene informacije.

o Dostupnost – pristup informaciji (resursima) autoriziranim korisnicima kada im je to potrebno.

2.2 Kriptografija

2.2.1 Povijest

Kriptografija ima dugu i fascinantnu povijest. Najiscrpniji ne-tehnički dokaz je Kahnova "The Codebrakers". Ta knjiga prati kriptografiju od njenog inicijalnog i ograničenog korištenja kod Egipćana prije 4000 godina, do 20. stoljeća u kojemu je odigrala ključnu ulogu u oba svjetska rata. Završena 1963., Kahnova knjiga sadrži većinu bitnih aspekata povijesti kriptografije do tada[17].

Najistaknutiji praktičari kriptografije bili su povezani s vojskom, diplomatskim korom, odnosno vladama općenito. Kriptografija se koristila kao alat kojime se štite nacionalne strategije i tajne.

Širokim korištenjem računala i komunikacijskih sustava 1960-tih, u poslovnom svijetu dolazi do potrebe za zaštitom informacije u digitalnom obliku. Godine 1972. američki je National Bureau of Standards (NBS) inicirao program za zaštitu računalnih i komunikacijskih podataka. Jedan od ciljeva je bio razvijanje standardnog kriptosustava. Godine 1973. NBS je raspisao javni natječaj za takav kriptosustav, koji je trebao zadovoljiti slijedeće uvjete:

o visoki stupanj sigurnosti

o potpuna specifikacija i lako razumijevanje algoritma

o sigurnost leži u ključu, a ne u tajnosti algoritma

o dostupnost svim korisnicima

o prilagodljivost uporabi u različitim primjenama

o ekonomičnost implementacije u elektoničkim uređajima

o efikasnost

o mogućnost provjere

o mogućnost izvoza (zbog američkih zakona)

Na tom natječaju niti jedan prijedlog nije zadovoljavao sve navedene zahtjeve. Međutim, na ponovljeni natječaj iduće je godine pristigao prijedlog algoritma koji je razvio IBM-ov tim kriptografa. Algoritam je zasnovan na tzv. Fiestelovoj šifri. Gotovo svi simetrični blokovni algoritmi koji su danas u uporabi koriste ideju koju je uveo Horst Feistel 1973. godine. Jedna od glavnih ideja je alternirana uporaba supstitucije i transpozicije.

Predloženi je algoritam, nakon nekih preinaka u kojima je sudjelovala i National Security Agency (NSA), 1976. godine prihvaćen kao norma i dobio je ime Data Encryption Standard (DES). On postaje norma kojom se osigurava elektronsko poslovanje u mnogim financijskim institucijama diljem svijeta.

No, najzanimljiviji trenutak u povijesti računalne kriptografije se dogodio 1976. kada su Diffie i Hellman objavili "New Directions in Cryptography". Taj je rad uveo revolucionarni koncept kriptografije javnim ključem, te genijalnu metodu za razmjenu ključeva. Iako autori nisu imali ideju praktične realizacije kriptografije javnim ključem, ona je privukla značajan interes i intenzivirala aktivnost kriptografske zajednice[18].

1978. godine Rivest, Shamir i Adleman su otkrili prvu praktičnu metodu kriptografije javnim ključem, nazvanu RSA. RSA algoritam je temeljen na matematičkom problemu faktoriziranja velikih brojeva.

Korištenje teškog matematičkog problema revitaliziralo je pokušaje da se pronađe efikasnija metoda rastava broja na proste faktore. Osamdesete godine prošlog stoljeća donijele su veliki napredak u tom području, ali niti jedna od novih metoda nije ugrozila RSA algoritam.

Jedan od najvažnijih potencijala kriptografije javnim ključem je stvaranje digitalnog potpisa. 1991. je donešena prva međunarodna norma za digitalni potpis (ISO/IEC 9796) koja je temeljena na korištenju RSA kriptiranja javnim ključem. 1994. godine vlada SAD-a je prihvatila Digital Signature Standard, mehanizam temeljen na ElGamal kriptografiji javnim ključem.

2.2.2. Definicija kriptografije

Kriptografija je znanstvena disciplina koja se bavi proučavanjem metoda slanja poruka u takvom obliku da ih može pročitati samo onaj kome su namijenjene. Sama riječ kriptografija je grčkog podrijetla i znači tajnopis. Za razliku od dešifriranja, kriptoanaliza ili dekriptiranje je znanstvena disciplina koja se bavi proučavanjem postupaka čitanja skrivenih poruka bez poznavanja ključa. Kriptologija je grana znanosti koja obuhvaća kriptografiju i kriptoanalizu[6].

Osnovni zadatak kriptografije je omogućavanje dvjema osobama (zvat ćemo ih pošiljatelj i primatelj) da komuniciraju preko nesigurnog komunikacijskog kanala (telefonska linija, računalna mreža, itd.), na način da treća osoba (potencijalni napadač) ne može razumjeti njihove poruke.

Dva postupka koja se koriste u kriptografiji su kriptiranje (eng. encryption, enciphering) i dekriptiranje (eng. decryption, deciphering). Kriptiranje je matematička funkcija koja ima slijedeći oblik:

C = E(P, Ke)

gdje je P čitki tekst (eng. plain text, cleartext), C kriptirani tekst, a Ke ključ kriptiranja. Dekriptiranje je matematička funkcija (D) slijedećeg oblika:

P = D(C, Kd)

gdje je Kd ključ dekriptiranja. Proizlazi da je dekriptiranje matematička funkcija inverzna kriptiranju te vrijedi:

D( E(P, Ke), Kd ) = P

Postavljaju se dva uvjeta:

o mora se omogućiti kriptiranje na mnogo načina kako bi se izbjeglo lako otkrivanje poruke

o algoritmi kriptiranja i dekriptiranja moraju, kompatibilnosti radi, biti javno poznati.

Kako bi se zadovoljila ova dva uvjeta, stvoreni su postupci kriptiranja i dekriptiranja koji su javno poznati, a čija uporaba zahtijeva korištenje ključeva Ke i Kd kao parametara. Upravo ti parametri unose varijabilnost u rezultat funkcija.

Ako se ne koriste ključevi, snaga sustava u potpunosti ovisi o tajnosti algoritma. Zbog toga je kriptografsko pravilo da sigurnost sustava ovisi o tajnosti ključa, a ne algoritma.

Postoje dvije osnovne vrste kriptografskih algoritama: simetrični i asimetrični. Kod simetričnih algoritama ključ dekriptiranja Kd jednak je ključu kriptiranja Ke (Ke = Kd = K). Simetrični algoritmi se zovu još i algoritmi s tajnim ili simetričnim ključem.

Slika 2.1: Proces kriptiranja i dekriptiranja (simetrični algoritam)

Kod asimetričnih algoritama ključ Kd nije jednak ključu Ke, te je vrlo teško (praktički nemoguće u stvarnom vremenu) iz Ke odrediti Kd. Stoga se ključ Ke može javno obznaniti. Asimetrični algoritmi se zovu još i algoritmi s javnim ključem.

Slika 2.2: Proces kriptiranja i dekriptiranja (asimetrični algoritam)

U daljnjim poglavljima ću se pobliže osvrnuti na simetrično i asimetrično kriptiranje, te za svako objasniti detaljnije korake kriptiranja detaljnije.

2.2.3. Simetrični algoritmi

Jedan od najstarijih i najpoznatijih simetričnih algoritama poznat je još iz antičkog doba, a koristio ga je i sam Julije Cezar kad je svojim generalima slao kriptirane poruke. Sastoji se u pomicanju slova u abecedi za proizvoljan broj mjesta n udesno. Tako je, npr. u slučaju korištenja broja 3, kriptirano slovo A predočeno slovom D, kriptirano slovo B slovom E, itd. Kriptirana poruka jednostavno se dekriptira pomicanjem slova u abecedi ulijevo za isti broj n.

Očito se radi o simetričnom algoritmu jer je ključ kriptiranja (broj mjesta n za koji se slova pomiču) jednak ključu dekriptiranja. Čak i u ovom najprimitivnijem postupku vide se osnovna načela kriptografije: algoritam je javno poznat (potrebno je pomicati slova za n mjesta), dok je ključ tajan (broj mjesta n).

Analizirajući podrobnije Cezarov algoritam kao primjer simetričnog algoritma, mogu se primijetiti tri potencijalna problema. Prvi se odnosi na način na koji je Cezar prenosio tajni ključ (u ovom slučaju broj n za koji se pomiču slova u abecedi) svojim generalima. Cezar je koristio provjerenog kurira. Provjereni kurir nije jamac tajnosti jer se ključ putem može izgubiti, ukrasti, kopirati ili prodati.

Drugi problem se odnosi na broj ključeva koje je Cezar morao posjedovati kako bi sa svakim generalom zasebno mogao tajno komunicirati. Naime, morao je za svakog generala posjedovati poseban ključ.

Situacija se dodatno pogoršava ako zamislimo da su svi generali međusobno htjeli tajno komunicirati. Tada bi svaka komunikacija između bilo koja dva generala zahtijevala vlastiti ključ. U tom bi slučaju 5 generala zahtijevalo 10 ključeva, 10 generala bi zahtijevalo 45 ključeva, a 1000 generala 499500 ključeva! Kažemo da je složenost O(n²). Treći problem odnosi se na broj mogućih ključeva. Budući ključ definira broj mjesta pomicanja, u sustavu od 30 znakova, ključ 1 i 31 predstavljaju isti ključ. Danas su kod simetričnih algoritama aktualna ista dva pitanja: kako sigurno dostaviti privatni ključ drugoj strani i koliko je privatnih ključeva potrebno da bi se uspostavio sigurni kanal među svim sudionicima komunikacije.

Simetrične algoritme koji se praktično primjenjuju u računarstvu dijelimo u dvije grupe: algoritmi za kriptiranje toka podataka (eng. stream cipher) i blok kriptiranje (eng. block cipher). Kriptiranje toka podataka radi tako da se kriptiranje poruke (originala) obavlja bit po bit, dok se kod blok kriptiranja kriptiranje obavlja po blokovima podataka, tj. uzimaju se blokovi od više bitova (64, 128, 196, 256 ...) te se kriptiraju kao cjelina. Dekriptiranje se najčešće obavlja inverznim kriptiranjem, tj. algoritam je isti, ali se podključevi kriptiranja koriste obrnutim redoslijedom.

Prednost simetričnih algoritama je ta što su iznimno brzi. Među simetrične algoritme spadaju RC2, RC5, IDEA, DES, 3DES, Stripjack, Blowfish, CAST.

2.2.4. Asimetrična kriptografija

Asimetrični algoritmi koriste par ključeva od kojih se bilo koji može koristiti za kriptiranje. Ako je jedan ključ iz para upotrijebljen za kriptiranje poruke onda se isključivo drugi ključ iz para može upotrijebiti za dekriptiranje poruke. Na ovaj je način moguće sigurno primati poruke tako da se jedan ključ iz para javno obznani (javni ključ) dok se drugi zadrži tajnim (privatni ključ). Svatko može kriptirati poruku korištenjem javnog ključa ali poruku može dekriptirati samo vlasnik privatnog ključa.

U kriptografskim primjerima uobičajeno je opisivanje scenarija u kojima glavne uloge imaju korisnici A i B ili Ana i Bobi (eng. Alice & Bob).

Asimetrični algoritmi, korištenjem para ključeva umjesto samo jednog ključa, rješavaju oba problema simetričnih algoritama. Svaki korisnik ima javno dostupan ključ za kriptiranje i privatni ključ za dekriptiranje. Kada Ana želi poslati tajnu poruku Bobiju, ona dohvaća Bobijev javno dostupni ključ za kriptiranje i njime kriptira poruku. Bobi koristi svoj privatni ključ za dekriptiranje kako bi dekriptirao tu poruku. Kako se poruka kriptirana jednim ključem iz para može dekriptirati samo korištenjem drugog ključa iz para, jasno je da samo Bobi može pročitati poruku. Ana se ne mora brinuti o načinu na koji će dostaviti ključ Bobiju jer ga Bobi već ima. Dodatno, upravljanje ključevima je znatno pojednostavljeno jer je dovoljno da svaki sudionik komunikacije ima jedan par ključeva kako bi mogao uspostaviti sigurnu komunikaciju s bilo kojim drugim sudionikom. To znači da grupa od 1000 korisnika zahtijeva 1000 pari ključeva za sigurnu komunikaciju svatko-sa-svakim, za razliku od simetričnih algoritama gdje je taj broj veći od 500000.

Mana asimetričnih algoritama je njihova sporost. Rad s asimetričnim algoritmom je oko 100 puta sporiji od rada sa simetričnim algoritmom. Među asimetrične algoritme spadaju RSA, EIGamal, Diffie-Hellman.

2.2.5. Usporedba simetrične i asimetrične kriptografije

Primarna prednost kriptiranja javnim ključem je povećana sigurnost: privatni ključevi se nikada ne moraju slati ili pokazivati bilo kome. Kod simetričnog kriptiranja, tajni ključevi se moraju slati (ili ručno ili kroz komunikacijski kanal) te postoji prilika da se u transportu otkrije tajni ključ. Daljnja prednost kriptografije javnim ključem je u mogućnosti stvaranja digitalnog potpisa. Autentikacija korištenjem simetričnog kriptiranja zahtjeva razmjenu neke predefinirane lozinke i ponekad zahtjeva vjerovanje nekoj trećoj strani. Kao rezultat, pošiljatelj može pobiti svoju transakciju, tvrdeći da je prethodno autenticirana poruka bila nekako kompromitirana, od neke od strana koje dijele istu lozinku. Na primjer Kerberos autentikacija tajnim ključem zahtjeva centralnu bazu koja sadrži kopije svih privatnih ključeva za sve korisnike. Kompromitiranje baze bi omogućilo laku falsifikaciju poruka. Autentikacija javnim ključem, s druge strane, ne dozvoljava takav tip kompromitiranja. Svaki korisnik sam ima odgovornost štićenja svog privatnog ključa. Ta se osobina kriptiranja javnim ključem naziva i neporecivost.

Mana korištenja kriptografije javnim ključem za kriptiranje je brzina. Popularni algoritmi kriptiranja tajnim ključem su mnogo brži od trenutno dostupnih algoritama za kriptiranje javnim ključem. Za kriptiranje je, na primjer, najbolje rješenje kombinacija kriptiranja javnog i tajnog ključa. Time se postiže sigurnosna prednost kriptiranja javnim ključem i brzina kriptiranja tajnim ključem. To jest, kriptiranje javnim ključem se može iskoristiti da bi se kriptirao tajni ključ (puno kraći od poruke) kojime je poruka kriptirana kriptiranjem tajnim ključem. Takvo korištenje se naziva digitalna omotnica (eng. envelope), podrobnije opisana u slijedećim poglavljima.

Kriptografija javnim ključem može biti osjetljiva na napad zamjenom identiteta, te u slučaju kada korisnikov privatni ključ nije dostupan. Uspješni napad na Certificate Authority, dozvoljava napadaču da oponaša bilo koga, te izdavajući si certifikat na bilo koje ime (više o certifikatima i CA u slijedećim poglavljima).

U nekim situacijama, kriptografija javnim ključem nije nužna i kriptografija tajnim ključem je dovoljna. To uključuje okoliš u kojemu je izmjena tajnih ključeva sigurna, na primjer za korisnike koji se sastaju privatno. Podjednako tako je prikladna za zatvorene sustave u kojemu jedan entitet zna i održava sve ključeve, npr. bankarski sustav. Budući da taj entitet zna sve ključeve, ne postoji prednost korištenja javnih odnosno privatnih ključeva. Jednako tako kriptografija javnim ključem najčešće nije potrebna u jedno-korisničkom okolišu. Ukoliko želite držati vlastite datoteke kriptirane, možete iskoristiti bilo koji simetrični algoritam i zasebnu lozinku kao tajni ključ.

Generalno gledajući, kriptografiju javnim ključem najbolje je primijeniti u otvorenom, više-korisničkom okruženju.

Kriptografija javnim ključem nije napravljena kao zamjena kriptografije tajnim ključem, nego kao dodatak, da bi se kriptografija tajnim ključem napravila sigurnijom. Prvo korištenje kriptografije javnim ključem bila je sigurna izmjena ključeva u sustavu koji je koristio kriptografiju tajnim ključem, i to je još uvijek jedna od primarnih funkcija kriptografije javnim ključem. Kriptografija tajnim ključem ostaje i nadalje vrlo važna i predmet je mnogih razmatranja i istraživanja.

2.2.6 Snaga kriptografskih algoritama

Snaga nekog algoritma ovisi o dva elementa. Prvi je matematički dokazano teško ili nemoguće razbijanje algoritma poznatim metodama kriptoanalize, a drugi njegova programska implementacija. Čak i najbolje osmišljen algoritam može biti probijen, ako je negdje u implementaciji njegovog algoritma ostavljena "rupa" za kriptoanalitičare. Teoretski, svaku poruku kriptiranu algoritmom koji koristi ključ moguće je razbiti pokušavajući sve moguće ključeve u razbijanju poruke. Ta metoda razbijanja poruke zove se napad grubom silom (eng. brutte force), jer se ne koriste nikakvi inteligentni načini ili spoznaje o algoritmu da se ubrza ili smanji prostor za nalaženje ključa. To je sigurna, ali vrlo neučinkovita metoda razbijanja šifri jer se povećanjem dužine ključa eksponencijalno povećava prostor ključa (eng. keyspace) i potrebna računalna snaga za nalaženje ključa. Na primjer, za ključ od 32 bita potrebno je napraviti 2³² (oko 10⁹) koraka. Sustavu koji razbija 40-bitni ključ potrebno je 2⁴⁰ koraka. To zahtijeva dosta računalne snage, ali je još uvijek u dometu lakog razbijanja i nalaženja šifre (potrebno je oko tjedan dana izračunavanja, a na jako brzim računalnim grozdovima i mnogo manje).

Sustav koji razbija 56-bitni ključ treba obraditi prostor od 2⁵⁶ kombinacija što opet zahtijeva puno više procesorske snage od prije navedenih slučajeva (DES, koji koristi 56-bitni ključ, razbijen je u projektu koji je koristio snagu distribuiranih računala u roku od samo par mjeseci. Noviji pokušaji razbijanja smanjili su to vrijeme na par sati i manje. Također, napravljeno je specijalno sklopovlje nazvano DES cracking machine koje efikasno pronalazi DES ključeve).

Ključeve dužine 64 bita je mnogo teže razbiti, no ipak moguće. Postoje organizacije koje si mogu priuštiti takvu računalnu moć (vlade nekih jačih ekonomskih država, vodeće svjetske kompanije, te neke kriminalne organizacije). Ključevi dužine 80 bita smatraju se dobrim za još neko vrijeme (par godina), ali tek se ključevi sa 128 bita smatraju dovoljno dugačkim i sigurnim za budućnost. Neki algoritmi koriste i puno veće ključeve (160,192, 256... 448 bita). No, kao što je i spomenuto, algoritam nije siguran samim time što koristi veliki ključ. Mnogi algoritmi se mogu razbiti i na druge načine, a ne samo napadom čistom snagom[5].

Neki su se algoritmi u prošlosti (sada sve manje) oslanjali na tajnost algoritma enkripcije, tj. njegovu su neprobojnost temeljili na nepostojanju nikakvih saznanja o tome kako algoritam radi. To je velika greška, jer se obrnutim inženjeringom (eng. reverseengineering) može saznati način na koji radi bilo koji algoritam. Na žalost, takvi su se algoritmi pokazali kao jako slabi jer jednom kada se došlo do spoznaje kako on radi, bilo je lako to znanje iskoristiti za njegovo razbijanje. Općenito, takvi algoritmi nisu pouzdani i treba ih izbjegavati.

Prethodno navedene činjenice su se odnosile ponajviše na simetrične algoritme i njihove ključeve. Kod asimetričnih algoritama problem je postavljen malo drugačije jer je drugačija i njihova problematika. U pravilu, ključevi asimetričnih algoritama (512, 1024, 2048 bita) su puno duži od ključeva simetričnih algoritama (64, 128, 256 ..448 bita). Problem kod razbijanja asimetričnih algoritama je u deriviranju tajnog ključa iz poznatog javnog ključa. Kod dobro smišljenih asimetričnih algoritama to je iznimno teško, no nije nemoguće. Kod RSA algoritma na primjer, to se može postići faktoriziranjem velikog cijelog broja koji ima dva ogromna prim broja za faktore. Kod nekih drugih algoritama primjenjuju se metode izračunavanja diskretnog logaritamskog modula od velikog cijelog broja (što se smatra približno teškim kao i faktoriziranje ako je modulo veliki prim broj).

Za predodžbu težine izračunavanja, navedene su neke tipične dužine ključeva kod asimetričnih algoritama i kompleksnost njihovog razbijanja. Modul 256-bitnih ključeva danas se može lako faktorizirati na kućnim računalima. 512-bitni ključevi zahtijevaju više procesorske snage, no još uvijek ih mogu izračunati računala dostupna akademskoj zajednici. Ključevi dužine 768-bita su sigurniji, no ne treba se na njih previše oslanjati jer u bliskoj budućnosti mogu i oni biti lako razbijeni. Ključevi dužine 1024 bita i više smatraju se sigurnim te se preporuča njihovo korištenje.

Važno je još jednom napomenuti da snaga nekog algoritma ovisi o njegovoj najslabijoj karici. Nijedan aspekt u dizajniranju algoritma ne smije biti zanemaren, počevši od njegovog izbora, implementacije, distribucije ključeva te načina korištenja.

2.2.7 Sažetak poruke

Kao što je ranije spomenuto, kod opisivanja komunikacije između dvije strane često se koriste imena (Ana i Bobi) da bi čitatelj dobio bolju predođbu o dijelovima komunikacije. Iako Ana prilikom slanja poruke Bobiju može istu kriptirati Bobijevim javnim ključem i tako je učiniti tajnom za sve osim Bobija, postoji mogućnost da netko presretne njenu poruku i zamijeni je drugom porukom koja je također kriptirana Bobijevim javnim ključem. Kako bi Bobi bio siguran u autentičnost sadržaja poruke, Ana mora priložiti dokaz da je poruka nepromijenjena. Zbog toga Ana samoj poruci prilaže i sažetak poruke.

Sažetak poruke (eng. message digest) može se usporediti s "digitalnim otiskom prsta"– ne postoje dvije poruke koje imaju isti sažetak. Sažetak poruke računa se pomoću funkcija za izračunavanje sažetka poruke (eng. hash). Hash funkcije su obične matematičke funkcije sa svojstvom da za svaki ulazni niz bilo koje duljine daju izlazni niz iste, fiksne duljine.

H(M) = h,

H – hash funkcija

M - poruka

h – sažetak poruke fiksne duljine

Tako npr. funkcija SHA-1 za ulazni niz bilo koje duljine daje izlazni niz fiksne duljine 160 bitova. Dodatno, ne postoje dva različita ulazna niza za koje hash funkcije daju iste izlazne nizove te je izrazito teško (praktički nemoguće) iz izlaznog niza dobiti ulazni niz. Naravno, činjenica da ne postoje dva različita ulazna niza koja daju isti sažetak nije stopostotno točna, jer (u slučaju SHA1 hash funkcije) postoji "samo" 2¹⁶⁰ sažetaka. Međutim i to je više nego dovoljno da se vjerojatnost da dva različita ulazna niza daju isti sažetak asimptotski približi nuli. Osim SHA1, poznate su hash funkcije MD5, MD4 i MD2.

Prema Jamesu Walshu u knjizi "True Odds – How Risks Affect Your Everyday Life": veća je šansa da grom ubije Vas i još 9 ljudi koje Vi nasumice odaberete nego da izvorna i krivotvorena poruka imaju isti SHA1 sažetak[19]!

Slika 2.3: Računanje sažetka poruke

Bobi, po primitku poruke, razdvaja sažetak poruke od samog sadržaja. Koristeći istu hash funkciju kao i Ana, Bobi računa sažetak poruke koju je primio od Ane, te dobiveni sažetak uspoređuje sa sažetkom kojeg je poslala Ana. Ako su sažeci identični, poruka je do Bobija stigla nepromijenjena, a ako nisu vjerojatno je netko podvalio krivotvorenu poruku. Naravno, postoji opasnost da netko presretne i sadržaj i sažetak poruke, te najprije promijeni sadržaj, a potom sukladno sadržaju promijeni i sažetak. U tom slučaju Bobi neće detektirati da je netko mijenjao izvornu poruku. Kako bi se izbjegla takva situacija koristi se digitalni potpis.

2.2.8 Digitalni potpis

Kada Ana putem interneta šalje poruku Bobiju, on se s pravom može zapitati da li mu baš Ana šalje poruku a ne netko drugi te da li je sadržaj poruke uistinu onaj kojeg je poslala Ana. Ova se pitanja mogu riješiti primjenom digitalnog potpisa koji je zapravo kombinacija sažetka poruke i asimetričnog algoritma. Željene funkcionalnosti digitalnog potpisa su autentificiranje pošiljatelja, očuvanje integriteta poruke, te nemogućnost krivotvorenja i ponovnog korištenja.

Da bi Bobi bio siguran u autentičnost poruke, Ana stvara digitalni potpis tako da najprije izračuna sažetak vlastite poruke uz pomoć neke hash funkcije. Nakon toga taj sažetak kriptira vlastitim privatnim ključem (koji joj inače služi za dekriptiranje).

Slika 2.4: Stvaranje digitalnog potpisa

Kriptirani sažetak poruke (digitalni potpis) svatko može dekriptirati dohvaćanjem Aninog javnog ključa, ali je Ana jedina koja ga je mogla kriptirati korištenjem svog privatnog ključa. Dobiveni digitalni potpis Ana priključuje svojoj izvornoj poruci i šalje Bobiju. Po primitku poruke, Bobi dohvaća Anin javni ključ za kriptiranje (koji se u ovom slučaju unatoč imenu koristi za dekriptiranje) i pomoću njega dekriptira sažetak poruke.

Slika 2.5: Provjera digitalnog potpisa

Slika 2.6: Provjera digitalnog potpisa

Bobi zatim računa sažetak Anine poruke koju je primio uz digitalni potpis i dobiveni sažetak uspoređuje sa sažetkom koji je kriptiran došao s porukom. Ako su sažeci identični, poruka je autentična jer je jedino Ana mogla svojim privatnim ključem kriptirati sažetak.

Slika 2.7: Provjera digitalnog potpisa

Kriptiranje je vremenski skupa operacija. Kriptiranje cijele poruke trajalo bi predugo, pa se zato pribjegava kriptiranju samo sažetka poruke.

Slika 2.8: Razmjena poruka i digitalnih potpisa

Na ovaj se način stvara digitalni potpis poruke, ali nije osigurana i njezina tajnost. Tajnost se može osigurati kriptiranjem poruke primateljevim javnim ključem nakon potpisivanja.

Slika 2.9: Razmjena poruka i digitalnih potpisa

Kriptiranjem nakon potpisivanja osiguravaju se autentifikacija pošiljatelja te integritet i tajnost poruke. Međutim, ostaje pitanje povjerenja.

Slika 2.10: Razmjena poruka i digitalnih potpisa

Na temelju čega Bobi može vjerovati da je Anin javni ključ koji je dohvatio zaista Anin javni ključ? Bobi može osobno poznavati Anu te zatražiti od nje njen javni ključ i vjerovati joj na riječ da je to zaista njezin javni ključ. Ako se Bobi i Ana ne poznaju, jedan od načina je da imaju zajedničkog poznanika Mirka kojem oboje bezuvjetno vjeruju. Ana može svoj javni ključ dati Mirku, a Mirko ga dalje proslijediti Bobiju. Ako Mirko kaže da je to Anin javni ključ, onda mu Bobi bezuvjetno vjeruje. Obzirom da je vrlo teško naći zajedničkog poznanika sa svim ljudima kojima želimo u nekom trenutku poslati tajnu poruku, potrebno je naći pouzdaniji mehanizam.

2.2.9 Digitalna omotnica

Digitalna omotnica osigurava tajnost, ali ne i besprijekornost informacije. Poruku pošiljatelj kriptira proizvoljnim (obično slučajno generiranim) simetričnim ključem K koristeći neki od simetričnih algoritama kriptiranja. Simetrični (sjednički) ključ se kriptira javnim ključem primatelja P_B. Kriptirana poruka i kriptirani ključ čine digitalnu omotnicu:

digitalna_omotnica = { E(m,K); E(K,P_B) }.

2.2.10 Digitalni pečat

Digitalni pečat je digitalno potpisana digitalna omotnica. Digitalnim potpisom nije osigurana tajnost poruke (poruku svatko može pročitati), ali su osigurani autentičnost, integritet i neporecivost. S druge strane, digitalnom omotnicom je osigurana samo tajnost. Digitalni pečat osigurava sva četiri sigurnosna zahtijeva: tajnost, autentičnost, integritet i neporecivost.

3. Pametne kartice

3.1. Uvod

Jedna od glavnih karakteristika evolucije računala je smanjenje njihovih fizičkih dimenzija . Ta se karakteristika najbolje vidi na primjeru pametnih kartica. Nekoć su računala zauzimala prostorije veličine sportske dvorane, a danas se na čipu veličine nekoliko milimetara nalazi računalo mnogo snažnije od svojih velikih predaka.

Pametna se kartica prvi put spominje kao patent francuskog novinara 1974. godine. Deset godina kasnije, upravo u Francuskoj, proizvedena je prva pametna kartica, koja se koristila u telefonskoj industriji. Nakon toga događaja, financijski giganti Europay, Mastercard i Visa udružuju snage s namjerom da pametne kartice što prije zažive u bankarstvu. Rezultat je EMV specifikacija. Ubrzo je i industrija mobilnih komunikacija uvidjela da je njihov interes uzeti dio nove tehnologije, te 1998. izlazi GSM specifikacija. Danas su telefonska i financijska industrija najveći korisnici tehnologije pametnih kartica i ulažu ogromna sredstva u daljnji razvoj.

Sigurnost je najvažnija i najznačajnija osobina pametne kartice koja joj garantira dug život na tržištu i čitav niz uspješnih implementacija[21].

3.2. Vrste pametnih kartica

Postoji više kriterija podjele pametnih kartica u skupine. Mogu se dijeliti po vrsti čipa ili po načinu komunikacije kartice s terminalom. S obzirom na vrstu čipa, kartice dijelimo na memorijske i mikroprocesorske. S obzirom na pristup terminalu, dijelimo ih na kontaktne i bezkontaktne.

Memorijske kartice

Memorijska kartica ima čip s memorijom i neprogramabilnom logikom. Obično pohranjuje do 4K memorije. Tipičan predstavnik memorijske kartice je telefonska kartica. Ona u svojoj memoriji sadrži zapis koji govori o kreditu na kartici; kad se on potroši, kartica postaje neupotrebljiva. Prednost ove vrste kartica je njihova niska cijena.

Mikroprocesorske kartice

Mikroprocesorske kartice sadrže mikroprocesor, čime se značajno podiže razina sigurnosti. Kartica može implementirati razne kriptografske algoritme. Njezina je snaga ograničena memorijskim prostorom i snagom procesora.

Kontaktne kartice

Kontaktne kartice su mikroprocesorske kartice koje komuniciraju s terminalom putem čitača (CAD eng. Card acceptance device). Kartica je spremna za korištenje tek nakon što se umetne u čitač koji je spojen na terminal. Kartica napajanje prima preko čitača. Što se tiče mikroprocesorskih kartica, ovaj je tip u najširoj uporabi.

Bezkontaktne kartice

Radi se o mikroprocesorskim karticama koje za rad ne moraju biti umetnute u čitač, već je dovoljno da budu unutar magnetskog polja CAD uređaja. Kartica sadrži antenu preko koje se obavlja komunikacija s CAD uređajem. Napajanje dolazi indukcijom u magnetskom polju. Ovaj tip kartica najčešće se koristi kao propusnica za ulaz u štićene objekte. Svoju primjenu također nalaze u sustavima za naplatu cestarina.

3.3 Električna i fizička svojstva

Dimenzije

Slika 3.1: Pametna kartica

Mikroprocesor

Mikroprocesor je najvažniji dio kartice. Za razliku od magnetske trake, koja se na karticu lijepi, čip se, radi zaštite od fizičkih utjecaja, umeće u kućište koje se naziva modul čipa.

Slika 3.2: Mikroprocesor pametne kartice

Čipovi se dizajniraju i proizvode specijalno u tu svrhu, od komponenti koje nisu široko dostupne. Proizvode su uglavnom od silicija, koji je neelastičan i lomljiv. Iz tog je razloga njegova površina jako mala (25mm²). Tako mala "radna površina" pred dizajnere stavlja težak zadatak optimiranja rasporeda komponenti.

Kontaktna površina

Pametna kartica ima osam kontaktnih točaka. Dimenzije i lokacije kontakata opisuje norma ISO 7816, 2. dio.

- Na Vcc kontakt se dovodi napajanje. Naponska razina je 3V ili 5V, s maksimalnom devijacijom od 10%. Pametne kartice mobilnih telefona, SIM moduli, imaju napajanje od 3 V.

- RST kontakt služi za slanje reset signala mikroprocesoru, to je tzv. topli reset. Hladni reset se dobiva prekidom signala napajanja. Izvlačenje i ponovno umetanje kartice u CAD uređaj rezultira hladnim reset-om.

- Mikroprocesor pametne kartice nema mogućnost generiranja signala takta. Na CLK kontakt se dovodi vanjski signal takta iz kojeg se derivira unutrašnji takt.

- GND kontakt se koristi kao referentna naponska vrijednost. Najčešće je to nulta naponska razina.

- Vpp kontakt je opcionalan i koristi se samo kod starih tipova kartica. Takvi tipovi kartica zahtijevali su korištenje dviju programskih naponskih razina. Niža naponska razina označavala je pasivno stanje, a viša naponska razina se koristila prilikom pisanja u EEPROM memoriju. Današnje pametne kartice ne koriste taj kontakt, jer moderni mikrokontroleri koriste integriranu strujnu pumpu.

- I/O kontakt se koristi za prijenos podataka i naredbi između pametne kartice i vanjskog svijeta. Komunikacija je dvosmjerna (izmjenični prijenos u oba smjera, ne istovremeno) [21].

Procesor

Većina pametnih kartica koristi 8-bitni procesor baziran na CISC arhitekturi s taktom od 5MHz i 16-bitnim memorijskim adresiranjem. Snažnije kartice mogu imati takt do 40Mhz. Danas se već proizvode 16-bitni i 32-bitni procesori, ali je niska cijena razlog zbog kojeg 8-bitni procesori vjerojatno nikad neće biti istisnuti do kraja.

Koprocesor

Pametne kartice često implementiraju kriptografske algoritme koji mogu biti vrlo zahtjevni. Budući je procesor usko grlo u radu kartice, često se uz procesor ugrađuje i koprocesor zadužen za obavljanje zahtjevnih kriptografskih funkcija. Time kartica dobiva na svojoj snazi, ali raste i njezina cijena.

Memorija

Pametne kartice obično sadrže tri tipa memorije: postojanu ispisnu memoriju, postojanu upisno-ispisnu memoriju i ne postojanu upisno-ispisnu memoriju. ROM , EEPROM i RAM su najčešće korištene memorije. Omjeri veličina pojedinih memorija ovise o namjeni pametne kartice. Obzirom da je RAM ćelija otprilike 16 puta veća od ROM ćelije, uvijek je prisutan zahtjev za što manjom količinom RAM memorije.

ROM (eng. Read Only Memory) se koristi za pohranu nepromjenjivog programskog koda. Sadrži kôd operacijskog sustava i nepromjenjive podatke korisničkih aplikacija. Proces pisanja stalnih programskih komponenti u ispisnu neprogramirljivu memoriju čipa naziva se maskiranje, a obavlja se u fazi proizvodnje kartice. Nakon te faze nemoguće je upisivanje podataka, zapisani podaci mogu se samo čitati. ROM memorija zadržava svoje stanje i bez prisutnosti napajanja.
EEPROM (engl. Electrically Erasable Programmable Read Only Memory) također zadržava svoje stanje kad nema napajanja. Sadržaj memorije se može mijenjati za vrijeme normalnog korištenja kartice. Koristi se za pohranu podataka i korisničkih aplikacija, te funkcionalno odgovara tvrdom disku osobnog računala. Važni električni parametri EEPROM memorije su broj ciklusa pisanja, vrijeme zadržavanja podataka i vrijeme pristupa. EEPROM koji koriste pametne kartice može izvesti barem 100 000 ciklusa pisanja i zadržati podatke dulje od 10 godina. Čitanje EEPROM-a je jednako brzo kao i čitanje RAM-a, ali je zato pisanje u EEPROM 1000 puta sporije od pisanja u RAM.
RAM (engl. Random Acces Memory) se koristi kao privremeni radni prostor za pohranu i modifikaciju podataka. Uklanjanjem napajanja gubi se informacija o sadržaju memorije.

3.4 Komunikacijski model

CAD uređaji

Pametna kartica započinje komunikaciju s ostalim sustavima umetanjem u CAD uređaj. Postoje dvije vrste CAD uređaja: kartični čitač i terminal. Pametna kartica komunicira s računalom pomoću kartičnog čitača koji je na računalo spojen serijskim, paralelnim ili USB portom. Čitač nema mogućnost procesiranja, već isključivo služi za komunikaciju i otkrivanje pogrešaka uslijed neodgovarajućeg transportnog protokola. Terminali su računala kod kojih je čitač integriran kao dio računala. Primjer za takve uređaje su sveprisutni bankomati. Takvi uređaji imaju mogućnost procesiranja, pa tako na primjer bankomat može umanjivati saldo na računu kartice.

Komunikacijski model

Model komunikacije koji koriste pametne kartice omogućava komunikaciju u oba smjera, ali ne istodobno. Dva entiteta, u ovom slučaju kartica i računalo, komuniciraju izmjenjujući podatkovne pakete koje propisuje protokol. Sustav pametnih kartica koristi vlastiti format podatkovnih paketa – APDU (engl. Application Protocol Data Unit) pakete. U APDU paketu se uvijek nalazi ili naredba ili odgovor. Sustav se temelji na korisnik-poslužitelj (engl. client-server) modelu, u kojem kartica preuzima ulogu pasivnog sudionika u komunikaciji; terminal šalje naredbu, a kartica uzvraća odgovorom.

APDU protokol

APDU protokol, specificiran u normi ISO 7816-4, je protokol na razini aplikacija između pametne kartice i terminala. APDU poruke obuhvaćene su s dvije strukture: prvu strukturu koristi aplikacija na strani terminala za slanje naredbi kartici, a drugu kartica za slanje povratnih odgovora aplikaciji terminala. Dotični formati poruka se nazivaju APDU naredba (C-APDU) i APDU odgovor (R-APDU).

ZAGLAVLJE				TIJELO
CLA	INS	P1	P2	Lc	Podatkovno polje	Le

Slika 3.3: Prikaz formata zaglavlja APDU naredbe

TIJELO	STATUSNA RIJEČ
Podatkovno polje	SW1	SW2

Slika 3.4: Prikaz formata tijela APDU naredbe

Zaglavlje APDU naredbe se sastoji od 4 okteta: CLA (oznaka klase kojoj pripada instrukcija), INS (oznaka instrukcije), P1 i P2 (parametri instrukcije). Oktet klase identificira kategoriju APDU naredbe i APDU odgovora. Instrukcijski oktet određuje instrukciju naredbe. Parametri P1 i P2 se koriste kao proširenja funkcionalnosti instrukcije.

Nakon zaglavlja APDU naredbe slijedi tijelo naredbe. Tijelo je opcionalno i varijabilne duljine. Lc polje određuje duljinu podatkovnog polja (broj okteta). Podatkovno polje sadrži podatke koji se šalju kartici za izvršavanje instrukcije specificirane u zaglavlju. Posljednji oktet APDU naredbe je Le polje. Le polje definira koliki broj okteta očekuje aplikacija terminala u sljedećem APDU odgovoru. Kartica šalje APDU odgovor koji se sastoji od opcionalnog tijela i obaveznog završnog dijela. Tijelo obuhvaća podatkovno polje čija je duljina određena Le poljem odgovarajuće APDU naredbe. Završni dio se sastoji od dva polja, SW1 i SW2, koja zajedno tvore statusnu riječ. Statusna riječ opisuje u kojem je radnom stanju kartica nakon što izvrši instrukciju APDU naredbe. Npr. statusna riječ "0x9000" znači da je kartica uspješno i u potpunosti izvršila naredbu.

Iz činjenice da C-APDU i R-APDU uvijek dolaze u paru i da je podatkovno polje opcionalno u obje APDU strukture, proizlaze četiri moguća slučaja APDU komunikacije.

TPDU protokol

TPDU (engl. Transport Protocol Data Unit) protokol je protokol niže razine – transportni protokol definiran u ISO 7816-3 normi. Na ovom mjestu se može povući paralela s ISO OSI referentnim sustavom. U toj usporedbi APDU protokol bi predstavljao 7. OSI sloj, a TPDU protokol 6. OSI sloj. Ispod toga se nalaze niži slojevi, odnosno "žice" kojima se prenose električni impulsi.

U kartičnim sustavima su najraširenija dva tipa transportnih protokola; T=0 protokol i T=1 protokol. Oba protokola su asinkrona i dvosmjerna. Razlika je u tome što je T=0 oktet orijentiran protokol kod kojeg je najmanja jedinica prijenosa 1 oktet, dok je T=1 blok orijentiran protokol kod kojeg je najmanja jedinica prijenosa blok (niz okteta). T=0 protokol je zastarjeli protokol koji «ne vidi» gore navedenu podjelu komunikacijskog sustava na slojeve. Suprotno tome, T=1 protokol ukalupljuje APDU pakete u TPDU jedinice. Time se omogućava ulančavanje poruka i kriptiranje sadržaja ADPU poruka.

ATR

Kad se na kontaktnu površinu kartice dovede signal napajanja, takta i reseta, kartica preko I/0 linije terminalu šalje ATR (engl. Answer To Reset) poruku. To je poruka koja sadrži parametre potrebne za uspostavljanje komunikacije. Duljina poruke je maksimalno 33 okteta, a sadrži podatke o tipu prijenosnog protokola, brzini prijenosa i druge informacije koje terminal mora znati da bi započeo komunikaciju.

PTS

Kad terminal primi ATR naredbu, komunikacija može započeti. Prije samog početka terminal može poslati PTS (engl. Protocol Type Selection) poruku, kojom može promijeniti neki od parametara komunikacije. PTS poruka se mora poslati neposredno nakon primitka ATR naredbe. Nakon ATR naredbe može se poslati samo jedna PTS poruka.

3.5 Operacijski sustav

Operacijski sustav pametnih kartica ima jako malo sličnost s operacijskim sustavima koje obično susrećemo na računalima. Ne postoji korisničko sučelje i nema mogućnost pristupa vanjskim jedinicama za pohranu podataka. Njegova osnovna zadaća je upravljanje komunikacijom.

Norma ISO 7816-4 predstavlja temelj većine današnjih operacijskih sustava pametnih kartica. Njegova najvažnija karakteristika je datotečna orijentacija. Kao posljedica toga, korisnička aplikacija se predstavlja podatkovnom datotekom, a naredbe za pristup aplikacijskim podacima definira operacijski sustav. Upravo zbog te karakteristike, odnosno nedovoljno jasnog razdvajanja operacijskog sustava i korisničke aplikacije, razvila se potreba za novim tehnologijama. Jedna od njih je i Java Card tehnologija.

3.6 Životni ciklus kartice

Prema normama ISO 10202-1 razlikujemo 5 faza životnog ciklusa kartice.

Tablica 3.1: Životni ciklus pametne kartice

Faze životnog ciklusa kartice	Tipične aktivnosti
Faza 1: Proizvodnja čipa i proizvodnja kartice	Dizajn čipa Generacija operacijskog sustava kartice Proizvodnja čipa i modula Proizvodnja tijela kartice Ugrađivanje modula u tijelo kartice
Faza 2: Priprema kartice	Završavanje operacijskog sustava kartice
Faza 3: Priprema aplikacije	Inicijalizacija aplikacije/a Personalizacija aplikacije/a
Faza 4: Korištenje kartice	Aktiviranje aplikacije Deaktiviranje aplikacije
Faza 5: Kraj korištenja kartice	Deaktiviranje aplikacije Deaktiviranje kartice

4. PKI infrastruktura

4.1 Uvod

IETF definicija PKI sustava glasi: PKI je skup sklopovlja, programske opreme, ljudi, pravila i funkcija potrebnih za stvaranje, upravljanje, pohranjivanje, distribuiranje i opozivanje certifikata baziranih na kriptografiji javnim ključem[1].

PKI pruža osnovnu sigurnost potrebnu za sigurnu komunikaciju takvu da korisnici, koji se međusobno ne poznaju ili su dosta udaljeni, mogu sigurno komunicirati kroz lanac povjerenja. PKI se stoga naziva i hijerarhijom povjerenja. Povjerenje je građevni blok infrastrukture javnog ključa i ono se u svijetu interneta klasificira pomoću slijedećeg:

Privatnost. Ostvaruje se korištenjem kriptiranja. Poruka se pretvara u drugačiji tekst korištenjem algoritama enkripcije i samo osobe sa ispravnim ključem za dekriptiranje mogu dobiti originalnu poruku.
Integritet. Jamči da je ono što je primatelj primio upravo ono što je pošiljatelj poslao. Nema gubitka informacija.
Neporecivost. Osigurava da korisnik ne može negirati da je poslao poruku ili sudjelovao u transakciji (Zakon o elektroničkom potpisu [Hrvatski sabor, 2002])[20].
Autentifikacija. Utvrđuje da je entitet ono što tvrdi da jest. Digitalni certifikat povezuje identitet s jedinstvenim ključem.

Temeljni dio kriptiranja kod PKI-a čini par ključeva; javni i privatni ključ. Svaki korisnik posjeduje svoj jedinstveni par ključeva. Jedan ključ iz para je privatni i njime se koristi samo njegov vlasnik, a drugi je ključ javan i dostupan svima. Ključevi u paru vezani su složenim matematičkim algoritmom (RSA algoritam) koji jamči slijedeće:

posjedovanjem javnog ključa nije moguće otkriti privatni ključ,
sve što je šifrirano privatnim ključem moguće je dekriptirati samo javnim ključem i obratno.

Kriptografija javnim ključem manifestira se kroz kriptiranje i digitalno potpisivanje. Poruka se kriptira pomoću javnog ključa osobe kojoj poruku šaljemo. Na taj način samo primatelj može dekriptirati poruku s odgovarajućim privatnim ključem. Kod digitalnog potpisivanja izračunava se sažetak (engl. hash) poruke, koji je jedinstven za svaku poruku, a čime se onemogućava kopiranje već korištenog potpisa. Pošiljatelj potpisuje sažetak poruke svojim privatnim ključem, a primatelj utvrđuje autentičnost javnim ključem pošiljatelja. Tj. iz primljene poruke se vadi kriptirani sažetak, dekriptira se javnim ključem pošiljatelja, te se iz primljene izvorne poruke računa novi sažetak i uspoređuje sa dobivenim. Ukoliko su isti, dokazuje se identitet pošiljatelja i integritet poruke (funkcija sažetka je jednosmjerna, te je nemoguće iz dobivenog sažetka dobiti izvornu poruku).

Slika 4.1: Razmjena poruka i digitalnih potpisa

Privatni ključ nije dostupan svima i stoga je zaštićen lozinkom. U tu se svrhu dodatna sigurnost PKI sustava ostvaruje uporabom pametnih kartica. Pored pohrane privatnog ključa, digitalni potpis se generira unutar sigurnog okruženja čipa. Na taj način privatni ključ nikada ne napušta karticu i nije dostupan aplikacijama izvan čipa. Za korištenje pametne kartice potreban je osobni broj ili PIN (engl. Personal Identification Number), koji posjeduje samo korisnik - vlasnik pametne kartice i čitač kartice koji se priključi na računalo. Zaštita i čuvanje pametne kartice i PIN-a obaveza su svakog korisnika usluge[2].

Primjeri korištenja PKI-a:

Osiguravanje transakcija između poslovnih partnera i krajnjih klijenata preko javne mreže, kao što je Internet, korištenjem SSL-a,
Internet bankarstvo,
Autentifikacija korisnika i kontrola pristupa kroz identifikaciju baziranu na certifikatima,
Neporecivost; digitalni certifikat potvrđuje korisnikov identitet, tako da je poslije nemoguće poricati digitalno potpisanu transakciju (npr. kupovanje na Web stranicama).

4.2 PKI komponente

Dijelovi PKI sustava:

Certifikacijski centar (CA): izdaje i povlači certifikate, održava informacije o stanju certifikata, objavljuje valjane certifikate.
Registracijski centar (RA): provjerava sadržaj certifikata za CA.
Repozitorij: distribuira certifikate i liste opozvnih certifikata u realnom vremenu.
Krajnji entiteti (korisnici): osobe ili oprema.

Slika 4.2: PKI infrastruktura

4.2.1 Certifikacijski centar

Certifikacijski centar je treća strana povjerenja (engl. Trusted Third Party). Javni ključevi se distribuiraju u formi certifikata javnog ključa. CA je temeljni dio PKI-a s obzirom da je jedina komponenta koja može izdavati certifikate. CA koji je izdao određeni certifikat digitalno ga potpisuje (time se povezuje ime subjekta sa javnim ključem). CA je također odgovoran za izdavanje liste opozvanih certifikata (CRL) osim u slučaju kad je ta funkcija dodijeljena odvojenom izdavatelju CRL-a.

4.2.2 Registracijski centar

RA obrađuje zahtjeve korisnika za izdavanje certifikata, registrira korisnike i surađuje sa CA u poslovima izdavanja certifikata. Cilj RA je identifikacija korisnika i osiguravanje neporecivosti – da li je digitalni identitet izdan pravoj osobi? RA predstavlja sučelje između krajnjeg korisnika i CA, te obavlja slijedeće funkcije:

Potvrđuje atribute subjekta koji zahtijeva certifikat,
Potvrđuje da subjekt ima vlasništvo nad registriranim privatnim ključem,
Generira par privatni/javni ključ,
Upravlja interakcijom sa CA (ili nekoliko njih) kao posrednik krajnjeg entiteta, uključujući obavještavanje o kompromitiranju ključa i zahtjev za oporavak ključa.

4.2.3 Repozitorij

Repozitorij se koristi za distribuiranje certifikata i statusa izdanih certifikata. Najčešće upotrebljavana usluga repozitorija je LDAP poslužitelj. CA objavljuje certifikate u repozitorij, a klijenti ih dohvaćaju pomoću LDAP bazirane klijentske aplikacije. LDAP implementacija može biti jednostavan LDAP poslužitelj ili potpuni X.500 proizvod.

Status certifikata može imati dvije forme. Ukoliko je to CRL ili CDP (CRL Distribution Point), koristi se LDAP poslužitelj. CRL se objavljuje na LDAP poslužitelj, te klijent dohvaća najnoviji CRL. Druga se forma zove On-line Certificate Status Protocol (OCSP). U tom slučaju, priručni spremnik (engl. cache) (forma repozitorija), pohranjuje status certifikata. Svaki put kada klijentova aplikacija odluči koristiti certifikat, postavit će OCSP priručnom spremniku upit o valjanosti certifikata.

4.2.4 Krajnji entiteti

Krajnji entiteti najčešće predstavljaju krajnje korisnike-ljude. No, to mogu biti i razni uređaji kao što su usmjeritelji, poslužitelji, aplikacije/servisi ili bilo što drugo što se može identificirati u imenu subjekta certifikata javnog ključa. Kao krajnji entiteti mogu biti predstavljeni i pružatelji usluga (podrške) vezanih uz PKI. Tako se iz perspektive CA, RA smatra krajnjim entitetom.

4.3 PKI funkcije upravljanja

4.3.1 Registracija

Krajnji entiteti se moraju učlaniti u PKI prije nego što počnu koristiti njegove usluge. Registracija je prvi korak u tom procesu i predstavlja obradu zahtjeva za certifikacijom. Ovaj korak je najčešće povezan s inicijalnom provjerom identiteta krajnjih entiteta. Proces registracije se može postići direktno sa CA ili preko RA. Isto tako može biti on-line ili off-line (ili kombinacija oba). U registracijskom postupku, u skladu s certifikacijskom politikom i pravilima o izdavanju certifikata, potrebno je odrediti u koje će se svrhe certifikat koristiti i koliki će biti period valjanosti certifikata[3].

4.3.2 Inicijalizacija

Inicijalizacija slijedi nakon registracije. Ovaj se korak najčešće odnosi na povezivanje krajnjeg entiteta s parom ključeva. Generira se par ključeva što uključuje stvaranje para javni/privatni ključ, koji je povezan s krajnjim entitetom. Ključeve može generirati RA, CA ili neka druga komponenta.

4.3.3 Certifikacija

Certifikacija je zaključni dio učlanjivanja krajnjeg entiteta u PKI. Ovaj korak uključuje izdavanje certifikata javnog ključa od strane CA. Ukoliko je zahtjev za certifikacijom odobren, CA će potpisati podatke i javni ključ iz zahtijeva. Kada je generiran, certifikat se daje krajnjem entitetu i/ili objavljuje u repozitoriju.

4.3.4 Oporavak para ključeva

Parovi ključeva se mogu koristiti kao potpora pri stvaranju digitalnog potpisa, za provjeru, kriptiranje i dekriptiranje ili oboje. Kada se koriste za kriptiranje/dekriptiranje, važno je omogućiti mehanizam oporavka ključeva potrebnih za dekriptiranje, jer se može dogoditi da "normalan" pristup sadržaju ključeva nije moguć. U tom slučaju nije moguće moguće obnoviti kriptirane podatke. Normalan pristup ključevima dešifriranja može rezultirati zaboravljenom lozinkom, štetom na sklopovlju i sl. Oporavak para ključeva omogućuje krajnjim entitetima povratak ključeva od autoriziranog sustava za pohranu (engl. backup) ključeva.

4.3.5 Ažuriranje ključeva

Certifikati se izdaju s fiksnim vremenom trajanja (dvije do pet godina) i nakon toga ističu. Ažuriranje para ključeva uključuje generiranje novog para ključeva i izdavanje novog certifikata, a može se pojaviti s unaprijed danim istekom vremena. Tako se legitimni par ključeva uvijek nalazi u vlasništvu krajnjeg entiteta. Moguće je utemeljiti različite periode valjanosti za ključeve koji se koriste za digitalno potpisivanje i provjeru.

4.3.6 Zahtjev za opoziv

Certifikati se izdaju s dugim vremenom trajanja, no certifikat može isteći i prije, zbog raznih okolnosti kao što su promjena imena, kompromitiranje ključa i sl. Zbog toga je potrebno opozvati certifikat prije isteka vremena trajanja certifikata. Zahtjev za opoziv može doći i od krajnjeg entiteta (ili RA). Informacije o opozivu moraju biti dostupne od CA koji je izdao certifikat ili od izdavatelja CRL-a kojemu je CA povjerila tu funkciju. Krajnji entiteti moraju provjeravati status opoziva svih certifikata u certifikacijskoj putanji. To uključuje informacije o opozivu krajnjih entiteta i prijelaznih CA.

4.3.7 Međusobno certificiranje

Međusobno certificiranje se pojavljuje između CA centra. Cross certifikat je zapravo certifikat javnog ključa koji je jedan CA izdao drugom. Drugim riječima, to je certifikat koji sadrži javni ključ jednog CA, a digitalno ga je potpisao drugi CA. Budući da PKI sustav može imati više CA, moguće je da dva korisnika PKI sustava imaju javne ključeve certificirane kod različitih CA, a koji nisu podređeni istom vršnom CA. Međusobno certificiranje CA korisnicima omogućuje međusobnu autentifikaciju u takvoj situaciji. [5]

Slika 4.3: Međusobna certifikacija

5. X.509 certifikat javnog ključa

5.1 Uvod

Certifikat je najvažniji dio cjelokupnog PKI sustava. Na njemu počiva uzajamno povjerenje vlasnika certifikata i onoga tko certifikat provjerava. Certifikat jednoznačno povezuje osobu uz njezin javni ključ - potvrđuje identitet osobe. Sprječava se lažno predstavljanje sudionika u elektroničkim transakcijama, kao i otkrivanje tajnih informacija osobama koje za to nisu ovlaštene. U javnom životu certifikat bi predstavljao ekvivalent osobnoj iskaznici i u tom smislu, u komunikaciji putem interneta, osigurava međusobnu identifikaciju strana koje komuniciraju.

Kako bi podržavao automatsko obrađivanje i da bi se mogao distribuirati putem interneta, certifikat mora biti digitalni objekt i mora biti kodiran u standardnom formatu. Široko prihvaćen standardni format certifikata javnog ključa je X.509 certifikat javnog ključa. X.509 je prvi put objavljen 1988., a u međuvremenu su se pojavile još dvije verzije. Sve moderne implementacije PKI-a generiraju i obrađuju certifikate X.509 verzije 3 (X.509 v3), koja je uvela proširenja certifikata. Proširenja se koriste kada izdavatelj želi uključiti informacije koje nisu podržane osnovnim poljima certifikata. Nedavno je dovršen i certifikat X.509 v4, no on ne mijenja format certifikata nego definira neka nova proširenja[5].

Vrste certifikata su:

Certifikati krajnjih korisnika. Ovi certifikati se izdaju subjektima koji nisu CA. Moraju sadržavati dostatnu informaciju da bi korisnici certifikata ustanovili da li je javni ključ prikladan za određene aplikacije. Subjekt certifikata krajnjeg entiteta može biti čovjek ili sustav (npr. web server ili usmjeritelj).
CA certifikati. Ovi certifikati su izdani subjektima koji jesu CA. Oni su dio certifikacijskog puta. Javni ključevi iz ovih certifikata se koriste za provjeru digitalnog potpisa na certifikatima i listi opozvanih certifikata. Moraju sadržavati dostatnu informaciju za korisnike, za konstruiranje certifikacijskog puta i lociranje CRL-a. Subjekt CA certifikata može biti drugi CA unutar istog PKI sustava, CA iz drugog PKI sustava ili mosni CA.
Samoizdani certifikati. To je posebna vrsta CA certifikata kod kojega su izdavatelj i subjekt isti. Samoizdani certifikati se koriste za utemeljenje točaka povjerenja, distribuiranje novih javnih ključeva i modificiranje skupa certifikacijskih pravila podržanih u PKI-u.

Digitalni certifikat se koristi u dvije svrhe:

Javni ključ dostupan je drugim osobama koje mogu koristiti taj ključ kako bi poslali šifrirane poruke, poruke koje može čitati samo vlasnik privatnog ključa. Druge osobe ne mogu čitati te šifrirane poruke.
Potvrđuje identitet kada se šalju poruke drugim osobama. Drugim riječima, služi kao dokaz da ste vi osoba za koju tvrdite da jeste.

5.2 Komponente certifikata

X.509 certifikat možemo promatrati kao tri ugniježđene komponente. Prva komponenta je tzv. tamper-evident omotnica na kojoj su jasno vidljivi znaci promjena i koju osigurava digitalni potpis. Unutar omotnice nalazi se osnovni sadržaj koji uključuje informacije obavezne za svaki certifikat. Osnovni sadržaj može uključivati skup proširenja po izboru. Većina certifikata, danas generiranih, uključuje sve tri komponente; omotnicu, osnovni sadržaj i proširenja. Slika 5.1 prikazuje strukturu X.509 certifikata.

5.2.1 Tamper-evident omotnica

"Tamper-evident" omotnicu možemo promatrati kao prozirnu, plastičnu omotnicu oko sadržaja certifikata. Poruka se može lako pročitati, ali se ne može mijenjati bez oštećivanja omotnice. Na ovoj razini certifikat ima samo tri polja:

Potpisani certifikat
Algoritam potpisa: sadrži identifikator algoritma i identificira algoritam digitalnog potpisa koji je izdavatelj koristio pri potpisivanju certifikata.
Vrijednost potpisa: sadrži digitalni potpis koji je kodiran kao bit string.

Slika 5.1: Sadržaj digitalnog certifikata

5.2.2 Osnovni sadržaj certifikata

Certifikat koji treba biti potpisan (engl. to-be-signed certificate) sadrži sve osnovne informacije certifikata. Sadrži minimalno šest polja:

serijski broj Cijeli broj koji izdavatelj dodjeljuje svakom certifikatu. Serijski broj mora biti jedinstven za svaki certifikat koji je generirao određeni izdavatelj. Kombinacija imena izdavatelja i serijskog broja jedinstveno određuje svaki certifikat.
potpis Polje potpisa sadrži identifikator algoritma. To je kopija algoritma potpisa sadržanog u polju algoritma potpisa. Digitalni potpis štiti ovu vrijednost.
ime izdavatelja Sadrži X.500 jedinstveno ime (engl. distinguished name) izdavatelja. Ovo polje mora biti popunjeno. Jedinstveno ime je strukturirano tako da podržava hijerarhijski sustav imenovanja. Atributi imenovanja su: C=država (engl. country), O=organizacija (engl. organization), OU= organizacijska jedinica (engl. organizational unit), L=mjesto (engl. locality), CN=ime (engl. commom name) Npr. C=HR; O=FINA; OU=RDC; CN=ANA
period valjanosti Ovo polje ima dvije komponente. Datum kada je certifikat postao valjan, ne prije (engl. notBefore), te datum kada certifikat ističe, ne kasnije (engl. notAfer).
javni ključ Ovo polje sadrži subjektov javni ključ i identifikator algoritma. Parametri unutar ovog polja sadrže važne informacije o javnom ključu.
subjekt Sadrži jedinstveno ime (dn) onoga tko posjeduje privatni ključ uparen s javnim ključem certifikata. Subjekt može biti CA ili krajnji entitet. Zbog certifikacijske putanje, ime subjekta u CA certifikatu mora se poklapati s imenom izdavatelja certifikata koji slijedi.

Postoje četiri izborna polja:

verzija Ovo polje opisuje sintaksu certifikata. Ukoliko se izostavi, certifikat se kodira po verziji 1 koja ne uključuje jedinstvene identifikatore i proširenja. Verzija 2 uključuje jedinstvene identifikatore bez proširenja, dok verzija 3 uključuje i identifikatore i proširenja.
jedinstveni ID izdavatelja i subjekta Svrha jedinstvenog ID-a izdavatelja i subjekta je ponovno korištenje imena izdavatelja i subjekta nakon nekog vremena. Međutim, preporuka je da se ova polja izostave.
proširenja Ovo se polje pojavljuje samo u verziji 3. Svako proširenje uključuje identifikator proširenja, kritičnu zastavicu i vrijednost proširenja.

5.2.3 Proširenja certifikata

Raniji razvoj PKI-a je pokazao da je osnovni sadržaj certifikata nedovoljan. Korisnici certifikata nisu bili u mogućnosti odrediti važne informacije o izdavatelju, subjektu i javnom ključu. Proširenja certifikata dopuštaju da CA uključi informacije koje nisu podržane osnovnim sadržajem certifikata. Svaka organizacija može definirati privatna proširenja, no većina uvjeta može biti zadovoljena upotrebom standardnih proširenja, koja su široko podržana komercijalnim proizvodima.

Proširenja imaju tri komponente: identifikator proširenja, kritičnu zastavicu i vrijednost proširenja. Identifikator proširenja je OID (engl. object identifier), sekvenca cijelih brojeva koja jedinstveno identificira objekt i ukazuje na format i semantiku vrijednosti proširenja. Kritična zastavica ukazuje na važnost proširenja. Kada je postavljena, informacija je neophodna za uporabu certifikata. Zato se certifikat ne smije koristiti ukoliko se naiđe na nepoznato kritično proširenje. Isto tako, nepoznato nekritično proširenje može se ignorirati.

Proširenje tipa subjekta. Nesposobnost određivanja da li certifikat pripada CA-u ili krajnjem entitetu otežava konstrukciju certifikacijske putanje. Proširenje osnovnim ograničenjima rješava ovaj problem. Osnovna ograničenja također uključuju ograničenje duljine putanje. To izborno polje sadrži cijeli broj koji pokazuje maksimalan broj slijedećih CA certifikata u certifikacijskoj putanji. Ako je duljina putanje specificirana kao nula, u obzir se uzimaju samo certifikati krajnjih entiteta.

Proširenje imena. Alternativno proširenje imena, subjektova i izdavateljeva alternativna imena su dodatna imena koja bi bila osigurana za CA i subjekt certifikata. Ta alternativna imena mogu preuzeti bilo koju formu (e-mail adresa i DNS ime u certifikatima za ljude, URL i DNS imena za računala(osobito servere) te IP adrese i DNS imena za usmjeritelje i servere).

Atributi ključa. Većina CA centara i krajnjih entiteta imaju više od jednog para javni/privatni ključ i ne koriste isti par ključeva za implementiranje različitih sigurnosnih usluga. Kako bi razlikovali javne ključeve u različitim certifikatima, CA koristi četiri različita proširenja certifikata: namjena ključa (opisuje sigurnosne usluge za koje se javni ključ koristi), proširena namjena ključa (ukazuje na aplikacije specifične za javni ključ), identifikator ključa autoriteta (ako CA ima nekoliko ključeva za potpisivanje certifikata, ovo proširenje daje ispravan ključ za provjeru određenog potpisa) i identifikator subjektovog ključa (ako subjekt ima više certifikata, omogućuje brzo identificiranje certifikata s ključem koji nas zanima).

Informacije o pravilima. Postoje dva standardna proširenja ovog tipa: proširenje Certificate Policies i Policy Mapping. Certificate Policies se odnosi na pravila pod kojima je certifikat izdan, kod CA certifikata se odnosi na pravilo pod kojim CA radi. Policy mapping se koristi kod CA certifikata za prevođenje informacija o pravilima između dvije domene pravila (između dva CA centra).

Dodatne informacij. Kako bi provjerio certifikat, korisnik certifikata mora dobiti CA certifikat sa kojega uzima javni ključ, te pomoću njega provjerava potpis certifikata. Nakon toga konzultira najnoviji CRL radi utvrđivanja valjanosti certifikata. Kako bi dobio certifikate ili CRL iz direktorija, korisnik mora znati samo jedinstveno ime iz certifikata. No, ako se pristupa nekom drugom repozitoriju, korisnik mora znati jedinstveno ime, adresu repozitorija koji sadrži informaciju i protokol pristupa. Svaki CA u certifikacijskoj putanji može koristiti drugi repozitorij. Postoji nekoliko standardnih proširenja koja korisnicima daju dodatne informacije: CRL točka distribucije, najsvježiji CRL, pristup informacijama centra, pristup informacijama subjekta i drugo. CRL točka distribucuje govori korisniku gdje i kako dobiti CRL potreban za utvrđivanje da li je certifikat opozvan. Ovo proširenje sadrži jednu ili više distribucijskih točaka i svaka opisuje lokaciju odgovarajućeg CRL-a.

Slika 5.2: Digitalni certifikat

5.3 Formati zapisa certifikata

Postoji više načina zapisa digitalnih certifikata. Metode zapisa opisane su u ASN.1 sustavu (Abstract Syntax Notation) [7][9].

5.3.1 ASN.1 notacija

ASN.1 (Abstract Syntax Notation One) je notacija za opis apstraktnih tipova i vrijednosti. Kod ASN.1 tip je skup vrijednosti. Za neke tipove skup vrijednosti je konačan, dok je za neke beskonačan. ANS.1 ima četiri vrste tipova:

jednostavni tipovi (nemaju komponente)
strukturirani tipovi (imaju komponente)
označeni tipovi koji su izvedeni od drugih tipova)
ostali tipovi (uključuju tipove CHOICE i ANY)

Tipovima i vrijednostima mogu se pridjeljivati imena pomoću ASN.1 operatora ::= i ta se imena mogu koristiti u definiranju drugih tipova i vrijednosti.

Svaki ASN.1 tip, osim CHOICE i ANY tipova, ima oznaku koja se sastoji od klase i pozitivnog broja oznake. ASN.1 tipovi su apstraktno jednaki ukoliko imaju brojeve oznaka.

Postoje četiri vrste oznaka:

Univerzalni – za tipove čije je značenje jednako u svim aplikacijama; ovi tipovi su definirani samo u X.208
Aplikacijski – za tipove čije je značenje specifično za aplikaciju
Privatni
Kontekst specifični – za tipove čije je značenje specifično za dani strukturirani tip.

Tablica 5.1 prikazuje neke ASN.1 tipove i njihove oznake

Tablica 5.1: ASN.1 tipovi

Tip	Broj oznake (decimalni)	Broj oznake (heksadecimalni)
INTEGER	2	02
BIT STRING	3	03
OCTET STRING	4	04
NULL	5	05
OBJECT IDENTIFIER	6	06
SEQUENCE i SEQUENCE OF	16	10
SET i SET OF	17	11
PRINTABLE STRING	19	13
T61STRING	20	14
IA5STRING	22	16
UTCTIME	23	17

ASN.1 tipovi i vrijednosti su prikazani na fleksibilan način sa specijalnim pravilima:

višestruki razmaci i prekidi linija promatraju se kao jedan razmak
komentari se označavaju znakovima --
imena vrijednosti i polja, kao i imena tipova sastoje se od velikih i malih slova, znakova, znamenki..

Jednostavni tipovi

Jednostavni tipovi ne sadrže komponente. ASN.1 definira nekoliko jednostavnih tipova. Oni važni za PKCS normu su:

BIT STRING, niz bitova (jedinice i nule).

IA5String, niz IA5 (ASCII) znakova.

INTEGER, cijelobrojna vrijednost.

NULL, null vrijednost.

OBJECT IDENTIFIER, objekt identifikator

OCTET STRING, niz okteta.

PrintableString, niz ispisnih znakova.

T61String, niz of T.61 (8-bitni) znakova.

UTCTime, "coordinated universal time".

Jednostavni tipovi dijele se u dvije kategorije: string tipovi i ne- string tipovi. BIT STRING, IA5String, OCTET STRING, PrintableString, T61String, i UTCTime su string tipovi.

Strukturirani tipovi

Strukturirani tipovi se sastoje od komponenti. ASN.1 definira četiri strukturirana tipa, a svi su bitni za PKCS normu.

SEQUENCE, uređeni skup jednog ili više tipova.

SEQUENCE OF, uređeni skup koji se sastoji od nula ili više pojavljivanja danog tipa.

SET, neuređeni skup jednog ili više tipova.

SET OF, neuređeni skup koji se sastoji od nula ili više pojavljivanja danog tipa.

Implicitno i eksplicitno označeni tipovi

Označavanje je korisno u svrhe razlikovanja tipova unutar aplikacije. Osim toga koristi se i za razlikovanje tipova komponenti unutar strukturiranih tipova. Postoje dva načina označavanja tipova: eksplicitni i implicitni.

Implicitno označeni tipovi izvedeni su od drugih tipova promjenom njihovih oznaka. Eksplicitno označeni tipovi izvode se od drugih tipova na način da im se dodaju vanjske oznake.

5.3.2 Jednostavna pravila kodiranja

Jednostavna pravila kodiranja (engl. Basic Encoding Rules) ili BER pružaju jedan ili više načina za prikaz ASN.1 vrijednosti kao niza okteta[14]. Postoje tri metode za dekodiranje ASN.1 vrijednosti pod BER-om. Koja će se metoda odabrati ovisi o tipu vrijednosti i o tome da li je duljina vrijednosti poznata. Te tri metode su:

o primitivna, dekodiranje konačne duljine

o složena, dekodiranje konačne duljine

o složena, dekodiranje beskonačne duljine

Bez obzira na metodu BER, kodiranje se sastoji od tri ili četiri dijela:

o identifikacijski okteti – identificiraju klasu i broj oznake ASN.1 vrijednosti, te pokazuju koja je metoda korištena

o dužinski okteti – za metode koje rade s konačnom duljinom određuju koja je duljina vrijednosti. Za metodu koja radi s beskonačnom duljinom kažu da se radi o beskonačnoj duljini.

o sadržajni okteti – za primitivnu metodu prikazuju konkretan prikaz vrijednosti. Za složene metode prikazuje konkatenaciju vrijednosti.

o "kraj-vrijednosti" okteti – za složenu metodu s beskonačnom duljinom označavaju kraj sadržaja. Za druge metode nisu definirani.

Primitivna metoda konačne duljine

Ova metoda se koristi kod primitivnih tipova i tipova izvedenih iz primitivnih tipova. Zahtijeva da se podatak o duljini vrijednosti zna unaprijed. Dijelovi BER dekodiranja su:

o identifikacijski okteti – postoje dvije vrste: niski brojevi oznaka (za brojeve oznaka između 0 i 30) i visoki brojevi oznaka (za brojeve oznaka veće od 31)

o dužinski okteti – postoje dvije vrste: kratki (za duljine između 0 i 127) i dugi (za duljine između 0 i 2¹⁰⁰⁸-1)

o sadržajni okteti – daju konkretan prikaz vrijednosti.

Složena metoda konačne duljine

Ova se metoda koristi kod jednostavnih tipova, strukturiranih tipova i tipova izvedenih od bilo kojih drugih pomoću eksplicitnog označavanja. Zahtijeva da se podatak o duljini vrijednosti zna unaprijed. Dijelovi BER dekodiranja su:

o identifikacijski okteti – isto kao u prethodnom poglavlju osim što bit 6 ima vrijednost "1" čime se definira da se radi o složenom dekodiranju

o dužinski okteti – kao u prethodnom poglavlju

o sadržajni okteti – konkatenacija BER dekodiranja komponenti vrijednosti je:

o za jednostavne string tipove i tipove izvedene od njih pomoću implicitnog označavanja konkatenacija BER dekodiranja podstringova

o za strukturirane tipove i tipove izvedene od njih pomoću implicitnog dekodiranja konkatenacija BER dekodiranja komponeneti vrijednosti

o za tipove izvedene od bilo kojih drugih tipova pomoću eksplicitnog označavanja BER dekodiranja tipa od kojeg je izveden

Složena metoda beskonačne duljine

Ova se metoda koristi kod jednostavnih string tipova, strukturiranih tipova, tipova izvedenih iz string tipova i strukturiranih tipova pomoću implicitnog označavanja i tipova izvedenih iz bilo kojih tipova pomoću eksplicitnog označavanja. Ne zahtijeva da se podatak o duljini vrijednosti zna unaprijed. Dijelovi BER dekodiranja su:

o identifikacijski okteti – isto kao u prethodnom poglavlju

o dužinski okteti – jedan oktet

o sadržajni okteti – isto kao u prethodnom poglavlju

o "kraj-vrijednosti" okteti – primitivno dekodiranje konačne duljine vrijednosti s univerzalnom klasom, brojem oznake 0 i duljinom 0.

5.3.3 Posebna pravila kodiranja

Digitalni certifikat postaje koristan kad se svaka ASN.1 vrijednost konvertira u nizove nula i jedinica[14]. Originalni protokol za ovaj tip konverzije bio je BER (opisan u poglavlju 5.3.2). Kao što je i navedeno u tom dijelu, postoji više načina da se ASN.1 objekt kodira pomoću BER pravila. X.509 specifikacija eliminira činjenicu da postoji više načina dekodiranja tako da koristi posebna pravila kodiranja (engl. Distinguished Encoding Rules). DER je podskup BER kodiranja koji pruža jedinstven način kodiranja bilo kojeg ASN.1 objekta.

DER je oznaka/duljina/vrijednost sustav kodiranja kod kojeg je svaka ASN.1 vrijednost predstavljena nizom okteta, gdje je oktet 8-bitni cijeli broj bez predznaka. Bitovi su numerirani; osmi bit je najvažniji, a prvi najmanje važan.

Identifikacijski oktet

Prvi oktet, nazvan identifikacijski oktet, je podijeljen na tri dijela, kao što se vidi na slici.

|Bit |  8 7  |     6       | 5 4 3 2 1    |

|-----------------------------------------|

|    | CLASS | CONSTRUCTED | TAG NUMBER   |

|--------|--------------------------------|

Slika 5.3: Identifikacijski oktet

Svaka ASN.1 vrijednost ima oznaku koja se sastoji od klase i pozitivnog broja oznake. Kako bi se zaobišlo ograničenje koje nameće činjenica da je najveći broj koji se može prikazati pomoću 5 bitova 31, koriste se dvije vrste oznaka. Prva vrsta su niski brojevi oznaka, koji se koriste za brojeve oznaka između 0 i 30. Druga vrsta su visoki brojevi oznaka, koji se koriste za brojeve oznaka iznad 30. Kod visokih brojeva oznaka bitovi od 5 do 1 su postavljeni u 1, što govori da je pravi broj oznake sadržan u jednom ili više okteta koji slijede.

Dužinski oktet

Nakon "identifikacijskog okteta" slijedi "dužinski oktet" koji govori koliko slijedećih okteta čini sadržaj. Kao i u slučaju sa oznakama, postoje dvije vrste duljina. Kratki se oblik sastoji od jednog okteta i koristi se kad je duljina između 0 i 127. Dugi oblik sadrži od 2 do 127 okteta. Kod kratkog oblika osmi bit je postavljen u 0, a duljina je prezentirana preko bitova 0 do 7. Kod dugog oblika osmi bit je postavljen u 1, a bitovi 7 do 0 govore u koliko je slijedećih okteta sadržana informacija o dužini.

6. Jezik Java i računalna sigurnost

6.1 Uvod

Pri dizajniranju Java platforme i programskog jezika velika važnost posvećena je sigurnosti. Isto tako, ta se podrška revidirala kako je šire korištenje Java tehnologije donosilo nove izazove.

Visok stupanj sigurnosti je postignut korištenjem više metoda. Kao prvo, jezik je dizajniran kako bi bio strog u korištenju tipova podataka i jednostavan za korištenje. Mogućnosti Java platforme, kao što su automatsko korištenje memorije, provjera raspona polja i znakovnih nizova, neke su od stavaka koje potvrđuju tezu da Java platforma i programski jezik pomaže programeru u pisanju sigurnog kôda[12].

Bitan dio sigurnosti Java platforme dolazi iz koncepta virtualnog stroja, u kojoj je kôd interpretiran, te time stalno pod nadzorom izolirajući bajtkod od direktnog pristupa memoriji (registrima) računala, te korištenjem apstraktnih podatka – referenca na objekte umjesto direktnih memorijskih adresa, te samih svojstava jezika. Od tih svojstava, vezanih za sigurnost Java platforme, najvažnija su:

Strogo držanje podatkovnog tipa (engl. Strong Typed) – pridržavanje striktnih pravila nekog tipa podataka bez iznimaka. Svi tipovi podataka poznati su u trenutku prevođenja te se krivo korištenje (npr. pridodavanje varijabli jednog tipa vrijednost drugog tipa) rezultira pogreškom pri prevođenju. Strogo držanje podatkovnog tipa pri prevođenju smanjuje broj pogrešaka pri izvođenju. Uz Javu strogo držanje podatkovnog tipa podržavaju još i npr. Ada, Haskel, dok među jezike koji ne drže strogo podatkovne tipove spadaju C i C++.
Provjera međukôda (engl. Bytecode verification) –specifikacija međukôda je javno dostupna, radi većeg prihvaćanja Java platforme (više implementacija virtualnog stroja). Zlonamjerna bi osoba mogla stvoriti međukôd koji zaobilazi sigurnosne provjere pri izvođenju (provjere pristupa, izvršavanja strojnog kôda (engl. native code)). Provjera međukôda onemogućuje takva manipuliranja bajtkodom koristeći apstraktne automate (engl. Apstract State Machines). Provjera međukôda je donekle ekvivalentna sintaktičkoj i semantičkoj provjeri originalnog koda. Koje provjere radi bajtkod provjera:

1. Provjerava da je prevedeni kod formatiran pravilno.

2. Provjerava interne stogove (engl. stack) da se ne prenapune (engl. overflow) ili preisprazne (engl. underflow).

3. Provjerava da se ne dešavaju ilegalne konverzije, npr. da broj posluži kao pokazivač (referenca), te time sprječava pristup zabranjenim memorijskim područjima.

4. Provjerava da instrukcije međukôda imaju pravilne tipove podataka za neki kontekst.

Provjere tipa podataka pri izvršavanju (engl. Runtime type safety checks) – prilikom izvršavanja programa virtualni stroj provjerava korištenje tipova podataka te krivo korištenje tipa podataka signalizira iznimkom pri izvođenju. Da provjere ne postoje otvorila bi se mogućnost promjene tipa podatka pri izvršavanju. To bi moglo rezultirati zaobilaženjem aplikativnih provjera, ili korupcijom stoga.
Učitavanje koda koristeći učitavatelj klasa (engl. Class loader) – bajtkod prije izvršavanja učitava učitavatelj klasa. Kako kôd koji treba učitati može biti na lokalnom, kao i na udaljenom računalu, učitavanje kôda mora biti sputano određenim pravilima koje učitavatelj klasa primjenjuje. Konkretno, učitavatelj klasa pridjeljuje učitanoj klasi domenu zaštite (engl. protection domain), koja je definirana u sigurnosnoj politici.
Menađer sigurnosti (engl. Security manager) – za izvršavanje posebno sigurnosno osjetljivih operacija (npr. pristup datotečnom sustavu koda učitanog sa udaljenog računala) potrebna su dodatna prava koja menađer sigurnosti dozvoljava, odnosno odbija u ovisnosti o konfiguraciji odnosno kredencijalima koda koji se izvršava definiranim u sigurnosnoj politici.

6.2 Povijest platformne sigurnosti Jave platforme

6.2.1 Originalni Java 1.0 sigurnosni model

Originalni sigurnosni model na Java 1.0 platformi uveo je pojam pješčanika (engl. sandbox). On je postojao s namjerom da osigura vrlo restriktivan okoliš za izvršavanje koda koji je učitan s udaljenog računala (preko mreže). Ideja pješčanika je da lokalni kôd ima puni pristup vitalnim resursima sistema (npr. datotečnom sustavu). Kôdu koji je učitan preko mreže (npr. applet) se ne vjeruje, te on može pristupiti samo limitiranim resursima dostupnim unutar pješčanika. Model pješčanika je prikazan na slici 6.1.

Slika 6.1: Originalni model pješčanika

Model pješčanika je distribuiran u sklopu Java Development Kit-a verzije 1.0, te je kao takav prihvaćen u aplikacijama stvorenim za JDK 1.0, uključujući i web preglednike.

Učitavatelj klasa (engl. class loader) definira zasebni prostor za izvršavanje, koji omogućava da se applet kojemu se ne vjeruje ne može interferirati s drugim programima koji se izvršavaju. JDK 1.1 donosi koncept potpisanog applet-a, kao što je prikazano na slici 6.2. U toj verziji, ispravno digitalno potpisani applet je tretiran kao da je lokalni kôd kojemu se vjeruje, pod uvjetom da je ključ pomoću kojeg je napravljen potpis prepoznat i da mu se vjeruje od strane sustava koji prihvaća applet. Potpisani applet, zajedno sa potpisom, dostavljen je u JAR (Java Archive) formatu. U JDK 1.1, nepotpisani se applet-i još uvijek izvršavaju unutar pješčanika.

Slika 6.2: Model pješčanika

6.2.2 Evoluirani Sandbox model

Od verzije 2 Java platforme (JDK verzije 1.2 na više) napravljene su određene promjene u sigurnosnom modelu i to ponajviše iz sljedećih razloga:

Fino kontrolirana prava – ta je mogućnost postojala i u prijašnjim verzijama. Da bi se iskoristila programer bi morao napisati veliku količinu koda (npr. nasljeđivanjem i preradom SecurityManager klase, ili ClassLoader klasa). Primjer aplikacije koja je koristila fino kontrolirana prava već u prvoj verziji Java platforme je HotJava preglednik – jer je omogućavao korisniku odabir razine sigurnosti.

Mana takvog pristupa jest da je kôd koji ta prava kontrolira iznimno osjetljiv, gledano s aspekta sigurnosti, te zahtijeva veliko znanje i vještinu u području programiranja sigurnosti. Od verzije 2 Java platforme nova arhitektura omogućava daleko jednostavnije i sigurnije kontrole prava.

Sigurnosna politika (engl. Security policy) koju je lako konfigurirati – i ta je mogućnost postojala u prošlim verzijama Java platforme, ali nije bila jednostavna za korištenje. U verziji 2 Java platforme omogućeno je programerima i korisnicima jednostavno konfiguriranje sigurnosne politike bez potrebe za programiranjem.
Kontrola pristupa (engl. access control) koja je jednostavno proširiva – do verzije 1.1 Java Development Kit-a, da bi ste stvorili novu kontrolu pristupa, morate dodati novu check metodu u klasu izvedenu iz SecurityManager klase. Nova arhitektura u Java 2 platformi dozvoljava tipizirane dozvole (od kojih svaka reprezentira pristup nekom od sistemskih resursa), te automatsko obnašanje svih dozvola (uključujući i trenutno ne definirane dozvole prema trenutno ne definiranim resursima) nad nekim tipom. U većini slučajeva nema potrebe za stvaranjem novih metoda u SecurityManager klasi.

6.3 Java 2 sigurnosni model

Domena je skup objekata koje trenutno direktno koristi subjekt (engl. principal), gdje je subjekt entitet u računalnom sustavu kojemu je pristup (a kao nuspojava i odgovornost) dozvoljen. Model pješčanika korišten u Java 1 platformi koristi domensku zaštitu s fiksnom granicom. Koncept domenske zaštite služi kao zgodan mehanizam za grupiranje i izolaciju među dijelovima različitih sigurnosnih postavka.

Domenske zaštite mogu se podijeliti na dvije vrste:

sustavska domena – npr. pristup eksternim resursima kao što su datotečni sustav, mrežni sustav, tipkovnica, itd.
aplikacijska domena – domena definirana aplikacijom i njenim resursima.

Domena konceptualno zatvara skup klasa za čije instance je dozvoljen isti skup dozvola. Domenska zaštita je definirana trenutnom sigurnosnom politikom koja je na snazi. Okoliš (engl. environment) Java aplikacije održava vezu između kôda (klasa i instanca) i njihovih domenskih zaštita i dozvola za tu domenu. Tijek izvršavanja se u potpunosti može događati unutar iste zaštitne domene, ili može uključivati i sistemsku i aplikativnu domenu. Na primjer aplikacija koja ispisuje na ekran poruku, mora koristiti sistemsku domenu koja jedina ima pristup ekranu – u takvom slučaju presudno je da aplikacijska domena ne poprimi dodatne dozvole sistemske domene, što bi imalo ozbiljne sigurnosne implikacije.

Zaključak se lako donosi: domena s manjim skupom dozvola ne smije poprimiti dodatne dozvole pozivom metode iz domene s većim skupom dozvola. Ista diskusija vrijedi i za tijek izvršavanja koji koristi više od dvije zaštitne domene. Jednostavno pravilo prema kojemu se određuje domena, odnosno trenutni skup dozvola, je slijedeće: Skup dozvola je presjek svih dozvola zaštitnih domena kroz koje tijek izvršavanja prolazi. Klasa trenutno ima dozvole koje su zajedničke svim domenama kroz tijek izvršavanja. Ukoliko se pri provjeri dozvola dođe do klase koja je označena kao privilegirana, dozvole tog kôda su presjek dozvola domena do te klase. Primjena privilegirane klase je dobivanje povišenih dozvola. Na primjer, ukoliko aplikaciji (applet-u) nije dozvoljen pristup do datotečnog sustava (npr. datotekama koje sadrže fontove), aplikacija mora povećati svoj skup prava koristeći privilegiranu klasu, te tako zatražiti font (datoteku fonta). Osnovni princip jest da se provjerava cijeli tijek izvršavanja i relevantne dozvole dane zaštitnim domenama. U slučaju da klasa ima traženu dozvolu izvršavanje se dalje nastavlja, a ukoliko nema signalizira se sigurnosnom iznimkom.

Svaka domena (bilo sustavska ili aplikacijska) može implementirati dodatne zaštite svojih internih resursa, unutar svojih vlastitih granica domene. Na primjer, bankovna aplikacija može podržavati zaštitu internih koncepata kao što su računi, te terećenje odnosno odobrenje po tim računima.

6.4 Dozvole i sigurnosna politika

Klase za dozvole predstavljaju dostupnost sustavskih resursa. Iz apstraktne klase java.security.Permission izvode se klase koje predstavljaju konkretnu dozvolu za neki sistemski resurs. Nove dozvole se izvode ili iz Permission klase ili iz neke od već predefiniranih klasa kao što je java.security.BasicPermission. Izvedene dozvole su u pravilu u drugim paketima (ne u java.securtiy), na primjer FilePermission je u paketu java.io. Bitna apstraktna metoda koju klasa izvedena iz Permission klase mora implementirati je implies metoda. Implies metoda definira da li ta dozvola podrazumijeva neku drugu dozvolu. Na primjer pristup cijelom datotečnom sustavu za pisanje i čitanje podrazumijeva i čitanje odnosno pisanje neke konkretne datoteke. Vezana za java.security.Permission klasu je i apstraktna klasa java.security.PermissionCollection i konačna klasa (tj. klasa označena sa final kvalifikatorom) java.security.Permissions.

7. Pregled alata koji dolaze s J2SDK

7.1 Uvod

Java je u sklopu svoje Java 2 platforme isporučila i niz alata koji korisniku pomažu pri razvoju sigurnih aplikacija. Dio tih alata je korišten pri izradi praktičnog dijela ovog diplomskog rada. U ovom poglavlju bit će predstavljen njihov opis sastavljen na temelju dokumentacije koja je dostavljena s alatima. U slijedećim poglavljima koja se tiču praktičnog dijela rada, bit će opisane zamjerke i poteškoće koje se javljaju pri korištenju ovih alata[6].

7.2 Spremište ključeva

Ključevi i certifikati koji se koriste za stvaranje digitalnog potpisa aplikacija i applet-a (više u opisu potpisnika JAR arhiva) skladište se u bazi spremišta ključeva (engl. keystore). Spremište ključeva je zaštićena baza. Zaštićena je lozinkom koja je definirana stvaranjem spremišta ključeva, te se može promijeniti ukoliko se zna trenutna lozinka. Dodatno svaki privatni ključ u spremištu ključeva se može zaštititi zasebnom lozinkom.

Inicijalno spremište ključeva koji dolazi sa Java virtualnim strojem nalazi se u ${java.home}/lib/securty/cacerts (primjeniti lokalni separator direktorija kako je prikladno za određenu platformu). Lozinka za inicijalno spremište ključeva je changeit. U njemu su zapisani CA certifikati kojima se vjeruje, te čijim potpisima (izdanim certifikatima!) se vjeruje ad hoc. Ukoliko se preko mreže učitava JAR arhiva koja je potpisana od strane korisnika čiji je certifikat potpisan od CA certifikata koji nije u cacerts spremištu – onda učitavanje te arhive neće uspjeti. Lokacija je promjenjiva, ali samo za neke podsustave koji to podržavaju.

"cacerts" spremište ključeva dolazi s pet korijenskih CA certifikata sa slijedećim X.500 čitkim imenima:

1. OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

2. OU=Class 2 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

3. OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

4. OU=Class 4 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

5. OU=Secure Server Certification Authority, O="RSA Data Security, Inc.", C=US

Korisničko spremište je spremište ključeva koje korisnik može sam administrirati (dodavati certifikate, stvarati ključeve, itd.) i nalazi se u datoteci .keystore u korisničkom kućnom direktoriju (${user.home}).

7.2.1 Sadržaj spremišta ključeva

Spremište ključeva sadrži dva različita podatka:

Ključeve (i certifikate za njih) pohranjene u sigurnom formatu kako bi se spriječio neautorizirani pristup. Pohranjeni ključ je simetrični ključ ili privatni ključ uparen sa certifikatom odnosno stazom certifikata do CA certifikata.

Nadimak je specificiran pri stvaranju podatka u spremištu, odnosno pri stvaranju para ključeva ili pri uvozu (engl. import) certifikata. Daljnje je korištenje podatka jedino moguće koristeći isti nadimak da bi se naznačilo s kojim podatkom se želi neka radnja obaviti.

7.3 Alat za rad s ključevima

Alat za rad s ključevima (engl. keytool) se koristi za održavanje spremišta ključeva. Omogućava korisnicima administriranje vlastitih privatnih odnosno javnih ključeva i certifikata za njih, koje koriste za autentikaciju, integritet podataka i digitalni potpis. Isto tako, dozvoljava korisnicima spremanje javnih ključeva osoba (u certifikatima), odnosno servisa sa kojima komuniciraju.

Ukoliko neki JCE modul implementira keystore u formatu PKCS#12, nazvan pkcs12, onda treba modificirati keystore.type u datoteci java.security kao u sljedećem primjeru:

keystore.type = pkcs12

Klasa KeyStore u java.security paketu definira sučelje kojime se može pristupiti odnosno mijenjati podatke u spremištu ključeva. Moguće je imati više konkretnih implementacija, gdje se svaka od implementacija koristi određenom vrstom spremišta ključeva. Različite implementacije spremišta ključeva mogu se dodavati instaliranjem dodatnih JCE modula (više o njima u daljnjim poglavljima). Tip spremišta ključeva definira način spremanja i format podataka u spremištu, te algoritme koji se koriste da bi se zaštitili privatni ključevi i integritet samog spremišta.

7.3.1 Podržani algoritmi i veličine ključeva

Alat za rad s ključevima dozvoljava korisnicima da specificiraju algoritam generiranja para ključeva i potpisa koji se koristi, podržan od bilo kojeg registriranog JCE modula. To jest, specificirani algoritmi u keyalg i sigalg opciji moraju biti podržani od implementacije JCE modula. Podrazumijevani algoritam za generiranje ključeva je "DSA".

Algoritam potpisa je vezan za algoritam ključa koji se koristi. Ukoliko je algoritam ključeva "DSA", podrazumijevani algoritam potpisa je "SHA1withDSA", a ukoliko je algoritam ključeva "RSA", podrazumjevani algoritam potpisa je "MD5withRSA". Osim navedenih može se koristiti i kombinacija "SHA1withRSA".

Kada se generira DSA par ključeva, veličina ključa mora biti od 512 do 1024 bitova, te mora biti višekratnik 64. Inicijalna veličina ključa za bilo koji algoritam je 1024 bitova.

7.4 Potpisnik JAR arhiva

Potpisnik JAR arhiva (engl. Jarsigner) se koristi u dvije situacije:

za stvaranje digitalnog potpisa JAR arhive, te
za provjeru digitalnog potpisa (integriteta) JAR arhive.

Kao što je poznato, JAR je skraćeno od "Java archive", arhiva koja omogućava pakiranje više datoteka u jednu kompaktnu arhivu. U arhivi se najčešće nalaze Java klase, te resursi (konfiguracija, slike, zvukovi, podaci). Digitalni potpis arhive je moguć jedino ako onaj koji potpisuje arhivu ima par ključeva, te mu pripadaju i certifikat, koje potpisnik JAR arhiva dobiva iz spremišta ključeva.

Potpisana JAR arhiva, uz digitalni potpis, sadrži i certifikat potpisnika, kako bi provjera potpisa bila jednostavnija. U tom slučaju onaj koji provjerava potpis arhive mora imati samo lanac certifikata do certifikata potpisnika u svom lokalnom spremištu ključeva. Potpisnik za generiranje potpisa podržava DSA enkripciju sa SHA1 algoritmom sažetka ili RSA algoritam enkripcije sa MD5 algoritmom sažetka. Podrazumjevana akcija pri pozivanju potpisnika JAR arhiva je potpisivanje, da bi se provjerio potpis treba koristiti –verify opciju.

7.4.1 Potpisana JAR arhiva

Kada se potpisnik JAR arhiva koristi za generiranje digitalnog potpisa JAR arhive, izlazna JAR arhiva po sadržaju obuhvaća sve što se nalazilo u ulaznoj, te uz te datoteke dodaje još dvije datoteke u META-INF direktorij arhive:

datoteka sa sažetcima (.sf ekstenzija) i
digitalni potpis i lanac certifikata potpisnika (.dsa ekstenzija za DES algoritam, .rsa ekstenzija za RSA algoritam enkripcije)

7.4.2 Datoteka sa sažecima (.sf datoteka)

Datoteka s potpisima izgledom sliči na datoteku Manifest koja je uvijek uključena u JAR arhivu, ukoliko je arhiva stvorena jar alatom.

Format datoteke s potpisima je slijedeći za svaku datoteku u JAR arhivi:

staza do datoteke (relativna prema JAR arhivi),
algoritam sažetka i sažetak

U Manifest datoteci za svaku datoteku u JAR arhivi je izračunat sažetak sadržaja te datoteke, a u .sf datoteci je izračunati sažetak tog zapisa u Manifest datoteci.

7.4.3 Provjera potpisa JAR arhive

Uspješna (pozitivna) provjera JAR arhive se događa kada su potpisi validni, a niti jedna od datoteka u JAR arhivi nije promijenjena od trenutka generiranja potpisa. Sljedeći koraci se koriste za provjeru potpisa JAR arhive:

1. Provjera potpisa .sf datoteke – provjera da je potpis spremljen u .dsa ili .rsa datoteci generiran privatnim ključem čiji je certifikat u lancu certifikata u istoj datoteci, te da je sažetak .sf datoteke jednak sažetku koji je kriptiran privatnim ključem tog certifikata. Time se provjerava da .sf datoteka nije mijenjana.

2. Provjera svakog sažetaka za svaku datoteku JAR arhive upisanog u .sf datoteku za svaku datoteku navedenu u Manifest datoteci – ukoliko .sf datoteka sadrži sažetak Manifest datoteke provjera može provjeriti da li je Manifest datoteka mijenjana. Ukoliko nije mijenjana provjera kreće sa slijede im korakom. Ukoliko je Manifest datoteka mijenjana od trenutka generiranja potpisa, provjerava se da li svaki od sažetaka za pojedine datoteke JAR arhive odgovara sažetku linija za tu datoteku u Manifest datoteci. Jedan od razloga zbog kojeg sažetak Manifest datoteke ne odgovara sažetku Manifest datoteke navedenom u .sf datoteci, je zato što su se nakon generiranja potpisa dodavale datoteke u JAR arhivu, te time mijenjale Manifest datoteku.

Provjera se još uvijek smatra uspješnom (pozitivnom) ukoliko su sve datoteke koje su se nalazile u JAR arhivi nepromijenjene od trenutka kada je potpis generiran.

7.4.4 Višestruki potpisi JAR arhive

JAR arhiva vrlo jednostavno može biti potpisana od više potpisnika pokretanjem potpisnika više puta nad istom arhivom, a koristeći različita spremišta podataka odnosno nadimke.

Na primjer:

jarsigner arhiva.jar lolek

jarsigner arhiva.jar bolek

Kada se JAR arhiva potpisuje više puta, stvara se više .sf i .dsa odnosno .rsa datoteka u toj JAR arhivi. Tako da za primjer dan iznad, JAR arhiva u META-INF direktoriju sadrži datoteke vezane za digitalni potpis arhive:

lolek.sf

lokek.rsa

bolek.sf

bolek.rsa

7.4.5 Naredbe

keystore url

Specificira URL na kojemu se nalazi spremište ključeva. Ukoliko se ne specificira, podrazumijevana lokacija spremišta ključeva je .keystore u korisnikovom kućnom direktoriju. Spremište ključeva je nužno kada se potpisuje, tako da se mora specificirati, ukoliko se ne želi koristiti podrazumijevana ili ukoliko potonja ne postoji.

Nije nužna prilikom provjere, ali ako se specificira ili postoji podrazumijevano spremište ključeva, i –verbose opcija je specificirana, dodatne informacije se ispisuju o tome da li je neki od certifikata potpisnika JAR arhive pronađen u specificiranom spremištu ključeva.

storetype storetype

Specificira tip spremišta ključeva koji će se koristiti. Vrijednost je potrebna samo prilikom stvaranja potpisa JAR arhive.

storepass lozinka

Specificira lozinku koja se koristi za pristup spremištu ključeva. Vrijednost je potrebna samo prilikom stvaranja potpisa JAR arhive. U tom slučaju, ukoliko nije specificirana u komandnoj liniji, korisnika će se upitati za vrijednost.

keypass lozinka

Specificira lozinku koja se koristi za zaštitu privatnog ključa u traženom spremištu ključeva određenog nadimkom u komandnoj liniji sa –alias opcijom. Vrijednost je potrebna samo prilikom stvaranja potpisa JAR arhive, te u tom slučaju samo ukoliko je lozinka od spremišta različita od lozinke za privatni ključ. Ukoliko nije specificirana u komandnoj liniji, a potrebna je, korisnika će se upitati za vrijednost.

sigfile datoteka

Specificira osnovno ime koje se koristi za stvaranje .sf i .dsa odnosno .rsa datoteka. Znakovi moraju biti slova ili brojke te znakovi "_" i "-". Svi znakovi napisani malim slovima biti će pretvoreni u velika slova.

Ukoliko se –sigfile opcija ne koristi u komandnoj liniji, osnovno će se ime stvoriti od prvih osam znakova nadimka specificiranog u komandnoj liniji.

signedjar datoteka

Specificira ime pod kojim će se spremiti potpisana JAR arhiva. Ukoliko nije specificirano, jednako je kao ulazna datoteka, tj. ulazna datoteka će se prepisati sa potpisanom JAR arhivom. Pri tome se ne gube datoteke iz originalne ulazne datoteke.

verify

Ukoliko je specificirana -verify opcija u komandnoj liniji, JAR arhiva će se provjeriti, a ne potpisati. Ukoliko je provjera uspješna (pozitivna), ispisuje se jar verified, a ukoliko se pokušava provjeriti nepotpisana JAR arhiva, ispisuje se jar is unsigned. (signatures missing or not parsable).

7.5 Problemi u radu s Java alatima

Java je zasigurno najkorišteniji jezik koji se koristi u programiranju sustava čiji je zahtjev visok stupanj sigurnosti. Osnovni cilj praktičnog dijela rada je izrada aplikacije pomoću koje se mogu stvarati digitalni potpisi JAR arhiva koristeći certifikate koji se nalaze na kartici. Kao što je navedeno u ovom poglavlju, Java u tu svrhu nudi alat potpisnik JAR arhiva (engl. Jarsigner) koji je komandno linijski program. U toj činjenici leži moja prva zamjerka. Naime, alat koji se pokreće iz komandne linije nije jednostavno povezati s Java aplikacijom te se zahtjeva rad s dretvama. Dobro rješenje, koje se međutim još ne nazire, bila bi izrada klasa koje bi omogućile rad s potpisnikom.

Tu problemi ne prestaju. Verzija Jave 1.5 podržava rad s potpisnikom JAR arhiva međutim iz nepoznatog razloga pokretanje alata rezultira NullPointer iznimkom. Ne postoji objašnjenje zbog čega se ovaj problem javlja, ali je izvjesno da problem muči velik broj programera koji se žale putem Java foruma.

Zbog gore navedenih razloga aplikacija je izrađena u Javi 1.4 uz korištenje komercijalnog IAIK providera[10][11]. Upute za rad s providerom su jako štura i teško je iz njih izvući korisnu informaciju.

8. Pregled normi

8.1 Uvod

Kako kriptografija iz dana u dan sve više napreduje, jedna stvar postaje jasna: ukoliko želi biti učinkovita u onoj mjeri u kojoj joj tehnologija to dopušta, moraju postojati ujednačene norme. Iako će se trgovci i složit oko jednostavnih kriptografskih tehnika, kompatibilnost među implementacija nije zagarantirana.

Upravo su iz tog razloga stručnjaci RSA laboratorija (engl. RSA Laboratories), u suradnji s znanošću, industrijom i američkom vladom razvili obitelj normi pod nazivom Public-Key Cryptography Standards ili skraćeno PKCS.

Ponudili su ove norme tvrtkama i organizacijama koje se bave PKI sustavima i sličnim tehnologijama. Njihov je cilj da u suradnji s tvrtkama do kraja razviju norme koji će biti prihvaćene u potpunosti[8].

Uloga RSA laboratorija sastoji se od četiri dijela:

objaviti pažljivo pisanu dokumentaciju koja opisuje norme,
skupiti mišljenja i prijedloge programera u vezi s nužnim promjenama normi,
objaviti nove verzije normi kad dođe vrijeme za to,
osigurati implementacije i upute za rad s njima.

U procesu stvaranja PKCS normi RSA laboratorij zadržava pravo nad svim dokumentima, iako su svi savjeti i preporuke sa strane poželjni. Cilj RSA laboratorija nije završetak izrade normi, već samo ubrzanje njegovog razvoja. Čim norme dosegnu određeni stupanj prihvaćenosti, RSA laboratorij će se odreći svih svojih prava, te ih prepustiti usavršavanju.

Obitelj PKCS stadarda trenutno uključuje:

PKCS #1: RSA Encryption Standard. Verzija 1.5, Studeni 1993.

PKCS #3: Diffie-Hellman Key-Agreement Standard. Verzija 1.4, Studeni 1993.

PKCS #5: Password-Based Encryption Standard. Version 1.5, Studeni 1993.

PKCS #6: Extended-Certificate Syntax Standard. Verzija 1.5, Studeni 1993.

PKCS #7: Cryptographic Message Syntax Standard. Verzija 1.5, Studeni 1993.

PKCS #8: Private-Key Information Syntax Standard. Verzija 1.2, Studeni 1993.

PKCS #9: Selected Attribute Types. Verzija 1.1, Studeni 1993.

PKCS #10: Certification Request Syntax Standard. Verzija 1.0, Studeni 1993.

PKCS #11: Cryptographic Token Interface Standard. Verzija 1.0, Travanjl 1995.

PKCS #12: Personal Information Exchange Syntax Standard. Verzija 1.0 u izradi.

8.2 Pregled dizajna

Od početka svog razvoja Cryptoki je bio namijenjen (da služi) kao sučelje između aplikacija i raznih prijenosnih kriptografskih uređaja, kao što su pametne kartice, PCMCIA kartice i pametne diskete. Već postoje neke norme za pristup ovim uređajima na određenom nivou. Npr. Mehaničke su karakteristike i električne konekcije dobro opisane, kao i metode za slanje naredbi i primanje rezultata (ISO 7816, PCMCIA specifikacija). Ono što je ostalo nedefinirano su pojedine kriptografske naredbe. Nije dovoljno samo definirati skup naredbi za svaki pojedini uređaj, jer to ne bi riješilo problem neovisnosti aplikacije o uređaju.

Primarni cilj Cryptokia je programiranje sučelja na nižoj razini, koje prikazuje detalje o uređaju na apstraktnoj razini. Na taj se način aplikaciji prikazuje jedinstveni model kriptografskog uređaja, poznatiji pod nazivom kriptografski token ili jednostavnije token.

Drugi cilj u razvoju je omogućavanje dijeljenja resursa. Kao što su multi-tasking operacijski sustavi postali jako popularni, tako i jedan uređaj mora moći «raditi» s više aplikacija. Uz to, jedna aplikacija mora biti u mogućnosti koristiti više uređaja. Cilj Cryptokia nije da postane generičko sučelje za sve kriptografske funkcije, iako bi se kriptografski servisi mogli izraditi pomoću Cryptokia. Njegova svrha nije da se natječe, već da surađuje sa sličnim sučeljima kao što su Generic Security Services Application Programming Interface (RFC 1508 and RFC 1509) i Generic Cryptographic Service API (GCS-API).

8.3 Opći model

Opći model Cryptokia je prikazan na slici. Model "započinje" s jednom ili više aplikacija koje moraju obaviti određene kriptografske funkcije, a "završava" s uređajem na kojem se te funkcije zapravo obavljaju.

Slika 8.1: Opći model Cryptokia

Cryptoki pruža sučelje prema jednom ili više uređaja koji su spojeni na sustav preko slotova. Svaki slot, preko kojeg su spojeni čitač ili neki drugi uređaj, može sadržavati token. Token je «prisutan» u slotu kad je kriptografski uređaj prisutan u čitaču. Moguće je da više slotova dijeli isti čitač. Bit je u tome da sustav ima određeni broj slotova, a aplikacija može pristupati jednom ili možda čak svim slotovima.

Kriptografski uređaj može obavljati određene kriptografske operacije slijedeći skup instrukcija. Te se instrukcije najčešće prosljeđuju preko standardnih upravljačkih programa. Korištenjem Cryptokia svaki kriptografski uređaj izgleda kao bilo koji drugi uređaj, bez obzira na implementaciju i tehnologiju. Štoviše, aplikacija uopće ne mora imati sučelje prema upravljačkim programima (čak ne mora znati ni o kojim se programima radi); Cryptoki skriva sve detalje.

Cryptoki se implementira kao biblioteka koja podržava funkcije sučelja, a aplikacije su povezane s bibliotekama. Aplikacija može bit povezana s Cryptokiem izravno; suprotno tome Cryptoki može bit tzv. "dijeljena" biblioteka. U tom slučaju aplikacija se povezuje dinamički. Dijeljene biblioteke se uobičajeno koriste na operacijskim sustavima kao što su Windows i OS/2, dok se bez puno problema mogu koristiti pod UNIX-om i DOS-om. Dinamički model povezivanja ima mnogo prednosti, ali i neke negativne karakteristike, posebno po pitanju sigurnosti. Budući da se dinamički povezane biblioteke lako zamjenjuju, potencijalni napadač lako može «podvaliti» svoje biblioteke, te tako presresti korisnikov PIN. Dakle, iz perspektive sigurnosti, bolje je koristiti izravno povezivanje. Bez obzira na način povezivanja, sučelje između aplikacije i Cryptoki biblioteka ostaje isti.

8.4 Logički pogled na token

Za Crytpoki token predstavlja objekt koji čuva objekte i može obavljati kriptografske funkcije. Definiraju se tri klase objekata: podaci, certifikati i ključevi. Objekt podataka definira aplikacija, objekt certifikata sadrži certifikat javnog ključa, a objekt ključa čuva kriptografski ključ. Ključ može biti javni, privatni ili tajni.

Slika 8.2: Cryptoki objekti

Objekti su kategorizirani po vijeku trajanja i "vidljivosti". "Objekte token" vide sve aplikacije koje su spojene na token i imaju dovoljne dozvole, te ostaju na njemu nakon završetka svih sjednica i nakon što je token izvađen iz slota. "Sjednički objekti" su nešto kraćeg vijeka trajanja. U trenutku kad se sjednica završi svi se objekti unište. Osim toga te objekte vide samo aplikacije koje su ih stvorile.

Token može stvoriti objekte, uništiti ih, manipulirati njima, ili ih tražiti. Također može obavljati kriptografske funkcije s objektima.

Važno je razlikovati logički pogled na token od stvarne implementacije, jer nemaju sve implementacije ovaj koncept «objekata» niti mogućnost za obavljanje svih kriptografskih funkcija. Mnogi uređaji imaju točno određena mjesta za pohranu ključeva i ograničen skup instrukcija. Uloga Cryptokia je da prevede te implementacije u logički pogled.

9. Praktični rad

Praktični dio rada se odnosi na izradu Java aplikacije za stvaranje i provjeru digitalnog potpisa JAR arhiva i "običnih" datoteka. Osim toga, aplikacija omogućava stvaranje digitalne omotnice i digitalnog pečata. Certifikati koji se koriste za obavljanje navedenih funkcija nalaze se na kartici. Aplikacija omogućava i pregled certifikata koji su pohranjeni na kartici. Uz "logiku" aplikacije, izrađeno je korisničko sučelje koje korisniku omogućava lako korištenje aplikacije.

9.1 Pristup problemu

Kao što je navedeno u prethodnim poglavljima aplikacija je izrađena uz velike poteškoće. Općenito, rad na aplikaciji koja komunicira s karticom nije jednostavan kao što se može činiti. Brojni simulatori rada s pametnim karticama nisu vjerodostojni u prikazu složenosti takvog načina rada.

Prvi, možda i najveći problem, je postupak povezivanja čitača s računalom. U tu su svrhu korišteni ActivCard upravljački programi. Međutim, da bi stvar funkcionirala kako treba, potrebno je na računalo instalirati više zakrpi za upravljačke programe.

Drugi problem, kao što je ranije spomenuto, je slaba Javina podrška za normu PKCS#11. Java tek u svojoj zadnjoj verziji (1.5) predviđa korištenje vlastitog providera za rad kriptografskim uređajima. Potpisnik JAR arhiva za tu verziju Jave još ne radi ispravno. Iz tog razloga korištena je verzija Jave 1.4 uz komercijalni IAIK provider. Potpisnik JAR arhiva u toj verziji ispravno radi, ali se, kao što je spomenuto ranije, radi o komandno-linijskom alatu. Ovaj će se nedostatak moći ukloniti kad Java predstavi klase koje će upravljati potpisnikom JAR arhiva. Budući je aplikacija zamišljena kao jedinstvena cjelina, od korisnika je skrivena činjenica da se u bilo kojem trenutku koristi komandna linija.

9.2 Korištene klase

U slijedećem su dijelu teksta opisane stvorene klase koje aplikacija koristi.

9.2.1 Klasa Digitalni.java

Klasa Digitalni.java je najvažnija klasa koju koristi aplikacija. Pomoću te klase se dohvaćaju certifikati, te se ključevi, odnosno reference na ključeve (kod privatnog ključa) spremaju u array liste. Kasnije sve metode koriste tu listu ključeva. Metoda vratiCert postavlja novi provider, te stvara token manager pomoću metode createPKCS11Provider.

Osim navedenih metoda klasa Digitalni.java sadrži slijedeće metode:

PotpisiFile() – metoda koja stvara digitalni potpis datoteke
VerificirajFile() – metoda koja provjerava potpis datoteke
FileUByte() – pomoćna metoda koja sadržaj datoteke pretvara u polje okteta

Izvorni tekst klase Digitalni.java nalazi se na pratećem CD-u.

9.2.2 Klasa Jar.java

Klasa Jar.java se koristi za prosljeđivanje naredbi potpisniku JAR arhiva. Kao što je navedeno ranije, potpisnik JAR arhiva je komandno-linijski alat i ova klasa služi da bi tu činjenicu sakrila od korisnika.

Klasa sadrži:

metodu Potpisi() – stvara naredbu za potpis JAR arhive i novi runtime u kojem poziva potpisnik
metodu Verificiraj() – stvara naredbu za provjeru potpisa JAR arhive i novi runtime u kojem poziva potpisnik
klasu StreamGobbler() – koja se koristi za dohvat izlaza koji daje potpisnik

Izvorni tekst klase Jar.java nalazi se na pratećem CD-u.

9.2.3 Klasa OmotnicaPecat.java

Klasa OmotnicaPecat.java se koristi za stvaranje i "otvaranje" digitalne omotnice, te stvaranje digitalnog pečata.

Klasa sadrži:

metodu GenerirajKljuc() – generira simetrični ključ za DES kriptiranje i dekriptiranje
metodu dekriptirajSim() – dekriptira kriptiranu poruku DES algoritmom
metodu dekriptirajASim() – dekriptira kriptiranu poruka RSA algoritmom
metodu kriptirajSim() – kriptira poruku DES algoritmom
metodu kriptirajASim() – kriptira poruku RSA algoritmom
metodu KreirajPecat() – stvara digitalni pečat
metodu OtvoriOmotnicu() – iz digitalne omotnice «izvlači» originalnu poruku
metodu KreirajOmotnicu() – stvara digitalnu omotnicu

Izvorni tekst klase OmotnicaPecat.java nalazi se na pratećem CD-u.

9.2.4 Klasa Aplikacija.java

Klasa Aplikacija.java je središnja klasa koja se poziva kad se aplikacija pokreće. Ona je zadužena za prikaz sučelja, poziv svih metoda iz drugih klasa i ispis rezultata procesa. U klasi se nalazi velik broj metoda koje su zadužene za sam izgled sučelja pa ih na ovom mjestu neću navoditi.

Izvorni tekst klase Aplikacija.java nalazi se na pratećem CD-u.

9.3 Konfiguriranje okoline

Budući aplikacija ne koristi Sun provider već IAIK provider, prije početka rada potrebno je promijeniti neke postavke koje su Java okružju postavljene kao podrazumijevane.

pkcs11wrapper.dll mora biti postavljen u putanju
U java.security datoteci potrebno je postaviti providere za IAIK i PKCS11 (preporuka je postaviti pkcs11 provider na drugo, a IAIK na zadnje mjesto).

# List of providers and their preference orders (see above):

security.provider.1=sun.security.provider.Sun

security.provider.2=iaik.pkcs.pkcs11.provider.IAIKPkcs11

security.provider.3=com.sun.net.ssl.internal.ssl.Provider

security.provider.4=com.sun.rsajca.Provider

security.provider.5=com.sun.crypto.provider.SunJCE

security.provider.6=sun.security.jgss.SunProvider

security.provider.7=iaik.security.provider.IAIK

U \jre\lib\ext Jave kojom se potpisuje treba kopirati:

o iaik_jce_full_signed.jar

o iaikPkcs11Provider_signed.jar

o iaikPkcs11Wrapper.jar

U <java_home>\jre\lib\ext treba dodati iaik.jar koji sadrži u iaik\pkcs\pkcs11\provider\ direktoriju property datoteke firstInstance.properties i IAIKPkcs11Global.properties.

o firstInstance.properties PKCS11_NATIVE_MODULE = acpkcs201.dll

o IAIKPkcs11Global.properties

providerInstance.1=iaik/pkcs/pkcs11/provider/firstInstance.properties

providerInstance.2=iaik/pkcs/pkcs11/provider/firstInstance.properties

9.4. Pregled aplikacije

Aplikacija je izrađena u programskom jeziku Java, dok su se za izradu korisničkog sučelja koristile Java Swing komponente. U slijedećem dijelu teksta biti će opisano korisničko sučelje.

9.4.1 Glavni izbornik

Na slici 9.1 prikazan je glavni prozor koji se otvara nakon pokretanja aplikacije.

Slika 9.1: Prozor s glavnim izbornikom

Glavni izbornik se vidi na svim prozorima, a sadrži slijedeće opcije:

- Potpis JAR arhive

- Digitalni potpis

- Dodatno

- Status kartice

- Pomoć

- Kraj

9.4.2 Opcija Potpis JAR arhive

Odabirom opcije Potpis JAR arhive otvara se padajući izbornik koji nam pruža dvije mogućnosti odabira:

- Potpiši JAR arhivu

- Verificiraj JAR arhivu

Slika 9.2: Izbornik za rad s JAR arhivama

Opcija Potpiši JAR arhivu

Odabirom opcije Potpiši JAR arhivu otvara se novi prozor prikazan na slici 9.3.

Slika 9.3: Prozor za potpis JAR arhive

Za stvaranje potpisa JAR arhive potrebno je odabrati arhivu, što se postiže pritiskom miša na dugme TRAŽI JAR ARHIVU. Nakon toga se otvara novi prozor s birateljem datoteka koji je podešen da prima samo datoteke s ekstenzijom .jar, kao što je i prikazano na slici 9.4.

Slika 9.4: Izbor JAR arhive

Nakon odabira arhive putanja do arhive se prikazuje u tekst polju. Nakon toga potrebno je odabrati i certifikat čiji će se ključevi koristiti pri stvaranju digitalnog potpisa. Kao što je vidljivo na slici 9.5 certifikati su prikazani u tablici na prozoru. U tablici su prikazani svi certifikati koji se nalaze na kartici. Svaki red u tablici predstavlja jedan certifikat, a svaki certifikat je prikazan svojim aliasom (imenom) i tekstom koji opisuje za što je certifikat predviđen. Certifikat se odabire pritiskom miša na redak u tablici koji sadrži traženi certifikat. Nakon pritiska miša odabrani redak mijenja boju.

Slika 9.5: Izbor certifikata

Nakon što su odabrani certifikat i JAR arhiva za potpis, pritiskom miša na dugme POTPIŠI JAR ARHIVU otvara se mali prozor u kojem se zahtijeva unos osobnog broja, kao što se vidi na slici 9.6.

Slika 9.6: Unos osobnog broja

Osobni broj se zahtijeva zbog toga što se on u slučaju potpisa JAR arhive koristi kao parametar pri pozivu potpisnika. Kartica je, kao što je već spomenuto, spojena na računalo preko Activ Card upravljačkih programa, te je pin unesen kod otvaranja njegovog sučelja. Nakon unosa osobnog broja (čije se znamenke radi zaštite prikazuje kao zvjezdice *) pritiskom na dugme POTPIŠI JAR ARHIVU u prozoru za unos osobnog broja, pokreće se postupak potpisivanja.

Ukoliko je potpisivanje obavljeno bez poteškoća, na ekranu (slika 9.7) se ispisuje poruka o uspješnom potpisivanju. Prilikom potpisivanja stvara se i tekstualna datoteka u kojoj se nalazi izlaz koji je dao potpisnik. Datoteka ima ime formata <ime_arhive>.<dnevnik_potpisa.txt>.

Slika 9.7: Ispis statusa

Nakon što je potpisivanje obavljeno ažurirana je JAR arhiva te su u META-INF datoteku dodane dvije nove datoteke, kao što je opisano u poglavlju 7.4. Prikazom ovog prozora završen je postupak potpisivanja JAR arhive.

Opcija Verifikacija potpisa JAR arhive

Odabirom opcije Verifikacija JAR arhive otvara se novi prozor prikazan na slici 9.8

Slika 9.8: Prozor za provjeru potpisa JAR arhive

Kod postupka provjere JAR arhive potrebno je odabrati samo potpisanu JAR arhivu. Isto kao i kod postupka potpisivanja, pritiskom na dugme TRAŽI JAR ARHIVU otvara se novi prozor s birateljem datoteka koji opet ima filter i traži samo JAR arhive. Nakon odabira arhive, putanja do nje se ispisuje u tekst polje. Pritiskom na dugme VERIFICIRAJ POTPIS otvara se mali prozor u kojem se zahtijeva unos osobnog broja (slika 9.9) koji se , kao u slučaju potpisa JAR arhive, prosljeđuje potpisniku.

Slika 9.9: Unos pin-a

Nakon unosa osobnog broja, pritiskom na dugme VERIFICIRAJ POTPIS, pokreće se postupak provjere potpisa JAR arhive. Ukoliko je provjera uspješno obavljena, na ekranu se ispisuje poruka o uspješnoj provjeri. (slika 9.10)

Slika 9.10: Ispis statusa

Prilikom provjere potpisa, kreira se tekst datoteka čije je ime formata <ime_arhive><.dnevnik_verifikacije.txt>. U tu se datoteku zapisuje izlaz koji daje potpisnik prilikom provjere potpisa. Prikazom ovog prozora završen je proces provjere JAR arhive.

Obrada iznimaka

Prilikom stvaranja i provjere potpisa JAR arhive može doći do određenih grešaka. Dio tih grešaka aplikacija "hvata" i ispisuje na ekran. Riječ je situacijama u kojima korisnik zaboravi odabrati arhivu, certifikat ili osobni broj. U tim slučajevima se ispisuju poruke o parametru koji nije unesen (slika 9.11).

Slika 9.11: Ispis pogreške

U slučajevima da je aplikacija loše konfigurirana na računalu, što će se dogoditi u slučaju da je krivo postavljena putanja do potpisnika, aplikacija će javiti da je proces ispravno završen, ali će se u dnevniku potpisa ili u dnevniku provjere prikazati tekst pogreške. Zbog toga je korisno konzultirati dnevnike nakon svake akcije. U slučaju da potpisnik uopće nije konfiguriran, odnosno ne postoji datoteka signer_config na c disku, aplikacija neće dopustiti početak procesa potpisivanja ili provjere JAR arhive, već će korisniku sugerirati da je potrebno konfigurirati potpisnik JAR arhiva (Slika 9.12).

Slika 9.12: Ispis pogreške

9.4.3 Opcija Digitalni potpis

Odabirom opcije Digitalni potpis otvara se padajući izbornik koji nam pruža dvije mogućnosti odabira:

- Potpiši FILE

- Verificiraj FILE

Slika 9.13: Izbornik za rad s običnim datotekama

Opcija Potpiši FILE

Odabirom opcije Potpiši FILE otvara se novi prozor prikazan na slici 9.14.

Slika 9.14: Prozor za potpis datoteke

Opcije na ovom prozoru iste su kao i kod potpisa JAR arhive. Pritiskom na dugme TRAŽI FILE ZA POTPIS otvara se biratelj datoteka koji u ovom slučaju nije podešen da filtrira JAR arhive već prima sve vrste datoteka. Nakon toga potrebno je odabrati certifikat čiji će se ključevi koristiti pri stvaranju potpisa. Pritiskom na dugme POTPIŠI FILE pokreće se proces potpisivanja. Ukoliko proces potpisivanja ispravno prođe, na ekranu se ispisuje poruka o uspješnom stvaranju potpisa (slika 9.15). Osim toga, stvara se i tekst datoteka u koju se zapisuje potpis, a format imena tekst datoteke je <ime_file-a><.potpis.txt>.

Slika 9.15: Ispis statusa

Opcija Verificiraj FILE

Odabirom opcije Verificiraj FILE otvara se novi prozor prikazan na slici 9.16.

Slika 9.16: Prozor za provjeru potpisa datoteke

Prozor izgleda identično kao i prozor za stvaranje potpisa. Potrebno je odabrati datoteku čiji se potpis provjerava, a nakon toga i certifikat čiji se ključevi koriste kod provjere. Pritiskom na dugme VERIFICIRAJ POTPIS otvara se novi prozor u kojem se zahtijeva unos datoteke u kojoj je sadržan potpis. (Slika 9.17)

Slika 9.17: Izbor datoteke koja sadrži potpis

Pritiskom na dugme TRAŽI FILE S POTPISOM otvara se biratelj datoteka u kojem je potrebno odabrati tekst datoteku u kojoj se nalazi potpis. Pritiskom na dugme VERIFICIRAJ POTPIS pokreće se proces provjere potpisa. Ako postupak ispravno završi, na ekranu se ispisuje poruka o ispravnoj provjeri potpisa.(slika 9.18)

Slika 9.18: Ispis statusa

Prikazom ovog prozora završava se postupak provjere potpisa.

Obrada iznimaka

Obrada iznimaka kod stvaranja i provjere digitalnog potpisa datoteke slična je kao i kod potpisa JAR arhive. Aplikacija će reagirati u slučajevima kad korisnik zaboravi unijeti putanju do datoteke ili certifikat koji se koristi.

9.4.4 Opcija Dodatno

Odabirom opcije Dodatno otvara se padajući izbornik koji nam pruža dvije mogućnosti odabira:

- Kreiraj digitalnu omotnicu

- Kreiraj digitalni pečat

Slika 9.19: Izbornik za rad s digitalnom omotnicom i pečatom

Opcija Kreiraj digitalnu omotnicu

Odabirom opcije Kreiraj digitalnu omotnicu otvara se novi prozor prikazan na slici 9.20.

Slika 9.20: Prozor za stvaranje digitalne omotnice

Prozor sadrži iste elemente kao i prozor za potpis datoteke. Pomoću biratelja datoteka izabire se datoteka koju se želi staviti u omotnicu. Nakon toga se iz tablice bira jedan od ponuđenih certifikata čiji će se ključevi koristiti kod stvaranja omotnice. Pritiskom na dugme KREIRAJ DIGITALNU OMOTNICU pokreće se postupak stvaranja digitalne omotnice. Na ekran se nakon toga ispisuje poruka o uspješnom završetku postupka stvaranja omotnice, ukoliko je on uistinu završio (Slika 9.20).

Slika 9.21: Ispis statusa

Prilikom stvaranja digitalne omotnice aplikacija stvara dvije tekst datoteke. Prva tekst datoteka ima ime formata <ime_file-a_koji_je_u_omotnici><.omotnica>, koji sadrži samu omotnicu. Druga datoteka ima ime formata <ime_file-a_koji_je_u_omotnici><.dnevnik_izrade_omotnice> i sadrži dnevnik izrade u kojem se nalaze svi koraci u izradi omotnice.

U prozoru prikazanom na slici 9.21 nalazi se još i dugme OTVORI OMOTNICU koje pokreće postupak "otvaranja" omotnice odnosno "izvlačenja" same poruke iz omotnice. Nakon toga se otvara prozor prikazan na slici 9.22 koji izvještava o uspješnosti postupka otvaranja omotnice.

Slika 9.22: Ispis statusa

Prilikom otvaranja omotnice stvara se i datoteka čije je ime formata <ime_file-a_koji_je_u_omotnici><.omotnica_otvorena.txt>, a koja sadrži originalnu poruku koja je spremljena u omotnicu.

Opcija Kreiraj digitalni pečat

Odabirom opcije Kreiraj digitalni pečat otvara se novi prozor prikazan na slici 9.23.

Slika 9.23: Prozor za stvaranje digitalnog pečata

Prozor izgleda isto kao i prozor za izradu omotnice. Osnovna razlika je u biratelju datoteka koji je podešen da pronalazi isključivo digitalne omotnice. Nakon odabira certifikata iz tablice, pritiskom na dugme KREIRAJ DIGITALNI PEČAT pokreće se proces stvaranja digitalnog pečata. Nakon završetka postupka otvara se novi prozor koji izvještava o uspješnosti operacije stvaranja digitalnog pečata (Slika 9.24).

Slika 9.24: Ispis statusa

Prilikom stvaranja digitalnog pečata, aplikacija stvara datoteku čije je ime formata <omotnica><.pecat> i u kojem se nalazi digitalni pečat.

Obrada iznimaka

Obrada iznimaka je ista kao u slučaju potpisa datoteke. Aplikacija reagira u slučajevima kad korisnik zaboravi unijeti putanju do datoteke ili omotnice, ili zaboravi unijeti certifikat.

9.4.5 Opcija Status kartice

Odabirom opcije Status kartice otvara se padajući izbornik koji nam pruža dvije mogućnosti odabira:

- Pregled certifikata

- Konfiguracija Jarsignera

Slika 9.25: Izbornik za pregled certifikata i konfiguracije

Opcija Pregled certifikata

Odabirom opcije Pregled certifikata otvara se prozor u kojem se prikazuju detaljne informacije o svim certifikatima koji su prisutni na kartici (Slika 9.26).

Slika 9.26: Prozor s ispisom sadržaja certifikata

Opcija Konfiguracija Jarsignera

Odabirom opcije Konfiguracija Jarsignera otvara se prozor prikazan na slici 9.27.

Slika 9.27: Prozor za unos parametara konfiguracije

U prozoru se nalaze dva tekst polja u koja se unose putanje do potpisnika JAR arhiva i dummyStore-a na lokalnom računalu. U slučaju da su putanje već postavljene, na dnu ekrana se ispisuje poruka koja korisnika obavještava da je konfiguracija već postavljena. Ukoliko poruka nije prisutna, nakon upisa putanja u tekst polja, pritiskom na dugme UNESI KONFIGURACIJU putanje se upisuju u konfiguracijsku datoteku.

9.4.6 Opcija Pomoć

Odabirom opcije Pomoć otvara se padajući izbornik koji nam pruža dvije mogućnosti odabira:

- Upute o radu

- O aplikaciji

Slika 9.28: Izbornik za korištenje uputa

Opcija Upute o radu

Odabirom opcije Upute o radu otvara se mali prozor u kojem se ispisuju informacije o situacijama na koje treba obratiti pozornost pri radu s aplikacijom. Nakon duže faze testiranja aplikacije, lista tih informacija bi svakako trebala biti veća (Slika 9.29).

Slika 9.29: Prozor s važnim napomenama

Opcija O aplikaciji

Odabirom opcije O aplikaciji otvara se mali prozor u kojem se ispisuju servisne informacije o načinu izrade aplikacije i autorskim pravima (Slika 9.30)-

Slika 9.30: Prozor s informacijama o aplikaciji

9.4.7 Kraj

Odabirom opcije Kraj otvara se padajući izbornik sa samo jednom opcijom, a to je Završi s radom. Odabirom te opcije korisnik završava rad s aplikacijom. (Slika 9.31)

Slika 9.31: Kraj rada

Budući je aplikacija izrađena korištenjem Java Swing komponenti, njen izgled je prilično jednostavan i "unixoidan". Korištenjem nekih drugih alata za izradu korisničkih sučelja aplikacija može poprimiti neki drugi oblik koji će korisniku pružiti mogućnost lakšeg rada.

10. Zaključak

Infrastruktura javnog ključa je vrlo složen sustav za čiji je razvoj potreban izniman trud i mnogo vremena. U samim počecima teorije o PKI očekivanja su bila velika; išla su čak do predviđanja po kojima će cijeli svijet biti povezan jednim PKI sustavom. Kako se teorija razvijala javljali su se brojni problemi. Neki od tih problema još uvijek nisu riješeni te neki autori predlažu i potpuno napuštanje sustava.

PKI će vjerojatno svoju pravu snagu pokazati kroz srednje i relativno zatvorene sustave. Štoviše, takvi sustavi već postoje i komercijalno su isplativi. Međutim, svakim se danom sve više komunikacija i poslovanja u svijetu odvijaju putem Interneta. Osim toga, sve više ljudi posjeduje danas već jako moćna osobna računala i želi aktivno koristiti blagodati poslovanja putem Interneta. Te činjenice pred stručnjake postavljaju nove zahtjeve koji se odnose na računalnu sigurnost. Da li će to biti neki novi sustav ili nadgradnja PKI sustava, teško je predvidjeti. Sigurno je da u ovom trenutku velik broj stručnjaka radi u jednom i drugom smjeru. Sigurno je također, da kad se i pojavi bilo kakav sustav zaštite, pojavit će se i ljudi koji će ga pokušati ugroziti.

Praktični dio diplomskog rada je jedna mala karika u lancu koji jamči sigurnost. Pri samoj izradi aplikacije javljali su se određeni problemi koji su detaljno opisani u prethodnim poglavljima. Unatoč tomu, aplikacija uspješno obavlja sve funkcije koje su navedene kao nužni zahtjevi. Daljnjim razvojem tehnologija, posebice Java tehnologije, aplikacija će se moći nadograditi i tako postati sigurnija karika u PKI sustavu. Studentima i stručnjacima koji se bave računalnom sigurnošću rad može poslužiti kao dobra i koncizna literatura.

Jurica Čular

_______________

11. Literatura

[1] Russ Housley, Tim Polk, 2001. Planning for PKI, Wiley Computer Publishing, Canada.

[2] Alan Young, Public-Key Infrastructure: The road to E-Business security, http://www.cas.mcmaster.ca/~wmfarmer/SE-4C03-02/projects/student_work/youngcy.html

[3] Fina Pki, 2003. Pravilnik o administriranju korisnika i certifikata, http://rdc.fina.hr/dokumentacija/FINA-PKI-PAKv1.18.pdf

[4] Fina Pki, 2003 Reference, kratice i definicije, http://rdc.fina.hr/dokumentacija/FINA-PKI-definicije1.0.4.pdf

[5] Nikolina Pekić, Diplomski Rad, 2005 Sustav za provjeru valjanosti digitalnih certifikata

[6] Ivan Krnić, Zoran Regvart, Interna Skripta, PKI i Java programiranje za PKI

[7] Krešimir Nesek, Seminarski Rad, 2004 Infrasrtuktura javnih ključeva i certifikacijski centar

[8] RSA Laboratories 1997, PKCS#11 Cryptographic Token Interface Standard

[9] Ietf, Request for Comments, http://www.ietf.org/rfc

[10] Iaik Tugraz, Uputstva Za Korištenje, PKCS11 Provider, http://jce.iaik.tugraz.at/sic/products/core_crypto_toolkits/pkcs_11_provider

[11] Iaik Tugraz, Uputstva Za Korištenje , PKCS11 Manual, http://jce.iaik.tugraz.at/products/13_PKCS11_ME-Manual.pdf

[12] Java Sun, Uputstva Za Korištenje,Java Security, http://java.sun.com/j2se/1.5.0/docs/guide/security/p11guide.html#ALG

[13] BeeTrusted, KeyUsage, http://www.betrusted.com/downloads/ products/keytools/v50/pro/c-docs/html/refguide/Certificates/KeyUsage.html

[14] Burton S. Kaliski Jr., Pregled Normi,1993, A Layman's Guide to a Subset of ASN.1, BER, and DER, http://www.columbia.edu/~ariel/ssleay/layman.html

[15] William R. Cheswick, Steven M. Bellovin, Firewalls and Internet Security, http://www.wilyhacker.com/

[16] Simson Garfinkel, Eugene Spafford, Practical UNIX and Internet Security, http://www.amazon.com/exec/obidos/tg/browse/-/565748/104-5357782-6529525

[17] David Kahn, 1967, The Codebrakers

[18] W.Diffie, M.Hellman 1976, New Directions in Cryptography

[19] James Walsh, 1996, True Odds – How Risks Affect Your Everyday Life, www.amazon.com/exec/obidos/ tg/detail/-/1563431149?v=glance

[20] Zakon o elektroničkom potpisu, 2002, www.nn.hr/clanci/sluzbeno/2002/0242.htm

[21] Jurica Čular, Seminarski Rad, 2005, Basic pametne kartice

12. Skraćenice

APDU Application Protocol Data Unit Podatkovna jedinica aplikacijskog

protokola

ASN Abstract Syntax Notation Apstraktna sintaksna notacija

ATR Answer To Reset Odgovor na reset

BER Basic Encoding Rules Osnovna pravila kodiranja

CA Certification Authority Certifikacijski centar

CAD Card acceptance device Uređaj za prihvat kartice

CRL Certificate Revocation List Lista opozvanih certifikata

DER Distiguished Encoding Rules Istaknuta pravila dekodiranja

DES Data Encryption Standard Algoritam kriptografije; vrsta

simetričnog algoritma

DNS Domain Name System Ovlašteni sustav imenovanja

OSI Open Systems Interconnection Povezivanje otvorenih sustava

PKCS Public Key Cryptographic Standard Kriptografske norme u infrastrukturi

javnog ključa

PKI Public Key Infrastructure Infrastruktura javnog ključa

PTS Protocol Type Selection Odabir vrste protokola

RA Registration Authority Registracijski centar

RFC Requests For Comments IETF-ove specifikacije, zahtjevi za

komentarima

RSA Rivest-Shamir-Adleman Algoritam kriptografije; vrsta

asimetričnog algoritma

Dodatak A: Pregled izlaznih datoteka

Digitalni potpis i provjera potpisa JAR arhive

Kao primjer rada aplikacije za potpis JAR arhive, uzet ćemo JAR arhivu hak.jar čiji se sadržaj vidi na slici A.1.

Slika A.1: Sadržaj JAR arhive

Sadržaj META-INF dijela vidi se na slici A.2.

Slika A.2: Sadržaj META-INF datoteke prije potpisa

Vidljivo je da digitalni potpis u ovom trenutku nije prisutan u JAR arhivi. Nakon stvaranja digitalnog potpisa pomoću aplikacije sadržaj META-INF dijela se upotpuni datotekama koje sadrže potpis.(Slika A.2)

Slika A.3: Sadržaj META-INF datoteke nakon potpisa

Prilikom potpisa JAR arhive aplikacija kreira tekst datoteku koja sadrži izlaz koji je dao potpisnik JAR arhiva.

Sadržaj hak.jar.dnevnik_potpisa.txt datoteke.

OUTPUT> updating: META-INF/DARIO_BE.SF

OUTPUT> updating: META-INF/DARIO_BE.RSA

OUTPUT> adding: hr/

OUTPUT> adding: hr/hak/

OUTPUT> signing: hr/hak/CheckPermission.class

OUTPUT> signing: hr/hak/CheckPermission.java

OUTPUT> signing: hr/hak/DrivingPermission.class

OUTPUT> signing: hr/hak/DrivingPermission.java

OUTPUT> signing: hr/hak/Permission.class

Prilikom provjere JAR arhive njen se sadržaj ne mijenja, već aplikacija stvara tekst datoteku koja sadrži izlaz koji je dao potpisnik.

Sadržaj hak.jar.dnevnik_verifikacije.txt datoteke.

OUTPUT>

OUTPUT> 548 Wed Dec 17 13:21:50 GMT+01:00 2003 META-INF/MANIFEST.MF

OUTPUT> 601 Tue Jan 17 16:57:30 GMT+01:00 2006 META-INF/DARIO_BE.SF

OUTPUT> 1413 Tue Jan 17 16:57:30 GMT+01:00 2006 META-INF/DARIO_BE.RSA

OUTPUT> 0 Wed Dec 17 13:21:16 GMT+01:00 2003 META-INF/

OUTPUT> 0 Tue Dec 16 13:41:48 GMT+01:00 2003 hr/

OUTPUT> 0 Tue Dec 16 13:54:54 GMT+01:00 2003 hr/hak/

OUTPUT>smk 527 Tue Dec 16 14:04:38 GMT+01:00 2003 hr/hak/CheckPermission.class

OUTPUT>smk 289 Tue Dec 16 13:56:52 GMT+01:00 2003 hr/hak/CheckPermission.java

OUTPUT>smk 2680 Tue Dec 16 14:04:38 GMT+01:00 2003 hr/hak/DrivingPermission.class

OUTPUT>smk 3661 Tue Dec 16 14:04:32 GMT+01:00 2003 hr/hak/DrivingPermission.java

OUTPUT>smk 538 Tue Dec 16 14:04:38 GMT+01:00 2003 hr/hak/Permission.class

OUTPUT>

OUTPUT> s = signature was verified

OUTPUT> m = entry is listed in manifest

OUTPUT> k = at least one certificate was found in keystore

OUTPUT> i = at least one certificate was found in identity scope

OUTPUT>

OUTPUT>jar verified.

OUTPUT>

Digitalni potpis i provjera potpisa datoteke

Prilikom stvaranja digitalnog potpisa stvara se tekst datoteka u kojoj se nalazi sam potpis.

Sadržaj datoteke test_file.txt

Ovo je tekst koji treba potpisati

Sadržaj datoteke test_file.txt.potpis.txt

10228636181524625811060977587450848935702430193792125743615708971238089954375370326691084535345484997849401844979505274490402432432999687718778799702697208934738794549513212683803449024929143259527053715318258627664889006369686310729998905048906955361721623554672713405277164676130685051909501457375074942017

Digitalna omotnica

Kod stvaranja digitalne omotnice stvara se tekst datoteka koja sadrži omotnicu i tekst datoteka koja sadrži dnevnik stvaranja omotnice.

Sadržaj datoteke test_file.txt.omotnica

Ovo je digitalna omotnica koju je kreirala aplikacija!!

Ovo je kriptirana poruka:

1803300155368926193657281024065044581324121825478908758734291173787102384349081605990750016154932

Ovo je kriptirani tajni ključ:

90552501534712960922461812431678099171007510389677485074647991307621435014057032396835457841074002097444674314896871583113626414280110087291376652262187723597697531080250189345481971197206818043219088376118036342107991061370657511504603647011121974896003369508983118992680650285281411180056646514820227723237

Sadržaj datoteke test_file.txt.dnevnik_izrade_omotnice

Kriptiram ove podatke simetričnim algoritmom:

Ovo je tekst koji treba potpisati

Završeno simetrično kriptiranje!!

########

Kriptiram tajni ključ asimetričnim algoritmom:

Završeno asimetrično kriptiranje!!

Digitalna omotnica kreirana!!!

Omotnica se nalazi u C:\Documents and Settings\jcular\Desktop\slike\test_file.txt.omotnica

Prilikom "otvaranja" omotnice stvara se datoteka koja sadrži poruku koja je spremljena u omotnicu.

Sadržaj datoteke test_file.txt.omotnica_otvorena.txt

Ovo je tekst koji treba potpisati

Digitalni pečat

Prilikom stvaranja digitalnog pečata stvara se datoteka koja sadrži sam pečat.

Sadržaj datoteke test_file.txt.omotnica.pecat

76216108133635838324868628909302911109173865611771552617801836706328175869025661338096252321589041710258049274813058321179869744727610594778133079187940596361735220430578282723757233939766311648996361771902755905944190671613278367269646283287649635432712465019084105909850009753192117814015155373321777030798