SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

Zavod za telekomunikacije

DIPLOMSKI RAD br. 3040

IMPLEMENTACIJA SUSTAVA ZA VALIDACIJU

MOBILNIH ULAZNICA Matko Kvesić

Zagreb, listopad 2008.

2

Sadržaj

Sadržaj ...................................................................................................................................... 2

1. Uvod ..................................................................................................................................... 4

2. Mobilno poslovanje ............................................................................................................. 5

2.1. Kratka povijesna nota................................................................................................... 5

2.2. Definiranje mobilnog poslovanja ................................................................................ 6

2.3. Usluga mobilnih ulaznica ............................................................................................ 8

2.3.1. Mobilna ulaznica ................................................................................................. 10

2.3.2. Barkod forma ulaznice ........................................................................................ 12

2.3.3. Validacija mobilne ulaznice ............................................................................... 15

3. Sustav e-Portir ................................................................................................................... 20

3.1. Zahtjevi izvedbe sustava ............................................................................................ 22

3.1.1. Inicijalni zahtjevi izvedbe................................................................................... 22

3.1.2. Funkcijski zahtjevi .............................................................................................. 22

3.2. Arhitektura sustava..................................................................................................... 23

3.3. Tehnologija sustava .................................................................................................... 26

3.2.1. Prezentacijski sloj ............................................................................................... 26

3.2.2. Aplikacijski sloj .................................................................................................. 27

3.2.3. Podatkovni sloj .................................................................................................... 28

3.4. Izvedba i implementacija ........................................................................................... 29

3.4.1. Mobilna ulaznica ................................................................................................. 31

3.4.2. QR Code barkod.................................................................................................. 36

3.4.3. Ulaznični poslužitelj ........................................................................................... 43

3.4.4. Validacijski klijent .............................................................................................. 47

3.4.5. Validacijski poslužitelj ....................................................................................... 52

3.5. Modeliranje sigurnosnih rizika validacijske komponente ....................................... 58

3.5.1 Razine pristupa ..................................................................................................... 59

3.5.2. Ulazne i izlazne točke ......................................................................................... 59

3

3.5.3. Točke napada....................................................................................................... 61

3.5.4. Prijetnje i ranjivosti sustava ............................................................................... 62

4. Instalacija i korištenje e-Portira ....................................................................................... 65

4.1. Instalacija .................................................................................................................... 65

4.1.1. Softverski i hardverski zahtjevi .......................................................................... 65

4.1.2. Tijek instalacije ................................................................................................... 66

4.2. Korištenje e-Portira ................................................................................................... 69

4.2.1. Ulaznični poslužitelj ........................................................................................... 69

4.2.2. Validacijski klijent .............................................................................................. 71

4.2.3. Validacijski poslužitelj ....................................................................................... 72

4.2.4. Validacija ulaznica .............................................................................................. 75

5. Zaključak ............................................................................................................................ 78

6. Literatura ............................................................................................................................ 79

7. Kratice ................................................................................................................................ 80

8. Dodaci ................................................................................................................................ 81

4

1. Uvod

Moderna znanost i tehnologije današnjice uvele su nas u digitalno doba.

Obavljanje komercijalnih djelatnosti pomoću računala ili mobilnog uređaja danas je jedna

od svakodnevnih ljudskih aktivnosti. Uzrok tome su učinkovitost i jednostavnost

poslovnih modela po kojemu se takve aktivnosti obavljaju. Tko je npr. papirnati novac

već odavno zamijenjen digitalnim objektima i bitovima, elektroničkim novcem u

elektroničkom poslovanju. Slično tome, usluga mobilnog poslovanja koja određuje

procese upravljanja mobilnim ulaznicama – usluga mobilnih ulaznica (engl. mobile

ticketing), danas može u potpunosti zamijeniti uporabu konvencionalnih papirnatih

ulaznica digitalnim mobilnim ulaznicama.

U ovom radu opisani su opći elementi potrebne infrastrukture, poslovni procesi i

tehnologije koje ostvaruju uslugu mobilnih ulaznica. Time je dan i okvir za izvedbu

praktičnog dijela rada; programsku implementaciju prototipnog sustava za validaciju

mobilnih ulaznica. Prije same implementacije sustava izvršeno je modeliranje

sigurnosnih rizika prema dizajnu sustava za validaciju, a nakon implementacije model je

revidiran i dopunjen.

Kako bi se ostvario potpuni životni ciklus usluge mobilnih ulaznica, dodatno je

izveden i sustav koji vrši izdavanje mobilnih ulaznica. Dvije spomenute cjeline, sustav za

validaciju mobilnih ulaznica (validacijska komponenta) i sustav za izdavanje mobilnih

ulaznica (ulaznična komponenta), čine programski sustav za simulaciju usluge mobilnih

ulaznica - e-Portir.

Diplomskom radu priloženo je programsko rješenje sustava e-Portir na CD

mediju.

5

2. Mobilno poslovanje

2.1. Kratka povijesna nota

Godine 1897. Talijan Guiliemo Marconni je prvi uspio proizvesti kontinuirani

bežični zvučni kontakt na velikoj udaljenosti (otprilike šest kilometara) putem radio

valova. Eksperiment se dogodio na brodu u Bristolskom kanalu, a Marconni je uspješno

poslao poruku „jeste li spremni“ u signalima Morseovog kôda prema primateljskoj radio

stanici na obali. Od tada pa do danas, bežične telekomunikacije evoluirale su od relativno

jednostavnih analognih tehnologija prve generacije, pa do modernih digitalnih

tehnologija treće i četvrte generacije. Krajem 2001. godine 14% svjetske populacije

posjedovalo je mobilne uređaje. U zadnjem desetljeću mobilni uređaji su evoluirali od

luksuza probranih do uređaja dostupnih svakome i gotovo neophodnih u svakodnevici.

Najveći prodor mobilnih uređaja i tehnologija dogodio se u Europi devedesetih godina

prošlog stoljeća prihvaćanjem globalnog standardnog sustava za mobilnu telefoniju –

GSM. Kako su tada mobilni telefoni (mobiteli) dominirali bežičnom glasovnom

komunikacijom, tako su ostali uređaji koji koriste bežičnu komunikaciju, kao npr. PDA i

prijenosna računala, doprinosili razvoju mobilnog poslovanja. S vremenom i razvojem

industrije, razlika u funkcionalnostima mobitela, PDA uređaja i prijenosnog računala

postajala je sve manja, a ta se tendencija nastavlja i danas. Procvat mobilnog poslovanja

dogodio se pojavom WAP tehnologije za mobilni pristup Internetu u drugoj generaciji

mobilne tehnologije. S 2000. godinom javlja se GPRS tehnologija, mogućnost paketskog

prijenosa podataka i stalne mrežne konekcije. Nekoliko godina nakon, javlja se treća

generacija mobilne tehnologije koja omogućava širokopojasni pristup Internetu,

mogućnosti mobilnog prijenosa različitog višemedijskog sadržaja, usluge temeljene na

geografskoj poziciji mobilnog korisnika, usluge ovisne o vremenskoj domeni, itd.

6

2.2. Definiranje mobilnog poslovanja

Izraz „mobilno poslovanje“ (engl. mobile commerce, m-commerce) označava

model trgovanja koji uključuje prijenos vlasništva ili prava na korištenje dobara i usluga,

a koji je iniciran i / ili završen korištenjem mobilnog pristupa uz pomoć komunikacijskog

uređaja. Misli se na model u kojem nema fizičkog transfera novca ili monetarnog

ekvivalenta.

Izraz „mobilno poslovanje“ se kroz izvore i literaturu opisuje različito, a

nedosljednost definicija uzrokuje dvojba je li mobilno poslovanje ograničeno samo na

telekomunikacijsku bežičnu mrežu ili se ono odnosi i na poslovanje kroz bežični pristup

bilo kojoj računalno posredovanoj mreži. U ovom radu prikloniti ćemo se proširenoj

definiciji koja podrazumijeva usluge mobilnog poslovanja usvojene kroz različite vrste

bežičnih i mobilnih mreža, te različite vrste mobilnih uređaja1. Konkretnije, misli se na

telekomunikacijske mreže; generacija 2G, 2.5G, 3G, 4G, dalje bežične WLAN i Wi-Fi2

mreže, WAP, Bluetooth, IrDA i dr., te mobilne uređaje kao što su mobitel, smartphone,

PDA, IP telefoni, Pocket PC i dr.

Možemo reći da mobilno poslovanje danas, zbog napretka tehnologije mobilnih

uređaja i mreža, u potpunosti ostvaruje i elektroničko poslovanje3 (kraće „e-poslovanje“,

engl. electronic commerce, e-commerce). No, postoji nekoliko karakteristika koje

određuju mobilno poslovanje i razlikuju ga od e-poslovanja4:

1. Mobilnost

a. Sloboda kretanja: mogućnost ostvarivanja mobilne usluge „u pokretu“

b. Sveprisutnost: mogućnost ostvarivanja mobilne usluge bilo gdje

c. Dostupnost: mogućnost ostvarivanja mobilne usluge bilo kada

2. Personalizacija: usluga se može prilagoditi za individualnog korisnika jer je

mobilni uređaj tipično vezan za samo jednu osobu

1 JONKER J., M-Commerce and M-Payment, Bedrijfswiskunde en informatica, 2003. 2 Wi-Fi – bežična tehnologija koja implementira više vrsta tehnologija IEEE 802.11 standarda 3 Elektroničko poslovanje – označava model trgovanja koji uključuje prijenos vlasništva ili prava na korištenje dobara i usluga putem Interrneta 4 E-COMMERCE WORKING PARTY, Considering the implications of M-commerce – A Consumer Perspective, Consumer Affairs Victoria, 2004.

7

3. Lokacijska svjesnost: lokacija korisnika je su svakom trenutku poznata

(ovisno o pristupnoj mreži)

S obzirom na komunikacijske tehnologije, mobilno poslovanje se ostvaruje kroz

osnovne usluge i kroz usluge s dodanom vrijednošću (engl. value-added services, kraće

VAS). VAS označava usluge koje temeljnim uslugama i infrastrukturi dodaju vrijednost

gledajući tehnološke i komercijalne čimbenike. Primjerice, u mobilnoj

telekomunikacijskog mreži glasovni poziv je osnovna usluga, a VAS usluge poput SMS-a

i MMS-a koriste istu infrastrukturu mreže, tehnološki i funkcionalno se razlikuju, te

imaju različit sustav naplate usluge od osnovne usluge. Također, sve usluge koje dodatno

proširuju postojeću uslugu s dodanom vrijednošću smatramo VAS uslugom (primjerice

usluga u kojoj SMS porukom plaćamo parkirno mjesto je VAS usluga u odnosu na

osnovnu SMS uslugu).

Spomenimo neke od danas dostupnih usluga mobilnog poslovanja podijeljenih u

nekoliko tematskih kategorija:

- Informacijske usluge (npr. novosti, vremenska prognoza, itd.)

- Mobilno bankarstvo (engl. m-banking): banke i ostale financijske institucije

pružaju mogućnosti integriranja svojih usluga u mobilno poslovanje

- Lokacijski svjesne usluge (npr. GPS, praćenje vozila, praćenje ljudi, itd.)

- Mobilna kupovina digitalnih sadržaja

- Mobilna kupovina

- Multimedijske usluge

- Zabavne usluge

- Peer-to peer usluge

- Mobilni marketing i oglašavanje

- Usluge mobilnih ulaznica (engl. mobile ticketing, kraće m-ticketing)

8

2.3. Usluga mobilnih ulaznica

Pojam „ulaznica“ – predstavlja dokument ili certifikat koji svojem vlasniku daje

neka određena prava5.

„Usluga mobilnih ulaznica“ naziv je za uslugu u mobilnom poslovanju koja

uključuje procese (kronološkim redom izvršavanja): 1. izdavanja, 2. transformacije i 3.

validacije ulaznica izvršavane korištenjem mobilnog uređaja:

1. Izdavanje ulaznice: Korisnik komunicira s komponentom za izdavanje

ulaznica i izvršava potrebne operacije (npr. plaćanje i sl.) nakon kojih mu se

izdaje ulaznica

2. Transformacija ulaznice: Korisnik dobiva ulaznicu u digitalnom formatu i

pohranjuje ju na mobilni uređaj.

3. Validacija ulaznice: Korisnik izlaže ulaznicu mehanizmima za provjeru

valjanosti ulaznice i ostvaruje prava i / ili usluge koja nosi valjana ulaznica.

Ulaznica koja sudjeluje u procesima usluge mobilnih ulaznica jest mobilna

ulaznica. Usluga mobilnih ulaznica reducira proizvodne i distribucijske troškove

klasičnih papirnih ulaznica, te pruža i korisniku i pružatelju usluge praktičnije načine

upravljanja ulaznicama. Prilagođavanjem usluge korisniku empirijski je pokazano da se

povećava zadovoljstvo korisnikova korištenja usluge, a povećanje dostupnosti usluge

preko područja mobilnog i elektroničkog poslovanja pružateljima usluge donosi veću

potencijalnu komercijalnu dobit.

Životni ciklus usluge mobilnih ulaznica čine događaji:

1. Pokretanje usluge

2. Konkurentno izvršavanje skupa iterativnih sljedova procesa usluge: izdavanje,

transformacija i validacija ulaznice

3. Zaustavljanje usluge

Akteri u životnom ciklusu usluge mobilnih ulaznica su:

1. Pružatelj usluge

2. Korisnik usluge

5 Prema Oxford Advanced Learners Dictionary, Oxford University Press 1995.

9

3. Mobilna ulaznica

4. Sustav: ulaznična komponenta, validacijska komponenta

Primjer 2.1.: Radi bolje ilustracije, opisan je tipični slijed događaja u životnom ciklusu

konkretne, pojednostavljene usluge mobilnih ulaznica. Pretpostavimo da mobilnu

ulaznicu predstavlja SMS poruka:

1. Korisnik se informira o načinu kupovine mobilne ulaznice za koncert

2. Korisnik prema uputama mobitelom šalje potrebne podatke (šifru događaja – ID, broj

željenih ulaznica - Q) za izdavanje ulaznice u posebno formatiranoj SMS poruci:

„ID:777, Q:1“.

3. Pružatelj usluge prima korisnikove podatke, tereti njegov pretplatnički račun iznosom

koji odgovara cijeni jedne ulaznice za koncert, te šalje na njegov broj SMS poruku s

tekstualnim kodom: 123456789. Ta SMS poruka je mobilna ulaznica za koncert.

