Sigurni sustav elektroničke pošte - sigurnost.zemris.fer.hrsigurnost.zemris.fer.hr/pki/2006_knezic/diplomski_rad.pdf · SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

SVEUČILIŠTE U ZAGREBUFAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

DIPLOMSKI RAD br. 1632

Sigurni sustav elektroničke pošteMladen Knežić

Zagreb, listopad 2006

Abstract. In this document are described techniques used to fight spam. It is explained usage of digital signature and authentication mechanisms inside public key infrastructure. It is developed system of e-mail server and client. System uses digital signature to authenticate sender and, by that, filter spam.

Sažetak. U ovom radu opisane su tehnike borbe protiv neželjene pošte. Opisana je upotreba digitalnog potpisa te autentifikacijski mehanizmi unutar infrastrukture javnog ključa. Razvijen je programski sustav poslužitelja elektroničke pošte i klijenta U sustavu se digitalni potpis koriste u svrhu autentifikacije pošiljatelja a time i filtriranja poruka neželjene pošte.

Sadržaj1 Uvod....................................................................................................................................12 Neželjena pošta...................................................................................................................2

2.1 Osnovni pojmovi................................................................................................................... 22.1.1 Poruka neželjene pošte......................................................................................................................22.1.2 Infrastruktura javnog ključa – PKI....................................................................................................22.1.3 Digitalni potpis..................................................................................................................................2

2.2 Statistički podaci................................................................................................................... 32.2.1 Korištenje elektroničke pošte............................................................................................................32.2.2 Neželjena pošta................................................................................................................................. 32.2.3 Zaključne procjene............................................................................................................................4

3 Tehnike borbe protiv neželjene pošte................................................................................ 53.1 Filtriranje............................................................................................................................... 5

3.2 Provjera identiteta pošiljatelja............................................................................................. 6

3.3 Provjera pošiljatelja.............................................................................................................. 6

3.4 Okosnica police pošiljatelja.................................................................................................. 7

3.5 Zaključak............................................................................................................................... 8

4 Digitalni potpis i njegova primjena................................................................................... 94.1 Postupak potpisivanja........................................................................................................... 9

4.2 PKI – infrastruktura javnog ključa................................................................................... 104.2.1 Ključevi...........................................................................................................................................104.2.2 Digitalni certifikat........................................................................................................................... 10

4.3 Autentifikacija pošiljatelja................................................................................................. 134.3.1 Protokol s jednom porukom............................................................................................................134.3.2 Protokol s dvije poruke................................................................................................................... 144.3.3 Protokol s tri poruke........................................................................................................................144.3.4 Odabrani model autentifikacije pošiljatelja.................................................................................... 144.3.5 Problem opozvanih certifikata........................................................................................................ 15

5 Korištene tehnologije....................................................................................................... 175.1 Eclipse RCP......................................................................................................................... 17

5.2 SWT...................................................................................................................................... 18

5.3 Spring framework............................................................................................................... 18

6 Poslužiteljski sustav elektroničke pošte.......................................................................... 196.1 Princip rada sustava............................................................................................................ 19

6.2 Komponente sustava........................................................................................................... 19

6.3 CA/RA poslužitelj................................................................................................................ 196.3.1 Dodatne izmjene poslužitelja.......................................................................................................... 216.3.2 Dodavanje korisnika....................................................................................................................... 246.3.3 Izdavanje i preuzimanje certifikata i ključeva................................................................................ 24

6.4 Poslužitelj pošte................................................................................................................... 266.4.1 Provjera digitalnog potpisa............................................................................................................. 276.4.2 Akcije poslužitelja...........................................................................................................................316.4.3 Konfiguracija pristupa CA/RA te bazi podataka............................................................................ 33

6.5 Baza podataka..................................................................................................................... 33

7 Programski sustav klijenta...............................................................................................347.1 Zadaće klijenta.................................................................................................................... 34

7.2 Sučelje klijenta.................................................................................................................... 35

7.3 Primjeri rada klijenta......................................................................................................... 377.3.1 Slanje pošte..................................................................................................................................... 377.3.2Primanje pošte..................................................................................................................................397.3.3 Postavke klijenta............................................................................................................................. 39

8 Zaključak..........................................................................................................................419 Literatura..........................................................................................................................42

Popis slikaSlika 3.1: Primjer captcha testa.............................................................................................. 7Slika 4.1: Prikaz digitalnog certifikata................................................................................. 11Slika 4.2: Detalji digitalnog certifikata................................................................................ 11Slika 4.3: Certifikacijski put.................................................................................................12Slika 6.1: Arhitektura EJBCA CA/RA poslužitelja............................................................. 20Slika 6.2: Java servlet koji odrađuje posao provjere certifikata...........................................22Slika 6.3: Konfiguracija servleta unutar web.xml datoteke................................................. 23Slika 6.4: Ekran za dodavanje korisnika.............................................................................. 24Slika 6.5: Generiranje ključeva i preuzimanje certifikata.................................................... 25Slika 6.6: Arhitektura JAMES-a.......................................................................................... 26Slika 6.7: Kod razreda SmailMatcherRejectUnsigned.........................................................27Slika 6.8: Kod razreda SmailMatcherRejectInvalid – dio 1.................................................29Slika 6.9: Kod razreda SmailMatcherRejectInvalid – dio 2.................................................30Slika 6.10: Konfiguracijska datoteka poslužitelja Apache JAMES, config.xml..................32Slika 7.1: Izgled sučelja klijenta...........................................................................................35Slika 7.2: Prikaz klijenta s otvorenom porukom.................................................................. 36Slika 7.3: Slanje poruke........................................................................................................37Slika 7.4: Programski kod digitalnog potpisivanja i slanja poruke......................................38Slika 7.5: Uređivač postavki korisnika.................................................................................39

Popis tablicaTablica 2.1: Statistika korištenja elektroničke pošte u 2004. godini......................................3Tablica 2.2: Statistika šteta od neželjene pošte...................................................................... 3

1 Uvod

U današnjem svijetu gdje se velika pažnja pridaje informacijama, vrlo je važno saznati pravu informaciju u pravo vrijeme. Isto tako je važno uočiti informaciju. Ukoliko smo zatrpani mnoštvom beskorisnih informacijama, nije moguće pronaći onu jednu ali korisniu informaciju.

Neželjena pošta (engl. spam) danas čini većinu komunikacije elektroničkom poštom. Korisnici elektroničke pošte pokušavaju se boriti protiv nje raznim tehnikama, a u pomoć im priskaču i njihovi pružatelji usluga koji sve više shvaćaju kako neželjena pošta i njima stvara štetu, ne samo zbog direktnih troškova u vidu zatrpanosti poslužitelja, smanjenja mrežne propusnosti, ... , nego i zbog gubitka povjerenja korisnika. Korisnici će radije koristiti usluge pružatelja usluga koji se brine za njih te sprečava neželjenu poštu.

U svrhu sprečavanja širenja neželjene pošte, u ovom radu je izrađen sustav, temeljen na postojećim sustavima elektroničke pošte te infrastrukture javnog ključa (engl. Public Key Infrastructure tj. PKI). Korištenjem tehnika i standarda infrastrukture javnog ključa razvijena je nadogradnja sustava elektroničke pošte, kompatibilna standardnim sustavima elektroničke pošte, koja omogućava uklanjanje neželjene pošte na siguran način, posve transparentno za korisnika.

Poslužiteljski dio razvijen je na osnovu postojećih, open-source sustava. Za poslužitelja elektroničke pošte odabran je Apache JAMES, a kao certifikacijsko/registracijsko tijelo (CA/RA) koristi se EJBCA, oboje open-source i slobodno dostupni.

Klijentski dio razvijen je samostalno poštujući norme za rad s elektroničkom poštom. Razvijen je korištenjem slobodno dostupne, open-source platforme za razvoj aplikacija naziva Eclipse RCP (engl. Rich Client Platform).

1

2 Neželjena pošta

2.1 Osnovni pojmovi

2.1.1 Poruka neželjene pošte

Iako se spam (engl. neželjena pošta1) prevodi kao poruka neželjene pošte, nije svaka neželjena pošta spam.

Poruka neželjene pošte se najlakše definira kao poruka elektroničke (u ovom slučaju, iako se može primjeniti i na klasičnu poštu) pošte kod koje su prekršena pravila ponašanja, u slučaju elektroničke pošte netiquette tj. pravila ponašanja na Internetu.

Poruke neželjene pošte se u novije vrijeme definiraju sve više kao poruke koje se šalju u većem broju, širem krugu primatelja bez da su to oni izravno ili neizravno (npr. davanjem svoje adrese) zatražili. Najčešće se radi o komercijalnim porukama, oglasima, prijevarama, elektroničkim virusima i sličnim.

2.1.2 Infrastruktura javnog ključa – PKI

Infrastruktura javnog ključa, PKI (public key infrastructure), definira povezivanje sustava i korisnika u smislu povezivanja javnog ključa i imena korisnika. Koristeći tehnike i standarde infrastrukture javnog ključa, može se jednostavnom, predloženom nadogradnjom klasičnog sustava elektroničke pošte smanjiti pojavu neželjene pošte.

2.1.3 Digitalni potpis

Digitalni potpis je elektronički ekvivalent klasičnog potpisa korisnika na dokumentu. Koristeći digitalni potpis i infrastrukturu javnog ključa moguće je, na siguran način, utvrditi identitet pošiljatelja poruke elektroničke pošte. Detaljnije o digitalnom potpisu i njegovoj primjeni u poglavlju 4.

1 poruka elektroničke pošte poslana širem krugu korisnika u svrhu stjecanja financijske koristi pošiljatelju

2

2.2 Statistički podaci

Koristeći statističke podatke objavljene na Internetu u obliku izvještaja i studija dolazi se do zastrašujućeg podatka da čak 60% elektroničke pošte čini neželjena pošta, koja pričinjava štetu primateljima (u vidu gubitka vremena, informacija, ...).

2.2.1 Korištenje elektroničke pošte

broj poruka poslanih po danu 31 000 000 000

broj poruka dobivenih u jednom danu na jednu adresu elektroničke pošte

