1. Uvod

Elektronički novac, odnosno elektronička gotovina[1], jedan je od načina ostvarivanja elektroničkog oblika plaćanja. Razvoj elektroničkog novca potaknut je širenjem Interneta, medija kojim se se obavlja sve veći broj transakcija uz neizbježnu komunikaciju i poslovanje ljudi širom svijeta. Da bi se takve transakcije što jednostavnije, uz što manje troškova i u što kraćem vremenu obavljale, razvijeni su različiti oblici elektroničkog plaćanja.

Protok elektroničke informacije, kao što je elektronički novac, između dviju strana koje komuniciraju putem Interneta, omogućuje njeno nesmetano promatranje i eventualnu zlouporabu od treće strane. Da bi se takve neželjene aktivnosti neutralizirale ili sprječile, koristi se zaštita kriptiranjem te provjera autentičnosti sudionika u transakciji. Podloga takvim postupcima su različiti kriptografski algoritmi i mehanizmi te dodatno razvijeni protokoli više razine koji osiguravaju zaštitu elektroničke informacije kao i privatnost sudionika transakcije. Upravo su privatnost i autentičnost bitne osobine potencijalnog sustava elektroničkog plaćanja.

Ovaj diplomski rad predstavlja i analizira jedan od protokola plaćanja elektroničkim novcem koji je dalje osnovica za izradu sustava elektroničkog plaćanja. Također, u radu je detaljno razrađena enkapsulacija spomenutog protokola unutar kriptografske zaštite što je posljednji korak do implementacije istog tog protokola u sustav plaćanja elektroničkim novcem. Na taj je način rješena problematika vezana uz zaštitu protoka elektroničkog novca unutar sustava elektroničkog plaćanja. Time je ovaj diplomski rad napravljen kao nastavak rada ostvarenog u seminarskom radu u kojemu su opisani spomenuti protokol plaćanja elektroničkim novcem te osnove kriptografskih mehanizama. Kao dio diplomskog rada izrađena je simulacija postupka plaćanja elektroničkim novcem putem Interneta, odnosno preko WWW stranica. Od četiri modula od kojih se sustav sastoji, trgovca, kupca, banke i autentifikacijskog poslužitelja, modul trgovca je implementiran kao dio pravog sustava plaćanja elektroničkim novcem, dok se ostali moduli simuliraju tako da se ostvari čim veća funkcionalnost i neovisnost modula trgovca. Cijeli postupak plaćanja elektroničkim novcem može se promatrati preko Interneta na odgovarajućoj WWW stranici.

2. Kriptografski algoritmi i protokoli

2.1 Uvodno razmatranje

Radi što bolje analize problema zaštite postupka plaćanja elektroničkim novcem, na početku je potrebno prikazati osnovne koraka tog postupka.

U svakom obliku protokola plaćanja elektroničkim novcem javljaju se tri sudionika: kupac[2] , trgovac[3] i banka. Komunikacija je uspostavljena između sva tri sudionika, pri čemu su, za sada, bitna tri osnovna osnovna koraka protokola, dok će se u jednom od poglavlja diplomskog rada detaljno analizirati odabrani protokol. Slika 2.1 ilustrira spomenuta tri osnovna koraka.

1. podizanje novca iz banke (od strane kupca)

2. plaćanje (kupac plaća trgovcu)

3. depozit primljenog novca u banku (od strane trgovca)

S obzirom da se sva tri opisana koraka odvijaju putem Interneta, nazire se da takav nezaštićen oblik komunikacije nije siguran niti za jednog od sudionika transakcije. To znači da poruka, elektronička novčanica koja, na primjer, u 2. koraku putuje od kupca prema trgovcu, nije sigurna da će stići na odredište u izvornom obliku, da će uopće stići na odredište, da će biti neovlašteno kopirana, odnosno da će 2 korak biti simuliran od lažnog kupca, dakle nije sigurno da će odredište primiti važeću ili izmišljenu poruku. Isti zaključak vrijedi za svaki pojedini korak protokola plaćanja elektroničkim novcem bez obzira radi li se o tri osnovna koraka ili više njih u kasnije opisanom protokolu.

Dakle općenito javlja se problem zaštite elektroničke informacije koja putuje Internetom od zlouporabe treće strane[4] te autentičnosti informacije koja dolazi na odredište. S odgovarajućom kriptografskom zaštitom, željena funkcionalnost protokola plaćanja elektroničkim novcem nije upitna. U tu svrhu, koriste se asimetrični, simetrični i hash kriptografski algoritmi te protokol za utvrđivanje autentičnosti sudionika transakcije. U ovom diplomskom radu kao asimetrični kriptografski algoritam koristi se RSA algoritam, kao simetrični kriptoalgoritam odabran je DES te se kao hash algoritam koristi MD5. Autentifikacija korisnika ostvarena je protokolom za utvrđivanje autentičnosti zasnovanom na asimetričnom kriptosustavu. Spomenuti kriptografski mehanizmi bit će opisani u sljedećim poglavljima.

2.2 RSA

RSA[5] kriptografski algoritam spada u skupinu asimetričnih kriptoalgoritama. To znači da se u komunikaciji kriptiranim porukama koriste dva različita ključa. Jednim ključem se poruka kriptira dok se drugim dekriptira i obrnuto. Jedan ključ je uvijek javni ključ te je dostupan svima. Drugi ključ je tajni i posjeduje ga samo jedna strana u komunikaciji, odnosno samo jedna osoba. Dodatna osobina ovakvog kriptosustava je da se iz jednog ključa ne može, u praksi, generirati drugi ključ. Dakle poznavanjem javnog ključa ne može se direktno generirati tajni ključ. Druga pozitivna osobina asimetričnog sustava je da se iz kriptirane poruke ne može, u praksi, izvesti izvorna poruka. Jedna, možda manje popularna osobina je brzina kriptiranja/dekriptiranja koja je za par redova veličina manja u odnosu na simetrične kriptosustave. S druge strane, distribucija javnih ključeva je uvelike pojednostavljena u odnosu na distribuciju simetričnih ključeva. Slika 2.2 prikazuje princip na kojem radi asimetrični kriptosustav kao što je RSA.

Sigurnost RSA algoritma zasniva se na problemu faktoriziranja velikih brojeva. Javni i tajni ključ su funkcije dva velika prim broja. Upravo je zato težina generiranja izvorne poruke na temelju javnog ključa i kriptirane poruke jednaka težini faktoriziranja umnoška dvaju prim brojeva. To znači da je gotovo nemoguće, bar ne u razumnom vremenu, otkriti tajni ključ metodom pokušaja i pogrešaka.

Postupak generiranja javnog i tajnog ključa je sljedeći:

1. Odabiru se dva velika prim broja p i q (više od 100 znamenaka svaki)

2. Računa se broj n:

n=pq

(2.1)

3. Odabire se slučajni broj e koji je relativno prost u odnosu na (p-1)(q-1)

4. Izračunava se broj d:

ed=1 mod ((p-1)(q-1))

(2.2)

odnosno

d=e^-1 mod((p-1)(q-1))

(2.3)

5. Par (e,n) predstavlja javni ključ, (d,n) predstavlja tajni ključ

Brojevi p i q više nisu potrebni, ali je bitno da i dalje ostanu tajni jer se na njima temelji tajni ključ d.

Postupak kriptiranja obavlja se tako da se izvorna poruka kodiranjem podijeli na cijele brojeve m_i Î [0, n-1]. Pojedini broj m_i kriptira se formulom 2.4:

ci=mi^e mod n

(2.4)

Da bi dekriptirali poruku c_i koristi se formula 2.5:

mi=ci^d mod n

(2.5)

Iz teorije brojeva poznato je da vrijedi:

ci^d=(mi^e)^d=mi^ed=mi^k^(p-1)(q-1)+1=mimi^k^(p-1)(q-1)omi (mod n)

(2.6)

2.3 DES

Najpoznatiji kriptosustav s tajnim ključem, odnosno simetrični kriptosustav je DES[6]. Simetrični kriptosustavi temelje se na jednom tajnom simetričnom ključu. Obje strane u komunikaciji posjeduju jedan te isti ključ kojim se poruke kriptiraju, odnosno dekriptiraju, stoga nastoje ga zadržati u tajnosti. Kao što je već spomenuto, simetrični kriptoalgoritmi su brži od asimetričnih za par redova veličina, ovisno o pojedinom kriptoalgoritmu. Manje privlačna osobina simetričnih kriptosustava je razdioba ključeva. S obzirom da je jedan ključ, obje strane u komunikaciji trebaju isti ključ. Pošto se istovremeno radi o tajnom ključu čija se tajnost nastoji zadržati, distribucija ključa od jedne strane prema drugoj je kompliciranija nego kod asimetričnih kriptoalgoritama. Problem se obično rješava tako da se u kriptiranoj komunikaciji dviju strana kombinirano koriste asimetrični i simetrični kriptosustav. U tom slučaju asimetrični kriptosustav koristi se za kriptiranje tajnog ključa simetričnog kriptosustava koji se potom koristi u daljnjoj kriptiranoj komunikaciji. Detaljniji opis i primjena ovakve kombinacije bit će opisani u jednom od sljedećih poglavlja.

Na slici 2.3 možemo vidjeti način na koji funkcionira kriptiranje kriptosustavom temeljenom na tajnom ključu ili simetričnom kriptosustavu.

DES algoritam temelji se na operaciji isključivo ili koja je simetrična. Sljedeće dvije formule ilustriraju kriptiranje odnosno dekriptiranje DES-om na temelju spomenute operacije. Pretpostavimo da je m poruka koja se kriptira te da je k simetrični ključ kojim se kriptira.

c=m A k	(2.7)
m=c A k=( m A k) A k	(2.8)

Efektivna duljina ključa DES kriptoalgoritma je 56 bita. S obzirom da se na svakih sedam bita ključa uzima po jedan paritetni bit, kao konačna duljina ključa uzima se 64 bita. Stoga je potrebno poruku koja se kriptira raspodijeliti na blokove od po 64 bita duljine.

Algoritam se sastoji od dvije permutacije i 16 iteracija koje se ponavljaju. Za svaku iteraciju se generira 48 bitni ključ Ki na temelju zadanog 64 bitnog ključa. Na početku se obavlja početna permutacija IP. Rezultat permutacije se podijeli na dvije jednake polovice, lijevu L₀ i desnu R₀, svaku po 32 bita. M predstavlja 64 bitni blok izvorne poruke.

L0R0=IP(M)

(2.9)

Nakon toga se obavlja 16 koraka pri čemu za i=1,…,16 vrijedi:

Li=Ri-1	(2.10)
Ri=Li-1 A f(Ri-1, Ki)	(2.11)

L_i predstavlja lijevu polovicu, dok R_i predstavlja desnu polovicu poruke koja se kriptira u i-tom koraku. K_i je ključ za i-ti korak algoritma. Nakon 16 spomenutih koraka obavlja se permutacija inverzna početnoj, IP^-1, nad zamijenjenim polovicama L₁₆ i R₁₆:

C=IP^-1(R16L16)

(2.12)

Pojedini ključ K_i generira se na sljedeći način. Prvo se iz zadanog 64 bitnog ključa, pomoću tablice permutacije, generiraju dva bloka po 28 bita. Nakon toga slijedi 16 koraka u kojima se svaki blok rotira u lijevo za broj bita ovisno o kojem se koraku radi. Potom se, u pojedinom koraku, pomoću permutacijske tablice generira ključ K_i iz dva 28 bitna bloka koji su prethodno lijevo rotirani.

Najbitniji dio algoritma je funkcija f. Njena kompleksnost jamči dugogodišnju sigurnost DES algoritma od provaljivanja. Ulazni argument funkcije R_i-1 se proširuje pomoću zadane tablice na 48 bita. Obavlja se operacija isključivo ili između dobivenih 48 bita i odgovarajućeg ključa K_i. Rezultat operacije se dijeli na osam dijelova po šest bita. Prvi i zadnji bit pojedinog dijela predstavljaju adresu retka, dok srednja četiri bita predstavljaju adresu stupca u tablici selekcije. Za svaki od osam spomenutih dijelova 48 bitnog bloka uzima se po 4 bita iz tablice selekcije na temelju izračunatih adresa. Dobivenih 32 bita još se permutira zadanom tablicom te se kao rezultat dobiva povratna vrijednost funkcije f.

S obzirom na operaciju isključivo ili i formule 2.7 i 2.8, postupak dekriptiranja obavlja se obrnutim redoslijedom. To se postiže tako da se u i-toj iteraciji umjesto ključa K_i uporabi ključ K_16-i+1.

2.4 MD5

MD5[7] kriptografski algoritam spada u hash algoritme. Osnova hash algoritama su tzv. jednosmjerne funkcije čiji inverz je nemoguće ili gotovo nemoguće izračunati. To znači da je podatke kriptirane hash algoritmom nemoguće dekriptirati. Upravo iz tog razloga, bit hash algoritma je u uspoređivanju rezultata kriptiranja, a ne u njihovoj dekripciji. Rezultat određenog hash algoritma je niz uvijek jednake duljine, bez obzira na duljinu izvorne poruke. Taj niz zove se sažetak[8].

Ilustracija uporabe hash algoritma je u utvrđivanju autentičnosti poruke koja se razmjenjuje između dvije strane u komunikaciji. Ako se želi utvrditi autentičnost izvorne poruke, strana koja šalje poruku šalje i sažetak poruke. Druga strana koja prima poruku, propušta dobivenu poruku kroz isti hash algoritam koji je koristila prva strana i uspoređuje dobiveni sažetak s onim kojeg je primila. Jednakost sažetaka jamči vjerodostojnost primljene poruke.