4. Korisnik na dan koncerta odlazi do koncertne dvorane i pruža svoj mobitel prema

uređaju s optičkim skenerom. Skener detektira broj 123456789 u otvorenoj SMS

poruci i povezuje se sa centralnom bazom podataka u kojoj pronalazi podatke o

mobilnoj ulaznici sa šifrom 123456789. Uređaj prepoznaje mobilnu ulaznicu kao

valjanu.

5. Korisnik ulazi u koncertnu dvoranu

Tehnološka i funkcionalna realizacija procesa usluge mobilnih ulaznica je

raznovrsna i njihova izvedba često interferira s elementima procesa drugih usluga

elektroničkog poslovanja; svi procesi i artifakti usluge mobilnih ulaznica ne moraju

nužno biti realizirani preko mobilnog uređaja (opisano u primjeru 2.2.).

Primjer 2.2.: U procesu nabave mobilne ulaznice, pružatelj usluge mobilnih ulaznica

omogućio je i nabavu ulaznica preko svoje Internet stranice. Korisnik upisuje

pretplatnički mobilni broj u formular na stranici i po plaćanju mu se njegova mobilna

ulaznica šalje na broj kao SMS poruka (Sl. 2.1.). U navedenom primjeru nabava mobilne

ulaznice odvija se preko Interneta, pa se cijela usluga ne odvija u potpunosti preko

mobilnog uređaja (kako je spomenuto u definiciji usluge mobilnih ulaznica).

10

Sl. 2.1. Ilustracija uz primjer 2.2.

2.3.1. Mobilna ulaznica

Mobilna ulaznica je ulaznica koja sudjeluje u procesima usluge mobilnih

ulaznica. Trojka parametara koji određuju mobilnu ulaznicu su:

1. Informacija ulaznice

2. Forma: digitalni format u kojemu je oblikovna informacija ulaznice

3. Način dostave: tehnologija medija u kojemu je sadržana forma ulaznice

Entitet mobilne ulaznice ima karakteristike mobilnog poslovanja: mobilnost (u

procesima usluge) i mogućnost personalizacije prema korisniku usluge. Mobilna ulaznica

nije tehnološki standard, no elementi njezine forme i načina dostave najčešće jesu

standardizirane veličine. Iz danas dostupnih komercijalnih usluga mobilnih ulaznica i

standarda mobilnog poslovanja prepoznajemo moguće kombinacije konstrukcije mobilne

ulaznice prema parametrima:

11

Sl. 2.2. Prikaz mogućih konstrukcija mobilne ulaznice prema parametrima

Žutom bojom (Sl. 2.2.) označene su moguće forme ulaznice, dok su sivom

označeni mogući načini dostave ulaznice. Svaka mobilna ulaznica sadržava samo jedan

par forma - način dostave. Linijama na slici prikazane su moguće kombinacije parova

[forma, način dostave]. Slaganje parova ovisi o tehnološkoj izvedbi forme i načina

dostave. Tako npr. obična SMS poruka ne može sadržavati grafičke elemente već samo

niz znakova. Informacija ulaznice prikazana je formom ulaznice. U formalnom opisu,

informacija ulaznice je zapravo niz bitova raspoređenih po nekom pravilu unutar forme

ulaznice, forma ulaznice je prezentacijski sloj informacije ulaznice koji bitove prikazuje

na određeni način, a način dostave je transportna jedinica koja sadržava formu.

Sl. 2.3. Shema mobilne ulaznice izgrađene prema određenim parametrima

Forma ulaznice

Razlikujemo tri forme ulaznice: 1. znakovna, 2. grafička, 3. kombinacija

znakovne i grafičke. Forma bitove u mobilnoj ulaznici prikazuje kao niz znakova ili, ako

Informacija ulaznice – niz bitova (heksadecimalni prikaz): 55 4C 41 5A 4E 49 43 41 Forma ulaznice – niz znakova (ASCII kodirani znakovi): „ULAZNICA“ Način dostave – SMS poruka koja sadržava formu ulaznice

12

su tako formatirani, kao grafičke elemente. U grafičkoj izvedbi forme mobilnih ulaznica,

najčešće korišten grafički element ulaznice je barkod (poglavlje 2.3.2.).

Načini dostave

- SMS: Podržava znakovnu formu i to maksimalno do 160 znakova u nizu. Ulaznica je

sadržana u SMS tekstualnoj poruci.

- RFID: Podržava znakovnu formu. Informacija ulaznice pohranjuje se na RFID čipu

(RFID tagu) ugrađenom u mobilni uređaj. Prijenos informacije na čip vrši se posebno

namijenjenim aplikacijama instaliranim na mobilni uređaj.

- Smart messaging (SM): Podržava monokromatsku grafičku formu ulaznice. Ulaznica

je sadržana u nekoliko povezanih SMS poruka koje tvore grafički element.

- EMS: Podržava tekstualnu i monokromatsku grafičku formu ulaznice. Ulaznica je

sadržana u EMS grafičkoj poruci.

- MMS: Podržava obje forme. Ulaznica je sadržana u MMS poruci.

- WAP push: Podržava obje forme. Ulaznica je sadržana unutar WAP Internet stranice.

- WAP: Podržava obje forme. Ulaznica je sadržana unutar WAP Internet stranice.

- E-mail: Podržava obje forme. Ulaznica je sadržana u e-mail poruci.

2.3.2. Barkod forma ulaznice

Barkod je vizualna reprezentacija podataka. Grafički element prvih barkodova

koji su se pojavili na tržištu, tvore paralelne vertikalne tamne i svijetle linije različitih

debljina. Informacija koju nosi takav barkod čita se iz jedne plošne dimenzije

(horizontalne), te je takav barkod retrospektivno nazvan 1D (jednodimenzionalan)

barkod.

Sl. 2.4. 1D (lijevo) i 2D (desno) barkod. Kodirani tekst je: "DIPLOMSKI RAD"

13

Danas su, osim 1D barkodova, u upotrebi i 2D barkodovi, te 3D barkodovi. 2D

barkodovi informaciju nose u dvije dimenzije plošne ravnine, a 3D barkodovi, osim

pohrane informacije u dvije dimenzije, nose informaciju predstavljenu bojom koja čini

treću dimenziju. 2D i 3D barkodovi tako konstruirani mogu nositi znatno veću količinu

informacija od 1D kodova. 1D, 2D i 3D barkodova ima više vrsta i konstrukcije

pojedinih često se u potpunosti razlikuju.

Barkod je optički, strojno čitljiv kod i to ga čini pogodnim formatom za prikaz

podataka koji se prenose s jednog medija na drugi metodama optičkog raspoznavanja

uzorka. Barkod slika nastaje kodiranjem ulaznih podataka prema određenom algoritmu.

Podaci dobiveni optičkim raspoznavanjem barkoda (dekodiranjem) trebaju biti jednaki

ulaznima. 1D barkodovi (linearni barkodovi) konstruirani su za lasersko optičko čitanje,

dok je za čitanje 2D i 3D barkodova potrebno fotografsko skeniranje slike barkoda.

Kako se usluga mobilnih ulaznica odvija preko mobilnog uređaja, konstrukcija i

izgled ulaznice u mnogome ovisi i treba se prilagoditi samom mobilnom uređaju u

kojemu će ulaznica biti pohranjena. Teži se konstrukciji univerzalne ulaznice, opet

pogodne za prikaz na što više različitih vrsta mobilnih uređaja na tržištu. Karakteristike

koji određuju mobilne uređaje, a utječu konstrukciju ulaznice su:

- Memorijski kapacitet

- Podrška za pohranu određenog formata podataka

- Vrsta, veličina, kvaliteta ekrana

- Procesorske mogućnosti uređaja

Zbog tih karakteristika, uvodi se barkod kao forma mobilne ulaznice jer su se,

zbog svojih značajki, pokazali kao odgovarajuća forma za prikaz podataka na mobilnim

uređajima:

- Moguće je pohraniti veliku količinu podataka u grafiku veličine optimalne za

mobilni uređaj

- Format grafike barkoda može se prikazati na većini mobilnih uređaja

dostupnih na tržištu

- Zbog jednostavne izvedbe pogodni su za prikaz na ekranima mobilnih uređaja

- Prikaz barkodova ne zahtjeva instaliranje nekih dodatnih aplikacija na

mobilne uređaje

14

Svrha barkoda kao grafičkog elementa ulaznice, je povećanje učinkovitosti čitanja

informacije ulaznice, kao i unapređenje tehnološke izvedbe mobilne ulaznice:

- izvedba 2D barkodova, zbog mogućnosti pohrane velikih količina podataka,

uključuje i podatke generirane posebnim algoritmima, potrebne za ispravljanje

potencijalnih pogrešaka pri čitanju informacije barkoda optičkim uređajem

- zbog mogućnosti pohrane velikih količina podataka informacija ulaznice

može sadržavati potpune podatke o ulaznici (suprotno izvedbi u kojoj je

informacija zapravo referenca na potpune podatke izvan ulaznice, u nekom

vanjskom spremištu podataka)

Pregled nekih 2D barkodova

U tablici 2.1. dan je pregled 2D barkodova koji se koriste za prikaz mobilne

ulaznice u danas dostupnim komercijalnim uslugama mobilnih ulaznica. Dani su i podaci

maksimalnog kapaciteta kodiranih podataka ovisno o njihovoj vrsti; kodirani samo

numerički znakovi (brojevi), kodirani samo alfanumerički znakovi, te kodirani binarni

podaci. Tablica 2.1. Pregled nekih 2D barkodova korištenih uslugama mobilnih ulaznica

Naziv Primjer simbola Maksimalni kapacitet pohranjenih podataka

Proizvodnja Binarni [byte]

Alfanumerički [broj znakova]

Numerički [broj znakova]

Maxi Code

93 138 1987. Omniplanar

DataMatrix

1556 2335 3116 1989.

International Data Matrix

PDF417

1108 1850 2710 1992.

Symbol Technologies

QR Code

2953 4296 7089 1994. Denso Wave

Aztec

1914 3067 3832 1995. Welch Allyn

15

2.3.3. Validacija mobilne ulaznice

Validacija mobilne ulaznice je završni proces usluge mobilnih ulaznica i izvršava

ga validacijska komponenta. Validacijom se utvrđuje valjanost mobilne ulaznice.

Validacija mobilne ulaznice sastoji se od slijednih procesa:

1. provjera ulaznice po logici validacije

2. provjera stanja ulaznice

Kriterij valjanosti ulaznice definira se na početku životnog ciklusa usluge

mobilnih ulaznica.

Izdavanje ulaznice vrši ulaznična komponenta. Ona formulira informaciju

ulaznice tako da validacijska komponenta „može zaključiti“ je li ulaznica valjana.

Poslovna logika, po kojoj validacijska komponenta određuje je li ulaznica valjana –

logika validacije, treba biti usklađena na razini cijelog sustava (trebaju ju „poznavati“ i

ulaznična i validacijska komponenta). Drugim riječima, ulaznična komponenta

informaciju ulaznice izvodi prema pravilima logike validacije, tako da ju validacijska

komponenta može validirati.

Primjer 2.3.: U pojednostavljenom sustavu mobilnih ulaznica, logika validacije

izvedena je tako da validacijska komponenta označava valjanima one ulaznice koje nose

informaciju kao brojčanu šifru s nizom početnih brojeva: "123". Ulaznična komponenta

izdaje mobilne ulaznice s šiframa: "12355417" i druga "12384517". Potom validacijska

komponenta validacijom utvrđuje da su obje ulaznice valjane. (primjer ne opisuje

provjeru stanja ulaznica)

Centralizirana i neovisna validacija

Validacija mobilnih ulaznica zahtjeva posebne mehanizme za praćenje trenutnog

stanja ulaznice kako ne bi došlo do zloporabe ulaznica (iskorištavanja iste ulaznice više

puta). Mobilna ulaznica, s obzirom na kriterij valjanosti, ima dva osnovna stanja: valjana

ulaznica i ne valjana ulaznica. Valjanu ulaznicu još je k tome moguće općenito odrediti

kao jednokratno, višekratno i permanentno (stalno) valjanu, te ulaznicu koja je valjana uz

neke posebno definirane uvjete. Validacijom valjanih ulaznica stanje se mijenja, dok

16

validacijom ne valjane i permanentno valjane ulaznice stanje ostaje isto. U tablici 2.2.

prikazana su stanja ulaznica s obzirnom na broj izvršenih procesa validacije.

Tablica 2.2. Moguća stanja ulaznica u odnosu na izvršen process validacije

Početno stanje ulaznice

Stanje ulaznice nakon jedne validacije

Stanje ulaznice nakon N-te validacije (N>0)

Jednokratno valjana Ne valjana Ne valjana Višekratno valjana (X puta valjana, X>0)

X-1 puta valjana X-N puta valjana za N<X Ne valjana za N>=X

Permanentno valjana Permanentno valjana Permanentno valjana Posebno stanje - - Ne valjana Ne valjana Ne valjana

Karakteristika sustava mobilnih ulaznica je namjena velikom broju korisnika,

dakle, postavljaju se zahtjevi skalabilnosti i raspoloživosti za funkcionalnosti

komponenata sustava koje opslužuju korisnike – ulazničnu i validacijsku. Kod procesa

validacije ulaznica, velika je vjerojatnost da će validacijska komponenta sustava u

kratkom vremenskom okviru biti opterećena zahtjevima za validacijom ulaznica velikog

broja korisnika. Slijedni događaji; izdavanje ulaznice i validacija te iste ulaznice, također

se mogu odviti u vrlo kratkom vremenskom razmaku. Zbog toga je potrebno izvesti

sustav takav da validacijska komponenta u svakom trenutku od izdavanja ulaznice može

ispravno odrediti stanje ulaznice. Bazu stanja izdanih ulaznica validacijska komponenta

dohvaća implicitno ili eksplicitno s ulaznične komponente. Informaciju s mobilne

ulaznice dohvaća dio validacijske komponente - validacijski klijent.

Validacijskom klijentu informaciju ulaznice je moguće prenijeti:

- vizualnom inspekcijom ulaznice i ručnim unosom informacije ulaznice

- optičkim računalnim skeniranjem

- bežičnim prijenosom s mobilnog uređaja validacijskom klijentu (Bluetooth,

IrDA, RFID, itd.).

17

Postoje dva načina izvedbe validacije ulaznica u sustavu mobilnih ulaznica6:

1. Centralizirana validacija: baza stanja ulaznica nalazi se u centraliziranoj komponenti

u sustavu (validacijska ili ulaznična komponenta)