56

broj poslanih poruka u jednom danu po osobi 174

broj adresa elektroničke pošte po osobi prosječno 3,1

troškovi svih internet korisnika 255 000 000 $

Tablica 2.1: Statistika korištenja elektroničke pošte u 2004. godini

Iz tablice 2.1 vidljivo je da elektronička pošta postaje važan dio komunikacije korištenjem Interneta. Veliki broj poslanih poruka te isto tako i primljenih poruka čini elektroničku poštu zanimljivom osobama koje na nepošten način, na štetu ostalih korisnika Interneta, pokušavaju ostvariti financijsku korist.

2.2.2 Neželjena pošta

postotak neželjene pošte od ukupnog broja poruka 60 %

broj poslanih poruka neželjene pošte po danu 12 400 000 000

toškovi čišćenja neželjene pošte za sve privatne korisnike 255 000 000 $

troškovi čišćenja neželjene pošte za sve poslovne korisnike u Americi (2002. godine)

8 900 000 000 $

procjenjen porast broja poruka neželjene pošte do 2009. godine 63 %

Tablica 2.2: Statistika šteta od neželjene pošte

U tablici 3.2, najvažniji podatak je činjenica da 60% ukupnog broja poruka elektroničke pošte sačinjavaju poruke neželjene pošte. Gledajući uz to i podatke iz tablice 3.1, dolazi se do zaključka kako je slanje poruka neželjene pošte unosan posao, čak i uz relativno mali postotak odgovora na takvu poruku. Nasuprot pošiljateljima takvih poruka nalaze se oni čiji je posao obrana korisnika od poruka neželjene pošte. Troškovi njihova rada rastu svakodnevno sa porastom broja poslanih poruka neželjene pošte koja će, prema procjenama, porasti za 63% do 2009. godine.

3

2.2.3 Zaključne procjene

Prema Robertu Mahowaldu, istraživačkom menadžeru IDC-a, tvrtka sa 14 000 zaposlenih godišnje troši 245 000 $ na borbu protiv neželjene pošte. Prema svim navedenim podacima, troškovi će rasti još više i još brže.

U Jupiter Communications procjenjuju da je ulaganje u poruke neželjene pošte, s ciljem dobivanja financijske koristi, iznosilo približno 7,3 milijardi $ 2005. godine.

Istraživanja Gartner Group govore da bi 36% korisnika promijenilo pružatelja internet usluga ako bi se time smanjio broj poruka neželjene pošte koju dobivaju. Isto tako, istraživanja govore da bi 24% korisnika bilo voljno financijski platiti takve usluge s ciljem sprečavanja poruka neželjene pošte.

Vodeći se navedenim podacima, dolazi se do zaključka kako je sprečavanje poruka neželjene pošte potrebno i opravdano, kako potrebama korisnika tako i sve većim porastom internet prometa te prometa poruka elektroničke pošte.

Očekivanja Rona Herardiana, glavnog sistemskog arhitekta u Global System Services, govore kako će vodeći proizvođači sistemske podrške, u domeni zaštite osobnih podataka, prikazati tehnologiju temeljenu na digitalnom potpisu a koja filtrira poruke koristeći procjenu prema domeni poruke i to dok poruke prolaze u lokalnu, poslovnu mrežu kroz sigurnosnu zaštitnu stijenu.

Kroz sakupljene statističke podatke, lagano je zaključiti kako je najefikasnije i najisplativije poruku neželjene pošte zaustaviti na putu do krajnjeg korisnika. Kako bi se osigurali od mogućih gubitaka korisnih podataka tj. poruka pogrešno označenih kao neželjena pošta, potrebno je korisniku ostaviti mogućnost da sam određuje pravila filtriranja poruka.

4

3 Tehnike borbe protiv neželjene pošte

3.1 Filtriranje

Filtriranje poruka elektroničke pošte podrazumijeva određeni sustav koji na temelju sadržaja poruke i njenih zaglavlja odlučuje da li se poruka treba smatrati porukom neželjene pošte ili ne.

Filtriranje se može obavljati na nekoliko mjesta na putu poruke od pošiljatelja do primatelja:

• filtriranje na polaznom poslužitelju (poslužitelj koji prima poruke od pošiljatelja i prosljeđuje ih drugim poslužiteljima ili korisnicima)

• filtriranje na dolaznom poslužitelju (poslužitelj koji prima poruke za primatelja i prosljeđuje ih korisnicima)

• filtiranje na klijentskoj strani (filtriranje u klijentskom programu primatelja poruke)

Filtriranje se može obavljati na više načina:

• filtriranje poruka koristeći statističke metode tzv. Bayesian filtering (engl., filtriranje zasnovano na Bayesovim pravilima)➔ na osnovu sadržaja poruke i zaglavlja, koristeći bazu podataka s poznatim izrazima

koji se pojavljuju u porukama neželjene pošte, svakoj poruci se dodijeli ocjena te se na osnovu nje odlučuje da li je poruka neželjene pošte ili nije

• filtriranje razmjenom kontrolnog zbroja (engl. Distributed Checksum Filtering)➔ poslužitelji pošte se povezuju u mrežu koja razmjenjuje kontrolni zbroj, tzv. potpis

poruke (može biti npr. sažetak dijela poruke, ...) međusobno➔ ukoliko se utvrdi da je neka poruka zapravo poruka neželjene pošte, nije potrebno

razmjenjivati čitavi sadržaj već samo potpis poruke kako bi se moglo filtrirati takve poruke

• filtriranje koristeći “crnu” i “bijelu” listu (engl. Whitelisting/Blacklisting)➔ stvara se liste internet adresa pošiljatelja, “crna” za pošiljatelje poruka neželjene

pošte koje treba filtrirati, “bijela” lista za poznate pošiljatelje koje treba propuštati

Prema [8], postoje mnogi razlozi za i protiv filtriranja poruka. Neki od razloga protiv su zakonski aspekti otvaranja tuđe pošte (iako je u elektroničkom obliku), pouzdanost sustava filtiranja (mogućnost da se važnu poruku proglasi neželjenom i kao takvu filtrira), veličina listi u slučaju korištenja “crne” liste pošiljatelja (nije moguće identificirati sve pošiljatelje). Razlozi za bi bili smanjenje prometa poruka neželjene pošte, mogućnost brze identifikacije poruke neželjene pošte (npr. koristeći Bayesova pravila), mogućnost brze izmjene sustava filtriranja (ukoliko se koristi filtriranje na poslužiteljima može se čitavi sustav izmijeniti u kratkom roku u svrhu povećanja efikasnosti filtriranja).

5

3.2 Provjera identiteta pošiljatelja

Koristeći provjeru pošiljatelja može se utvrditi koja poruka je neželjena pošta jer se pošiljatelji takvih poruka skrivaju mijenjajući adresu pošiljatelja u poruci te koristeći tuđi pristup poslužiteljima. Razloga tome ima više a najčešći su najnovije zakonske odredbe i kazne za pošiljatelje poruka neželjene pošte.

Isto tako, pružatelji internet usluga zaustavljaju širenje poruka neželjene pošte onemogućavajući korisnike da šalju poruke. Ukoliko se utvrdi da je njihov korisnik poslao takve poruke, najčešće mu se ukida pristup poslužitelju.

Provjeru pošiljatelja može se vršiti na više načina :

• POP/IMAP-prije-SMTP (engl. POP/IMAP-before-SMTP)• sigurni SMTP (engl. secure SMTP)• SMTP AUTH i STARTTLS

POP/IMAP-prije-SMTP je najstariji način provjere pošiljatelja kod kojeg se pošiljatelj mora autentificirati korištenjem POP ili IMAP protokola prije nego može koristiti SMTP protokol slanja poruka elektroničke pošte. Prednosti takva načina su korištenje postojećih protokola, nije potrebno mijenjati klijentske programe niti dodatno podešavati, potrebna je manja izmjena na poslužitelju. Mane takva pristupa jesu razina sigurnosti jednaka razini sigurnosti kod POP/IMAP protokola (sigurnost pristupa na poslužitelj slanjem lozinke korisnika preko Interneta bez dodatne zaštite) te najčešći nedostatak potpore kod poslužitelja elektroničke pošte (potrebno je dodatno mijenjati poslužitelja).

Sigurni SMTP (kraće SMTPS) jest metoda kod koje se koristi TLS enkripcija pristupa poslužitelju kod slanja poruka. Prednost je jednostavnost protokola te sigurnost s obzirom na to da TLS dosad nije imao nikakvih sigurnosnih problema. Nedostaci bi bili potreba dodatnog podešavanja/mijenjanja klijentskog programa, dodatni promet kod slanja poruka te obaveza korištenja certifikata.

SMTP AUTH i STARTTLS su dodatna proširenja SMTP protokola. Prednosti korištenja tih metoda su široka podrška klijentskih programa, podrška poslužitelja te fleksibilnost kod korištenja enkripcije, dok je najveći nedostatak mogućnost sigurnosnih pogrešaka tj. previda.

3.3 Provjera pošiljatelja

Dok se kod provjere identiteta pošiljatelja utvrđivao sam identitet pošiljatelja, metode provjere pošiljatelja utvrđuju da li je poruka koja se šalje pravovaljana tj. da poruka nije neželjena pošta te da je šalje pošiljatelj a ne neki računalni program za masovno slanje poruka neželjene pošte. Kod provjere pošiljatelja traži se da pošiljatelj dokaže svoj identitet izvodeći određene postupke, koji su u nekim slučajevima vrlo kreativni.

6

Postupci provjere uključuju :

• vizualni captcha (engl. Completely Automated Public Turing test to tell Computers and Humans Apart, potpuno automatizirani javni Turingov test za razlikovanje računala i ljudi)➔ test se zasniva na tome da osoba upiše tekst koji se nalazi na slici➔ primjer takvog testa jest slika 3.1 kod koje će ljudska osoba lagano zaključiti koji

je niz znakova prikazan na slici dok će računalo vrlo teško uspjeti odgonetnuti koja je to riječ

• Haiku➔ metoda zahtjeva umetanje zaglavlja koja će Haiku program koristiti za