MD5 hash algoritam zapravo je poboljšana verzija MD4 algoritma. Duljina sažetka kojeg proizvodi MD5 je 128 bita. Poruka koja će se kriptirati proširuje se, po potrebi, tako da njena duljina bude cjelobrojni višekratnik broja 512. Dakle proširena poruka će se sastojati od jednog ili više blokova po 512 bita. Proširivanje se tako obavlja da se ne bi dogodilo da dvije različite izvorne poruke izgledaju jednako nakon proširivanja. Nakon toga, inicijaliziraju se četiri varijable, A, B, C, D, na sljedeće vrijednosti:

A=0123456716	(2.13)
B=89ABCDEF16	(2.14)
C=FEDCBA9816	(2.15)
D=7654321016	(2.16)

Spomenute varijable zovu se ulančane varijable[9]. Potom počinje izvršavanje glavne petlje koja se ponavlja toliko puta koliko je 512-bitnih blokova proširene poruke. Četiri ulančane varijable kopiraju se u privremene varijable:

a=A	(2.17)
b=B	(2.18)
c=C	(2.19)
d=D	(2.20)

Glavna petlja sastoji se od četiri slične iteracije. Svaka iteracija koristi drugačiju operaciju 16 puta. Kao primjer jedne takve operacije koristi se operacija sa slike 2.4. Pojedina od četiri operacije izvodi nelineranu funkciju od tri varijable. Vrijednosti koje se uvrštavaju u nelinearnu funkciju su iznosi privremenih varijabli a, b, c ili d. Nelinerane funkcije, za svaku iteraciju, predstavljene su jednadžbama 2.21 do 2.24.

F(X,Y,Z)=(X U Y) Ú ((OX) U Z)	(2.21)
G(X,Y,Z)=(X U Z) Ú (Y U (OZ))	(2.22)
H(X,Y,Z)=X A Y A Z	(2.23)
I(X,Y,Z)=Y A (X Ú (OZ))	(2.24)

Nakon što je obavljena nelinearna funkcija na tri od četiri ulančane varijable, na rezultat se dodaje vrijednost preostale četvrte varijable, dio 512-bitnog bloka poruke M_j i unaprijed određena konstanta t_i. Dobiveni rezultat se posmiče u desno za varijabilni broj bitova te mu se potom dodaje vrijednost jedne od a, b, c ili d. Tako dobiveni rezultat sprema se u jednu od privremenih varijabli a, b, c ili d. Postupak se za pojedinu iteraciju ponavlja 16 puta. Nakon što su obavljene sve četiri iteracije, vrijednosti a, b, c i d dodaju se varijablama A, B, C i D, respektivno.

Ako se proširena poruka sastoji od više od jednog 512-bitnog bloka, algoritam se ponavlja za preostali broj blokova proširene poruke, koristeći pritom vrijednosti varijabli A, B, C i D svaki put iz prethodnog koraka u tekućem koraku. Sažetak se dobiva slaganjem varijabli A, B, C i D jedne za drugom.

2.5 Digitalni potpis

Nakon što su opisani glavni kriptografski algoritmi i njihovi odabrani predstavnici, slijedi opis jednog od mogućih oblika digitalnog potpisa.

Digitalni potpis u svijetu računala i elektroničkih informacija predstavlja potpis analogan vlastoručnom potpisu u svakidašnjem svijetu. Osoba koja ostavlja digitalni potpis na nekoj elektroničkoj informaciji potvrđuje njenu ispravnost, integritet i autentičnost gledano od strane iste te osobe. Da bi određeni digitalni potpis bio vjerodostojan, mora biti ostvariv od strane samo jedne osobe. Dakle mora identificirati tu osobu kao osobu za koju se predstavlja. Takve osobine digitalnog potpisa moguće je ostvariti s jednim ili više kriptoalgoritama, stoga je digitalni potpis kriptosustav više razine ili unija kriptoalgoritama.

Kao što je već spomenuto, digitalni potpis moguće je ostvariti na više načina. U ovom diplomskom radu bit će opisan najčešći oblik digitalnog potpisa. Temelji se na hash algoritmu u kombinaciji s kriptiranjem asimetričnim kriptosustavom.

Opis digitalnog potpisa ilustriran je na slici 2.5 gdje se kao hash algoritam uzima MD5, a za asimetrični kriptosustav uzima se RSA. Komunikacija se obavlja između osobe A i osobe B. S_A predstavlja tajni, dok P_A predstavlja javni ključ osobe A. Na slici je prikazan samo potpis i njegova provjera, dok je ostatak komunikacije trenutno nebitan. Za elektroničku informaciju uzet je elektronički novac.

Osoba A koja potpisuje elektroničku novčanicu obavlja hash funkciju nad elektroničkom novčanicom te dobiva njen sažetak. Taj sažetak kriptira svojim tajnim ključem RSA kriptoalgoritma. Rezultat kriptiranja je digitalni potpis elektroničke novčanice. Prilikom slanja elektroničke novčanice, osoba A prilaže i digitalni potpis. Nakon što osoba B dođe do elektroničke novčanice i njenog potpisa, dakle do potpisane elektroničke novčanice, ona odvaja digitalni potpis od elektroničke novčanice te ga dekriptira javnim ključem osobe A. Potom obavlja istu onu hash funkciju na odvojenom elektroničkom novčanicom koju je obavila osoba A. Dobiveni sažetak uspoređuje se s dekriptiranim digitalnim potpisom. Ako su sažeci jednaki, utvrđena je autentičnost i ostale osobine koje ima digitalni potpis. U slučaju da se sažeci razlikuju, moguće je da je potpisana elektronička novčanica promijenjena na putu od osobe A do osobe B ili moguće je da elektronička novčanica nije potpisana od strane osobe A, dakle osobe od koje se to očekuje, već od neke druge osobe.

Potpisana elektronička informacija može se zaštititi dodatnim kriptiranjem simetričnim ili asimetričnim kriptoalgoritmom, ali o tome će biti riječi u jednom od sljedećih poglavlja.

Digitalni potpis moguće je ostvariti kriptiranjem elektroničke informacije asimetričnim kriptosustavom, pri čemu rezultat kriptiranja predstavlja potpisanu elektroničku informaciju. Na taj način dobiva se, relativno jednostavnim postupkom, potpisana i zaštićena elektronička informacija, ali je vrijeme kriptiranja i dekriptiranja duže nego u prethodnom slučaju. Ovakav oblik digitalnog potpisa manje je popularan, ali je nezaobilazan u nekim kriptografskim mehanizmima.

2.6 Autentifikacijski protokol

Da bi protokol elektroničkog plaćanja mogao u potpunosti funkcionirati uz navedene kriptografske algoritme koji štite samu informaciju od neželjenog promatranja i korigiranja, u njega se ugrađuje postupak utvrđivanja autentičnosti, odnosno autentifikacijski protokol. Utvrđivanje autentičnosti uključuje identifikaciju i verifikaciju. Postupkom identifikacije osoba najavljuje svoj identitet, dakle predstavlja se. Verifikacijom se obavlja provjera objavljenog identiteta, odnosno utvrđuje se da li je predstavljena osoba zbilja osoba za koju se predstavlja. Konkretna uporaba ovog protokola, kao i već navedenih kriptografskih algoritama, bit će opisana u jednom od sljedećih poglavlja.

Postoje tri osnovna načina na koji se može provjeriti identitet osobe. Prvi postupak temelji se na identifikatoru i šifri osobe koja se identificira. Drugi predstavlja provjeru identiteta jednog sudionika u komunikaciji od strane drugog. Treći način provjere identiteta predstavlja obostrano utvrđivanje autentičnosti oba sudionika u komunikaciji. Radi potreba protokola plaćanja elektroničkim novcem, u ovom će poglavlju biti opisan postupak jednostranog utvrđivanja autentičnosti.

Sljedeći autentifikacijski protokol zasniva se na asimetričnom kriptosustavu. Prilikom utvrđivanja identiteta, koristit će se centralizirani autentifikacijski server. Opis postupka autentifikacije može se pratiti na primjeru sa slike 2.6.

AS predstavlja autentifikacijski server. Tajni ključ AS-a je S_S dok je javni ključ P_S. Osoba A se identificira osobi B. Odgovarajući ključevi osobe A, po analogiji značenja ključeva AS-a, su S_A i P_A. Ključevi osobe B su S_B i P_B, dok R_B predstavlja zahtjev za odgovarajućim javnim ključem koji se upućuje AS-u od strane osobe B.

1. korak: osoba A šalje identifikator a₁ osobi B

a1=IDA

(2.25)

2. korak: osoba B prima a₁, generira slučajni broj N_r te šalje poruku a₂ osobi A

a2=Nr

(2.26)

3. korak: osoba A prima a₂, kriptira N_r sa S_A te šalje a₃ osobi B

a3=E(Nr, SA)

(2.27)

4. korak: osoba B prima a₃, oblikuje a₄ i šalje ga AS-u

a4=(RB, IDA)

(2.28)

5. korak: AS prima a₄, na temelju ID_A pronalazi P_A, oblikuje kriptiranu poruku a₅ te ju šalje osobi B

a5=E((IDA, PA), SS)

(2.29)

6. korak: osoba B prima a₅, dekriptira a₅ s P_S i dobiva ID_A i P_A, dekriptira a₃ s primljenim P_A i dobiva N_r, uspoređuje dobiveni N_r s izvornim N_r te prihvaća komunikaciju u slučaju da su oba N_r jednaka, odnosno odbija u suprotnom

Iz opisanih koraka vidi se da ako se osoba A krivo predstavi te pošalje N_r kriptiran sa svojim S_A, onda će osoba B dobiti javni ključ neke druge osobe te će dekriptiranje a₃ biti neuspješno. U tom slučaju komunikacija se prekida. Slično vrijedi ako se osoba A predstavi s nepostojećim identifikatorom ID_A, pri čemu osoba B neće niti pokušati dekriptirati a₃ jer će dobiti negativan odgovor od AS-a.

2.7 SSL protokol

2.7.1 Općenito o SSL protokolu

Da bi Internet komunikacija između dvije strane bila sigurna, odnosno zaštićena od neželjenih pogleda i djelovanja, formiran je protokol koji se brine da upravo spomenute negativne osobine Interneta budu neutralizirane. SSL[10] i zaštita koju donosi njegova implementacija može se primjenjivati bilo u korisničkim aplikacijama u svrhu prijenosa osjetljivih informacija preko Interneta, bilo u sigurnim transakcijama preko WWW-a. Konkretno, radi se o prijenosu brojeva kreditnih kartica, elektroničkog novaca, dakle općenito elektroničko plaćanje, e-mail poruka, privatnih informacija, izvještaja itd. Da bi SSL bio uporabljiv, potrebno je da obje strane u komunikaciji podržavaju protokol.

SSL predstavlja dodatan viši sloj zaštite koji se prislanja na postojeće komunikacijske Internet protokole. Iz skraćenice na engleskom jeziku vidi se da SSL osigurava sigurni komunikacijski sloj korištenjem utičnica[11]. SSL je ujedino protokol jer se sastoji od niza određenih pravila i postupaka kojima se ostvaruju željene osobine. Što se zapravo događa s porukom koja prolazi kroz SSL? Prvo, poruka se prije slanja kriptira. Nakon što je druga strana primila takvu poruku, ona ju dekriptira te provjerava pošiljaoca i izvornost poruke. U grubo opisanom protokolu naziru se sljedeće osobine: privatnost, autentičnost i integritet poruke. U poglavlju 2.7.3 bit će opisane spomenute osobine protokola.

2.7.2 Princip rada

Glavana i primarna primjena SSL-a je zaštita web komunikacija. Takvoj namjeni je prilagođeno funkcioniranje protokola, uz napomenu da to nije jedina primjena protokola, kao što je to već spomenuto u prethodnom poglavlju. Stoga sljedeći opis principa rada protokola koji se odnosi na web komunikaciju, može se primijeniti na drugom mjestu implementacije SSL-a.

Dvije strane u komunikaciji su web pretraživač i poslužitelj. Obje strane trebaju podržavati SSL protokol. To se ostvaruje tako da obje strane posjeduju certifikate. Certifikat je skupina bitnih informacija koje identificiraju pretraživača (ili korisnika) i poslužitelja. Kao takav, sastoji se od, na primjer, imena organizacije koja izdaje certifikat, imena organizacije ili korisnika kojemu se izdaje certifikat, e-mail adrese organizacije ili korisnika, zemlje porijekla organizacije, odnosno korisnika, javnog ključa organizacije ili korisnika te ostalih bitnih informacija koje identificiraju stranu kojoj se izdaje certifikat. Certifikat se izdaje od strane pouzdanog Certifikat Autoriteta[12]. Od takvog CA korisniku se izdaje certifikat[13] koji se pohranjuje u lokalni web pretraživač. Strani poslužitelja također se izdaje certifikat[14]. Način na koji se izdaje pojedini certifikat ovisi o CA i njegovim postupcima utvrđivanja identiteta onoga kome se izdaje certifikat. Kada obje strane posjeduju potrebne certifikate, može se uspostaviti sigurna komunikacija između korisničkog web pretraživača i web stranica na sigurnom poslužitelju.

2.7.3 Opis SSL protokola