Sl. 2.5. Shema centralizirane validacije ulaznica

Validacijski poslužitelj je dio validacijske komponente sa zadaćom dohvaćanja i

praćenja stanja ulaznica. Mogući načini na koje validacijski poslužitelj može

dohvaćati podatke o ulaznicama za koje se trenutno zahtijeva validacija jesu:

a) Prosljeđivanje svakog zahtjeva za validacijom jedinstvene ulaznice izravno prema

ulazničnoj komponenti, koja sadrži bazu svih izdanih ulaznica: takvom izvedbom

osigurano je da se za svaku ulaznicu u svakom trenutku može ispravno utvrditi

početno stanje (tj. je li uopće izdana). Negativna posljedica izvedbe je stroga

centralizacija sustava – validacijska komponenta je strogo ovisna o ulazničnoj

komponenti i postaje kritična komponenta sustava. Zahtijeva se postojanje

pouzdane, sigurne i skalabilne komunikacijske veze između validacijske i

ulaznične komponente.

b) Jednokratno osvježavanje baze stanja ulaznica: baza stanja ulaznica na

validacijskom poslužitelju se osvježava samo jednom, te se nakon tog trenutka ne

mogu validirati ulaznice izdane nakon osvježavanja. Prednost ovog načina je

jednostavnost izvedbe, dok je mana nemogućnost validacije ulaznica izdanih od

određenog vremenskog trenutka. (npr. sve ulaznice za koncert se trebaju prodati

prije nego što posjetitelji počnu ulaziti u koncertnu dvoranu)

6 Masabi – Secure Mobile Applications, http://www.masabi.com/

18

c) Periodičko osvježavanje baze stanja ulaznica: baza stanja ulaznica na

validacijskom poslužitelju se osvježava svaki određeni period vremena kako bi se

prikupljali podaci o novoizdanim ulaznicama. Negativna posljedica izvedbe je,

kao i u prvom načinu, stroga centralizacija sustava. Također, ne može se egzaktno

odrediti vremenski interval osvježavanja baze kod kojeg bi validacijska

komponenta u svakom trenutku mogla odrediti stanje svake novoizdane ulaznice.

2. Neovisna validacija: kod ovakve izvedbe validacije komunikacijska veza između

validacijske i ulaznične komponente tijekom procesa validacije nije potrebna. Svi

podaci potrebni za validaciju sadržani su u informaciji izdane mobilne ulaznice koja

se validira, a zadaća validacijskog poslužitelja je održavanje baze stanja validiranih

ulaznica. U koraku pokretanja usluge mobilnih ulaznica s neovisnom validacijom

ulaznična komponenta treba definirati i razmijeniti (pregovarati) s validacijskom

komponentom potrebne sigurnosne postavke koje omogućuju neovisnu validaciju

(objašnjeno u nastavku).

Sl. 2.6. Shema neovisne validacije ulaznica

Za izvedbu neovisne validacije potrebno je u ulazničnu i validacijsku komponentu

implementirati sigurnosne mehanizme koji će se koristiti za izdavanje odnosno

validaciju ulaznice. Kod neovisne validacije, prije provjere stanja ulaznice, potrebno

je izvršiti verifikaciju ulaznice. Verifikacija je proces neovisne validacije kojim se

određuje je li ulaznica autentična tj. je li (upravo) ulaznična komponenta sustava

(uopće) izdala ulaznicu. Informaciju mobilne ulaznice treba oblikovati tako da

validacijska komponenta može izvršiti verifikaciju ulaznice bez prethodne

komunikacije sa ulazničnom komponentom.

19

Autentičnost mobilne ulaznice osigurava se umetanjem sigurnosne

informacije u informaciju ulaznice. Taj proces zovemo zaštita ulaznice i izvršava ga

ulaznična komponenta. Sigurnosnu informaciju čine podaci šifrirani simetričnom ili

asimetričnom kriptografijom.

1. Zaštita ulaznice simetričnom kriptografijom:

a. Šifriranje cijele informacije ulaznice: ulaznična komponenta šifrira

simetričnim ključem cijelu informaciju ulaznice. Verifikaciju validacijska

komponenta izvodi dešifriranjem šifriranog istim simetričnim ključem. Nakon

uspješne verifikacije nastavljaju se procesi validacije.

b. Potpisivanje ulaznice: ulaznična komponenta izvodi šifriranje cijele

informacije ili samo nekog njezinog dijela simetričnim ključem. Potom se

dobivena sigurnosna informacija (potpis) dodaje originalnoj informaciji

ulaznice. Verifikaciju validacijska komponenta izvodi provjerom potpisa

ulaznice. Nakon uspješne verifikacije nastavljaju se procesi validacije.

Razmjena sigurnosnih postavki prilikom pokretanja usluge uključuje razmjenu

istog simetričnog ključa između ulaznične i validacijske komponente.

2. Zaštita ulaznice asimetričnom kriptografijom (digitalno potpisivanje ulaznice):

koristi se PKI infrastruktura za ostvarivanje sigurnosnih mehanizama. Ulaznična

komponenta šifrira informaciju ulaznice privatnim ključem i dodaje sigurnosnu

informaciju originalnoj informaciji ulaznice (digitalni potpis). Verifikaciju

validacijska komponenta izvodi provjerom digitalnog potpisa ulaznice koristeći

javni ključ. Nakon uspješne verifikacije nastavljaju se procesi validacije.

Razmjena sigurnosnih postavki prilikom pokretanja usluge uključuje distribuciju

javnog ključa validacijskim komponentama.

Osim centralizirane i neovisne validacije, moguće je izvesti sustave koji

kombiniraju navedena dva osnovna načina validacije.

20

3. Sustav e-Portir

Svrha e-Portir prototipnog programskog sustava jest simulacija usluge mobilnih

ulaznica kroz sve faze životnog ciklusa usluge. Sustav čine tri programske cjeline:

validacijski klijent i validacijski poslužitelj koji čine validacijsku komponentu, te

ulaznični poslužitelj koji čini ulazničnu komponentu. Sustav koristi izvedbu neovisne

validacije sa zaštitom ulaznice asimetričnom kriptografijom. Korištena forma mobilne

ulaznice je dvodimenzionalni barkod. Nakon početne inicijalizacije pokreću se

programske cjeline sustava i sustav je spreman za izvršavanje procesa usluge mobilnih

ulaznica.

U sustavu e-Portir sve procese usluge mobilnih ulaznica korisnik ne obavlja

izričito pomoću mobilnog uređaja. Tako korisnik mobilnu ulaznicu pribavlja preko web

sučelja ulazničnog poslužitelja. Opseg ovog rada ne obuhvaća realizaciju poslovnih

procesa elektroničkog plaćanja za izdanu ulaznicu, kao ni procese prijenosa ulaznice na

mobilni uređaj. Prijenos ulaznice na medij vrši se ručno. Ulaznicu e-Portira predstavlja

svaki medij koji sadržava formu ulaznice (npr. mobilni uređaj, prijenosna memorijska

jedinica, itd.). Uzmimo za primjer korisnika koji želi pribaviti ulaznicu za koncert. On

preko web sučelja ulazničnog poslužitelja predaje potrebne podatke za koje mu ulaznični

poslužitelj izdaje jednokratnu ulaznicu za koncert. Potom se vrši prijenos na medij;

korisnik ručno prebacuje ulaznicu na svoj mobilni uređaj (pohranjuje ju u memoriju

uređaja). Korisnik po ulaznicu nije trebao fizički doći na kakav terminal, već su jedini

preduvjeti u ovom slučaju bili omogućen pristup web sučelju ulazničnog poslužitelja i

posjedovanje odgovarajućeg medija za ulaznicu. Sljedeći korak je validacija ulaznice.

Kako se radi o ulaznici zaštićenoj asimetričnom kriptografijom, kroz validaciju je

potrebno izvršiti verifikaciju i provjeru stanja ulaznice. Korisnik odlazi do koncertne

dvorane kako bi poslušao koncert. Svoj mobitel, koji sadrži ulaznicu prikazanu na

ekranu, prinosi uređaju koji skenira barkod ulaznice, dekodira ga i obavlja verifikaciju

nad dobivenim podacima (validacijski klijent). Nakon verifikacije validacijski klijent

prosljeđuje ulaznicu validacijskom poslužitelju kako bi se utvrdilo trenutno stanje

21

ulaznice. Validacijski poslužitelj utvrđuje da u bazi stanja nema zapisa o ulaznici, pa

upisuje ulaznicu u bazu podataka i šalje validacijskom klijentu odgovor da je ulaznica

valjana. Korisnik ulazi u koncertnu dvoranu i (još jednom) prepušta svoje uho notama

violine i orkestra.

U scenariju gdje korisnik pokuša krivotvoriti ulaznicu ili iskoristiti već korištenu

jednokratnu ulaznicu, ulaz u koncertnu dvoranu biti će mu odbijen po verifikaciji,

odnosno provjeri stanja ulaznice.

22

3.1. Zahtjevi izvedbe sustava

3.1.1. Inicijalni zahtjevi izvedbe

1. Izgraditi ulazničnu i validacijsku komponentu sustava mobilnih ulaznica

2. Izvesti administratorska sučelja za komponente sustava

3. Napraviti model sigurnosnih rizika validacijske komponente sustava

3.1.2. Funkcijski zahtjevi

Funkcijski zahtjevi koji trebaju biti zadovoljeni u izvedbi prototipnog sustava

mobilnih ulaznica e-Portir su:

1. Omogućiti generiranje forme ulaznice kao niz znakova

2. Omogućiti generiranje forme ulaznice kao 2D barkod

3. Ostvariti praktičnu sigurnosnu zaštitu visokog stupnja za ulaznice prema

sigurnosnim zahtjevima cjelovitosti i autentičnosti

4. Mobilnu ulaznicu realizirati tako da bude prenosiva, ne vezana za jedinstvenog

korisnika ili medij ulaznice (npr. mobitel)

5. Omogućiti neovisnu validaciju ulaznica (validacijska i ulaznična komponenta

moraju biti neovisni entiteti)

6. Omogućiti validaciju mobilnih ulaznica s više validacijskih klijenata za isti

događaj istovremeno

7. Omogućiti validaciju ulaznice za obje forme ulaznice

23

3.2. Arhitektura sustava

Troslojna arhitektura (engl. three-tier) sustava e-Portir izgrađena je u tri logički

odvojena glavna sloja sustava; prezentacijski, aplikacijski i podatkovni sloj. U tako

raslojenom sustavu olakšan je neovisan, komponentni razvoj svakog sloja posebno.

Prezentacijski sloj jest samo grafičko korisničko sučelje sustava (engl. graphical user

interface - GUI). Aplikacijski sloj vrši procesiranje ulaznih parametara sa prezentacijskog

sloja i izvodi cijelu poslovnu logiku sustava (drugi naziv je sloj poslovne logike, engl.

bussiness logic layer - BLL), te pristupa podatkovnom sloju. Podatkovni sloj čine

mehanizmi upravljanja i pohrane podataka.

e-Portir se sastoji od tri komponente:

1. Ulaznični poslužitelj

2. Validacijski klijent

3. Validacijski poslužitelj

Ulazničnu komponentu u sustavu čini ulaznični poslužitelj. Validacijsku

komponentu čine validacijski poslužitelj i jedna ili više instanci validacijskih klijenata sa

ostvarenom komunikacijskom vezom prema validacijskom poslužitelju. Međusobnu

konekciju validacijskih klijenata nije potrebno ostvariti.

Prezentacijski sloj komponenata čini grafičko korisničko sučelje aplikacija (GUI)

prema korisniku. Vezu GUI-a i aplikacijskog sloja realizira komunikacijski među-sloj

(GUI-BLL) u aplikacijskom sloju.

24

Sl. 3.1. Shema arhitekture sustava e-Portir

25

Ulaznični poslužitelj

Funkcionalnosti ulazničnog poslužitelja izložene su korisniku usluge u životnom

ciklusu usluge mobilnih ulaznica:

- Prihvat korisnikovih podataka: GUI komponenta vrši prihvat unesenih korisnikovih

podataka potrebnih za generiranje mobilne ulaznice

- Generiranje koda ulaznice: koder ulaznice generira kod ulaznice ili znakovnu formu

ulaznice na temelju unešenih podataka korisnika po definiranoj logici validacije

- Kodiranje barkoda ulaznice: koder barkoda na temelju koda ulaznice generira barkod

formu ulaznice

Validacijski klijent

Funkcionalnosti validacijskog klijenta izložene su pružatelju usluge u životnom

ciklusu usluge mobilnih ulaznica:

- Skeniranje mobilne ulaznice: video adapter GUI sloja upravlja hardverskim optičkim

uređajem za skeniranje mobilne ulaznice

- Dekodiranje barkoda: digitalnu formu barkoda dekodira dekoder barkoda u znakovnu

formu ulaznice

- Verifikacija ulaznice: verifikaciju izvršava verifikator ulaznice

- Komunikacija s validacijskim poslužiteljem: konekcijski sloj ostvaruje komunikaciju

s komponentom validacijskog poslužitelja

Validacijski poslužitelj

Funkcionalnosti validacijskog poslužitelja izložene su validacijskim klijentima u

životnom ciklusu usluge mobilnih ulaznica:

- Komunikacija s validacijskim klijentima: klijentski poslužitelj ostvaruje

komunikacijsku vezu s validacijskim klijentima

- Provjera stanja ulaznice: provjeru stanja ulaznice izvršava validator ulaznice

- Pristup podatkovnom sloju: sloj pristupa podacima ostvaruje komunikaciju s

RDBMS-om i vrši operacije nad podacima u bazi podataka.

26

3.3. Tehnologija sustava

Sustav e-Portir izgrađen je i povezan u cjelinu pomoću nekoliko tehnologija.

Sl. 3.2. Shema tehnologija sustava e-Portir kroz troslojni model arhitekture

Horizontalni presjeci na slici 3.2. prikazuju korištene tehnologije u izvedbi

sustava kroz troslojnu arhitekturu sustava. Vertikalni presjeci „Validacijski poslužitelj“,

„Validacijski klijent“ i „Ulaznični poslužitelj“ prikazuju tehnologije korištene u

implementaciji pojedinih komponenata sustava.

3.2.1. Prezentacijski sloj

Tehnologije kojima je izveden prezentacijski sloj su Adobe Flex (ulaznični

poslužitelj), te Adobe AIR (validacijski klijenti i validacijski poslužitelj).

Adobe Flex

Adobe Flex je programska razvojna okolina koja obuhvaća nekoliko tehnologija:

