SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

DIPLOMSKI RAD BR. 1796

Sustav za pouzdano vremensko označavanje dokumenata

Maja Grubid

Voditelj: Marin Golub

Zagreb, srpanj 2009.

ZADATAK

Sustav za pouzdano vremensko označavanje dokumenata

Proučiti i opisati dijelove sustava javnog ključa (Public Key Infrastructure, PKI). Posebnu pozornost posvetiti centru za izdavanje vremenskih oznaka (Time Stamp Authority, TSA). Opisati ulogu vremenske oznake u sustavu javnog ključa. Navesti postupak stvaranja vremenske oznake te njenu provjeru. Načiniti program koji simulira rad sustava za pouzdano vremensko označavanje dokumenata i digitalnih potpisa. Simulirati proizvoljno odabrani protokol koji se koristi u sustavu e-trgovine. Grafički prikazati tok poruka i njihov sadržaj. Radu priložiti izvorne tekstove programa. Citirati korištenu literaturu.

SAŽETAK

U ovom radu opisan je sustav za pouzdano vremensko označavanje dokumenata koji se temelji

na protokolu razmjene vremenskih oznaka (Timestamp protocol, TSP). Opisana je uporaba

vremenskih oznaka u sustavu javnih ključeva (Public Key Infrastructure, PKI) i njihova struktura.

Poseban naglasak stavljen je na X.509 certifikate, njihovu strukturu, uporabu u PKI sustavu,

značenje u izdavanju vremenskih oznaka, te na njihove prednosti i nedostatke. U praktičnom

dijelu rada implementirani su centar za izdavanje vremenskih oznaka(Timestamp authority, TSA),

te klijent koji traži izdavanje vremenskih oznaka i vrši njihovu provjeru.

ABSTRACT Title: Secure Timestamping System This diploma thesis describes a system for secure document timestamping based on a Timestamp Protocol, TSP. Importance of timestamps in a Public Key Infrastructure (PKI) is explained, as well as their structure and usage. Implementation of a timestamp authority and a timestamp client is provided. Finally, a simple web shop is implemented to show usage of timestamps in a real system.

Sadržaj

1. Uvod .............................................................................................................................. 1

2. PKI (Public Key Infrastructure) sustav .............................................................................. 2

2.1 Struktura PKI sustava .............................................................................................. 2

2.2 Primjer korištenja PKI sustava za autentifikaciju korisnika ...................................... 6

2.3 Povijesni razvoj PKI sustava .................................................................................... 8

2.4 Prednosti i ograničenja PKI sustava ......................................................................... 9

2.5 PKI u Hrvatskoj ..................................................................................................... 10

3. X.509 certifikati ............................................................................................................ 12

3.1 Verzije X.509 certifikata ........................................................................................ 12

3.2 Struktura X.509 certifikata verzije 3 ...................................................................... 12

3.3 Podržani kriptografski algoritmi ............................................................................ 16

3.4 Provjera X.509 certifikata ..................................................................................... 17

3.5 ASN.1.................................................................................................................... 20

4. Centar za pouzdano vremensko označavanje ............................................................... 23

4.1 Centar za pouzdano vremensko označavanje vremenskih oznaka ......................... 23

4.2 Uloga centra za vremensko označavanje u PKI sustavu ......................................... 24

4.3 TSA transakcije .................................................................................................... 25

4.4 Identifikacija TSA .................................................................................................. 25

4.5 Format zahtjeva za vremenskom oznakom ........................................................... 25

4.6 Format odgovora .................................................................................................. 27

4.7 Format vremenske oznake .................................................................................... 28

4.8 Prijenos TSA poruka .............................................................................................. 31

4.9 Sigurnosni problemi .............................................................................................. 33

5. Programsko ostvarenje................................................................................................. 35

5.1 Vremenske oznake, zahtjevi i odgovori ................................................................. 35

5.2 Poslužitelj za izdavanje vremenskih oznaka .......................................................... 36

5.3 Komunikacija između poslužitelja i klijenta ........................................................... 39

5.4 Klijent za zahtijevanje izdavanja vremenskih oznaka ............................................. 44

5.5 Primjer korištenja sustava za vremensko označavanje dokumenata ..................... 49

5.6 Primjer korištenja vremenskih oznaka u sustavu e-trgovine .................................. 60

6. Zaključak ...................................................................................................................... 64

7. Literatura ..................................................................................................................... 65

1

1. Uvod

Prema statistikama iz ožujka 2009. godine, Internet danas koristi 1.596 milijardi ljudi [1]. To znači da su stotine tisuda ljudi online svakog dana. Internet postaje globalna enciklopedija, mjesto gdje se pronalaze informacije o raznoraznim temama, te informacije koje nisu lako dostupne drugdje. Internet je i globalni medij za razmjenu novosti i vijesti. Mnogi posežu za Internetom i zbog komunikacije s rodbinom ili prijateljima s drugog kraja svijeta. Drugi pak koriste Internet za razonodu. Posljednjih godina, na Internetu se sve brže razvija i trgovina te svakim danom postaje sve popularnija među širokim brojem korisnika. Ljudi kupuju knjige, rezerviraju hotele, pladaju račune, a sve to u samo nekoliko klikova mišem. To podrazumijeva da se svakodnevno izvrše tisude transakcija u kojima korisnici razmjenjuju svoje privatne i poslovne podatke. Ovakav način poslovanja onemogudio je tradicionalne metode provjere identiteta (kao npr. provjere osobnih iskaznica) i otvorio vrata mnogim sigurnosnim problemima. Neki od najčešdih sigurnosnih problema su prisluškivanje podataka, mijenjanje podataka, izmišljanje podataka, prekidanje komunikacijskog kanala, te lažno predstavljanje. Prilikom prisluškivanja podataka napadač presrede vezu između izvorišta i odredišta podataka te čita podatke koji su namijenjeni nekom drugom. Brojevi kreditnih kartica, kreditnih računa i JMBG mogu biti ukradeni prisluškivanjem podataka. Prilikom mijenjanja podataka napadač presrede podatke u prolasku. Napadač mijenja podatke, te takve zamijenjene šalje primaocu. Tako se može npr. promijeniti broj bankovnog računa na koji korisnik šalje novac. Prilikom izmišljanja podataka napadač uspostavlja komunikaciju s odredištem lažno se predstavljajudi kao izvorište, te primaocu šalje izmišljene ili stare poruke. Prilikom lažnog predstavljanja napadač se predstavlja kao neki drugi korisnik (primjerice, provalivši na nečiji tuđi račun).

Sustav javnih ključeva (eng. Public Key Infrastructure ili skradeno PKI) osmišljen je da bi ponudio rješenje nekih sigurnosnih problema.

U ovom radu pobliže je opisana infrastruktura javnog ključa i svi njezini sastavni dijelovi, uz naglasak na centru za izdavanje vremenskih oznaka (eng. Time Stamp Authority ili skradeno TSA). Izdavanjem vremenske oznake TSA jamči da je dokument postojao u određenom trenutku u vremenu, te da mu se sadržaj nije mijenjao od navedenog vremena.

U radu je opisana i uloga vremenske oznake u sustavu javnog ključa, postupak stvaranja vremenske oznake te njena provjera. Uza sve to, opisan je razvoj infrastrukture PKI sustava kroz povijest, te prednosti i mane ovakvog sustava. Poseban naglasak stavljen je na X.509 certifikate zbog njihove važnosti u izdavanju vremenskih oznaka. Na kraju je opisan praktični dio rada te funkcije i razredi korišteni u praktičnom dijelu.

2

2. PKI (Public Key Infrastructure) sustav

PKI ili infrastruktura javnog ključa je sustav koji povezuje korisnike, digitalne certifikate, certifikacijske i registracijske autoritete, te baze važedih i opozvanih certifikata. Certifikacijski autoriteti vrše provjeru identiteta svih strana uključenih u internetsku transakciju uporabom para ključeva. Par ključeva sačinjavaju javni i privatni (tajni) ključ. Javni ključ je dostupan svima i koristi se za kriptiranje poruka, dok je privatni ključ poznat samo vlasniku i koristi se za dekriptiranje. Svaki korisnik ima svoj par ključeva. Identitet korisnika mora biti jedinstven unutar certifikacijskog centra. Povezivanje korisnika s njegovim identitetom ostvaruje se kroz proces registracije i izdavanja certifikata, koji, ovisno o razini zahtijevane sigurnosti može biti obavljen samo softwareom unutar certifikacijskog centra ili mora biti nadgledan od strane čovjeka. PKI je sustav koji omoguduje autentifikaciju, povjerljivost i integritet podataka, neporecivost, te upravljanje ključevima, odnosno certifikatima [2].

2.1 Struktura PKI sustava

PKI se sastoji od više međusobno povezanih objekata, aplikacija i servisa:

alata za upravljanje i nadgledanje sustava, registracijskog centra ili registratora (Registration Authority ili skradeno RA) koji

obavlja registraciju korisnika, certifikacijskog centra (Certification Authority ili skradeno CA) koji se brine za

izdavanje i valjanost certifikata, baze izdanih certifikata (najčešde se koristi LDAP imenički servis) i liste opozvanih

certifikat (Certification Revocation List ili skradeno CRL), centra za pouzdano vremensko označavanje (Timestamp Authority ili skradeno TSA), izdavača opozvanih certifikata, korisničkog certifikata , korisničkih aplikacija, poslužitelja itd., koji koriste PKI autorizaciju.

PKI autorizaciju koriste subjekti certifikata (ponekad se zovu i krajnji korisnici), koji ne moraju biti fizičke ili pravne osobe ved i uređaji kao što su poslužitelji (poslužitelji) i usmjernici (routeri), zatim programi i procesi, odnosno sve što može biti identificirano imenom na certifikatu. Certifikacijski centar (CA) je entitet koji potpisuje i izdaje certifikate. Osnovne operacije certifikacijskog centra su izdavanje certifikata, njihovo obnavljanje i po potrebi njihov opoziv. CA svojim potpisom jamči ispravnost podataka u certifikatu. CA izravno ili preko registracijskog centra (RA) registrira krajnje entitete ili korisnike i verificira njihov identitet na odgovarajudi način. Ponekad obavlja i funkciju sigurnog pohranjivanja ključeva. On je izvor povjerenja u PKI, a povjerenje je osnova na kojoj se zasniva PKI. Registracijski centar (RA) je opcionalna komponenta PKI sustava, a može biti i dio certifikacijskog centra. Njegova uloga je registriranje korisnika PKI sustava. Osim ove uloge, RA može provjeravati posjeduje li korisnik privatni ključ koji odgovara javnom ključu koji de se nalaziti na certifikatu, ili može sam generirati par ključeva. On može biti i posrednik između korisnika certifikacijskog centra prilikom informiranja o kompromitiranju privatnog ključa. Sve ove

3

funkcije su obavezni dio PKI sustava, te ako ih ne obavlja RA mora ih obavljati CA. RA je također i korisnik PKI sustava te ima svoj javni ključ i certifikat. RA ne smije obavljati funkcije izdavanja i opoziva certifikata. Baza važedih certifikata je sustav ili skup distribuiranih sustava koji pohranjuju certifikate i listu opozvanih certifikata. Baza važedih certifikata je dostupna svim unutarnjim ali i vanjskim korisnicima PKI sustava koji koriste certifikate za identifikaciju. Izdavač opozvanih certifikata je komponenta PKI sustava koja izdaje listu opozvanih certifikata. Certifikati se izdaju s određenim periodom valjanosti. Postoji više razloga zašto certifikati mogu postati nevažedi i prije isteka tog perioda, a jedan od njih je kompromitiranje privatnog ključa. Svaki opozvani certifikat identificiran je svojim serijskim brojem u listi opozvanih certifikata. Lista opozvanih certifikata je javno dostupna svima.

Centar za pouzdano vremensko označavanje (TSA) je pružatelj usluge ovjere elektroničkog potpisa. Elektronički potpis je opdeniti izraz koji obuhvada sve metode kojima se može potpisati elektronička informacija, neovisno o tehnologiji i načinu izvedbe. Za elektronički potpis mogu se definirati zahtjevi kao što su očuvanje integriteta potpisanih informacija, neporecivost potpisivanja i identifikaciju potpisnika. U okviru elektroničkog potpisa ne govori se o načinu izvedbe traženih zahtjeva, tj. korisnicima se ostavlja na izbor odabir najpovoljnije ili najpouzdanije tehnologije za izvedbu. U Hrvatskoj je 17. siječnja 2002. proglašen Zakon o elektroničkom potpisu. Prema tom zakonu definicija elektroničkog potpisa je sljededa: Elektronički potpis – znači skup podataka u elektroničkom obliku koji su pridruženi ili su logički povezani s drugim podacima u elektroničkom obliku i koji služe za identifikaciju potpisnika i vjerodostojnosti potpisanoga elektroničkog dokumenta [3]. Također definiran je i napredan elektronički potpis. Napredan elektronički potpis je elektronički potpis koji:

1. je povezan isključivo s potpisnikom, 2. nedvojbeno identificira potpisnika, 3. nastaje korištenjem sredstava kojima potpisnik može samostalno upravljati i koja su isključivo pod nadzorom potpisnika, 4. sadržava izravnu povezanost s podacima na koje se odnosi i to na način koji nedvojbeno omogudava uvid u bilo koju izmjenu izvornih podataka.

Prema tome napredan elektronički potpis ima istu pravnu snagu i zamjenjuje vlastoručni potpis, odnosno vlastoručni potpis i otisak pečata [4].

TSA vremenskim žigom ovjerava potpis potpisnika. Vremenskim se žigom potvrđuje da su podaci i elektronički potpis postojali prije izdavanja (stavljanja) vremenskog žiga. Vremenska ovjera je podrška za pravno valjanu uporabu kvalificiranog elektroničkog potpisa. Servise vremenske ovjere je mogude primijeniti u bilo kojoj aplikaciji koja zahtijeva dokaz da je određeni podatak postojao prije nekog određenog vremena. Ovo svojstvo se koristi da se potvrdi da je elektronički potpis bio primijenjen na dokument prije nego je pripadajudi certifikat opozvan, omogudavajudi time da se certifikat i nakon opozvanosti koristi za provjeru potpisa nastalih prije datuma opoziva. Dakle, servisi vremenske ovjere osiguravaju pouzdanost elektroničkog potpisa i poslije isteka valjanosti/opoziva certifikata potpisnika/subjekta. Ovo je važno svojstvo PKI sustava.

Ono što je bitno nije vrijeme kao takvo, nego sigurno povezivanje vremena i podataka. Za neke aplikacije čak nije ni potrebno da vremenska oznaka predstavlja stvarno vrijeme; ona može biti redni broj koji označava da je pojedini dokument bio predstavljen centru za

4

pouzdano vremensko označavanje prije dokumenta x, te nakon dokumenta y. Bez obzira što vremenska oznaka predstavlja, sve zainteresirane strane moraju modi provjeriti da je vremenska oznaka povezana s dokumentom autentična, te da je očuvan integritet dokumenta.

Na slici 2.1. prikazani su osnovni dijelovi PKI sustava.

Krajnji entitet

(END ENTITY)Provjera certifikata

Registrator

(RA)

Certifikator

(CA)

PKI korisnici

Objavljivanje

certifikata

B

a

z

a

c

e

r

t

i

f

i

k

a

t

a

&

C

R

L

l

i

s

t

e

Izdavač opozvanih

certifikata

(CRL Issuer)Objavljivanje

opozvanih

certifikata

Objavljivanje certifikata

Objavljivanje CRL liste

Certifikator 2

(CA 2)

Certifikacija

između

certifikatora

registracija,

inicijalizacijska

certifikacija,

obnavljanje para

ključeva,

zahtjev za opozivom

Slika 2.1. Struktura PKI sustava

U PKI sustavu povjerljivost podataka se osigurava enkripcijom poruka odnosno korištenjem privatnog (private key) i javnog (public key) ključa, te pripadne im matematičke funkcije (tzv. asimetrična enkripcija). Svaka osoba u PKI sustavu ima vlastiti javni i privatni ključ, nadopunjen certifikatom. Osnovni princip sustava je sigurno pohranjivanje privatnog ključa koji mora biti dostupan i poznat samo korisniku. Korisnički certifikat, u kojem se nalazi javni ključ, dostupan je svima i najčešde se pohranjuje pomodu LDAP imeničkog servisa. Korištenjem kombinacije privatnog i javnog ključa prilikom slanja poruke, sadržaj poruke se kriptira čime poruka postaje nečitljiva. Primjenom pripadajudeg privatnog ključa, koji svaka osoba u PKI sustavu čuva za sebe, poruka se dekriptira te ponovno postaje čitljiva.

Dodatna sigurnost se postiže uporabom višenamjenske pametne kartice (smartcard) za pohranu korisničkih ključeva i certifikata.

5

Privatni ključ se koristi i kod digitalnog potpisivanja poruka pa primatelj pomodu pošiljateljevog javnog ključa može provjeriti je li sadržaj poruke prilikom dostave mijenjan, odnosno je li dobio originalni sažetak poruke (hash).

Digitalni potpis (digital ID) je dodatak koji se dodaje digitalnom dokumentu i služi kao autentifikacija osobe ili računala koje koristi neku uslugu, aplikaciju ili komunicira s drugim korisnicima putem Interneta ili drugačije. Sam certifikat u sebi sadrži korisnikov javni ključ koji, korištenjem algoritma sažimanja (hash algoritma), mora biti potpisan, odnosno odobren od organizacije koja jamči da je certifikat izdan po pravilima.