dokazivanje da poruka nije neželjena pošta• izračunavanje pošiljatelja (engl. sender compute)

➔ zahtjeva se da pošiljatelj riješi određeni ne-trivijalni matematički zadatak i riješenje postavi kao zaglavlje poruke kod slanja

• metoda upita i odgovora (engl. challenge/response)➔ od pošiljatelja se traži da odgovori na upit koji je poslao primatelj➔ najčešće ljudi odbijaju takve metode te se ne koriste često

3.4 Okosnica police pošiljatelja

Okosnica police pošiljatelja, SPF (engl. Sender Policy Framework1) jest metoda kod koje grupe internet adresa tj. domene specificiraju liste numeričkih internet adresa sa kojih će se slati pošta njihovih korisnika. Na taj način pošiljatelji poruka neželjene pošte ne mogu koristiti adrese korisnika čije domene koriste SPF , uz potrebnu SPF provjeru primatelja pošte. Ukoliko pošiljatelj poruke neželjene pošte koristi takvu internet adresu u poruci, primatelj provjerom police pošiljatelja (ukoliko domena pošiljatelja specificira policu tj. koristi SPF) povezuje identitet pošiljatelja s numeričkom internet adresom sa koje je poslana poruka i može utvrditi da je veza identiteta i adrese pošiljatelja ispravna ukoliko u polici domene kojoj pripada pošiljatelj pronađe takvu adresu.

1 tehnika filtriranja elektroničke pošte na osnovu dozvoljenih internet adresa sa kojih poslužitelj elektroničke pošte prihvaća slanje poruka [8]

7

Slika 3.1: Primjer captcha testa

3.5 Zaključak

Istražujući različite tehnike borbe protiv neželjene pošte dolazi se do sljedećih tvrdnji

Najlakše je za prepoznavanje poruke neželjene pošte koristiti provjeru identiteta pošiljatelja. Time se otklanjaju sve sumnje u mogućnost krive procjene da je poruka neželjena pošta te se time izbjegava moguću štetu zbog gubitka vrijednih informacija.

Filtriranjem poruka na poslužitelju smanjuje se promet poruka elektroničke pošte od poslužitelja prema korisniku tj. primatelju pošte te između dva poslužitelja elektroničke pošte prilikom razmijene poruka.

Na osnovu ovih tvrdnji, u ovom radu će se izraditi sigurni sustav elektroničke pošte temeljen na autentifikaciji pošiljatelja korištenjem digitalnog potpisa te filtriranju poruka elektroničke pošte na poslužitelju. Kako bi se ostvarila kompatibilnost sigurnog sustava elektroničke pošte sa klasničnim sustavom elektroničke pošte, poslužitelji unutar sigurnog sustava elektroničke pošte će uz filtriranje koristit i obilježavanje poruka elektroničke pošte. Na taj način će primatelj moći primiti poruku koja nije digitalno potpisana uz prikladno upozorenje, uz pretpostavku da je korisnik na poslužitelju odredio da se takve poruke ne filtriraju već samo obilježavaju kako bi se klijentskim programom mogle razvrstati tj. izdvojiti od onih poruka koje koriste digitalni potpis.

8

4 Digitalni potpis i njegova primjena

Digitalni potpis definira se kao dvojac {m, E[Q(m), SA]}, sastavljen od poruke m koja je digitalno potpisana, te kriptiranog sažetka poruke, gdje Q(m) predstavlja funkciju sažimanja poruke tj. sažetak poruke, a E[Q(m), SA] funkciju enkripcije tog sažetka privatnim ključem SA korisnika A koji potpisuje poruku. Svatko tko poznaje javni ključ PA korisnika A moći će provjeriti valjanost potpisa koristeći postupak opisan u poglavlju 4.1 .

4.1 Postupak potpisivanja

Digitalni potpis u današnje doba informatizacije zamjenjuje tradicionalni potpis na digitalnim dokumentima (različite datoteke/informacijski tokovi). Kako bi vjerodostojno zamijenio kasični potpis, digitalni potpis mora osigurati autentičnost potpisa i onemogućiti krivotvorenje potpis.

Koristi se najčešće u svrhu dokazivanja autentičnosti pošiljatelja/vlasnika/autora digitalnog dokumenta.

Kod digitalnog potpisivanja potrebno je prvo izračunati sažetak poruke odnosno dokumenta. Ovisno o odabranom algoritmu, dobit će se sažetak određene duljine.

Taj sažetak se zatim dekriptira algoritmom javnog ključa (asimetričnim kriptografskim algoritmom) korištenjem privatnog ključa. Privatni ključ se koristi kako bi svatko tko posjeduje javni ključ, onoga tko je potpisao poruku, mogao provjeriti potpis, a kako su postupci kriptiranja i dekriptiranja jednaki kod asimetričnih algoritama, to znači da će svatko tko javnim ključem kriptira dobiveni potpis (dekripitrani sažetak) dobivene poruke dobiti originalni sažetak.

Kad osoba primi potpisanu poruku, postupak provjere potpisa je sljedeći. Prvo se izračuna sažetak dobivene jasne poruke. Taj sažetak se sačuva kako bi se kasnije usporedio. Zatim se dobiveni potpis (kriptirani sažetak) dekriptira kako bi se dobio sažetak kojeg je osoba koja je potpisala poruku, potpisala. Zatim se te dvije vrijednosti sažetaka usporede i ako su identične, tada je potpis ispravan i autentičnost poruke i njenog pošiljatelja je utvrđena.

Ključevi za provjeru digitalnog potpisa dobivaju se od certifikacijskog centra (CA) koristeći infrastrukturu javnog ključa (PKI).

9

4.2 PKI – infrastruktura javnog ključa

Infrastruktura javnog ključa pruža sigurno povezivanje javnog ključa i korisnika. Korištenjem takve infrastrukture omogućava se uspostavljanje putova certificiranja između korisnika sustava. Osnovne dijelove infrastukture javnog ključa čine CA – certifikacijsko tijelo te RA – registracijsko tijelo.

CA (certifikacijsko tijelo) izdaje, opoziva i arhivira certifikate korisnika sustava. Čitavi sustav je hijerarhijski tako da jedan CA (CAA) može biti u svojstvu korisnika u nekom drugom CA (CAB). Time se uspostavlja povjerenje između korisnika jednog i drugog sustava. Korisnik CAA vjeruje svim certifikatima potpisanim od strane CAA a kako CAA vjeruje CAB

time se tranzitivno stvara povjerenje korisnika CAA u certifikate potpisane od strane CAB.RA (registracijsko tijelo, registracijski centar) je sućelje između korisnika i CA.

Osnovne funkcije RA jest identifikacija i autentifkacija korisnika uime CA te raspodjela certifkata, generiranih od strane CA, korisnicima. RA djeluje kao posrednik između korisnika i CA.

4.2.1 Ključevi

Ključevi, tj. par ključeva, javni i privatni, određuju funkcije kriptiranja i dekriptiranja. Privatni ključ se koristi kod digitalnog potpisivanja dokumenta, dok se javni ključ koristi za provjeru digitalnog potpisa.

4.2.2 Digitalni certifikat

Digitalni certfikat povezuje javni ključ korisnika s njegovim imenom. [2]Kako bi se moglo provjeriti vjerodostojnost takve veze potrebno je poznavati i certifikat tijela koje je izdalo takav certifikat tj. certifikacijskog tijela. Koristeći certifikat certifikacijskog tijela (uz pretpostavku da korisnik vjeruje tom certifikatu), provjerava se veza javnog ključa korisnika iz certifikata s imenom korisnika dobivenog iz certifikata. Postupak provjere svodi se na uzimanje javnog ključa certifikacijskog tijela koje je potpisalo korisnikov certifikat te provjerom digitalnog potpisa na tome certifikatu. Ukoliko je digitalni potpis ispravan, tada se uspostavlja povjerenje u vezu javnog ključa korisnika i imena naznačenog u certifikatu.

Primjer digitalnog certifikata, prikazanog korištenjem mehanizama Windows operativnog sustava, nalazi se na slikama 4.1, 4.2, 4.3.

10

11

Slika 4.1: Prikaz digitalnog certifikata

Slika 4.2: Detalji digitalnog certifikata

Na slici 4.3 prikazan je certifikacijski put (eng. certification path1) ovog certifikata. Certfikacijski put sadrži zapis svih osoba odnosno certifikacijskih tijela koja su potpisala dani certifikat. Vidi se da je ovaj certifikat izdalo certifikacijsko tijelo naziva aresCA (slika 4.2, issuer) te se je ono zapisalo kao prvo na certifikacijskom putu. Posljednje na certifikacijskom putu se nalazi certifikat kome pripada ovaj certifikacijski put. Provjera certifikata vrši se kretanjem certifikacijskim putem od kraj prema početku. Dakle, ako bi htjeli utvrditi valjanost certifikata izdano osobi naziva SuperAdmin tada bi, prema slici tj. certifikatu, trebali provjeriti potpis certifikacijskog tijela naziva aresCA. Ako je potpis ispravan (neposredno je potrebno utvrditi ispravnost certifikata certifikacijskog tijela aresCA kako bi odbacili mogućnost krivotvorenja digitalnog certifikata), tada se može reći da je certifikat valjan (uz uvjet da certifikatu nije istekao naznačeni vremenski okvir valjanosti, slika 4.2, valid from te valid to polja).

1 lanac sastavljen od digitalnih certifikata, s time da je moguće provjeriti svaki od tih certifikata, a ujedno je to najmnaji povezani skup certifikata takvih da korisnik vjeruje jednom certifikatu (najčešće pripada certifikacijskom tijelu) a povjerenje prema drugim certifikatima se uspostavlja koristeći početni certifikat

12

Slika 4.3: Certifikacijski put

4.3 Autentifikacija pošiljatelja

Unutar infrastrukture javnog ključa, PKI, koristi se autentifikacija pošiljatelja prema X.509 standardu [2].

Standard predviđa tri protokola, opisana u sljedećim poglavljima.

4.3.1 Protokol s jednom porukom