Flash, MXML, ActionScript. Aplikacije u Flexu razvijene su pomoću MXML i

ActionScript jezika. Bogata biblioteka klasa Flex razvojne okoline napisana je u

ActionScriptu i sadržana u „mx“ paketu klasa koje su, u procesu prevođenja Flex

aplikacije, uključene u izvršnu „.swf“ Flash datoteku koja nastaje prevođenjem. Kod

prevođenja, Flex aplikacija se, točnije kolekcija ActionScript datoteka, prevodi u

27

ActionScript bytecode. Ona se može izvršavati samo u okolini s instaliranim Flash

runtimeom. To je datoteka s .swf ekstenzijom, koju izvršava Adobe Flash virtualni stroj

(Flash virtual machine - FVM) unutar aplikacije Flash Player. Prevedeni ActionScript

kod (ActionScript bytecode) izvršava ActionScript virtualni stroj (ActionScript virtual

machine - AVM) koji je ugrađen u FVM.

U razvoju e-Portira korištena je Flex 3 inačica Flexa koja koristi ActionScript 3.0

jezik (kraće AS3, definiran ECMA-2627 standardom). Za pokretanje AS3 potreban je

ActionScript virtual machine 2 (AVM2) kojega podržava inačica 9 Flash virtualnog stroja

(Flash 9.0) ili inačice više od te.

Adobe AIR

Adobe AIR (engl. Adobe integrated runtime) je višeplatformni runtime koji omogućava

izvršavanje aplikacija prevedenih u AIR bytecode. Nadalje, AIR aplikacije mogu biti

kreirane i prevođenjem koda nastalog u Flex razvojnoj okolini. Ono što razlikuje AIR

aplikaciju od Flash aplikacije je to da za AIR aplikaciju, po instaliranju AIR runtimea,

nije potrebna nikakva dodatna aplikacija za pokretanje (aplikacija se pokreće samostalno

unutar AIR virtualnog stroja), što nije slučaj s Flash aplikacijama (moraju biti pokrenute

Flash playerom). AIR aplikacija se instalira i pokreće lokalno unutar operacijskog sustava

i nema sigurnosne restrikcije Flash sandboxa koje ima Flash aplikacija, poput pisanja na

lokalni disk, među-aplikacijske komunikacije, pristupa nekim funkcijama operativnog

sustava itd.

3.2.2. Aplikacijski sloj

Aplikacijski sloj validacijske komponente sustava izveden je u programskom

jeziku Java. Kako su prezentacijski i aplikacijski sloj izvedeni u različitim tehnologijama

bilo je potrebno uspostaviti pouzdani komunikacijski kanal između ta dva sloja.

Komunikacijski kanal izveden je pozivima udaljenih procedura (engl. remote procedure

call, kraće RPC), s prezentacijskog sloja (Flexa i AIR-a) prema aplikacijskom (Java).

Tehnologija kojom je ostvaren most je Adobe BlazeDS (engl. Blaze data services).

7 http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

28

Ulaznična komponenta izvedena je također u svim prethodno navedenim tehnologijama

uz dodatak dijela komponente izvedene u skriptnom jeziku PHP.

Java

Java je programski jezik neovisan o platformi. Java programski kod prevodi se u

Java bytecode, a interpretira ga Java virtualni stroj (engl. Java virtual machine). Sustav e-

Portir koristi 1.6. inačicu virtualnog stroja tvrtke Sun (JDK 1.6.)

Adobe BlazeDS

BlazeDS je poslužiteljska aplikacija izvedena u Javi i pokrenuta unutar J2EE

(engl. Java 2 Platform Enterprise Edition) kompatibilnog web poslužitelja koja

omogućava komunikaciju Java i Flex/AIR/Flash klijentskih aplikacija. Klijentske

aplikacije preko BlazeDS-a komuniciraju sa Java aplikacijama pokrenutima na

poslužitelju koristeći pozive udaljenih procedura (RPC). Za prijenos poziva i odgovora

koristi se protokol AMF3 (engl. Action message format version 3) preko transportnog

protokola HTTP. AMF je binarni protokol i njegove poruke su binarni objekti

serijalizirani na klijentskoj (ActionScript objekti) odnosno poslužiteljskoj strani (Java

objekti). Prednost korištenja BlazeDS naspram drugih tehnologija (npr. SOAP, XML-

RPC, itd.) je velika brzina protokola AMF postignuta binarnom serijalizacijom i malom

veličinom AMF paketa, te mogućnost mapiranja ActionScript i Java objekata. BlazeDS je

besplatna aplikacija otvorenog koda (engl. open source).

PHP

PHP je skriptni objektno orijentirani programski jezik. U e-Portir sustavu PHP je

korišten u sprezi sa HTTP poslužiteljem koji upravlja zahtjevima za izvršavanjem skripti

prema PHP interpreteru, te odgovorima PHP interpretera.

3.2.3. Podatkovni sloj

Podatkovni sloj validacijske komponente čini sustav za upravljanje bazom

podataka MySQL.

29

3.4. Izvedba i implementacija

Sustav e-Portir izveden je trima aplikacijama:

1. Ulaznični poslužitelj

2. Validacijski klijent

3. Validacijski poslužitelj

Aplikacije su programske realizacije komponenata sustava mobilnih ulaznica

predstavljenih u poglavlju o arhitekturi sustava (poglavlje 3.2.).

U sustavu e-Portir sve procese usluge mobilnih ulaznica korisnik ne obavlja

izričito pomoću mobilnog uređaja. Prezentacijski sloj aplikacije ulazničnog poslužitelja

izveden je kao web sjedište preko kojega se korisniku izdaje ulaznica. Podržana je

znakovna i grafička forma ulaznice (barkod forma). Korisnik ulazničnom poslužitelju

može pristupiti pomoću bilo kojeg uređaja s pristupom Internetu, a koji podržava prikaz

tehnologija Internet stranice u kojemu je izvedeno web sjedište. Za izdanu ulaznicu

korisnik samostalno vrši prijenos mobilne ulaznice na uređaj pogodan za fizički transfer

ulaznice do validacijske komponente. Optički uređaj povezan s validacijskim klijentom

vrši skeniranje ulaznice i prijenos digitalne slike barkoda validacijskom klijentu poradi

dekodiranja barkoda i validacije ulaznice. Kako je prijenos ulaznice validacijskom

klijentu moguće ostvariti optičkim skeniranjem, u e-Portiru moguća je i uporaba

„običnih“ papirnatih ulaznica sa sadržanom barkod formom ulaznice. Prijenos znakovne i

barkod ulaznice također je moguće je ostvariti svim ostalim tehnologijama za prijenos

podržanim od računala koje pokreće aplikaciju validacijskog klijenta. Sustav e-Portir

koristi neovisnu validaciju mobilnih ulaznica, pa su ulaznična komponenta (ulaznični

poslužitelj) i validacijska komponenta (validacijski poslužitelj, validacijski klijent)

neovisne aplikacije – ne postoji komunikacijska veza između ulaznične i validacijske

komponente.

30

Sl. 3.3. Ilustrativni prikaz funkcioniranja sustava e-Portir

31

3.4.1. Mobilna ulaznica

Za ostvarenje neovisne validacije ulaznica potrebno je zaštiti ulaznicu s obzirom

na sigurnosni zahtjev autentičnosti. Način osiguravanja autentičnosti ulaznice u e-Portiru

je digitalno potpisivanje ulaznice. Ulaznična komponenta koristi infrastrukturu za

asimetričnu kriptografiju i generira par ključeva; privatni i javni. Korišteni algoritam za

kreiranje ključeva je 512-bitni SHA1RSA algoritam. Ulaznična komponenta također

generira i certifikat koji sadrži podatke o izdavatelju te prethodno generirani javni ključ.

Takav certifikat ulaznična komponenta može javno publicirati. Svaki entitet, koji ima

odgovarajuće mehanizme, pomoću certifikata može odrediti je li ulaznica autentična

provjerom digitalnog potpisa ulaznice. Validacijski klijent validacijske komponente

pribavlja certifikat i koristi ga upravo za provjeru autentičnosti ulaznice (verifikaciju).

Logika validacije i informacija ulaznice

Logika validacije određuje informaciju mobilne ulaznice. Po pravilima logike

validacije ulaznična komponenta generira informaciju ulaznice i izdaje ulaznicu.

Mehanizmi za validaciju validacijske komponente poznaju logiku validacije, tj. način na

koji je konstruirana informacija ulaznice, te shodno tome, analiziraju ulaznicu i

pripremaju je za validaciju.

Na slici 3.4. prikazan je dijagram toka validacije iz perspektive ulaznične

(izdavanje ulaznice) i validacijske komponente (validacija ulaznice).

32

Sl. 3.4. Dijagram toka validacije u sustavu e-Portir

33

• Perspektiva ulaznične komponente:

Opisuje redoslijed i postupke za generiranje informacije ulaznice. Blok „Ulazni

podaci“ predstavljaju podatke koje korisnik unosi preko web sučelja ulaznične

komponente, na temelju kojih mu se izdaje ulaznica. U e-Portir prototipnom sustavu

definirano je da ispravne ulazne podatke koje korisnik mora predati za izdavanje

ulaznice predstavlja bilo koji, proizvoljan niz ASCII znakova.

1. Računanje sažetka8 ulaznih podataka: računa se sažetak ulaznih podataka

koristeći 128-bitni MD5 hash algoritam. Rezultat računanja sažetka je podatkovni

niz od 128 bita.

2. Base329 kodiranje sažetka: sažetak ulaznih podataka kodira se u base32 zapis.

Rezultat kodiranja je 26-ero znamenkasti broj u base32 zapisu koji predstavlja

„Identifikator ulaznice“.

3. Digitalno potpisivanje sažetka: sažetak ulaznih podataka šifrira se privatnim

ključem ulazničnog poslužitelja.

4. Base32 kodiranje potpisa: digitalni potpis sažetka kodira se u base32 zapis.

Rezultat kodiranja je broj sa točno 103 znamenke u base32 zapisu koji predstavlja

„Digitalni potpis identifikatora ulaznice“.

5. Konkatenacija: vrši se spajanje base32 zapisa „Identifikator ulaznice“ i „Digitalni

potpis identifikatora ulaznice“. Tako formirani zapis čini informaciju ulaznice.

8 Sažetak poruke (engl. message digest, message hash) – jednosmjerna ne inverzna funkcija za pretvorbu niza bitova proizvoljne duljine u jedinstven niz bitova fiksne duljine 9 Base32 zapis – numerički zapis broja koji koristi bazu 32 (RFC-4648)

34

Sl. 3.5. Primjer logike validacije gledane iz perspektive ulaznične komponente

• Perspektiva validacijske komponente:

Opisuje redoslijed i postupke za validaciju informacije ulaznice.

1. Raščlamba informacije ulaznice: vrši se raščlamba informacije ulaznice na

segmente: „Identifikator ulaznice“ i „Digitalni potpis identifikatora ulaznice“

2. Dekodiranje identifikatora iz base32: „Identifikator ulaznice“ se dekodira iz

base32 zapisa, dobiveni rezultat je sažetak ulaznih podataka.

3. Dekodiranje potpisa iz base32: „Digitalni potpis identifikatora ulaznice“ se

dekodira iz base32 zapisa, dobiveni rezultat je digitalni potpis sažetka ulaznih

podataka.

4. Verifikacija digitalnog potpisa: validacijska komponenta verificira digitalni potpis

sažetka ulaznih podataka. Ako je potpis valjan ulaznica se prosljeđuje

mehanizmima za provjeru stanja ulaznice. Ako potpis nije valjan zaključuje se da

ulaznica nije valjana.

5. Provjera stanja ulaznice: validacijska komponenta vrši provjeru stanja ulaznice, te

određuje ulaznicu valjanom odnosno ne valjanom.

35

Sl. 3.6. Primjer logike validacije gledane iz perspektive validacijske komponente

Forma ulaznice

Podržane su dvije forme ulaznice: znakovna i barkod forma. Znakovnu formu

ulaznice čini informacija ulaznice u zapisu base32 broja kao ASCII string (informacija

dobivena u petom koraku provedbe logike validacije iz perspektive ulaznične

komponente). Barkod formu ulaznice čini zapis znakovne forme ulaznice u QRCode

barkodu.

Sl. 3.7. Shema primjera mobilne ulaznice u znakovnoj i barkod formi

36

3.4.2. QR Code barkod

QR Code (QR – engl. quick response) je dvodimenzionalni barkod definiran

ISO/IEC18004 industrijskim standardom. U e-Portiru on predstavlja barkod formu

ulaznice. Razlozi za uporabu upravo ovog barkoda u su: veliki kapacitet pohrane

podataka, dobra dokumentiranost barkoda od strane standardizacijskog tijela, dostupnost

besplatne programske podrške za kodiranje i dekodiranje barkoda, te činjenica da je sam

QR Code barkod besplatan za korištenje. Danas je QR Code jedan od najraširenijih 2D

barkodova na tržištu.

QR Code barkodom moguće je kodirati slijedeće vrste ulaznih podataka:

1. Brojevi: znamenke 0-9 (izraženo u bitovima 30HEX-39HEX) – tri znaka su kodirana sa

ukupno 10 bitova

2. Alfanumerički podaci: brojevi 0-9 (30HEX-39HEX), velika slova A-Z (41HEX-5AHEX), te

posebni znakovi: space % $ * + - . , / : (20HEX 24HEX 25HEX 2AHEX 2BHEX 2DHEX 2FHEX

3AHEX 24HEX 24HEX) – dva znaka su kodirana sa ukupno 11 bitova

3. Binarni podaci (definirani ISO/IEC 8859-1 standardom): svaki bajt znak se kodira sa

8 bitova

4. Kanji10

Veliki kapacitet za pohranu podataka QR Code barkoda te mogućnost optimalnog

kodiranja alfanumeričkih podataka omogućava izvedbu mobilne ulaznice e-Portira. Na

koji način? Glavni problem u izvedbi ulaznice bio je prikaz podataka nastalih zaštitom

ulaznice 512-bitnom asimetričnom kriptografijom, nužnom za ostvarivanje neovisne

validacije. Dakle, uz ostale podatke unutar informacije ulaznice, bilo je potrebno

prikazati i još najmanje 512 bitova podataka nastalih zaštitom. Kako se kod izvedbe

mobilne ulaznice teži smanjivanju veličine grafičke forme ulaznice, zbog ograničenih

mogućnosti ekrana mobilnih uređaja, bilo je nužno pronaći način prikaza podataka za