Ispravnost certifikata se jamči certifikatom višeg nivoa hijerarhije, tzv. korijenskim (root) certifikatom odnosno certifikatom potpisanim od nekog sub CA operatera koji je potpisan od root CA. Često korisnik nema listu certifikata od korijenskog CA. Ako korisnik nema ispravnu kopiju javnog ključa od CA koji je potpisao korisnikov certifikat, zahtijeva se još jedan certifikat od CA koji je potpisao njegov certifikat. Ovaj pristup se primjenjuje rekurzivno, sve dok se ne izgradi lanac certifikata (engl. certification path) i ne otkrije se "sidro" (anchor), tj. CA najviše hijerarhije (end-entity). Taj CA je obično specificiran certifikatom koji je izdao CA kojemu korisnik direktno vjeruje. U praksi, lanac certifikata je uređena lista certifikata, izgrađena od jednog certifikata kojeg je izdao CA najviše hijerarhije, te nula ili više dodatnih certifikata. Lista certifikata obično je kodirana jednim ili više načinom kodiranja, čime se omogudava siguran prijenos liste kroz mrežu i između različitih operacijskih sustava.

Slika 2.2. prikazuje listu certifikata od onog najviše hijerarhije (CA1) do korisnikovog certifikata (Ana) [5]. Lista certifikata uspostavlja povjerenje u Anin javni ključ preko posredničkog CA, CA2.

Slika 2.2. Lista certifikata

Lista certifikata mora prodi provjeru prije nego li se može osloniti na korisnikov javni ključ. Provjera se sastoji od raznih provjera nad certifikatima sadržanima u listi certifikata, kao npr. provjera potpisa i provjera da pojedini certifikat nije opozvan. Sustavi koji koriste javne ključeve moraju omoguditi izgradnju ili otkrivanje liste certifikata. RFC 2587 definira LDAP (Lightweight Directory Access Protocol) koji omogudava otkrivanje liste X.509 certifikata. Detaljnije o algoritmu provjere liste certifikata bit de govora kasnije.

6

2.2 Primjer korištenja PKI sustava za autentifikaciju korisnika [6]

Protokol autentifikacije sudionika A se sastoji od šest koraka. Protokol opisan u idudih šest točaka pretpostavlja da su oba sudionika – A i B prijavljena u istom certifikacijskom centru.

1. Sudionik A šalje u razgovijetnom obliku svoj identifikator sudioniku B u poruci

M1 = (IDA). 2. Po primitku M1 sudionik B generira slučajni broj N i šalje u razgovijetnom obliku

sudioniku A poruku

M2 = (N). 3. Po primitku M2 sudionik A kriptira svojim privatnim ključem N i šalje poruku

M3 = E (N, KDA). 4. Sudionik B po primitku M3 šalje certifikacijskom centru C u razgovijetnom obliku

poruku

M4 = (IDA, RB), gdje je RB kod kojim sudionik B zahtijeva od CA certifikat sudionika s identifikatorom IDA.

5. Po primitku M4 poslužitelj certifikacijskog centra C:

iz svoje tablice na temelju IDA pročita CERAC;

s pomodu svojeg privatnog ključa KDC kriptira CERAC i šalje poruku

M5 = E (CERAC, KDC).

6. Po primitku M5 sudionik B:

javnim ključem poslužitelja dekriptira M5 i dobiva

CERAC = D (E (CERA

C, KDC), KEC);

iz CERAC saznaje

IDA, KEA i E (H (IDA, KEA), KDC));

izračunava H (IDA, KEA) i dobiveni rezultat uspoređuje s dekriptiranom vrijednošdu D (E (H (IDA, KEA), KDC)), KEC) čime provjerava dobiveni KEA, čime je ustvari proveo operaciju utvrđivanja ključa sudionika A pomodu ključa certifikacijskog centra C;

s dobivenim KEA dekriptira raniju poruku M3 i dobiva

N = D (E (N, KDA), KEA);

dobiveni N uspoređuje s originalom, čime prihvada ili odbacuje sudionika A

Opisani protokol prikazan je slikom 2.3.

7

A B

C

M1 = (IDA)

M2 = (N)

M3 = E (N, KDA)

M4 =

(IDA , R

B )

M5 =

E (CER

A C, K

DC )

IDA, CERAC

IDB, CERBC

KEC, KDC

KEA, KDA,

KEC KEB, KDB,

KEC

Slika 2.3. Postupak jednostrane autentifikacije uz pomod certifikata

Slika 2.4. prikazuje primjer korištenja PKI sustava prilikom e – kupovine.

8

Slika 2.4. Primjer korištenja PKI sustava

2.3 Povijesni razvoj PKI sustava

1976. Whitfield Diffie i Martin Hellman izdaju članak "New Directions in Cryptography". U svom su članku predstavili, u tom trenutku revolucionarnu, metodu asimetrične kriptografije. U konceptu asimetričnih kriptografskih algoritama postoje dva ključa, za razliku od simetričnih u kojima postoji samo jedan. Algoritam DES je bio standard u to doba i osnovni algoritam temeljen na simetričnoj kriptografiji. Glavni problem simetrične kriptografije bio je sigurna razmjena tajnog ključa preko nesigurnog kanala. Diffie i Hellman su predložili da vrijednosti dvaju ključa budu povezani nekom matematičkom funkcijom, sporom za izračunavanje, i da se jedan vrijednost koristi za kriptiranje, a druga za dekriptiranje poruke. Bududi da bi veza između dvije vrijednosti ključa bila netrivijalna za izračunati, jedan ključ bi bio javan, bez gubitka sigurnosti. Iako autori u tom trenutku nisu imali ideju praktične realizacije kriptografije javnim ključem, ona je pobudila prilično veliko zanimanje i intenzivirala aktivnost kriptografske zajednice.

Autori predlažu i stvaranje bijelih stranica javnog ključa (Public Key White Pages), tako da svatko može dodi do javnog ključa pojedine osobe. Jednim potezom, izumili su kriptografiju temeljenu na javnom ključu i PKI.

9

Kriptografija javnog ključa oslanja se na koncept da privatni ključ ostaje tajan. 1978. student Kohnfelder objavljuje ideju o offline certifikacijskom centru (CA) koji bi povezivao identitet i javni ključ pojedinca potpisujudi certifikat svojim privatnim ključem. Centar daje svoje povjerenje, preko svog potpisa, kombinaciji identiteta i pripadnog javnog ključa. Online poslužitelj može sada izdavati certifikate, a svatko može dohvatiti certifikate i provjeriti njihovu autentičnost koristedi javni ključ od CA.

Da je povijest bila malo drugačija, imali bismo danas pravi PKI. No, dvije stvari su se umiješale. Prva je da je RSA dobio patente na prvoj radnoj implementaciji javnog ključa, i tehnologija javnog ključa se počela izbjegavati zbog problema s licencama – sve dok patenti nisu istekli. Phil Zimmerman je kreirao PGP, koji je zaobilazio RSA patente, ali je upotrijebio anarhični pristup distribuciji javnog ključa. Drugi veliki problem je posve nepovezan s prvim, a naziva se X.500 direktoriji.

X.500 direktoriji osmišljeni su da budu online globalna baza korištena za elektroničku poštu i ostale aplikacije korištene od strane OSI-ja (Open System Interconnections) u 1980-ima. X.500 se oslanja na na ASN.1 (Abstract Syntax Notation One) za definiciju sadržaja direktorija. ASN.1 je standard i fleksibilna notacija koja opisuje podatkovne strukture za prikaz, kodiranje, prijenos i dekodiranje podataka, te de o njoj biti govora kasnije. X.509 certifikat je prvi put izdan 3. srpnja 1988. za autentifikaciju pristupa X.500 direktorijima. Verzije 1 i 2 X.509 certifikata su ispale iz široke uporabe jer su im nedostajala ključna polja za uporabu u Internet aplikacijama. Npr. niti jedna verzija nema polje za korisnikovu e-mail adresu. Struktura imena koju DN upotrebljava nije povezana s imenovanjem kakvo koristimo u stvarnom životu, i stoga je DN velikim dijelom zaslužan zašto PKI nije u širokoj uporabi danas. Verzija 3 X.509 certifikata uvodi dovoljno fleksibilnosti za širu uporabu.

2.4 Prednosti i ograničenja PKI sustava

PKI svakako pruža osnovnu sigurnost potrebnu za sigurnu komunikaciju, i to takvu da korisnici, koji se međusobno ne poznaju ili su dosta udaljeni, mogu sigurno komunicirati kroz lanac povjerenja. Povjerenje je građevni blok infrastrukture javnog ključa i ono se ostvaruje osiguravanjem:

Privatnosti. Ostvaruje se korištenjem kriptiranja. Poruka se pretvara u drugačiji tekst korištenjem algoritama enkripcije i samo osobe s ispravnim ključem za dekriptiranje mogu dobiti izvornu poruku.

Integriteta. Jamči da je ono što je primatelj primio upravo ono što je pošiljatelj poslao. Nema gubitka informacija.

Neporecivosti. Osigurava da korisnik ne može negirati da je poslao poruku ili sudjelovao u transakciji.

Autentifikacije. Utvrđuje da je entitet ono što tvrdi da jest. Digitalni certifikat povezuje identitet s jedinstvenim ključem.

PKI sustav nažalost ima i nekoliko mana.

10

Sve sadržano u poljima X.509 certifikata potpisuje se privatnim ključem certifikacijskog centra. Niti jedan bit unutar certifikata ne može se promijeniti bez da certifikat postane nevažedi. Svaka promjena, kao npr. promjena e-mail adrese ili organizacijske jedinice uzrokuje ne samo izdavanje novog certifikata nego i poništavanje starog.

Drugi veliki problem su liste opozvanih certifikata (CRL liste). Ideja je poprilično jednostavna – svaki CA sadrži listu opozvanih certifikata koja se može koristiti svaki put kad aplikacija želi koristiti certifikat. Ovo dovodi do novog problema – certifikati se ne mogu više koristiti offline, jer se mora koristit online pristup najnovijoj listi. CRL sama po sebi može biti dugačka, pa je i sam proces preuzimanja (downloada) liste netrivijalan, i za aplikaciju i za samu mrežu. Kako svaki certifikat sadrži i podatke o točki distribucije liste opozvanih certifikata (Certificate Revocation List Distribution Point), promjena nekog parametra CRL-a, npr. URL-a, uzrokuje poništavanje svih certifikata. CRL ne prate nikakvu paradigmu stvarnog svijeta. Osim sporog preuzimanja velike liste opozvanih certifikata postoji još jedan problem, a to je mehanizam koji se ved pokazao neučinkovit. Kada se iz nekog razloga certifikat opoziva, moraju se istovremeno opozvati sve njegove kopije unutar raspodijeljenog sustava. U načelu se to može izvesti kao što se radi s ukradenim kreditnim karticama. Banke su nekod koristile listu ukradenih ili opozvanih kreditnih kartica, ali su to prestale. Umjesto toga, izdavatelj kartice šalje svim prodajnim mjestima popis opozvanih kartica s tim da se na svakom mjestu prije odobrenja kupovine mora provjeriti je li kartica još važeda. Sličan mehanizam postoji i u PKI-ju, u kojem umjesto downloadanja CRL-a aplikacija koja provodi provjeru certifikata provjerava kod izdavajudeg CA je li certifikat bio opozvan. Online Certificate Status Protocol (OCSP) pokušava se baviti s ovim problemom.

Još jedan problem X.509 certifikata jest da je previše fleksibilan. Vedina proizvođača stvara certifikate koji su nekompatibilni sa certifikatima drugih proizvođača. To se događa jer koriste polja kao npr. polje uporabe ključeva (Key Usage) na razne načine. Želi li se postidi interoperabilnost, najbolje je koristiti jedan proizvod na više mjesta. Drugim riječima, nema prave interoperabilnosti. Neki proizvodi podržavaju unakrsnu certifikaciju. Unakrsna certifikacija dozvoljava različitim CA da izdaju certifikate jedan drugome. Npr. zamislimo dvije tvrtke, svaku sa svojim internim CA koje žele upogoniti PKI komunikaciju između sebe. Unakrsna certifikacija dozvoljava korisnicima unutar svake od te dvije tvrtke da prepoznaju i validiraju certifikate druge tvrtke. Ovo je naravno izvedivo samo ako su polja unutar certifikata kompatibilna između dviju tvrtki. Različite organizacije mogu imati različite načine zapisivanja imena da bi se izbjegle kolizije.

2.5 PKI u Hrvatskoj

FINA je preko Registra digitalnih certifikata jedini pružatelj usluga certificiranja u RH, registrirana kod Ministarstva gospodarstva, rada i poduzetništva, od kojeg je dobila dozvolu za izdavanje kvalificiranih digitalnih certifikata [7].

FINA izdaje 2 tipa certifikata: autentifikacijski (normalizirani) certifikat, te potpisni (kvalificirani) certifikat. Autentifikacijski osigurava autentičnost, cjelovitost, izvornost i tajnost dokumenta ili elektroničke transakcije, ali ne osigurava neporecivost. Potpisni (kvalificirani) certifikat se koristi za elektroničko potpisivanje dokumenata ili transakcija

11

naprednim elektroničkim potpisom. Jamči autentičnost, cjelovitost i izvornost, priskrbljuje i neporecivost zamjenjujudi u cijelosti vlastoručni potpis ili vlastoručni potpis i otisak pečata.

Certifikati, prema namjeni, mogu biti:

1. Osobni (za građane – fizičke osobe) 2. Poslovni (za poslovne subjekte) 3. TDU (za tijela državne uprave)

Certifikati se po razini sigurnosti svrstavaju u 3 kategorije:

1. Standardna

- ova je razina prikladna u okolinama u kojima postoje rizici i posljedice prouzročene kompromitiranjem podataka, koji nemaju vedu važnost. To može biti pristup tajnim podacima za koje vjerojatnost zlonamjernog pristupa nije velika. Za ovu se sigurnosnu razinu podrazumjeva da je vjerojatnost da korisnici budu zlonamjerni mala.

2. Srednja

- ova je razina prikladna za okoline u kojima su rizici i posljedice kompromitiranja podataka umjereni. Može se koristiti u transakcijama koje imaju znatnu novčanu vrijednost ili rizik od krivotvorenja ili u onima u koje je uključen pristup tajnim informacijama za koje je vjerojatnost zlonamjernoga pristupa znatna.

3. Visoka

- ova je razina prikladna za uporabu u transakcijama u kojima je ugroženost podataka visoka ili su posljedice propusta u sustavu zaštite velike. To su transakcije vrlo visoke vrijednosti ili s velikim rizikom od krivotvorenja

12

3. X.509 certifikati

Digitalni certifikat je digitalno potpisani dokument koji povezuje javni ključ s osobom kojoj pripada (vlasnikom javnog ključa). Uveden je iz tog razloga što sudionici u komunikaciji, da bi uopde mogli komunicirati, moraju na neki način doznati ključeve svojih partnera. Osim toga, moraju biti uvjereni da partneri nisu uljezi koji se lažno predstavljaju. Ideju digitalnog certifikata predložio je L. Kohnfelder 1978. godine. Certifikat se digitalno potpisuje da bi se osigurao njegov integritet, koji jamči potpisnik. Norma X.509 određuje format zapisa i semantiku pojedinih polja certifikata. Osim toga navodi numeričke identifikatore pojedinih polja i normira neka proširenja. Također navodi metodu opoziva certifikata, načine provjere i nabraja podržane kriptografske algoritme. Formalni opis certifikata dan je ASN.1 zapisom, a kodiranje se izvodi izdvojenim pravilima.

3.1 Verzije X.509 certifikata

Najstarija verzija, verzija 1, potječe iz 1988. godine, kada je tek definiran X.500 standard. U proširenju 1993. godine, dodana su dva nova polja, rezultirajudi formatom verzije 2 (v2). Verzija 2 uvela je koncept jedinstvenih identifikatora subjekta i izdavača da bi se dozvolila mogudnost promjene imena subjekta ili izdavača tijekom vremena. Vedina dokumenata predlaže da se imena subjekta i izdavača ne mijenjaju s vremenom, te da se ne koriste jedinstveni identifikatori. Verzija 2 nije u širokoj upotrebi. Najnovija i najčešde upotrebljavana verzija je verzija 3. Ova verzija podržava proširenja. Proširenja su zamišljena tako da svatko može definirati proširenje i uključiti ga u certfikat. Neka danas česta proširenja su uporaba ključa (KeyUsage) koja dozvoljava uporabu u ključa za određene svrhe, npr. samo za potpisivanje dokumenata, alternativno ime (AlternativeNames) koje dozvoljava da više identiteta bude povezano s istim javnim kjučem, dodatni podaci o identifikaciji vlasnika certifikata, podaci o atributima ključa, ograničenja u stazi certifikacije, itd. Proširenja se mogu označiti kao kritična (critical) kako bi se indiciralo da se proširenja moraju provjeriti. Npr. ako certifikat ima uporabu ključa označenu kao critical i postavljenu na keyCertSign, a certifikat se prezentira tijekom SSL komunikacije, certifikat treba odbiti, jer proširenja na certifikatu indiciraju da se privatni ključ smije koristiti samo za potpisivanje certifikata, i ništa drugo.

3.2 Struktura X.509 certifikata verzije 3 [8]

Standard X.509 propisuje da svaki certifikat sadrži sljedede podatke:

Verzija

Označava koja verzija X.509 certifikata se primijenjuje na taj certifikat.

Serijski broj

Prirodni broj koji je jedinstven unutar CA. CA koji izdaje certifikat odgovoran je za dodjelu jedinstvenog serijskog broja certifikatu tako da se on može razlikovati od ostalih certifikata

13

koje taj CA izdaje. Ovaj broj se koristi u različite svrhe. Npr. prilikom opoziva certifikata serijski broj se smješta u listu opozvanih certifikata (Certificate Revocation List, CRL).