Protokol s jednom porukom (engl. one-way protocol), prema [2], služi za autentifikaciju dva sudionika u komunikaciji, A i B, te osigurava integritet sadržaja koji se prenose sudioniku B te upotrebom vremenske oznake sprečava napad ponavljanjem poruke [2].

Postupak se odvija obavljanjem sljedećih koraka

• kada sudionik A želi uspostaviti komunikaciju sa sudionikom B➔ generira nasumični broj NA

➔ oblikuje vremensku oznaku TA koja sadrži početno vrijeme važenja oznake i vrijeme trajanja valjanosti oznake

➔ pronalazi u tablicama put A → B te iz certifikata sudionika B, CERBCB saznaje

javni ključ KEB sudionika B➔ oblikuje četvorku (IDB , TA , NA , D) gdje je D podatkovna komponenta koja

može biti kriptirana ključem KEB, IDB je identitet sudionika A➔ šalje sudioniku B poruku M1 koja sadrži certifikat sudionika A, CERA

CA te oblikovanu četvorku kriptiranu privatnim ključem KDA

• kada sudionik B primi poruku M1

➔ pronalazi u tablicama put B → A te iz certifikata sudionika B, CERACA saznaje

javni ključ KEA sudionika A➔ pomoću ključa KEA dobiva (IDB , TA , NA , D) te na osnovu IDB utvrđuje da je

poruka namjenjena njemu➔ na temelju vremenske oznake TA utvrdi da je poruka unutar intervala valjanosti➔ dekriptira svojim privatnim ključem KDA podatkovnu komponentu D ako je bila

kriptirana➔ po želji, uspoređuje NA sa pohranjenima iz prethodnih poruka da bi utvrdio da

nije poruka ponovljena

13

4.3.2 Protokol s dvije poruke

Protokol s dvije poruke, prema [2], nastavlja se na protokol s jednom porukom obavljanjem dva dodatna koraka

• sudionik B➔ generira nasumični broj NB

➔ oblikuje vremensku oznaku TB

➔ oblikuje petorku (IDA , TB , NA , NB , D) gdje je D podatkovna komponenta koja može biti kriptirana ključem KEA

➔ šalje sudioniku A poruku M2 koja sadrži oblikovanu petorku kriptiranu privatnim ključem KDB

• kada sudionik A primi poruku M2

➔ pomoću ključa KEB dobiva (IDA , TB , NA , NB , D) te na osnovu IDA utvrđuje da je poruka namjenjena njemu

➔ na temelju vremenske oznake TButvrdi da je poruka unutar intervala valjanosti➔ dekriptira svojim privatnim ključem KDA podatkovnu komponentu D ako je bila

kriptirana➔ po želji, uspoređuje NB sa pohranjenima iz prethodnih poruka da bi utvrdio da

nije poruka ponovljena

4.3.3 Protokol s tri poruke

Protokol s tri poruke, prema [2], izvodi se jednako kao i protokol s dvije poruke, uz postavljanje vremenskih oznaka TA = TB = 0 te obavljanjem dva dodatna koraka

• sudionik A➔ uspoređuje dobiveni NA iz poruke M2 s izvornom vrijednošću i utvrđuje da je

poruka M2 odgovor na M1

➔ pomoću ključa KDA dobiva kriptira dobiveni NB i šalje kriptiranu vrijednost kao poruku M3

• kada sudionik B primi poruku M3

➔ pomoću ključa KEA dobiva NB ➔ uspoređuje NB iz poruke M3 sa izvornom vrijednošću i utvrđuje da je M3

odgovor na M2

4.3.4 Odabrani model autentifikacije pošiljatelja

S obzirom na samu tematiku rada (slanje elektroničkih poruka) odabrana je autentifikacija pošiljatelja provjerom digitalnog potpisa na poruci.

Pošiljatelj kod slanja poruke, potpisuje poruku koristeći svoj tajni ključ iz para ključeva vezanih na njegov certifikat izdan od certifikacijskog tijela. Uz digitalni potpis dodaje se niz drugih informacija kako bi se olakšala autentifikacija pošiljatelja.

14

Na standardna zaglavlja elektroničke poruke dodaju se sljedeća dodatna zaglavlja :• x-smail-signature

- digitalni potpis poruke u heksadecimalnom zapisu• x-smail-signer

- jedinstveno ime pošiljatelja (engl. distinguished name) prema X.500 standardu (određeno prilikom certificiranja u certifikacijskom tijelu, zapisano u certifikatu)

• x-smail-cert-issuer- jedinstveno ime certifikacijskog tijela

• x-smail-cert-serial- serijski broj certifikata

Dodavanjem jedinstvenog imena pošiljatelja, certifikacijskog tijela te serijskog broja certifikata riješilo se potrebe pridavanja certifikata potpisanoj poruci. Na osnovu tih podataka moguće je od certifikacijskog tijela dobiti certifikat pošiljatelja, ukoliko je certifikat ispravan.

Dodavanjem digitalnog potpisa osiguran je integritet poruke, autentičnost pošiljatelja i neporecivost. Integritet poruke osiguran je time da je sažetak (kriptografski) poruke kriptiran privatnim ključem pošiljatelja i kao takav zapisan uz poruku. Ponovnim izračunavanjem sažetka poruke i usporedbom sa dekriptiranom vrijednošću dobivenom s porukom može se zaključiti da li je poruka bila mijenjana na svom putu. Autentičnost pošiljatelja je osigurana time da je pošiljatelj svojim privatnim ključem kriptirao sažetak poruke te samo njegovim javnim ključem se može dekriptirati sažetak. Stavljanjem digitalnog potpisa pošiljatelj je osigurao neporecivost poruke jer je samo on mogao staviti svoj digitalni potpis na poruku.

Digitalni potpis nam omogućava, ukoliko neki korisnik zloupotrijebi sustav za slanje neželjenih poruka, sve potrebne dokaze za prijavu takvog korisnika nadležnom tijelu. Nadležno tijelo zatim, ukoliko se utvrdi zloupotreba, može opozvati certifikat korisnika i time efikasno spriješiti svaku daljnju dostavu njegovih poruka elektroničke pošte. Sve poruke koje je dani korisnik slao, a čiji certifikat je opozvan, neće se isporučivati korisnicima ako su odabrali da se poruke se neispravnim potpisima (krivo potpisano ili opozvan certifikat) odbacuju.

Svaki poslužitelj pošte, unutar sigurnog sustava elektroničke pošte, kod primitka poruke provjerava digitalni potpis. Ovisno o tome da li je pošiljatelj ispravno autentificiran (ispravan potpis) ili ne, te ovisno o postavkama primatelja dane poruke, poslužitelj će izvršiti akcije (opisane u poglavlju 6.4.2).

4.3.5 Problem opozvanih certifikata

U sustavima infrastrukture javnog ključa, jedan od većih problema je problem opozvanih certifikata, koji je dosta složen i potrebno je mnogo napora da bi se riješio.

Vezivanjem javnog ključa i identiteta korisnika pomoću certifikata prebačen je problem utvrđivanja identiteta tj. autentifikacije pošiljatelja sa krajnjeg korisnika na posrednički sustav tj. PKI i certifikate. Više nije potrebno složenim protokolima utvrditi identitet već je dovoljno provjeriti ispravnost certifikata i utvrditi identitet koristeći jedinstveno ime na certifikatu.

Problem nastaje ukoliko se razotkrije privatni ključ certifikacijskog tijela / korisnika ili na neki drugi način kompromitira certifikat (npr. krivotvorenjem digitalnih certifikata). U tome slučaju potrebno je opozvati certifikat.

Opoziv certifikata vrši certifikacijsko tijelo, a moguće je da korisnik sam zatraži opoziv ili da certifikacijsko tijelo odluči opozvati certifikat.

15

Prilikom opoziva certifikata potrebno je na listu opozvanih certifikata dodati certifikat koji se opoziva te u bazi tj. registru certifikata zapisati da je opozvan. Zatim je potrebno listu opozvanih certifikata razaslati svim zainteresiranim stranama, a koje obavljaju provjeru certifikata uvidom u listu opozvanih certifikata.

Ovaj problem moguće je izbjeći tako da se provjera ispravnosti ne obavlja pomoću liste opozvanih certifikata nego da se svaki put šalje upit u certifikacijsko tijelo. Time je povećan internet promet i opterećenje certifikacijskog tijela te ujedno zahtjeva stalnu vezu na certifikacijsko tijelo (ako nema veze na certifikacijsko tijelo, tada se ne može provjeriti valjanost certifikata). Obzirom na to da se radi o poslužitelju elektroničke pošte, pretpostavljena je stalna veza na Internet odnosno lokalnu mrežu a time i na certifikacijsko tijelo.

16

5 Korištene tehnologije

Poslužiteljski i klijentski programski sustavi bazirani su na open-source1 (engl., otvoreni kod) tehnologijama i proizvodima. Oba programska sustava koriste Spring framework (engl., okosnica), u verziji 1.2.8 dostupan na http://www.springframework.org , na nižim razinama, dok se na višim razinama koriste razni programski sustavi i frameworkci.

Osnovni dijelovi poslužiteljskog sustava (certifikacijsko tijelo, poslužitelj elektroničke pošte, baza podataka) koriste slobodno dostupne programske sustave. Kao certifikacijsko tijelo koristi se EJBCA (u verziji 3.2.0), http://sourceforge.net/projects/ejbca . Za bazu podataka koristi se MySQL baza podataka, u verziji 5.0.18, dostupna na http://www.mysql.com .

Kao poslužitelj elektroničke pošte koristi se Apache JAMES (Java Apache Mail Enterprise Server), verzije 2.2.0, dostupan na http://james.apache.org .

Za potrebe ovog rada, neznatno je izmjenjen EJBCA (vidi poglavlje 6.3.1), dok je korištenjem programskih sučelja koja nudi Apache JAMES izrađena dodatna programska oprema poslužitelja elektroničke pošte u svrhu obrade poruka unutar sigurnog sustava elekroničke pošte (vidi poglavlje 6.4.1).