koji će konačni simbol barkoda biti minimalan. Prebacivanjem binarne informacije

ulaznice u base32 bazu za prikaz brojeva dobiva se zapis čiji tekstualni prikaz sadrži

znakove koji su brojevi 0-9 i velika slova A-Z. Osim znakova koji pripadaju jednoj od te

10 Format koji podržava prikaz kineskih znakova.

37

dvije skupine, u base32 zapisu ne pojavljuju se drugi znakovi. Base32 kodira pet binarnih

znamenki jednom znamenkom, pa tako smanjuje veličinu informacije ulaznice.

Smanjivanjem veličine informacije ulaznice prebacivanjem iz binarnog u base32 zapis i s

mogućnošću optimalnog kodiranja alfanumeričkih znakova kod QR Code barkoda

dobivena je minimalna veličina simbola QR Code barkoda.

QR Code simbol

Svaki QR Code simbol strukturiran je od tamnih i svijetlih kvadratnih modula

pravilno raspoređenih unutar kvadratne mreže polja veličine jednake veličini jednog

modula. Tamni modul predstavlja binarnu jedinicu a svijetli modul binarnu nulu. Svaki

simbol se sastoji od funkcijskih uzoraka i uzoraka kodiranja. Funkcijski uzorci ne sadrže

kodirane podatke.

Sl. 3.8. Shema strukture QR Code barkod simbola

- Pozicijski uzorak: postoje tri jednaka pozicijska uzorka u svakom simbolu. On se

sastoji od tri koncentrična kvadrata duljine stranice 7, 5 i 3 modula. Odnos duljima

modula je 1:1:3:1:1 kako je i ilustrirano na slici. Simbol pozicijskog uzorka

konstruiran je tako da postoji vrlo mala vjerojatnost pojavljivanja sličnog oblika u

prostoru kodiranih podataka. Pronalazak tri pozicijska uzorka nedvosmisleno

određuje poziciju i orjentaciju simbola barkoda u vidnom polju.

38

Sl. 3.9. Shema pozicijskog uzorka

- Razmak: između svakog pozicijskog uzorka i ostalog simbola postoji razmak debljine

jednog modula

- Alternirajući uzorak: postoji jedan horizontalni i jedan vertikalni alternirajući uzorak.

Oni su građeni od retka ili stupca debljine jednog modula sa alternirajućim tamnim i

svijetlim modulima. Oni omogućavaju određivanje gustoće i verzije simbola, te služe

kao koordinatne osi za određivanje pozicije svakog modula u simbolu. Horizontalni

uzorak proteže se šestim retkom od razmaka lijevog do razmaka desnog pozicijskog

uzorka. Vertikalni uzorak proteže se šestim stupcem od razmaka lijevog do razmaka

donjeg pozicijskog uzorka (prema orijentaciji simbola kao na slici 3.8.). Oba uzorka

počinju i završavaju tamnim modulom.

- Uzorci za poravnavanje: svaki uzorak sastoji se od koncentričnih kvadrata duljina

stranica 5, 3 i 1 modul. Broj uzoraka za poravnavanje u simbolu ovisi o korištenoj

verziji QR Code simbola.

- Tiha zona: prostor oko simbola debljine četiri modula sa jednakom vizualnom

refleksijom kao i svijetli moduli u simbolu.

- Uzorci kodiranja: oni uključuju uzorke koji predstavljaju kodne riječi podataka,

kodne riječi za ispravljanje pogrešaka, informaciju o verziji i formatu simbola.

Postoji četrdeset verzija QR Code barkoda (verzija 1, verzija 2, itd.). Verzija 1

sastavljena je od kvadrata veličine 21x21 modula, a svaka slijedeća ima četiri modula

više po stranici kvadrata. Najveća verzija je verzija 40 koja je sastavljena od kvadrata

veličine 177x177 modula.

39

Sl. 3.10. Shema simbola verzije 1

QR Code implementira Reed-Solomon11 algoritam za generiranje kodnih riječi za

ispravljanje pogrešaka i za ispravljanje pogrešaka. Pogreške u barkodu mogu se javiti

prilikom optičkog čitanja barkoda uslijed oštećenja slike barkoda (ako je slika barkoda

sadržana na npr. papirnom mediju) ili npr. zbog neusklađenosti rezolucije čitača i veličine

slike barkoda, distorzije slike zbog kuta snimanja, svjetlosti itd. Postoje četiri razine

zaštite od pogrešaka u QR Code simbolu. Razinu zaštite proizvoljno odabire korisnik.

Tablica 3.1. Razine zaštite od pogrešaka kod QR Code simbola

Razina zaštite Približna količina potencijalno ispravljenih podataka (%)

L 7 M 15 Q 25 H 30

Kodiranje QR Code simbola

Koraci pri kodiranju ulaznih podataka u QR Code simbol su slijedeći:

1. Analiza podataka: vrši se analiza ulaznih podataka kako bi se odredili najefikasniji

načini kodiranja podataka u binarno kodirani tekst (string) gledajući veličinu

dobivenih podataka. Detektira se odabrana verzija simbola i razina ispravljanja

pogrešaka u simbolu. Ako verzija simbola nije izabrana, odabire se najmanja verzija

simbola koja može sadržati sve kodirane ulazne podatke.

2. Kodiranje podataka: vrši se konverzija ulaznih podataka u struju bitova prema

odabranim načinima kodiranja. Podržano je kombiniranje više načina kodiranja

podataka u jednom simbolu. Dobiveni niz bitova raščlanjuje se u segmente 8-bitnih

11 http://en.wikipedia.org/wiki/Reed-Solomon_error_correction

40

kodnih riječi, te se dodaju redundantne kodne riječi kako bi se popunio broj kodnih

riječi koji zahtjeva verzija simbola.

3. Kodiranje informacije za ispravljanje pogrešaka: slijed kodnih riječi podataka

raščlanjuje se na pojedinačne blokove kodnih riječi određene veličine (veličina ovisi

o verziji simbola i odabranoj razini ispravljanja pogrešaka) za koje se generiraju

kodne riječi za ispravljanje pogrešaka.

4. Formiranje završnog slijeda kodnih riječi: algoritam kojim se formira završni slijed

kodnih riječi za simbol objašnjen je na primjeru simbola verzije 5 sa H razinom

ispravljanje pogrešaka u simbolu (5-H).

Sl. 3.11. Formiranje završnog slijeda kodnih riječi za simbol 5-H

Verzija 5-H obuhvaća po četiri bloka kodnih riječi podataka i kodnih riječi za

ispravljanje pogrešaka. Prva dva bloka sadrže po 11 kodnih riječi podataka i 22 kodne

riječi za ispravljanje pogrešaka. Druga dva bloka sadrže po 12 kodnih riječi podataka

i 22 kodne riječi za ispravljanje pogrešaka. Završni slijed kodnih riječi formira se

čitanjem vertikalnih stupaca kodnih riječi podataka, pa potom kodnih riječi za

ispravljanje pogrešaka. Kod 5-H simbola slijed je: D1, D12, D23, D35, D2, D13, D24,

D36, ... D11, D22, D33, D45, D34, D46, E1, E23, E45, E67, E2, E24, E46, E68, ... E22, E44, E66,

E88.

5. Formiranje grafičkih elemenata barkoda: formiraju se dijelovi strukture barkoda;

pozicijski uzorak, razmak, alternirajući uzorak, uzorci za poravnavanje te blokovi

modula koji sadrže završni slijed kodnih riječi. Svaka kodna riječ završnog slijeda

prikazana je s jednim blokom od 8 modula. Većina kodnih riječi prikazana je tzv.

regularnim 2x4 blokovima sa horizontalnom ili vertikalnom orijentacijom. Ne

regularni blokovi koriste se kada se mijenja orijentacija bloka ili kada je pozicija

bloka u neposrednoj blizini s funkcijskim uzorkom. Blokovi u simbolu su raspoređeni

u stupce širine dva modula s alternirajućim vertikalnim smjerovima slaganja blokova.

41

Slaganje blokova u simbolu počinje od desnog donjeg kuta simbola s početnim

vertikalnim smjerom slaganja prema gore, pa na lijevu stranu. Najznačajniji bit

(oznaka 7) kodne riječi unutar bloka uvijek zauzima prvo slobodno mjesto u bloku.

Ostali bitovi popunjavaju se horizontalno u smjeru s desna na lijevo i vertikalno u

smjeru identičnom sa smjerom slaganja blokova.

Sl. 3.12. Prikaz nekih orjentacija i pozicija blokova kodnih riječi

Sl. 3.13. Formiranje završnog slijeda kodnih riječi u simbolu 2-M

6. Formiranje informacije o verziji i formatu: generiraju se blokovi informacija o verziji

i formatu simbola

a) Regularni blok sa smjerom popunjavanja bitova prema gore b) Regularni blok sa smjerom popunjavanja bitova prema dolje c) Neregularni blok sa smjerom popunjavanja prvo gore pa prema dolje (npr. pozicija gornjeg ruba simbola) d) Primjer postavljanja bitova u blokovima koji priliježu na uzorak za poravnavanje

42

Dekodiranje QR Code simbola

Postupak dekodiranja QR Code simbola prikazan je grafom na slici 3.14:

Sl. 3.14. Dijagram toka dekodiranja QR Code barkoda

43

3.4.3. Ulaznični poslužitelj

Ulaznični poslužitelj je programska cjelina izgrađena od nekoliko povezanih

programskih komponenti prikazanih na slici 3.15.

Prezentacijski sloj ulazničnog poslužitelja čini web sjedište kojega pokreće HTTP

poslužitelj. Ono je namijenjeno korisniku usluge mobilnih ulaznica i pokrenuto je unutar

mreže preko koje korisnik pristupa poslužitelju (npr. Internet, intranet, itd.).

Datotečna struktura web sjedišta sadrži slijedeće: - TicketingServer.html - TicketingServer.swf - TicketingServer.xml - history/ - playerProductInstall.swf

Glavna datoteka sjedišta je HTML datoteka TicketingServer.html. To je takozvana

omatajuća (engl. wrapper) datoteka za TicketingServer.swf Flash aplikaciju izvedenu u

Adobe Flex tehnologiji koja obavlja sve funkcionalnosti weba. TicketingServer.xml je

konfiguracijska datoteka ulazničnog poslužitelja koja sadrži nužne podatke za

inicijalizaciju dijelova sustava. Ostale datoteke unutar strukture su datoteke koje

osiguravaju ispravan prikaz i ponašanje TicketingServer.swf aplikacije pokrenute unutar

web preglednika.

44

Sl. 3.15. Implementacijska shema ulazničnog poslužitelja

45

Prezentacijski sloj

Elementi weba ulazničnog poslužitelja su:

1. Tekstualno polje za korisnički unos podataka ulaznice: prostor u koji korisnik usluge

upisuje potrebne ulazne podatke prema kojima mu sustav generira kod i barkod

ulaznice

2. Polje koda ulaznice: tekstualno polje u kojemu se prikazuje kod izdane ulaznice

3. Grafički prikaz barkoda ulaznice

4. Postavke barkoda: skup opcija koje koristi korisnik kako bi prilagodio simbol

barkoda. Moguće je odabirati razinu zaštite od pogrešaka, te veličinu modula QR

Code barkod simbola.

Sl. 3.16. Prezentacijski sloj ulazničnog poslužitelja

Aplikacijski sloj

Aplikacijski sloj aplikacije čine koder barkoda i koder ulaznice. Koder barkoda je

izveden kao web aplikacija koju pokreće HTTP poslužitelj povezan sa PHP interpreterom

46

koda. Koder barkoda čini biblioteka PHP skripti. Koder ulaznice sadržan je unutar

aplikacije TicketingComponent.jar koju pokreće J2EE poslužitelj.

Koder barkoda

Koder barkoda čini "QRcode ver.0.50g"12 PHP biblioteka skripti sa

implementiranim algoritmom za kodiranje QR Code barkoda. TicketingServer.swf

aplikacija s koderom barkoda komunicira putem HTTP protokola, te šalje zahtjeve s

parametrima za koje joj koder vraća sliku QR Code barkoda u JPEG ili PNG formatu.

Dobivenu sliku barkoda TicketingServer.swf prikazuje u polju grafičkog prikaza barkoda

ulaznice.

Koder ulaznice

Komponenta kodera ulaznice izvedena je u programskom jeziku Java, a

prevedene *.class datoteke komponente sažete su u TicketingComponent.jar arhivu.

Zadaća kodera ulaznice je formiranje informacije ulaznice prema logici validacije za

dane ulazne podatke.

Za kriptografske operacije zahtijevane u izvedbi informacije ulaznice (računanje

sažetka podataka, digitalno potpisivanje) koder koristi JCA (engl. Java cryptography

architecture) sigurnosni API.

TicketingServer.swf za komunikaciju s koderom ulaznice, tj. komunikacijskom

klasom unutar TicketingComponent.jar-a koristi RPC pozive procedura putem AMF

protokola. Kako bi TicketingComponent.jar mogao izložiti javne metode svojih klasa

RPC pozivima, potrebno ga je pokrenuti unutar J2EE web poslužitelja i povezati s Adobe

BlazeDS AMF komunikacijskim među-slojem. Komunikacijska klasa

TicketingComponent.jar-a je TicketingServer sadržana u paketu

hr.fer.dipl.ticketingserver.

12 Biblioteka je dostupna na http://www.swetake.com/qr/qr_cgi_e.html

47

Sl. 3.17. Dijagram slučaja uporabe ulazničnog poslužitelja

3.4.4. Validacijski klijent

Programska cjelina validacijskog klijenta izgrađena je od programskih

komponenti prikazanih na slici 3.18.

Korištenje programske cjeline validacijskog klijenta namijenjeno je pružatelju

usluge mobilnih ulaznica (aplikacijom upravlja administrator validacijskog klijenta).

Administrator pomoću sustava validacijskog klijenta vrši optičko skeniranje ulaznica i

dekodiranje barkoda, verifikaciju ulaznice, te zahtijeva provjeru stanja ulaznica od

validacijskog poslužitelja.

48

AMFEndpoint

MessageBroker

RemotingService

RemotingDestination

JavaAdapter

Sl. 3.18. Implementacijska shema validacijskog klijenta

49

Prezentacijski sloj

Prezentacijski sloj validacijskog klijenta čini korisničko sučelje; Adobe AIR

aplikacija ValidationClient.exe. Aplikacija ima dva pogleda: „Scanning“ i

„Configuration“.