Privatnost poruke koja se šalje preko SSL protokola ostvaruje se njenim kriptiranjem pri čemu treća strana ne može pročitati izvornu poruku. Kriptiranje koje se javlja u SSL-u može se podijeliti na dva dijela. U prvom dijelu, nakon što je sigurna komunikacija pokrenuta, korisnički web pretraživač generira jedinstveni simetrični ključ za komunikaciju sa sigurnim poslužiteljem. Potom kriptira jedinstveni simetrični ključ s javnim ključem sigurnog poslužitelja. Tako kriptiran ključ šalje se sigurnom poslužitelju koji ga po primitku dekriptira sa svojim tajnim ključem. Opisani postupak može se predočiti slikom 2.2 pri čemu je tajna poruka na slici zapravo jedinstveni simetrični ključ. Time je završilo kriptiranje i dekriptiranje asimetričnim kriptosustavom. Za daljnju razmjenu informacija, korisnički web pretraživač i sigurni poslužitelj koriste jedinstveni simetrični ključ. To predstavlja drugi dio kriptiranja odnosno dekriptiranja pri čemu se koristi simetrični kriptosustav. Slika 2.3 ilustrira spomenutu komunikaciju.

Takav način kriptiranja poruka između strana u sigurnoj komunikaciji odabran je zbog osobina korištenih kriptosustava. Već je spomenuta prednost simetričnog kriptosustava u njegovoj brzini u odnosu na asimetrični kriptosustav. Ta brzina možda nije toliko bitna kada se poslužuje jedan korisnički zahtjev, ali ako se radi o velikom broju zahtjeva koji se poslužuju paralelno, opravdano je koristiti se takvom kombinacijom spomenutih dvaju kriptosustava. Uz takvu konstataciju, prisutnost asimetričnog kriptosustava opravdana je nezgodnom razmjenom simetričnog ključa u slučaju izostanka asimetričnog kriptosustava. U tom slučaju, slanje simetričnog ključa sigurnom poslužitelju bez ikakve zaštitite omogućilo bi trećoj strani da nesmetano “pokupi” spomenuti ključ i na taj način ugrozi kompletnu preostalu komunikaciju, bez obzira na njenu zaštitu kriptiranjem.

Opisana zaštita poruke kriptiranjem možda se čini dovoljnom u komunikaciji dviju strana. Ali to ipak nije dovoljno. Autentičnost sudionika u sigurnoj komunikaciji osigurana je digitalnim potpisom. Uz svaku poruku, SSL protokol pridodaje digitalni potpis iste te na taj način ostvaruje drugu osobinu, odnosno autentičnost strane u komunikaciji.

Treća osobina SSL protokola je integritet poruke. Spomenuti digitalni potpis koji se koristi za utvrđivanje autentičnosti također osigurava integritet poruke. Opširniji opis digitalnog potpisa obrađen je u poglavlju 2.5.

3. Protokoli plaćanja elektroničkim novcem

3.1 Osnovni protokoli

Kao uvodno poglavlje 3. poglavlju slijede opisi dvaju jednostavnih protokola čija je jedina razlika u prisutnosti osobine anonimnosti kupca u sustavu plaćanja elektroničkim novcem. Podjela na dva osnovna protokola više je uvedena radi jednostavnijeg shvaćanja uvođenja i funkcioniranja mehanizma koji osigurava anonimnost kupca u transakciji, nego radi njihove pojedinačne uporabivosti i međusobne različitosti.

3.1.1 Protokol bez anonimnosti

Pretpostavimo da su sudionici transakcije plaćanja elektroničkim novcem kupac, trgovac i banka te da se radi o on-line sustavu plaćanja elektroničkim novcem. On-line sustav znači da se provjera valjanosti elektroničkog novca obavlja odmah nakon što trgovac primi elektronički novac od kupca. Suprotno on-line sustavu razlikujemo off-line sustav plaćanja elektroničkim novcem u kojem se provjera elektroničkog novca odgađa za kasnije. Da bi se provjera obavila, novac se prosljeđuje banci. Detaljniji opis provjere elektroničkog novca slijedi u poglavlju 3.2.

Slika 3.1 prikazuje kretanje zahtjeva za kupnjom te protok elektroničkog novca i kupljene robe između pretpostavljenih sudionika transakcije.

Šest koraka sa slike 3.1 mogu se grupirati u tri faze. Prva faza predstavlja podizanje elektroničkog novca s bankovnog računa:

• kupac šalje zahtjev banci za određenom količinom elektroničkog novca (korak 1.)
• banka oblikuje elektroničku novčanicu te ostavlja digitalni potpis
• banka šalje elektroničku novčanicu kupcu te umanjuje njegov račun (korak 2.)

U drugoj fazi obavlja se plaćanje odabrane robe:

• kupac šalje elektronički novac trgovcu (korak 3.)
• trgovac provjerava digitalni potpis banke na primljenoj novčanici

Treća faza transakcije predstavlja provjeru elektroničkog novca od strane banke i isporuku robe kupcu od strane trgovca:

• trgovac šalje elektroničku novčanicu banci (korak 4.)
• banka provjerava potpis na novčanici
• banka uspoređuje serijski broj novčanice s postojećima u bazi uporabljenih elektroničkih novčanica
• banka unosi serijski broj novčanice u bazu uporabljenih novčanica
• banka povećava račun trgovca
• banka šalje odgovor trgovcu (korak 5.)
• trgovac šalje kupljenu robu kupcu (korak 6.)

U drugoj točki prve faze protokola, banka potpisuje elektroničku novčanicu. Točnije, banka pridodaje elektroničkoj novčanici digitalni potpis iste čime je rješen potencijalni problem krivotvorenja elektroničkog novca. Ako se uz elektroničku novčanicu ne nalazi bankin potpis, novčanica je nevažeća.

Prilikom potpisivanja elektroničke novčanice u prvoj fazi, banka može zapamtiti vezu serijskog broja na novčanici i osobe koja je podigla novac, dakle kupca. Naknadno primanje iste te novčanice omogućuje banci praćenje transakcije koju je prethodno pokrenuo kupac. Opisani nedostatak protokola plaćanja elektroničkim novcem rješava se mehanizmom slijepog potpisa[15] koji onemogućuje banku da dovede u vezu podizanje elektroničke novčanice s njenim deponiranjem. Time će biti ostvarena anonimnost kupca dok će banka biti sigurna u valjanost elektroničke novčanice.

Protokol sa slike 3.1 predstavlja osnovni protokol u šest koraka. U tih šest koraka opisani su osnovni dijelovi transakcije: podizanje novca iz banke, plaćanje odabrane robe te provjera elektroničkog novca i isporuka kupljene robe. Svih šest koraka bit će osnovni i neizbježni dijelovi protokola plaćanja elektroničkim novcem koji se opisuju u ostatku diplomskog rada.

3.1.2 Protokol s anonimnošču

Ovaj protokol, za razliku od protokola iz prethodnog poglavlja, karakterizira osobina anonimnosti kupca u transakciji, odnosno nemogućnost praćenja transakcije u sustavu plaćanja elektroničkim novcem. Navedena osobina ostvaruje se mehanizmom slijepog potpisa koji će detaljnije biti opisan u poglavlju 3.3.

Opis ovog protokola također se može pratiti po koracima sa slike 3.1. Bitna razlika u odnosu na protokol iz poglavlja 3.1.1 javlja se već u prvoj fazi, odnosno fazi podizanja elektroničkog novca iz banke. Sljedeće točke predstavljaju spomenutu fazu:

• kupac oblikuje elektroničku novčanicu te ju “prikriva”
• kupac šalje “prikrivenu” elektroničku novčanicu banci zajedno sa zahtjevom za podizanje određene svote elektroničkog novca (korak 1.)
• banka potpisuje primljenu “prikrivenu” elektroničku novčanicu i umanjuje račun kupcu
• banka šalje potpisanu elektroničku novčanicu kupcu (korak 2.)
• kupac uklanja faktor prikrivanja[16] s elektroničke novčanice

Druga i treća faza ovog protokola ne razlikuju se od druge i treće faze protokola iz prethodnog poglavlja, stoga opis te dvije faze pogledati u prethodnom poglavlju.

U prvoj točki prve faze protokola kupac sam oblikuje elektroničku novčanicu. To je preduvjet da bi se ostvarila osobina anonimnosti kupca u transakciji. Nakon toga kupac “prikriva” elektroničku novčanicu koju je upravo oblikovao te na taj način čini serijski broj novčanice nevidljivim banci. Banka prilikom potpisivanja novčanice ne može zabilježiti serijski broj koji se nalazi na novčanici, stoga ne može dovesti u vezu podizanje elektroničke novčanice s njenim deponiranjem na kraju transakcije.

3.2 Konačni oblik protokola

Protokol plaćanja elektroničkim novcem iz prethodnog poglavlja predstavlja osnovu za konačni oblik protokola čiji opis slijedi u ovom poglavlju. Također, protokol iz prethodnog poglavlja ima jedan nedostatak, a taj je da bi u takvom protokolu nemoguće bilo otkriti prijevaru dvostruke potrošnje[17]. Prijevara dvostruke potrošnje javlja se kada se isti elektronički novac iskoristi u dvije ili više transakcija. Stoga se jedna elektronička novčanica upotrebljava samo u jednoj transakciji. Da bi se sprječila potrošnja iste elektroničke novčanice u dvije ili više transakcija koristi se mehanizam identificirajuće informacije. Identificirajuća informacija postaje djelom elektroničke novčanice. Temeljni princip je takav da ako kupac koji sudjeluje u transakciji koristi elektronički novac samo unutar jedne transakcije, njegov identitet ostaje sačuvan, dakle osobina anonimnosti je prisutna. Ako se već potrošen elektronički novac pokuša koristiti u novoj transakciji, identitet kupca iste transakcije otkrit će se već pri prvoj provjeri takvog novca u banci. Detaljniji opis identificirajuće informacije slijedi u poglavlju 3.3.

Slika 3.2 ilustrira u svim koracima konačni oblik protokola plaćanja elektroničkim novcem. Protokol se sastoji od ukupno deset koraka. Slično kao u prethodnom poglavlju, i ovaj se protokol može podijeliti na tri faze. Slijedi opis protokola sa slike 3.2.

Prva faza protokola:

• kupac oblikuje n elektroničkih novčanica koje nose jednaki iznos, ali različiti serijski broj
• kupac prikriva n elektroničkih novčanica
• kupac šalje n prikrivenih elektroničkih novčanica banci (korak 1.)
• banka šalje zahtjev kupcu za otkrivanje n-1 slučajno odabrane elektroničke novčanice (korak 2.)
• kupac šalje banci n-1 traženi faktor prikrivanja i n-1 odgovarajuću identificirajuću informaciju (korak 3.)
• banka provjerava valjanost n-1 elektroničke novčanice (iznos i identificirajuću informaciju)
• banka potpisuje preostalu elektroničku novčanicu
• banka šalje potpisanu elektroničku novčanicu kupcu te umanjuje račun kupca (korak 4.)
• kupac uklanja faktor prikrivanja s potpisane novčanice te provjerava potpis banke

Za razliku od protokola sa slike 3.1, konačni oblik protokola u prvoj fazi ima četiri koraka. Dodatna dva koraka detaljnije opisuju mehanizam slijepog potpisa. Kompletan opis slijedi u poglavlju 3.3. Također, banka provjerava prisutnost ispravne identificirajuće informacije na n-1 elektroničkoj novčanici čime se osigurava u slučaju dvostruke potrošnje.

Slijedi druga faza protokola koja prikazuje plaćanje odabrane robe:

• kupac šalje potpisanu elektroničku novčanicu trgovcu (korak 5.)
• trgovac provjerava digitalni potpis banke uz elektroničku novčanicu
• trgovac šalje kupcu slučajno generirani odabirući niz[18] (korak 6.)
• kupac šalje tražene informacije trgovcu (korak 7.)
• trgovac provjerava valjanost dijela identificirajuće informacije na elektroničkoj novčanici

U ovoj fazi spominje se odabirući niz. Taj pojam je vezan uz mehanizam identificirajuće informacije, stoga će detaljno biti objašnjen u poglavlju 3.3. U posljednjoj točki druge faze trgovac se uvjerava da je elektronička novčanica zbilja vlasništvo kupca koji komunicira s trgovcem. Na taj način može se odmah uštedjeti posao slanja elektroničke novčanice banci u slučaju primljene tuđe novčanice, dakle u slučaju prijevare.

Treću fazu konačnog oblika protokola plaćanja elektroničkim novcem predstavlja provjera elektroničke novčanice i isporuka kupljene robe:

• trgovac šalje potpisanu elektroničku novčanicu, identificirajući niz, dio identificirajuće informacije i broj bankovnog računa banci (korak 8.)
• banka provjerava digitalni potpis uz primljenu elektroničku novčanicu
• banka uspoređuje serijski broj elektroničke novčanice s onima u bazi uporabljenih novčanica
• banka unosi serijski broj elektroničke novčanice, odabirući niz i dio identificirajuće inforamcije u bazu uporabljenih elektroničkih novčanica
• banka šalje odgovor trgovcu o ispravnosti elektroničke novčanice i uvećava račun trgovca (korak 9.)
• trgovac provjerava odgovor banke
• trgovac šalje robu kupcu (korak 10.)

U posljednjoj fazi, kao i u prethodne dvije, pretpostavlja se da se svaki korak odvija ispravno, dakle da se transakcija odvija u najboljem redu, bez ikakvih pokušaja krivotvorenja, prijevare ili višestruke potrošnje.