Klijentski sustav izrađen je korištenjem Eclipse RCP frameworka.Izrađen je u modularnom obliku te ga je moguće ugraditi u već postojeće Eclipse RCP aplikacije, bez potrebe modifikacije samog klijentskog sustava. Isto tako, moguće ga je iskoristiti na bilo kojoj platformi za koju postoji SWT biblioteka odn. Eclipse RCP runtime (engl., izvedbeno okruženje).

5.1 Eclipse RCP

Eclipse RCP je open-source, java framework2 (engl. okosnica) za izradu aplikacija baziran na SWT biblioteci. Omogućava brzi razvoj aplikacija (engl. RAD – Rapid Aplication Development) korištenjem već predefiniranih komponenti. Izmjena predefiniranih komponenti je jednostavna i omogućuje jednostavnu prilagodbu specifičnim potrebama. Moguće je i kreirati vlastite komponente i / ili kombiniranjem postojećih komponenti kreirati potrebnu komponentu.

Eclipse RCP zasniva se na ideji modularnosti programa korištenjem tzv. plug-in komponenti tj. plug-inova (engl., programska koponenta koja poboljšava računalni program, aplikaciju) uz odgovarajuću arhitekturu same aplikacije.Podrška za plug-in razvijena je tako daleko da se nudi mogućnost automatizirane obnove konfiguriranih plug-inova unutar aplikacije, jednostavna ugradnja i konfiguracija novih bez potrebe za mijenjanjem aplikacije.

Klijentski dio razvijen u sklopu ovog rada izrađen je kao plug-in te se kao takav može lagano uklopiti u postojeće programe koji koriste plug-in

1 tehnologije tj. program čiji je izvorni kod slobodno dostupan2 biblioteka gotovih komponenata i načina korištenja takvih komponenata u određene svrhe

17