Identifikator algoritma potpisa

Identificira algoritam koji je korišten od strane CA prilikom izdavanja certifikata za digitalno potpisivanje certifikata.

Izdavač

Označava X.500 ime entiteta koji je potpisao certifikat. Ovo je obično CA. Uporaba certifikata implicira povjerenje u entitet koji je potpisao certifikat.

Razdoblje valjanosti

Svaki certifikat je valjan samo određeno vrijeme. Ovo vrijeme je određeno datumom početka i datumom kraja, a može varirati od samo nekoliko sekundi do gotovo stoljeda. Trajanje valjanosti ovisi o brojnim faktorima, kao npr. snaga privatnog ključa koji se koristi za potpisivanje certifikata ili o iznosu pladenom za certifikat.

Ime subjekta

Identificira entitet povezan s javnim ključem. Ime koristi X.500 standard, uz namjeru da bude jedinstveno na Internetu. Za kvalificirani certifikat ovo polje mora imati vrijednost prepoznatljivog imena subjekta (Distinguished Name, DN), npr.

CN = webmail.fer.hr, OU = CIP, O = FER, C = HR

gdje su oznake redom: CN – Common Name, OU – Organizational Unit, O – Organization, C – Country.

Podaci o javnom ključu subjekta

Sadrži javni ključ imenovanog subjekta, zajedno s identifikatorom kriptografskog algoritma, te parametrima ključa.

Jedinstveni ID izdavača

Ovo polje je propisano u verziji 2 preporuke i opcionalno je. U polju se određuje niz bitova koji jedinstveno identificiraju X.500 ime izdavača, u slučaju da je jedan X.500 DN kroz vrijeme bio dodijeljen više nego jednom certifikatoru.

Jedinstveni ID subjekta

Polje je propisano u verziji 2 preporuke i opcionalno je. U polju se određuje niz bitova koji jedinstveno identificiraju subjekt, u slučaju da je jedan X.500 DN kroz vrijeme bio dodijeljen više nego jednom entitetu (npr. zaposlenik napusti poduzede, a kroz nekoliko mjeseci u poduzedu se zaposli osoba istog imena i prezimena).

Proširenja

Proširenja su propisana u verziji 3. U preporuci se definiraju standardna proširenja za neke šire primjenjiva proširenja verzije 2 preporuke. Ali certifikati nisu ograničeni samo na standardna proširenja ved svatko može registrirati proširenje kod odgovarajudih ustanova (npr. ISO). Svako proširenje se sastoji od tri polja:

1. type – tip,

14

2. criticality – kritičnost i 3. value – vrijednost.

Struktura proširenja je prikazana na slici 3.1.

CriticalityType Value

Slika 3.1. Struktura proširenja verzije 3 X.509 certifikata

Polje extension type definira tip podatka u polju extension value. Tip može biti tekst, numerička vrijednost, datum, grafika ili neka složena struktura podataka. Polje extension

criticality je jednobitna oznaka. Kada je polje označeno kao kritično znači da polje extension

value sadrži podatak toliko važan da se ne smije zanemariti. Ako se kritično proširenje ne može obraditi, certifikat se mora odbaciti.

Postoji razlika između kritičnog proširenja i nužnog podatka u certifikatu. Određeno proširenje može biti nužno nekoj aplikaciji, ali to ne znači da takvo polje mora biti označeno kao kritično. Kritična polja su namijenjena samo za podatke tolike važnosti da ga moraju razumjeti sve aplikacije, npr. informacije važne za sprečavanje pogrešne uporabe certifikata. Velika vedina proširenja je nekritična. Kritična proširenja se trebaju dodavati s oprezom i tek nakon pažljivog razmatranja jer mogu prouzročiti probleme pri korištenju certifikata.

Polje extension value sadrži podatke. Tip podataka je definiran u polju extension type. Neka od standardnih proširenja su: informacije o ključu (sadrže informacije o namjeni certifikata i para ključeva), informacije o politici (daju mehanizam koji omoguduje certifikatoru da definira način na koji se određeni certifikat mora koristiti i interpretirati), atributi korisnika i certifikatora (omoguduju dodatne mehanizme kojima se određuju informacije za identifikaciju korisnika i certifikatora), ograničenja na stazu certifikacije (omoguduju mehanizme kojima certifikator upravlja i ograničava povjerenje "prošireno" na trede osobe, te se primjenjuje kod unakrsne certifikacije).

Digitalni potpis

Digitalni potpis ostvaruje se tako da se tijelo certifikata sažme odabranom funkcijom sažimanja. Kriptografski sažetak izrađuje se jednosmjernom funkcijom koja iz poruke proizvoljne duljine izračunava sažetak stalne duljine. Ova je funkcija jednosmjerna stoga što je izračunavanje sažetka vrlo lako dok je iz sažetka gotovo nemogude izračunati izvornu poruku. Sažeto tijelo certifikata se oblikuje i prosljeđuje algoritmu enkripcije. Tako dobiveni rezultat zapisuje se u ovo polje.

Struktura X.509 certifikata prikazana je slikom 3.2.

15

Slika 3.2. Struktura X.509 certifikata

Primjer cerfikata izdanog od strane velike tvrtke zaposleniku manje tvrtke koja surađuje s velikom tvrtkom prikazan je niže. Certifikat se koristi za autentifikaciju zaposlenika prilikom spajanja na VPN (Virtual Private Network) velike tvrtke.

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 75 (0x4b)

Signature Algorithm: md5WithRSAEncryption

Issuer: C=US, ST=WA, L=Seattle, O=RealNetworks International

Internet Tech, OU=The part that does not waste money,

CN=atfw.prognet.com/emailAddress=black@euro.real.com

Validity

Not Before: May 13 23:33:08 2008 GMT

Not After : May 11 23:33:08 2018 GMT

Subject: C=HR, ST=Grad Zagreb, L=Zagreb, O=Five minutes, OU=Five

minutes, CN=Maja Grubic /

emailAddress=maja.grubic@fiveminutes.eu

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (2048 bit)

16

Modulus (2048 bit):

00:cd:66:28:fb:b8:b3:b7:e0:72:77:48:2d:08:04:

e1:6d:1c:c5:4f:57:73:0c:e6:db:3b:8e:cd:c6:25:

61:7f:60:c9:da:a3:9f:1d:fa:d8:ef:00:7b:f9:54:

65:ab:7e:9e:9b:6d:ff:d4:12:ad:f8:ac:87:6e:83:

ec:65:5f:b4:2d:eb:b8:dc:1c:d7:32:b7:46:a5:e3:

a1:6c:0b:4c:1b:0c:89:0a:fb:0e:3a:c0:0f:af:b2:

62:1d:2f:60:e4:b1:27:b4:7c:59:00:2c:19:e9:f3:

a3:88:fe:01:d6:56:be:26:c7:f8:42:b1:79:39:98:

a1:b4:4a:84:dd:20:ca:e7:a9:db:6d:a6:73:88:e7:

81:8b:3e:81:3d:00:e5:5d:7f:3d:9b:cd:ba:9b:28:

88:88:7f:d7:69:2c:66:eb:8f:79:b8:ec:bc:bb:76:

67:b1:00:2a:70:bd:f1:21:66:6f:ba:74:81:82:30:

02:c0:a8:57:f8:9f:76:02:df:7f:49:44:4a:32:93:

48:a4:25:73:47:10:21:20:fe:b6:d2:09:1a:60:4f:

a5:d9:df:ea:55:49:43:c6:ce:96:0b:7d:a7:22:c1:

3e:5b:28:2e:2c:04:7a:b2:93:89:db:d8:2b:59:86:

a3:0a:c1:6f:f9:56:b2:a5:71:4c:4b:74:f3:b8:a1:

b4:65

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

Netscape Comment:

OpenSSL Generated Certificate

X509v3 Subject Key Identifier:

8D:2C:09:A6:6C:16:C3:FE:B8:A8:4B:DA:7C:B6:3F:93:47:87:4A:26

X509v3 Authority Key Identifier:

keyid: F1:8A:84:5C:3A:65:75:5F:23:72:85:9F:47:9C:13:06:

9A: 41:1D:2D

DirName:/C=US/ST=WA/L=Seattle/O=RealNetworks

International Internet Tech/OU=The part that does

not waste money/CN=atfw.prognet.com/

emailAddress=black@euro.real.com

serial:86:2C:4B:84:16:25:58:2F

Signature Algorithm: md5WithRSAEncryption

b5:b1:72:97:f5:6b:d0:94:59:d2:b9:3d:24:6c:d5:48:dd:d4:

1e:d8:a6:b8:77:be:37:c8:be:d0:98:d3:af:ec:b0:57:7d:29:

2c:6f:b8:e7:fd:07:e6:89:6b:93:d3:c7:d0:dd:fa:9c:af:c7:

6d:04:0d:63:64:48:4d:f9:df:02:d2:c5:fa:74:df:ca:ce:5b:

a7:19:77:24:6a:d8:e0:50:e7:fa:93:a2:fe:1e:66:b9:aa:84:

e9:82:ae:ed:62:b0:92:be:72:78:b9:b2:25:31:c7:bc:32:c2:

a5:e0:15:ba:ef:c8:19:88:67:1f:7b:7c:44:a0:3b:fa:24:88:

e7:fd

3.3 Podržani kriptografski algoritmi

Norma X.509 propisuje koje je funkcije sažimanja i enkriptiranja mogude upotrebljavati pri stvaranju digitalnih certifikata. SHA-1 je preferirana funkcija izračunavanja sažetka dok su MD5 i MD2 uključene radi očuvanja kompatibilnosti sa starijim normama.

MD2 je funkcija sažimanja koju je razvio Ronald Rivest 1989. godine, specificirana RFC-om 1319. MD2 proizvodi sažetak duljine 128 bita. Od osnovnih operacija MD2 koristi tablicu permutacija od 256 bajtnih elemenata i XOR funkciju koja je najvažnija pri izračunu.

17

MD5 kao i MD2 proizvodi sažetak duljine 128 bita. Izvorni tekst se dijeli na blokove duljine 512 bitova. Zadnji blok koji ne mora biti dugačak 512 bitova nadopunjuje se na 512 bitova tako da se iza zadnjeg bita teksta dodaje jedna jedinica, nakon koje se upisuje toliko nula koliko je potrebno da u bloku preostanu 64 bita, a zatim se u preostale bitove upisuje bitovna duljina izvorne poruke. Svaki se blok dijeli na 16 podblokova duljine 32 bita. Svaki podblok sudjeluje u izračunavanju 4 puta, pa se izračunavanje obavlja u 64 koraka podijeljena u 4 kruga.

Funkcija sažimanja SHA-1 proizvodi 160 bitovni sažetak. Izvorni tekst dijeli se na podblokove duljine 512 bita. Zadnji blok teksta nadopunjuje se na 512 bitova na jednaki način kao i kod MD5. Sažetak od 160 bitova sastoji se od 5 nadovezanih 32-bitovnih varijabli, koje se inicijaliziraju na određene početne vrijednosti. SHA-1 postupak ima 4 kruga s 20 koraka, tj. ukupno 80 koraka.

Certifikati mogu biti potpisani bilo kojim enkripcijskim algoritmom javnog ključa. Najčešde su korišteni DSA i RSA.

3.4 Provjera X.509 certifikata

3.4.1 Provjera X.509 liste opozvanih certifikata (Certificate Revocation List, CRL)

CRL je lista certifikata (ili točnije, lista serijskih brojeva certifikata) koji su opozvani i nisu više valjani, te time im se ne smije više vjerovati. [9]

RFC 3280 propisuje dva različita stanja opozvanosti:

Opozvan: Certifikat je nepovratno opozvan, ako je, npr., otkriveno da je CA nepropisno izdao certifikat ili ako je privatni ključ korišten od strane CA kompromitiran. Certifikati mogu biti opozvani i zbog nemogudnosti CA da se prilagodi različitim zahtjevima prilikom izdavanja ili zbog kršenja pravila izdavanja bilo od strane CA ili korisnika koji traži izdavanje.

Najčešdi razlog opoziva je ipak taj da korisnik više nije jedini u posjedu privatnog ključa, tj. privatni ključ je izgubljen ili ukraden.

U stanju čekanja: Ovo stanje se može vratiti na prijašnje stanje, a koristi se da se označi trenutna nevaljanost certifikata (npr. korisnik nije siguran je li privatni ključ izgubljen). Ako se privatni ključ kasnije pronađe, te se ustanovi da mu nitko osim korisnika nije imao pristup u međuvremenu, stanje se može promijeniti, te certifikat postaje ponovno valjan. Time se certifikat uklanja iz bududih verzija CRL – a.

Postoji 10 razloga za opoziv certifikata, kao što je prikazano tablicom 3.1.

Tablica 3.1. Razlozi za opoziv certifikata

nespecificirano (unspecified) 0

kompromitiranje ključa (keyCompromise) 1

kompromitiranje CA (cACompromise) 2

18

promjena pripadnosti(affiliationChanged) 3

zamjena(superseded) 4

prestanak djelovanja(cessationOfOperation) 5

certifikat na čekanju(certificateHold) 6

-- ne upotrebljava se 7

certifikat de biti uklonjen iz CRL-a (moveFromCRL) 8

privilegeWithdrawn 9

aACompromise 10

CRL se stvara i objavljuje periodički, unutar jasno definiranog vremenskog okvira. CRL se može objaviti i odmah nakon opoziva certifikata, uvijek ga izdaje CA koji izdaje pripadajude certifikate. Sve CRL imaju rok unutar kojeg su valjane, a taj rok je obično 24 sata ili čak manje.

Unutar vremenske valjanosti CRL-a, aplikacija u PKI sustavu se može osloniti na nju da provjeri cerfikat prije njegove uporabe.

Da bi se izbjegalo ometanje ili napad uskradivanjem usluge (denial of service attack), CRL obično ima digitalni potpis povezan sa CA koji ju je izdao. Da bi se provjerila CRL prije njezine uporabe, potreban je pripadajudi certifikat od CA. Ovaj certifikat se može nadi u javnom direktoriju i dostupan je svima.

Vremenska valjanost i datum prestanka valjanosti certifikata nisu nadomjestak za CRL. Svi istekli certifikati se smatraju nevažedima, dok svi trenutno valjani certifikati ne moraju biti važedi. CRL ili neke druge metode provjere certifikata su sastavni dio svakog pravilno organiziranog PKI sustava. Predvidljivo je da de se u stvarnom sustavu pojaviti greške u certifikatima i održavanju ključeva.

3.4.2 Algoritam provjere liste certifikata

Algoritam provjere liste certifikata je algoritam koji provjerava da je zadana lista certifikata valjana unutar zadanog PKI sustava. Ova lista certifikata se ponekad naziva i lanac certifikata. Razlog tome je da lista započinje s korisničkim certifikatom i nastavlja se kroz niz posredničkih certifikata do krajnjeg, korijenskog (root) certifikata, obično izdanog od stane CA, pa se može smatrati da su certifikati ulančani.

Provjera liste certifikata je potrebna da bi aplikacija ustanovila može li vjerovati certifikatu kojem ved eksplicitno ne vjeruje. Npr. lista certifikata koja počinje sa web poslužiteljem može dovesti do malenog CA, zatim preko posredničkog CA do velikog CA, kojemu klijentski browser ved vjeruje. Ili, lista certifikata koja počinje s korisnikom u tvrtki A može dovesti do CA certifikata tvrtke A, zatim do CA koji je spona između tvrtke A i tvrtke B, zatim do CA od tvrtke B, koji je CA kojemu se može vjerovati.

19

RFC 3280 definira standardni algoritam za provjeru liste certifikata X.509 certifikata, pod uvjetom da je ta lista poznata. Otkrivanje liste i sama konstrukcija lanca certifikata nisu sadržani u tom RFC-u.

Algoritam prima idude parametre:

certifikacijski lanac koji treba provjeriti;

trenutni datum / vrijeme;

listu OID-a prihvatljivih politika pri izdavanju certifikata (ili oznaku da su sve politike prihvatljive) ;

"sidro" liste certifikata;

indikatore koji pokazuju kada se može koristiti lista svih prihvatljivih politika;

U standardiziranom algoritmu, nekoliko koraka se ponavlja za svaki certifikat u lancu, počevši od certifikata najviše hijerarhije ("sidra"). Ako bilo koja provjera ne uspije za bilo koji certifikat, algoritam prestaje s izvršavanjem, te je provjera neuspješna. Koraci provjere ukratko su:

provjerava se algoritam javnog ključa i njegovih parametara;

trenutno vrijeme se uspoređuje s vremenom valjanosti certifikata;

provjerava se opozvanost certifikata (npr. uporabom CRL-a) ;

provjerava se ime izdavača certifikata da se ustanovi da ono odgovara imenu korisnika prethodnog certifikata u lancu;

provjeravaju se ograničenja na ime, da se vidi je li ime vlasnika unutar liste dozvoljenih imena svih prethodnih CA certifikata, tj. da nije niti u jednoj listi nedozvoljenih imena prethodnih CA certifikata;

OID-evi politika se uspoređuju s dozvoljenim OID-evima prethodnog certifikata;

provjeravaju se osnovna ograničenja i ograničenja na politiku izdavanja da se ustanovi da niti jedan eksplicitan zahtjev na politiku izdavanja nije prekršen, te da certifikat zaista je CA certifikat. Ovaj korak je ključan u sprječavanju napada čovjekom u sredini. Provjerava se duljina lanca da se provjeri da ne prelazi najvedu dozvoljenu duljinu specificiranu prethodnim certifikatom;