Konačni oblik protokola plaćanja elektroničkim novcem ima sve preduvjete za njegovu implementaciju, odnosno za njegovu praktičnu korist. Krivotvorenje se sprječava digitalnim potpisom banke u kojoj se nalaze bankovni računi kupca i trgovca. Ugrađena je osobina anonimnosti koju osigurava slijepi potpis. Višestruka potrošnja sprječava se mehanizmom identificirajuće inforamcije. Integritet elektroničke novčanice osiguran je digitalnim potpisom. Sve nabrojane osobine konačnog oblika protokola plaćanja elektroničkim novcem osiguravaju ispravnu i prihvatljivu transakciju unutar trokuta kupac-trgovac-banka, dakle gledano s više razine svakog od tri spomenuta sudionika transakcije.

U slučaju implementacije ovakvog protokola unutar web-a, gdje se pojavljuju neželjeni i pritajeni sudionici komunikacija između dviju strana, potrebno je koristiti dodatnu razinu zaštite cijelog protokola. Put koji prolazi elektronički novac između kupca i druge strane, odnosno trgovca i druge strane je potencijalno ugrožen od treće strane. Opis rješenja ovog problema nalazi se u poglavlju 3.4.

3.3 Zaštitni mehanizmi

3.3.1 Digitalni potpis

Digitalni potpis osigurava banku od krivotvorenja elektroničkog novca na način da se uz svaku elektroničku novčanicu mora nalaziti njen digitalni potpis.

Detaljan opis digitalnog potpisa opisan je u poglavlju 2.5

3.3.2 Slijepi potpis

Prilikom izdavanja elektroničke novčanice, banka može uz odgovarajući serijski bro zapamtiti i osobu kojoj je izdala novčanicu te na taj način narušiti privatnost iste osobe prilikom primanja iste te novčanice tjekom neke transakcije. U tom slučaju, u protokol plaćanja elektroničkim novcem ugrađuje se mehanizam slijepog potpisa koji osigurava anonimnost kupca koji ulazi u transakciju.

Radi jednostavnijeg shvaćanja slijepog potpisa, opisat će se analogija s omotnicom i indigo papirom. Pretpostavimo da kupac novčanicu koju želi da banka potpiše stavi u neprozirnu omotnicu u kojoj se također nalazi indigo papir. Potom ju kupac zatvori i pošalje banci. Banka potpisuje primljenu omotnicu, a zbog prisutnosti indigo papira potpisuje i novčanicu, te tako potpisanu omotnicu šalje natrag pošiljaocu. Nakon što je kupac primio potpisanu omotnicu, on ju otvara i uzima potpisanu novčanicu. Banka nikako nije mogla zabilježiti serijski broj novčanice koja je u zatvorenoj neprozirnoj omotnici, dok kupac ima potpisanu novčanicu i anonimnost u kupnji robe.

Sličan postupak se obavlja s elektroničkom novčanicom. Postoji više načina na koji se slijepi potpis može izvesti, dok će ovdje biti opisan jedan koji je implementiran u konačnom obliku protokola plaćanja elektroničkim novcem.

Kupac, prije nego što pošalje elektroničku novčanicu banci, prikriva novčanicu sa slučajno generiranim brojem, tzv. faktorom prikrivanja. Prikrivenu elektroničku novčanicu šalje banci. Banka potpisuje primljenu prikrivenu novčanicu te umanjuje račun kupca za dogovoreni iznos. Banka šalje potpisanu novčanicu kupcu koji po primitku novčanice uklanja faktor prikrivanja te dobija potpisanu elektroničku novčanicu. U ovom bi slučaju jedino kupac bio zadovoljan jer banka zapravo ne zna što potpisuje, pogotovo kada se radi o iznosu elektroničke novčanice. Opisani postupak se proširuje tako da kupac umjesto jedne prikrivene novčanice šalje banci n prikrivenih elektroničkih novčanica. Na svakoj elektroničkoj novčanici jednak je iznos novčanice, ali su serijski brojevi različiti. Kada banka primi svih n prikrivenih elektroničkih novčanica, ona slučajno odabire n-1 od tih novčanica te traži od kupca faktore prikrivanja za odabrane novčanice. Nakon što primi tražene faktore prikrivanja, otkriva odabrane elektroničke novčanice te provjerava njihovu valjanost. Najbitnije je da je iznos na svakoj od n-1 novčanice jednak dogovorenom iznosu. Ako su odabrane novčanice valjane, banka potpisuje preostalu prikrivenu elektroničku novčanicu. Potpisanu novčanicu šalje kupcu te umanjuje njegov račun. Vjerojatnost da je banka prevarena je 1/n.

Prikrivanje kod postupka slijepog potpisa moguće je ostvariti množenjem elektroničke novčanice sa slučajno generiranim brojem. Taj broj predstavlja faktor prikrivanja. Nakon što je prikrivena elektronička novčanica potpisana digitalnim potpisom, novčanica se dijeli s faktorom prikrivanja. Rezultat je potpisana elektronička novčanica. Ovaj postupak je ostvariv jedino ako su funkcije množenja i kriptiranja digitalnog potpisa komutativne. Jedna od izvedbi slijepog potpisa koristi kriptiranje RSA algoritmom kao digitalnim potpisom. Pretpostavimo:

(n, e) je javni ključ

(n, d) je tajni ključ

m je elektronička novčanica koja zadovoljava 0 L m < n

• kupac slučajno odabire broj k između 1 i n te prikriva elektroničku novčanicu m:

t=mk^e mod n

(3.1)

• banka potpisuje prikrivenu elektroničku novčanicu t:

t^d=(mk^e)^d mod n

(3.2)

• kupac uklanja faktor prikrivanja:

s=t^d/k mod n=m^dk/k mod n=m^d mod n	(3.3)
(mk^e)^d=m^dk^ed=1ed=aL(n)+11=m^dk^aL(n)+1om^dk (mod n)	(3.4)

3.3.3 Identificirajuća informacija

Identificirajuća informacija sastavni je dio svake elektroničke novčanice koju potpisuje banka da bi se pri tom osigurala od prijevare dvostruke potrošnje. Mehanizam identificirajuće informacije otkriva identitet sudionika transakcije koji je pokušao ili izvršio prijevaru dvostruke potrošnje, dok poštenog sudionika ostavlja u anonimnosti.

U postupku oblikovanja identificirajuće informacije koristi se n nizova identifikacijskih bitova. Identifikacijski bitovi genenriraju se na temelju podataka karakterističnih za osobu koja sudjeluje u transakciji, odnosno za osobu koja generira elektroničku novčanicu. Ti podaci mogu biti ime i prezime osobe, e-mail, telefonski broj te ostale bitne informacije o sudioniku transakcije koje ga identificiraju. Tako generirani identifikacijski nizovi razdvajaju se postupkom dijeljenja tajne[19] na dva dijela. Opširnije o tom postupku nešto kasnije. Svaki dio za sebe ne govori ništa o osobi koja je generirala identifikacijske nizove, ali oba dijela zajedno čine identifikacijski niz koji identificira osobu. Nakon što su svi identifikacijski nizovi razdijeljeni na dva dijela, svi parovi zajedno predstavljaju identificirajuću informaciju. Svaki par sastoji se od lijeve i desne polovice.

U koraku 6. sa slike 3.2 trgovac šalje kupcu odabirući niz. Odabirući niz je zapravo niz 0 i 1 pri čemu, ovisno o dogovoru, 1 znači jednu, dok 0 predstavlja drugu polovicu identifikacijskog niza. Redoslijed 0 i 1 u odabirućem nizu predstavlja redoslijed identifikacijskih nizova čije se polovice traže. Nakon što kupac pošalje polovice identifikacijskih nizova, trgovac ih uspoređuje s onima na elektroničkoj novčanici. Treba napomenuti da se na elektroničkoj novčanici nalaze sažeci polovica identifikacijskih nizova, tako da trgovac prije usporedbe obavlja hash funkciju nad svakom polovicom. Sažetak polovice identifikacijskog niza osigurava tajnost te polovice. U trenutku depozita, trgovac uz elektroničku novčanicu šalje banci odabirući niz i primljene polovice identifikacijskih nizova. Banka uspoređuje serijski broj elektroničke novčanice s onima u bazi uporabljenih novčanica. Ako je elektronička novčanica već korištena, banka uparuje dvije različite polovice istog identifikacijskog niza i otkriva identitet kupca koji je pokušao prijevaru dvostruke potrošnje. Jedna od polovica koje se uparuju je iz baze, dok je druga ona upravo primljena od strane trgovca zajedno s elektroničkom novčanicom. Utvrđivanje identiteta na taj način moguće je jer su, s velikom vjerojatnošću, odabirući niz iz baze i upravo primljeni odabirući niz različiti. Odabirući nizovi trebali bi biti različiti jer ih trgovac generira slučajno u svakoj transakciji. Ako se identificirajuća informacija sastoji od n parova polovica identifikacijskih nizova, vjerojatnost da trgovac dva puta generira isti odabirući niz je 1/2ⁿ. Dakle vjerojatnost je zanemarivo mala i opada s brojem identifikacijskih nizova koji se nalaze na elektroničkoj novčanici. Poželjno je staviti čim više identifikacijskih nizova, ali opet ne previše radi veličine same elektroničke novčanice.

S obzirom na vrlo malu vjerojatnost generiranja dva jednaka odabiruća niza, ako se i pojave takvi odabirući nizovi, sve upućuje na to da je trgovac pokušao prevariti banku i iskoristiti isti elektronički novac drugi put. Za to su mu potrebni elektronički novac kojeg je mogao zadržati iz neke od prijašnjih transakcija, odabirući niz i odgovarajuće polovice identifikacijskih nizova. Upravo zbog ispravnih polovica identifikacijskih nizova, trgovac je prisiljen koristiti, uz sačuvanu elektroničku novčanicu, i sačuvan odgovarajući odabirući niz i odgovarajuće polovice identifikacijskih nizova. Stoga ponovljeni odabirući niz uz ponovljenu elektroničku novčanicu jedino upućuje na pokušaj prijevare od strane trgovca. Treba uzeti u obzir vrlo malu vjerojatnost generiranja dva jednaka odabiruća niza za jednu te istu elektroničku novčanicu.

Da trgovac ne bi sam postavio lažnu identificirajuću inforamciju na novčanicu te time generirao lažni odabirući niz i odgovarajuće polovice identifikacijskih nizova, sprječava ga digitalni potpis banke na elektroničkoj novčanici.

Iz opisanog mehanizma identificirajuće informacije jasno se vidi da je protokol plaćanja elektroničkim novcem osiguran od prijevare dvostruke potrošnje bilo od strane kupca bilo od strane trgovca.

3.3.4 Postupak dijeljenja tajne

Postupak dijeljenja tajne koristi se kod razdvajanja identifikacijskih nizova na dva dijela jednake duljine. Nad izvornim identifikacijskim nizom obavlja se operacija isključivo ili sa slučajno generiranim nizom jednake duljine. Rezultantni niz je jedna polovica identifikacijskog niza, dok je slučajno generirani niz druga polovica. Ako se gleda pojedina polovica sama za sebe, ona ništa ne govori o onome što govori identifikacijski niz. Rezultat operacije isključivo ili između dviju polovica predstavlja identifikacijski niz.

Na ovaj se način osiguravaju dvije zavisne polovice identifikacijskog niza koje se koriste u izgradnji identificirajuće informacije.

3.4 Kriptografski zaštićen konačni oblik protokola

3.4.1 Uvod

Pretpostavimo da je kupac, kao fizička osoba, odlučio otići u kupovinu. Za to mu je potrebna određena količina novca, pretpostavimo gotovine. Da bi došao do novca, kupac odlazi u banku i podiže određenu svotu novca (papirnati ili kovanice). Na putu do trgovine taj će novac biti spremljen najčešće u novčaniku ili torbici daleko od znatiželjnih pogleda ostalih ljudi. Na taj način novac se nalazi na sigurnom mjestu te kupac nesmetano prelazi put do trgovine, odnosno trgovca. Vrlo je mala vjerojatnost da će se naći netko tko će ukrasti novac kojeg kupac nosi sa sobom do trgovine. Došavši u trgovinu, kupac nesmetano obavlja transakciju kupovine. Na sličan način, možda s drugačijim sredstvom zaštite novca, trgovac odnosi prikupljeni novac u banku.

Analogija vrijedi i kod transakcije plaćanja elektroničkim novcem. Da bi kupac, u sustavu plaćanja elektroničkim novcem, sigurno, bez moguće opasnosti od prisluškivanja treće strane, podigao elektronički novac iz banke te ga poslao trgovcu u elektroničku trgovinu, potrebna mu je adekvatna zaštita istog tog elektroničkog novca. Isto vrijedi za trgovca koji obavlja depozit primljenog elektroničkog novca u banku. Dakle elektronički novac koji se koristi u komunikaciji između dvije strane u konačnom obliku protokola plaćanja elektroničkim novcem, potrebno je na određeni način zaštititi od mogućih neželjenih negativnih utjecaja treće strane. Opisani problem javlja se zbog važne osobine elektroničkog novca, anonimnosti. Da elektronički novac nije anoniman, dakle da svaka novčanica, na primjer, nosi identitet svog prvog vlasnika, kupac bi prilikom plaćanja trebao samo dokazati svoj identitet koji ujedino nosi elektronička novčanica. Upravo je zato anonimnost bitna osobina sustava plaćanja elektroničkim novcem koji se razmatra u ovom diplomskom radu te je uzrok detaljnoj analizi konačnog oblika protokola i njegovoj zaštiti.