O uspješnosti Eclipse RCP frameworka dovoljno govori podrška velikih proizvođača računalne programske potpore (engl. software) te mnoštvo malih proizvođača koji u njegovoj otvorenosti vide određene prednosti. Korištenjem Eclipse RCP frameworka ostvareno je i programsko okruženje za razvoj aplikacija IBM Rational Software Development Platform (http://www.ibm.com). Više o samom Eclipse RCP može se naći na http://www.eclipse.org .

5.2 SWT

SWT (engl. standard widget toolkit) je open-source java biblioteka napravljene od strane IBM-a, namjenjena izradi grafičkih korisničkih sučelja, dostupna na http://www.eclipse.org .

SWT sučelje stavlja manje zahtjeve na opremu sustava koji izvodi java programe sa grafičkim sučeljem rađenim u SWT-u.

Izborom SWT biblioteke, izgled sučelja se približava izgledu radne okoline korisnika (npr. MS Windows, Linux, Unix), što pomaže bržem privikavanju korisnika na rad samog programa.

5.3 Spring framework

Spring framework razvijen je za potrebe brzog razvoja apikacija koristeći provjerene metode i postupke pisanja programskog koda u Java programskom jeziku. Koristeći Spring moguće je u kratkom roku izraditi složenu aplikaciju.

U ovom radu korištene su mogućnosti rada s bazom podataka te jednostavna konfiguracija aplikacije unutar XML datoteka.

Više o Spring frameworku na http://www.springframework.org .

18

6 Poslužiteljski sustav elektroničke pošte

6.1 Princip rada sustava

Poslužitelj elektroničke pošte po primitku poruke provjerava digitalni potpis same poruke. Ovisno o postavkama korisnika elektroničke pošte, poslužitelj će obilježiti poruku (ispravno potpisana, nepotpisana, neispravno potpisana) ili odbaciti poruku.

Klijent prilikom slanja poruke elektroničke pošte, digitalno potpisuje poruku. Prilikom primanja pošte, klijent će na osnovu obilježja poruke, postavljenih od strane poslužitelja, razvrstati poštu na ispravno potpisane, nepotpisane te neispravno potpisane. Klijent može poslužitelju zadati da neispravno potpisane i/ili nepotpisane poruke odbacuje čime se direktno smanjuje promet neželjenih poruka elektroničke pošte.

Za potpisivanje koristi se digitalnim certifikatom i parom ključeva koji su pridjeljeni certifikatu. Certifikat jednoznačno pridjeljuje korisniku certifikacijsko tijelo (CA) unutar infrastrukture javnog ključa, na zahtjev korisnika. Certifikacijsko tijelo održava bazu certifikata i na zahtjev korisnika može poništiti valjanost certifikata te mu izdati drugi certifikat.

Poslužitelj elektroničke pošte provjerava digitalni potpis na način da provjeri valjanost digitalnog certifikata naznačenog na poruci elektroničke pošte. Ukoliko je certifikat valjan, uzima se javni ključ iz certifikata i provjerava se digitalni potpis. Ovisno valjanosti digitalnog potpisa, poslužitelj poduzima odgovarajuće akcije.

6.2 Komponente sustava

Za ostvarenje sigurnog sustava elektroničke pošte odabran je postojeći poslužitelj elektroničke pošte, Apache JAMES, kojemu je pridodan CA/RA poslužitelj, EJBCA, te bazu podataka, MySQL, za spremanje osobnih postavki korisnika sustava.

6.3 CA/RA poslužitelj

Kao CA/RA poslužitelj koristi se open-source poslužitelj EJBCA koji se izvodi unutar Java aplikacijskog poslužitelja JBoss (više na http://www.jboss.org).

Poslužitelj će se postaviti na računalo sa internet adresom http://ares odnosno https://ares .

19

Na klijentskoj strani (Client) može se pojaviti više vrsta klijenata. U radu su korištena samo 2 od mogućih 4. Administrator koristi internet preglednik (Browser) za dodavanje korisnika i konfiguraciju CA/RA poslužitelja. Koristeći internet preglednik, korisnik je davao zahtjev za izdavanje certifikata te preuzimao generirani certifikat.

CA/RA poslužitelj sastoji se od dvije glavne komponente, CA (engl. Certification authority, certifikacijsko tijelo) i RA (engl. Registration authority, registracijsko tijelo) komponente.

Osnovna zadaća CA komponente (certifikacijsko tijelo) jest :• izdavanje certifikata korisnicima• objavljivanje certifikata korisnika• opoziv certifikata korisnika• arhiviranje certifikata korisnika

Među ostalim zadaćama, CA obavlja sljedeće funkcije• identifikacija i autorizacija podređenih CA• generiranje i upravljanje certifikata podređenih CA• provjera i izdavanje certifikata na zahtjev RA• primanje i autentificiranje zahtjeva za opoziv izdanih certifikata• generiranje liste opozvanih certifikata (engl. CRL Certificate revocation list) za

sve izdane certifikate• arhiviranje izdanih certifikata, CRL• dostava izdanih certifikata i CRL

RA komponenta (registracijsko tijelo) služi kao sučelje korisnika i CA. RA identificira i autentificira korisnika te na korisnikov zahtjev od CA traži izdavanje certifikata. RA korisniku dostavlja izdani certifikat.

20

Slika 6.1: Arhitektura EJBCA CA/RA poslužitelja

RA obavlja sljedeće funkcije :• identifikacija i autentifikacija korisnika• šalje zahtjev CA za izdavanje certifikata korisniku• prima certifikate od CA i proslijeđuje korisnicima• dostavlja certifikate CA svim zainteresiranim korisnicima• prima zahtjeve za opoziv certifikata, provjerava ih i prosljeđuje CA

EJBCA za pospremanje certifikata i svih ostalih podataka koristi bazu podataka te LDAP repozitorij (engl. Lightweight Directory Access Protocol). LDAP repozitorij koristi se za pohranjivanje podataka o korisnicima CA/RA sustava.

6.3.1 Dodatne izmjene poslužitelja

EJBCA poslužitelj potrebno je doraditi kako bi se mogla programski provjeriti valjanost certifikata. Prije nego se započne sa postupkom postavljanja certifikacijskog tijela potrebno je dodati servlet1 i njegovu konfiguraciju. U programski paket org.ejbca.ui.web.pub doda se novi razred CheckRevocationServlet, čiji je izvorni kod prikazan na slici 6.2 . Kako bi ga se moglo iskoristiti potrebno je konfigurirati servlet unutar aplikacije tj. EJBCA poslužitelja. Konfiguracija se obavlja unutar datoteke web.xml unutar src/publicweb/webdist/WEB-INF direktorija EJBCA programske distribucije. Da bi konfigurirali servlet dodaje se kod sa slike 6.3 u web.xml datoteku.

CheckRevocationServlet provjerava, na osnovu parametar poziva servleta issuer te serno, pozivom store.isRevoked(...) da li je certifikat opozvan ili nije. Ako je certifikat opozvan ili ne postoji, vraća poruku HttpServletResponse.SC_NOT_ACCEPTABLE, ukoliko nije moguće utvrditi valjanost certifikata vraća se poruka HttpServletResponse.SC_INTERNAL_SERVER_ERROR te ukoliko je certifikat ispravan vraća poruku HttpServletResponse.SC_OK . Poruke iz razreda HttpServletResponse označavaju standardne HTTP kodove odgovora na HTTP upit.

1 manji program koji se izvodi na poslužitelju, najčešće se radi o Java aplikacijskom poslužitelju

21

22

Slika 6.2: Java servlet koji odrađuje posao provjere certifikata

...

/** * Servlet used to simplify checking certificate for revocation. * If certificate is revoked, returns response code 404, if ok returns 200. * @author mknezic */public class CheckRevocationServlet extends HttpServlet {

....

public void doGet(HttpServletRequest request, HttpServletResponse response)

throws IOException, ServletException { String dn=request.getParameter("issuer"); String serno=request.getParameter("serno"); if (serno != null) serno=serno.trim(); if ((dn == null) || (serno == null)) { LOG.error("bad request for DN:" + dn + " serial:" + serno); response.setStatus(HttpServletResponse.SC_BAD_REQUEST); return; } RevokedCertInfo revinfo = store.isRevoked(new

Admin(Admin.TYPE_PUBLIC_WEB_USER, request.getRemoteAddr()), dn,new BigInteger(Hex.decode(serno)));

if (revinfo != null) { if (revinfo.getReason() != RevokedCertInfo.NOT_REVOKED) { LOG.error("certificate revoked for DN:" + dn + " serial:"

+ serno); response.setStatus(HttpServletResponse.SC_NOT_ACCEPTABLE); return; } else { response.setStatus(HttpServletResponse.SC_OK); LOG.debug("certificate not revoked for DN:" + dn + " serial:"

+ serno); return; } } else { LOG.error("no revocation info for DN:" + dn + " serial:" + serno); response.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR); return; } }

}

Nakon dodavanja servleta i njegove konfiguracije, može se nastaviti sa postavljanjem poslužitelja i njegovom konfiguracijom prema dokumentaciji unutar EJBCA programske distribucije.

23

Slika 6.3: Konfiguracija servleta unutar web.xml datoteke

<servlet> <servlet-name>CertCheck</servlet-name> <display-name>CertCheckServlet</display-name> <servlet-class>org.ejbca.ui.web.pub.CheckRevocationServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>CertCheck</servlet-name> <url-pattern>/certcheck</url-pattern> </servlet-mapping>

6.3.2 Dodavanje korisnika

Dodavanje korisnika tj. entiteta unutar EJBCA sustava izvodi administrator sustava koristeći web sučelje dostupno na adresi https://ares:8443/ejbca/adminweb/index.jsp. Potrebno je odabrati funkciju Add End Entity unutar odjeljka RA functions. Tada nam se prikazuje forma za unos podataka o korisniku (korisničko ime, lozinka, jedinstveno ime prema X.500 standardu, ...) prema slici 6.4.

Uz podatke o korisniku (tj. entitetu kojeg se dodaje), odabire se profil certifikata (krajnji korisnik) te način prijenosa certifikata i ključeva korisniku (odabrana je JKS datoteka radi kompatibilnosti sa klijentskim sustavom). Time je dodan korisnik no nije generiran par ključeva niti certifikat nego će se to obaviti na korisnikov zahtjev koristeći web sučelje za korisnika.

6.3.3 Izdavanje i preuzimanje certifikata i ključeva

Certifikacijsko tijelo na korisnikov zahtjev izdaje certifikat i ključeve. Potrebno je korištenjem web sučelja dostupnog na adresi https://ares:8443/ejbca/publicweb/apply/apply_main.jsp zadati zahtjev za generiranje ključeva i izdavanje certifikata uz prethodnu autentifikaciju korisnika (koristeći korisničko ime i lozinku zadane prilikom dodavanja korisnika u sustav).

24

Slika 6.4: Ekran za dodavanje korisnika

Na slici 6.5 prikazano je web sučelje za generiranje i dohvat certifikata s otvorenim prozorom intenet preglednika za prihvat datoteke s certifikatima. Datoteka koju je generirao EJBCA poslužitelj sadrži korisnikov certifikat, korisnikov par ključeva te certifikat EJBCA certifikacijskog tijela. Takvu datoteku korisnik dodaje u klijentski programski sustav kako bi mogao digitalno potpisivati poruke elektroničke pošte unutar sigurnog sustava elektroničke pošte.

25

Slika 6.5: Generiranje ključeva i preuzimanje certifikata

6.4 Poslužitelj pošte

Za poslužitelja elektroničke pošte unutar sigurnog sustava elektroničke pošte odabran je Apache JAMES poslužitelj . Koristeći mogućnost nadogradnje samog poslužitelja koju nudi Apache JAMES, kreirane su komponente poslužitelja koje obrađuju poruke elektroničke pošte. Prilikom obrade poruka, provjerava se da li je poruka digitalno potpisana a zatim da li je digitalni potpis ispravan.

Mogućnosti nadogradnje su iskazane kroz Mailet API (engl., aplikacijsko programsko sučelje).

Osnovna sučelja Mailet API-a jesu Mailet (engl., mali program unutar poslužitelja zadužen za obradu elektroničke pošte) i Matcher.

Matcher sučelje služi za razvrstavanje poruka prema određenim uvjetima. Uvjeti se zadaju kroz konfiguraciju, ovisno o programskoj implementaciji sučelja. Rezultati rada objekata koji ostvaruju sučelje Matcher jest popis primatelja poruke a na koje se odnosi akcija koju treba ostvariti. Matcher sučelje ne služi za obradu poruka i kao takvo ne može mijenjati sadržaj poruka.

Mailet sučelje služi za obradu poruka nakon što su razvrstane objektima koji ostvaruju sučelje Matcher. Objekti koji ostvaruju sučelje Matcher mogu mijenjati poruku na bilo koji način ili proslijediti poruku u neki vanjski sustav.

Slika 6.6: Arhitektura JAMES-a

26

Apache JAMES

klijentski program

mailet 1

mailet 2

mailet 3

matcher 1

matcher 2

poruka el. pošte

6.4.1 Provjera digitalnog potpisa

Kako bi provjerili digitalni potpis, razvijena su dva razreda koji ostvaruju sučelje Matcher iz Mailet API-a, opisano u poglavlju 6.4.

Razred SmailMatcherRejectUnsigned služi za razvrstavanje poruka prema tome da li sadrže digitalni potpis ili ne. Ukoliko poruka ne sadrži digitalni potpis, tada će uvidom u postavke korisnika na kojeg je naslovljena poruka biti odučeno da li odbaciti ovu poruku ili ne.

27

Slika 6.7: Kod razreda SmailMatcherRejectUnsigned

package hr.fer.zemris.smail.matchers;...

/** * Razred koji razvrstava poštu na osnovu postojanja digitalnog potpisa. * @author Mladen Knežić */public class SMailMatcherRejectUnsigned extends GenericMatcher { private ApplicationContext m_context; private UserDao m_userDao; public SMailMatcherRejectUnsigned() { super(); m_context = new ClassPathXmlApplicationContext(

"smail-context.xml"); m_userDao = (UserDao)m_context.getBean("userDao"); }

public Collection match(Mail p_mail) throws MessagingException { Collection recipientsCollection = p_mail.getRecipients(); Collection delete = new ArrayList(); MimeMessage message = p_mail.getMessage(); String[] signer = message.getHeader("x-smail-signer"); if (signer == null || !StringUtils.hasText(signer[0])) { message.addHeader("x-smail-signature-status", "unsigned"); Iterator recipients = recipientsCollection.iterator(); while (recipients.hasNext()) { MailAddress recipient = (MailAddress)recipients.next(); UserPreference pref =

m_userDao.fetchPreference(recipient.getUser()); if (pref.isRejectUnsigned()) { delete.add(recipient); } } } else { message.addHeader("x-smail-signature-status", "signed"); } return delete; }

}

Razred SmailMatcherRejectUnsigned provjerava postojanje digitalnog potpisa tako da traži zaglavlje poruke elektroničke pošte naziva "x-smail-signer" koji označava jedinstveno ime pošiljatelja koji je digitalno potpisao poruku. Ukoliko ga ne pronađe to znači da poruka nije potpisana te dodaje zaglavlje "x-smail-signature-status" sa vrijednošću "unsigned" koja predstavlja nepotpisanu poruku. U sljedećem koraku se provjerava postavke primatelja te poruke u bazi podataka. Pozivom nad DAO (engl. data access object, objekt za pristup podacima) objektom m_userDao.fetchPreference(recipient.getUser()) dohvaća postavke korisnika razreda UserPreference unutar baze sustava. Razred UserPreference predstavlja osobne postavke korisnika sa dvije vrijednosti. Jedna predstavlja odbacivanje nepotpisanih poruka, dok druga predstavlja odbacivanje krivoo potpisanih poruka. Pozivom isRejectUnsigned() nad objektom razreda UserPreference utvrdi se da li treba odbaciti poruku te se zatim proslijedi rezultat dalje gdje će sam poslužitelj elektroničke pošte na osnovu rezultata odlučiti odbaciti ili proslijediti poruku.

Razred SmailMatcherRejectInvalid služi za razvrstavanje poruka prema tome da li je digitalni potpis poruke ispravan ili ne. Ukoliko je poruka potpisana ispravno tj. digitalni potpis je valjan, poruka se proslijeđuje korisniku. Ukoiko je digitalni potpis neispravan, uvidom u postavke korisnika na kojeg je naslovljena poruka će biti odučeno da li odbaciti ovu poruku ili ne.

28

29

Slika 6.8: Kod razreda SmailMatcherRejectInvalid – dio 1.

package hr.fer.zemris.smail.matchers;.../** * Razred koji razvrstava poštu na osnovu ispravnosti digitalnog potpisa * poruke. * @author Mladen Knežić */public class SMailMatcherRejectInvalid extends GenericMatcher { private static final Log LOG =

LogFactory.getLog(SMailMatcherRejectInvalid.class); private ApplicationContext m_context; private UserDao m_userDao; public SMailMatcherRejectInvalid() { super(); m_context = new ClassPathXmlApplicationContext(

"smail-context.xml"); m_userDao = (UserDao)m_context.getBean("userDao"); }

public Collection match(Mail p_mail) throws MessagingException { Collection recipientsCollection = p_mail.getRecipients(); Collection delete = new ArrayList(); MimeMessage message = p_mail.getMessage(); String[] signers = message.getHeader("x-smail-signer"); if (signers != null && StringUtils.hasText(signers[0])) { Iterator recipients = recipientsCollection.iterator(); //check signature, if invalid, match recipient String signature = message.getHeader(

"x-smail-signature")[0]; String signer = message.getHeader("x-smail-signer")[0]; String certSerial = message.getHeader(

"x-smail-cert-serial")[0]; String issuer = message.getHeader("x-smail-cert-issuer")[0]; Boolean checked =

CertUtil.checkCertificate(issuer, certSerial); boolean invalid = false; if (checked == null || checked.booleanValue() == false) { //certificate unknown or revoked - signature is bad invalid = true; } else { //certificate ok, check signature ...

30

Slika 6.9: Kod razreda SmailMatcherRejectInvalid – dio 2

...//certificate ok, check signature

try { Signature sig = Signature.getInstance("md5withRSA"); X509Certificate cert =

CertUtil.getCertificate(signer); sig.initVerify(cert.getPublicKey()); Message jmessage = (Message)message; sig.update(

((String)jmessage.getContent()).getBytes()); sig.update(

((InternetAddress)jmessage.getFrom()[0]).getAddress().getBytes());

boolean verified = sig.verify(

new BigInteger(signature, 16).toByteArray());

if (!verified) { invalid = true; } } catch (NoSuchAlgorithmException e) { LOG.error(e); return null; } catch (InvalidKeyException e) { LOG.error(e); return null; } catch (SignatureException e) { LOG.error(e); return null; } catch (IOException e) { LOG.error(e); return null; } catch (MessagingException e) { LOG.error(e); return null; } } if (invalid) { message.addHeader(

"x-smail-signature-validity", "invalid"); while (recipients.hasNext()) { MailAddress recipient =

(MailAddress)recipients.next(); UserPreference pref =

m_userDao.fetchPreference(recipient.getUser()); if (pref.isRejectInvalid()) { delete.add(recipient); } } } else { //signature is valid, no rejections message.addHeader(

"x-smail-signature-validity", "valid"); } } return delete; }}