provjerava se proširenje uporabe ključa (key usage extension) da se ustanovi ima li certifikat dozvolu za potpisivanje certifikata;

sva preostala kritična proširenja se prepoznaju i obrađuju.

Ako se ovim postupom dođe do posljednjeg certifikata u lancu, bez kršenja ograničenja na ime ili politiku, te bez ikakvih drugih grešaka, algoritam provjere liste certifikata uspješno završava.

20

3.5 ASN.1

ASN.1 (Abstract Syntax Notation One) je zapis koji se koristi u opisu poruka koje se izmjenjuju između različitih aplikacija koje međusobno komuniciraju. Taj zapis pruža mogudnost opisa poruka na visokoj razini i oslobađa dizajnere protokola od fokusiranja na same bitove i oktete poruka. Inicijalno korišten za opis e-mail poruka unutar OSI protokola, ASN.1 je u međuvremenu postao prihvaden u širokom rasponu drugih aplikacija, kao što su one za mrežni nadzor, sigurni e-mail, mobilnu telefoniju, prijenos videa i govora preko Interneta i mnoge druge. Usko povezani uz ASN.1 su i skupovi standardnih pravila kodiranja koji opisuju bitove i oktete poruke u prijenosu između komunikacijskih aplikacija. Ni ASN.1 niti pravila kodiranja nisu vezani za ikoji programski jezik ili arhitekturu i to im je jedna od najvedih prednosti.

3.5.1 Zašto ASN.1?

Današnje aplikacije izmjenjuju podatke koji su sve složeniji i složeniji. Protivno uvriježenom mišljenju, te razmjene nisu pojednostavnile svoju strukturu (iako su ubrzane razvojem tehnologije). Dapače, mreže i računala svakim danim tvore sve heterogeniji svijet. Računala mogu imati različitu internu reprezentaciju podataka koje spremaju - na primjer, velika vedina koristi ASCII kodiranje, dok neki poput IBM-ovih mainframe računala pak koriste EBCDIC kodiranje. Heterogenost se očituje i u samim arhitekturama - Intelovi procesori slažu bitove unutar okteta s desna na lijevo dok je kod Motorolinih to suprotno (čuveni little Endian i big Endian). Razlika među programskim jezicima je također značajna. Primjerice, neki podatak de u jednom programskom jeziku biti prikazan kao polje cijelih brojeva dok de u drugom to biti lista cijelih brojeva. U jeziku C, svaki niz znakova mora biti terminiran znakom NULL, dok u ostalim jezicima to nije slučaj. Kako onda obaviti razmjenu podataka između različitih sustava? Jedno od mogudih rješenja je prikazano na slici 3.3. a). Svaki stroj zna svoju internu reprezentaciju podataka, kao i reprezentaciju od svih svojih (n-1) susjeda te se napravi dogovor o tome da li de format podataka biti onaj od pošiljatelja ili od primatelja. U oba slučaja, potrebno je n(n-1) programa za pretvaranje iz jednog formata u drugi. Drugo rješenje je razvoj zajedničkog formata podataka koji de biti standardiziran i prihvaden u cijelom svijetu. Iz slike 3.3 b) slijedi da je u tom slučaju potrebno n kodera i n dekodera, odnosno ukupno 2n programa za pretvaranje što je puno manje od n(n-1). Još važnije, sustav ne mora znati internu reprezentaciju podataka od drugog sustava s kojim želi komunicirati, ved samo kako pretvoriti podatke u standardizirani format te iz njega u svoj format.

21

Slika 3.3. Dva načina međusobne komunikacije

3.5.2 Konkretna sintaksa, apstraktna sintaksa, sintaksa prijenosa

Kada se govori o ASN.1, tri pojma su neizostavna: konkretna sintaksa, apstraktna sintaksa i sintaksa prijenosa. Konkretna sintaksa je prikaz struktura koje se trebaju prenijeti u nekom konkretnom programskom jeziku. To je 'sintaksa' zato jer slijedi određena leksička i sintaksna pravila jezika (npr. C-a), a naziv 'konkretna' ima zato jer podliježe zakonitostima određene računalne arhitekture i zato jer ju koriste aplikacije implementirane u tom određenom jeziku. Primjer konkretne sintakse su sljededi zapisi u C-u, odnosno Javi:

typedef struct { public class Zapis {

char ime[30+1]; String ime;

int godine; int godine;

enum { musko=1; boolean spol;

zensko=2; } spol; }

} Zapis;

Kao što se vidi, isti zapis je na dva dosta različita načina predstavljen u različitim programskim jezicima. Da bi se premostila ta razlika između konkretnih sintaksi, strukture podataka koje se prenose moraju biti opisane na isti način, neovisno o korištenom programskom jeziku. Taj opis također mora slijediti određena leksička i sintaksna pravila ali mora ostati neovisan o programskom jeziku i nikad ne smije direktno biti implementiran na nekom stroju. Zato se takav opis zove apstraktna sintaksa, odnosno ASN kao zapis te sintakse. Iako neovisna o programskom jeziku, apstraktna sintaksa mora biti barem jednako modna kao bilo koji formalizam tipova podataka u bilo kojem programskom jeziku. Drugim riječima, mora biti omogudeno stvaranje složenih tipova podataka iz jednostavnih

22

(ekvivalentnih tipovima npr. string, int, enum..), te moraju biti podržani složeni konstrukti (ekvivalentni npr. struct, union..).

Konačno, sintaksa prijenosa predstavlja sintaksu kojoj podliježu bitovi i okteti u prijenosu kako bi se mogli ispravno protumačiti od strane primatelja. Naravno, sintaksa prijenosa izrazito ovisi o apstraktnoj sintaksi bududi da se poredak kojim podaci moraju biti prenešeni određuje prema apstraktnoj sintaksi. Sintaksa prijenosa oblikuje i raspoređuje oktete koji se šalju drugom stroju (taj proces ponekad se zove marshalling). Ovdje se vodi računa o međusobnom rasporedu okteta, težini pojedinog bita unutar okteta i sl. Kod ASN.1, sintaksu prijenosa predstavljaju pravila kodiranja.

3.5.3 Pravila kodiranja

Uz ASN.1 se najčešde povezuju osnovna pravila kodiranja odnosno BER (Basic Encoding Rules). Ona kodiraju podatke u obliku identifikator-duljina-vrijednost, odnosno TLV (tag-length-value). Zbog svoje jednostavnosti široko su prihvadena te dopuštaju određenu slobodu prilikom kodiranja podataka. Upravo ta sloboda je ono što je nedopustivo u nekim aplikacijama, kao što su one povezane sa sigurnošdu. Dobar primjer je slanje poruke s digitalnim potpisom od pošiljatelja k primatelju, ali preko posrednika. Ako pošiljatelj šalje vrijednost v, on ju prvo kodira (ne i kriptira!) svojim pravilima kodiranja i računa digitalni potpis iz rezultirajude poruke c1(v). Posredniku se šalju kodirana poruka c1(v) i potpis s(c1(v)). Posrednik dekodira vrijednost v, a digitalni potpis ne mijenja. Vrijednost v se prije slanja prema konačnom odredištu ponovo kodira, ali koristedi proceduru c2 koja može biti različita od c1 te se kodiranoj poruci pridruži isti digitalni potpis s(c1(v)). Primatelj računa digitalni potpis s(c2(v)) te zaključuje da oni nisu jednaki i odbacuje poruku. Ovo sve se može desiti iz razloga što BER dopuštaju određen stupanj slobode prilikom implementacije kodera, primjerice boolean vrijednost true može se predstaviti sa više različitih okteta.

Pravila kodiranja koja ne ostavljaju nikakvu slobodu zovemo kanonskim pravilima kodiranja. Dva skupa kanonskih pravila kodiranja su izvedena iz BER i standardizirana 1994.: CER (Cannonical Encoding Rules) i DER(Distinguished Encoding Rules). Oni predstavljaju specijalizaciju osnovnih pravila kodiranja, što znači da BER dekoder može dekodirati podatke nastale CER ili DER kodiranjem. Obrat očito ne vrijedi. Osnovna razlika između ta dva skupa pravila je što CER koristi neodređeni oblik duljine podatka (indefinite-length format), dok DER koristi određeni oblik duljine podatka (definite-length format). Kao rezultat, CER su namijenjena u prvom redu aplikacijama koje moraju prenijeti veliku količinu podataka.

X.509 certifikati najčešde se kodiraju CER i DER pravilima kodiranja i tako postaju pogodni za korištenje u sustavima različitih arhitektura.

23

4. Centar za pouzdano vremensko označavanje

4.1 Centar za pouzdano vremensko označavanje vremenskih oznaka

Centar za pouzdano vremensko označavanje (Timestamp Authority, TSA) kreira vremenske oznake da bi označio da su podaci postojali u određenom trenutku u vremenu, bez mogudnosti da se kasnije tvrdi da su ti isti podaci postojali prije trenutka navedenog u vremenskoj oznaci. Tehnika stvaranja vremenskih oznaka temelji sa na digitalnom potpisu i funkcijama sažimanja. Podnosilac zahtjeva za vremenskom oznakom najprije izračuna sažetak podataka (npr. nekog dokumenta). Zatim taj sažetak pošalje centru za vremensko označavanje. TSA kreira vremensku oznaku (postupkom koji de detaljno biti opisan kasnije). Vremenska oznaka može biti npr. trenutno vrijeme. Zatim, TSA na primljeni sažetak nadodaje vremensku oznaku, te izračunava sažetak rezultata. Tako dobiveni sažetak TSA potpisuje svojim privatnim ključem. Ovako potpisani sažetak šalje zajedno s vremenskom oznakom natrag podnosilacu zahtjeva. Podnosilac zahtjeva zajedno sprema potpisani sažetak, vremensku oznaku i originalne podatke. Ovaj postupak prikazan je slikom 4.1. [10].

Dokument

1011 .... 101011

1011 .... 101011 vremenska oznaka

0100 .... 110010

vremenska oznaka0100 .... 110010

vremenska oznaka0100 .... 110010Dokument

izračunaj sažetakpošalji sažetak TSA - u

potpisana vremenska oznakaI sažetak se vraćajupodnosilacu zahtjeva

primijeni privatni ključ

od TSA

Tvrtka TSA

pohranitii zajedno

ovo je digitalni potpis

sažetka s

pridodanom

vremenskom oznakom

izračunaj sažetak

Slika 4.1. Postupak izdavanja vremenske oznake

Kako se originalni podaci ne mogu izračunati iz sažetka, TSA nikada ne barata originalnim podacima, što omogudava uporabu ove metode i za povjerljive podatke.

Svatko tko vjeruje izdavaču vremenske oznake može provjeriti da dokument nije stvoren niti mijenjan nakon datuma koji tvrdi izdavač. Također, ne može se poredi da je podnosilac zahtjeva za vremenskom oznakom bio u posjedu originalnog dokumenta u vremenu naznačenom vremenskom oznakom. Da bi ovo dokazao, podnosilac zahtjeva izračunava sažetak originalnih podataka, nadodaje mu vremensku oznaku koju je dobio od TSA, te izračunava sažetak rezultata. Nazovimo ovaj sažetak sažetak A. Zatim mora provjeriti da je

24

TSA zaista potpisao sažetak svojim privatnim ključem. Da bi ovo napravio, javnim ključem od TSA (zapisanim na certifikatu) dekriptira poruku dobivenu od TSA. Nazovimo ovo sažetkom B. Na kraju, uspoređuje sažetak A sa sažetkom B. Ako su isti, dokazano je da su i vremenska oznaka i dokument nepromijenjeni, te da su izdani od TSA. Ako nisu, to znači ili da je vremenska oznaka promijenjena ili da ju nije izdao navedeni TSA. Postupak provjere vremenske oznake prikazan je slikom 4.2.

Dokumentvremenska oznaka 0100 .... 110010

1011 .... 101011

0100 .... 110010

izračunaj sažetak

izračunaj sažetak

0100 .... 110010

primijeni javni ključ

od TSA

Slika 4.2. Postupak provjere vremenske oznake

4.2 Uloga centra za vremensko označavanje u PKI sustavu

TSA mora:

1. koristiti vjerodostojan izvor vremena; 2. uključiti vjerodostojnu vrijednost vremena u svaku vremensku oznaku; 3. uključiti jedinstven cijeli broj u svaku novo generiranu vremensku oznaku; 4. napraviti vremesku oznaku nakon zaprimljenog valjanog zahtjeva, ako je to

mogude; 5. u svaku vremensku oznaku uključiti identifikator kojim de se jedinstveno

naznačiti sigurnosna politika unutar koje je oznaka stvorena; 6. vremenski označiti samo sažetak podataka, tj. podatkovnu oznaku nastalu

jednosmjernom funkcijom sažimanja jedinstveno identificiranom sa OID-iom; 7. pregledati OID jednosmjerne funkcije sažimanja otporne na kolizije, te

provjeriti da duljina sažetka odgovara algoritmu sažimanja; 8. ne smije pregledavati sažetak kojeg treba vremenski označiti niti na jedan

drugi način, osim provjere duljine opisane u točki 7; 9. ne smije uključiti nikakvu oznaku entiteta koji zahtijeva vremensku oznaku u

samu vremensku oznaku; 10. potpisati svaku vremensku oznaku koristedi ključ generiran isključivo za ovu

namjenu i imati ovo svojstvo ključa označeno na pripadajudem certifikatu;

25

11. ako podnosilac zahtjeva koristi polja proširenja, mora uključiti dodatne informacije u vremensku oznaku, ali samo za ona proširenja koja su podržana od strane TSA. Ako to nije mogude, TSA bi trebao odgovoriti s porukom o grešci.

4.3 TSA transakcije

Entitet zatražuje vremensku oznaku šaljudi zahtjev centru za pouzdano vremensko označavanje, TSA-u. TSA šalje odgovor entitetu koji je tražio vremensku oznaku.

Nakon primitka odgovora, koji bi trebao sadržavati vremensku oznaku podnosilac zahtjeva provjerava status poruke o grešci primljen u odgovoru, i ako nema greške trebao bi provjeriti razna polja sadržana u vremenskoj oznaci, te valjanost digitalnog potpisa vremenske oznake. Posebice, trebao bi provjeriti da ono što je vremenski označeno odgovara onome što je bilo zatraženo za vremensko označavanje. Podnosilac zahtjeva mora provjeriti i da vremenska oznaka sadrži odgovarajudi identifikator certifikata od TSA, točan sažetak podataka i točan OID algoritma sa sažimanje. Zatim mora provjeriti pravovremenost odgovora uspoređujudi ili vrijeme uključeno u odgovor s lokalnim referentnim vremenom (ako postoji) ili vrijednost velikog slučajnog broja s velikom vjerojatnošdu da ga je klijent izgenerirao samo jednom (tzv. number used only once, ili skradeno nonce) uključenog u odgovor s onim uključenim u zahtjev. Ako makar jedna od ovih provjera ne uspije, vremenska oznaka de biti odbačena. Nakon toga podnosilac zahtjeva provjerava status certifikata od TSA, da se ustanovi je li certifikat vremenski valjan i da nije opozvan. Naposljetku, klijentska aplikacija treba provjeriti polje politike unutar koje je vremenska oznaka nastala da se utvrdi je li ta politika prihvatljiva za aplikaciju.

4.4 Identifikacija TSA

TSA mora potpisati svaku vremenski označenu poruku sa ključem rezerviranim isključivo za tu svrhu. TSA može imati razne privatne ključeve, npr. za podršku raznih politika, raznih algoritama, raznih veličina privatnih ključeva ili za poboljšanje radnog učinka. Pripadajudi certifikat mora sadržavati samo jednu oznaku polja ekstenzije proširene uporabe ključa, kako je definirano u RFC-om 2459 i ta ekstenzija mora biti označena kao kritična.

4.5 Format zahtjeva za vremenskom oznakom

Zahtjev za vremenskom oznakom prikazan je slikom 4.3.

26

Verzija (v1)

Politika zahtjeva

Veliki broj

Zahtjev za certifikatom

Obilježje poruke

Oznaka algoritma

Sažetak poruke

- opcionalno polje

Proširenja

Slika 4.3. Struktura zahtjeva za vremenskom oznakom

Verzija (trenutno verzija 1) označava verziju zahtjeva za vremenskom oznakom.

Obilježje poruke sadržava sažetak podataka za koji se traži vremenska oznaka, te oznaku algoritma sažimanja. Duljina sažetka mora odgovarati duljini koji proizvodi navedeni algoritam sažimanja (npr. 20 bajtova za SHA-1 ili 16 bajtova za MD). Algoritam sažimanja bi trebao biti jedan od poznatih algoritama sažimanja, tj. jednosmjeran i otporan na kolizije. Ako TSA ne prepozna zadani algoritam sažimanja, ili zna da on nije dovoljno jak, TSA mora odbiti stvaranje vremenske oznake i vratiti pkiStatusInfo postavljen na badAlg.

Oznaka politike je opcionalno polje, te ako je uključena, označava TSA politiku unutar koje bi TSA trebao napraviti vremensku oznaku.

Nonce je opcionalno polje, te ako je uključen dozvoljava klijentu da provjeri pravovremenost odgovora ako ne postoji lokalni sat. Nonce je veliki slučajni broj (npr. 64-bitni cijeli broj). Vjerojatnost da de klijent izgenerirati upravo taj broj samo jednom je poprilično velika. Ako je nonce uključen u zahtjev, ta ista vrijednost mora biti uključena u odgovor. U suprotnom, odgovor de biti odbijen.