Pretpostavimo sljedeću situaciju. Kupac je, po protokolu iz poglavlja 3.2, podigao elektronički novac te ga je poslao trgovcu u svrhu kupnje određene robe. Na putu od kupca do trgovca, treća strana je prisluškivanjem došla do spomenutog elektroničkog novca. Odmah potom je obavila depozit ukradenog elektroničkog novca u banku, prije nego što je to učinio trgovac s istim tim novcem. Nakon toga, trgovac obavlja depozit tog elektroničkog novca. Banka otkriva i okrivljuje trgovca u pokušaju depozita već potrošenog elektroničkog novca (slučaj s istim odabirućim nizom i polovicama identifikacijskih nizova) iako trgovac nije ništa skrivio.

U sljedećem slučaju, kupac, također po protokolu iz poglavlja 3.2, podiže elektronički novac iz banke. Nakon toga, kupac šalje trgovcu elektronički novac. U tom trenutku, treća strana prisluškivanjem krade potpisani elektronički novac, obavlja kupnju nekog proizvoda u nekoj trgovini prije nego to učini prvi kupac. Nakon što prvi kupac isplati trgovca, trgovac šalje elektronički novac u banku i provjerava valjanost novca. Banka otkriva da je kupac pokušao prijevaru dvostruke potrošnje iako je nedužan.

Dvije opisane situacije prijevare unutar sustava plaćanja elektroničkim novcem daju dovoljno razloga za potpunu enkapsulaciju protokola plaćanja elektroničkim novcem unutar kriptografske zaštite prije nego se implementira u spomenuti sustav.

3.4.2 Opis

Opis proširenog, kriptografski zaštićenog protokola iz poglavlja 3.2 ilustriran je na slici 3.3. Radi detaljnijeg i preglednijeg objašnjenja istog, sliku 3.3 će se razdijeliti na više manjih slika uz popratna objašnjenja svakog pojedinog koraka protokola.

Iako na slici nije prikazan, u ovakvom obliku protokola uključen je autentifikacijski server zbog potreba autentifikacije unutar kriptografski zaštićenog konačnog oblika protokola. Autentifikacijski protokol koji će se koristiti u protokolu sa slike 3.3 je protokol iz poglavlja 2.6. Izostanak simbola autentifikacijskog servera sa slike opravdava se nepreglednošću slike koja bi nastala kada bi se dodao AS i svi koraci koje donosi postupak autentifikacije (vidi sliku 2.6). U protokolu sa slike 3.3 tri puta se pojavljuje postupak autentifikacije. Svaki od tih postupaka je, s obzirom na prethodno objašnjenje, predstavljen jednom strelicom, dakle označen jednom skupnom porukom ma_x gdje x predstavlja broj poruke sa slike. Obična poruka označena je s m_x.

S obzirom na veću kompleksnost od protokola iz poglavlja 3.1 i 3.2, protokol sa slike 3.3 podijelit će se na više faza. Strelice koje čine pojedinu fazu na slici 3.3 vidljivo su grupirane tako da se paralelno, uz spomenute manje slike koje slijede niže u poglavlju, opis protokola može pratiti i na slici 3.3.

Prva faza predstavlja isporuku računa kupcu od strane trgovca i prikazana je slikom 3.4.

• skup poruka ma₁: autentifikacija trgovca prema kupcu
• poruka m₂: E(K_{kupca / trgovca}, P_trgovca)[20]
• poruka m₃: E(Račun, K_{kupca / trgovca})

Prije nego što počne prva faza protokola sa slike 3.3, kupac odabire željene proizvode u elektroničkoj trgovini i pokreće transakciju kupnje. Tom prilikom, trgovac generira odgovarajući račun s obzirom na odabranu robu. Taj račun se koristi u protokolu koji se trenutno opisuje. Detaljnije informacije u vezi funkcioniranja elektroničke trgovine na web stranicama slijede u 4. poglavlju.

U prvom koraku obavlja se autentifikacija trgovca od strane kupca. Cilj te autentifikacije je dobavljanje javnog ključa trgovca kupcu te identifikacija osobe koja se predstavlja kao trgovac u slučaju pokušaja prijevare. Prije drugog koraka kupac generira slučajni simetrični ključ K_{kupca / trgovca} koji služi za daljnju kriptiranu komunikaciju s trgovcem. Poruka m₂ predstavlja slanje tog ključa trgovcu, nakon čega trgovac u trećem koraku šalje račun kupcu. Pri tome se koristi zajedničkim simetričnim ključem kojeg je prethodno primio od kupca.

Potreba za kriptiranom komunikacijom između kupca i trgovca javlja se već na samom početku protokola. Kupcu je bitno da po primitku kriptiranog računa bude siguran da je primio račun od identificiranog trgovca, a ne od moguće treće strane koja prisluškuje komunikaciju.

Nakon što je kupac primio račun, obavlja se provjera tog računa na temelju prethodne kopije računa koju je kupac kao osoba zabilježio prije nego li je nepovratno započeo transakciju. Na taj način, trgovac nikako ne može podvaliti kupcu drugi račun koji bi, na primjer, bio stostruko veći. Detaljnije objašnjenje postupka bilježenja računa slijedi u 4. poglavlju.

U drugoj fazi kupac pokreće podizanje novca iz banke.

• skup poruka ma₄: autentifikacija kupca prema banci
• poruka m₅: E(K_banke, P_kupca)
• poruka m_6a: E(K_lažni, P_banke)[21]
• poruka m_6b: E(n prikrivenih elektroničkih novčanica, K_{kupca / banke})

U četvrtom koraku banka identificira kupca postupkom autentifikacije u svrhu smanjenja bankovnog računa i pribavljanja javnog ključa kupca. U poruci m₅ banka šalje kupcu svoj dio simetričnog ključa, K_banke, koji će služiti za daljnju komunikaciju kupca i banke. Kupac, po primitku K_banke, generira zajednički simetrični ključ K_{kupca / banke} za kriptiranje međusobne komunikacije te računa lažni simetrični ključ:

Klažni= Kkupca / banke A Kbanke

(3.5)

Lažni simetrični ključ šalje banci u poruci m_6a. Nakon primitka poruke m_6a, banka računa zajednički simetrični ključ po formuli 3.6:

Kkupca / banke = Klažni A Kbanke

(3.6)

Na ovaj način kupac je siguran da komunicira s pravom bankom, dok je banka sigurna da komunicira s identificiranim kupcem. Kupac ne može oblikovati K_lažni ako nema K_banke. Banka ne može dekriptirati K_lažni, a time niti izračunati K_{kupca / banke}, ako nije banka za koju se predstavlja.

U drugom dijelu šestog koraka kupac šalje n prikrivenih elektroničkih novčanica. Komunikacija kriptirana zajedničkim simetričnim ključem kupca i banke je počela.

Isplaćivanje elektroničkog novca iz banke obuhvaćeno je trećom fazom.

· poruka m₇: E(zahtjev za n-1 faktor prikrivanja, K_{kupca / banke})

· poruka m₈: E(n-1 faktor prikrivanja i parova polovica identifikacijskih nizova, K_{kupca / banke})

· poruka m₉: E(Potpisana elektronička novčanica, K_{kupca / banke})

Poruke m₇ i m₈ rezultat su mehanizma slijepog potpisa. Parovi polovica identifikacijskih nizova šalju se zajedno s faktorima prikrivanja da bi banka mogla provjeriti valjanost identificirajuće informacije na otkrivenim elektroničkim novčanicama. U devetom koraku, banka šalje potpisanu prikrivenu elektroničku novčanicu.

Četvrta faza obuhvaća isplatu elektroničkog novca trgovcu o s obzirom na primljeni račun.

·

poruka m₁₀: E(Elektronička novčanica, K_{kupca / trgovca})

· poruka m₁₁: E(Odabirući niz, K_{kupca / trgovca})

· poruka m₁₂: E(Polovice identifikacijskih nizova, K_{kupca / trgovca})

U ovoj fazi opisana su tri koraka konačnog oblika protokola sa slike 3.2: koraci 5, 6 i 7. Komunikacija između kupca i trgovca je kriptirana simetričnim kriptosustavom, stoga je sigurna. Prije nego što trgovac pošalje poruku m₁₁, provjerava digitalni potpis banke na elektroničkoj novčanici da vidi isplati li se nastaviti transakciju.

U sljedećoj, petoj fazi, trgovac šalje elektronički novac banci na provjeru te obavlja depozit u slučaju ispravnog novca.

·
skup poruka ma₁₃: autentifikacija trgovca prema banci

· poruka m₁₄: E(K_banke1, P_trgovca)

· poruka m_15a: E(K_lažni1, P_banke)

· poruka m_15b: E((Elektronička novčanica, odabirući niz, polovice identifikacijskih nizova, broj bankovnog računa), K_{trgovca / banke})

U trinaestom koraku trgovac se identificira banci putem autentifikacije. Autentifikacija je potrebna u slučaju ako trgovac pokuša iskoristiti već potrošen elektronički novac te po drugi put obaviti depozit. U tom slučaju će se znati tko je pokušao prijevaru. Postupkom autentifikacije se također dobavlja javni ključ trgovca koji je potreban banci za razmjenu simetričnih ključeva.

Postupak oblikovanja zajedničkog simetričnog ključa jednak je onom iz druge faze kada su komunikaciju započinjali kupac i banka. U ovom slučaju simetrični ključ banke, nakon postupka autentifikacije, prima trgovac. Da bi se trgovac uvjerio da je na drugoj strani zbilja banka, generira zajednički simetrični ključ K_{trgovca / banke} te lažni simetrični ključ K_lažni1 prema formuli 3.7:

Klažni1= Ktrgovca / banke A Kbanke1

(3.7)

K_lažni1, u poruci m_15a, šalje se banci zakriptiranog sa P_banke. Dakle samo banka može dekriptirati spomenutu poruku. Nakon što je banka primila K_lažni1, računa zajednički simetrični ključ K_{trgovca / banke}:

Ktrgovca / banke = Klažni1 A Kbanke1

(3.8)

Nakon toga počinje komunikacija između trgovca i banke kriptirana zajedničkim simetričnim ključem K_{trgovca / banke}. Banka prima poruku m_15b. S obzirom na sadržaj poruke, banka provjerava elektroničku novčanicu te u slučaju valjanosti uvećava iznos na bankovnom računu kojeg je poslao trgovac.

U šestoj fazi trgovac dobiva odgovor banke o ispravnosti elektroničkog novca.

• poruka m₁₆: E(Odgovor o ispravnosti elektroničkog novca, K_{trgovca / banke})

S obzirom da je poruka m₁₆ kriptirana zajedničkim simetričnim ključem, trgovac dobiva vjerodostojnu informaciju o ispravnosti elektroničkog novca kojeg je poslao banci. Spomenuta kriptirana poruka ne može se ponoviti u nekoj drugoj komunikaciji. Trgovac je spreman na isporuku robe kupcu.

Posljednja, sedma faza protokola sa slike 3.3, predstavlja isporuku kupljene robe kupcu.

· poruka m_17a: E(Odgovor o isporuci robe, K_{kupca / trgovca})

· poruka m_17b: E(Datoteka, K_{kupca / trgovca})

Posljednji korak kriptografski zaštićenog konačnog oblika protokola zapravo je slanje elektroničke robe, točnije datoteke, kupcu. Samim tim, ovaj korak zastupljen je jedino ako se radi o kupljenoj elektroničkoj robi, dakle kada se šalje datoteka. Korak se može ponoviti onoliko puta koliko je preostalih elektroničkih artikala.

Za kupljene materijalne artikle ili elektroničku robu koja zauzima puno prostora na disku, obavlja se drugačiji transport. Više riječi o tome u 4. poglavlju.

Kao što se može vidjeti, poruka m_17b je također u kriptiranom obliku. Dakle moguće prisluškivanje datoteke koja se šalje preko Interneta od trgovca do kupca je uzaludno. Postoji mogućnost da se izostavi kriptiranje, ali tada se javlja rizik od krađe spomenute datoteke tjekom njenog transporta.

Opisani konačni oblik protokola plaćanja elektroničkim novcem, koji je zaštićen kriptografskim metodama, osigurava siguran protok elektroničkog novca i informacije bitne za ispravno funkcioniranje protokola iz poglavlja 3.2.

Pažljivim promatranjem prve, druge ili pete faze može se uočiti sličnost sa SSL protkolom iz poglavlja 2.7. Komunikacija između dvije strane u transakciji je začtićena simetričnim kriptosustavom. Razmjena simetričnih ključeva obavlja se kriptiranjem pomoću asimetričnog kriptosustava, dakle koristeći javne ključeve za kriptiranje te tajne za dekriptiranje simetričnog ključa. Razlika u odnosu na SSL je ta što se prilikom razmjene kriptiranih poruka u komunikaciji ne šalje njihov digitalni potpis. Razlog tome je taj što se kod primanja sljedećih poruka točno zna koliko je kriptirana poruka dugačka i koji se sadržaj poruke očekuje. Samim tim integritet poruke je osiguran, dok je autentičnost sudionika transakcije provjerena na samom početku međusobne komunikacije dviju strana u autentifikacijskom postupku. To je dodatni razlog za korištenje autentifikacije prilikom prijave sudionika u transakciju. Na temelju opisane razmjene tajnih simetričnih ključeva zasniva se kriptografska zaštita konačnog oblika protokola plaćanja elektroničkim novcem. Bitno je napomenuti da se svi tajni simetrični ključevi slučajno generiraju.

Trgovac u prvoj fazi protokola sa slike 3.4 ne utvrđuje identitet kupca. Dva su razloga. Jedan je taj da trgovcu nije toliko bitno da li se s druge strane zbilja nalazi kupac koji je pokrenuo transakciju, već mu je bitno da se transakcija uspješno završi, dakle da trgovac proda robu i primi važeći elektronički novac. Ako se trgovcu predstavio lažni kupac, a ima namjeru kupiti robu koja se nalazi na računu trgovca, onda je mogao i sam pokrenuti transakciju. U suprotnom, transakcija će završiti prije nego što bi trebala. Drugi razlog je u tome što kupac ostaje anoniman tjekom cijele transakcije, stoga njegova identifikacija ne dolazi u obzir.