Elementi korisničkog sučelja prikazanog na slici 3.19. su:

1. Prikaz video ulaza

2. Prikaz uhvaćenih slika s video ulaza

3. Polje koda ulaznice

4. Status dekodiranja i validacije ulaznice

5. Status sustava validacijskog klijenta

6. Status izvršenih operacija u sustavu

7. Opcije povezivanja s validacijskim poslužiteljem

8. Konfiguracija sigurnosnih postavki verifikatora

50

Sl. 3.19. Prezentacijski sloj validacijskog klijenta

51

Aplikacijski sloj

Aplikacijski sloj validacijskog klijenta čine komponente: dekoder barkoda,

verifikator ulaznice i konekcijski sloj. Sve navedene komponente izvedene su

programskom jeziku Java i sažete u ValidationClient.jar arhivu. Za pokretanje Java

komponenti i uspostave njihove komunikacije sa korisničkim sučeljem klijenta

(ValidationClient.exe), potrebno je izvršiti postupke sukladne onima već navedenima u

opisu ulazničnog poslužitelja: pokretanje ValidationClient.jar-a unutar J2EE web

poslužitelja i povezivanje s Adobe BlazeDS AMF komunikacijskim među-slojem.

Komunikacijska klasa ValidationClient.jar-a je ValidationClient.class sadržana u paketu

hr.fer.dipl.validationclient.

Sl. 3.20. Prikaz komponenata ValidationClient.jar arhive

Dekoder barkoda

Dekoder QR Code barkoda u validacijskom klijentu čini biblioteka Java klasa

"Open Source QR Code Library"13 unutar ValidationClient.jar-a sadržana u

jp.sourceforge.qrcode paketu. Zadaća dekodera je dekodiranje barkoda ulaznice.

Nakon što administrator skenira mobilnu ulaznicu koristeći funkcije korisničkog

sučelja dekoderu barkoda šalje se slika barkoda, te on izvršava postupke njegovog

dekodiranja. Uslijed uspješnog dekodiranja povratna vrijednost korisničkom sučelju biti

će kod mobilne ulaznice.

Verifikator ulaznice

Verifikator ulaznice čini biblioteka klasa unutar ValidationClient.jar-a sadržana u

hr.fer.dipl.validationclient.verify paketu. Verifikator kao ulazni parametar prihvaća kod

13 Biblioteka je dostupna na http://qrcode.sourceforge.jp/

52

ulaznice, vrši potrebne kriptografske operacije verifikacije digitalnog potpisa ulaznice

(koristi se JCA sigurnosni API), te vraća rezultate verifikacije.

Konekcijski sloj

Konekcijski sloj čini biblioteka klasa unutar ValidationClient.jar-a sadržana u

hr.fer.dipl.validationclient.conn paketu. Zadaća konekcijskog sloja je povezivanje

klijenta s validacijskim poslužiteljem, te prijenos i prihvat podataka poslužitelja. Za

realizaciju komunikacije korištene su funkcionalnosti java.net.Socket Java klase, a

implementirana je komunikacija preko TCP protokola.

Sl. 3.21. Dijagram slučaja uporabe validacijskog klijenta

3.4.5. Validacijski poslužitelj

Programska cjelina validacijskog poslužitelja izgrađena je od programskih

komponenti prikazanih na slici 3.22.

53

Bla

zeD

S R

emot

eObj

ect

Val

idat

ionS

erve

r.exe

AMFC

hann

elVa

lidat

ionS

erve

r.xm

l

J2E

E p

oslu

žite

lj

Ser

vlet

kon

tenj

er

AM

F pr

eko

HTT

P-a

Val

idat

ionS

erve

r.jar

Kom

unik

acijs

ki m

eđus

loj (

GU

I-BLL

)TC

P/IP

loka

lno

MyS

QL

RD

BM

S

"val

idat

ion_

serv

er" b

aza

poda

taka

Blaz

eDS

Mes

sage

Bro

kerS

ervl

et

Kom

unik

acijs

ki m

eđus

loj (

GU

I-BLL

)

rem

otin

g-co

nfig

.xm

l

loka

lno

Valid

acijs

ki p

oslu

žite

lj

Val

idac

ijski

klij

ent

11.

.*

Sl. 3.22. Implementacijska shema validacijskog poslužitelja

54

Korištenje programske cjeline validacijskog poslužitelja namijenjeno je pružatelju

usluge mobilnih ulaznica (aplikacijom upravlja administrator validacijskog poslužitelja).

Validacijski poslužitelj u zajedno sa povezanim validacijskim klijentima čini validacijsku

komponentu u sustavu.

Prezentacijski sloj

Prezentacijski sloj validacijskog poslužitelja čini korisničko sučelje; Adobe AIR

aplikacija ValidationServer.exe. Aplikacija ima dva pogleda: "Server" i "Server

Database".

Elementi korisničkog sučelja prikazanog na slici 3.23. su:

1. Opcije pokretanja klijentskog poslužitelja

2. Opcije povezivanja s bazom podataka

3. Opcije odabira tablice baze podataka za čuvanje stanja ulaznica (tablice

ciklusa)

4. Prikaz podataka o povezanim validacijskim klijentima

5. Prikaz stanja tablice ciklusa

6. Status sustava validacijskog poslužitelja

7. Status izvršenih operacija u sustavu

8. Prikaz tablica baze podataka i operacije za manipulaciju bazom podataka

55

Sl. 3.23. Prezentacijski sloj validacijskog poslužitelja

56

Aplikacijski sloj

Aplikacijski sloj validacijskog poslužitelja čine komponente: klijentski

poslužitelj, validator ulaznica, sloj pristupa podacima.

Sl. 3.24. Prikaz komponenata ValidationServer.jar arhive

Sve navedene komponente izvedene su programskom jeziku Java i sadržane u

ValidationClient.jar arhivi. Komunikacijska klasa koja sudjeluje u uspostavi AMF

komunikacijskog kanala, za pozive sa korisničkog sučelja prema ValidationServer.jar-u,

je ValidationServer.class koja se nalazi u hr.fer.dipl.validationserver paketu.

Klijentski poslužitelj

Klijentski poslužitelj je zadužen za ostvarivanje veze prema validacijskim

klijentima. Izveden je kao višedretveni poslužitelj pa može održavati komunikacijsku

vezu sa više klijenata istovremeno. Za realizaciju poslužitelja korištene su

funkcionalnosti java.net.ServerSocket Java klase, a implementirana je komunikacija

preko TCP protokola.

Validator ulaznica

Validator je svojevrsna komunikacijska spona između validacijskih klijenata i

sloja pristupa podacima validacijskog poslužitelja. Klijentski poslužitelj, svakom

validacijskom klijentu koji se povezuje, dodjeljuje validatora ulaznica. Validator ulaznica

prihvaća zahtjeve klijenata za validacijom ulaznica, formatira ih u upit za dohvat

trenutnog stanja ulaznice prema sloju pristupa podacima, te dobiveni odgovor o stanju

ulaznice prosljeđuje natrag validacijskom klijentu.

Sloj pristupa podacima

57

Sloj pristupa podacima vrši svu komunikaciju s podatkovnim slojem. Za

realizaciju sloja korištena je MySQL Connector/J14 Java biblioteka.

Podatkovni sloj

Podatkovni sloj validacijskog poslužitelja čini MySQL baza podataka koju pogoni

MySQL RDBMS. Baza podataka predstavlja bazu zapisa o iskorištenim ulaznicama.

Zapisi o iskorištenim ulaznicama nalaze se unutar tablica baze podataka koje

predstavljaju jedan životni ciklus usluge mobilnih ulaznica. Drugim riječima, za svaki

novi životni ciklus usluge predviđen je odabir nove tablice koja će održavati podatke o

iskorištenim ulaznicama. U e-Portiru nije nužno stvaranje nove tablice za svaki ciklus,

već je moguć i nastavak prethodno definiranih ciklusa.

Sl. 3.15. Dijagram slučaja uporabe validacijskog poslužitelja s akterom

administratorom validacijskog poslužitelja

Sl. 3.16. Dijagram slučaja uporabe validacijskog poslužitelja s akterom

komponentom sustava validacijskog klijenta 14 http://dev.mysql.com/downloads/connector/j/5.1.html

58

3.5. Modeliranje sigurnosnih rizika validacijske komponente

Sigurnosni rizik definira se kao mogućnost realizacije nekog neželjenog događaja,

koji može negativno utjecati na povjerljivost (engl. confidentiality), cjelovitost ili

integritet (engl. integrity) i raspoloživost (engl. availability) informacijskih resursa. U

proširenoj definiciji sigurnosnog rizika uključen je i akter, korisnik resursa, te se ističu

zahtjevi za njegovom autorizacijom (engl. authorization), provjerom vjerodostojnosti ili

autentifikacijom (engl. authentication) i neporecivošću izvršenih operacija nad resursom

(engl. nonrepudiation).

Sigurnosna prijetnja (engl. security threat) definira se kao potencijal za povredu

sigurnosti uslijed takvih okolnosti, mogućnosti, akcija ili događaja u sustavu koji bi mogli

narušiti sigurnost sustava i uzrokovati štetu. Sigurnosna ranjivost (engl. security

vulnerability) je nedostatak ili slabost u dizajnu, implementaciji ili funkcionalnosti

sustava koja se može iskoristiti (realizacija sigurnosne prijetnje, napad na sustav) da bi se

narušila sigurnosna politika sustava. Izvor prijetnje (engl. threat source) je namjera i

metoda usmjerena zloupotrebi ranjivosti ili situacija i metoda koja slučajno može

aktivirati neku ranjivost. Izvor prijetnje ne predstavlja nikakvu opasnost ukoliko nema

ranjivosti koja se može iskoristiti. Da bi se utvrdila vjerojatnost neke prijetnje mora se

uzeti u obzir izvor prijetnje, potencijalne ranjivosti i postojeće sigurnosne kontrole.

Jedan od načina strukturiranog i detaljnijeg razvoja sigurnosnih funkcionalnosti

sustava je stvaranje modela sigurnosnih rizika. Model sigurnosnih rizika je svojevrsna

analiza koja pomaže u određivanju sigurnosno najrizičnijih područja programskog

sustava, te posljedica koje bi mogle uslijediti ako se ona sigurnosno ugroze. Cilj

modeliranja sigurnosnih rizika je određivanje sigurnosnih prijetnji kojima je sustav

izložen, pronalazak nedostataka u sustavu koje omogućuju njihovu realizaciju, te razrada

uvođenja sigurnosnih mehanizama u sustav kojima će prijetnje biti uspješno uklonjene.

Tijekom modeliranja sigurnosnih rizika sustav je razložen na funkcionalne

komponente i svaka se komponenta proučava s obzirom na svoje ulazne točke, te tok

podataka kroz sve funkcionalnosti, sa svrhom nalaženja sigurnosno ranjivih područja

59

sustava. Rezultat procesa modeliranja sigurnosnih rizika je dokument model sigurnosnih

rizika (engl. Threat model document).

Ograničenja koja sprečavaju napadačevo kompromitiranje sigurnosti komponente

su konačan skup ulaznih točaka (engl. entry points) sustava i razina pristupa dodijeljena

korisniku koji koristi ulazne točke.

3.5.1 Razine pristupa

Razine pristupa predstavljaju skup prava dodijeljenih entitetu (npr. korisnici),

kojima se oni raščlanjuju u logičke kategorije sa dozvolom, odnosno sa zabranom

pristupa određenom dijelu sustava.

Skup informacija o razinama pristupa u dokumentu modela čine:

• ID: jedinstvena oznaka dodijeljena razini pristupa, referenca za ulazne točke

• Ime: opisno ime razine pristupa

• Opis: opis razine pristupa

Tablica 3.2. Razine pristupa (RP) validacijske komponente

ID Ime Opis 1 Korisnik s pristupom

validacijskom klijentu Korisnik koji ima fizički pristup računalu koje validacijskog klijenta

2 Korisnik s pristupom validacijskom poslužitelju

Korisnik koji ima fizički pristup računalu koje pogoni validacijski poslužitelj

3 Korisnik usluge Korisnik koji zahtjeva validaciju ulaznice od validacijskog klijenta 4 Validacijski poslužitelj Programska komponenta validacijskog poslužitelja 5 Validacijski klijent Programska komponenta validacijskog klijenta

3.5.2. Ulazne i izlazne točke

Ulazne točke predstavljaju sredstvo interakcije napadača (točke potencijalnog

napada na sustav) tj. svaku lokaciju u sustavu gdje se podaci prenose između

modeliranog sustava i drugog aktera. Izlazne točke su isto tako uključene u sigurnosni

model zbog kontrole izlaznih informacija koje potencijalno mogu naštetiti sustavu.

Skup informacija o ulaznim točkama i izlaznim u dokumentu modela sigurnosnih

rizika čine:

• ID (identifikator): jedinstvena oznaka dodijeljena ulaznoj točki, referenca za

sigurnosne prijetnje i ranjivosti u procesu modeliranja

60

• Ime: opisno ime ulazne točke

• Opis: opis načina procesiranja ulazne točke u sustavu

• Razina pristupa: sigurnosna razina za ulaznu točku pristupa dodijeljena korisniku

(nije prikazano)

Tablica 3.3. Ulazne točke prezentacijskog sloja validacijskog klijenta

ID Ime Opis RP 1 ValidationClient.xml konfiguracijska

datoteka Datoteka za konfiguraciju po kojoj se validacijski klijent inicijalizira pri svom pokretanju

1

2 Polje za unos staze certifikata ulazničnog poslužitelja

Služi za lociranje certifikata ulazničnog poslužitelja i inicijalizaciju odabranog na aplikacijskom sloju

1

3 Polja za unos parametara poslužitelja (IP adresa, port)

Služe za formiranje TCP veze prema validacijskom poslužitelju

1

4 Polje za unos koda ulaznice Služi za unos koda ulaznice za verifikaciju ulaznice prema kodu

1

5 Video ulaz Video ulaz uređaja za skeniranje ulaznica 3 6 Krajnja točka AMF kanala AIR

aplikacije Krajnja točka AMF kanala prezentacijskog sloja koja prima podatke

5

Tablica 3.4. Ulazne točke aplikacijskog sloja validacijskog klijenta

ID Ime Opis RP 7 Krajnja točka AMF kanala BlazeDS

aplikacije Krajnja točka AMF kanala aplikacijskog sloja koja prima podatke

5

8 TCP socket veze prema poslužitelju TCP socket preko kojega klijent prima podatke od poslužitelja

4