Polje zahtjeva za certifikatom je također opcionalno polje koje poprima vrijednost true ili false. Ako je uključeno u zahtjev i postavljeno na true, označava da TSA u odgovor mora uključiti certifikat na kojem je javni ključ koji odgovara privatnom ključu kojim je TSA potpisao vremensku oznaku. U odgovoru mogu biti sadržani i drugi certifikati. Ako polje zahtjeva za certifikatom nije uključeno u zahtjev ili ako je postavljeno na false, tada certifikati ne smiju biti uključeni u odgovor.

Polje proširenja je generički način za dodavanje dodatnih informacija u zahtjev u bududnosti. Ako TSA ne prepozna proširenje uključeno u zahtjev, bez obzira bilo ono označeno kao kritično ili nekritično, TSA bi trebao odbiti stvaranje vremenske oznake i vratiti poruku o grešci označenu kao unacceptedExtension.

27

Zahtjev za vremenskom oznakom ne sadrži nikakvu oznaku o podnosilacu zahtjeva, niti TSA zahtijeva takve informacije. U slučajevima kad TSA ipak zahtijeva identifikaciju podnosilaca zahtjeva, trebaju se koristiti alternativni oblici identifikacije / autentifikacije (npr. CMS enkapsulacija ili TLS autentikacija).

4.6 Format odgovora

Odgovor je prikazan slikom 4.4.

Vremenska oznaka

status

statusInformacija

o grešciporuka

- opcionalno polje

Slika 4.4. Format odgovora na zahtjev za izdavanje vremenske oznake

Kada status sadrži vrijednost 0 ili 1, vremenska oznaka mora biti prisutna. Kada status sadrži vrijednost drugačiju od 0 ili 1, vremenska oznaka ne smije biti uključena u odgovor. PKIStatus mora poprimiti jednu od vrijednosti prikazanih tablicom 4.1.

Tablica 4.1. Dozvoljene vrijednosti u PKIStatus –u

odobreno (granted) 0

odobreno s modifikacijama (grantedWithMods) 1

odbijeno (rejection) 2

čekanje (waiting) 3

upozorenje o opozvanosti (revocationWarning) 4

informacija o opozvanosti (revocationNotification) 5

Upozorenje o opozvanosti ,4- označava da je opozvanost neizbježna i da de nastupiti uskoro, dok informacija o opozvanosti ,5- označava da je opozvanost ved nastupila.

TSA ne bi trebao proizvesti nikakve druge oznake u status. Klijent mora izgenerirati grešku ako u statusu dobije vrijednost koju ne prepoznaje.

U slučajevima kada vremenska oznaka nije prisutna, informacija o grešci označava razlog zašto je odbijen zahtjev za stvaranje vremenske oznake. Informacija o grešci (PKIFailureInfo) može poprimiti jednu od vrijednosti prikazanih tablicom 4.2.

28

Tablica 4.2. Dozvoljene vrijednosti u PKIFailureInfo

badAlg 0 identifikator algoritma nije prepoznat ili nije podržan

badRequest 2 transakcija nije dozvoljena ili nije podržana

badDataFormat 5 predani podaci su u krivom formatu

timeNotAvailable 14 vremenski izvor od TSA nije dostupan

addInfoNotAvailable 17 zahtijevane dodatne informacije su nerazumljive ili

nisu dostupne

systemFailure 25 zahtjev ne može biti obrađen zbog pada sustava

Vrijednosti navedene u tablici su jedine vrijednosti u PKIFailureInfo koje bi trebale biti podržane. TSA ne bi smio generirati nikakve druge vrijednosti. Klijent mora izgenerirati grešku ako dobije vrijednost koju ne prepoznaje. Polje statusString u PKIStatusInfo se može koristiti za opis greške, kao npr. "sažetak poruke nije u ispravnom formatu".

4.7 Format vremenske oznake

Vremenska oznaka je CMS podatak koji mora imati identifikator koji jedinstveno opisuje tip sadržaja, te sam sadržaj. CMS je struktura pogodna za potpisivanje proizvoljnih podataka zajedno s pomodnim podacima i dodatnim informacijama te certifikatima i CRL listama koji su potrebni za provjeru podataka.Sadržaj se prenosi kao DER-kodirana vrijednost informacija o vremenskoj oznaci. Vremenska oznaka ne smije sadržavati nikakve druge potpise osim potpisa samog TSA. Identifikator certifikata od TSA mora biti uključen u polje o potpisnikovom certifikatu. Polja koja sadrži informacija o vremenskoj oznaci prikazana su slikom 4.5.

29

Verzija (v1)

Politika zahtjeva

Serijski broj

Poopćeno vrijeme

Preciznost

Obilježje poruke

Oznaka algoritma

Sažetak poruke

Poredak

Veliki broj

Proširenja

TSA

- opcionalno polje

Slika 4.5. Struktura informacije o vremenskoj oznaci

Verzija (trenutno verzija 1) opisuje verziju vremenske oznake. Odgovarajudi TSA mora biti u mogudnosti proizvesti vremensku oznaku verzije 1. Od dodatnih polja, jedino polje za nonce mora biti podržano. Podnosilaci zahtjeva za vremenskom oznakom moraju prepoznati verziju 1 vremenske oznake zajedno sa svim pripadajudim opcionalnim poljima, ali nisu obavezni razumjeti semantiku niti jednog proširenja ako je ono prisutno.

Polje za politku mora označavati politku od TSA unutar koje je proizveden odgovor. Ako je slično polje bilo prisutno u zahtjevu, onda ono mora imati istu vrijednost, inače se mora vratiti greška. Politika može uključivati informacije o uvjetima u kojima se vremenska oznaka smije koristiti ili o postojanju zapisa o vremenskim oznakama, kojim se kasnije utvrđuje da je vremenska oznaka autentična.

Obilježje poruke mora imati istu vrijednost kao i slično polje u zahtjevu, s tim da duljina sažetka mora odgovarati duljini koju proizvodi algoritam naveden u ovom polju.

Serijski broj je cijeli broj dodijeljen od TSA svakoj vremenskoj oznaci. On mora biti jedinstven za svaku vremensku oznaku koju izda pojedini TSA.

Poopdeno vrijeme je vrijeme kada je TSA kreirao vremensku oznaku. Izražava se kao UTC (Coordinated Universal Time) da bi se izbjegle konfuzije s lokalnom vremenskom zonom. UTC je vremenska ljestvica, bazirana na sekundama (SI), definirana i preporučena od strane CCIR-a i održavana od strane Međunarodnog ureda za utege i mjere (Bureau International des Poids et Mesures, BIPM). Sinonim za UTC je "Zulu" vrijeme koje se koristi u civilnom zrakoplovstvu i označava slovom Z.

30

ASN.1 sintaksa poopdenog vremena može uključivati i detalje o djelidima sekunde. Poopdeno vrijeme mora uključivati sekunde. No, kada nema potrebe za preciznošdu vedom od sekunde, koristi se poopdeno vrijeme s preciznošdu postavljenom na jednu sekundu. Sintaksa je:

YYYYMMDDhhmmss*.s...+Z, npr: 19990609001326.34352Z. Oznaka mora završavati slovom Z ("Zulu" vrijeme). Decimalna točka, ako je pristutna, mora biti izražena kao točka – ".". Dio iza decimalne točke, ako je prisutan, mora izostaviti sve nule na kraju. Ako je decimalni dio cijeli jednak nuli, on mora biti u potpunosti izostavljen, isto kao i decimalna točka.

Ponod je predstavljena u obliku: YYYYMMDD000000Z, gdje "YYYYMMDD" označavaju dan nakon ponodi o kojoj se radi. Evo nekoliko primjera ispravnih prikaza vremena:

"19920521000000Z"

"19920622123421Z"

"19920722132100.3Z"

Preciznost (accuraccy) predstavlja devijaciju od UTC vremena sadržanog u poopdenom vremenu. Dodavanjem preciznosti u poopdeno vrijeme, može se dobiti gornja granica vremena u kojem je TSA kreirao vremensku oznaku. Na sličan način, oduzimanjem preciznosti od poopdenog vremena, može se dobiti donja granica vremena u kojem je TSA kreirao vremensku oznaku. Preciznost se sastoji od sekunda, milisekunda (1 – 999) i mikrosekunda (1 – 999), od kojih su sva tri polja opcionalna. Ako jedno polje nedostaje, ono mora biti postavljeno na vrijednost nula. Ako polje preciznosti nije prisutno u odgovoru, preciznost može biti dostupna kroz druga polja, npr. identifikator politike TSA.

Ako polje poretka (ordering) nije prisutno, ili je prisutno i postavljeno na false, tada poopdeno vrijeme označava samo vrijeme kada je TSA kreirao vremensku oznaku. U tom slučaju, poredak vremenskih oznaka izdanih od istog ili različitih TSA je mogud samo ako je razlika između poopdenog vremena prve i druge vremenske oznake veda od zbroja preciznosti poopdenog vremena svake vremenske oznake. Ako je polje poretka prisutno i postavljeno na true, može se napraviti poredak svih vremenskih oznaka izdanih od istog TSA, na temelju samo poopdenog vremena, bez obzira na preciznost.

Polje nonce mora biti prisutno ako je bilo prisutno u zahtjevu i u tom slučaju mora biti postavljeno na istu vrijednost.

Svrha tsa polja jest pomod u identificiranju imena TSA. Ako je prisutno, mora odgovarati imenu koje je naznačeno u certifikatu kojim se provjerava vremenska oznaka. Međutim, prava identifikacija identiteta koji je potpisao odgovor de se uvijek vršiti kroz uporabu identifikatora certifikata unutar polja o potpisnikovom certifikatu.

Proširenja su generički način dodavanja dodatnih informacija u bududnosti. Neka proširenja mogu se specificirati standardom ili se mogu definirati samo od strane pojedine organizacije ili zajednice.

31

4.8 Prijenos TSA poruka

RFC 3161 opisuje prijenos TSA poruka, tj. implementaciju TSP protokola na nekoliko načina [11]. Tako su opisani TSP protokol koristedi e-mail, protokol baziran na prijenosu datoteka, protokol temeljen na pristupnim točkama (socket), te protokol baziran na HTTP-u. Ovdje de biti pobliže opisani protokol temeljen na datotekama, protokol temeljen na pristupnim točkama, te protokol temeljen na HTTP-u jer se oni koriste u praktičnom dijelu ovog rada.

4.8.1 Protokol temeljen na datotekama

Datoteka koja sadrži poruku vremenske oznake mora sadržavati samo DER kodiranu TSA poruku, tj. ne smije biti nikakvih dodatnih prethodedih ili završnih dijelova u datoteci. Takve datoteke se onda mogu koristiti za prijenos poruka uporabom npr. FTP protokola.

Zahtjev za vremenskom oznakom trebao bi biti sadržan u datoteci s ekstenzijom *.tsq (Timestamp Query). Odgovor bi trebao biti sadržan u datoteci s esktenzijom *.tsr (Timestamp Reply).

4.8.2 Protokol temeljen na TCP-u

Postoji jednostavan TCP (Transmittion Control Protocol) protokol koji se koristi za prijenos TSA poruka. Ovaj protokol je pogodan za slučajeve gdje entitet započinje transakciju i može prozivati da bi dobio odgovor.

Protokol pretpostavlja da na TSA postoji listener koji može primati TSA poruke na pristupu 318. Obično se inicijator spaja na ovaj pristup i šalje inicijalnu TSA poruku. Odgovaratelj odgovara sa TSA porukom i/ili sa brojem koji de se koristiti kasnije kada de pozivati pravi TSA odgovor. Ako se treba proizvesti niz poruka za dani zahtjev (npr. ako treba poslati potvrdu prije slanja same vremenske oznake), vrada se i novi broj za prozivanje.

Kada podnosilac zahjteva primi finalnu TSA poruku, nema novog broja za prozivanje.

Inicijator transakcije šalje "direktnu TCP-baziranu TSA poruku" (direct TCP-based TSA message) primatelju. Primatelj odgovara sa sličnom porukom.

"Direktna TCP-bazirana TSA poruka" sastoji se od:

1. duljine (32 bita) 2. zastavice (8 bita) 3. vrijednosti

Duljina sadrži broj okteta ostatka poruke (npr. broj okteta u vrijednosti plus jedan oktet). Poredak sva 32 bita u ovom protokolu je specifičan za poredak bajtova u mreži.

RFC 3161 definira 7 vrsta TCP poruka koje su prikazane tablicom 4.3.

32

Tablica 4.3. Vrste TCP poruka za komunikaciju između klijenta i TSA

ime poruke zastavica vrijednost značenje

tsaMsg '00'H DER-kodirana TSA poruka inicijalna TSA poruka

pollRep '01'H broj za prozivanje

odgovor na prozivanje kada TSA nije spreman na odgovor

vrijeme za ponovni pokušaj

pollReq '02'H broj za prozivanje zahtjev za odgovorom na

inicijalnu poruku

negPollRep '03'H '00'H označava da nema više

odgovora na prozivanje, tj. transakcija je završena

partialMsgRep '04'H

idudi broj za prozivanje djelomični odgovor na prozivanje i nova

procijenjena vrijednost kada se može tražiti idudi dio

odgovora

vrijeme za ponovni pokušaj

DER-kodirana TSA poruka

finalMsgRep '05'H DER-kodirana TSA poruka posljednji (i poželjno jedini) odgovor na inicijalnu poruku

errorMsgRep '06'H poruka o grešci nastaje kad nastupi greška

Slijed poruka koji može nastupiti je:

a) entitet šalje tsaMsg i prima ili pollRep, negPollRep, partialMsgRep ili finalMsgRep kao odgovor

b) krajnji entitet šalje pollReq poruku i prima jednu od negPollRep, partialMsgRep, finalMsgRep ili errorMsgRep kao odgovor.

Najjednostavniji slučaj izmjene TCP poruka je sljededi: klijent pošalje inicijalnu, tsaMsg poruku u kojoj je sadržan zahtjev za izdavanjem vremenske oznake. TSA je u tom trenutku u stanju čekanja, tj. nema zahtjeva koje trenutno obrađuje, te sukladno zahtjevu stvara vremensku oznaku i šalje je natrag klijentu u poruci finalMsgRep. Klijent, dobivši finalMsgRep zna da je dobio zadnji odgovor na inicijalnu poruku i prekida komunikaciju sa TSA.

Mogude je, međutim, da klijent pošalje inicijalnu, tsaMsg poruku, ali TSA u tom trenutku ved obrađuje neki zahtjev, te ne može trenutno obraditi klijentov zahtjev. TSA u tom slučaju stvara broj, sprema lokalno taj broj i klijentov zahtjev, te kreira pollRep poruku. U poruci su sadržani broj kojim de klijent kasnije ponovno tražiti izdavanje vremenske oznake i vrijeme nakon kojeg bi klijent trebao ponovno pokušati tražiti izdavanje. Klijent, primivši pollRep

33

poruku, čeka onoliko vremena koliko je specificirano u poruci. Nakon isteka tog vremena, klijent kreira pollReq poruku u kojoj je sadržan samo broj dobiven od TSA u prijašnjoj poruci. TSA, ukoliko je ovaj put slobodan, pod brojem dobivenim u pollReq poruci pronalazi originalni klijentov zahtjev, kreira vremensku oznaku , te finalMsgRep i šalje poruku natrag klijentu. Klijent, dobivši finalMsgRep zna da je dobio zadnji odgovor na inicijalnu poruku i prekida komunikaciju sa TSA. Ukoliko dođe do greške (npr. zahtjev pod brojem dobivenim u pollReq poruci ne postoji na poslužitelju), TSA odgovara sa porukom o grešci, tj. s errorMsgRep.

4.8.3 TSP putem HTTP protokola

HTTP (Hypertext Transfer Protocol) nudi jednostavan način razmjenu poruka vremenskih oznaka. Poruke se mogu prenositi preko svih koji podržavaju HTTP. U zahtjevu mora biti zapisano: Content-Type: application/timestamp-query

<<ASN.1 DER-kodiran zahtjev za vremenskom oznakom>>

U odgovoru mora biti zapisano: Content-Type: application/timestamp-reply

<<ASN.1 DER-kodiran odgovor vremenske oznake>>

Nakon primitka valjanog zahtjeva, poslužitelj (server) mora odgovoriti ili s valjanim odgovorom ili mora poslati HTTP grešku.

4.9 Sigurnosni problemi

Prilikom dizajniranja centra za izdavanje vremenskih oznaka, uočeno je nekoliko problema koji mogu imati utjecaja na "povjerenje" u vremensku oznaku.

1. Kada se TSA više nede koristiti, a privatni ključ od TSA nije kompromitiran, treba opozvati certifikat od TSA. Ako prilikom opoziva postoji polje u CRL listi u kojem treba navesti razlog opozivanja, treba navesti jedan od idudih (vidjeti tablicu 3.1.) :

0 – unspecified

3 – affiliationChanged

4 – superseded

5 – cessationOfOperation

Navođenjem ovih oznaka kao razlog opoziva postiže se da se sve vremenske oznake potpisane privatnim ključem nakon vremena opoziva smatraju nevaljanima, dok one potpisane prije vremena opoziva ostaju valjane. Ako prilikom opoziva ne postoji razlog opoziva kao polje u CRL listi, sve vremenske oznake potpisane pripadajudim privatnim ključem smatrat de se nevažedima.

Kao rješenje problema, preporuča se koristiti ekstenziju reasonCode u CRL listi, u koju se unosi razlog opoziva certifikata.

34