U drugoj i petoj fazi opisanog protokola kupac i trgovac se identificiraju banci tako da banka zna tko podiže novac, odnosno tko obavlja depozit elektroničkog novca. S druge strane, kupac, odnosno trgovac posjeduju javni ključ banke te kombinacijom isključivo ili funkcije i dva simetrična ključa utvrđuju da li se s druge strane zbilja nalazi banka, a ne lažna banka. Detaljni opis generiranja simetričnih ključeva nalazi se uz prethodni opis poruka m_6a i m_15a.

Ostale faze protokola sa slike 3.3 svode se na korake sa slike 3.2, dakle na kriptografski zaštićenu komunikaciju po koracima sa slike 3.2.

3.4.3 Mogući napadi i obrane

Ako treća strana može prisluškivati komunikaciju između dvije strane te ju želi samo ometati, to joj je uvijek omogućeno. Dakle umjesto poruke koja je na putu od jedne strane ka drugoj, treća strana može spomenutu poruku modificirati i dalje ju pustiti prema cilju, može ju ukloniti s njenog puta ili poslati novu poruku umjesto izvorne, ili jednostavno izmisliti poruku i poslati ju postojećem cilju iako nikakva poruka nije namijenjena tom cilju. Bar jedna od spomenutih operacija je moguća bez obzira na kriptografske metode koje se koriste u komunikaciji. Rezultat takvog napada je, ovisno o robusnosti sustava koji se napada, ometanje pravilnog funkcioniranja sustava. U pravilu, takvim ometanjem ne bi se trebala činiti ozbiljnija šteta, uglavnom se usporava rad sustava koji se ometa. Na primjer, započeta transakcije se tjekom izvršavanja ometa te ju je potrebno ponoviti. Problem se rješava tako da se onemogući bilo kakvo prisluškivanje od neželjene treće strane. U Internetu, tako nešto je nemoguće.

Najgore što se može dogoditi je da tajni ključ asimetričnog kriptosustava neke osobe u komunikaciji bude otkriven. U daljnjem razmatranju takav slučaj se neće uzimati u obzir jer cjelokupni trud bilo kakve kriptografske zaštite koji se temelji na asimetričnom kriptosustavu pada u vodu.

Autentifikacijski protokol iz poglavlja 2.6 savršeno funkcionira, osim u slučaju ometanja.

SSL protokol je sam po sebi siguran, što se može vidjeti iz njegova naziva i iz njegova opisa. Stoga je i princip zaštite koji je opisan u prethodnom poglavlju, a koji se temelji na principu rada SSL-a, siguran.

Napadi koji se temelje na računu kojeg trgovac šalje kupcu, i na lažnom predstavljanju trgovca, bit će opisani u sljedećem poglavlju.

U slučaju da se umjesto banke, u 5. ili 14. koraku sa slike 3.3, predstavi lažna banka, već se u sljedećem koraku otkriva pokušaj napada. Detaljniji opisi vezani uz spomenute korake, odnosno opis obrane napada, nalazi se u prethodnom poglavlju.

Rezultat lažnog predstavljanja kupca opisan je u jednom odlomku pred kraj prethodnog poglavlja.

Ako treća strana pokuša napad s kopiranom porukom iz neke od prethodnih transakcija, komunikacija se odmah odbija jer se u svakoj novoj transakciji generiraju novi simetrični ključevi te se izvorne poruke kriptiraju s tim novim ključevima. Na taj način, određena poruka kriptirana simetričnim ključem u jednoj transakciji nije jednaka poruci iz istog koraka u drugoj transakciji iako se možda kupuje identična roba kod istog trgovca.

4. Simulacija postupka plaćanja elektroničkim novcem

4.1 Opis simulacije

U ovom poglavlju opisana je programska implementacija simulacije sustava plaćanja elektroničkim novcem. Cijela simulacija može se grubo podijeliti na dva dijela. Prvi dio zastupljen je web stranicama Elektroničke trgovine[22] i odgovarajućom programskom podrškom istih te vizualizacijom postupka plaćanja elektroničkim novcem. Drugi dio simulacije odnosi se na programsku podršku u “pozadini”, a predstavlja četiri programska modula koja simuliraju kriptografski zaštićen konačni oblik protokola plaćanja elektroničkim novcem. Točnije, tri modula, kupac, banka i autentifikacijski server, simuliraju, dok je jedan, trgovac, implementiran kao dio pravog sustava plaćanja elektroničkim novcem. Svi moduli i programska podrška web stranicama isprogramirani su za Linux i Solaris operacijski sustav.

4.1.1 Web stranice

Web stranice koje su dio simulacije postupka plaćanja elektroničkim novcem, također su, na neki način, simulacija web stranica elektroničke trgovine, odnosno trgovca, koje bi se koristile u pravom sustavu plaćanja elektroničkim novcem.

Početna stranica sastoji se od dva okvira[23], lijevog i desnog. U lijevom okviru nalaze se bitni linkovi, ID trgovca i e-mail adresa trgovca, dok se u desnom okviru nalazi, kod prvog učitavanja, web stranica Elektroničke trgovine. Desni okvir također prima stranice e-banke i uputstva/pomoći.

Prvi od tri linka prikazana u lijevom okviru je e-trgovina i pokazuje na web stranicu same elektroničke trgovine otkuda se pokreće transakcija. Link e-banka pokazuje na stranice banke, u ovom slučaju na stranicu koja daje kratki opis banke i njenih funkcija. Treći link je link na uputstvo o korištenju web stranica Elektroničke trgovine.

Stranica elektroničke trgovine s koje se pokreće transakcija i koja se postavlja kod prvog poziva stranice Elektroničke trgovine, sastoji se od dva bitna dijela. Prvi dio predstavlja područje koje popunjava kupac, a odnosi se na podatke računala na kojem se nalazi program na strani kupca, dakle modul kupca. Ti podaci su potrebni da bi se modul trgovca mogao u transakciji spojiti na modul kupca. U slučaju ove simulacije, sva četiri programska modula nalaze se na istom računalu. Spomenuti podaci su simboličko ime ili IP adresa tog računala i broj porta na kojem modul kupca očekuje transakcije. Da bi se postupak simulacije plaćanja elektroničkim novcem mogao pokrenuti, prisutnost spomenutih podataka je nužna.

Drugi dio stranice predstavlja tablicu u kojoj se nalaze svi artikli elektroničke trgovine koji su na raspolaganju. Artikli mogu biti u elektroničkom obliku, dakle datoteke, ili materijalni, dakle opipljivi. Ako se radi o elektroničkoj robi koja ne zauzima puno prostora na disku, prijenos robe obavlja se kao dio protokola opisanog u poglavlju 3.4. Ostala roba prenosi se do kupca na dogovoreni način, ovisno o tome tko implementira sustav plaćanja elektroničkim novcem. Svaki artikl u tablici ima svoj naziv, kratki opis, cijenu, šifru te polja za odabir pojedinog artikla i količinu istog artikla.

Da bi se postupak simulacije mogao pokrenuti, potrebno je odabrati barem jedan artikl u količini od barem jednog komada. Nakon pritiska na gumb s oznakom Kupi proizvod(e), postavlja se stranica predračuna. Time je simulacija postupka plaćanja elektroničkim novcem službeno započela, ali još je moguće predomisliti se i povući iz postupka kupnje odabranih artikala. To se može ostvariti pritiskom na strelicu sa za povratak na glavnu stranicu.

Web stranica predračuna sastoji se od tri dijela. U prvom dijelu nalaze se podaci računala na kojem se nalazi program na strani kupca. U drugom dijelu nalazi se tablica s odabranim artiklima koja izgleda kao na primjeru sa slike 4.1. Ispod tablice ispisan je ukupan iznos odabranih artikala u protuvrijednosti elektroničkog novca. Treći dio sadrži podatke za program na strani kupca da bi mogao prihvatiti sljedeću transakciju. Točnije, radi se o već spominjanom računu kojeg trgovac generira prije nego što kupac nepovratno prihvati transakciju kupnje. Slika 4.2 ilustrira primjer jednog takvog računa namijenjenog kupcu.

Prvi redak teksta računa sa slike 4.2 predstavlja identifikacijsku oznaku trgovca. Drugi redak pokazuje ukupni iznos odabranih artikala u protuvrijednosti elektroničkog novca. Svaki sljedeći redak sadrži količinu, cijenu i šifru odabranih artikala iz tablice sa slike 4.1. Predstavljeni račun namijenjen je kupcu korisniku da ga na neki način, na primjer postupkom copy & paste, prebaci do programske podrške kupca u datoteku racun.txt. Način na koji će to korisnik obaviti ostavljen je na izbor prilikom implementacije pravog sustava plaćanja elektroničkim novcem. U ovoj simulaciji, predstavljeni tekst računa prenosi se ručno tako da se korisnik prvo logira na linux/unix operacijski sustav gdje se nalazi program na strani kupca te spomenutim postupkom copy & paste unese tekst računa u datoteku račun.txt. Opis potrebe za računom na strani programskog modula kupca bit će detaljnije opisan u sljedećem poglavlju.

Pritiskom na strelicu s kojom se prihvaća kupnja proizvoda nepovratno se pokreće transakcije kupnje odabranih proizvoda. Nakon što se transakcija uspješno ili neuspješno završi, postavlja se stranica s obavijesti o završetku transakcije plaćanja elektroničkim novcem.

Od spomenute programske podrške opisanim web stranicama, koriste se dvije CGI skripte. To su dva izvršna programa koja kao ulazne argumente uzimaju podatke koje im pošalje web pretraživač, a kao rezultat generiraju određene web stranice na temelju primljenih podataka.

Jedna CGI skripta generira stranicu predračuna na temelju glavne stranice elektroničke trgovine otkud kupac pokreće transakciju pritiskom na gumb s oznakom Kupi proizvod(e). Druga CGI skripta nepovratno pokreće ostatak transakcije kupnje odabranih proizvoda i, na kraju, generira stranicu s obavijesti o završetku transakcije plaćanja elektroničkim novcem.

Prilikom dolaska neke od web stranica od strane web poslužitelja do pretraživača na strani kupca, moguće je da se u komunikaciju umiješa treća strana. Kao što je opisano u poglavlju 3.4.3, treća strana može modificirati poruku, u ovom slučaju web stranicu koja je na putu između dvije strane u komunikaciji. Na taj način može se promijeniti izgled bilo koje od spominjanih web stranica, pa tako i stranice predračuna. Mogućnosti su brojne. Treća strana može promijeniti, na primjer, izgled računa sa slike 4.2 u svoju korist. Može navesti svoje podatke umjesto onih koje je generirala CGI skripta predračuna. Nepažnjom kupca, može se dogoditi da kupac nepovratno nastavi transakciju u koju bi se opet umiješala treća strana. Dakle umjesto modula trgovca, predstavio bi se lažni modul trgovca ili treća strana koja se onda može uključiti u ostatak transakcije sve dok ne primi potpisani elektronički novac i polovice identifikacijskih nizova sve do 12. koraka sa slike 3.3 uključujući 12 korak. Tada bi kupac ostao pokraden, ali bi identitet treće strane bio otkriven jer bi se u prvom koraku sa slike 3.3 morala identificirati autentifikacijskim postupkom. Da li bi se na kraju istjerala pravda, pitanje je. U svakom slučaju, ako bi se simulacijske stranice ovog diplomskog rada htjele iskoristiti u pravom sustavu plaćanja elektroničkim novcem, ili ako bi stranice pravog sustava funkcionirale na sličan način, na primjer preko CGI skripti, web poslužitelj, na čijoj strani se nalaze stranice elektroničke trgovine, odnosno trgovca, i web pretraživač korisnika kupca morali bi podržavati SSL protokol opisan u poglavlju 2.7. U tom slučaju, uz implementiran kriptografski zaštićen protokol plaćanja elektroničkim novcem, cijela transakcija, od njenog
početka na web stranici elektroničke trgovine, bila bi 100 % sigurna.

Vizualizacija, odnosno pojedini događaji i tjek poruka kriptografski zaštićenog protokola plaćanja elektroničkim novcem, također je prikazana web stranicom. Na zasebnoj web stranici aktivira se pet appleta[24]. Četiri od tih pet appleta prikazuju događaje i tjek poruka od četiri programska modula koja simuliraju kriptografski zaštićen konačni oblik protokola plaćanja elektroničkim novcem, odnosno spomenute programske podrške koja “radi u pozadini”. Spomenuti appleti izgledaju kao na primjeru sa slike 4.3.

Prvo što se ispiše u nadgledničkom appletu je poruka o obavijesti da je isti spojen na odgovarajući programski modul. Komunikacija svih appleta i programskih modula na koje su spojeni uspostavljena je preko utičnica. Sljedeća poruka sa slike 4.3 predstavlja komentar ili zbivanje unutar predstavljenog modula. Karakterizira ju početni string <<>>. Svaka poruka koja počinje s Mx, gdje x predstavlja broj od 1 do 17, predstavlja poruku sa slike 3.3. Poruke koje počinju s Ax, gdje je x broj od 1 do 5, predstavljaju korake autentifikacijskog protokola sa slike 2.6. Dakle nadgledničkim appletima prati se i postupak autentifikacije sudionika transakcije jer je prisutan i applet koji predstavlja autentifikacijski server. Na kraju svake od zadnje dvije opisane poruke nalazi se strelica koja simbolizira da predstavljeni modul šalje ispisanu poruku nekom drugom modulu. Poruka sa strelicom na početku znači da je predstavljeni modul primio poruku, bilo Mx ili Ax, od nekog drugog modula.