Tablica 3.5. Ulazne točke prezentacijskog sloja validacijskog poslužitelja

ID Ime Opis RP 9 ValidationServer.xml konfiguracijska

datoteka Datoteka za konfiguraciju po kojoj se validacijski poslužitelj inicijalizira pri svom pokretanju

2

10 Polja za unos parametara poslužitelja (port)

Služi za pokretanje klijentskog TCP poslužitelja 2

11 Polje za unos parametara baze podataka Služi za ostvarivanje veze prema RDBMS-u 2 12 Polje za odabir tablice ulaznica Služi za odabir aktivne tablice ulaznica za ciklus

usluge mobilnih ulaznica 2

13 Polje za unos parametara za stvaranje tablice ulaznica

Služi za kreiranje tablice ulaznica u bazi podataka 2

14 Krajnja točka AMF kanala AIR aplikacije

Krajnja točka AMF kanala prezentacijskog sloja koja prima podatke

5

Tablica 3.6. Ulazne točke aplikacijskog sloja validacijskog poslužitelja

ID Ime Opis RP 15 Krajnja točka AMF kanala BlazeDS Krajnja točka AMF kanala aplikacijskog sloja 4

61

aplikacije koja prima podatke 16 TCP socket veze prema klijentu TCP socket preko kojega poslužitelj prima

podatke od klijenta 5

Tablica 3.7. Izlazne točke prezentacijskog sloja validacijskog klijenta

ID Ime Opis RP 1 Krajnja točka AMF kanala AIR

aplikacije Krajnja točka AMF kanala prezentacijskog sloja koja šalje podatke

5

Tablica 3.8. Izlazne točke aplikacijskog sloja validacijskog klijenta

ID Ime Opis RP 2 Krajnja točka AMF kanala BlazeDS

aplikacije Krajnja točka AMF kanala aplikacijskog sloja koja šalje podatke

5

3 TCP socket veze prema poslužitelju TCP socket preko kojega klijent šalje podatke poslužitelju

5

Tablica 3.9. Izlazne točke prezentacijskog sloja validacijskog poslužitelja

ID Ime Opis RP 4 Krajnja točka AMF kanala AIR

aplikacije Krajnja točka AMF kanala prezentacijskog sloja koja šalje podatke

4

Tablica 3.10. Izlazne točke aplikacijskog sloja validacijskog poslužitelja

ID Ime Opis RP 5 Krajnja točka AMF kanala BlazeDS

aplikacije Krajnja točka AMF kanala aplikacijskog sloja koja šalje podatke

4

6 TCP socket veze prema klijentu TCP socket preko kojega poslužitelj šalje podatke klijentu

4

3.5.3. Točke napada

Točke napada (engl. attack points) su sve vrste resursa ili komponenti sustava

kojima prijeti potencijalni napad. Točke napada su ciljevi prijetnji sustavu.

Skup informacija o točkama napada u dokumentu modela čine:

• ID: jedinstvena oznaka dodijeljena točki napada, referenca za sigurnosne prijetnje

i ranjivosti u procesu modeliranja

• Ime: opisno ime točke napada

• Opis: opis točke napada, potrebne zaštite, itd.

62

• Razina pristupa: sigurnosna razina za točku napada pristupa dodijeljena korisniku

Tablica 3.11. Točke napada validacijske komponente

ID Ime Opis 1 Korisničko sučelje komponenata

(GUI) Napadač izvršava štetne operacije koristeći GUI komponenata

2 AMF komunikacijski most Napadač kompromitira komunikacijsku vezu prezentacijskog i aplikacijskog sloja komponenata

3 TCP veza validacijskog poslužitelja i klijenata

Napadač kompromitira komunikacijsku vezu validacijskog poslužitelja i klijenata

4 RDBMS koji koristi validacijski poslužitelj

Napadač vrši štetne operacije unutar RDBMS sustava koji koristi validacijski poslužitelj

5 Konfiguracijske datoteke komponenata

Napadač modificira konfiguracijske datoteke štetnim podacima

6 J2EE poslužitelj Napadač kompromitira funkcionalnosti J2EE poslužitelja koji pogone aplikacijski sloj komponenata

3.5.4. Prijetnje i ranjivosti sustava

Skup informacija o prijetnjama i ranjivostima u dokumentu modela čine:

• ID: jedinstvena oznaka dodijeljena prijetnji

• Ime prijetnje: opisno ime prijetnje

• Opis prijetnje: opis prijetnje

• Opis ranjivosti: opis ranjivosti

• Uklanjanje prijetnje: informacija o stanju prijetnje i procesima za njezino

uklanjanje

• Ulazne i izlazne točke: reference ulaznih i izlaznih točaka koje koristi prijetnja

• Točke napada: reference točaka napada na koje prijetnja djeluje

63

ID 1

Ime prijetnje Napadač presreće komunikaciju validacijskog klijenta i poslužitelja

Opis prijetnje Napadač presreće komunikaciju klijenta i poslužitelja, te prikuplja podatke o valjanim ulaznicama koje procesira validacijski klijent. Ugrožena je povjerljivost podataka koji se prenose između klijenta i poslužitelja.

Opis ranjivosti Komunikacijska veza klijenta i poslužitelja izvedena je TCP protokolom korištenjem TCP socketa koji ne maskiraju sadržaj unutar transportnih jedinica prijenosa.

Uklanjanje prijetnje

Komunikaciju klijenta i poslužitelja potrebno je kriptirati. Kao moguće rješenje predlaže se uporaba TLS protokola.

Izlazne točke 6, 3 Točke napada 3

ID 2

Ime prijetnje Napadač „glumi“ validacijskog klijenta i ostvaruje vezu s validacijskim poslužiteljem

Opis prijetnje Napadač s ostvarenjem neovlaštene konekcije s poslužiteljem može izvršavati DoS (engl denial of service) napade i tako ugroziti raspoloživost poslužitelja

Opis ranjivosti Na validacijskom poslužitelju ne postoje implementirani mehanizmi za autorizaciju klijenata

Uklanjanje prijetnje

Potrebno je implementirati mehanizme za autorizaciju validacijskih klijenata prilikom spajanja na validacijski poslužitelj

Izlazne točke 16 Točke napada 6

ID 3

Ime prijetnje Baza podataka validacijskog poslužitelja nije raspoloživa

Opis prijetnje Kako logika validacije sustava ovisi o provjeri stanja ulaznica koja se čuvaju u bazi podataka ugroženo je ispravno izvođenje procesa validacije ulaznica.

Opis ranjivosti Validacijski server nema mehanizme za povezivanje s više RDBMS-ova između kojih bi mogao replicirati bazu podataka i napraviti oporavak u slučaju ne raspoloživosti jednog od njih

Uklanjanje prijetnje

Implementirati mehanizme za replikaciju baze podataka

Točke napada 4

64

ID 4

Ime prijetnje Napadač presreće komunikacijsku vezu prezentacijskog i aplikacijskog sloja komponenata

Opis prijetnje Ukoliko su prezentacijski i aplikacijski sloj pojedine komponente instalirani na različitim domenama, npr. dva različita računala povezana u lokalnu bežičnu mrežu, korisnik priključen na istu mrežu može neovlašteno iskorištavati RPC mehanizme aplikacijskog sloja

Opis ranjivosti Na aplikacijskom sloju komponenata nisu implementirani mehanizmi autorizacije za klijente koji prema njemu izvršavaju RPC pozive

Uklanjanje prijetnje

Komponente je potrebno konfigurirati tako da koriste siguran kanal SecureAMFChannel za međusobnu komunikaciju. Također je potrebno izvesti autorizaciju klijenata za BlazeDS RPC poslužiteljske mehanizme na razini J2EE poslužitelja u kojemu je pokrenut.

Ulazne točke 6, 7, 14, 15 Izlazne točke 1, 2, 4, 5

Točke napada 2

ID 5

Ime prijetnje Napadač zadobiva neovlašteni pristup GUI-u i konfiguracijskim datotekama validacijskog poslužitelja ili klijenta

Opis prijetnje Napadač koji ima pristup GUI-u i konfiguracijskim datotekama komponenata ima pristup i svim ulaznim točkama u sustavu

Opis ranjivosti Sustav nema implementirane mehanizme za autorizaciju korisnika

Uklanjanje prijetnje

Implementirati mehanizme za autorizaciju korisnika sustava na razini korisničkog sučelja sustava, te povezati mehanizme s prezentacijskim slojem - izvesti autorizaciju klijenata za BlazeDS RPC poslužiteljske mehanizme na razini J2EE poslužitelja u kojemu je pokrenut. Uvesti inicijalizaciju komponenata pomoću kriptiranih konfiguracijskih datoteka ili primijeniti druge mehanizme za preuzimanje konfiguracijskih postavki.

Ulazne točke * Izlazne točke *

Točke napada *

65

4. Instalacija i korištenje e-Portira

4.1. Instalacija

4.1.1. Softverski i hardverski zahtjevi

Prije instalacije sustava e-Portir potrebno je instalirati vanjske programske

komponente prema tablici 4.1.:

Tablica 4.1. Vanjske programske komponente potrebne za pokretanje sustava e-Portir

e-Portir Ulaznični

poslužitelj Validacijski

klijent Validacijski poslužitelj

Java Development Kit (verzije 6 ili veće) ● ● ● J2EE web poslužitelj ● ● ● Adobe BlazeDS aplikacija ● ● ● HTTP poslužitelj ● PHP interpreter (verzije 4.1 ili veće) ● MySQL RDBMS ● Adobe Flash runtime (verzije 9 ili veće) ● ● ● Adobe AIR runtime ● ● Internet preglednik ●

Sve tri komponente sustava e-Portir su neovisne i mogu biti instalirane na

različitim računalima. Slijedno tome, na računala koja pokreću svaku pojedinu

komponentu potrebno je instalirati samo one tehnologije označene upravo za tu

komponentu.

Sivom bojom u tablici 4.1. označene su konkretne tehnologije i implementacije

koje je potrebno instalirati:

- Java Development Kit http://java.sun.com/javase/downloads/index.jsp

- Adobe BlazeDS aplikacija http://opensource.adobe.com/wiki/display/blazeds/BlazeDS

- PHP interpreter http://www.php.net/

66

- MySQL RDBMS http://www.mysql.com/

- Flash runtime http://www.adobe.com/products/flashplayer/

- Adobe AIR runtime http://www.adobe.com/products/air/

Izbor za odabir implementacija ostalih tehnologija je višeznačan, pa istaknimo da

su dolje niže navedene samo neke mogućih opcija implementacija:

- J2EE web poslužitelj: Apache Tomcat http://tomcat.apache.org/

- HTTP poslužitelj: Apache HTTP Server http://httpd.apache.org/

- Internet preglednik: Mozilla Firefox http://www.mozilla.com/firefox/

Preuzimanje, instalacija i korištenje svih gore navedenih komponenata je

besplatno.

Za optičko skeniranje mobilne ulaznice na računalo koje pokreće aplikaciju

validacijskog klijenta e-Portira, potrebno je priključiti digitalnu kameru. Softverski

mehanizmi validacijskog klijenta automatski prepoznaju video ulaz kamere s USB

priključkom, tako da nije potrebno izvršavati druge postupke za povezivanje kamere i

aplikacije validacijskog klijenta.

4.1.2. Tijek instalacije

Za brzu instalaciju HTTP i J2EE poslužitelja, te PHP-a i MySQL-a možemo

koristiti XAMPP15 instalacijski paket s Apache Tomcat dodatkom. Instalacija navedenih

komponenata preko ovog besplatnog paketa vrlo je jednostavna, a korisniku se skraćuju

dodatne muke konfiguriranja instaliranih komponenata (npr. veze HTTP poslužitelja i

PHP interpretera i sl). Dalje obavimo instalaciju JDK 6, Adobe BlazeDS aplikacije, Flash

i AIR runtimea, te Internet preglednika.

15 http://www.apachefriends.org/en/xampp.html

67

Ulaznični poslužitelj

Instalacijske datoteke ulazničnog poslužitelja nalaze se u TicketingComponent.rar

arhivi. Struktura arhive je slijedeća: - TicketingServerWeb/ - TicketingComponent.jar - TicketingComponentUtilities/ - TEST/

1. Mape TicketingServerWeb i TicketingComponentUtilities smještamo unutar

public_html mape HTTP poslužitelja

2. U blazeds\WEB-INF\lib mapu BlazeDS aplikacije instalirane na J2EE serveru

smještamo TicketingComponent.jar.

3. Vršimo konfiguraciju ulazničnog poslužitelja u TicketingServer.xml16 datoteci koja se

nalazi u TicketingServerWeb mapi.

4. Vršimo konfiguraciju remoting-config.xml17 datoteke BlazeDS aplikacije.

Validacijski klijent

Instalacijske datoteke validacijskog klijenta nalaze se u ValidationClient.rar

arhivi na priloženom instalacijskom CD-u. Struktura arhive je slijedeća: - ValidationClient.air - ValidationClient.jar - TEST/

1. Pokrećemo ValidationClient.air i slijedimo korake instalacije

Sl. 4.1. Dijalog instalacije validacijskog klijenta

16 Primjer izgleda TicketingServer.xml konfiguracijske datoteke dan je u poglavlju 8. 17 Primjer izgleda remoting-config.xml konfiguracijske datoteke dan je u poglavlju 8.

68

2. U blazeds\WEB-INF\lib mapu BlazeDS aplikacije instalirane na J2EE serveru

smještamo ValidationClient.jar.

3. Vršimo konfiguraciju validacijskog klijenta u ValidationClient.xml18 datoteci koja se

nalazi u mapi odabranoj u koraku 1.

4. Vršimo konfiguraciju remoting-config.xml19 datoteke BlazeDS aplikacije.

Validacijski poslužitelj

Instalacijske datoteke validacijskog poslužitelja nalaze se u ValidationServer.rar

arhivi na priloženom instalacijskom CD-u. Struktura arhive je slijedeća: - ValidationServer.air - ValidationServer.jar - TEST/

1. Pokrećemo ValidationServer.air i slijedimo korake instalacije

2. U blazeds\WEB-INF\lib mapu BlazeDS aplikacije instalirane na J2EE serveru

smještamo ValidationServer.jar.

3. Vršimo konfiguraciju validacijskog poslužitelja u ValidationServer.xml20 datoteci

koja se nalazi u mapi odabranoj u koraku 1.

4. Vršimo konfiguraciju remoting-config.xml21 datoteke BlazeDS aplikacije.

5. Stvaramo bazu podataka validacijskog poslužitelja unutar MySQL RDBMS-a