2. Ako je privatni ključ od TSA kompromitiran, tada treba opozvati pripadajudi certifikat. U tom slučaju, nije bitno je li razlog opoziva prisutan kao ekstenzija u CRL listi. Ako je prisutan, treba navesti vrijednost koja označava kompromitiranje privatnog ključa (keyCompromise – ,1-). Svaka vremenska oznaka izdana od TSA i potpisana tim privatnim ključem gubi vjerodostojnost. Iz ovog razloga, obavezno je da se privatni ključ od TSA čuva s velikom sigurnošdu i pod kontrolom, tako da se smanji mogudnost kompromitiranja. U slučaju da privatni ključ zaista postane kompromitrian, može se izvršiti kontrola zapisa svih vremenskih oznaka izdanih od strane TSA. Time se može barem donekle razlučiti između autentičnih vremenskih oznaka i onih s krivom oznakom vremena.

3. Ključ kojim TSA potpisuje vremenske oznake mora biti dovoljne duljine da mu se dozvoli dovoljno dug životni vijek. Bez obzira koliko dugačak ključ bio, on de uvijek imati ograničeni životni vijek. Stoga, svaka vremenska oznaka izdana od TSA trebala bi biti ponovno potpisana kasnije da se obnovi povjerenje u potpis od TSA. Drugi način očuvanja povjerenja u TSA je pohranjivanje vremenskih oznaka u Evidence Recording Authority (ERA).

4. Klijentska aplikacija koja koristi samo nonce, a ne i lokalni sat trebala bi voditi računa o vremenu koje je voljna čekati na odgovor. Napad čovjekom u sredini (man-in-the-middle attack) može uvesti kašnjenja. Stoga, svaki odgovor koji klijent dobije nakon određenog prihvatljivog vremena treba smatrati sumnjivim. Pošto svaki protokol prijenosa specificiran u poglavlju 4.8 ima drugačije karakteristike, prihvatljivo vrijeme kašnjenja ovisit de o korištenom protokolu, kao i o drugim faktorima iz okoline u kojoj se aplikacija izvršava.

5. Ukoliko različiti klijenti traže izdavanje vremenske oznake za isti podatak i koristedi isti algoritam sažimanja, ili ako jedan klijent traži izdavanje više vremenskih oznaka za isti podatak, generirane vremenske oznake sadržavat de isti sažetak poruke. Kao posljedica toga, promatrač s pristupom tim oznakama mogao bi zaključiti da vremenske oznake označavaju isti podatak.

6. Mogu se dogoditi nenamjerni ili namjerni duplikati zahtjeva koji sadrže isti sažetak i isti algoritam sažimanja. Nenamjerni duplikati zahtjeva događaju se kad se ista poruka pošalje TSA-u dvaput zbog problema u mreži. Namjerni duplikati nastaju kada čovjek u sredini reproducira legitimne odgovore od TSA. Da bi se otkrile ovakve situacije, koristi se nekoliko tehnika. Korištenje nonce-a uvijek dozvoljava da bi se otkrili duplikati, i stoga je njegova uporaba preporučljiva. Druga mogudnost je uporaba i lokalnog sata i mijenjajudeg vremenskog okvira unutar kojeg podnosilac zahtjeva pamti sve sažetke poslane u tom okviru. Ako se ista vrijednost sažetka pojavljuje više nego jednom u vremenskom okviru, podnosilac zahtjeva može ili upotrijebiti nonce ili pričekati da se vremenski okvir vrati natrag na vrijednost gdje se isti sažetak pojavljivao samo jednom u vremenskom okviru.

35

5. Programsko ostvarenje

U praktičnom dijelu detaljan naglasak stavljen je na protokol razmjene vremenskih oznaka, TSP, kako specificira RFC 3161. Implementirani su centar za izdavanje vremenskih oznaka, timestamp authority (TSA), te klijent koji traži izdavanje vremenske oznake. Razmjenu poruka između TSA i klijenta mogude je ostvariti protokolima TCP i HTTP. Neovisno o korištenom protokolu, TSA i klijent ostvaraju istu funkcionalnost.

Klijent ostvaruje 4 osnovne funkcije:

stvaranje zahtjeva za vremenskom oznakom

slanje zahtjeva TSA-u jednim od navedenih protokola

provjeravanje odgovora dobivenog od TSA (je li ono što je dobio ono što je trebao dobiti, te ukoliko je izdana vremenska oznaka provjerava je li ju izdao provjereni TSA)

provjera X.509 certifikata od TSA (ukoliko je certifikat uključen u odgovor)

TSA ostvaruje 2 osnovne funkcije:

stvaranje vremenske oznake nakon dobivenog zahtjeva (ukoliko je to mogude)

slanje odgovora natrag klijentu

Komunikacija između poslužitelja i klijenta u potpunosti je implementirana u programskom jeziku Java, uz korištenje kriptografskog open-source paketa Bouncy Castle[13] , te Java SWT skupa alata za izradu grafičkog sučelja [14].

Naposlijetku, prikazan je primjer uporabe vremenskih oznaka u sustavu e-trgovine. E – trgovina ima mogudnost kupovine s popustom za registrirane korisnike. Ona sastavlja ugovor o kupovini s popustom, šalje ugovor klijentu koji zatim od TSA traži izdavanje vremenske oznake. Klijent po dobivenom odgovoru od TSA odgovara e – trgovini. Korisnik koji prihvati vremenski potpisan ugovor ima pravo na kupovinu s popustom.

E–trgovina također je u potpunosti je implementirana korištenjem Jave, točnije *.jsp stranica i servleta. Kao baza koristi se MySql [15].

5.1 Vremenske oznake, zahtjevi i odgovori

U diplomskom radu koristi se Bouncy Castle implementacija vremenskih oznaka, zahtjeva za izdavanjem vremenskih oznaka, te odgovora s vremenskim oznakama. Ova implementacija u potpunosti je napravljena prema specifikacijama RFC-a 3161, tako da se ovdje nede detaljno opisivati. Slike 5.1. i 5.2. prikazuju strukture razreda zahtjeva za vremenskom oznakom, te odgovora na zahtjev.

36

Slika 5.1. Struktura razreda zahtjeva za vremenskom oznakom

Slika 5.2. Struktura razreda odgovora na zahtjev s vremenskom oznakom

5.2 Poslužitelj za izdavanje vremenskih oznaka

Poslužitelj za izdavanje vremenskih oznaka implementiran je također prema specifikacijama RFC-a 3161. Poslužitelj koristi X.509 certifikat za potpisivanje vremenskih oznaka. Za digitalno potpisivanje certifikata koristi se RSA algoritam s duljinom ključa od 2048 bita. Ova duljina odabrana je da bude dovoljna velika tako da se izbjegne sigrunosni problem opisan u poglavlju 4.9 pod točkom 3. Kao algoritam sažimanja koristi se MD5. X.509 certifikat ima samo jedno polje proširene uporabe ključa, a to je id-kp-timeStamping (OID

37

1.3.6.1.5.5.7.3.8), s tim da je ta ekstenzija označena kao kritična. Certifikat se generira koristedi Bouncy Castle provider. Svaku izdanu vremensku oznaku TSA potpisuje privatnim ključem koji pripada tom certifikatu. Zbog pojednostavljenja aplikacije, ne generira se i ne objavljuje CRL u koju bi se spremali opozvani certifikati.

U programskom ostvarenju, struktura centra za izdavanje vremenskih oznaka je hijerarhijska. Na vrhu hijerarhije je razred TSA koji implementira logiku izdavanja vremenskih oznaka. Ovaj razred omoguduje podešavanje paramatera odgovora, kao što su korištenje preciznosti, te specificiranje preciznosti u sekundama, milisekundama i mikrosekundama. Postavke se inicijalno učitaju iz unaprijed zadane konfiguracijske datoteke (serverProperties.properties), a kasnije ih korisnik može ručno promijeniti preko grafičkog sučelja. Za učitavanje datoteke iskorišten je razred java.util.Properties, koji predstavlja mapu s podrškom za učitavanje i snimanje iz/u datoteku s ekstenzijom *.properties. Struktura datoteke *.properties prati strukturu hash mape – u njoj su definirani ključ s pripadajudom vrijednošdu. Prilikom učitavanja, učitaju se sve vrijednosti ključeva s pripadajudim vrijednostima, te se odgovarajude varijable u TSA postavljaju na učitane vrijednosti. Prednost datoteke *.properties je da korisnik može u bilo kojem tekstualnom editoru mijenjati sadržaj datoteke. Jedino je bitno da prilikom mijenjaja sadržaja mijenja samo polje vrijednosti, a ne mijenja polje ključa. Primjer inicijalne konfiguracijske datoteke serverProperties.properties:

use_Accuracy=true

seconds=10

milis=77

micros=55

use_Ordering=false

Vidljivo je da se polje ključa nalazi s lijeve strane znaka jednakosti, dok se vrijednosti nalaze s njegove desne strane.

Razred Server naslijeđuje razred TSA, te dodaje još logiku za povezivanje centra za izdavanje vremenskih oznaka s klijentom koji traži izdavanje vremenskih oznaka. Bududi da je implementirano povezivanje klijenta i poslužitelja putem TCP protokola, te HTTP protokola, razred Server nasljeđuju dva razreda: HTTPServer, te TCPServer. Ovi razredi razlikuju se u implementaciji metode start(), tj. u načinu na koji se povezuju na pristupnu točku i na koji primaju zahtjeve od klijenta. No, bez obzira na korišteni protokol, za svaki novi zahtjev pristigao na poslužitelj stvara se nova dretva koja zatim obrađuje taj zahtjev. I dretva u HTTP protokolu, i dretva u TCP protokolu de nakon primljenog zahtjeva taj zahtjev proslijediti TSA-u. Ako je zahtjev valjan, TSA de pokušati stvoriti vremensku oznaku i odgovor na zahtjev za izdavanje vremenske oznake. Ovisno o korištenom protokolu, poslužitelj de odgovoriti klijentu tako što de odgovor uključiti ili u TCP poruku ili u HTTP odgovor. O načinu prijenosa poruka detaljnije de biti govora kasnije. Ako dođe do greške u stvaranju odgovora, TSA de izgenerirati poruku o grešci. Poslužitelj de zatim odgovoriti klijentu također na način karakterističan za korišteni protokol – ukoliko se radi o TCP protokolu, poslat de TCP ErrorMsgRep poruku, a ukoliko se radi o HTTP poslužitelju, poslat de HTTP odgovor s greškom 500.

38

Struktura poslužitelja prikazana je slikom 5.3. Radi pojednostavljenja dijagrama razreda i bolje preglednosti slike, iz dijagrama su izbačeni getteri i setteri privatnih varijabli pojedinih razreda.

Slika 5.3. Razredi korišteni za ostvarenje centra za izdavanje vremenskih oznaka

39

5.3 Komunikacija između poslužitelja i klijenta

5.3.1 Komunikacija putem TCP protokola

Da bi se omogudila komunikacija poslužitelja i klijenta putem TCP protokola, implementirane su odgovorajude poruke, kako je opisano u poglavlju 4.8.2 (vidjeti tablicu 4.3).

Strukutura poruka prikazana je slikom 5.4.

Slika 5.4. Struktura TCP poruka

Razred TCPBasedTSAMessage je vršni razred kojeg nasljeđuje 7 razreda: TsaMsg, PollRep, PollReq, NegPollRep, PartialMsgRep, FinalMsgRep, ErrorMsgRep.

TCPBasedTSAMessage ima 3 polja, kako je i propisano RFC-om. Polja su: duljina, zastavica, i vrijednost. Ovakva struktura poruka pogodna je za TCP protokol, jer se iz pristupne točke najprije učitaju 4 bajta duljine. Ako je učitana vrijednost numerička vrijednost, učita se ostalih n bajtova poruka, gdje n odgovara učitanoj duljini. Nakon učitanih vrijednost, pokuša se stvoriti TCPBasedTSAMessage. Prilikom stvaranja provjerava se odgovara li učitana duljina duljini ostatka poruke, te je li učitana zastavica u skupu prihvatljivih zastavica (00H – 06H).

40

Klijent poslužitelju šalje dvije od ovih poruka – TsaMsg i PollReq. Poslužitelj može odgovoriti sa PollRep, FinalMsgRep, ErrorMsgRep. PartialMsgRep i NegPollRep nisu podržane u ovoj implementaciji protokola.

Mogude je nekoliko slučajeva razmjene poruka između klijenta i poslužitelja. Najjednostavniji (i poželjni) slučaj je kako slijedi.

4. Korisnik šalje u razgovijetnom obliku originalnu datoteku klijentu u poruci M1 = (originalna datoteka).

5. Po primitku M1 klijent stvara sažetak primljene poruke M1, te generira zahtjev za vremenskom oznakom. Klijent stvoreni zahtjev uključuje u tsaMsg poruku i šalje poslužitelju poruku: M2 = (tsaMsg).

6. Poslužitelj po primitku M2, ukoliko je slobodan, generira vremensku oznaku, te stvara odgovor sa vremenskom oznakom. Odgovor uključuje u finalMsgRep, te šalje klijentu poruku: M3 = (finalMsgRep).

7. Po primitku M3 klijent provjerava dobiveni odgovor (više o koracima provjere bit de rečeno kasnije). Ukoliko odgovor odgovara poslanom zahtjevu, klijent šalje korisniku poruku: M4 = (vremenski potpisana datoteka).

8. Po primitku M4, korisnik sprema vremenski potpisanu datoteku za budude korištenje.

Opisani slijed razmjene poruka prikazan je slikom 5.5.

klijent Server

M2 = (tsaMsg)

M1 = (originalni dokument)

M3 = (finalMsgRep)

korisnik

M4 = (dokument s vremenskom

oznakom)

Slika 5.5. Primjer razmjene TCP poruka između klijenta i poslužitelja

Bitno je napomenuti da ukoliko je u nekom dijelu čitanja klijentovog zahtjeva ili izdavanja vremenske oznake došlo do pogreške, poslužitelj odgovara sa errorMsgRep.

41

U slučaju da poslužitelj u nekom trenutku primitka zahtjeva za izdavanjem vremenske oznake nije u mogudnosti odmah izdati vremensku oznaku, mogudi slijed razmjene poruka je idudi.

1. Korisnik šalje u razgovijetnom obliku originalnu datoteku klijentu u poruci M1 = (originalna datoteka).

2. Po primitku M1 klijent stvara sažetak primljene poruke M1, te generira zahtjev za vremenskom oznakom. Klijent stvoreni zahtjev uključuje u tsaMsg poruku i šalje poslužitelju poruku: M2 = (tsaMsg).

3. Poslužitelj po primitku M2, ukoliko nije slobodan, generira slučajan broj, pohranjuje zahtjev, te odgovara s porukom u koju je upisao generirani slučajan broj i vrijeme nakon kojeg klijent treba pokušati ponovno tražiti odgovor. Poslužitelj klijentu šalje poruku: M3 = (pollRep).

4. Po primitku M3, klijent čeka navedeni broj sekundi, a nakon isteka tog vremena stvara poruku u koju uključuje broj dobiven od poslužitelja u M3. Poslužitelju šalje poruku M4 = (pollReq).

5. Po primitku M4, poslužitelj ukoliko je slobodan među zahtjevima koji čekaju na obradu, pod brojem dobivenim u M4, pronalazi klijentov zahtjev, generira vremensku oznaku, te stvara odgovor sa vremenskom oznakom. Poslužitelj klijentu šalje poruku M5 = (finalMsgRep). Ako je poslužitelj po primitku M4 zauzet, ponavljaju se koraci 2 i 3, sve dok poslužitelj po primitku M4 ne bude slobodan.

9. Po primitku M5 klijent provjerava dobiveni odgovor. Ukoliko odgovor odgovara poslanom zahtjevu, klijent šalje korisniku poruku: M6 = (vremenski potpisana datoteka).

10. Po primitku M6, korisnik sprema vremenski potpisanu datoteku za budude korištenje.

Navedeni slijed razmjene poruka prikazan je slikom 5.6.

42

klijent Server

M2 = (tsaMsg)

M1 = (originalni dokument)

M5 = (finalMsgRep)

korisnik

M6 = (dokument s vremenskom

oznakom)

M3 = (pollRep)

M4 = (pollReq)

Slika 5.6. Primjer razmjene TCP poruka između klijenta i poslužitelja

Da bi TCPServer mogao podržati ovakav protokol, on u jednu varijablu sprema svoje trenutno stanje. Stanje može biti: WAITING, RECEIVED_INITIAL, RECEIVED_POLLREQ. WAITING označava da je poslužitelj slobodan, i da nakon zaprimljenog zahtjeva može započeti izradu FinalMsgRep. RECEIVED_INITIAL označava da je poslužitelj zaprimio TsaMsg i da ju trenutno obrađuje. RECEIVED_POLLREQ označava da je poslužitelj zaprimio PollReq poruku i da ju trenutno obrađuje. U oba slučaja, poslužitelj de krenuti s izradom PollRep poruke, jer nije u mogudnosti izdati vremensku oznaku. Nakon završene obrade TsaMsg ili PollReq poruke, poslužitelj se opet stavlja u stanje WAITING.

Pošto se na poslužitelj može spojiti istovremeno više klijenata, a svaki novi zahtjev obrađuje nova dretva, čitanje i postavljanje varijable stanja potrebno je proglasiti kritičnim odsječkom. U suprotnom, moglo bi se dogoditi da dvije dretve istovremeno pročitaju da je poslužitelj slobodan i krenu u izradu odgovora. To bi rezultiralo padom poslužitelja, jer ne može stvarati dvije vremenske oznake istovremeno. Ovaj problem se rješava uporabom java.util.concurent.Semaphore razreda, čija implementacija odgovora klasičnom binarnom semaforu. Pojednostavljeni dio koda kojim se postiže sinkronizacija nakon što je zaprimljena TsaMsg:

TsaMsg tsaMsg = new TsaMsg(receivedMessage);

semaphore.acquire();