Jedini zadatak opisanog appleta je ispis poruke koju primi od modula na kojeg se spojio.

Da bi se moglo pratiti koji modul od kojeg prima poruku, brine se peti applet koji se nalazi u sredini, između prva četiri. Ovaj appelt spaja se na sva četiri modula i vizualizacijom pokazuje smjer poruka prema slici 3.3 i 2.6. Crne strelice određuju smjer poruka između dva appleta koja predstavljaju programske module u simulaciji. Strelice se crtaju na temelju poruka koje im šalje pojedini modul.

Vizualizacijska stranica može se pokrenuti na više mjesta istovremeno. Drugim riječima, jednu simulaciju postupka plaćanja elektroničkim novcem može pratiti više ljudi na više različitih mjesta istovremeno.

4.1.2 Četiri programska modula

Četiri programska modula predstavljaju trgovca, kupca, banku i autentifikacijski server. Svaki programski modul može se parametrizirati iz naredbene linije, odnosno prompta, i iz konfiguracijske datoteke. Više o parametrizaciji u sljedećem poglavlju. Kao što je već spomenuto, modul trgovca je implementiran kao za pravi sustav plaćanja elektroničkim novcem, dok ostali moduli simuliraju ostale sudionike sustava i udovoljavaju potrebama modula trgovca koji se ponaša kao da je u pravom sustavu. Na taj način simulirani moduli isprogramirani su nešto više nego samo za običnu simulaciju. To znači da, na primjer, koraci usmjereni prema modulu trgovca zapravo nisu simulirani već udovoljavaju modulu trgovca te su na taj način u potpunosti implementirani. Zbog kompleksnosti cijele simulacije i modula trgovca okruženog simuliranim modulima, situacija koja može biti posljedica neželjenog prekida komunikacije trgovca i kupca, a u slučaju isplaćenog elektroničkog novca kupca bez primljenog odgovora o isporuci robe (korak m₁₇) u mogućoj implementaciji cijelog sustava plaćanja elektroničkim novcem potrebno je izgraditi mehanizam oporavka od prekida komunikacije. Opisana potreba odnosi se na isporuku isplaćene robe kupcu na alternativni način. Spomenuti problem te općenito problemi vezani uz transport kupljene robe potrebno je rješavati u okviru rješenja implementacije cijelog sustava plaćanja elektroničkim novcem.

Vizualno si možemo predočiti interakciju svih modula slikom 3.3 uz dodatak autentifikacijskog servera. Komunikacija između modula uspostavljena je također utičnicama. Svi moduli izvršavaju se na jednom računalu, na istom na kojem se nalaze web stranice Elektroničke trgovine.

Na svaki od modula može se spojiti jedan ili više nadgledničkih i vizualizacijskih appleta.

Simulacija sustava plaćanja elektroničkim novcem tako je isprogramirana da može simulirati istovremeno više od jednog postupka plaćanja elektroničkim novcem. U tom slučaju, vizualizacija više nije vjerodostojna jer služi za prikaz događaja i tjek poruka samo jedne simulacije postupka plaćanja.

4.2 Parametrizacija programa simulacije

Da bi se uopće mogli pokrenuti programi koji predstavljaju sudionike sustava plaćanja elektroničkim novcem, potrebno je prevesti izvorne kodove istih. Za to je dovoljno otkucati naredbu make linux ili make solaris, ovisno na kojem sustavu radite, u direktoriju s izvornim kodovima diplomskog rada. Potom je potrebno kopirati web stranice, CGI skripte i konfiguracijske datoteke koje se nalaze u cgi direktoriju u odgovarajuće direktorije u kojima ih prepoznaje web poslužitelj.

Svaki program iz simulacije koristi jednu ili više konfiguracijskih datoteka[25]. Sve konfiguracijske datoteke i datoteke s javnim i tajnim ključevima nalaze se u istom direktoriju u kojem se nalazi program koji ih koristi. Oblik retka konfiguracijske datoteke ima tri mogućnosti. Jedna mogućnost je prazan redak koji se kod parsiranja ignorira. Drugi oblik retka je [tekst komentara; tekst odjeljka] i predstavlja komentar ili oznaku odjeljka u datoteci artikli.ini. Treći oblik retka je ime parametra=vrijednost parametra. Razmaci su dozvoljeni s obje strane jednakosti.

Konfiguracijske datoteke CGI skripta su artikli.ini i trgovina.ini. Datoteka artikli.ini sadrži broj artikala elektroničke trgovine i popis vrijednosti koje popunjavaju redak tablice glavne stranice Elektroničke trgovine za svaki artikl. Sljedi primjer početka datoteke koji uključuje broj artikala i popis vrijednosti retka tablice za prvi artikl:

broj=6

[artikl 1]

sifra=123

cijena=5.00

naziv=Zemlja iz orbite

opis=Slika u jpeg formatu, predstavlja sliku Zemlje iz orbite snimljenu satelitom; podrucje Juzne i Sjeverne Amerike; rezolucija 1024x768; 24 bita

kolicina=20

file=earth.jpg

Vrijednost svakog parametra proteže se kroz jedan redak datoteke. Dodatni parametri su količina i file. Parametar količina govori CGI skripti koja generira predračun, kolika je najveća dozvoljena prodajna količina pojedinog artikla. Parametar file označava ime datoteke elektroničke robe koja će se prenositi preko Interneta u slučaju da je netko kupi. Ako se radi o materijalnoj robi, dakle artiklu koji se ne prenosi preko Interneta, parametar file ima vrijednost no.

Konfiguracijska datoteka trgovina.ini sadržava parametre iz tablice 4.1.

Ime parametra	Opis parametra
id	identifikacijska oznaka trgovca
url	url računala na kojem je e-trgovina
cgi	putanja do cgi skripte od osnovnog direktorija /
html	putanja do web stranica od osnovnog direktorija /
port	broj porta modula trgovca
hostname	ime računala na kojem je e-trgovina
timeout	prisutnost timeouta (yes / no)
public	ime datoteke s javnim ključem trgovca
artikli	najveći broj artikala u trgovini

Tablica 4.1: Parametri datoteke trgovina.ini

Svaki od četiri programska modula imaju mogućnost primanja parametara u naredbenoj liniji. Tablica 4.2 objašnjava spomenute parametre.

Ime parametra	Opis parametra
-v	opširan ispis komentara
-b	pokreni program u pozadini
-f [ime_datoteke]	šalji ispis u datoteku (ime_datoteke)

Tablica 4.2: Parametri s naredbene linije

Konfiguracijske datoteke trgovca, kupca, banke i autentifikacijskog servera su, respektivno, trgovac.ini, kupac.ini, banka.ini i aserv.ini. Parametri koji su zajednički za prve tri datoteke su prikazani u tablici 4.3.

Ime parametra	Opis parametra
id	identifikacijska oznaka sudionika transakcije
port	broj porta računala na kojem se osluškuju konekcije
timeout	prisutnost timeouta (yes / no)
log	podrazumijevano ime datoteke s ispisom programa
private	ime datoteke s tajnim ključem sudionika transakcije
public	ime datoteke s javnim ključem sudionika transakcije
delay	vremenski razmak između dva koraka u vizualizaciji
ident	broj identifikacijskih nizova
identLen	duljina identifikacijskog niza
portAS	broj porta AS-a
hostnameAS	ime računala na kojem je pokrenut program AS
identPos	mjesto početka identificirajuće informacije na elektroničkoj novčanici

Tablica 4.3: Zajednički parametri za trgovca, kupca i banku

Bitno je dodatno napomenuti parametre ident, identLen i identPos. Spomenuti parametri karakteriziraju modul trgovca koji je implementiran kao dio pravog sustava plaćanja elektroničkim novcem, kao konfigurabilnog i prilagodljivog modula. Ako netko poželi promijeniti izgled elektroničke novčanice, dakle odluči se za drugačiji broj identifikacijskih nizova iz kojih će biti građena identificirajuća informacija, ili za drugačiju duljinu spomenutog identifikacijskog niza ili za drugačiju poziciju identificirajuće informacije na elektroničkoj novčanici, slobodno to može učiniti konfiguriranjem tri spomenuta parametra te će modul trgovca dalje funkcionirati ispravno.

Konfiguracijska datoteka trgovac.ini i kupac.ini sadrži dodatne parametre.

Ime parametra	Opis parametra
racun	broj računa u banci / ime datoteke s računom
novcanica	veličina elektroničke novčanice
artikli	najveći broj artikala u elektroničkoj trgovini
publicB	ime datoteke s javnim ključem banke
portBanka	broj porta banke
hostnameBanka	ime računala na kojem je pokrenut program banke

Tablica 4.4: Zajednički parametri za trgovca i kupca

Prvo značenje parametra racun iz tablice 4.4 odnosi se na trgovca, drugo na kupca. Ime datoteke računa koje je parametar kupca, predstavlja datoteku u koju se posprema teksta računa koji je opisan u poglavlju 4.1.1. Programskom modulu kupca potreban je tekst računa prije nego se nepovratno pokrene transakcija sa stranice predračuna tako da bi isti modul bio siguran, kada primi račun od trgovca u poruci m₃ sa slike 3.3, kako je primio račun kojega je vidio i kupac osoba na stranicama elektroničke trgovine. Razlog tome je taj da trgovac ne bi podvalio krivi račun ili da se treća strana ne bi umiješala sa svojim računom i obavila transakciju dok ne primi potpisan elektronički novac. Stoga, dok modul kupca ne provjeri račun koji mu šalje trgovac, ne mogu se primati nove transakcije kupovanja. Nakon što se račun provjeri, datoteka s računom prazni na veličinu 0 karaktera. To je znak da podvala transakcije od treće strane koja glumi trgovca ne može proći jer ne postoji prethodno unesen račun. Dakle kupac može istovremeno kupovati na više mjesta, ali tek nakon što se isprazni datoteka s tekstom računa.

Programski modul autentifikacijskog servera koristi parametre iz konfiguracijske datoteke aserv.ini. Parametri su sadržani u tablici 4.5.

Ime parametra	Opis parametra
port	broj porta računala na kojem se osluškuju konekcije
log	podrazumijevano ime datoteke s ispisom programa
delay	vremenski razmak između dva koraka u vizualizaciji
xxxxxxx	umjesto xxxxxxxx dolazi id sudionika sustava; s desne strane jednakosti nalazi se ime datoteke s javnim ključem sudionika

Tablica 4.5: Parametri autentifikacijskog servera

S obzirom na navedene parametre, simulacija sustava plaćanja elektroničkim novcem dosta je konfigurabilna, pogotovo implementirani modul trgovca koji se može ugraditi, uz minimalne preinake, u potencijalni sustav plaćanja elektroničkim novcem. Slično vrijedi za web stranice i programsku podršku istih, odnosno CGI skripte.

4.3 Programska implementacija

Općeniti opis programske izvedbe simulacije može se svesti na objektno orijentirano programiranje, konkretno na C++ programski jezik.

CGI skripte i četiri programska modula isprogramirani su za Linux odnosno Solaris operacijski sustav. Stoga je kod prevođenja kompletnog izvornog koda u glavnom direktoriju koda simulacije potrebno napisati make linux ili make solaris. Sav izvorni kod organiziran je po direktorijima od kojih svaki sadrži svoj Makefile. U glavnom direktoriju nalazi se glavni Makefile. Alati koji su se koristili za prevođenje izvornog koda su GNU-ov C++ prevodilac g++ i GNU make. Preporuča se korištenje istih za svako novo prevođenje izvornog koda simulacije.

Veliki dio programskog koda prevodi se u objektne datoteke jer se u njima nalaze brojni razredi[26] i pripadajući im postupci ili metode. Te datoteke se kasnije koriste kod prevođenja izvršnih programa radi korištenja spomenutih razreda i metoda. Na neki način, objektne datoteke predstavljaju statičke biblioteke.

Od bitnijih razreda koji se koriste od strane CGI skripti, a kasnije i od nekih modula simulacije, predstavljeni su cArticle i cParseArticles.

struct cArticle {

cArticle() : sifra(0), cijena(0.0), Naziv(""), Opis(""), kolicina(0), File("") {}

int sifra;

double cijena;

string Naziv;

string Opis;

int kolicina;

string File;

};

class cParseArticles {

public:

cParseArticles(const char *); //prima ime datoteke s popisom artikala

~cParseArticles();

cArticle *getArticle(int); //prima sifru artikla

cArticle *getArticle1(int); //prima indeks artikla u polju

int getNumArticles();

private:

void splitLine(const char *, string &, string &);

cArticle *Articles;

int numArticles;

};

cArticle je razred (struktura) koji se koristi od strane razreda cParseArticles, ali je također dostupan i izvršnim programima zbog potrebe koja proizlazi iz povratnih vrijednosti metoda getArticle i getArticle1. Razred cParseArticles, točnije njegov konstruktor, parsira datoteku artikli.ini te posprema sve artikle u dinamički zauzetu memoriju Articles s obzirom na broj artikala elektroničke trgovine koji se nalazi na početku artikli.ini.

Sljedeći bitni razred ili grupa razreda u hijerarhiji nasljeđivanja su razredi koji uključuje operacije nad utičnicama. Prvi i osnovni razred je cSocket:

class cSocket {

public:

virtual ~cSocket() { closeSock(); }

int getSock() { return sock; }

void setSock(int _sock) { sock=_sock; }

void closeSock() { close(sock); }

virtual int _read1(char *, int, bool);

virtual int write1(const char *, int);

virtual int read1(cProperties &, bool, char *, int);

virtual int read1(cProperties &, bool, cRsa &, char *, int);

virtual int read1(cProperties &, bool, cDes &, char *, int);

int select1(long);

protected:

int sock;

};

Razred cSocket predstavlja jednostavni razred za čitanje i pisanje s već otvorenim utičnicama. Kao što se može vidjeti u sučelju razreda, implementirana je nova read metoda pod imenom read1 i to osobinom prekrivanja[27] u tri nova oblika. Ono što je bitno reći u vezi ovog razreda je to da svaka poruka koja se treba pročitati s jednom od spomenute tri metode u sebi uključuje zaglavlje u kojem piše koliko je poruka dugačka. Ako je primljena poruka kriptirana RSA kriptografskim sustavom, prvo se dekriptira prvi blok RSA zakriptirane poruke koji je dugačak onoliko koliko je dugačak broj n iz formule 2.1. Prva sizeof(int) karaktera dekriptirane poruke predstavljaju cijeli broj tipa integer koji govori kolika je ukupna duljina nadolazeće kriptirane poruke uključujući i dektriptirani blok. Ako netko skrati ili produlji poruku, dolazi do pogreške u komunikaciji. Ovom osobinom osigurana je još jedna razina zaštite u kriptografski zaštićenom obliku protokola plaćanja elektroničkim novcem. Slična je metoda kod čitanja poruke kriptirane DES kriptosustavom. Razilka je u tome što se, nakon dekriptiranja prvog bloka kriptirane poruke, dobiva ukupna duljina nekriptirane poruke bez zaglavlja. Na temelju toga izračunava se ukupna duljina kriptirane poruke sa zaglavljem. Neposredno nakon sizeof(int) karaktera dekriptirane poruke, bilo RSA ili DES, slijedi jedan karakter koji predstavlja broj poruke koja se prima. Taj broj je zapravo jedan od brojeva koji dolazi uz poruke sa slike 3.3 i nema, trenutno, neke praktične svrhe u simulaciji, ali može biti od koristi u eventualnoj nadogradnji sustava na postojećeg implementiranog trgovca.

Sljedeći razred koji nasljeđuje cSocket je cConnect i predstavlja razred kojim se ostvaruje veza spajanja jedne strane u komunikaciji, preko utičnice, na drugu stranu. To ujedino predstavlja jedinu razliku u odnosu na prethodno opisani razred.

Drugi razred koji nasljeđuje cSocket je cServ. Taj razred implementira uslugu posluživanja spajanja na utičnicu. Dakle program koji koristi objekt razreda cServ očekuje da se drugi programi spajaju na njega i to korištenjem instance razreda cConnect.

Sljedeća bitna skupina razreda su razredi enkripcije/dekripcije. U programskoj implementaciji trgovca korišteni su RSA, DES i MD5 kriptoalgoritmi. Programska implementacija spomenutih kriptoalgoritma korištena je iz OpenSSL biblioteke koja sadrži sve bitne kriptosustave, njihove implementacije u SSL protokolu, funkcije za generiranje slučajnih brojeva itd. S obzirom na ponuđene RSA i DES funkcije implementirane u C programskom jeziku, kao dio programske implementacije simulacije nastali su razredi cRsa i cDes.

class cRsa {

public:

cRsa() : flag(false) {}

cRsa(const char *, bool);

~cRsa();

int init(const char *, bool);

int encrypt(char *, int, char *, int &);

int decrypt(char *, int, char *, int &);

int sizeofED(int); //rezultat se ubacuje na pocetak poruke

int KeySize();

int Sign(char *, int, char *);

int Verify(char *, int, char *);

};

class cDes {

public:

cDes();

cDes(char *, int);

int KeyGet(char *);

void KeyGet1(char *);

int KeySet(char *);

int sizeofED(int); //rezultat se koristi za de/encrypt

int encrypt(char *, char *, int);

int decrypt(char *, char *, int);

};

Private dijelovi razreda su izbačeni jer predstavljaju varijable koje koriste metode sučelja te nisu od važnosti za objašnjenje istih. Neke metode navedenih sučelja razreda dovoljno govore svojim imenima. Stoga će biti objašnjen dio navedenih metoda.

Metoda int cRsa::init(const char *, bool) učitava ključ iz datoteke prvog argumenta, dok drugi argument govori o kojem se ključu radi, javnom ili tajnom. int cRsa::sizeofED(int) vraća duljinu kriptirane poruke s obzirom na duljinu nekriptirane poruke koju predstavlja argument metode. Vraćeni broj upisuje se u odgovarajuće zaglavlje poruke prije njenog kriptiranja odnosno slanja. Metoda int cRsa::Sign obavlja digitalni potpis koji je implementiran RSA kriptiranjem tajnim ključem u skladu sa osobinama slijepog potpisa. Metoda int cRsa::Verify obavlja provjeru potpisane poruke. int cRsa::KeySize vraća veličinu RSA ključa predstavljenog objektom razreda cRsa.

Metoda int cDes::getKey generira ispravan DES ključ i sprema ga u sam objekt, dok ista funkcija sa sufiksom 1 vraća ključ pospremljen u objektu razreda cDes. int cDes::KeySet postavlja ključ iz argumenta kao važeći ključ objekta, s tim da se ključ prethodno provjerava da li je valjan, odnosno da nije slabi ključ. Ostale metode razreda cDes slične su onima iz razreda cRsa.

Ostali značajniji razredi su cProperties, cRacunParse i sArgsAll. Prvi razred objedinjuje sve metode za rad s konfiguracijskim datotekama i parametrima koji se učitavaju iz tih datoteka. Drugi navedeni razred parsira račun kojeg trgovac šalje kupcu u poruci m₃ sa slike 3.3 i račun kojeg kupac prethodno čita iz datoteke. Razred sArgsAll je struktura koja se koristi za prenošenje argumenata novokreiranoj dretvi. Više o dretvenosti simulacije nešto kasnije. Neki moduli nasljeđuju taj razred da bi njegovim proširivanjem dodali dodatne argumente za prosljeđivanje dretvi.

Iako je modul trgovca implementiran kao za pravi sustav plaćanja elektroničkim novcem, ostali moduli se, po svom funkcioniranju na razini operacijskog sustava, ne razlikuju puno od modula trgovca. Dakle sva četiri modula simulacije podržavaju višedretvenost, odnosno mogu istovremeno izvršavati više od jedne dretve, odnosno obavljati više od jedne funkcije koja im je namijenjena. Modul trgovca ispisuje dodatne poruke na terminal kojima se može pratiti tjek transakcije. Svaki ispis može se, parametriranjem, preusmjeriti u odgovarajuću datoteku. Svaki modul ima ugrađen mehanizam prihvaćanja konekcija od strane appleta kojima se onda šalju odgovarajuće tekstualne poruke. Svaki modul može primati više od jednog appleta za vizualno praćenje transakcije.

Predefinirane vrijednosti koje se koriste u svim programima simulacije definirane su u datoteci global.h.

5. Zaključak

Konačni oblik protokola plaćanja elektroničkim novcem, prihvatljivog za kupca, trgovca i banku, enkapsuliran je unutar kriptografske zaštite od mogućih prisluškivanja i napada neželjenih promatrača. Na taj način rješeno je pitanje sigurnosti postupka plaćanja elektroničkim novcem. Rezultat praktičnog dijela rada je simulacija postupka plaćanja elektroničkim novcem te funkcijska implementacija konfigurabilnog modula trgovca kao dijela sustava plaćanja elektroničkim novcem. Simulacijom je pokazano ispravno funkcioniranje zaštićenog protokola te je rezultat ovog diplomskog rada dobar temelj za implementaciju sustava plaćanja elektroničkim novcem.

Objektno orijentirani pristup izradi cijele simulacije, osobinama preglednosti koda i jednostavnošću ponovne iskoristivosti, te ugrađena višedretvenost, dodatno idu u prilog mogućem proširenju simulacije na pravi sustav plaćanja elektroničkim novcem.

6. Popis literature

[1] B. Schneier, Applied Cryptography Second edition, John Wiley & Sons Inc., 1996.

[2] -, SSLeay Documentation, dostupno na Internet adresi: http://www.di.unito.it/~rabser/ssleay/, lipanj 2000.

[3] -, Miscellaneous OpenSSL Documents, The OpenSSL Project, dostupno na Internet adresi: http://www.openssl.org/docs/, lipanj 2000.

[4] -, Explain ssl to me, SSL.com, dostupno na Internet adresi: http://www.ssl.com/n_explainA.htm, kolovoz 2000.

[5] -, DES algoritam kriptiranja podataka, upute za laboratorijske vježbe iz Operacijskih sustava 2, dostupno na Internet adresi: http://www.zemris.fer.hr/labosi/os2/des.html, lipanj 2000.

[6] -, eCash, Electronic payment solution, eCash Technologies, Inc., dostupno na Internet adresi: http://www.digicash.com/, lipanj 2000.

[7] -, What Do I Need To Set Up An ecash Shop?, 1994-1997 Digicash Inc., dostupno na Internet adresi: http://www.digicash.com/ecash/docs/ShopSet(23G).pdf, ožujak 1999.

[8] -, An Introduction to How ecash Works, 1994-1997 Digicash Inc., dostupno na Internet adresi: http://www.digicash.com/ecash/docs/Works(23G).pdf, ožujak 1999.

[9] Dokumentacija projekta E-grupe RASIP, dostupno na Internet adresi: http://www.rasip.fer.hr/research/ecash/broshura/broshura.htm, ožujak 1999.

[10] B. Mutik, J. Šribar, Demistificirani C++, Element, Zagreb, 1997.

SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

DIPLOMSKI RAD br. 1219

ZAŠTITA PODATAKA PRILIKOM PLAĆANJA ELEKTRONIČKIM NOVCEM

Dubravko Gorupić

Zagreb, rujan 2000.

Sadržaj

1. Uvod.. 1

2. Kriptografski algoritmi i protokoli. 2

2.1 Uvodno razmatranje. 2

2.2 RSA 3

2.3 DES 5

2.4 MD5. 7

2.5 Digitalni potpis. 10

2.6 Autentifikacijski protokol. 12

2.7 SSL protokol. 13

2.7.1 Općenito o SSL protokolu. 13

2.7.2 Princip rada. 14

2.7.3 Opis SSL protokola. 15

3. Protokoli plaćanja elektroničkim novcem... 17

3.1 Osnovni protokoli 17

3.1.1 Protokol bez anonimnosti 17

3.1.2 Protokol s anonimnošču. 19

3.2 Konačni oblik protokola.. 20

3.3 Zaštitni mehanizmi 23

3.3.1 Digitalni potpis. 23

3.3.2 Slijepi potpis. 23

3.3.3 Identificirajuća informacija. 24

3.3.4 Postupak dijeljenja tajne. 26

3.4 Kriptografski zaštićen konačni oblik protokola.. 26

3.4.1 Uvod. 26

3.4.2 Opis. 28

3.4.3 Mogući napadi i obrane. 35

4. Simulacija postupka plaćanja elektroničkim novcem... 36

4.1 Opis simulacije. 36

4.1.1 Web stranice. 36

4.1.2 Četiri programska modula. 40

4.2 Parametrizacija programa simulacije. 41

4.3 Programska implementacija.. 45

5. Zaključak.. 50

6. Popis literature.. 51

Zahvaljujem se mr. sc. Marinu Golubu na savjetima pri izradi ovog diplomskog rada te Davoru Krtiću na pomoći pri izradi vizualizacijske web stranice.

---

[1] engl. ecash, u ostatku diplomskog rada spominjat će se kao elektronički novac

[2] engl. customer

[3] engl. merchant

[4] pojam treća strana odnosi se na osobu koje se nalazi između dvije strane u komunikaciji i neovlašteno promatra ili sudjeluje u komunikaciji ili zloupotrebljava sadržaj komunikacije

[5] kratica dolazi od imena trojice ljudi koji su izumili kriptografski algoritam: Ron Rivest, Adi Shamir i Len Adleman

[6] kratica od engl. Data Encription Standard

[7] MD dolazi od engl. Message Digest, sažetak poruke

[8] engl. digest

[9] eng. chaining variables

[10] engl. Secure Sockets Layer

[11] engl. socket

[12] engl. Certificate Authority, CA

[13] korisnički certifikat zove se engl. Root Certificate

[14] certifikat poslužitelja zove se engl. Server Certificate

[15] engl. blind signature

[16] engl. blinding factor, prijevod preuzet iz [11]

[17] engl. double spending

[18] engl. selector string

[19] engl. secret splitting

[20] E(Xxxx, Y) predstavlja kriptiranu poruku. Xxxx je izvorna poruka koja se kriptira, Y je ključ kojim se kriptira. Simetrični ključ označen je velikim slovom K. Javni ključ označen je velikim slovom P. Tajni ključ označen je velikim slovom S. Uz svaku oznaku ključa nalazi se indeks koji govori kome ključ pripada.

[21] javni ključ banke P_banke poznat je svim kupcima i trgovcima

[22] Elektronička trgovina je ime elektroničke trgovine te se stoga piše velikim početnim slovom

[23] pojam okvir odnosi se na html tag <frame>

[24] java programi namijenjeni izvršavanju na web stranicama

[25] format svih konfiguracijskih datoteka sličan je formatu .ini windows datoteke, stoga i nose nastavak .ini

[26] engl. class, hrvatski razred, neki koriste izraz klasa

[27] engl. overloading, neki koriste izraz preopterećivnje