Razred SmailMatcherRejectInvalid provjerava ispravnost digitalnog potpisa tako da traži sljedeća zaglavlja poruke elektroničke pošte :

• "x-smail-signer" – predstavlja jedinstveno ime pošiljatelja prema X.500 standardu• "x-smail-signature" – predstavlja digitalni potpis u heksadecimalnom zapisu• "x-smail-cert-serial" – predstavlja serijski broj certifikata• "x-smail-cert-issuer" – predstavlja jedinstveno ime izdavatelja certifikata

pošiljatelju prema X.500 standardu

Iz zaglavlja navedenih zaglavlja dobivaju se sve informacije potrebne za provjeru valjanosti certifikata i digitalnog potpisa. Pozivom CertUtil.checkCertificate(...) s parametrima imenom izdavatelja certifikata te serijskim brojem certifikata provjerava se valjanost certifikata upitom samom certifikacijskom tijelu. Ukoliko je certifikat valjan, nastavlja se sa provjerom digitalnog potpisa. Dohvaća se certifikat pošiljatelja pozivom CertUtil.getCertificate(..)s imenom pošiljatelja kao parametrom. Iz dobivenog certifikata uzima se javni ključ pošiljatelja. Pozivom Signature.getInstance("md5withRSA") dohvaća se objekt razreda Signature koji koristi algoritam kriptiranja RSA u kombinaciji sa MD5 algoritmom sažimanja kako bi ostvario digitalni potpis. Objekt se inicijalizira sa javnim ključem pošiljatelja dobivenim iz samog certifikata. Zatim se objektu predaje sadržaj poruke i zaglavlja koja su bila potpisana od strane pošiljatelja. Na kraju se dohvaća digitalni potpis iz objekta i uspoređuje sa potpisom na samoj poruci. Ukoliko se te dvije vrijednosti poklapaju, tada je poruka ispravno potpisana i prosljeđuje se primateljima.

Ako se pak utvrdi da potpis nije ispravan, pozivom nad DAO objektom m_userDao.fetchPreference(recipient.getUser()) dohvaćaju se postavke korisnika razreda UserPreference unutar baze sustava. Pozivom isRejectInvalid() nad objektom razreda UserPreference utvrdi se da li treba odbaciti neispravno potpisanu poruku te se zatim proslijedi rezultat dalje gdje će sam poslužitelj elektroničke pošte na osnovu rezultata odlučiti odbaciti ili proslijediti poruku.

6.4.2 Akcije poslužitelja

Poslužitelj na osnovu rezultata dobivenih iz objekata razreda SMailRejectUnsigned te SMailRejectInvalid odlučuje o tome kamo poslati poruke koje su odabrane na osnovu zadanih uvjeta (vidi poglavlje 6.4.1). Odredište takvih poruka zadaje se u konfiguracijskoj datoteci poslužitelja Apache JAMES, prema slici 6.10.

Slika 6.10: Konfiguracijska datoteka poslužitelja Apache JAMES, config.xml

31

...<!-- Set the Java packages from which to load mailets and matchers --><matcherpackages> <matcherpackage>org.apache.james.transport.matchers</matcherpackage> <matcherpackage>hr.fer.zemris.smail.matchers</matcherpackage></matcherpackages>

...

<mailet match="SMailMatcherRejectUnsigned" class="ToProcessor"> <processor> relay-denied </processor></mailet>

<mailet match="SMailMatcherRejectInvalid" class="ToProcessor"> <processor> relay-denied </processor></mailet>...

Na slici 6.10 se vidi konfiguracija Apache JAMES poslužitelja. Na početku je potrebno definirati pakete koji sadrže razrede koji ostvaruju sučelje Matcher, unutar XML elementa matcherpackages. Ovdje su definirana dva paketa org.apache.james.transport.matchers koji sadrži standardne razrede potrebne za ispravan rad poslužitelja, te hr.fer.zemris.smail.matchers koji sadrži dva prethodno opisana razreda potrebna za rad sigurnog sustava elektroničke pošte.

Nakon definicije paketa moguće je koristiti razrede u daljnjoj konfiguraciji. XML elementima mailet definira se postupak obrade poruka elektroničke pošte. Element mailet ima svojstva match te class, dok se kao podelement nalazi element processor. Svojstvo match određuje naziv razreda koji ostvaruje sučelje Matcher koji će razvrstavati poruke. Svojstvo class određuje razred koji ostvaruje sučelje Mailet a kojemu će se prosljeđivati odabrane poruke. Podelement processor određuje kamo će mailet ovako konfiguriran prosljeđivati poruke. Odredište relay-denied jedno je od standardno definiranih unutar poslužitelja Apache JAMES a koristi se za poruke koje se ne smiju prosljeđivati dalje.

Ovakvom konfiguracijom ostvarenih razreda SMailMatcherRejectUnsigned te SMailMatcherRejectInvalid odredilo se sljedeće :

• sve poruke provjeravaju se da li imaju digitalni potpis➔ ukoliko poruke nemaju digitalni potpis, provjeravaju se postavke primatelja➔ ako primatelj odredi odbacivanje takvih poruka, poruka se ne prosljeđuje

takvom korisniku➔ poruke koje ne zadovoljavaju prethodna dva kriterija, prosljeđuju se dalje u

poslužitelju• sve poruke koje su preostale provjeravaju se da li im je digitalni potpis ispravan

➔ ukoliko je potpis neispravan, provjeravaju se postavke primatelja➔ ako je primatelj odredio odbacivanje takvih poruka, poruka se ne prosljeđuje

tom korisniku➔ poruke koje ne zadovoljavaju prethodna dva kriterija, prosljeđuju se dalje u

poslužitelju• sve preostale poruke prosljeđuju se primateljima

32

6.4.3 Konfiguracija pristupa CA/RA te bazi podataka

Ostvareni razredi ugrađuju se u server postavljanjem .jar datoteke sa izvedbenim datotekama razreda (.class datoteke) i potrebnim datotekama resursa. Konfiguracija je izvedena unutar sljedećih datoteka resursa :

• database-config.xml – sadrži konfiguraciju objekata za pristup bazi podataka• databaseContext.properties – sadrži postavke pristupa bazi podataka za potrebe

objekata za pristup bazi podataka (korisničko ime i lozinka za pristup bazi podataka, url baze podataka)

• log4j.properties – konfiguracija logiranja rada poslužitelja (dio koji se odnosi na siguran sustav elektroničke pošte)

• server.properties – postavke pristupa CA/RA poslužitelju (internet adresa, protokol pristupa)

• smail-context.xml – konfiguracija sustava (objekti za pristup bazi podataka, ...)

6.5 Baza podataka

Za spremanje postavki korisnika vezanih na primanje poruka unutar sigurnog sustava elektroničke pošte koristi se baza podataka MySQL.

Unutar baze podataka kreirana je jedna tablica, naziva preferences koja sadrži postavke korisnika.

Tablica preferences sadrži sljedeće stupce :• username – predstavlja korisničko ime, tipa VARCHAR(45)• rejectInvalid – predstavlja odluku korisnika da poslužitelj odbaci poruke koje

imaju neispravan digitalni potpis, tipa VARCHAR(5), sadržaja true ili false• rejectUnsigned – predstavlja odluku korisnika da poslužitelj odbaci poruke

koje nemaju digitalni potpis, tipa VARCHAR(5), sadržaja true ili false

Nad stupcem username kreiran je indeks radi bržeg pristupa podacima.

33

7 Programski sustav klijenta

7.1 Zadaće klijenta

Razvijen je jednostavan klijentski programski sustav, korištenjem Eclipse RCP tehnologije te Java Mail API-a, programskog sučelja za rad s porukama elektroničke pošte u programskom jeziku Java.

Klijentski program zasnovan je na slanju jednostavnih, tekstualnih poruka elekroničke pošte, bez naprednijih mogućnosti današnjih sustava elektroničke pošte.

Klijentski program omogućava digitalno potpisivanje poruka koje se šalju te razvrstavanje primljenih poruka na tri kategorije :

• potpisane poruke• nepotpisane poruke• neispravno potpisane poruke

Klijentski program omogućava spremanje osobnih postavki korisnika na poslužiteljski sustav, a koje se odnose na filtriranje i obilježavanje poruka na poslužitelju. Tako je moguće odrediti da poslužitelj filtrira poruke koje su nepotpisane ili da ih obilježi. Isto tako je moguće zadati filtriranje ili obilježavanje poruka koje su neispravno potpisane. Filtriranjem se smanjuje promet poruka od poslužitelja prema korisnicima, dok se obilježavanjem poruka omogućava sigurno razvrstavanje poruka na klijentskoj strani, bez straha od gubitka važnih informacija.

Kod potpisivanja poruka, koristi se certifikatima izdanim od certifikacijskog tijela unutar infrastrukture javnog ključa.

34

7.2 Sučelje klijenta

Sučelje sadrži izbornika sa osnovnim funkcijama za rad sa porukama i klijentom.Struktura izbornika klijenta:

➔ Smail➔ postavke➔ spremi na poslužitelj ➔ izlaz