if (state.equals(State.WAITING)) {

state = State.RECEIVED_INITIAL;

semaphore.release();

output = makeFinalMsgRep(request);

semaphore.acquire();

state = State.WAITING;

semaphore.release();

} else if (state.equals(State.RECEIVED_INITIAL) ||

43

state.equals(State.RECEIVED_POLLREQ)) {

semaphore.release();

output = makePollRep(request);

}

Slično izgleda i postavljanje stanja kod primitka PollReq poruke.

5.3.2 Komunikacija putem HTTP protokola

Komunikacija putem HTTP protokola slična je od onoj putem TCP protokola. Klijent šalje poslužitelju zahtjev vremenskom oznakom tako da u zaglavlju HTTP zahtjeva postavi Content-Type na application/timestamp-query, a u tijelu zahtjeva postavi DER – kodirani zahtjev. Poslužitelj, ukoliko je stvorio odgovor odgovara tako da u zaglavlju postavi Content-Type na application/timestamp-response, a u tijelu šalje DER – kodirani odgovor. Ukoliko je došlo do greške prilikom izdavanja vremenske oznake, poslužitelj odgovara sa HTTP greškom 500.

Pošto RFC 3161 ne specifira detaljno kojim porukama se prenose zahtjevi i odgovori, u implementaciji klijent zahtjev šalje sa HTTP POST, dok sever odgovora sa standardnim HTTP 200 OK. Klijent može od poslužitelja tražiti ved gotovu datoteku s odgovorom, i u tom slučaju šalje standardni HTTP GET zahtjev s imenom datoteke. Na ovaj način datoteku je mogude dohvatiti i iz običnog web preglednika. Ukoliko datoteka postoji na poslužitelju, poslužitelj de ju vratiti klijentu, opet šaljudi HTTP 200 OK. Ukoliko ne postoji, vratit de HTTP grešku 404.

Ukoliko zaglavlje sadrži polje s duljinom sadržaja (Content – Length), duljina služi za provjeru je li primljeni sadržaj one duljine koje bi trebao biti, tj. duljine koja je naznačena.

Primjer razmjene poruka između HTTP poslužitelja i HTTP klijenta opisan je u idudih nekoliko koraka.

1. Korisnik šalje u razgovijetnom obliku originalnu datoteku klijentu u poruci M1 = (originalna datoteka).

2. Po primitku M1 klijent stvara sažetak primljene poruke M1, te generira zahtjev za vremenskom oznakom. Klijent stvoreni zahtjev uključuje u HTTP Post poruku u čije zaglavlje upisuje vrstu i duljinu sadržaja, a u tijelo vrijednost zahtjeva. Klijent šalje poslužitelju poruku: M2 = (HTTP Post).

3. Poslužitelj po primitku M2, ukoliko je slobodan, generira vremensku oznaku, te stvara odgovor sa vremenskom oznakom. Odgovor uključuje u HTTP Ok poruku, u čije tijelo uključuje odgovor sa vremenskom oznakom te šalje klijentu poruku: M3 = (HTTP 200 OK).

4. Po primitku M3 klijent provjerava dobiveni odgovor. Ukoliko odgovor odgovara poslanom zahtjevu, klijent šalje korisniku poruku: M4 = (vremenski potpisana datoteka).

5. Po primitku M4, korisnik sprema vremenski potpisanu datoteku za budude korištenje.

Opisana razmjena HTTP poruka prikazana je slikom 5.7. u koju su uključeni primjeri zaglavlja poruka koje se razmijenjuju.

44

klijent Server

M2 = (POST HTTP/1.1Host: 127.0.0.1:318

Content-Length: 163

Content-Type: application/timestamp-query)

M1 = (originalni dokument)

korisnik

M4 = (dokument s vremenskom

oznakom)

M3 = (HTTP/1.1 200 OKServer: JB TSA Server

Content-Type:

application/timestamp-response

Content-Length: 1836)

Slika 5.7. Primjer razmjene HTTP poruka između klijenta i poslužitelja

Konkretna implementacija navedenih razmjena poruka bit de prikazana kasnije, u opisu korištenja ostvarenog sustava za vremensko označavanje dokumenata (vidjeti poglavlje 5.5).

5.4 Klijent za zahtijevanje izdavanja vremenskih oznaka

Klijent za zahtijevanje izdavanja vremenskih oznaka, slično kao i poslužitelj, ima implementiranu osnovnu funkcionlanost u razredu Client. Ovaj razred omoguduje podešavanje paramatera zahtjeva, kao što su: algoritam sažimanja koji de se koristiti, hode li se koristiti nonce u zahtjevu i koliki de biti, zahtjeva li se certifikat od TSA u odgovoru itd. Inicijalno, postavke se učitavaju iz konfiguracijske datotke (clientProperties.properties), a korisnik može ove postavke promijeniti iz grafičkog sučelja. Podržani algoritmi sažimanja su: SHA-1, SHA-256, SHA-384, SHA-512, te MD5.

Razred Client nasljeđuju 2 razreda: TCPClient i HTTPClient koji se razlikuju u implementaciji metode za slanje vremenske oznake poslužitelju. Naravno, TCPClient implementira tu metodu komunicirajudi sa poslužiteljem putem TCP protokola i uporabom ved opisanih TCPBasedTSAMessage poruka, dok HTTPClient komunicira sa poslužiteljem uporabom HTTP protokola i ved opisanin HTTP zahtjevima.

Podatak koji treba vremenski označiti klijent može zaprimiti na tri načina. Prvi, najčešdi i preporučljivi način uporabe klijenta jest da se vremenski označi neka datoteka. Podržani formati datoteka su tekstualne (*.txt) datoteke, Excel datoteke (*.xls, *.xlsx), te

Word (*.doc) datoteke. Za učitavanje Excel i Word dokumenata koristi se open source paket, Apache POI. Apache POI u trenutku pisanja ovog rada pruža dobru podršku za obradu

45

Excel datoteka, no obrada Word dokumenata još je u eksperimentalnoj fazi razvijanja, pa se može dogoditi poneko neispravno učitavanje *.doc datoteke.

Drugi način zaprimanja podataka jest da klijent zaprimi podatak direktno unosom novog teksta u, za to predviđen obrazac, u grafičkom sučelju. Tredi način je da klijent primi podatak putem web servisa (ovaj način se koristi u sustavu e – trgovine i o tome de biti govora kasnije). Web servis je upotrebljen za komunikaciju između e – trgovine i klijenta da bi se omogudila komunikacija s klijentom bez obzira na tehnologiju u kojoj je rađena e – trgovina, te da se omogudi jednostavan prijenos podataka preko mreže.