18 Primjer izgleda TicketingServer.xml konfiguracijske datoteke dan je u poglavlju 8. 19 Primjer izgleda remoting-config.xml konfiguracijske datoteke dan je u poglavlju 8. 20 Primjer izgleda TicketingServer.xml konfiguracijske datoteke dan je u poglavlju 8. 21 Primjer izgleda remoting-config.xml konfiguracijske datoteke dan je u poglavlju 8.

69

4.2. Korištenje e-Portira

4.2.1. Ulaznični poslužitelj

Prije korištenja ulazničnog poslužitelja potrebno je generirati par javni, privatni

ključ ulazničnog poslužitelja 512-bitnim SHA1RSA algoritmom. Generirani par ključeva

pohranjujemo u datoteku s funkcijom spremišta ključeva. Nakon toga vršimo generiranje

javnog certifikata ulazničnog poslužitelja. Takav certifikat može se javno publicirati na

web sjedištu ulazničnog poslužitelja. Na kraju obavljamo unos novih konfiguracijskih

postavki u TicketingServer.xml22 datoteci.

Za izvršavanje prethodno navedenih operacija možemo npr. koristiti pomoćnu

aplikaciju keytool koja je sastavni dio JDK-a ili koristiti testne datoteke dostupne u mapi

TEST instalacijskog paketa ulazničnog poslužitelja.

Za pokretanje ulazničnog poslužitelja potrebno je pokrenuti: J2EE poslužitelj na

kojem se nalazi TicketingComponent.jar, HTTP poslužitelj koji pokreće web komponentu

poslužitelja i komponentu kodera barkoda. Nakon toga moguće je pristupiti web

komponenti ulazničnog poslužitelja Internet preglednikom (glavna datoteka je

TicketingServer.html).

Izdavanje ulaznice

1. Korisnik pristupa web komponenti ulazničnog poslužitelja

22 Primjer izgleda TicketingServer.xml konfiguracijske datoteke dan u dodatku dan je u poglavlju 8.

70

Sl. 4.2. Početna stranica web sjedišta ulaznične komponente

2. Korisnik predaje podatke za koje mu ulaznična komponenta generira mobilnu

ulaznicu (kod i barkod ulaznice). Korisnik također može izabrati razinu ispravljanja

pogrešaka za generirani i veličinu modula simbola barkoda ulaznice

Sl. 4.3. Izgled web sjedišta nakon izvršenog izdavanja ulaznice

71

4.2.2. Validacijski klijent

Za pokretanje validacijskog klijenta potrebno je pokrenuti: J2EE poslužitelj na

kojem se nalazi ValidationClient.jar i priključiti kameru23 na računalo. Nakon toga

pokrećemo instaliranu .exe aplikaciju.

Sl. 4.4. Izgled početnog ekrana validacijskog klijenta

Prije početka skeniranja i validacije ulaznica potrebno je izvršiti konfiguraciju

validacijskog klijenta koja uključuje inicijalizaciju certifikata ulazničnog servera i

povezivanje s validacijskim poslužiteljem. Konfiguracija validacijskog klijenta se vrši u

pogledu „Configuration“.

23 Kod testiranja sustava korištena je web kamera proizvođača CANYON, razlučivosti 0.3 megapiksela.

72

Inicijalizacija certifikata

1. Pritiskom na tipku „Browse“ moguće je odabrati lokalno pohranjen certifikat.

Sl. 4.5. Inicijalizacija certifikata na validacijskom klijentu

2. Nakon odabira certifikata pritiskom na tipku „Load“ vrši se inicijalizacija verifikatora

ulaznica validacijskog klijenta.

Povezivanje s validacijskim poslužiteljem

1. U polja „Server IP“ unosimo IP adresu i vrata validacijskog poslužitelja na koji se

želimo spojiti.

2. Pritiskom gumba „Connect“ validacijski klijent uspostavlja vezu s poslužiteljem

4.2.3. Validacijski poslužitelj

Za pokretanje validacijskog poslužitelja potrebno je pokrenuti: J2EE poslužitelj

na kojem se nalazi ValidationServer.jar i MySQL RDBMS. Nakon toga pokrećemo

instaliranu .exe aplikaciju.

73

Sl. 4.6. Izgled početnog ekrana validacijskog poslužitelja

Za ispravno funkcioniranje validacijskog poslužitelja potrebno je izvršiti:

- Spajanje na bazu podataka

- Odabrati tablicu životnog ciklusa usluge

- Pokrenuti klijentski poslužitelj

Spajanje na bazu podataka

1. U polje „Server database control“ unosimo adresu baze podataka, korisničko ime i

zaporku

2. Pritiskom gumba „Connect“ validacijski poslužitelj uspostavlja vezu s bazom

podataka

Odabir tablice životnog ciklusa usluge

74

1. Unutar polja „Event – database table binding“ pomoću padajućeg izbornika

„Avaliable events“ vršimo odabir raspoloživih tablica životnog ciklusa u bazi

2. Pritiskom gumba „Bind“ validacijski poslužitelj odabire izabranu tablicu ciklusa

Pokretanje klijentskog poslužitelja

1. Unutar polja „Server control“ unosimo vrata na kojima želimo pokrenuti klijentski

poslužitelj

2. Pritiskom gumba „Start“ pokreće se klijentski poslužitelj na odabranim vratima

Sl. 4.7. Ekran validacijskog poslužitelja s pokrenutim klijentskim poslužiteljem

i ostvarenom konekcijom na bazu podataka

Izvršavanje operacija nad bazom podataka

Operacije nad bazom podataka vrše se u pogledu „Server database“.

75

Sl. 4.8. Pogled "Server database" validacijskog poslužitelja

Unutar polja „Listed events from database“ moguće je:

- Pregledavati postojeće tablice ciklusa

- Pregledavati detalje tablica (dvoklik mišem na tablicu)

- Brisati tablice (označi tablicu > tipka DEL)

- Dodavati tablice (upis imena tablice u polje > gumb „Add event“)

Unutar polja „Listed events from database“ moguće je:

- Pregledavati postojeće zapise tablica

- Brisati zapise tablica

4.2.4. Validacija ulaznica

Za ispravnu validaciju ulaznica u e-Portiru svi indikatori u polju statusa sustava

validacijskoj klijenta i validacijskog poslužitelja moraju biti označeni zelenom bojom.

76

Sl. 4.9. Usporedni prikaz indikatora statusa sustava poslužitelja i klijenta

Primjer 4.1.: Pogledajmo redoslijed događaja validacije ulaznica u e-Portiru u kojemu

validacijska komponenta ima npr. tri validacijska klijenta, a sve komponente sustava su

već inicijalizirane i pokrenute: korisnik usluge nakon pribavljanja ulaznice prebacuje

ulaznicu na svoj mobilni uređaj i odlazi do koncertne dvorane. Na ulaznu koncertne

dvorane korisnik izlaže svoj mobilni uređaj validacijskom klijentu koji joj validira

ulaznicu

Sl. 4.10. Validacijski poslužitelj povezan sa tri validacijska klijenta (slika uz primjer 4.1.)

77

Sl. 4.11. Validacijski poslužitelj nakon uspješno izvršene validacije ulaznice (slika uz primjer 4.1.)

Sl. 4.12. Validacijski klijent nakon uspješno izvršene validacije ulaznice (slika uz primjer 4.1.)

78

5. Zaključak

Sustavom e-Portir u potpunosti je moguće realizirati uslugu mobilnih ulaznica.

Dodatnu vrijednost e-Portiru daje činjenica da je on izveden pomoću potpuno besplatnih

i lako dostupnih implementacijskih tehnologija. Teoretski gledano, sustav se može

slobodno prodavati bez plaćanja ikakvih licenca na korištene tehnologije. Nadalje, slaba

spregnutost slojeva arhitekture sustava omogućava ostvarivanje prezentacijskog i

aplikacijskog sloja svake pojedine komponente sustava (ulaznična, validacijski klijent i

poslužitelj) na različitim, udaljenim lokacijama, s potpuno različitom tehnologijom

izvedbe svakog sloja. Komponentni razvoj sustava i na aplikacijskom i na

prezentacijskom sloju, olakšava proširivost sustava u budućnosti.

Najosjetljiviji korak izgradnje sustava bio je izvedba logike validacije mobilne

ulaznice, samim time i konstrukcija informacije ulaznice. Odabirom i izvedbom neovisne

validacije ulaznica u e-Portiru omogućio se neovisan rad ulaznične i validacijske

komponente sustava, a zaštitom ulaznice asimetričnom kriptografijom ostvarena je

sigurna usluga mobilnih ulaznica.

Matko Kvesić

79

6. Literatura

[1] Automatic identification and data capture techniques — QR Code 2005 bar code

symbology specification, ISO/IEC, 2005.

[2] BAO F., ANANTHARAMAN L., DENG R., Design of Portable Mobile Devices Based E-

Payment System and E-Ticketing System with Digital Signature, Kent Ridge Digital

Labs, 2005.

[3] GAO J. Z., PRAKASH W., JAGATESAN R., Understanding 2D-BarCode Technology and

Applications in M-Commerce – Design and Implementation of A 2D Barcode

Processing Solution, IEEE, 2007.

[4] HOWARD M., LEBLANC D., Writing Secure Code 2nd Edition, Microsoft Press, 2003.

[5] HOWARD M., LEBLANC D., Writing Secure Code, Microsoft Press, 2001.

[6] JAKUBAUSKAS G., Improvement of urban passenger transport ticketing systems by

deploying intelligent transport systems, Vilnius Gediminas Technical University,

2006.

[7] JONKER J., M-Commerce and M-Payment, Bedrijfswiskunde en informatica, 2003.

[8] Masabi – Secure Mobile Applications, http://www.masabi.com/

[9] MENNECKE B., STRADER T., Mobile Commerce - Technology, Theory, and

Applications, Idea Group Publishing, 2003.

[10] SADEH N., M-Commerce Technologies, Services, and Business Models, John

Wiley & Sons, Inc., 2002.

[11] Security in Telecommunications and Information Technology, International

Telecommunication Union, 2003.

[12] SWIDERSKI F., SNYDER W., Threat Modeling, Microsoft Press, 2004.

[13] Threat Risk Modeling - OWASP, http://www.owasp.org/index.php/Threat_Risk_Modeling

[14] Web stranice kolegija Operacijski sustavi 2, http://os2.zemris.fer.hr

[15] Wikipedia, http://www.wikipedia.org

80

7. Kratice

3G Telekomunikacijska mreža 3 generacije

AMF engl. Action Message Format

ASCII engl. American standard code for information interchange

BLL engl. Bussiness Logic Layer

EMS engl. Enhanced Messaging Service

GPRS engl. General Packet Radio Service

GPS engl. Global Positioning System

GSM engl. Global system for mobile communications

GUI engl. Graphical User Interface

HTTP engl. Hypertext Transfer Protocol

IDE engl. Integrated Development Enviroment

IP engl. Internet Protocol

IrDa engl. Infrared data association

J2EE engl. Java 2 Platform Enterprise Edition

JDK engl. Java Development Kit

JPEG engl. Joint Photographic Experts Group

MMS engl. Multimedia Messaging Service

PDA engl. Personal Digital Assistant

PKI engl. Public key infrastructure

PNG engl. Portable Network Graphics

RDBMS engl. Relational database management system

RFID engl. Radio-frequency identification

RPC engl. Remote Procedure Call

SDK engl. Software Development Kit

SMS engl. Short Message Service

SMSC engl. Short Message Service Center

SOAP engl. Simple Object Access Protocol

TCP engl. Transmission Control Protocol

TLS engl. Transport Layer Security

VAS engl. Value-added services,

WAP engl. Wireless Application Protocol

WLAN engl. Wireless Local Area Network

XML engl. Extensible Markup Language

81

8. Dodaci

TicketingServer.xml

<?xml version="1.0"?> <conf> <AMF_CHANNEL_ID>my-amf</AMF_CHANNEL_ID> <AMF_CHANNEL_ENDPOINT>http://192.168.1.30:8080/blazeds/messagebroker/amf</AMF_CHANNEL_ENDPOINT> <RPC_SOURCE>hr.fer.dipl.ticketingserver.TicketingServer</RPC_SOURCE> <QR_ENCODER_URL>http://192.168.1.30/matko/TicketingComponentUtilities/QR/qr_img0.50g/php/qr_img.php</QR_ENCODER_URL> <KEYSTORE_FILE>C:/xampp/.keystore</KEYSTORE_FILE> <KEYSTORE_PASSWORD>123456</KEYSTORE_PASSWORD> <KEYSTORE_KEY_ALIAS>TicketingServer</KEYSTORE_KEY_ALIAS> <KEYSTORE_KEY_PASSWORD>654321</KEYSTORE_KEY_PASSWORD> </conf>

ValidationClient.xml

<?xml version="1.0"?> <conf> <AMF_CHANNEL_ID>my-amf</AMF_CHANNEL_ID> <AMF_CHANNEL_ENDPOINT>http://127.0.0.1:8080/blazeds/messagebroker/amf</AMF_CHANNEL_ENDPOINT> <RPC_SOURCE>hr.fer.dipl.validationclient.ValidationClient</RPC_SOURCE> </conf>

ValidationServer.xml

<?xml version="1.0"?> <conf> <AMF_CHANNEL_ID>my-amf</AMF_CHANNEL_ID> <AMF_CHANNEL_ENDPOINT>http://127.0.0.1:8080/blazeds/messagebroker/amf</AMF_CHANNEL_ENDPOINT> <RPC_SOURCE>hr.fer.dipl.validationserver.ValidationServer</RPC_SOURCE> </conf>

remoting-config.xml

<?xml version="1.0" encoding="UTF-8"?> <service id="remoting-service" class="flex.messaging.services.RemotingService"> <adapters> <adapter-definition id="java-object" class="flex.messaging.services.remoting.adapters.JavaAdapter" default="true"/> </adapters> <default-channels> <channel ref="my-amf"/> </default-channels> <destination id="validationClient"> <properties> <source>hr.fer.dipl.validationclient.ValidationClient</source> <scope>session</scope> </properties> <adapter ref="java-object"/> </destination> <destination id="validationServer">

82

<properties> <source>hr.fer.dipl.validationserver.ValidationServer</source> <scope>session</scope> </properties> <adapter ref="java-object"/> </destination> <destination id="ticketingServer"> <properties> <source>hr.fer.dipl.ticketingserver.TicketingServer</source> <scope>session</scope> </properties> <adapter ref="java-object"/> </destination> </service>