➔ Poruka➔ pošalji poruku➔ primi poruke➔ obriši poruku➔ isprazni smeće

➔ Pomoć➔ o programu

Na alatnim trakama, slijeva nadesno su prečice na sljedeće akcije iz izbornika :pošalji poruku, primi poruke, postavke, spremi na poslužitelj.

35

Slika 7.1: Izgled sučelja klijenta

U lijevom dijelu sučelja prikazuju se pretinci s porukama elektroničke pošte.

Pretinac potpisane sadrži primljene poruke s ispravnim digitalnim potpisom, pretinac neispravan potpis sadrži primljene poruke s neispravnim potpisom, pretinac nepotpisane sadri primljene poruke koje nemaju digitalni potpis, pretinac smeće sadrži obrisane poruke, a pretinac poslane sadrži sve poruke koje je korisnik poslao koristeći klijentski program.

Odabirom jednog od pretinaca u desnom gornjem dijelu prikazat će se popis poruka koje taj pretinac sadrži.

Odabirom poruke u desnom gornjem dijelu, otvorit će se sadržaj poruke u donjem desnom dijelu, prema slici 7.2.

36

Slika 7.2: Prikaz klijenta s otvorenom porukom

7.3 Primjeri rada klijenta

7.3.1 Slanje pošte

Da bi poslao poruku, korisnik treba odabrati akciju pošalji poruku iz izbornika ili alatne trake klijentskog programa.

Po odabiru akcije, otvara se uređivač poruka s mogućnostima slanja poruke ili zatvaranja uređivača.

Nakon što je korisnik odabrao slanje poruke, poruka se šalje te se po slanju poruke otvara prozor sa porukom o tome da li je poruka uspješno poslana ili ne.

Prije samog slanja poruke, poruka se digitalno potpisuje. Slika 7.4 prikazuje programski kod klijenta koji obavlja potpisivanje i slanje poruke.

37

Slika 7.3: Slanje poruke

Slika 7.4: Programski kod digitalnog potpisivanja i slanja poruke

Pozivom KeyStore.getInstance("JKS") te keystore.load(..), kojemu se prosljeđuje lozinka za pristup skladištu ključeva, otvara se skladište ključeva i certifikata. Pozivom Session.getInstance(..) otvara se sjednica sa poslužiteljem pošte. Kreira se poruka, postavi se adresa primatelja, tema, sadržaj poruke. Zatim se pozivom Signature.getInstance("md5withRSA") dohvaća objekt da bi potpisali poruku. Pozivima keystore.getKey(..) se dohvaća ključ kojim će se potpisati poruka. Zatim se pozivom keystore.getCertificate(..) dohvaća certifikat kako bi se moglo postaviti u zaglavlja poruke informacije o pošiljatelju te digitalni potpis. Sljedeće se dodaju zaglavlja opisana u poglavljima 4.3.4 i 6.4, kako bi poslužitelj mogao autentificirati pošiljateljaNakraju, pozivom Transport.send(..) tako stvorena poruka se šalje.

38

KeyStore keystore = KeyStore.getInstance("JKS");keystore.load(new FileInputStream(

SMailPlugin.getDefault().getPreferenceStore().getString( PreferenceConstants.P_OBJECT_STORE) + "/smail.jks"), SMailPlugin.getDefault().getPreferenceStore().getString( PreferenceConstants.P_KEYSTORE_PASSWORD).toCharArray());Properties props = new Properties();props.put("mail.smtp.host",

SMailPlugin.getDefault().getPreferenceStore().getString( PreferenceConstants.P_SMAIL_SERVER));Session session = Session.getInstance(props, null);Message msg = new MimeMessage(session);msg.setFrom(new InternetAddress(

SMailPlugin.getDefault().getPreferenceStore().getString( PreferenceConstants.P_USERNAME) + "@" +

SMailPlugin.getDefault().getPreferenceStore().getString( PreferenceConstants.P_SMAIL_SERVER))); InternetAddress[] address = {new InternetAddress(p_to)};msg.setRecipients(Message.RecipientType.TO, address);msg.setSubject(p_subject);msg.setSentDate(new Date());msg.setText(p_content);Signature sig = Signature.getInstance("md5withRSA"); PrivateKey key = (PrivateKey)

keystore.getKey( SMailPlugin.getDefault().getPreferenceStore().getString(

PreferenceConstants.P_KEYSTORE_ALIAS), SMailPlugin.getDefault().getPreferenceStore().getString(

PreferenceConstants.P_KEYSTORE_PASSWORD).toCharArray());X509Certificate cert = (X509Certificate)keystore.getCertificate(

SMailPlugin.getDefault().getPreferenceStore().getString( PreferenceConstants.P_KEYSTORE_ALIAS));sig.initSign(key);sig.update(((String)msg.getContent()).getBytes());sig.update(

((InternetAddress)msg.getFrom()[0]).getAddress().getBytes());byte[] sign = sig.sign();msg.setHeader("x-smail-signature",

new BigInteger(sign).toString(16));msg.setHeader("x-smail-signer",

cert.getSubjectX500Principal().getName());msg.setHeader("x-smail-cert-issuer",

cert.getIssuerX500Principal().getName());msg.setHeader("x-smail-cert-serial",

cert.getSerialNumber().toString(16));Transport.send(msg);

7.3.2 Primanje pošte

Za primanje poruka elektroničke pošte sa poslužitelja potrebno je odabrati akciju primi poruke iz izbornika ili alatne trake.

Po primitku poruka, odabirom jednog od pretinaca može se pregledati primljene poruke. U slučaju grješke kod primanja poruka javlja se prozor s obavijesti o grješci.

7.3.3 Postavke klijenta

Postavke klijenta može se uređivati odabirom akcije postavke iz izbornika ili alatne trake klijenta. Po odabiru akcije otvara se prozor sa uređivačem postavki.

U uređivaču postavki moguće je definirati poslužitelja pošte (Smail poslužitelj), certifikacijsko tijelo, lokaciju kamo će klijent spremati svoje datoteke.

U postavkama se definiraju korisnička imena i lozinke za pristup poslužitelju pošte te naziv ključa / certifikata i lozinka za pristup spremištu ključeva.

39

Slika 7.5: Uređivač postavki korisnika

Postavke vezane za rukovanje poštom na poslužitelju određuju se označavanjem odabira filtriranja poruka na poslužitelju (odbaci neispravno potpisane poruke te odbaci nepotpisane poruke).

Moguće je odabrati veličinu ikona na alatnoj traci.

Postavke se spremaju tipkom Apply.

Da bi postavke vezane za rukovanje poštom pospremile na poslužitelj (u bazu podataka) potrebno je nakon zatvaranja uređivača pritiskom na tipku Apply, dodatno pokrenuti akciju spremi na poslužitelj.

40

8 Zaključak

Korištenjem autentifikacije pošiljatelja pošte, uz pomoć infrastrukture javnog ključa (PKI), omogućeno je smanjenje prometa neželjenih poruka elektroničke pošte na putu od poslužitelja prema primatelju te između dva poslužitelja. Omogućavanjem razvrstavanja poruka elektroničke pošte na siguran način na klijentskoj strani ostvarene su značajne uštede vremena i spriječen je mogući gubitak informacija. Korištenjem razvijenog sustava, korisnici više ne trebaju trošiti vrijeme na razvrstavanje pošte te pregledavanje da nisu možda zabunom važnu poruku obilježili kao poruku neželjene pošte. Dovoljno je otvoriti klijentski program, pokupiti poruke sa poslužitelja i klijentski program će sam razvrstati poštu na tri kategorije, potpisanu, nepotpisanu i neispravno potpisanu, korištenjem sigurnog načina autentifikacije pošiljatelja korištenjem digitalnog potpisa. Određivanjem odbacivanja nepotpisanih i neispravno potpisanih poruka već na poslužitelju, moguće je potpuno ukloniti poruke neželjene pošte. Primjenom takvog načina, pošiljatelj poruke je utvrđen na siguran način, bez mogućnosti prevare sustava.

Uvođenjem u širu primjenu sigurnog sustava elektroničke pošte ili sličnih sustava zasnovanih na digitalnom potpisu i korištenju infrastrukture javnog ključa, moguće je smanjiti količinu neželjenih poruka, na siguran i jednostavan način, bez straha od gubitka informacija koje su pogrešno smatrane neželjenom poštom na osnovu sadržaja iako je pošiljatelj pouzdan. Korištenjem digitalnog potpisa se smanjuje razmjere štetnih radnji poput slanja neželjene pošte i krađe identiteta te se povećava opća razina sigurnosti u komunikaciji elektroničkom poštom.

41

9 Literatura

[1] Mladen Knežić, Sustav digitalnog potpisa, seminarski rad,Fakultet elektrotehnike i računarstva, Zagreb, listopad 2005.dostupno na internet adresi http:// os2.zemris.fer.hr/algoritmi/simetricni/2004_knezic/seminar/index.html

[2] Leo Budin, RSA, PKI, Skripta iz Operacijskih sustava 2, Fakultet elektrotehnike i računarstva, Zagreb, 2003.

[3] Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone,Handbook of Applied Cryptography, CRC Press, Fifth printing, kolovoz 2001dostupno na internet adresi http://www.cacr.math.uwaterloo.ca/hac/

[4] PKCS 1,3,5,6,7,8,9,10,11,12,15, Public key cryptography standardRSA Laboratoriesdostupno na internet adresi http://www.rsasecurity.com/rsalabs/

[5] Ron Rivest, The MD5 Message-Digest Algorithm, travanj 1992,dostupno na internet adresi ftp://ftp.rfc-editor.org/in-notes/rfc1321.txt

[6] Jeff McAffer, Jean-Michel Lemieux,Eclipse Rich Client Platform: Designig, coding and packaging JavaTM Applications Addison Wesley Professional, listopad 2005.

[7] Eric Clayberg, Dan RubelAddison Wesley ProfessionalEclipse: Building commercial-quality plug-ins, second editionAddison Wesley Professional, ožujak 2006.

[8] Robert Haskins, Dale Nielsen, Slamming spam : A guide for system administratorsAddison Wesley Professional, prosinac 2004.

42