Nakon zaprimanja podatka, klijent ovisno o naznačenom algoritmu sažimanja stvara sažetak podatka, te stvara zahtjev za vremenskom oznakom. U zahtjev uključuje obavezna polja, te opcionalna polja sukladno postavkama. Ukoliko je u zahtjevu potrebno koristiti nonce, a on nije eksplicitno zadan, aplikacija de ga izgenerirati slučajno, koristedi Java generator slučajnih brojeva. Nonce je u aplikaciji izveden koristedi razred java.math.BigInteger, s brojem bitova postavljenim na 17. Postavljanjem broja bitova na 17, mogu se izgenerirati brojevi u opsegu 0 – (217 -1), tj. u opsegu [0 – 131071+, pa je pretpostavka da de se, i uz dovoljno velik broj izdanih zahtjeva, svaki izgenerirani broj izgenerirati maksimalno jednom. Ako je zahtjev uspješno kreiran, klijent šalje zahtjev poslužitelju. Vrijeme čekanja na odgovor postavljeno je na 10 sekundi, da bi se smanjio rizik od napada čovjekom u sredini (vidjeti poglavlje 4.9, točka 4). Ukoliko u roku 10 sekundi od slanja zahtjeva ne dobije odgovor, klijent zatvara vezu prema poslužitelju i smatra slanje zahtjeva neuspješnim. Ukoliko dobije odgovor, krede u provjeru odgovora.

Provjera odgovora sastoji se od nekoliko koraka.

1. Najprije se provjerava cjelobrojna vrijednost statusa dobivena u odgovoru. Vrijednost statusa mora biti u okviru dozvoljenih vrijednosti, tj. u skupu { 0, 1, 2, 3, 4, 5}. Ukoliko dobivena vrijednost nije u dozvoljenom okviru, klijent de izbaciti iznimku i odbaciti primljeni odgovor.

2. Ako je dobivena vrijednost statusa u okviru dozvoljenih vrijednosti, provjerava se sadrži li odgovor vremensku oznaku.

3. Ako vremenska oznaka nije prisutna, a status je postavljen na 0 ili 1, klijent de izgenerirati grešku i odbaciti primljeni odgovor. Ako vremenska oznaka nije prisutna, a status je postavljen na odgovarajudu vrijednost (2, 3, 4 ili 5), provjerava se cjelobrojna vrijednost informacije o razlogu izostanka oznake u odgovoru. Ako vrijednost nije u okviru dozvoljenih vrijednosti, tj. u skupu {0, 2, 5, 14, 15, 16, 17, 25}, klijent de izbaciti iznimku i odbaciti primljeni odgovor. Ukoliko je vrijednost u dozvoljenom skupu, klijent de upozoriti korisnika o razlogu odbijanja izdavanja vremenske oznake od strane poslužitelja, te de pokušati poduzeti korake za promjenu svojih postavki, ukoliko je došlo do greške od strane klijenta. Koraci koje klijent poduzima kao pokušaj oporavka od neispravnog rukovanja zahtjevom:

3.1. Ako je kao razlog neizdavanja vremenske oznake naveden badAlg, klijent resetira algoritam sažimanja na SHA-1, uz pretpostavku da je to najčešde korišten, te pouzdan algoritam sažimanja.

46

3.2. Ako je kao razlog neizdavanja vremenske oznake naveden badDataFormat, klijent resetira svoj podrazumijevani način kodiranja na UTF-8.

3.3. Ako je kao razlog neizdavanja vremenske oznake naveden unacceptedPolicy, klijent resetira postavljanje oznake politike u zahtjev na false, tj. ne uključuje oznaku politike u budude zahtjeve.

3.4. Ako je kao razlog neizdavanja vremenske oznake naveden unacceptedExtension, klijent isključuje postavljanje tog proširenja u budude zahtjeve.

3.5. Ako je kao razlog neizdavanja vremenske oznake naveden timeNotAvailable ili systemFailure, došlo je do greške na strani poslužitelja, pa klijent ne čini ništa.

4. Ako je vremenska oznaka uključena u odgovor, klijent provjera polja vremenske oznake, uspoređuje ih s poljima poslanog zahtjeva, te utvrđuje odgovaraju li primljeni podaci poslanima.

4.1. Klijent najprije provjerava zahtjev za cerfikatom od TSA. Ako je zahtjev za certifikatom bio prisutan u zahtjevu za vremenskom oznakom i postavljen na true, certifikat mora biti pristuan u vremenskoj oznaci. Ukoliko zahtjev za certifikatom nije bio prisutan u zahtjevu ili je bio prisutan i postavljen na false, certifikat ne smije biti prisutan u vremenskoj oznaci. U suprotnom, klijent de izbaciti iznimku i odbaciti vremensku oznaku.

4.2. Klijent zatim provjerava sažetak poruke dobiven u vremenskoj oznaci. Provjerava odgovora li naznačeni identifikator algoritma sažimanja onome naznačenome u zahtjevu, te jesu li primljeni i poslani sažetak identični. Ukoliko jedan od ta dva uvjeta nije zadovoljen, klijent de izbaciti iznimku i odbiti vremensku oznaku.

4.3. Klijent provjerava nonce. Ako je nonce bio uključen u zahtjev, on mora biti prisutan i u dobivenoj vremenskoj oznaci, te mora imati istu vrijednost. Ukoliko nije bio uključen u zahtjev, on ne smije biti uključen u odgovor. Pošto klijent nema svoj lokalni sat, preporuča se uporaba nonce-a u zahtjevu, da se zadovolje sigurnosne mjere opisane u poglavlju 4.9, točka 6.

4.4. Klijent provjerava oznaku politike. Ako je oznaka politike bila uključena u zahtjev, ona mora imati istu vrijednost u vremenskoj oznaci. Ukoliko oznaka politike nije bila uključena u zahtjev, u vremenskoj oznaci bi se trebala nalaziti oznaka politike koju je postavio TSA.

5. Naposljetku, ako je u odgovor uključen certifikat od TSA, klijent krede u provjeru certifikata. Kod provjere certfikata provjeravaju se četiri stvari: je li zadana datoteka u formatu X.509 certifikata, je li certifikat vremenski valjan, je li ga izdao CA kojemu se može vjerovati, te postoji li certifikat u listi opozvanih certifikata. Lista opozvanih certifikata se provjera samo ako u certifikatu postoji ekstenzija sa OID-ijem 2.5.29.31, tj. ako je u certifikatu zapisan url za dohvat liste opozvanih certifikata. Listu opozvanih certifikata mogude je dohvatiti preko LDAP protokola, ili HTTP protokola. Preferirani način dohvata je LDAP protokol. Provjera je li certifikat izdan od strane CA kojem se može vjerovati uvelike je pojednostavljena. Provjerava se postoji li u lokalnom spremniku certifikata korijenski certifikat koji je izdavač traženog

47

certifikata. Ukoliko je certifikat pronađen, generira se lanac certifikata od krajnjeg do korijenskog, te je CA označen kao izdavač kojemu se može vjerovati. U praksi je izrada lanca certifikata od krajnjeg do korijenskog jako složen proces, te kompliciran za implementaciju. Pošto se za potrebe diplomskog rada upotrebljava izdavanje certifikata od Bouncy Castle providera, generirani CA certifikat dodaje se u spremnik certifikata, te de svi certifikati potpisani od strane tog CA certifikata biti označeni kao sigurni.

Struktura klijenta prikazana je slikom 5.8. Radi pojednostavljenja dijagrama i bolje preglednosti slike, s dijagrama su izostavljeni getteri i setteri privatnih varijabli razreda.

48

Slika 5.8. Razredi korišteni za ostvarenje klijenta koji zahtijeva izdavanje vremenske oznake

49

5.5 Primjer korištenja sustava za vremensko označavanje dokumenata

Kako je aplikacija za vremensko označavanje dokumenata napravljena u dva logički zasebna dijela (poslužitelj i klijent), koja ostvaruju komunikaciju, preporuča se pokretanje aplikacije sa dva zasebna računala koja međusobno mogu komunicirati preko mreže. Ovo se može ostvariti npr. iz dva virtualna računala.

Prilikom pokretanja aplikacije korisniku se nudi odabir pokretanja ili poslužiteljskog ili klijentskog dijela.

Odabirom pokretanja poslužitelja, pokrede se poslužiteljski prozor. U prvom dijelu prozora odabiru se postavke vezane uz protokol, adresu poslužitelja i korišteni pristup (port). Protokol, kako je ved specificirano, može biti TCP ili HTTP. Za adresu je potrebno upisati IP adressu ili FQDN (Fully Qualified Domain Name) računala na kojem de se izvoditi poslužitelj. Vjerojatno de se najčešde poslužitelj izvoditi na trenutnom računalu, pa je dovoljno upisati trenutnu IP adresu računala, kako je to prikazano slikom 5.9.

Slika 5.9. Pokretanje TCP poslužitelja

Kako RFC 3161 specificira pristup 318 kao preporučeni pristup za TSP protokol, ovaj pristup nije preporučljivo mijenjati. Prilikom pokretanja aplikacije na Linux operacijskom sustavu, za pokretanje poslužitelja na pristupu 318 zahtijevat de se root ovlasti. Ukoliko nije mogude dobiti root ovlasti, mogude je pokrenuti poslužitelj i na nekom drugom pristupu.

Pritiskom na gumb Start, pokrede se poslužitelj, tj. stvara se pristupna točka koji se veže na zadanu IP adresu i pristup. Istovremeno, omogudava se prethodno onemoguden gumb Stop, čija uloga je da zatvori vezu poslužitelja na pristupnu točku.

Pokretanjem poslužitelja, inicijaliziraju se njegove postavke. Postavke se inicijalno učitavaju iz početne konfiguracijske datoteke, ali ju korisnik može promijeniti iz izbornika File > Load Configuration. Također, korisnik može spremiti trenute postavke u konfiguracijsku datoteku, te ju učitati neki od idudih puta pokretanja poslužitelja. Prilikom pokretanja, stvara se X.509

50

certifikat, koji se može vidjeti pritiskom na gumb View TSA's certificate. Kao što je ved napomenuto, certifikat koristi MD5 algoritam sažimanja, uz RSA enkripciju, te ima samo jednu vrijednost proširene uporabe ključa, a to proširenje je označeno kao kritično. Certifikat je prikazan slikom 5.10.

Slika 5.10. X.509 certifikat centra za vremensko izdavanje oznala

U drugom dijelu prozora unose se postavke za uporabu poretka i preciznosti. Ukoliko se koristi preciznost, milisekunde i mikrosekunde moraju biti broj u rangu 1-999, inače de se korisnika upozoriti o grešci. Na sekunde nema ovog ograničenja. Ukoliko je poslužitelj pokrenut, postavke de se spremiti u trenutnu instancu poslužitelja. Ukoliko nije, postavke de se spremiti u konfiguracijsku datoteku, te de se učitati prilikom idudeg pokretanja poslužitelja.

Korisniku je na raspologanju i izbornik Help, u kojem se nudi pomod oko uporabe same aplikacije, opde informacije o vremenskim oznakama, te opde informacije o X.509 certifikatima. Prozor s informacijama o vremenskim oznakama prikazan je slikom 5.11., dok je prozor s informacijama o X.509 certifikatu prikazan slikom 5.12.

51

Slika 5.11. Prozor za pomod s informacijama o vremenskim oznakama

Slika 5.12. Prozor za pomod s informacijama o X.509 certifikatu

52

Pokretanjem poslužitelja, poslužitelj "sluša" na zadanoj adresi i zadanom pristupu, te čeka da se njega spoji klijent, te da počne obrađivati klijentov zahtjev. Pokretanjem poslužitelja otvara se novi prozor u kojem se ispisuju postavke poslužitelja, te sav promet na poslužitelju. U tom prozoru bit de registrirani svi zaprimljeni zahtjevi, te poslani odgovori. Prozor za pradenje prometa na poslužitelju prikazan je slikom 5.13. U gornjem dijelu prozora ispisuju se postavke o poslužitelju – njegova IP adresa i pristup, vrijeme kada je pokrenut, koristi li se preciznost i poredak, te ako se koriste koliko iznose.

Slika 5.13. Prozor za pradenje prometa na poslužitelju

Poslužitelj ne mora samo čekati da se na njega spoji klijent i zatraži izdavanje vremenske oznake, ved je vremensku oznaku mogude generirati i iz prethodno dobivenog zahtjeva za izdavanje vremenske oznake. Ovo je mogude odabirom Make response from request file iz izbornika File. Kod stvaranja odgovora iz datoteke, bitno je da je datoteka u *.tsq formatu, tj. da sadrži samo DER-kodiranu vrijednost zahtjeva za izdavanjem vremenske oznake.

Klijentski dio aplikacije sličan je poslužiteljskom. Odabirom pokretanja klijenta prilikom pokretanja aplikacije otvara se prozor kako je prikazano slikom 5.14.

Da bi se pokrenuo klijent, potrebno je unijeti protokol kojim de klijent komunicirati sa poslužiteljem, te adresu i pristup na kojoj se nalazi poslužitelj. U slučaju da se komunikacija sa poslužiteljem iz nekog razloga ne može ostvariti, korisnika se obavještava o grešci.

53

Slika 5.14. Klijentski dio aplikacije

Ukoliko je komunikacija uspješno ostvarena, otvara se prozor sličan prozoru na slici 5.13. na kojem de se pratiti tijek dolaznih i odlaznih poruka sa klijenta. U gornjem dijelu prozora nalazi se pregled postavki koje de klijent koristiti. Tako je vidljivo na koji poslužitelj se klijent spojio, te koje postavke de koristiti prilikom slanja zahtjeva. Prilikom pokretanja klijenta, učitaju se početne postavke iz konfiguracijske datoteke (clientProperties.properties). Slično kao i kod poslužitelja, korisnik može učitati postavke iz neke druge konfiguracijske datoteke (odabirom iz izbornika File > Load properties), te trenutne postavke može spremiti u novu konfiguracijsku datoteku (odabirom iz izbornika File > Save properties). Pojedinačne postavke mogu se mijenjati iz drugog dijela prozora, kako je prikazano slikom 5.15.

Ovdje korisnik ima mogudnost odabira korištenog algoritma sažimanja, hode li se u zahtjevu postavljati polje zahtjeva za certifikatom od TSA, hode li se koristiti nonce, te koliki de on biti itd. Nonce se automatski izgenerira kako je opisano u prethodnom poglavlju, no korisnik može unijeti vlastiti broj koji želi koristiti. Ukoliko trenutno postoji pokrenuta instanca klijenta, klijent se odmah ažurira na nove postavke. Ukoliko ne postoji, ove postavke de se spremiti u konfiguracijsku datoteku, te de biti korištene idudi put kod pokretanja klijenta. Resetiranjem postavki, postavke se vradaju na vrijednosti koje su zapisane u inicijalnoj konfiguracijskoj datoteci.

54

Slika 5.15. Podešavanje postavki klijenta

Nakon što je klijent pokrenut i postavljen na željene postavke, spreman je za slanje zahtjeva poslužitelju. Datoteka koju je potrebno vremenski označiti učitava se iz izbornika File > Make request from file. Ako je datoteka uspješno učitana, stvara se njezin sažetak, te zahtjev za vremenskom oznakom. Ako je potrebno vremenski označiti samo tekst, a ne gotovu datoteku, tekst se može unijeti direktno u obrazac za unos teksta, odabirom iz izbornika File > Make request from text.

Bez obzira na način unosa podataka, od primljenih podataka izračunava se sažetak ovisno o navedenom algoritmu sažimanja, te se stvara zahtjev za stvaranjem vremenske oznake.

Zahtjev se prikazuje na prozoru za pradenje prometa na klijentu, zajedno s porukom koja de se poslati poslužitelju. Ako je odabrani protokol komunikacije sa poslužiteljem TCP, stvara se TsaMsg, te se ta poruka šalje poslužitelju. Valja napomenuti kako se u TsaMsg uključuje samo DER – kodirana vrijednost zahtjeva, kako je to specificirano RFC-om, te se ona kao takva prenosi između klijenta i poslužitelja, no zbog bolje preglednosti se prije ispisa na ekran ta poruka kodira u Base64 format.

Na poslužiteljskoj strani, u prozoru u kojem se ispisuje promet na poslužitelju zabilježuje se pristigli zahtjev. Poslužitelj, bududi da je slobodan i da je primio valjan zahtjev, stvara vremensku oznaku, te odgovor sa vremenskom oznakom šalje u FinalMsgRep prema klijentu. Prikaz poruka na klijentskoj i poslužiteljskoj strani prikazan je slikama 5.16., te 5.17. Tijek poruka između poslužitelja i klijenta odgovara onome prikazanome na slici 5.5.

Vidljivo je da su vrijednosti polja u zahtjevu za izdavanjem vremenske oznake identična onima u odgovoru sa sadržanom vremenskom oznakom.

55

Klijent prima FinalMsgRep poruku te preuzima iz nje odgovor. Na slici 5.16. vidljivo da je PKIStatusInfo postavljen na vrijednost 0, što znači da je vremenska oznaka sadržana u odgovoru, a to se vidi i iz slike. Iz slike je također vidljivo da polja sadržana u odgovoru odgovaraju onima sadržanima u zahtjevu. Nakon primljenog odgovora klijent krede u provjeru dobivenog odgovora, te provjerava stavke opisane u poglavlju 5.4. Ukoliko je u odgovor uključen certifikat od TSA, klijent završava provjeru odgovora provjeravajudi certifikat od TSA.

Slika 5.16. Promet na klijentskoj strani prilikom razmjene TCP poruka

56

Slika 5.17. Promet na poslužiteljskoj strani prilikom razmjene TCP poruka

Slika 5.18. prikazuje tijek poruka na klijentskoj strani u slučaju da je prilikom primitka prve TsaMsg poruke poslužitelj bio zauzet, te da je odgovorio sa PollRep proukom.

Ovaj slučaj analogan je onome prikazanom na slici 5.6.

57

Slika 5.18 Primjer prometa na klijentu prilikom razmjene TCP poruka

Slično, ukoliko klijent komunicira sa poslužiteljem preko HTTP protokola, on stvara zahtjev za vremenskom oznakom, no ovaj put ga uključuje u HTTP POST zahtjev.

Poslužitelj i ovog puta bilježi pristigli zahtjev, te stvara vremensku oznaku koju šalje u HTTP poruci klijentu. Razmjena poruka između poslužitelja i klijenta prikazana je slikama 5.15. i 5.16. Tijek poruka odgovara onome na slici 5.7.

58

Slika 5.19. Promet na poslužiteljskoj strani prilikom razmjene HTTP poruka

59

Slika 5.20. Promet na klijentskoj strani prilikom razmjene HTTP poruka

Opet, vidljivo je da zahtjev koji klijent šalje odgovara zahtjevu kojeg je poslužitelj primio, te da su polja u zahtjevu identična onima u odgovoru.

Drugi način uporabe HTTPServera jest da se iz web preglednika izravno zatraži datoteka s odgovorom. Datoteka mora postojati na poslužitelju, te ako postoji, korisnik ju može zatražiti preko svog web preglednika, tako da upiše HTTP adresu poslužitelja s imenom tražene datoteke, npr. http://localhost:318/response.tsr.

60

5.6 Primjer korištenja vremenskih oznaka u sustavu e-trgovine

E–trgovina zasnovana je na open source rješenju, Jsp Cart, koje nudi osnovnu funkcionalnost online kupovine [16]. Omoguden je pregled proizvoda neregistriranim korisnicima, te dodavanje proizvoda u košaricu, dok je za kupnju proizvoda potrebno biti registiran i logiran korisnik. Ukoliko korisnik koji nije registiran poželi kupiti neki proizvod, provest de ga se kroz jednostavan proces registracije, u kojem korisnik unosi željeno korisničko ime i lozinku. Neke od funkcionalnosti e-trgovine prikazane su dijagramom toka na slici 5.20.

Ulazna točka

aplikacije

Izbor

Pregled Registracija

obrazac

za

registraciju

provjera prijave

neuspješna

prijava

Kupnja

Prijava

obrazac

za prijavu

provjera prijave

Izbor

Izbor

uspješna prijava

kupnja s

popustom

neuspješna prijavauspješna prijava

uspješna prijava

proces kupnje

kupnja

uspješna

kupnja

neuspješna

izazna točka

aplikacije

po

nazivu

po

nazivu

Izbor

ulaz / izlaz aplikacije

izbor

korisnička stranica

pozadinski proces

LEGENDA

Slika 5.21. Dijagram toka za ostvarenu e – trgovinu

Da bi korisnik mogao pristupiti korištenju kupnje s popustom, mora biti registriran. Forma za registraciju prikazana je slikom 5.22.

61

Slika 5.22. Forma za registraciju u e - trgovini

Ukoliko je registracija uspješna, korisnika se obavještava o uspješnom procesu registracije, te može nastaviti s kupovinom. Ukoliko registracija nije uspješna (npr. željeno korisničko ime ved postoji u bazi), od korisnika se traži da ponovno unese polje koje je izazvalo grešku.

Za potrebe ovog diplomskog rada, ova e- trgovina je prilagođena tako da podrži uporabu vremenskih oznaka u procesu kupnje. Registriranim korisnicima nudi se mogudnost kupnje s popustom. E-trgovina iz predloška ugovora stvara ugovor u koji dodaje korisničko ime trenutno registriranog korisnika, čime osigurava da de sažetak ugovora biti jedinstven za svakog korisnika. Nakon stvaranja ugovora, slijede koraci:

1. Bellevue Shop šalje korisniku ugovor i nudi mu da prihvati uvjete ugovora. Ponuđeni ugovor prikazan je slikom 5.23.

62

Slika 5.23. Ponuđeni ugovor za omogudavanje kupnje s popustom

2. Korisnik prihvada uvjete ugovora. 3. Bellevue Shop pomodu web servisa šalje ugovor klijentu koji traži izdavanje

vremenske oznake. Bellevue Shop ima unaprijed zadanu web adresu i pristup na kojem se nalazi web servis klijenta.

4. Klijent po primitku ugovora sastavlja njegov sažetak, te šalje poslužitelju za izdavanje vremenskih oznaka da vremenski označi taj ugovor, kako je opisano u prethodnom poglavlju.

5. Ako poslužitelj uspješno izda vremensku oznaku, šalje klijentu odgovor s vremenskom oznakom.

6. Klijent po primitku odgovora od poslužitelja provjerava je li vremenska oznaka valjana te ako jest, kao povratnu vrijednost metode web servisa, vrada e–trgovini

63

izgeneriranu vremensku oznaku. U suprotnom, izbacit de iznimku ili vratiti NULL vrijednost, pa de e-trgovina po primitku iznimke ili null vrijednosti znati da je nastupila greška prilikom vremenskog potpisivanja dokumenta. U slučaju da je nastupila greška, korisnika se obavještava o grešci, te ga se moli da pokuša ponovno.

7. Ukoliko Bellevue Shop dobije valjan odgovor od klijenta, u bazu sprema uz ID korisnika original ugovora, te vremenski potpisan ugovor.

8. Bellevue Shop šalje korisniku vremenski potpisan ugovor. 9. Korisnik sprema vremenski potpisan ugovor.

Opisani tijek razmjene poruka prikazan je slikom 5.24.

korisnik

originalni ugovor

baza

klijent

TSA

zahtjev za izdavanje vremenske oznake

odgovor s vremenskom oznakom

originalni ugovor

vremenski

potpisan

ugovor

originalni ugovor

originalni

ugovor

vremenski

potpisan

ugovor

vremenski

potpisan

ugovor

Bellevue Shop1.

6.

3.

2.

5.

4.

7.

8.vremenski

potpisan

ugovor

9.

User ID

5.24. Tijek razmjene poruka u sustavu e-trgovine

Jednom kada je korisnik dobio vremenski potpisani ugovor, on uz cijene svih proizvoda vidi cijenu s navedenim popustom (25% popusta). Korisnik može dodavati proizvode u svoju košaricu, te de mu se ukupna cijena prikazivati kao zbroj svih cijena s popustom. Prije same kupnje, korisnik mora unijeti svoj ugovor. Nakon unosa ugovora, trgovina provjerava odgovara li uneseni ugovor s onim pohranjenim u bazu, te ukoliko odgovara, dozvoljava korisniku kupovinu navedenih proizvoda.

Nakon obavljene kupovine, korisnik može nastaviti s pregledom proizvoda, kupiti nove proizvode, ili otidi sa stranice. Prilikom svake idude kupovine, ukoliko želi kupovinu s popustom, korisnik de morati unijeti isti ugovor. Ovim postupkom osigurava se da se ugovor od trenutka kada je prvi put prikazan korisniku do trenutka kupovine nije mijenjao.

64

6. Zaključak

U radu je prikazan sustava za pouzdano vremensko označavanje dokumenata u sustavu javnih ključeva koji osigurava tajnost komunikacije, autentifikaciju korisnika i digitalno potpisivanje dokumenata. Cilj je bio predstaviti uporabu vremenskog označavanja dokumenata u stvarnom sustavu, te je za takav sustav odabrana jednostavna e – trgovina.

U ostvarenom sustavu za vremensko označavanje dokumenata implementirani su centar za izdavanje vremenskih oznaka, te klijent koji traži izdavanje vremenskih oznaka i vrši njihovu provjeru. Klijent i centar za izdavanje vremenskih oznaka međusobno komuniciraju ili putem TCP ili putem HTTP protokola i pritom izmjenjuju poruke specifične za pojedini protokol.

Centar za izdavanje vremenskih oznaka svaku vremensku oznaku potpisuje svojim privatnim ključem, koji odgovara javnom ključu na njegovom X.509 certifikatu. Klijent u sklopu provjere vremenske oznake provjerava i ispravnost certifikata centra za izdavanje vremenskih oznaka, te je za tu potrebu implementiran i algoritam provjere X.509 certifikata.

Za ostvarenje sustava korištene su programske tehnologije i alati koje olakšavaju izvedbu kriptografskih i sigurnosnih funkcija ili imaju ugrađenu podršku za njih u svojim standardnim programskim paketima, što osigurava lakšu kontrolu, administriranje, izmjene i nadgradnju sustava. U ostvarenom sustavu još ima mjesta za poboljšanja i proširenja. U bududim proširenja sustava tako bi trebalo dodati generiranje liste opozvanih certifikata i objavljivanje te liste. Klijentski dio sustava zatim bi trebao provjeriti certifikat i u listi opozvanih certifikata prije nego li ga prihvati kao valjanog.

65

7. Literatura

[1] World Internet Usage Statistics News and Population Stats, dostupno na Internet adresi: http://www.internetworldstats.com/stats.htm

[2] Franjo Rebac: Infrastruktura javnog ključa, seminarski rad, dostupno na Internet adresi: http://os2.zemris.fer.hr/pki/2005_rebac/index.html

[3] Zakon o elektroničkom potpisu Republike Hrvatske, dostupno na Internet adresi: http://narodne-novine.nn.hr/clanci/sluzbeni/308001.html

[4] Literatura za predmet Ergonomija na Fakultetu elektrotehnike i računarstva, dostupno na Internet adresi: http://web.zpr.fer.hr/ergonomija/2004/guzvinec/ElSig.html

[5] Sunove stranice o X509 certifikatima, dostupno na Internet adresi: http://java.sun.com/j2se/1.3/docs/guide/security/cert3.html

[6] Leo Budin, Marin Golub: Predavanja iz predmeta Operacijski sustavi 2, Zagreb, 2007.

[7] FINA DEMO PKI, dostupno na Internet adresi: http://demo-pki.fina.hr

[8] RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, dostupno na Internet adresi: http://www.ietf.org/rfc/rfc3280.txt

[9] RFC 2459, Internet X.509 Public Key Infrastructure Certificate and Internet Protocol, dostupno na Internet adresi: http://tools.ietf.org/html/rfc2459

[10] Wikipedia o vremenskim oznakama, dostupno na Internet adresi: http://en.wikipedia.org/wiki/Trusted_timestamping

[11] RFC 3161, Internet X.509 Public Key Infrastructure and Time – Stamp Protocol, dostupno na Internet adresi: http://www.ietf.org/rfc/rfc3161.txt

[12] Apache POI, Java API za Microsoft Office dokumente, dostupno na Internet adresi: http://poi.apache.org/

[13] Bouncy Castle, open source kriptografski paket implementiran u Javi, dostupno na Internet adresi: http://www.bouncycastle.org/

[14] Java SWT, skup alata za izradu grafičkog korisničkog sučelja, dostupno na Internet adresi: http://www.eclipse.org/swt/

[15] MySql, open source baza, dostupno na Internet adresi: http://www.mysql.com

[16] JspCart, open source implementacija e-trgovine, dostupno na Internet adresi: http://www.neurospeech.com/Products/JspCart.html