Skripta Zastita Racunarskih i Poslovnih Sistema 01

ZAŠTITA RAČUNARSKIH I POSLOVNIH SISTEMA

Skripta

Dr Milan Marković

Banja Luka, Januar 2009.

Sadržaj

1. UVOD...................................................................................................................................................................5

2. SAVREMENE RAČUNARSKE MREŽE, INFORMACIONI SISTEMI I SISTEMI ZAŠTITE..............6

2.1 SAVREMENE RAČUNARSKE MREŽE I TCP/IP PROTOKOL................................................................................62.2 TRENDOVI U SISTEMIMA ZAŠTITE SAVREMENIH RAČUNARSKIH MREŽA.........................................................72.3 POTENCIJALNI NAPADI NA SAVREMENE RAČUNARSKE MREŽE I MOGUĆI NAČINI ODBRANE........................102.4 PRIMERI NAPADA NA SAVREMENE RAČUNARSKE MREŽE.............................................................................11

2.4.1 Krađa identiteta - phishing................................................................................................................122.4.2 Prisluškivanje......................................................................................................................................122.4.3 Modifikacija podataka........................................................................................................................122.4.4 Identity spoofing (IP address spoofing)..........................................................................................122.4.5 Napadi na lozinke...............................................................................................................................132.4.6 Denial-of-service napad....................................................................................................................132.4.7 Man-in-the-middle napad..................................................................................................................142.4.8 Napad kompromitacije ključa............................................................................................................142.4.9 Sniffer napad.......................................................................................................................................142.4.10 Napad na aplikativnom nivou.........................................................................................................14

2.5 TEHNOLOGIJE ZAŠTITE SAVREMENIH RAČUNARSKIH MREŽA.......................................................................15

3. PRIMENA KRIPTOGRAFSKIH METODA ZAŠTITE U INFORMACIONOM SISTEMU.................16

3.1 SIMETRIČNI KRIPTOGRAFSKI ALGORITMI.......................................................................................................163.1.1 Blok šifarski sistemi............................................................................................................................173.1.2 Kriptografski modovi blok šifarskih algoritama..............................................................................303.1.3 Sekvencijalni šifarski sistemi............................................................................................................363.1.4 Komparativna analiza blok i sekvencijalnih šifarskih sistema.....................................................40

3.2 ASIMETRIČNI KRIPTOGRAFSKI ALGORITMI....................................................................................................413.2.1 PKCS#1 standard...............................................................................................................................413.2.2 RSA algoritam.....................................................................................................................................44

3.3 MESSAGE DIGEST ALGORITMI........................................................................................................................483.3.1 MD5 message digest algoritam........................................................................................................49

3.4 PRIMENA KRIPTOGRAFSKIH ALGORITAMA U INFORMACIONIM SISTEMIMA...................................................51

4. VIŠESLOJNA ARHITEKTURA SISTEMA ZAŠTITE SAVREMENIH RAČUNARSKIH MREŽA. . .52

4.1 ZAŠTITA NA APLIKATIVNOM NIVOU..............................................................................................................534.2 ZAŠTITA NA TRANSPORTNOM NIVOU.............................................................................................................554.3 ZAŠTITA NA MREŽNOM NIVOU.......................................................................................................................56

5. OSNOVE PKI SISTEMA.................................................................................................................................58

5.1 UVOD U SISTEME SA JAVNIM KLJUČEVIMA (PKI – PUBLIC KEY INFRASTRUCTURE).....................................585.1.1 Podrška različitim politikama rada PKI sistema.............................................................................585.1.2 Bezbednost sistema...........................................................................................................................595.1.3 Skalabilnost.........................................................................................................................................595.1.4 Fleksibilnost.........................................................................................................................................595.1.5 Jednostavno korišćenje.....................................................................................................................605.1.6 Otvorenost sistema............................................................................................................................60

5.2 KOMPONENTE PKI SISTEMA..........................................................................................................................605.2.1 Moduli PKI sistema............................................................................................................................62

5.3 SERTIFIKACIONO TELO (CA – CERTIFICATION AUTHORITY)........................................................................635.3.1 Funkcionalnost CA.............................................................................................................................645.3.2 Obeležja CA........................................................................................................................................65

5.4 OPERATOR SERTIFIKACIONOG TELA (CAO)..................................................................................................655.4.1 Funkcionalnost CAO..........................................................................................................................655.4.2 Obeležja CAO.....................................................................................................................................66

2

5.5 REGISTRACIONO TELO (RA)..........................................................................................................................665.5.1 Funkcionalnost RA.............................................................................................................................665.5.2 Obeležja RA........................................................................................................................................67

5.6 OPERATOR REGISTRACIONOG TELA (RAO)...................................................................................................675.6.1 Funkcionalnost RAO..........................................................................................................................675.6.2 Obeležja RAO.....................................................................................................................................68

5.7 SERTIFIKACIONO TELO KAO WEB VIŠESLOJNA APLIKACIJA...........................................................................685.8 DIGITALNI SERTIFIKATI, STRUKTURA I STANDARDI.......................................................................................68

5.8.1 ITU X.509 v3 sertifikat-struktura.......................................................................................................705.8.2 Ekstenzije u sertifikatu.......................................................................................................................725.8.3 Najčešće korišćene ekstenzije.........................................................................................................79

5.9 METODE REGISTRACIJE KORISNIKA...............................................................................................................795.9.1 Registracija u ličnom kontaktu..........................................................................................................815.9.2 Udaljena registracija..........................................................................................................................82

5.10 SISTEMI ZA DISTRIBUCIJU SERTIFIKATA......................................................................................................845.11 UPRAVLJANJE ŽIVOTNIM VEKOM SERTIFIKATA...........................................................................................85

5.11.1 Obnavljanje sertifikata.....................................................................................................................855.11.2 Povlačenje sertifikata.......................................................................................................................855.11.3 Suspenzija sertifikata.......................................................................................................................85

5.12 LISTA POVUČENIH SERTIFIKATA..................................................................................................................865.13 OPIS PROCEDURE GENERISANJA I ZAŠTITE ASIMETRIČNIH KLJUČEVA SERTIFIKACIONOG TELA..................90

5.13.1 Opšta obeležja HSM........................................................................................................................915.13.2 Opšta obeležja smart kartica..........................................................................................................94

5.14 SERVER ZA ARHIVIRANJE KLJUČEVA...........................................................................................................975.14.1 Funkcionalnost servera za arhiviranje ključeva...........................................................................995.14.2 Obeležja Arhiv servera....................................................................................................................99

5.15 STANDARDI KOJI SE ODNOSE NA FUNKCIONISANJE PKI SISTEMA...............................................................995.15.1 Abstract sintax notation one - ASN.1..........................................................................................1005.15.2 ITU X.509 v3 sertifikat-struktura..................................................................................................1015.15.3 ITU X.509 v2 lista opozvanih sertifikata.....................................................................................1025.15.4 X.509 v2 lista opozvanih sertifikata - formiranje........................................................................102

5.16 TIPOVI SERTIFIKACIONIH TELA I MOGUĆI NAČINI REALIZACIJE................................................................1035.17 GENERIČKI MODEL REALIZACIJE CA KAO SOFTVERSKOG-HARDVERSKOG SISTEMA ZA GENERISANJE DIGITALNIH SERTIFIKATA..................................................................................................................................1045.18 ORGANIZACIONI ASPEKTI FUNKCIONISANJA PKI SISTEMA........................................................................107

5.18.1 Bezbednosne procedure u odnosu na ljudski faktor................................................................1075.18.2 Bezbednosne procedure u odnosu na prostorije i uređaje......................................................1095.18.3 Sistemi fizičke i logičke kontrole pristupa u okviru Sertifikacionog tela.................................110

5.19 OSNOVNI DOKUMENTI RADA SERTIFIKACIONOG TELA..............................................................................1125.19.1 Politika sertifikacije – opšti koncept.............................................................................................1135.19.2 Relativni odnos dokumenata Politika sertifikacije i Praktična pravila rada...........................1145.19.3 Sadržaj dokumenata Politika sertifikacije i Praktična pravila rada.........................................1155.10.4 Interna pravila rada sertifikacionog tela......................................................................................1175.19.5 Upravljanje radom PKI sistema....................................................................................................118

5.20 KRITERIJUMI KOJE CA TREBA DA ISPUNI DA BI IZDAVALO KVALIFIKOVANE SERTIFIKATE......................1195.20.1. Sposobnost za pouzdano obavljanje usluga izdavanja elektronskih sertifikata..................1215.20.2 Bezbedno i ažurno vođenje registra korisnika kao i sprovođenje bezbednog i trenutnog opoziva elektronskog sertifikata...............................................................................................................1235.20.3 Obezbeđivanje tačnog utvrđivanja datuma i vremena izdavanja ili opoziva elektronskog sertifikata......................................................................................................................................................1235.20.4 Obezbeđivanje pouzdane registracija korisnika........................................................................1235.20.5 Obezbeđivanje neophodnih kadrovskih resursa i upravljanja operativnim radom sertifikacionog tela......................................................................................................................................1255.20.6 Korišćenje pouzdanih i bezbednih kriptografskih sistema.......................................................1265.20.7 Zahvevi za obezbeđenjem zaštite od falsifikovanja sertifikata i tajnosti generisanih ključeva.......................................................................................................................................................................1295.20.8 Zahtevi za odgovornošću i osiguranjem od rizika.....................................................................1305.20.9 Zahvevi za čuvanjem svih relevantnih informacija....................................................................1315.20.10 Zahtevi za bezbednim uslovima za korisnike za koje se generišu podaci za formiranje elektronskog potpisa..................................................................................................................................132

3

5.20.11 Zahtevi za sisteme fizičke zaštite uređaja, opreme i podataka i sigurnosna rešenja zaštite od neovlašćenog pristupa.........................................................................................................................1335.20.12 Zahtevi za raspoloživošću informacija o uslovima izdavanja i korišćenja sertifikata........1355.20.13 Zahtevi za sistem upravljanja sertifikatima..............................................................................135

5.21 ASPEKTI INTEROPERABILNOSTI PKI SISTEMA...........................................................................................1365.21.1 Kriterijumi i proces krossertifikacije.............................................................................................136

5.22 DOSADAŠNJA ISKUSTVA U IZGRADNJI SERTIFIKACIONIH TELA.................................................................138

6. IMPLEMENTACIJA SISTEMA UPRAVLJANJA INFORMATIČKOM BEZBEDNOŠĆU U ORGANIZACIJI PO STANDARDU ISO/IEC 27001:2005............................................................................142

6.1 UVOD...........................................................................................................................................................1426.2 ISTORIJAT ISO/IEC 27001:2005 STANDARDA.............................................................................................1426.3 USPOSTAVA I UPRAVLJANJE ISMS SISTEMOM............................................................................................145

6.3.1 Uspostava ISMS (Plan)...................................................................................................................1456.3.2 Implementacija i operativni rad ISMS sistema (Do)....................................................................1476.3.3 Nadzor i preispitivanje ISMS sistema (Check)............................................................................1476.3.4 Održavanje i poboljšanje ISMS sistema (Act)..............................................................................148

6.4 ZAHTEVI ZA DOKUMENTACIJOM..................................................................................................................1496.4.1 Opšte odredbe..................................................................................................................................1496.4.2 Kontrola dokumenata.......................................................................................................................1496.4.3 Kontrola zapisa.................................................................................................................................150

6.5 ODGOVORNOST MENADŽMENTA..................................................................................................................1506.5.1 Posvećenost menadžmenta...........................................................................................................150

6.6 UPRAVLJANJE RESURSIMA...........................................................................................................................1516.6.1 Obezbeđivanje resursa....................................................................................................................1516.6.2 Obuka, svesnost i kompetencija....................................................................................................151

6.7 INTERNI ISMS AUDITI.................................................................................................................................1516.8 UPRAVNI PREGLED ISMS SISTEMA.............................................................................................................152

6.8.1 Opšte odredbe..................................................................................................................................1526.8.2 Ulazi za pregled................................................................................................................................1526.8.3 Izlazi upravnog pregleda.................................................................................................................153

6.9 POBOLJŠANJE ISMS SISTEMA......................................................................................................................1536.9.1 Kontinualno poboljšavanje..............................................................................................................1536.9.2 Korektivne akcije..............................................................................................................................1536.9.3 Preventivne akcije............................................................................................................................154

6.10 Proces sertifikacije prema ISO/IEC 27001:2005 standardu......................................................................154

4

1. UVOD

Ovaj dokument predstavlja skriptu za izvođenje predmeta „Zaštita računarskih i poslovnih sistema“ na Fakultetu poslovne informatike Univerziteta Apeiron u Banja Luci.

U okviru ovog kursa analiziraju se ključna pitanja bezbednosti u računarskim mrežama i informacionim sistemima. Analiziraju se takođe osnovne bezbednosne karakteristike savremenih računarskih mreža bazirane na Internet tehnologijama i dat je prikaz tehnika i kriptografskih protokola kojima se navedeni bezbednosni problemi rešavaju.

Razmatraju su trendovi u zaštiti računarskih mreža, potencijalni napadi, mogući načini odbrane, tehnologije zaštite, standardni kriptografski algoritmi, digitalni potpis, digitalna envelopa, PKCS standardi i višeslojna arhitektura zaštite. Opisane su tehnike zaštite na aplikativnom, transportnom i mrežnom nivou ISO/OSI modela koje se baziraju na primjeni infrastrukture sistema sa javnim ključevima.

Pored toga, razmatraju se softverska, softversko/hardverska i hardverska rješenja zaštite. U tom smislu, razmatrane su procedure jake autentikacije, kao i primena tokena, smart kartica i HSM urjeđaja.

U okviru kursa se posebno razmatra infrastruktura sistema sa javnim ključevima (PKI - Public Key Infrastructure) koja omogućuje ambijent za pouzdanu primjenu elektronskog poslovanja i koja se najčešće bazira na kombinovanoj primeni asimetričnih i simetričnih kriptografskih sistema. PKI sistemi se baziraju na digitalnim sertifikatima kao jednoznačnim elektronskim identifikatorima ovlašćenih učesnika u računarskoj mreži. Dodatno se razmatraju komponente PKI sistema, sertifikaciono telo (CA), registraciona tela (RA), PKI aplikacije, kao i primjeri realizacije PKI sistema i PKI aplikacija. Takođe su razmatrani i aspekti primene odgovarajuće Evropske i domaće Zakonske regulative u domenu digitalnog potpisa i PKI sistema.

Na kraju se razmatraju aspekti implementacije sistema upravljanja informatičkom bezbednošću u skladu sa svetskim standardima (ISO/IEC 27001:2005).

Ova skripta služi radi lakšeg praćenja predavanja na predmetu Zaštita računarskih i poslovnih sistema, kao i za pripremanje za polaganje kolokvijuma i ispita. Materijal u skripti je komplementaran sa materijalom koji će biti prikazan na prezentacijama tako da skripta i prezentacije zajedno čine kompletan materijal za pripremu i polaganje ispita.

5

2. SAVREMENE RAČUNARSKE MREŽE, INFORMACIONI SISTEMI I SISTEMI ZAŠTITE

2.1 Savremene računarske mreže i TCP/IP protokol

Savremene računarske mreže se uglavnom baziraju na Internet tehnologijama i protokolima koji su podložni mogućim napadima koji narušavaju bezbednost podataka i identiteta subjekata.

Ključni problem leži u činjenici da podaci kruže i egzistiraju u elektronskom obliku koji nije neposredno vidljiv i zbog toga postaju izloženi novim vrstama napada, a osnovni razlozi za to leže u samim osnovnim karakteristikama arhitekture računarskih mreža Internet/Intranet tipa:

TCP/IP protokoli nisu projektovani da zadovolje zahteve za zaštitom informacija,

Internet je mreža sa komutacijom paketa u kojoj se jednostavno pristupa informacijama koje se prenose i moguće je ubacivanje poruka nepoznatog porekla i sadržaja.

U cilju rešavanja navedenih problema, uporedo sa razvojem računarskih mreža, razvijaju se i specijalizovani softverski i hardverski sistemi zaštite.

Danas u svetu postoji veliki broj proizvođača tehnološki kvalitetnih proizvoda za različite nivoe zaštite savremenih mreža. U ovim proizvodima su ugrađeni javni “de-facto” standardni kriptografski algoritmi. Ovi algoritmi obezbeđuju dovnoljni nivo bezbednosti za većinu komercijalnih informacionih sistema i računarskih mreža.

Iako pomenuti proizvodi predstavljaju veoma kvalitetna rešenja sa stanovišta tehnologije realizacije, oni se ne preporučuju za primenu u TCP/IP računarskim mrežama sa bezbedno osetljivim podacima. Osnovni razlog je nepostojanje potpune sigurnosti u kriptografski kvalitet ovih rešenja, npr. ona se ne mogu verifikovati na nivou izvornog koda.

Najkvalitetnija kriptografska rešenja koja se primenjuju u savremenim računarskim mrežama baziraju se na primeni simetričnih kriptografskih sistema za zaštitu tajnosti (u specijalnim slučajevima po mogućstvu uz korišćenje sopstvenih simetričnih algoritama višeg kriptografskog kvaliteta), tehnologije digitalnog potpisa na bazi asimetričnih kriptografskih sistema, digitalnih certifikata i hardverskih modula (smart kartice i kriptografski koprocesori).

Ovakvi sistemi zaštite su projektovani da se uspešno odbrane od potencijalnih opasnosti i napada u cilju ugrožavanja bezbedno osetljivih resursa informacionih sistema.

Kriptografski algoritmi koji se primenjuju u sistemima zaštite Internet/Intranet računarskih mreža dele se u dve velike grupe:

Simetrični kriptografski algoritmi,

6

Asimetrični kriptografski algoritmi.

Podela je izvedena na osnovu posedovanja informacija neophodnih za šifrovanje i dešifrovanje. Primenom simetričnih kriptografskih algoritama se, kao i u tradicionalnim sistemima zaštite, ostvaruje funkcija zaštite tajnosti u savremenim informacionim sistemima.

Sa druge strane, primenom asimetričnih kriptografskih algoritama i tehnologije digitalnog potpisa ostvaruju se sledeće funkcije u savremenim računarskim mrežama:

Autentičnost strane koja je poslala digitalno potpisanu poruku, Zaštita integriteta podataka u poruci koja je poslata, Neporecivost elektornskog potpisnika za sadržaj date poruke.

2.2 Trendovi u sistemima zaštite savremenih računarskih mreža

Uporedo sa razvojem i implementacijom računarskih mreža Interenet tipa, razvijaju se i različiti mehanizmi zaštite specijalizovani za odbranu od pojedinih vrsta napada.

U startu treba biti svestan da računarske mreže Internet tipa, pored toga što omogućavaju izuzetno povećanje efikasnosti rada i smanjenje troškova, predstavljaju kritičnu tačku bezbednosti date organizacije sa stanovišta bezbednosti informacija koje se u sistemu prenose.

U svetu postoji veliki broj različitih pregleda i analiza opasnosti korišćenja računarskih mreža na bazi Internet tehnologija izrađenih od strane relevantnih institucija. Jedna takva analiza ukazuje na tipove napada, u procentima prijavljenih napada, Slika 2.1, kao i prosečne gubitke prouzrokovane tim napadima u 2001. godini, Slika 2.2.

Slika 2.1: Tipovi prijavljenih napada na računarske mreže u procentima

7

Prema jednom sličnom pregledu američkog instituta za zaštitu računara (Computer Security Institute (CSI)’s 2000 Computer Crime and Security Survey) koji je obuhvatao velike korporacije, 70% razmatranih subjekata je prijavilo detektovane neautorizovane pristupe u svojim mrežama u prethodnoj godini.

Takođe, prema istoj analizi, u prethodnih 5 godina, 66 razmatranih subjekata je prijavilo ukupan gubitak proizveden krađom osetljivih korporacijskih informacija u iznosu od $66 708 000, a 54 razmatrana subjekta su prijavila ukupan gubitak proizveden finansijskom proneverom u iznosu od $53 996 000.

Slika 2.2: Procečni gubici u 2001. godini

Ova analiza je takođe potvrdila sledeće trendove u korišćenju računarskih mreža Internet tipa u poslednje vreme:

Razvoj sve šireg spektra mogućih napada. Napadi na korporacijske računarske mreže Internet tipa mogu biti eksterni i

interni. Iako su prethodnih godina napadi na računarske mreže Internet tipa bili pretežno eksterni, novije analize (kao što je i prethodno pomenuta analiza CSI) pokazuju da mnogo veću štetu i finansijske gubitke nanosi širok spektar internih napada. Razlozi za to leže u samoj prirodi mreža Internet tipa u kojima interni učesnici nisu samo zaposleni u datoj korporaciji (za koje postoji određeni stepen poverenja), već i poslovni partneri, zaposleni u firmama podružnicama, kooperanti, dostavljači, itd., koji iz razloga jednostavnosti korišćenja i povećanja efikasnosti i produktivnosti rada imaju vrlo sličan, ako ne i isti, pristup korporacijskoj mreži kao i zaposleni u datoj korporaciji.

U poslednje vreme su zabeleženi veoma veliki finansijski gubici prouzrokovani napadima na računarske mreže Internet tipa.

Uočeno je da primena samo komercijalnih tehnologija zaštite informacija ne može uvek predstavljati pouzdano rešenje odbrane od potencijalnih napada već da se ponekad mora koncipirati i primeniti slojevita i sveobuhvatna politika zaštite koja će pored komercijalnih tehnologija zaštite obavezno uključiti i

8

primenu kvalitetnijih, sopstveno realizovanih mehanizama zaštite, kao i mehanizama kontrole pristupa i organizacionih elemenata zaštite date računarske mreže Internet tipa.

Sa druge strane, SANS Institut je obavio istraživanja koja su rezultovala u definisanju tri liste osnovnih grešaka koje omogućavaju različite vrste napada na mreže Internet tipa i pojedinačne radne stanice u mreži.

Prva lista se odnosi na krajnje korisnike i definiše sledećih pet najvećih bezbednosnih grešaka:

Otvaranje nezahtevanog e-mail priloga (attachment) dobijenog od nepoverljivog izvora,

Propust da se instaliraju bezbednosni patch-evi standardnih Internet programskih paketa, kao i novih definicija (upgrade) antivirusnih programa,

Instaliranje i download-ovanje screen saver-a i igara od nepoverljivih izvora, Nekreiranje i netestiranje back-up operacija, Korišćenje modema dok ste vezani u lokalnoj računarskoj mreži (LAN).

Druga lista se odnosi na korporacijske uprave (management) i definiše sledećih sedam najvećih bezbednosnih grešaka koje utiču na slabosti korporacijske računarske mreže:

Neobezbeđenje odgovarajućeg broja službenika koji treba da uspostave i održavaju sistem zaštite u okviru korporacije,

Primena samo organizacionih vidova zaštite bez primene (i bez prihvatanja neophodnosti primene) mehanizama zaštite informacija,

Rešavanje samo pojedinačnih bezbednosnih problema bez primene mera i stvaranja uslova za kreiranje kompletnog sistema zaštite koji bi osigurao rešenje najšireg spektra bezbednosnih problema,

Korišćenje samo mrežnih barijera (firewall) u korporacijskoj računarskoj mreži, Neshvatanje koliko vrede intelektualno vlasništvo i poslovna reputacija firme, Primena kratkotrajnih rešenja pojedinačnih situacija što dovodi do brzog

umnožavanja bezbednosnih problema, Pretvaranje da će se bezbednosni problemi rešiti sami od sebe ako se

ignorišu.

Treća lista se odnosi na informatičke profesionalce i definiše sledećih deset najvećih bezbednosnih grešaka:

Priključivanje računarskog sistema na Internet bez prethodne primene svih neophodnih bezbednosnih mera da se to učini,

Priključivanje test i razvojnih sistema na Internet sa default lozinkama, Propust da se sistem ažurira sa rešenjima nekih bezbednosnih problema, Korišćenje nekriptovanih protokola za upravljanje sistemima, ruterima i

firewall-ovima, Davanje korisnicima lozinki preko telefona i njihovo menjanje bez prethodne

autentikacije osobe koja zahteva izmenu, Propust pri održavanju i testiranju procedure back-up-a sistema, Korišćenje nepotrebnih Internet servisa,

9

Primena mrežnih barijera sa pravilima koja ne osiguravaju bezbedno osetljivi dolazeći i odlazeći saobraćaj,

Propust u implementaciji i ažuriranju softverskog paketa za detekciju virusa, Propust u edukaciji korisnika u odnosu na to šta je potrebno učiniti kada se

uoči potencijalni bezbednosni problem.

Imajući u vidu prethodno rečeno, u nastavku su sumirani najčešći vidovi potencijalnih napada i moguće odbrane u okviru TCP/IP distribuiranih računarskih sistema.

2.3 Potencijalni napadi na savremene računarske mreže i mogući načini odbrane

Najčešći vidovi napada na računarske mreže Internet/Intranet tipa su:

Prisluškivanje – neovlašćeno pristupanje podacima u otvorenom obliku i lozinkama,

Lažno predstavljanje – neautorizovani pristup podacima ili kreiranje neautorizovanih podataka,

Napad tipa ukidanja servisa (denial-of-service) – onemogućavanje funkcionisanja mrežnih servisa i resursa,

Ponavljanje poslatih poruka – neovlašćena kontrola komunikacije subjekata i ponavljanje, izmena ili sprečavanje prenosa podataka,

Pogađanje lozinke – neovlašćeni pristup podacima uz pomoć otkrivene lozinke,

Kriptoanaliza – otkrivanje tajnih ključeva – otkrivanje podataka u otvorenom obliku na bazi šifrata i otkrivenog tajnog ključa,

Napadi tipa Trojanskog konja – distribucija zlonamernih programa na radne stanice,

Virusi – uništenje podataka.

Iako pomenuti napadi nisu specifični samo za TCP/IP računarske mreže oni su tu najviše ispoljeni jer se daleko najveći broj računarskih mreža u svetu bazira na Internet tehnologijama.

Mogući načini odbrane od navedenih napada su sledeći:

Šifrovanje – zaštita tajnosti podataka i lozinki, Primena tehnologije digitalnog potpisa – provera autentičnosti, zaštita

integriteta podataka i obezbeđenje neporecivosti za sadržaj poslate poruke, Procedura jake autentikacije – bezbedna međusobna autentikacija strana u

komunikaciji, Korišćenje jakih ključeva i česta izmena ključeva – sprečavanje metoda

kriptoanalize, Zaštita adresa servera – zaštita od napada tipa ukidanje servisa, Korišćenje digitalnih certifikata kao jednoznačnih identifikacionih parametara

subjekata u komunikaciji, Korišćenje smart kartica za generisanje digitalnog potpisa i bezbedno čuvanje

ključeva i drugih kriptografskih parametara, Višenivoska antivirusna zaštita.

10

U cilju odbrane od navedenih potencijalnih napada na mrežu, najsvrsishodnije je primeniti kombinovane metode zaštite koje se sastoje od većine gore navedenih metoda.

2.4 Primeri napada na savremene računarske mreže

Internet je uveo revoluciju u način na koji kompanije posluju s obzirom da je to izuzetno efikasan, jeftin i fleksibilan protokol.

Međutim, postojeće metode koje se koriste za rutiranje paketa u mreži čine ih ranjivim u odnosu na veliki opseg bezbednosnih rizika, kao što su: spoofing, sniffing i session hijacking. Takođe, TCP/IP protokol ne obezbeđuje nikakvu formu neporecivosti za ugovorne i finansijske transakcije.

Pored toga što moraju da obezbede interno okruženje, organizacije moraju da obezbede i komunikaciju između udaljenih kancelarija, poslovnih partnera, korisnika i zaposlenih koji putuju ili rade sa udaljenog mesta. Prenošenje poruka putem Interneta ili Intraneta do tih različitih entiteta predstavlja jedan očigledan rizik, imajući u vidu nedostatak zaštite u postojećoj Internet mreži. Kontrola i upravljanje bezbednošću i pristupom pomenutih entiteta u poslovnom okruženju kompanije je od izuzetnog značaja.

Bez primene bezbednosnih mehanizama, i javne i privatne mreže su ranjive na neovlašćeno nadgledanje i pristup. Interni napadi mogu biti rezultat minimalne ili nepostojeće Intranet bezbednosti.

Rizici koji dolaze spolja u jednoj privatnoj mreži potiču od konekcija na Internet i ekstranet. Kontrola pristupa korisnika samo na bazi password-a ne može da zaštiti podatke koji se prenose kroz mrežu.

Bez primene kontrola i mera bezbednosti, vaši podaci i sistemi mogu biti predmet napada. Neki napadi su pasivni u kojima se informacije samo mpnitorišu. Drugi napadi su aktivni i informacije se menjaju sa ciljem menjanja ili uništenja samih podataka ili same mreže putem koje se vrši prenos podataka. Vaše mreže i podaci su ranjivi na bilo koji od tipova napada koji su navedeni u nastavku ukoliko niste primenili odgovarajuže bezbednosne mere.

U nastavku, daćemo osnovne informacije i listu uobičajenih mrežnih napada koje se primenjuju na fiksne i mobilne TCP/IP računarske mreže. Jedan dobar pregled ovih ranjivosti se može naći na Microsoft resursima (www.microsoft.com).

Krađa identiteta - phishing Prisluškivanje Modifikacija podataka Spoofing identiteta (IP address spoofing) Napadi na lozinke Denial-of-service (DoS) napad Man-in-the-middle napad

11

http://www.microsoft.com/

Napad kompromitacije ključa Sniffer napad Napad na aplikativnom nivou

2.4.1 Krađa identiteta - phishing

To je jedan od danas najpopularnijih napada. U najkraćem, napad se ogleda u pretvaranju da se radi o validno web sajtu određene organizacije, kao i da se radi o validnoj aktivnosti (resetovanje, neke administrativne aktivnosti, itd.) u vezi korisničkih tajnih parametara pristupa sistemu (credentials). U tom smislu, napadač traži od korisnika da dostavi napadaču svoje tajne parametre (brojeve kartica ili bilo šta drugo).

Drugim rečima, phishing predstavlja simuliranje pravog bankarskog web sajta ili email adrese u cilju jednostavnog sakupljanja tajnih parametara krajnjih korisnika koji se zatim koriste za eventualnu kražu novca sa realnog web sajta.

Phishing predstavlja jednu novu vrstu Internet napada koji pre svega cilja korisnike bankarskih servisa. Phishing je jedan od prvih bezbednosnih napada koji omogućuje jednostavnu masovnu zloupotrebu, koja privlači organizovan kriminal.

2.4.2 Prisluškivanje

U opštem slučaju, veliki deo mrežnih komunikacija se realizuje u otvorenom obliku (nešifrovano), što omogućuje napadaču koji je pristupio putevima podataka u mreži da monitoriše i čita saobraćaj. Kada napadač prisluškuje komunikaciju, to se naziva sniffing ili snooping. Mogućnost da prisluškivač monitoriše mrežu je generalno najveći bezbednosni problem sa kojim se admnistratori susreću u jednoj organizaciji. Ukoliko se ne primene jaki kriptografski mehanizmi šifrovanja, podaci mogu biti čitani od strane neovlašćenih lica tokom prolaska kroz mrežu.

2.4.3 Modifikacija podataka

Nakon što napadač dođe u poziciju da može da čita podatke koji prolaze kroz računarsku mrežu orgnaizacije, naredni logički korak je često da ih modifikuje. Često, napadač može menjati podatke u paketima na način da niti primalac niti pošiljalac mogu to primetiti.

2.4.4 Identity spoofing (IP address spoofing)

Većina mreža i operativnih sistema koristi IP adrese u cilju identifikacije validnog računara na mreži. U nekim slučajevima, moguće je da se zloupotrebi IP adresa od strane zlonamernog korisnika (napadača). Taj napad je poznat kao identity spoofing.

Napadač može koristiti specijalne programme da konstruiše IP pakete koji se pojavljuju na mreži kao da potiču sa validnih adresa u okviru Intranet-a (internet mreže) date organizacije. Nakon dobijanja pristupa mreži sa validnom IP adresom, napadač može modifikovati, rerutirati ili brisati podatke.

12

Napadač takođe može sprovoditi i druge tipove napada, kao što je opisano u narednim sekcijama.

2.4.5 Napadi na lozinke

Uobičajena stvar u većini operativnih sistema i mrežnih bezbednosnih planova je korišćenje sistema kontrole pristupa na bazi lozinki. Naime, najčešće je pristup kako samom računaru tako i mrežnim resursima određen korisničkim imenom (user name) i lozinkom (password).

Ranije verzije komponenata operativnih sistema nisu uvek štitile informacije o identitetu korisnika tokom njihovog puta kroz mrežu u cilju validacije. To je moglo da omogući prisluškivaču da dobije validno korisničko ime i lozinku i da ih iskoristi da dobije pristup mreži kao validan koristnik.

Kada napadač nađe i pristupi validnom korisničkom nalogu, on će imati ista prava kao i aktielni korisnik. Na primer, ukoliko korisnik ima administratorska prava, napadač može kreirati dodatne naloge za kasniji pristup. Nakon što dobije pristup mreži sa validnim nalogom, napadač može realizovati bilo koju od sledećih aktivnosti:

Da dobije liste validnih korisnika i imena računara, kao i mrežnih informacija, Da modifikuje konfiguracije servera i same računarske mreže, uključujući i

kontrolu pristupa i ruting tabele, Da modifikuje, rerutira ili obriše podatke.

2.4.6 Denial-of-service napad

Za razliku od napada na lozinke, Denial-of-Service (DoS) napad sprečava normalno korišćenje računara ili računarske mreže od strane validnih korisnika.

Nakon što dobije pristup mreži, napadač može realizovati bilo koju od aktivnosti:

Da prevari zaposlene informacionog sistema tako da oni nisu u mogućnosti da odmah detektuju napad. Na taj način, napadač ima mogućnost da kreira dodatne napade,

Da šalje nevalidne podatke aplikacijama ili mrežnim servisima, prouzokujući na taj način da se prekine rad aplikacija ili servisa ili da ne rade na uobičajen način,

Da šalje veliku gomilu saobraćaja sve dok se računar ili čitava mreža ne ugase,

Da blokira saobraćaj što rezultuje u nemogućnosti pristupa mrežnim resursima od strane autorizovani korisnika.

2.4.7 Man-in-the-middle napad

13

Kao što i sam ime kaže, man-in-the-middle napad se ostvaruje kada neko neovlašćeno, postavljen između dva validna korisnika koji komuniciraju, vrši aktivno monitorisanje, prihvatanje i kontrolu komunikacije i to bez znanja ovlašćenih korinsika.

Na primer, napadač može da dogovori/uspostavi ključeve za šifrovanje sa oba ovlašćena korisnika. Svaki korisnik tada šalje šifrovane podatke napadaču koji može da dešifruje podatke.

Kada računari komuniciraju na niskim nivoima mrežnog sloja, računari mogu ne biti u mogućnosti da odrede sa kojim računarima u mreži oni u stvari razmenjuju podatke.

2.4.8 Napad kompromitacije ključa

Ključ predstavlja tajni kod ili broj koji se zahteva za šifrovanje, dešifrovanje ili validaciju zaštićenih informacija. Iako određivanje/rekonstrukcija ključa predstavlja jedan težak i računarski intenzivan process za napadača, to je moguće realizovati.

Kada napadač dođe do ključa, taj ključ se posmatra kao kompromitovan ključ. Napadač koristi kompromitovan ključ da dobije pristup zaštićenoj komunikaciji pri čemu niti pošiljalac niti primalac nisu svesni da su predmet napada.

Uz korišćenje kompromitovanog ključa, napadač može dešifrovati ili modifikovati podatke. Napadač takođe može pokušati da koristi kompromitovan ključ da izračuna dodatne ključeve koji mogu omogućiti pristup drugim zaštićenim komunikacijama.

2.4.9 Sniffer napad

Sniffer je aplikacija ili uređaj koji može da čita, monitoriše i preuzima podatke i pakete koji se razmenjuju u mreži. Ukoliko paketi paketi podataka nisu šifrovani, sniffer program može imati poptpun uvid u podatke koji su unutar paketa.

Korišćenjem sniffer programa, napadač može realizovati sledeće operacije:

Analizirati mrežu i informacije o pristupu, eventualno prouzrokujući da mreža prestane da odgovara ili postane neispravna,

Pristupiti i čitati privatnu komunikaciju.

2.4.10 Napad na aplikativnom nivou

Napad na aplikativnom nivu cilja aplikatvine servere prouzrokujući grešku u operativnom sistemu servera ili aplikacijama. To može rezultovati da napadač dobije mogućnost da preskoči normalne kontrole pristupa. Napadač koristi prednosti takve situacije, zadobijna kontrolu nad aplikacijom, sistemom ili mrežom i može sprovesti neku od sledećih operacija:

Da čita, dodaje, briše ili modifikuje podatke ili operativni sistem,

14

Da ubaci virus koji će koristiti računare i softverske aplikacije da kopira viruse kroz celu računarsku mrežu,

Da uvede sniffer program u cilju analize mreže i da dobije informacije koje će eventualno moći da se koriste da se prouzrokuje da mreža prestane da odgovara ili postane neispravna,

Da se na neuobičajen način prekine rad aplikacija ili operativnih sistema, Da se deaktiviraju druge bezbednosne kontrole da bi se omogućili budući

napadi.

U prilogu A su date dodatne informacije o potencijalnim napadima na računarske mreže i mogućim načinima odbrane, kao i detaljne informacije o pitanju antivirusne zaštite.

2.5 Tehnologije zaštite savremenih računarskih mreža

U cilju zaštite informacionih sistema i savremenih računarskih mreža od gore navedenih napada, neophodno je uspostaviti sistem bezbednosti u organizaciji u kome će se primenjivati sledeće tehnologije zaštite:

Tehnologija digitalnog potpisa bazirana na asimetričnim šifarskim sistemima, Zaštita tajnosti podataka primenom simetričnih šifarskih sistema, Infrastruktura sistema sa javnim ključevima (PKI – Public Key Infrastructure).

15

3. PRIMENA KRIPTOGRAFSKIH METODA ZAŠTITE U INFORMACIONOM SISTEMU

Kriptografski algoritmi koji se primenjuju u sistemima zaštite Internet/Intranet računarskih mreža dele se u dve velike grupe:

Simetrični kriptografski algoritmi, Asimetrični kriptografski algoritmi.

Podela je izvedena na osnovu posedovanja informacija neophodnih za šifrovanje i dešifrovanje.

3.1 Simetrični kriptografski algoritmi

Grupu simetričnih kriptografskih algoritama predstavljaju algoritmi kod kojih je ključ za šifrovanje identičan ključu za dešifrovanje, Slika 3.1. Algoritmi iz ove grupe se takođe nazivaju i algoritmi sa tajnim ključem jer je tajnost ključa koji se koristi i za šifrovanje i za dešifrovanje esencijalna za bezbednost poruka u sistemu.

Ovi sistemi predstavljaju osnovu tradicionalne kriptološke teorije i razvijaju se već veoma dugi niz godina. S obzirom da zaštita informacija težišnu primenu ima u poslovima vezanim za državne strukture (vojska, policija i diplomatija), ovi sistemi su bili isključivo tajni sistemi, namenski definisani i realizovani od strane nadležnih državnih institucija.

Slika 3.1: Simetrični kriptografski sistemi

Bezbedni kanalBezbedni kanal

Izvor Izvor ključaključa

IzvorIzvor porukeporuke

EEAA

XX XXOdredišteOdredišteDDAA

YY

KriptoanalitičarKriptoanalitičar

KK

16

Sa porastom intenziteta i primene elektronskih oblika komunikacija javila se potreba za definisanjem javnih simetričnih kriptografskih algoritama pa je u poslednjih desetak godina definisano više javnih simetričnih kriptografskih algoritama za primenu u aplikacijama u kojima za to postoji potreba.

Ovi algoritmi se uglavnom koriste u aplikacijama vezanim za sisteme poslovnih i finansijskih komunikacija. Imajući u vidu eksplozivni razvoj poslovnih i finansijskih sistema u poslednje vreme, javni simetrični kriptografski algoritmi su postali dominantni u pogledu korišćenja.

Međutim, nijedan od njih nije usvojen kao generalni standard već pomenuti sistemi uglavnom koriste odgovarajuće liste mogućih kriptografskih algoritama. Na taj način, kao parametar komunikacije, bira se i identifikator simetričnog šifarskog algoritma koji će se koristiti pri datoj transakciji.

Iako je po masovnosti komercijalna upotreba simetričnih kriptografskih algoritama daleko prevazišla upotrebu u tajnom sektoru (vezanom za državne strukture), glavni teorijski rezultati se i dalje dešavaju u oblasti tajne kriptologije i tajnih sistema. Velika većina država ima specijalizovane organizacije koje se bave dizajniranjem i analizom raznih vrsta šifarskih sistema (npr. NSA u SAD). Stepeni dostignuća u toj oblasti najčešće nisu javno poznati i nalaze se u sferi pretpostavki.

Postoje dve osnovne vrste simetričnih šifarskih sistema:

blok šifarski sistemi, sekvencijalni šifarski sistemi (stream cipher).

3.1.1 Blok šifarski sistemi

Blok šifarski sistemi procesiraju blokove nešifrovanog signala - otvorenog teksta (OT) i šifrovanog signala – šifrata (ST), obično u blokovima čija je veličina 64 bita ili više. Sekvencijalni šifarski sistemi procesiraju nizove bita, bajtova ili reči (16 ili 32 bita) OT i ST.

Ako se u toku procesa šifrovanja jedne poruke nekim blok šifarskim sistemom više puta pojavljuje isti blok otvorenog teksta (OT) rezultat će biti uvek isti blok šifrata (ST), što nije slučaj kod sekvencijalnih šifarskih sistema.

Kod sekvencijalnih šifarskih sistema verovatnoća da isti niz bita, bajtova ili reči OT pri svakom pojavljivanju u jednoj poruci proizvodi isti šifrat teži nuli ukoliko su niz za šifrovanje i otvoreni tekst nezavisni. Blok šifarski sistemi se veoma mnogo koriste u sistemima poslovnih i finansijskih transakcija, ali su njihove bezbednosne osobine dosta slabije od sekvencijalnih šifarskih sistema.

I pored toga definisan je veliki broj javnih algoritama baziranih na blok šifarskim sistemima, kao što su DES, 3-DES, RC2, IDEA, i mnogi drugi koji su našli veoma široku primenu u savremenim informacionim sistemima.

17

U 2001. godini, NIST organizacija u SAD je usvojila novi standard AES (Advanced Encryption Standard). Kao primer jednog blok šifarskog algoritma, daćemo kratak opis AES simetričnog blok kriptografskog algoritma.

3.1.1.1 DES (Data Encryption Standard)

DES je zvanično objavljen 1976. godine. Iako se danas smatra nesigurnim za većinu aplikacija zbog veoma kratkog ključa (56 bita), on predstavlja teoretsku osnovu za sve blok šifarske algoritme. Na osnovu njega su izgrađeni i njegovi naslednici koji su danas u upotrebi (AES, 3DES).

DES je simetrični blok šifarski algoritam koji za ulaz uzima string fiksne dužine i serijom komplikovanih transformacija ga transformiše u šifrovani tekst iste dužine. Kod DES-a veličina bloka je 64 bita.

Pošto spada u simetrične algoritme, dekripcija se može izvršiti samo uz poznavanje ključa kojim je izvršeno enkritpovanje. Ključ se sastoji od 64 bita, ali algoritam koristi samo njih 56. Preostalih 8 se koristi samo za provjeru parnosti i zatim se odbacuju.

Struktura algoritma

Sastoji se od 16 identičnih faza, koje se nazivaju rundama, slika 3.2. Osim njih postoje i inicijalna i završna permutacija, koje su inverzne operacije. Međutim, one nemaju kriptografski značaj.

Pre početka glavnih rundi blok se se dijeli na dve 32-bitne polovine koje se procesiraju naizmenično. Ovo ukrštanje se naziva Feistel-ova šema. Feistel-ova struktura osigurava da su enkripcija i dekripcija vrlo slični procesi. Jedina razlika je da se potključevi primenjuju u obrnutom redosledu u dekripciji. Ostatak algoritma je identičan. Ovo uveliko olakšava implementaciju DES-a jer nema potrebe za razdvajanje enkripcionog i dekripcionog algoritma.

U svakoj od 16 rundi jedna polovina bloka prolazi kroz F funkciju koja šifruje tu polovinu pomoću odgovarajućeg potključa. Izlaz iz F funkcije se tada kombinuje sa drugom polovinom bloka pomoću XOR operacije. Zatim polovine bloka zamene mjesta prije početka sljedeće runde. Nakon završne runde polovine ne menjaju mjesta.

Feistel-ova (F) funkcija

Operiše sa 32-bitnom polovinom bloka i sastoji se od 4 faze, slika 3.3:

1. Ekspanzija – 32-bitna polovina bloka se proširuje do 48 bita koristeći ekspanzionu permutaciju, tj. dupliciranjem nekih bita.

2. Miksanje sa ključem – rezultat se kombinuje sa potključem koristeći XOR operaciju. Šesnaest 48-bitnih potključeva (po jedan za svaku rundu) se izvode iz glavnog ključa korištenjem algoritma key schedule.

3. Supstitucija – nakon miksanja sa potključem blok se dijeli u osam 6-bitnih delova pre procesiranja u S-box-ovima. Svaki od 8 S-box-ova zamenjuje šest

18

bita na ulazu sa četiri bita na izlazu pomoće nelinearne transformacije. S-box-ovi predstavljaju jezgro sigurnosti DES-a. Bez njih bi algoritam bio linearan i samim tim bi njegovo razbijanje bilo trivijalno.

4. Permutacija – 32 bita izašlih iz S-box-ova se rearanžiraju pomoću fiksne permutacije – P-box-a.

Slika 3.2: DES algoritam

19

Slika 3.3: Feistel-ova funkcija

3.1.1.2 3DES (Triple DES)

Triple DES je blok šifarski algoritam formiran korištenjem DES-a tri puta, slika 3.4.

Kad je otkriveno da 56-bitni ključ DES-a nije dovoljan da se algoritam zaštiti od brute force napada, 3DES je izabran kao jednostavan način da se proširi ključ bez potrebe prebacivanja na novi algoritam. Korištenje tri koraka je esencijalno u sprečavanju meet-in-the-middle napada koji su efektni protiv duple DES enkripcije.

Bitna je činjenica da DES nije algebarska grupa. Da jeste, 3DES konstrukcija bi bila ekvivalentna običnom DES-u i ne bi bila sigurnija.

Najjednostavnija varijanta 3DES-a ima sljedeću šemu:

DES(k3;DES(k2;DES(k1;M))),

gde je M blok poruke koja se enkriptuje, a k1, k2, i k3 su DES ključevi. Ova varijanta se popularno naziva EEE pošto su sve tri DES operacije enkripcije. Da bi se pojednostavnila interoperabilnost između DES-a i 3DES-a srednji korak se obično zamenjuje dekripcijom (EDE mod):

DES(k3;DES-1(k2;DES(k1;M))).

20

Na taj način se jedna DES enkripcija sa ključem k predstavlja kao 3DES-EDE gdje je k1 = k2 = k3 = k. Izbor dekripcije kao srednjeg koraka ne utiče na sigurnost algoritma.

Slika 3.4: 3-DES algoritam

Uopšteno, 3DES sa tri različita ključa ima dužinu ključa od 168 bita - tri DES ključa po 56 bita, ali zbog meet-in-the-middle napada efektivna dužina je samo 112 bita.

3DES lagano izlazi iz upotrebe i uveliko se zamijenjuje sa AES-om. Izuzetak je industriji elektronskog plaćanja gdje se i dalje proizvode novi 3DES standardi. Ovo garantuje da će 3DES ostati aktivan kriptografski standard još dugo vremena.

Zbog samog dizajna DES, a samim tim i 3DES, su softverski spori. Na modernim procesorima AES je oko 6 puta brži. 3DES daje nešto bolje performanse u hardverskim implementacijama, ali i tu AES daje bolje rezultate. Konačno, AES nudi veću sigurnost: veći blok i potencijalno duži ključ.

3.1.1.3 IDEA

Ovo je simetrični blok šifarski algoritam.

Činjenice:

enkriptuje blok veličine 64 bita; koristi ključ dužine 128 bita;

21

52 potključa dužine 16 bita; koristi jedan par potključeva po rundi; koristi 8 unakrsnih runda (iteracije) kod enkriptovanja; dekripcija se vrši inverznom enkripcijom.

Prednosti:

do sada je izdržao 'napade' akademske zajednice

IDEA koristi 52 potključa dužine 16 bitova i ima 8 rundi enkripcija poruke. Po dva potključa se koriste u svakoj rundi (16), zatim četiri potključa se koriste pre svake runde (32), a poslednja četiri potključa koriste se nakon zadnje runde (4) = 16+32+4=52.

Potključevi se dobijaju tako što se 128 bitni ključ razdeli u prvih 8 potključeva (K1-K8) veličine 16 bita. Zatim se sledećih 8 potključeva dobije tako što se 25 puta napravi kružni pomeraj ulevo svakog od prethodno napravljenih potključeva. Postupak se ponavlja dok se ne kreiraju svi potključevi.

Iako je generisanje ključeva pravilno, što bi ukazalo na slabost algoritma, do sada je ovaj algoritam izdržao sva nastojanja akademskih ustanova na njegovom razbijanju.

3.1.1.4 AES algoritam

Kao što je već rečeno, u toku 2001. godine, NIST (National Institute of Standards and Technology) organizacija u SAD je objavila standard za simetrične kriptografske algoritme AES (Advanced Encryption Standard) koji je trebalo da zameni prethodni standard DES (Data Encryption Standard).

Nakon duge selekcione procedure, za AES algoritam izabran je Rijndael algoritam koga su realizovali Belgijski istraživači: Joan Daemen i Vincent Rijmen. Rijndael predstavlja blok šifarski algoritam koji podržava promenljivu dužinu bloka informacije (128, 192 i 256 bita) kao i promenljivu dužinu ključa (128, 192 i 256 bita).

Naime, poruke šifrovane DES algoritmom su se, zbog nedostataka u samom algoritmu (bezbedonosni nedostaci u supstitucionim s-tabelama), male dužine ključa (56-bita) i povećane procesne moći računara, mogle dešifrovati za samo par časova. Nakon selekcione procedure, za realizaciju AES standarda izabran je Rijndael algoritam koga su realizovali belgijski matečatičari: Joan Daemen i Vincent Rijmen.

Rijndael je blok šifarski algoritam koji podržava promenljivu dužinu bloka otvorenog teksta (128, 192 i 256 bita) kao i promenljivu dužinu ključa (128, 192 i 256 bita). Rijndael algoritam je u odnosu na konkuretske algoritme (MARS, RC6, Serpent, Twofish) bio brži i zahtevao je manje operativne memorije u procesu šifrovanja i dešifrovanja poruka. Rijndael algoritam sa 128-bitnom dužinom ključa je brži za oko 2.5 puta u odnosu na 3-DES algoritam.

AES algoritam realizuje operacije šifrovanja i dešifrovanja bloka podataka u promenljivom broju ciklusa. Broj ciklusa zavisi od veličine ključa i iznosi 10/12/14 za

22

veličinu ključa 128/192/256 bita, respektivno. Pre početka šifrovanja ili dešifrovanja vrši se ekspanzija ključa.

Realizacija šifrovanja u AES algoritmu

U realizaciji šifarske transformacije bloka podataka otvorenog teksta se izvršavaju četiri različita tipa funkcija koje se primenjuju nad elementima matrice međurezultata dimenzija 44 bajta:

nelinearna zamena bajtova pomoću supstitucione tabele (funkcija ByteSub), promena mesta bajtova unutar istog reda (funkcija ShiftRow), transformacija bajtova unutar iste kolone (funkcija MixColumns), sabiranje po modulu dva sa odgovarajućem delom ključa (funkcija

AddRoundKey).

U poslednjem ciklusu šifrovanja se ne obavlja transformacija bajtova unutar iste kolone (funkcija MixColumns).

U Rijndael algoritmu sve operacije sabiranja i množenja se vrše nad elementima konačnog polja (pored konačnih polja od r-elemenata (r-prost broj) postoje i konačna polja od q=rm elemenata, gde je m prirodan broj; navedena konačna polja se nazivaju i polja Galoa (Galois Field) u oznaci GF(rm), u čast francuskog matematičara Galoa (E. Galois)) od 256 elemenata (u oznaci GF(28) ):

pri sabiranju bajtova primenjuju se bitska operacija sabiranja po modulu dva, rezultat množenja dve vrednosti je proizvod po modulu vrednosti nerazloživog

polinoma (polinom r(x) n-tog stepena je nesvodljiv ako nije deljiv ni sa jednim polinomom stepena m gde je 0 < m < n).

c(x)=a(x)*b(x) mod m(x) (3.1.1.1)

gde je vrednost nerazloživog polinoma:

m(x)=x8+x4+x3+x+1 (3.1.1.2)

Svaki elemenat konačnog polja, a(x), ima jednoznačnu inverznu vrednost, ainv(x), koja zadovoljava uslov:

a(x)*ainv(x) mod m(x)=1 (3.1.1.3)

Da bi se ubrzao proces množenja u skupu od 256 elemenata konačnog polja formiraju se logaritamska i antilogaritamska tabela. Vrednost svakog elementa konačnog polja p može da se predstavi u obliku stepena prostog broja.

U Rijndael algoritmu za kreiranje logaritamske i antilogaritamske tabele koristi se prost broj {03}. U logaritamskoj tabeli za svaki elemenat konačnog polja x postoji odgovarajuća vrednost L koja zadovoljava uslov {x}={03}L. U antilogaritamskoj tabeli za svaki elemenat konačnog polja x postoji odgovarajuća vrednost E koja zadovoljava uslov {E}={03}x.

23

U procesu množenja dva elementa konačnog polja a i b, pomoću logaritamske tabele se odrede koeficijenti i takvi da je a={03} i b= {03}. Množenjem vrednosti a i b dobija se vrednost ab= {03}+. Traženi proizvod se dobija kada se iz antilogaritamske tabele iz ulaza x= + odredi vrednost E = ab.

Logaritamska i antilogaritamska tabela se takođe mogu koristiti za pronalaženje inverznog elementa. Naime, iz logaritamske tabele se za dati elemenat a, odredi vrednost , takva da zadovoljava uslov a= {03}. Inverzna vrednost E=a-1, date veličine, se dobija kada se iz antilogaritamske tabele iz ulaza x=255- , pročita vrednost E.

U procesu šifrovanja se realizuju sledeće funkcije:

1. Funkcija ByteSub vrši nelinearnu transformaciju bajta ulazne poruke pomoću supstitucione s-tabele (tkz. S-box tabele). Pri kreiranju supstitucione s-tabele, vrednost ulaza x (x=0…255) se dobija u dva koraka:

određivanje inverzne vrednosti ulazne veličine pomoću logaritamske i antilogaritamske tabele, prema prethodno opisanom mehanizmu.

vrednost datog ulaza supstitucione s-tabele se dobija određivanjem vrednosti svakog bita i unutar bajta (0 i 8):

, (3.1.1.4)

gde je: c={63h},

Navedeni postupak se može prikazati i u matričnom obliku:

(3.1.1.5)

24

Nakon kreiranja s-tabele vrši se nelinearna transformacija ulazne poruke, Slika 3.5, koja je upisana u matrici dimenzija 44 bajta, tako što se svaki bajt ulazne poruke zameni sa vrednošću iz odgovarajućeg ulaza iz s-tabele.

a0, 0 a0, 1 a0, 2 a0, 3 b0, 0 b0, 1 b0, 2 b0, 3

a1, 0 a1, 1 a1, 3 B1, 0 b1, 1 b1, 3

a2, 0 a2, 1 a2, 2 a2, 3 B2, 0 b2, 1 b2, 2 b2, 3

a3, 0 a3, 1 a3, 2 a3, 3 B3, 0 b3, 1 b3, 2 b3, 3

Slika 3.5: Grafički prikaz nelinearne transformacije poruke pomoću s-tabele

2. Funkcija ShiftRows obavlja operaciju nad elementima u redovima matrice podataka dobijene nakon nelinearne transformacije pomoću s-tabele. Pravilo po kome se vrši promena mesta bajta unutar istog reda matrice je prikazano sledećim izrazom:

dr,c = br,[c+h (r,Nc)] mod Nc (3.1.1.6)

gde je za AES usvojena varijanta Rijndael algoritma : Nc=4, 0 r 4 i h(r,Nc )=h(r). Rotacija bajtova unutar istog reda matrice međurezultata je prikazana na Slici 3.6.

Slika 3.6: Grafički prikaz promene mesta bajtova u redu matrice međurezultata

3. Funkcija MixColumns vrši transformaciju elemenata kolone matrice međurezultata nakon realizacije funkcije ShiftRows. Elementi kolone matrice se posmatraju kao koeficijenti polinoma, pri čemu svaki koeficijent predstavlja elemenat konačnog polja

25

s-box

ai, j bi, j

GF(28). Zatim se, tako dobijeni polinomi, množe sa konstantnim polinomom n(x)='03'x3 + '01'x2 + '01'x + '02' po modulu x4 +1. Navedeno modularno množenje se može prikazati i u matričnom obliku:

(3.1.1.7)

gde je: 0c4.

Način na koji se vrši transformacija kolona matrice je prikazana na Slici 3.7.

d0, 0 D0, 1 a0, 2 d0, 3 e0, 0 e0, 1 b0, 2 e0, 3

d1, 0 D1, 1 d1, 3 e1, 0 e1, 1 e1, 3

d2, 0 D2, 1 a2, 2 d2, 3 e2, 0 e2, 1 b2, 2 e2, 3

d3, 0 d3, 1 a3, 2 d3, 3 e3, 0 e3, 1 b3, 2 e3, 3

Slika 3.7: Grafički prikaz promene mesta bajtova u kolonama matrice međurezultata

4. Funkcija AddRoundKey vrši operaciju eksluzivne disjunkcije nad elemenata matrice, dobijene nakon izvršenja funkcije MixColumn, i matricom odgovarajućeg dela ekspandovanog ključa, Slika 3.8.

e0,

0

e0,

1

e0,

2

e0,

3

k0, 0 k0, 1 k0, 2 k0, 3 r0, 0 r0, 1 r0, 2 r0, 3

e1,

0

e1,

1

e1,

2

e1,

3 k1, 0 k1, 1 k1, 2 k1, 3

=r1, 0 r1, 1 r1, 2 r1, 3

e2,

0

e2,

1

e2,

2

e2,

3k2, 0 k2, 1 k2, 2 k2, 3 r2, 0 r2, 1 r2, 2 r2, 3

e3,

0

e3,

1

e3,

2

e3,

3k3, 0 k3, 1 k3, 2 k3, 3 r3, 0 r3, 1 r3, 2 r3, 3

Slika 3.8: Grafički prikaz funkcije AddRoundKey

Optimizacija realizacije šifrovanja u AES algoritmu

26

d0, j

d1, j

d2, j

d3, j

e0, j

e1, j

e2, j

e3, j

c(x)

Tranformacija kolone ulazne matrice kroz jedan ceo ciklus šifrovanja se može matematički prikazati sledećim nizom izraza:

(funkcija AddRoundKey) (3.1.1.8)

(funkcija MixColumns) (3.1.1.9)

(funkcija ShiftRows) (3.1.1.10)

(funkcija ByteSub) (3.1.1.11)

Sumarno se dobija sledeći izraz koji opisuje proces transformacije j-te kolone ulaznog podataka u jednom ciklusu šifrovanja.

(3.1.1.12)

Množenje matrica može se prikazati i sledećim izrazom:

(3.1.1.13)

Činilac množenja s[ ] se dobija određivanjem vrednosti ulaza supstitucione s-tabele. Da bi se ubrzao proces množenja mogu se kreirati 4 tabele:

27

(3.1.1.14)

Svaka od četiri tabele sadrži 256 četvorobajtnih reči, tako da je ukupan memorijski prostor potreban za njihovo skladištenje 4KB. Primenom datih tabela, transformacija j-te kolone ulaznog podatka u jednom ciklusu šifrovanja se može predstaviti izrazom:

(3.1.1.15)

Definišimo funkciju RowByte(W) koja vrši rotaciju svakog bajta ulazne reči za jedno mesto udesno W=b3b2b1b0 (bi , i-ti bajt reči), tako da je izlazna reč oblika W=b2b1b0b3.

Veza između tabela i se može prikazati sledećom relacijom:

(3.1.1.16)

Transformacija j-te kolone matrice ulaznog podatka u jednom ciklusu šifrovanja se može predstaviti sledećim izrazom:

(3.1.1.1

7)

Primenom ove formule umesto četiri tabele sa ukupno 1024 četvorobajtnih reči (4KB) potrebno je kreirati jednu tabelu od 256 reči (1KB), ali ciklus šifrovanja traje neznatno duže, za tri dodatne operacije rotacije bajta unutar reči (funkcija RotByte).

Realizacija dešifrovanja u AES algoritmu

Proces dešifrovanja poruke je sličan procesu šifrovanja. U procesu dešifrovanja se primenjuju četiri različita tipa funkcija nad elementima matrice međurezultata dimenzija 44 bajta:

nelinearna zamena bajtova pomoću inverzne supstitucione tabele (funkcija InvByteSub),

promena mesta bajtova unutar istog reda (funkcija InvShiftRow), transformacija bajtova unutar iste kolone (funkcija InvMixColumns), sabiranje po modulu dva sa odgovarajućim delom ključa (funkcija

AddRoundKey).

U poslednjem ciklusu dešifrovanja se ne obavlja transformacija bajtova unutar iste kolone (funkcija InvMixColumns).

U procesu dešifrovanja se realizuju sledeće funkcije:

28

1. Nelinearna transformacija ulazne matrice dimenzija 44 bajta se vrši pomoću inverzne supstitucione s-tabele. U procesu kreiranja inverzne supstitucione s-tabele vrednost za svaki od ulaza x (x=0..255) se određuje u dva koraka:

transformacija vrednosti ulaznog bajta x se realizuje određivanjem vrednosti svakog bita i unutar bajta (0 i 8):

(3.1.1.18)gde je: d={05h},

vrednost ulaza x u inverznoj supstitucionoj tabeli se dobija kao rezultat

inverzne transformacije prethodno dobijene vrednosti b= .

2. Funkcija InvShiftRows obavlja operacije nad elementima u redovima matrice međurezultata, dobijenom nakon prethodno opisane transformacije. Pravilo po kome se vrši promena mestu bajta unutar istog reda matrice se može prikazati sledećim izrazom:

d r, [c+h (r,Nc)] mod Nc br,c (3.1.1.19)

gde je za AES usvojena varijanta Rijndael algoritma : Nc=4, 0 r 4 i h(r,Nc )=h(r). Rotacija bajtova unutar istog reda matrice međurezultata je prikazana na Slici 3.9.

3. Funkcija InvMixColumns vrši transformaciju elemenata kolone matrice dobijene nakon izvršenja funkcije InvShiftRows. Elementi kolone matrice se posmatraju kao koeficijenti polinoma, pri čemu svaki koeficijent predstavlja elemenat konačnog polja GF(28). Zatim se, tako dobijeni polinomi, množe sa konstantnim polinomom p(x)='0B'x3 + '0D'x2 + '09'x + '0E' po modulu x4 +1. Navedeno modularno množenje se može prikazati u matričnom obliku:

(3.1.1.20)

gde je: 0c4.

29

Slika 3.9: Grafički prikaz promene mesta bajtova u redu matrice međurezultata

4. Funkcija AddRoundKey vrši sabiranje po modulu dva elementa matrice, dobijena nakon izvršenja funkcije InvMixColumns, sa odgovarajućim delom ključa za dešifrovanje:

(3.1.1.21)

3.1.2 Kriptografski modovi blok šifarskih algoritama

Kriptografski mod predstavlja način upotrebe bazičnog šifarskog algoritma i najčešće je kombinacija neke vrste povratne petlje i određenih jednostavnih operacija. Operacije koje se primenjuju nad algoritmom su uglavnom jednostavne jer je bezbednost određena bazičnim šifarskim algoritmom a ne kriptografskim modom.

Blok šifarski sistemi se primenjuju u različitim kriptografskim modovima, kao što su:

ECB (Electronic CodeBook mode), CBC (Cipher Block Chaining), CFB (Cipher FeedBack) i OFB (Output FeedBack).

3.1.2.1 Mod elektronske kodne knjige (ECB – Electronic CodeBook).

ECB mod predstavlja najprirodniji i najlakši način primene blok šifarskih sistema - blok OT se šifruje u blok ST, Slika 3.10. Svaki OT blok se šifruje nezavisno. Sa kriptološke strane, ECB mod je najproblematičniji.

Naime, ako kriptoanalitičar poseduje parove OT i ST za nekoliko poruka, moguće je da tokom konverzacije dve strane formira pravu kodnu knjigu, skup odgovarajućih parova ST i OT, i bez poznavanja ključa.

U većini realnih situacija: fragmenti poruka teže ponavljanju, različite poruke imaju zajedničke delove, određeni računarski generisane poruke (kao e-mail) imaju

30

regularnu strukturu, poruke mogu biti veoma redundantne i imati veoma duge nizove nula i pauze. Ovi problemi su najistaknutiji na početku i na kraju poruke, gde se u dobro definisanim zaglavljima i futnotama mogu nalaziti informacije o pošiljaocu, primaocu, datumu, itd.

Formiranje reprezentativne kodne knjige ne samo da omogućava trećoj strani pristup informacijama već joj dodatno omogućava da može modifikovati i ponavljati šifrovane poruke (tzv. block replay problem) bez poznavanja ključa i algoritma, u slučaju da ima mogućnost presretanja šifrovanih poruka između dve strane. Ovi problemi su inicirali uspostavljanje zavisnosti između susednih blokova šifrata kroz definisanje novih kriptografskih modova blok šifarskih sistema.

Slika 3.10: Grafički prikaz rada u ECB modu

3.1.2.2 Mod ulančavanja blokova (CBC – Cipher Block Chaining)

Mehanizam ulančavanja povezuje blokove šifrata tako što se rezultat šifrovanja prethodnih blokova koristi pri šifrovanju tekućeg bloka.

Drugim rečima, svaki blok se koristi za modifikaciju šifrovanja sledećeg bloka tako da svaki blok ST zavisi ne samo od tekućeg bloka OT već i od svih prethodnih blokova OT. Načini na koje se to može ostvariti su raznovrsni.

31

Slika 3.11: Grafički prikaz rada u CBC modu

U CBC modu, Slika 3.11, taj uticaj se realizuje tako što se izvršava operacija “ekskluzivno ili” (XOR) između OT i neposredno prethodnog bloka ST, a zatim se tako dobijeni blok podataka šifruje. Preciznije:

1. U povratni registar se smesti inicijalna vrednost.2. Blok otvorenog teksta i sadržaj povratnog registra se spregnu operacijom

ekskluzivne disjunkcije i tako dobijeni blok se transformiše šifarskom transformacijom E čime se formira blok šifrata C.

3. U povratni registar se smesti C i proces se ponavlja od koraka 2 sve dok ima blokova za šifrovanje.

Na taj način, rezultat šifrovanja svakog bloka zavisi od svih prethodnih blokova.

Proces dešifrovanja sledi direktno i odvija se na sledeći način:

1. U povratni registar se smesti inicijalna vrednost.2. Blok šifrata C dešifruje se primenom transformacije , tako dobijeni blok

teksta i sadržaj povratnog registra se spregnu operacijom ekskluzivne disjunkcije i tako se dobije blok otvorenog teksta.

3. U povratni registar se smesti C i proces se ponavlja od koraka 2 sve dok ima blokova za dešifrovanje.

Matematički, proces šifrovanja i dešifrovanja može se prikazati na sledeći način, relacijama (3.1.1.22) i (3.1.1.23), respektivno:

(3.1.1.22) (3.1.1.23)

CBC mod prouzrokuje da se identični blokovi OT šifruju u različite ST blokove samo ako su neki prethodni blokovi različiti. Dve kompletno identične poruke će se ipak šifrovati u iste ST.

Ovaj problem se može rešiti tako što se za prvi blok podataka uzima neka slučajna veličina. Ovaj blok slučajnih podataka se naziva inicijalizacioni vektor (IV). Kada

32

primalac dešifruje ovaj blok, on prosto smešta IV u povratni registar. Tekuće vreme sistema (timestamp) često predstavlja dobro rešenje za IV. Primenom IV, identične poruke se šifruju u različite ST.

Primenom IV, eliminisana je mogućnost primene block replay metode. Štaviše, IV ne mora da bude tajni podatak i može se preneti otvoreno, zajedno sa ST, uz upotrebu nekog od mehanizama zaštite integriteta.

Međutim, možda ne tako očigledno kao u ECB modu, i u CBC modu postoje određeni bezbednosni problemi koji se mogu manifestovati kao određena mogućnost da kriptoanalitičar dodaje određene blokove na krajeve poruka koje se razmenjuju i u činjenici da veoma duge poruke i dalje nisu imune na pojavljivanje određenih identičnih oblika iako se vrši proces ulančavanja.

3.1.2.3 Mod povratnog šifrovanja (CFB - Cipher-Feedback Mode)

U nekim aplikacijama se javlja potreba da se delovi otvorenog teksta šifruju i prenose u u jedinicama veličine r bita (r < n –veličina bloka), što u CBC modu nije moguće. Ovim modom se prevazilazi osnovni problem CBC moda - da šifrovanje i prenos podataka ne mogu početi sve dok se ne primi kompletan blok podataka. U CFB modu, podaci se šifruju u manjim jedinicama od aktuelne veličine bloka i ovaj mod se označava kao r-bitni CFB mod, gde je r manje ili jednako od veličine bloka osnovnog blok šifarskog sistema.

Proces šifrovanja se odvija na sledeći način, Slika 3.12:

1. Otvoreni tekst se podeli u blokove veličine r bita, formira se inicijalni vektor veličine n bita i smesti u povratni registar. Odabere se K, ključ za šifarsku transformaciju.

2. Formira se izlazni blok, O, tako što se izvrši šifarska transformacija ključem K tekućeg sadržaja povratnog registra.

3. Blok šifrata se formira tako što se operacija ekskluzivne disjunkcije izvrši nad tekućim blokom otvorenog teksta i r bita najmanje težine bloka O.

4. Sadržaj povratnog registra se pomera za r bita u levo i na mesto r bita najmanje težine se smešta formirani blok šifrata.

Koraci 2-4 se ponavljaju sve dok ima blokova otvorenog teksta. Dešifrovanje se odvija na sličan način.

1. Formira se inicijalni vektor veličine n bita i smesti u povratni registar. Odabere se K, ključ za šifarsku transformaciju.

2. Formira se izlazni blok, O, tako što se ivrši šifarska transformacija ključem K tekućeg sadržaja povratnog registra.

3. Blok otvorenog teksta se formira tako što se operacija ekskluzivne disjunkcije izvrši nad tekućim blokom šifrata i r bita najmanje težine bloka O.

4. Sadržaj povratnog registra se pomera za r bita ulevo i na mesto r bita najmanje težine se smešta tekući blok šifrata.

Inicijalizacioni vektor ima istu ulogu kao i u CBC modu, da spreči pojavljivanje istih šifrata u slučaju istih poruka šifrovanih jednakim ključevima. Iz opisa načina

33

transformacije jasno je da je za ispravno dešifrovanje neophodno da je prethodnih

blokova šifrata ispravno dešifrovano.

S obzirom da se i u procesu šifrovanja i u procesu dešifrovanja koristi ista šifarska transformacija, to algoritam kojim se formira blok O ne može biti iz klase algoritama sa javnim ključem.

Slika 3.12: Grafički prikaz rada u CFB modu

3.1.2.4 Izlazni povratni mod (OFB – Output Feedback Mode)

Ovaj mod rada predstavlja spoj dobrih osobina ECB i CFB modova rada, sprečava propagaciju greške i ima poboljšane bezbednosne karakteristike. OFB mod rada takođe omogućava prenos podataka u jedinicama manjim od veličine bloka.

Transformacija otvorenog teksta se odvija na sledeći način, slika 3.13:

1. Otvoreni tekst se podeli u blokove veličine r bita, formira se inicijalni vektor veličine n bita i smesti u povratni registar. Odabere se K, ključ za šifarsku transformaciju.

2. Formira se izlazni blok, O, tako što se izvrši šifarska transformacija ključem K tekućeg sadržaja povratnog registra .

3. Blok šifrata se formira tako što se operacija ekskluzivne disjunkcije izvrši nad tekućim blokom otvorenog teksta i r bita najmanje težine bloka O.

4. Blok O postaje sadržaj povratnog registra.

34

Koraci 2-4 se ponavljaju sve dok ima blokova otvorenog teksta. Dešifrovanje se odvija na sličan način.

Formira se inicijalni vektor veličine n bita i smesti u povratni registar. Odabere se K, ključ za šifarsku transformaciju.

Formira se izlazni blok, O, tako što se ivrši šifarska transformacija ključem K tekućeg sadržaja povratnog registra.

Blok otvorenog teksta se formira tako što se operacija ekskluzivne disjunkcije izvrši nad tekućim blokom šifrata i r bita najmanje težine bloka O.

Sadržaj povratnog registra zameni se formiranim blokom O.

Koraci 2-4 se izvršavaju sve dok ima blokova za dešifrovanje.

Prethodno izloženi opis je prema standardu ISO 10116. Postoje takođe i druge varijacije na ovu temu (npr. FIPS-81) ali se ova izložena verzija smatra, za sada, najbezbednijom.

Slika 3.13: Grafički prikaz rada u OFB modu

Pored toga što se radom u ovom modu onemogućava propagacija greške, dobra osobina ovog moda rada je i to što se veći deo izračunavanja može izvršiti off-line, nakon čega se vrši samo XOR-ovanje izlaza algoritma i jedinica OT.

Detaljna analiza OFB moda rada je pokazala da ovaj mod rada treba koristiti samo u slučaju da je r jednako dužini bloka n. Drugim rečima, 64-bitne blok šifarske algoritme treba koristiti u 64-bitnom OFB modu.

3.1.2.5 Izbor odgovarajućeg moda rada blok šifarskog sistema

Jedan od četiri bazična moda rada – ECB, CBC, OFB ili CFB pogodan je za skoro svaku aplikaciju. Koji će se mod koristiti zavisi od korisnikovih specifičnih zahteva. Ako su jednostavnost i brzina najbitniji, ECB mod je pravi izbor, kao najlakši i najbrži mod za korišćenje blok šifarskih sistema. Međutim, ECB mod je najslabiji sa

35

bezbednosne tačke gledišta i ne preporučuje se za šifrovanje poruka. Sa druge strane, ECB mod je veoma dobar za šifrovanje kratkih slučajnih podataka, kao što su na primer ključevi, jer se pri tome ne iskazuju prepoznate slabosti ECB moda.

Za šifrovanje normalnog OT treba koristiti CBC, CFB ili OFB mod. CBC je generalno najbolji mod za šifrovanje datoteka. Takođe, ako je aplikacija softverski bazirana, CBC je skoro uvek najbolje rešenje. Sa druge strane, CFB mod (specijalno 8-bitni CFB mod) je generalno mod koji treba birati za šifrovanje nizova karaktera u kojima se svaki karakter tretira individualno, kao na primer u vezi između terminala i host računara. OFB mod rada se najčešće koristi u sinhronim sistemima visokih brzina gde se ne toleriše propagacija grešaka.

3.1.3 Sekvencijalni šifarski sistemi

Sekvencijalni šifarski sistemi predstavljaju vrlo važnu klasu šifarskih algoritama. Oni transformišu pojedinačne karaktere (najčešće bite i bajtove otvorenog teksta) koristeći transformaciju koja pored ključa zavisi na određeni način i od vremenskog trenutka u kojem se primenjuje, za razliku od blokovskih šifarskih sistema koji transformišu blokove otvorenog teksta nepromenljivom transformacijom tokom šifrovanja cele poruke.

Kao i obično, u praksi, ova podela nije tako rigidna, postoje transformacije koje se mogu po svojim osobinama svrstati i u jedne i u druge. Tako na primer CFB i OFB modovi blokovskih šifarskih sistema imaju neke karakteristike sekvencijalnih šifarskih sistema. Sa druge strane sekvencijalni šifarski sistemi se mogu smatrati blokovskim kod kojih je dužina bloka jedan karakter (bit, bajt ili mašinska reč (word) dužine 16, 24 ili 32 bita).

Generalno govoreći sekvencijalni šifarski sistem sastoji se od generatora niza ključa (keystream generator) koji generiše niz jedinica ključa k1, k2, …, ki, … i funkcije f koja se primenjuje na niz jedinica OT: p1, p2, …, pi, proizvodeći niz jedinica ST: c1, c2, …, ci, na bazi sledeće relacije:

(3.1.3.1)

Na drugom kraju komunikacije, primenom inverzne funkcije na parove jedinica šifrata i jedinica ključa dobijaju se jedinice poslatog OT. Naime:

(3.1.3.2)

jer je funkcija f tako odabrana da je

(3.1.3.3)

Zbog jednostavnosti obrade za f se najčešće koristi ekskluzivna disjunkcija (XOR operacija). Bezbednost nizovnog šifarskog sistema primarno je određena kriptološkim kvalitetom generatora niza ključa.

36

3.1.3.1 Klasifikacija sekvencijalnih šifarskih sistema

Klasifikacija sekvencijalnih šifarskih sistema se može vršiti po različitim kriterijumima, po načinu na koji se generiše niz ključa, po tipu primenjenog algoritma (sa javnim ili tajnim ključem), itd. Osnovna je podela po načinu na koji se generiše niz ključa. U tom smislu postoje sistemi sa slučajnim i pseudo-slučajnim nizom.

Sistemi sa slučajnim nizom – kod ovih sistema niz ključa se generiše na slučajan način, tako što se jedinice ključa generišu nezavisno i slučajno. Ako se prema prethodnim oznakama za funkciju f uzme ekskluzivna disjunkcija, tada se dobija takozvani “one time pad” sistem za koji se može teorijski pokazati da je apsolutno siguran, tj. da šifrat ne nosi nikakvu informaciju o otvorenom tekstu.

Sa druge strane taj sistem je i optimalan u smislu da koristi najkraći ključ kojim se postiže apsolutna sigurnost. Naime, Šenon je u svojim radovima pokazao da je neophodan uslov za apsolutnu bezbednost da entropija ključa bude veća ili jednaka od entropije poruke. Kako je kod ovog sistema entropija ključa jednaka dužini poruke, čija entropija ne može biti veća od njene dužine, to sledi da je ovo zbilja optimalan sistem u navedenom smislu.

Nedostatak ovog sistema je u činjenici da oba učesnika komunikacije moraju imati isti niz ključa koji mora biti tajan, što proizvodi, ponekad nepremostive, probleme u upravljanju ključevima jer treba obezbediti i dostaviti stranama u komunikaciji velike količine ključeva kako bi mogle nesmetano da komuniciraju.

Sistemi sa pseudoslučajnim nizom – kod ovih sistema se na osnovu inicijalne vrednosti i dogovorenog algoritma generiše niz jedinica ključa. Posedovanjem identične inicijalne vrednosti, obe strane u komunikaciji su u stanju da produkuju isti niz jedinica ključa i da ostvare bezbednu komunikaciju. Kako je generisanje jedinica ključa determinističko, niz ključa je u potpunosti definisan sa:

Početnim unutrašnjim stanjem – inicijalna vrednost kojom se definiše početno stanje generatora ključa,

Funkcijom narednog stanja – koja na bazi prethodnog unutrašnjeg stanja generiše novo unutrašnje stanje,

Izlaznom funkcijom – koja na osnovu unutrašnjeg stanja generiše izlaznu jedinicu ključa.

Posledica činjenice da je niz ključa deterministički je da je on nužno periodičan. Iako su ovo na izgled činjenice koje ovakve sisteme značajno dezavuišu, stvari ne stoje tako loše, i ti problemi se mogu sasvim uspešno prevazići. Naime, bezbednost ovakvih sistema direktno zavisi od veličine inicijalnih podataka i kvaliteta dogovorenog algoritma. Dobro dizajnirani algoritmi ovog tipa pružaju zaštitu koja je po kvalitetu vrlo blizu apsolutno bezbednim sistemima.

Sekvencijalni šifarski sistemi sa pseudoslučajnim nizom se dele u dve velike grupe:

Sinhroni sekvencijalni šifarski sistemi Samosinhronišući sekvencijalni šifarski sistemi

37

Sinhroni sekvencijalni šifarski sistemi su oni kod kojih se niz ključa generiše nezavisno od otvorenog teksta i šifrata, slika 3.14.

Proces šifrovanja se može opisati sledećim skupom jednačina:

(3.1.3.4)

Gde se početno stanje, ơ0, određuje na osnovu inicijalne vrednosti k, f je funkcija sledećeg stanja, g je funkcija koja produkuje niz ključa a h izlazna funkcija koja od otvorenog teksta i niza ključa formira šifrat .

Kod ovih sistema niz ključa se generiše nezavisno od niza jedinica poruke. Na obe strane u komunikaciji se istovremeno generišu nizovi ključa. Učesnici u komunikaciji su u stanju da razmenjuju poruke sve dotle dok su algoritmi za generisanje niza ključa sinhronizovani među sobom.

Ukoliko se desi gubitak ili umetanje jednog ili više jedinica tokom prenosa ST, dešifrovanje će biti nekorektno. U slučaju takvog događaja, generatori niza ključa na predajnoj i prijemnoj strani moraju se resinhronizovati, pre nego što nastave komunikaciju.

Sa druge strane, u ovim sitemima se ne propagira greška i svaki pogrešan bit u prenosu ostaće i u dešifrovanom obliku pogrešan, ali ta greška neće uticati ni na prethodne ni na buduće bite za prenos.

Prethodno navedena osobina može poslužiti aktivnom protivniku kao osnova za različite vrste pokušaja kompromitovanja ovakvog sistema.

Slika 3.14: Grafički prikaz rada sinhronih sekvencijalnih šifarskih sistema

Samosinhronišući asinhroni sistemi su oni kod kojih je niz ključa dobija u funkciji inicijalne vrednosti, dogovorenog algoritma i izvesnog konstantnog broja prethodnih jedinica šifrata, Slika 3.15. Proces šifrovanja se opisuje sledećim skupom jednačina:

38

(3.1.3.5)

Gde je inicijalno stanje, početno stanje određuje se na osnovu inicijalne vrednosti k, f je funkcija sledećeg stanja, g je funkcija koja produkuje niz ključa a h izlazna funkcija koja od otvorenog teksta i niza ključa formira šifrat

.

Kod ovih sistema moguće je ostvariti samosinhronizaciju zato što dešifrovanje zavisi samo od fiksnog broja prethodnih jedinica šifrata, tako da je moguće sinhronizaciju ponovo uspostaviti vraćanjem na određeni broj dobro primljenih znakova šifrata.

Slika 3.15: Grafički prikaz rada samosinhronišućih sistema sa pseudo-slučajnim nizom

Kod ovih sistema propagacija greške je takođe ograničena na fiksiran broj uzastopnih jedinica a posle toga se preostale jedinice šifrata mogu ispravno dešifrovati.

Sekvencijalni šifarski sistemi imaju veliku ulogu u zaštiti masovnih podataka zato što obezbeđuju kvalitetnu zaštitu a pri realizaciji obezbeđuju veliku brzinu obrade.

Teorija analize i sinteze sekvencijalnih šifarskih sistema sa pseudoslučajnim nizom je veoma razvijena i u glavnom jedna podstiče drugu na razvoj.

3.1.3.2 RC4 algoritam

39

RC4 je najkorišteniji sekvencijalni algoritam i koristi se u popularnim protokolima kao što su SSL i WEP. Izvrstan je zbog jednostavnosti i brzine, ali je sa druge strane ranjiv na napade kada početak izlaznog niza nije odbačen ili kada se jedan ključ koristi dvaput.

RC4 je jednostavan za opis. Ima 256 S-box-ova. Ulazi su permutacija brojeva od 0 do 255, a permutacija je funkcija ključa promenljive dužine. Ima dva brojača, i i j, postavljena na 0. Za generisanje slučajnog bajta koristi se sledeći algoritam:

i = (i + 1) mod 256j = (j + Si) mod 256zamijeni Si i Sj

t = (Si + Sj) mod 256K = St.

Bajt K se XOR-uje sa otvorenim tekstom da bi se dobio šifrat ili XOR-uje sa šifratom da bi se dobio otvoreni tekst. Enkripcija je brza (oko 10 puta brža nego kod DES-a). Inicijalizacija S-box-ova je takođe lagana.

Prvo se popunjavaju linearno: S0 = 0, S1 = 1,..., S255 = 255.

Zatim se generiše drugi 256-bajtni niz ključa, ponavljajući ključ koliko je potrebno da se popuni cijeli niz: K0, K1,..., K255. Indeks j se postavlja na 0. Tada se izvršava sljedeća petlja:

for i = 0:255j = (j + Si + Ki) mod 256zameni Si i Sj.

Algoritam je imun na diferencijalnu i linearnu kriptoanalizu i krajnje je nelinearan. Indeks i osigurava da se svaki element menja, a indeks j da se elementi menjaju slučajno.

3.1.4 Komparativna analiza blok i sekvencijalnih šifarskih sistema

Iako su blok i sekvencijalni šifarski sistemi veoma različiti, blok sistemi se mogu implementirati kao sekvencijalni sistemi i obrnuto. Razlike se najviše iskazuju u implementaciji ovih sistema. Naime, sekvencijalni šifarski sistemi koji šifruju i dešifruju svaku jedinicu OT nisu previše pogodni za softverske implementacije. Oni su pogodni za šifrovanje i dešifrovanje podataka u realnom vremenu, i to posebno ako su realizovani u hardveru.

Sa druge strane, blok šifarski sistemi su lakši za implementaciju u softveru zato što često izbegavaju vremenski zahtevne bitske manipulacije i zato što rade nad podacima u računarski podeljenim blokovima. Postoje neki specifični momenti gde šifrovanje jedinica OT može biti od interesa i u računarskim sistemima, kao na primer šifrovanje veze između tastature i procesora, ali i u tom slučaju blok koji se šifruje treba da bude najmanje širine magistrale podataka.

40

U savremenom razvoju kriptologije svedoci smo sve intenzivnijeg korišćenja kako blok tako i sekvencijalnih šifarskih sistema. Savremene aplikacije finansijskih i poslovnih transakcija su prouzrokovale eksplozivan rast primena pomenutih šifarskih sistema i to: DEA, 3-DES, RC2, IDEA, AES, itd. kao blok šifarskih sistema, i RC4, i drugih, kao sekvencijalnih šifarskih sistema.

U savremenim softverskim i hardverskim proizvodima za zaštitu finansijskih, poslovnih i državnih računarskih mreža uglavnom se podržava čitav skup najviše korišćenih blok i sekvencijalnih algoritama (de facto standardnih algoritama).

3.2 Asimetrični kriptografski algoritmi

Asimetrični kriptografski algoritmi predstavljaju jedno od najvećih dostignuća kriptologije druge polovine dvadesetog veka. Otkriveni su u procesu rešavanja problema vezanih za zaštitu tajnosti i distribuciju ključeva koji je često bio aktuelan u primenama simetričnih kriptografskh algoritama.

Naime, u asimetričnim šifarskim sistemima se koriste različiti ključevi za šifrovanje i dešifrovanje, tzv. javni i tajni ključ, tako da ključ za šifrovanje može imati svako a samo posednik ključa za dešifrovanje može dešifrovati poruku.

Međutim, visoka računarska zahtevnost ovih algoritama utiče na performanse sistema u kojima se primenjuju, tako da se ne preporučuje primena za zaštitu tajnosti informacija u sistemima sa velikim protokom informacija.

Ovo naravno ne dezavuiše automatski ove algoritme jer način na koji je uz korišćenje ovakvih algoritama moguće ostvariti funkcije integriteta, autentičnosti i neporicanja ima nesumnjivu prednost nad tradicionalnim tehnikama.

U literaturi je opisano više algoritama sa javnim ključem ali sa stanovišta kvaliteta, otpornosti na razne vrste napada, efikasnost i lakoću implementacije te rasprostranjenost, nisu svi podjednako dobri. U tom smislu se kao prirodni izbor nameće RSA algoritam koji više od dvadeset godina odoleva svim teorijskim i tehnološkim napadima.

Opis i način upotrebe ovog algoritma propisani su u standardu PKCS#1. Pored RSA algoritma moguće je koristiti i druga dva algoritma, DSA (Digital Signature Algorithm) i ECDSA (Elliptic Curve DSA), koja spadaju u standard digitalnog potpisa (NIST standard DSS (Digital Signature Standard).

3.2.1 PKCS#1 standard

PKCS#1 standard opisuje metode šifrovanja podataka korišćenjem RSA asimetričnog algoritma i najčešće se koristi za konstrukciju digitalnog koverta i digitalnog potpisa.

U slučaju digitalnog koverta, sadržaj poruke se prvo šifruje određenim simetričnim algoritmom (kao što su DES, 3-DES, RC2, RC4, IDEA, AES, ili neki namenski privatni algoritmi). Zatim se tajni ključ primenjenog simetričnog algoritma koji je

41

upotrebljen za šifrovanje date poruke šifruje RSA algoritmom upotrebom javnog ključa korisnika kome je data poruka namenjena (RSA public key operacija).

Tako šifrovan sadržaj poruke i tajni ključ kojim je ta poruka šifrovana zajedno predstavljaju digitalni koverat.

Postupak šifrovanja i dešifrovanja putem tehnologije digitalnog koverta je prikazan na slikama 3.16 i 3.17, respektivno.

Slika 3.16: Digitalna envelopa – šifrovanje

Slika 3.17: Digitalna envelopa – dešifrovanje

42

U slučaju digitalnog potpisa, Slika 3.18, sadržaj koji treba da se potpiše, poruka M, prvo se redukuje u otisak poruke (message digest), H, primenom nekog od metoda za kreiranje otiska poruke, message-digest algoritma (kao što su na primer MD5 ili SHA-1 algoritmi), a zatim se dobijeni otisak poruke šifruje primenom, na primer, RSA algoritma koristeći privatni ključ potpisnika poruke (RSA private key operacija), ključ A. Šifrovani otisak poruke predstavlja digitalni potpis date poruke, S, i postaje njen pridruženi deo.

Kada ovakva poruka stigne do primaoca kojem je namenjena izvršava se postupak verifikacije digitalnog potpisa. Ovaj postupak se sastoji od dešifrovanja otiska dobijene poruke primenom RSA algoritma uz upotrebu javnog ključa pošiljaoca poruke, ključ B. Po dešifrovanju digitalnog potpisa primalac poruke izvrši isti message digest postupak nad dobijenom porukom, M1.

Ako je dobijeni otisak poruke, H1, identičan sa dešifrovanom vrednošću otiska, verifikacija je uspela, u protivnom verifikacija je negativna.

Ukoliko je verifikacija uspela, primalac poruke je siguran u sledeće:

Autentičnost pošiljaoca – jer je uspešno dešifrovao otisak poruke primenom RSA algoritma sa javnim ključem datog pošiljaoca,

Integritet poslate poruke – ako su izračunati i dešifrovani otisci date poruke identični zaključuje se da poruka na prenosnom putu nije menjana, i

Nemogućnost da pošiljalac naknadno porekne da je tu poruku poslao jer je njegov digitalni potpis uspešno verifikovan i ukoliko je potpisnik koristio privatni ključ generisan na smart kartici.

Slika 3.18: Procedura digitalnog potpisa i verifikacije

43

Da bi dati primalac bio u mogućnosti da prima poruke od datog pošiljaoca i sprovede proces verifikacije digitalnog potpisa mora imati mogućnost pristupa javnom ključu pošiljaoca. Pristup i distribucija javnih ključeva se mogu organizovati na različite načine a najčešće se realizuju u procesu utvrđivanja identiteta putem razmene digitalnih certifikata.

PKCS#1 standardom se pored bezbednosnih mehanizama definiše i unutrašnja struktura validnih poruka čime se omogućava dodatni mehanizam verifikacije ispravnosti poruka. Naime, svaka poruka koja ima narušenu strukturu se smatra neispravnom i odbacuje se.

Treba posebno naglasiti da je trenutno aktuelan i važeći PKCS#1 standard verzije 2.1 i da su njime značajno izmenjene preporuke date u PKCS#1 standardu verzije 1.5, koje se odnose na format bloka podataka koji podleže operacijama šifrovanja i potpisivanja. Razlog za ovakve drastične promene leži u činjenici da prema verziji 1.5 pri formiranju bloka za šifrovanje postoji niz bita na početku bloka koji je uvek isti.

To se može iskoristiti da se bez poznavanja tajnih informacija, samo uz poznavanje šifrata dođe do otvorenog teksta. Ovde treba naglasiti da ovim nije kompromitovana bezbednost samog RSA algoritma već je, grubo govoreći, način njegove upotrebe bio takav da je pod određenim uslovima dolazilo do oticanja informacija.

U verziji 2.1 ovog standarda blok podataka koji se šifruje prethodno se kodira OAEP (Optimal Assymetric Encryption Padding) metodom koja ima dobre bezbednosne karakteristike tako da čak ni dva identična bloka podataka posle kodiranja ovim metodom ne daju isti rezultat.

Time su izbegnute slabosti detektovane u verziji 1.5. PKCS#1 standard verzije 2.1 je neophodno primeniti u mehanizmima zaštite u specijalizovanim računarskim mrežama i informacionim sistemima.

3.2.2 RSA algoritam

RSA algoritam je prvi put publikovan 1978. godine. Naziv je dobio po prvim slovima prezimena autora algoritma (R.L.Rivest, A.Shamir, L.Adleman). Teorijska osnova algoritma za realizaciju šifrovanja i dešifrovanja poruka prikazana je u sledećim teoremama.

Teorema 1: Linearna kongruencija

(3.2.2.1)

ima rešenje ako i samo ako je NZD(a,m)b (NZD-najveći zajednički delilac), i u tom slučaju, ako je jedno rešenje kongruencije, onda je opšte rešenje

(3.2.2.2)

gde je .

44

Posledica 1a: Ako su brojevi a i m relativno prosti, tj. , onda linearna kongruencija ima tačno jedno nekongruentno rešenje po modulu m.

Teorema 2: (Kineska teorema o ostacima) Ako su po parovima relativno prosti celi brojevi, tada sistem kongruencija:

. . . (3.2.2.3)

ima jedinstveno rešenje po modulu .

Teorema 3: (Ojlerova teorema (L.Euler)) Ako su a i n uzajamno prosti brojevi, onda je:

(3.2.2.4)

gde je sa označen broj prirodnih brojeva, ne većih od n, uzajamno prostih sa n.

Posledica 3a: (Fermaova teorema (P. Fermat)) Ako je p prost broj i NZD(a,p)=1, onda je

. (3.2.2.5)

Posledica 3b: Ako je n proizvod prostih pozitivnih brojeva p, q (n=pq) i NZD(a,n)=1, onda je

. (3.2.2.6)

Teorema 4: Neka je proizvod n=pq prirodan broj gde su p i q prosti pozitivni brojevi. Neka je e prirodan broj takav da je i neka su brojevi e i proizvod

relativno proste veličine. Tada postoji prirodan broj d takav da je:

(3.2.2.7)

i za svaki prirodan broj a, 0 a n važi:

(3.2.2.8)

Dokaz:

Kako su brojevi e i proizvod brojeva relativno proste veličine tada se može, na osnovu teoreme 2, zaključiti da postoji prirodan broj d takav da je ispunjeno:

(3.2.2.9)

45

Dati proizvod se može predstaviti na sledeći način:

(3.2.2.10)

gde je A prirodan broj.

Može se dokazati da za proizvoljan broj a važi .

Neka su a i n relativno prosti brojevi (NZD(a,n)=1), tada je prema Ojlerovoj teoremi (3.2.2.4):

(3.2.2.11)

Neka je NZD(a,n)1 i 0 a < n. Tada je, s obzirom na oblik broja n, NZD(a,n)=p ili je NZD(a,n)=q. Ako se pretpostavi da je NZD(a,n)=p, tada je, prema Fermaovoj teoremi (3.2.2.5):

(3.2.2.12)

(3.2.2.13)

Kako su p i q prosti brojevi, prema kineskoj teoremi o ostacima (3.2.2.3), sistem kongruencija:

(3.2.2.14)

ima jedinstveno rešenje X koje je manje od n=pq. Prema prethodnom a je jedno takvo rešenje pa prema tome i jedino. Na isti način se postupa u slučaju da je NZD(a,n)=q. Prema prethodno navedenom, pokazuje se da je u bilo kom slučaju zadovoljeno .

Algoritam za transformaciju poruka baziran na navedenoj teoremi odvija se na sledeći način.

Neka je M poruka koju je potrebno transformisati.

Prvi korak u realizaciji algoritma je odabir prostih pozitivnih brojeva p, q i određivanje vrednosti njihovog proizvoda n=pq.

U sledećem koraku bira se prirodan broj e, takav da je.

46

Nakon odabira vrednosti za e se izračunava broj d takav da je .

Proces transformacije poruka odvija se na sledeći način. Ako se sa M označi numerički ekvivalent poruke M i napiše u obliku M=M1M2 …Mk gde je 0 Mi < n, i=1, 2, … , k; tada se za svako Mi, i=1, 2, … , k izračuna:

(3.2.2.15)

Poruka C=C1C2 …Ck predstavlja transformisani oblik poruke M i u datom obliku se poruka M prenosi primaocu komunikacionim kanalima. Primalac rekonstruiše poruku tako što znajući vrednosti d, p i q izračunava:

(3.2.2.16)

i ulančavanjem formira originalnu poruku M=M1M2 …Mk. Korektnost navedenog načina transformacije i rekonstrukcije poruka direktna je posledica teoreme 4. Uređeni par (e,n) je javni ključ a uređena trojka (d,p,q) je tajni ključ RSA algoritma.

Po bezbednosnoj klasifikaciji prethodni algoritam spada u klasu računski bezbednih sistema. Sigurnost ovog algoritma bazira se na nepoznavanju efikasnog algoritma za faktorizaciju prirodnih brojeva i direktno zavisi od veličine broja n (koja se može izražavati brojem cifara u dekadnom ili binarnom zapisu).

Pored asimetričnog kriptografskog algoritma, u asimetričnim sistemima je od izuzetne važnosti izbor odgovarajućeg algoritma za generisanje asimetričnog para ključeva. U slučaju da je asimetrični algoritam RSA algoritam, generisanje ključeva se odnosi na generisanje velikih slučajnih prostih brojeva. U tom smislu, takođe su veoma značajni algoritmi za proveru da li su izgenerisani ključevi prosti brojevi.

Testovi da li je odgovarajući broj prost generalno se mogu podeliti na dva tipa:

Verovatnosni testovi, Testovi za dokazivanje da je dati broj prost.

Testovi prve grupe su generalno takvi da, kao rezultat, daju podatak da li je broj složen ili se ponaša kao prost. U prvom slučaju broj je sigurno složen, i kao takav ne može biti prost, a u drugom slučaju postoji verovatnoća da se ponaša kao prost ali da nije takav. U ovu grupu testova spadaju Fermaov, Solovej-Strasenov i Miler-Rabinov test.

Testovi druge grupe predstavljaju metode kojim se može dokazati da je broj prost. Generalno ove metode su računarski veoma zahtevne. U ovu grupu testova spadaju Poklingtonov test, test Jakobijevih suma i test zasnovan na eliptičkim krivim.

U ovom generičkom modelu predlaže se Miler-Rabinov test koji se odvija prema sledećoj proceduri ( je broj koji se proverava da li je prost):

1. Stavimo gde je t neparan broj

47

2. Izaberimo slučajno broj 3.4. Ako je tada je prost i kraj.5. Od do radi

Ako je tada je prost i kraj,inače

6. je složen i kraj

Može se pokazati da je verovatnoća greške ovog algoritma, verovatnoća da se broj

proglasi prostim kada on to nije, jednaka . Nezavisnim izborom različitih vrednosti

za a i sukcesivnim ponavljanjem testa greška se može učiniti proizvoljno malom.

Ovaj test je bolji od Fermaovog i Solovej-Strasenovog u smislu da je kod njega broj lažnih prostih brojeva najmanji.

3.3 Message digest algoritmi

Takozvane jednokoračne hash ili message digest funkcije H(M) izvršavaju se nad porukom M proizvoljne dužine, proizvodeći hash vrednost h=H(M) fiksne dužine m. Hash funkcije treba da zadovolje sledeće karakteristike:

Za datu poruku M, treba da je relativno jednostavno izgenerisati h, Za dato h, treba da je izuzetno teško izračunati M tako da je H(M)=h, Za dato M, treba da je izuzetno teško naći drugu poruku M’ takvu da je

ispunjeno H(M)=H(M’).

Algoritam MD5 zadovoljava gore navedene karakteristike i predstavlja jedan od najčešće korišćenih hash algoritama. Pored toga ovaj algoritam je specificiran za korišćenje u okviru standarda PKCS#1. Algoritam MD5 produkuje 128-bitnu hash vrednost. Pored ovog algoritma, kao što je veće rečeno, moguća je opcija korišćenja SHA-1 hash algoritma koji produkuje 160-bitnu hash vrednost. U nastavku je kao primer dat kratak opis MD5 algoritma.

Međutim, u poslednjih par godina se došlo do saznanja da poemnuti hash algoritmi, posebno MD5, imaju prilično velike slabosti i da se više ne preporučuju za korišćenje. Umesto tog algoritma, predlaže se korišćenje novih SHA algoritama: SHA-224, SHA-256, SHA-384 i SHA-512.

3.3.1 MD5 message digest algoritam

Nakon određenog inicijalnog procesiranja, MD5 algoritam procesira ulaznu poruku u blokovima od 512 bita, podeljenim u 16 podblokova dužine 32 bita. Naime, prvo se poruka proširuje na taj način da se dobije poruka koja je po dužini tačno 64 bita kraća od odgovarajućeg multipla od 512 bita.

Proširivanje je vrlo jednostavno, prvo se na kraj poruke doda jedan bit jedinice, praćen zahtevanim brojem nula. Zatim se 64-bitna reprezentacija dužine poruke

48

priključi rezultatu. Ova dva koraka služe u cilju formiranja poruke čija je dužina tačno multipl od 512 bita, što se zahteva u algoritmu, obezbeđujući pri tome da različite poruke neće izgledati isto nakon pomenutog proširivanja. Izlaz algoritma predstavlja skup od 4 32-bitna bloka, spojena tako da jednoznačno formiraju 128-bitnu hash vrednost.

Algoritam se sastoji od sledećih koraka:

Prvo se poruka obradi tako da je njena dužina tačno multipl od 512 bita, Zatim se inicijalizuju 4 32-bitne promenljive (tzv. promenljive ulančavanja):

A=0x01234567B=0x89abcdefC=0xfedcba98D=0x76543210

Zatim počinje glavna petlja algoritma koja se izvršava za sve blokove dužine 512 bita date poruke. Četiri inicijalne promenljive se kopiraju u promenljive a, b, b i d. Glavna petlja se sastoji od 4 faze koje su veoma slične. Svaka faza koristi različitu operaciju 16 puta, koja se sastoji od primene određene nelinearne funkcije nad tri od četiri promenljive a, b, c ili d. Zatim se tako dobijeni rezultat dodaje četvrtoj promenljivoj, podbloku poruke i jednoj konstanti. Dobijeni rezultat se rotira ulevo promenljivi broj bita i dodaje se jednoj od četiri promenljive a, b, c ili d. Na kraju rezultat zamenjuje jednu od promenljivih a, b, c ili d. Videti Slike 3.19 i 3.20.

Postoje četiri nelinearne funkcije, po jedna se koristi u svakoj operaciji:

F(X,Y,Z) = (X ^ Y) v (( X) ^ Z)G(X,Y,Z) = (X ^ Z)v (Y ^ ( Z)H(X,Y,Z) = X Y ZI(X,Y,Z) = Y (X v ( Z ))

gde navedeni funkcijski znaci predstavljaju ( - XOR funkcija, ^ - AND funkcija, v - OR funkcija, i - NOT funkcija).

49

Блок поруке

Корак 1 Корак 2 Корак 3 Корак 4

А АB BC C

DD

+

+

+

+

Slika 3.19: Glavna petlja MD5 algoritma

a

b

c

d

Нелинеарна функција <<< S

+ + + +

Mj ti

Slika 3.30: Jedna operacija MD5 algoritma

Ako Mj predstavlja j-ti podblok poruke, j=0, …, 15, a <<< s predstavlja funkciju cirkularnog šiftovanja za s bita, tada se pomenute četiri operacije mogu predstaviti na sledeći način:

FF(a,b,c,d,Mj,s,ti) označava: a = b + ((a + F(b,c,d) + Mj + ti) <<< s)GG(a,b,c,d,Mj,s,ti) označava: a = b + ((a + G(b,c,d) + Mj + ti) <<< s)HH(a,b,c,d,Mj,s,ti) označava: a = b + ((a + H(b,c,d) + Mj + ti) <<< s)II(a,b,c,d,Mj,s,ti) označava: a = b + ((a + I(b,c,d) + Mj + ti) <<< s)

Nakon prethodno opisanog postupka, a, b, c i d se dodaju na A, B, C i D, respektivno, i algoritam nastavlja sa narednim blokom podataka. Krajnji rezultat se formira konkatenacijom od dobijenih A, B, C i D.

3.4 Primena kriptografskih algoritama u informacionim sistemima

U prethodnom tekstu bilo je reči o kriptografskim tehnikama koje se mogu koristiti pri dizajniranju i realizaciji sistema za zaštitu informacija. Kriptografske tehnike koje se koriste smo svrstali u dve grupe, simetrične i asimetrične kriptografske sisteme. Sa stanovišta bezbednosnih usluga jasno je da se uz manje ili veće probleme pri realizaciji u svakom od ovih sistema može realizovati većina osnovnih bezbednosnih servisa.

U obe vrste sistema neosporno se može postići poverljivost podataka. Činjenica je da simetrični sistemi na bazi slučajnog i pseudoslučajnog niza pružaju viši nivo bezbednosti od asimetričnih sistema pri istim dužinama ključeva. Takođe, asimetrični sistemi su znatno sporiji od simetričnih sistema i neophodni su im ključevi znatno

50

veće dužine. Sa druge strane kod simetričnih sistema u slučaju intenzivnog saobraćaja javlja se problem distribucije ključeva.

Što se tiče utvrđivanja autentičnosti i identiteta subjekta u komunikaciji to se izuzetno kvalitetno realizuje u asimetričnim sistemima korišćenjem tehnike digitalnog potpisa uz upotrebu digitalnih certifikata. U simetričnim sistemima takođe se mogu realizovati sistemi za autentikaciju, najpoznatiji je Kerberos, ali sa stanovišta logike samog procesa autentifikacije tu postoji jedna nepremostiva teškoća. Naime u takvim sistemima uvek postoji treća strana od poverenja koja aktivno učestvuje u procesu autentikacije, te kao takva predstavlja potencijalni izvor opasnosti.

Što se tiče zaštite integriteta podataka u oba sistema se pomenuti servis relativno lako realizuje a kao kriterijum se uzima uspešno dešifrovanje (struktura i sadržaj poruke). Kod realizacije servisa neporicanja kod simetričnih sistema se javlja problem postojanja aktivne treće strane od poverenja koja u spornim situacijama vrši arbitražu. Prednost asimetričnih sistema u ovom slučaju je u tome što je subjekt sam u stanju da pruži dokaze učešća drugog entiteta u transakciji ukoliko su ostali bezbednosni mehanizmi sistema adekvatni (pasivna treća strana od poverenja).

Iz prethodnog izlaganja prirodno proističu zaključci o koncepciji sistema zaštite u savremenim informacionim sistemima i računarskim mrežama. Najjednostavnije i najlogičnije je formirati sistem koji koristi dobre strane i jednih i drugih kriptografskih algoritama, pogotovu što su oni po svojim dobrim osobinama komplementarni.

Prema tome najefikasniji pristup u koncipiranju savremenih sistema zaštite je formiranje hibridnog sistema koji koristi dobre osobine i jednih i drugih sistema, pa tako za utvrđivanje autentičnosti, zaštite integriteta i obezbeđenje neporicanja treba koristiti asimetrične sisteme a za zaštitu tajnosti podataka simetrične kriptografske algoritme.

Od algoritama sa javnim ključem prirodan izbor bi bio RSA algoritam zbog svoje robusnosti i činjenice da se isti algoritam koristi i za šifrovanje i za potpisivanje poruka. Rasprostranjenost ovog algoritma u primenama učinila ga je važećim de facto standardom u toj klasi.

51

4. VIŠESLOJNA ARHITEKTURA SISTEMA ZAŠTITE SAVREMENIH RAČUNARSKIH MREŽA

U cilju optimalne odbrane informacionih sistema i savremenih računarskih mreža od potencijalnih opasnosti i raznovrsnih napada kojima se ugrožavaju različiti servisi i resursi, predlaže se arhitektura sistema zaštite koja se sastoji od mehanizama zaštite primenjenih na tri nezavisna bezbednosna nivoa koji su namenjeni za odbranu od različitih tipova napada.

Ovi nivoi su projektovani da minimizuju i ograniče moguću štetu tako što eventualno ugrožavanje jednog nivoa ne može kompromitovati ostale bezbednosne nivoe arhitekture sistema zaštite.

U tom smislu, mehanizmi zaštite informacionog sistema mogu da se sastoje od primenjenih mehanizama na sledeća tri nivoa:

Zaštita “s kraja na kraj” (end-to-end security) na aplikativnom nivou koja se zasniva na primeni tehnologije digitalnog potpisa na bazi asimetričnih kriptografskih algoritama i zaštite tajnosti podataka primenom simetričnih kriptografskih algoritama. Primenom ovog nivoa zaštite globalno se obezbeđuje:

o provera autentičnosti korisnika servisa kako u smislu komunikacije (end-user authentication) tako i (opciono) u smislu kontrole pristupa mreži (access control),

o zaštita integriteta podataka koji se prenose, o zaštita od mogućnosti naknadnog poricanja odgovornosti za poslate

podatke io zaštita tajnosti podataka.

Ovaj nivo zaštite generalno služi za odbranu od internih napada. Zaštita na transportnom nivou predstavlja zaštitu tajnosti podataka primenom

simetričnih kriptografskih algoritama i autentikacije čvorova komunikacionog segmenta mreže na transportnom nivou. Ovaj nivo štiti mrežu od eksternih napada primenom kriptografskih tunela (zaštićenih sesija) između čvorišta komunikacionog segmenta mreže na transportnom nivou na bazi simetričnih kriptografskih sistema i primenom procedure jake autentikacije između čvorišta mreže čime se obezbeđuje provera autentičnosti strana u komunikaciji.

Zaštita na mrežnom IP nivou obezbeđuje kriptografsku i logičku zaštitu na nivou IP paketa koji se razmenjuju između mrežnih čvorova i štiti čitavu mrežu od eksternih napada korišćenjem zaštitnih mehanizama koje pruža standardna komunikaciona oprema. Ova zaštita se bazira na ostvarivanju kriptografskih tunela na IP nivou na bazi IPSec protokola zaštite putem koga se ostvaruju Virtuelne Privatne Mreže (VPN – Virtual Private Network).

Suština predloga primene višeslojne arhitekture zaštite je u preporuci korišćenja kombinovanih mehanizama zaštite na više različitih nivoa ISO/OSI modela. Dakle,

52

ukoliko nije moguće koristiti mehanizme na svim nivoima, kao minimalna arhitektura, predlaže se primena kombinacije mehanizama na dva nivoa, i to:

Zaštita na aplikativnom nivou (kao obavezna) i Dodatna zaštita na transportnom ili mrežnom nivou.

Na taj način, sistem se brani kako od internih (aplikativna zaštita) tako i od eksternih napada (transportna ili mrežna zaštita).

4.1 Zaštita na aplikativnom nivou

U cilju realizacije mehanizama zaštite na aplikativnom nivou u okviru informacionog sistema Organizacije, predlaže se primena digitalnog potpisa i digitalne envelope, na bazi smart kartica za korisnike.

Za realizaciju zaštite na aplikativnom nivou, neophodno je primeniti odgovarajuću kriptografsku biblioteku kako na klijentu, u okviru odgovarajuće klijentske aplikacije (standalone) ili Internet browser programa, tako i za primenu na odgovarajućem web ili aplikativnom serveru. Ove kriptografske biblioteke na klijentu i serveru su u potpunosti odgovorne za realizaciju kriptografskih funkcija na aplikativnom nivou.

Naime, klijentska offline aplikacija (standalone) sa ugrađenom kriptografskom bibliotekom (ili odgovarajućom ActiveX kontrolom) ili web pretraživački program iz koga se poziva odgovarajuća ActiveX kontrola (ili JAVA aplet u non-Windows baziranim aplikativnim sistemima), treba da ima sledeće kriptografske karakteristike:

Primena mehanizmima zaštite na aplikativnom nivou kojima se obezbeđuju sledeće funkcije:

o Autentičnost potpisnika (asimetrični kriptografski algoritam i tehnologija digitalnog potpisa),

o Zaštita integriteta fajlova (asimetrični kriptografski algoritam i tehnologija digitalnog potpisa),

o Obezbeđenje neporecivosti (asimetični kriptografski algoritam i generisanje ključeva na samim smart karticama i tehnologija digitalnog potpisa),

o Zaštita tajnosti podataka (simetrični kriptografski algoritam i tehnologija digitalne envelope).

Koriste se tehnologije digitalnog potpisa i digitalne envelope. Univerzalnost u odnosu na smart kartice i čitače smart kartice. Ugrađena

ActiveX kontrola na klijentu, kao i kriptografske biblioteke ugrađene na serveru, koristi odgovarajući middleware (koji se sastoji od: CSP (Cryptographic Service Provider), PKCS#11 bibilioteke i token menadžera za administraciju smart kartice) za pristup smart karticama. Na ovaj način, klijentska i serverska aplikacija su nezavisne od konkretne smart kartice koja će biti korišćena a i prelaz na drugi tip kartice je u potpunosti direktan.

Klijentska aplikacija (bilo standalone bilo da se koristi web pretraživački program) sa ugrađenom kripto kontrolom mora da obezbedi funkciju provere

53

autentičnosti korisnika na bazi njegove smart kartice i odgovarajućeg PIN-a pre nego što se omogući korišćenje same aplikacije, tj. aplikacija ne može da se startuje bez korišćenja odgovarajuće smart kartice ovlašćenog korisnika. Pri tome, provera nije samo da li se određena kartica nalazi u čitaču kartica već se mora proveriti i sertifikat korisnika (proverom validnosti, da li je izdat od CA kome se veruje i provera statusa povučenosti).

Bazira se na kriptografskim operacijama koje se izvršavaju na samoj smart kartici: digitalni potpis (tj. RSA private key encryption) i dešifrovanje simetričnog ključa kod digitalne envelope (digital envelope retrieval). Ostale kriptografske operacije (šifrovanje/ dešifrovanje simetričnim algoritmima, kreiranje hash vrednosti podataka koji se digitalno potpisuju, verifikacija digitalnog potpisa) se izvršavaju u klijentskom i serverskom softveru (softverski deo kripto komponenti na klijentu i serveru).

Bazira se na PKCS de facto standardima za zaštitu, i to:

o PKCS#1 za digitalni potpis i digitalnu envelopu,o PKCS#7 za format zaštićenih podataka,o PKCS#11 standardni interfejs za pristup smart karticama.

Aplikacija treba da bude standardna u smislu formata digitalno potpisanih i šifrovanih podataka. U tom smislu, treba primeniti standarde: PKCS#7 (ili noviji Cades) ili XML DIGSIG standard (ili noviji Xades) za format zaštićenih fajlova.

Aplikacija pri realizaciji bezbednosnih mehanizama treba da koristi standardne načine pristupa smart karticama: CSP (Cryptographic Service Provider) i PKCS#11 biblioteka, i stoga je nezavisna od konkretne smart kartice koja će biti korišćena tako da je prelaz na drugi tip kartice u potpunosti direktan.

Klijentska standalone aplikacija, ili odgovarajuće stranice web aplikacije, treba da omoguće:

o Izbor sertifikata potpisnika (koji stoje u Personal Store-u) ukoliko na datoj radnoj stanici postoji veći broj korisničkih sertifikata.

o Izbor sertifikata (koji stoje u Other PeopleStore-u) namenjenog primalaca šifrovanog fajla, tj. lice/korisnik za koga se šifruje taj fajl nakon digitalnog potpisivanja. To može biti i sam server ukoliko se radi o šifrovanoj dostavi podataka do servera.

o Prikaz informacija o podacima koji se digitalno potpisuju pre samog potpisivanja,

o Prikaz informacija o rezultatima digitalnog potpisivanja i/ili šifrovanja datih podataka,

o Prikaz informacija o rezultatima uspešne ili neuspešne verifikacije digitalnog potpisa i/ili uspešnog ili neuspešnog dešifrovanja datih podataka.

Klijentska i serverska kripto komponenta treba da u ovom trenutku podrži sledeće kriptografske algoritme i pridružene dužine ključeva:

o Asimetrični algoritmi – RSA algoritam (koji se izvršava na smart kartici) sa dužinom asimetričnog ključa od 2048 bita.

54

o Hash algoritmi – SHA-1, SHA-224, SHA-256, SHA-384 ili SHA-512.o Simetrični algoritmi – 3DES algoritam sa dužinom ključa od 168 bita ili

AES algoritam sa dužinama ključa od 128, 192 ili 256 bita.

Aplikacija treba da bude otvorena za stalnu dogradnju kako novih algoritama tako i za zamenu onih algoritama za koje je utvrđeno da su kriptografski slabi za korišćenje. Takođe, aplikacija treba da obezbedi promenu dužina odgovarajućih kriptografskih ključeva ukoliko se ukaže potreba za tim.

Aplikacija treba da bude otvorena za eventualnu ugradnju privatnih simetričnih algoritama kreiranih i verifikovanih od strane nadležne institucije za poslove kriptozaštite u zemlji, ukoliko postoje zahtevi za to.

U okviru aplikacije (klijentske i serverske) treba obezbediti funkciju verifikacije digitalnog potpisa odgovarajućih podataka (koji se razmenjuju između korisnika i sistema ili podataka/dokumenata koji su arhivirani i pregledaju se u okviru sistema) koji se sastoji od sledeća dva koraka (tim redom):

o Provera digitalnog potpisa podataka na osnovu javnog ključa iz digitalnog sertifikata potpisnika (koji je došao uz digitalno potpisane podatke u samoj formatiranoj poruci),

o Provera samog digitalnog sertifikata. Ova provera se izvršava na sledeći način:

proverava se da li je dati sertifikat istekao, proverava se da li je sertifikat izdat od CA (certification Authority)

kome se veruje i proverava se da li je sertifikat povučen, tj. da li se nalazi na

važećoj CRL listi koje izdaje dato CA.

U okviru mehanizama zaštite na aplikativnom nivou mogla bi se integrisati i odgovarajuća challenge-response procedura jake autentikacije korisnika na aplikativnom nivou.

Alternativa tome je da se za te potrebe iskoristi standardna procedura klijentske i serverske autentikacije u okviru SSL protokola zaštite na transportnom nivou što je opisano u nastavku a što se i predlaže za primenu u okviru informacionog sistema Organizacije.

4.2 Zaštita na transportnom nivou

U vezi realizacije transportnih mehanizama zaštite, predlaže se primena standardnog SSL (Secure Sockets Layer) protokola (novija verzija je TLS (Transport Layer Security) protokol) između korisnika i web servera (ili web servisa).

U stvari, u informacionom sistemu Organizacije predlaže se primena:

SSL protokola sa serverskom autentikacijom – neophodan je SSL serverski sertifikat izdat za dati web server i

55

SSL protokola sa klijentskom i serverskom autentikacijom na bazi digitalnih sertifikata i smart kartica korisnika. U ovom slučaju je takođe neophodno da web server (ili odgovarajući web servis) ima SSL serverski sertifikat.

Naime, za potrebe autentikacije korisnika informacionog sistema Organizacije, predlaže se primena zaštite na transportnom nivou i jake autentikacije korisnika na bazi SSL protokola sa klijentskom i serverskom autentikacijom.

Dakle, u ovom slučaju nije samo dovoljno da web server poseduje sertifikat (serverska autentikacija) već je neophodno da u sistemu postoji/koristi se i odgovarajuće Sertifikaciono telo (CA) koje izdaje sertifikate klijentima na smart karticama. Na ovaj način se postiže da samo klijenti sa smart karticama i odgovarajućim digitalnim sertifikatima mogu da pristupe datom web serveru, a samim tim da izvršavaju poslovne procese u okviru informacionog sistema Organizacije.

4.3 Zaštita na mrežnom nivou

Umesto SSL protokola na transportnom nivou, ili dodatno njemu, mogu se koristiti i kriptografski mehanizmi zaštite na mrežnom nivou koji se najčešće baziraju na IPSec protokolu zaštite i uspostavi virtuelnih privatnih mreža (VPN – Virtual Private Network).

U zavisnosti od načina komunikacije kao i protokolima koji se koriste za komunikaciju, kriptografske VPN mreže se najčešće baziraju na čistom IPSec protokolu zaštite ili na kombinacijama PPTP/IPSec ili L2TP/IPSec.

U okviru informacionog sistema Organizacije generalno se predlaže primena IPSec protokola na bazi digitalnih sertifikata čvorova u računarskoj mreži (ili između klijenta i VPN servera).

U tom smislu, VPN mreža, koja se bazira na IPSec protokolu, može se uspostaviti između dva rutera ili rutera i firewall-a, ili između VPN klijenta i VPN koncentratora (ruter ili firewall uređaj) – opet na bazi digitalnih sertifikata.

Sa druge strane, neophodno je primeniti firewall uređaje u cilju podizanja sveukupne zaštite i kontrole pristupa sistemu. Jedan primer moguće primene firewall uređaja dat je na slici 4.1.

Na slici 4.1 je dat mogući primer jedne višestruke firewall konfiguracije u kojoj se jedan nivo firewall uređaja (npr. prevashodno paketski filtri) koristi za „prvu odbranu“ i razdvajanje eksterne mreže, DMZ zone i interne mreže, dok se drugi nivo firewall uređaja (npr. prevashodno aplikativni firewall uređaji) koriste za zaštitu najosetljivijih delova informacionog sistema – baza podataka.

Web višeslojne aplikativne konfiguracije u Organizaciji bi se, prema Slici 4.1, sastojale od web servera u DMZ zoni, aplikativnog servera u internoj mreži i baze podataka u najbezbednijem delu interne mreže (back end server network). Firewall konfiguracija prikazana na Slici 4.1 se može realizovati sa fiše firewall uređaja sa 2 ili 3 interfejsa, ili jednim parom firewall uređaja sa više interfejsa (5 i više).

56

Takođe, potrebno je razmotriti i primenu drugih „nekriptografskih“ mehanizama zaštite u Organizaciji, i to: antivirusne zaštite, patch management, web content filtriranja, Intrusion Prevention Sistema (IPS), end-point security mehanizama, itd. Međutim, pomenuti mehanizmi nisu predmet ove studije. Predmet ove Studije zaštite su pre svega kriptografski mehanizmi zaštite.

Slika 4.1: Jedan primer moguće primene višestruke firewall konfiguracije

57

5. OSNOVE PKI SISTEMA

5.1 Uvod u sisteme sa javnim ključevima (PKI – public key infrastructure)

Infrastruktura sistema sa javnim ključevima (PKI – Public Key Infrastructure) omogućuje ambijent za pouzdanu primenu elekronskog poslovanja i ona se najčešće bazira na kombinovanoj primeni asimetričnih i simetričnih šifarskih sistema.

PKI infrastruktura se sastoji od više komponenata, aplikacija i dokumenata koji definišu način realizacije četiri osnovne kriptografske funkcije u elektronskom poslovanju:

Zaštita tajnosti – realizuje se primenom simetričnih kriptografskih sistema, Autentičnost – realizuje se primenom asimetričnih šifarskih sistema, Integritet podataka – realizuje se primenom asimetričnih šifarski sistema, Neporecivost transakcija – realizuje se primenom asimetričnih šifarskih

sistema.

Dok se funkcije zaštite tajnosti i integriteta podataka mogu realizovati i primenom tradicionalnih simetričnih tehnika, funkcije autentičnosti i neporecivosti transakcija zahtevaju primenu asimetričnih kriptografskih sistema – u okviru uspostavljenog PKI sistema.

Najbolje karakteristike pokazuju sistemi u kojima su realizovane sve pomenute četiri funkcije. PKI sistemi obezbeđuju pouzdan metod za realizaciju funkcija provere autentičnosti i neporicanja transakcija koji je baziran na precizno utvrđenoj politici rada.

PKI sistemi su brzo postali ključna karika svih sistema elektronske trgovine i korporacijske bezbednosti i sigurno će dominirati u bezbednosnim sistemima budućnosti.

Osnovni funkcionalni zahtevi koje treba da ispuni određeni PKI sistem navedeni su u nastavku.

5.1.1 Podrška različitim politikama rada PKI sistema

PKI sistem mora omogućiti podršku za primenu različitih bezbednosnih politika krajnjeg korisnika. Ova funkcionalnost omogućuje adaptaciju sistema na promene zakonske, poslovne i drugih politika rada koje utiču na realizaciju PKI sistema.

S obzirom da PKI sistemi predstavljaju infrastrukturu u kojoj su, pored tehničkih aspekata, veoma bitni i značajni legalni i proceduralno-organizacioni aspekti, mogućnost adaptacije sistema na promene politike funkcionisanja predstavlja jedan od ključnih zahteva.

58

5.1.2 Bezbednost sistema

S obzirom da Sertifikaciono telo (Certification Authority – CA) predstavlja centralni deo PKI sistema sa najvažnijim ciljem da uspostavi jedinstvenu tačku poverenja u čitavom sistemu, osnovni zahtev koji se postavlja je najviša bezbednost samog CA.

Naime, ako je CA kompromitovano (tj. ako je privatni ključ asimetričnog kriptografskog sistema CA kompromitovan) bilo internim ili eksternim napadom, i čitav PKI sistem je kompromitovan. Iz tih razloga, CA i čitav PKI sistem je potrebno zaštititi na najvišem nivou.

5.1.3 Skalabilnost

Komercijalno dostupni PKI sistemi su skalabilno dizajnirani tako da se kreću od malih konfiguracija koje rade na jednom PC računaru na kome su realizovane aplikacije CA, registracionih tela (Registration Authority – RA) i neophodne baze podataka pa sve do velikih instalacija sistema.

U velikim instalacijama sistema, postoje višestruka RA sa više operatora, organizovana kao podređeni činioci višestrukom hijerarhijskom sistemu CA, koji su pod jurisdikcijom jednog “Root CA” sistema.

Kao druga veoma značajna osobina, PKI sistem mora podržati eventualno proširivanje sistema dodavanjem određenih modula bez potrebe zaustavljanja rada sistema. Drugim rečima, ako se data organizacija proširuje, ili ako se zahtevi za PKI tehnologijom povećavaju, to se mora rešiti dodavanjem odgovarajućih specifičnih PKI modula.

5.1.4 Fleksibilnost

Određeni PKI sistem treba da je dizajniran tako da bude fleksibilan u cilju lakog rešavanja različitih PKI zahteva.

U ova obeležja su uključeni:

Višestruki sistemi za registraciju i dostavu sertifikata i ključeva – potrebno je da dati PKI sistem podržava različite mehanizme registracije i dostave PKI parametara, uključujući: e-mail servis, web komunikaciju, ličnu dostavu, VPN i drugo.

Podrška različitim bezbednosnim modulima, malim hardverskim modulima (tokenima) i smart karticama,

Podrška primeni različitih kriptografskih algoritama, kako javnih, tako i privatnih algoritama definisanih od strane dizajnera ili samih korisnika sistema,

Višestruki sistemi publikacije izdatih i povučenih sertifikata koji uključuju različite eksterne direktorijumske servise (LDAP i X.500), kao i publikaciju na hard disk u cilju olakšavanja procesa publikacije,

59

Podrška različitim metodama provere validnosti (povučenosti) digitalnih sertifikata, kao što su CRL (Certificate Revocation List), CRL distribucione tačke i OCSP (Online Certificate Status Protocol),

Podrška kompleksnim PKI hijerarhijama – PKI sistem mora podržati hijerarhiju sertifikacionih tela (bilo koje dubine), višestruka registraciona tela (RA), višestruke operatore RA, i mora podržati proceduru među-sertifikacije (cross-certification) sa drugim CA,

Podrška višestrukim ključevima i sertifikatima po korisniku – politika rada PKI sistema, i samog Sertifikacionog tela (CA), treba da predvidi korišćenje višestrukih ključeva i sertifikata po korisniku, a da se korišćenje ovih ključeva tako konfiguriše da se odvojeni ključevi koriste za digitalno potpisivanje i za šifrovanje (u okviru digitalne envelope),

Sistem treba da podrži fleksibilni autorizacioni proces – svaki zahtev za izdavanjem sertifikata može biti autorizovan od strane jedne ili više ovlašćenih osoba, što treba definisati u politici rada CA. Dodatno, sistem treba da omogući da se zahtevi za izdavanje sertifikata procesiraju i automatski, bez potrebe za primenom specifične procedure autorizacije.

5.1.5 Jednostavno korišćenje

U svakom PKI sistemu najvažniji subjekti su:

Administrator bezbednosti PKI sistema koji uspostavlja i monitoriše rad čitavog PKI sistema,

Administrator CA, Operatori RA koji sakupljaju registracione informacije i koji mogu da autorizuju

proces sertifikacije i povlačenja sertifikata, Krajnji korisnici koji podnose zahtev za izdavanjem sertifikata.

PKI sistem treba da bude dizajniran tako da za sve gore pomenute kategorije korisnika sistem bude veoma jednostavan za korišćenje, i da korisnici jedini imaju pristup funkcijama koje su im omogućene za korišćenje. Ovo minimizuje proces obuke neophodne za svaki tip korisnika i redukuje moguće probleme koje oni mogu imati u cilju korišćenja sistema.

5.1.6 Otvorenost sistema

U cilju eventualnih zahteva za interoperabilnošću, PKI sistem mora zadovoljavati osobinu da se bazira na otvorenim standardima, od kojih je najvažniji X.509 standard za format digitalnog sertifikata.

5.2 Komponente PKI sistema

Kao što je već rečeno, infrastruktura sistema sa javnim ključevima (PKI sistem) predstavlja kombinaciju hardverskih i softverskih proizvoda, politika i procedura. PKI sistemi omogućuju osnovno bezbednosno okruženje koje se zahteva u sistemima elektronskog poslovanja (e-business) u kome korisnici, koji se ne poznaju ili su

60

distribuirani po svetu i nalaze se na velikim udaljenostima, mogu komunicirati bezbedno kroz mrežu poverenja.

PKI sistemi se baziraju na digitalnim identitetima (digital IDs) poznatim pod nazivom digitalni sertifikati koji igraju ulogu svojevrsnih “digitalnih pasoša” ili “digitalnih ličnih karata”, i koji povezuju ime vlasnika datog sertifikata sa njegovim javnim ključem asimetričnog kriptografskog sistema, kao što je na primer RSA algoritam, koji služi za verifikaciju digitalnog potpisa.

Bezbednost PKI sistema se bazira na politici zaštite informacionog sistema u kome se primenjuje. Politika zaštite uspostavlja i definiše osnovne pravce i strategiju razvoja bezbednosti informacionog sistema date organizacije, i propisuje procedure i principe korišćenja kriptografskih mehanizama u sistemu. Tipično, bezbednosna politika propisuje na koji se način upravlja ključevima i ostalim neophodnim informacijama u sistemu, i propisuje neophodne nivoe kontrole koji odgovaraju nivoima rizika.

PKI sistem se sastoji od sledećih osnovnih komponenata:

Osnovni dokumenti rada PKI sistema:

o Politika sertifikacije (CP – Certificate Policy) – utvrđuje osnovne principe rada sertifikacionog tela i ostalih komponenata PKI sistema.

o Praktična pravila rada (CPS – Certificate Practice Statement) – predstavlja dokument koji praktično opisuje rad Sertifikacionog tela. CPS predstavlja jedan detaljan dokument koji sadrži operativne procedure za realizaciju principa koji su navedeni u politici sertifikacije i predstavlja praktičnu podršku sistemu. Tipično, CPS uključuje definicije kako je CA formirano i način rada, kako se generišu digitalni sertifikati, kako se povlače, kako će ključevi biti generisani, registrovani i sertifikovani, gde će se čuvati i kako će biti raspoloživi korisnicima.

Sertifikaciono telo (CA) – je najvažnija komponenta i osnova poverenja datog PKI sistema čiji je zadatak da upravlja digitalnim sertifikatima u njihovom čitavom životnom ciklusu. Osnovni zadaci CA su da:

o Generiše digitalne sertifikate tako što povezuje identifikacione podatke određenog korisnika u sistemu sa njegovim javnim ključem asimetričnog kriptografskog sistema, i sve to potvrđuje svojim digitalnim potpisom svih podataka u sertifikatu,

o Upravlja rokom važnosti izdatih digitalnih sertifikata,o Obezbeđuje funkciju povlačenja izdatih digitalnih sertifikata u

slučajevima kada za to postoje uslovi, i u tom smislu, publikuje liste povučenih sertifikata (CRL – Certificate Revocation List).

U postupku formiranja PKI sistema, organizacija može da realizuje sopstveno CA, ili da koristi usluge CA servisa, realizovanog od neke treće strane od poverenja.

Registraciono telo (RA) – obezbeđuje interfejs između korisnika i CA. RA prihvata zahteve i proverava autentičnost korisnika i prosleđuje standardni

61

zahtev za izdavanje digitalnog sertifikata. Kvalitet procedure provere identiteta korisnika određuje nivo poverenja koji se ugrađuje u dati sertifikat.

Sistemi za distribuciju sertifikata – Generisani digitalni sertifikati se mogu distribuirati na različite načine, u zavisnosti od strukture čitavog PKI sistema, kao na primer direktno korisnicima ili preko direktorijumskog servera. Direktorijumski server može već postojati u datom informacionom sistemu same organizacije, ili može biti isporučen kao deo čitavog PKI rešenja. U poslednje vreme, smart kartice predstavljaju načešći način distribucije sertifikata korisnicima.

PKI aplikacije – čitav PKI sistem se kreira da podrži rad većeg broja aplikacija u kojima se koriste digitalni sertifikati i tehnoogija digitalnog potpisa, kao što su:

o Zaštita WEB transakcija,o Zaštita e-mail servisa,o VPN – virtuelne privatne mreže,o Bezbedno upravljanje elektronskom dokumentacijom,o Identity and Access Management sistemi, itd.

5.2.1 Moduli PKI sistema

U cilju zadovoljenja neophodnih zahteva koji se postavljaju pred sistem zaštite, praktične implementacije PKI sistema i samog CA u obliku softversko-hardverskih sistema moraju biti modularno realizovane.

Svi moduli komuniciraju međusobno korišćenjem baze podataka, ili korišćenjem zaštićenih TCP/IP konekcija. Shodno tome, osnovni moduli PKI sistema su:

Sertifikaciono telo (CA) – digitalno potpisuje digitalne sertifikate i publikuje sertifikate i liste povučenih sertifikata (CA je kompleksna komponenta i takođe se sastoji od modula),

Operator Sertifikacionog tela (CAO) – CAO je bezbednosni administrator čitavog PKI sistema,

Registraciono telo (RA) – rutira informacije, sertifikate i zahteve za izdavanjem sertifikata kroz hijerarhiju datog PKI sistema,

Operator RA (RAO) – ima zadatak da potvrdi ili odbije udaljene i lično podnete zahteve za izdavanjem sertifikata,

Arhivni server – ovo je opcioni modul koji se koristi za eventualno čuvanje korisničkih parova ključeva za šifrovanje digitalnom envelopom, ukoliko je ta opcija predviđena politikom sertifikacije datog PKI sistema.

Tradicionalni PKI sistemi su bili bazirani na client-server tehnologijama dok su noviji sistemi većinom web bazirani aplikativni sistemi višeslojne aplikativne infrastrukture.

U nastavku su detaljnije opisani navedeni moduli i to prvo sa stanovišta tradicionalnih client-server tehnologija a zatim i sa stanovišta novih web batiranih rešenja.

62

5.3 Sertifikaciono telo (CA – Certification Authority)

Sertifikaciono telo ili Sertifikacioni autoritet (CA) predstavlja jezgro čitavog PKI sistema. Čitavo poverenje sadržano u PKI infrastrukturi zavisi od digitalnog potpisa CA koji se formira na bazi asimetričnog kriptografskoh algoritma (npr. RSA) i asimetričnog privatnog ključa CA.

CA funkcioniše na bazi sopstvene fleksibilne politike rada (Politike sertifikacije), i kontrolisano je od strane CAO i drugih administratora i operatora. Sertifikaciono telo predstavlja softversko-hardversku aplikaciju koja, kao ulazni parametar, uzima javni ključ asimetričnog kriptografskog sistema korisnika, smešta ga u okvir digitalnog sertifikata i sve to, zajedno sa ostalim podacima korisnika, digitalno potpisuje u cilju garancije da dati javni ključ pripada definisanom korisniku (vlasniku datog digitalnog sertifikata). Za razliku od samopotpisanih sertifikata (kao što su digitalni sertifikati Root Sertifikacionih tela), digitalni sertifikati potpisani od strane CA koji se izdaju korisnicima impliciraju da je CA, kao “treća strana od poverenja” (Trusted Third Party), proverila da dati javni ključ pripada definisanom korisniku i da svojim potpisom sertifikuje da je to istinito.

U najkraćem, ideja se sastoji u tome da određeno ovlašćeno eksterno telo (CA) preuzme lične podatke određenog korisnika i njegov javni ključ, formatira sve te podatke na standardni način, u obliku digitalnog sertifikata, koga zatim digitalno potpiše.

Slika 5.1: U prošćeni grafički prikaz funkcionalnosti CA

63

HSM

Smartкартиц

а

X.500/LDAP

Архив сервер

Интерна база

података

РА

ЦАО

Crypto engine

Управљачки модул

ЦА(CA

engine)

- Directory Manager

- Archive Manager

Digitalni sertifikat, na osnovu digitalnog potpisa CA, predstavlja pouzdanu vezu identiteta određenog korisnika i njegovog javnog ključa. Naime, ime vlasnika sertifikata, javni ključ i dodatne informacije kao što su: datum izdavanja i rok važnosti, ime CA koje je izdalo sertifikat, itd. formatiraju se u obliku digitalnog sertifikata u standardnom formatu (X.509 standard) tako da ga standardni programi za pretraživanje (browser) i kriptografski softverski sistemi mogu procesirati.

Koncept funkcionalnost CA je grafički prikazan na slici 5.1.

5.3.1 Funkcionalnost CA

CA prihvata potvrđene zahteve za generisanjem i povlačenjem sertifikata od registracionih tela (RA) i CAO i isporučuje digitalne sertifikate i potvrdne poruke.

Ako je tako predviđeno utvrđenom politikom rada (Politika sertifikacije), CA takođe dostavlja krajnjim korisnicima asimetrični par ključeva za šifrovanje (digitalna envelopa) koji se arhiviraju u bazi ključeva u arhivnom serveru.

Digitalno potpisivanje sertifikata – CA je odgovorno za digitalno potpisivanje infrastrukturnih sertifikata (sertifikati ovlašćenih korisnika u okviru samog PKI sistema) i sertifikata krajnjih korisnika. CA takođe digitalno potpisuje sertifikate podređenih CA, kao i drugih CA u slučaju unakrsne sertifikacije (cross-certification).

Publikovanje CRL (Certificate Revocation List) – CA digitalno potpisuje sve informacije objavljene u okviru CRL, koja se publikuje u standardnom formatu X.509v2.

Digitalno potpisivanje poruka – sve poruke koje se šalju od strane CA i razmenjuju u PKI sistemu su digitalno potpisane.

Verifikacija poruka – CA verifikuje sve poruke koje dobije u cilju provere autentičnosti i integriteta.

Šifrovanje podataka – sve poruke koje se razmenjuju preko CA su šifrovane putem tehnologije digitalne envelope u PKCS#7 formatu.

Arhiviranje podataka – svi relevantni podaci i log fajlovi se arhiviraju u bazi podataka CA. Sve arhivirane informacije su digitalno potpisane od strane CA. Svaki ulazni slog u bazu poseduje odgovarajući jedinstveni procesni broj.

Publikacija sertifikata i drugih neophodnih parametara – CA opciono publikuje sertifikate i CRL na LDAP ili X.500 direktorijume. CA podržava i publikaciju pomenutih parametara u okviru fajl strukture na hard disku, kao jedan od mehanizama publikacije sertifikata koji se može lako kastomizovati.

Opciono – CA može publikovati CRL i na OCSP (Online Certification Status) serveru.

Generisanje asimetričnog para ključeva – CA generiše svoj sopstveni par ključeva za asimetrični kriptografski algoritam.

Provera jedinstvenog imena Dname i javnih ključeva – CA može opciono da proverava da li svi izdati digitalni sertifikati imaju jedinstveno Dname i javni ključ.

5.3.2 Obeležja CA

64

CA treba da podrži različite hardverske elemente, kao što su: smart kartice za krajnje korisnike, hardverske bezbednosne module (HSM – Hardware Security Module) i druge slične tokene.

CA treba da podrži mogućnost korišćenja DAP i LDAP mehanizama. CA obezbeđuje višestruko generisanje parova asimetričnog ključa. Opciono,

CA može imati individualni par ključeva za svaku od funkcija: digitalno potpisivanje sertifikata, digitalno potpisivanje CRL, šifrovanje podataka, šifrovanje ključa.

CA podržava promenljivo vreme publikovanja CRL. CA opciono treba da podrži OCSP servise. CA treba da podrži čitavu paletu simetričnih i asimetričnih ključeva. Što se tiče

asimetričnih kriptografskih tehnika, CA bi trebalo da podržava sledeće algoritme za realizaciju digitalnog potpisa: RSA, DSA i ECDSA.

5.4 Operator sertifikacionog tela (CAO)

Modul operatora sertifikacionog tela (CAO) predstavlja modul za administraciju, nadzor i kontrolu bezbednosti CA i čitavog PKI sistema koji se bazira na datom CA.

CAO kontroliše sve administratorske funkcije u sistemu i dodeljuje odgovarajuće privilegije ostalim učesnicima u PKI sistemu (administratorima, modulima i eventualno podsistemima).

5.4.1 Funkcionalnost CAO

CAO prosleđuje potvrđene zahteve za izdavanjem sertifikata direktno CA. Zahtevi za izdavanjem sertifikata se smeštaju u CA bazu podataka.

Kreiranje politike rada CA – CAO je odgovoran za kreiranje i održavanje aktuelne politike izdavanja sertifikata. CAO takođe održava politike i procedure rada drugih CA i svih RA.

Ažuriranje novih verzija politike rada CA i celog PKI sistema – CAO dinamički dostavlja nove verzije politike i procedura rada do individualnih operatora registracionih tela (RAO) u cilju obezbeđenja da se svi digitalni sertifikati uvek izdaju u uslovima ažurnih aktuelnih verzija politike datog PKI sistema.

Povlačenje sertifikata – svaki sertifikat može biti povučen od strane CAO. Zahtevi za povlačenjem sertifikata se smeštaju u CA bazu podataka.

Razvoj PKI sistema – CAO može dodati nove module ili aplikacije u PKI sistem i dati im odgovarajuće privilegije.

Generisanje ključeva – CAO može biti odgovoran za generisanje odgovarajućih ključeva (simetričnih i asimetričnih) za korisnike, ukoliko CA vrši tu funkciju.

Digitalno potpisivanje poruka – sve poruke koje se šalju od strane CAO su digitalno potpisane.

Verifikacija potpisanih poruka – sve poruke koje CAO prima prolaze proveru (verifikaciju) digitalnog potpisa u cilju provere autentičnosti potpisnika i integriteta sadržaja poruke.

65

Šifrovanje podataka – sve poruke koje se razmenjuju preko CAO modula su šifrovane putem tehnologije digitalne envelope u PKCS#7 formatu.

Arhiviranje podataka – svi podaci i log fajlovi se arhiviraju u bazi podataka CA. Sve informacije koje se arhiviraju se digitalno potpisuju od strane CAO. Svaki ulazni slog ima svoj jedinstveni procesni broj (tracking number).

5.4.2 Obeležja CAO

CAO treba da podrži različite hardverske elemente, kao što su: smart kartice za krajnje korisnike, hardverske bezbednosne module (HSM – Hardware Security Module) i druge tokene.

Poseduje grafički interfejs, jednostavan za korišćenje. Procesira sertifikate i CRL. Svaki CAO može imati različite nivoe privilegija.

5.5 Registraciono telo (RA)

Registraciono telo (RA) igra ulogu rutera između operatora registracionog tela (RAO) i CA. RA može imati svoju sopstvenu politiku rada, koja se održava lokalno ili od strane CAO. RA može biti klijent-server aplikacija koja ima svoju lokalnu bazu i koja sa jedne strane komunicira sa operatorom RA – RAO, a sa druge strane sa CA. U nastavku je obrađen slučaj korišćenja RA u obliku klijent-server aplikacije.

5.5.1 Funkcionalnost RA

RA prosleđuje potvrđene zahteve za izdavanjem ili povlačenjem sertifikata, dobijene od RAO, do CA. RA dobija sertifikate i potvrdne poruke od strane CA i dostavlja ih do RAO.

RA prosleđuje zahteve za izdavanjem ili povlačenjem sertifikata, dobijene od korisnika putem određenog komunikacionog kanala, do RAO na proveru i potvrdu.

Digitalno potpisivanje poruka – sve poruke poslate od strane RA su digitalno potpisane.

Verifikacija poruka – sve digitalno potpisane poruke koje RA dobija se procesiraju u smislu verifikacije digitalnog potpisaa u cilju provere autentičnosti potpisnika i integriteta sadržaja poruke.

Šifrovanje podataka – sve poruke koje se razmenjuju preko RA su šifrovane u PKCS#7 formatu.

Arhiviranje podataka – svi podaci i log fajlovi se arhiviraju u bazi podataka RA. Sve arhivirane informacije su digitalno potpisane od strane RA. Svaki ulazni slog ima jedinstveni procesni broj.

5.5.2 Obeležja RA

66

RA treba da podrži različite hardverske elemente, kao što su: smart kartice za krajnje korisnike, hardverske bezbednosne module (HSM – Hardware Security Module) i druge tokene.

Opcija automatskog potvrđivanja – u slučaju da je to politikom rada predviđeno, RA može biti podešeno tako da automatski potvrđuje (digitalno potpisuje) sve udaljene zahteve koji stižu bez potrebe za intervencijom RAO.

5.6 Operator registracionog tela (RAO)

Operator registracionog tela (RAO) ima prvenstvenu funkciju da potvrđuje (digitalno potpisuje) zahteve za izdavanjem ili povlačenjem sertifikata koji će dalje biti procesirani od strane CA.

Međutim, u slučaju da politika rada CA (politika sertifikacije) to predviđa i dozvoljava, RAO može realizovati i funkciju generisanja ključeva za krajnjeg korisnika.

Tradicionalno, RAO se realizuje kao klijent-server aplikacija u kombinaciji sa RA, a osnovna funkcionalnost i obeležja biće prikazana u nastavku.

5.6.1 Funkcionalnost RAO

RAO prima zahteve za izdavanjem sertifikata preko RA, ili ih kreira direktno u ličnom kontaktu sa krajnjim korisnikom (face-to-face manner).

RAO je odgovoran za potvrđivanje ili odbijanje zahteva za izdavanjem sertifikata od krajnjeg korisnika koji su dobijeni u ličnom kontaktu ili elektronskom komunikacijom (ova funkcija zavisi od utvrđene politike rada PKI sistema).

RAO šalje potvrđene zahteve za izdavanjem ili povlačenjem sertifikata do RA. RAO može generisati ključeve (asimetrični par ključeva) za krajnjeg korisnika

u softveru ili na kriptografskom hardveru (HSM), ukoliko je to politikom rada predviđeno.

Digitalno potpisivanje poruka – sve poruke poslate od strane RAO su digitalno potpisane.

Verifikacija poruka – sve digitalno potpisane poruke koje RAO dobija se procesiraju u smislu verifikacije digitalnog potpisa a u cilju provere autentičnosti potpisnika i integriteta sadržaja poruke.

Šifrovanje podataka – sve poruke koje se razmenjuju preko RAO modula su šifrovane putem tehnologije digitalne envelope u PKCS#7 formatu.

Arhiviranje podataka – svi podaci i log fajlovi se arhiviraju u bazi podataka RA. Sve arhivirane informacije su digitalno potpisane od strane RAO. Svaki ulazni slog ima jedinstveni procesni broj.

5.6.2 Obeležja RAO

67

RAO treba da podrži različite hardverske elemente, kao što su: smart kartice, hardverske bezbednosne module (HSM – Hardware Security Module) i druge tokene.

Poseduje grafički interfejs jednostavan za korišćenje.

5.7 Sertifikaciono telo kao web višeslojna aplikacija

U prethodnim poglavljima smo opisali najvažnije komponente PKI sistema: CA, CAO, RA i RAO, kao delove jednog tradicionalnog klijent-server softversko-hardverskog sistema u kome i RA predstavljaju serversku aplikaciju sa bazom podataka i zaštićenom TCP/IP vezom sa CA.

Međutim, u poslednje vreme, implementacije PKI sistema se u sve većoj i većoj meri baziraju na višeslojnim aplikacijama, i to pre svega WEB višeslojnim aplikacijama.

Dakle, u novijim sistemima postoji WEB server CA i poseban aplikativni server CA koji prosleđuje zahteve CA crypto engine serveru u cilju formiranja digitalnih sertifikata. U ovakvoj realizaciji, ne postoji RA, već se funkcije RA i RAO kombinuju i integrišu u okviru Internet browser programa sa ciljem WEB komunikacije sa CA. Na taj način, najveći deo procesiranja se prebacuje na sentralni aplikativni server CA, a RAO postaje tanki klijent.

U ovom slučaju, RAO priprema zahteve za izdavanjem i povlačenjem sertifikata, digitalno ih potpisuje i po mogućstvu šifruje, i prosleđuje ih do WEB servera CA na dalju obradu.

RAO može, ali u najvećem broju slučajeva ne čuva nikakvu dokumentaciju u vezi registracije korisnika već se evidencija u potpunosti centralizuje u CA. RAO svojim digitalnim potpisom potvrđuje da su podaci koje dostavlja za korisnika koji zahteva sertifikat autentični i tačni. Ovaj potpis se proverava na strani WEB servera CA.

U slučaju WEB konfiguracije CA, korisnici mogu preko Interneta/Intraneta da dostavljaju direktno svoje zahteve i elektronski, direktno na WEB server CA, ukoliko je to u skladu sa Politikom sertifikacije datog sertifikacionog tela. Za ove slučajeve, u nekim centralnim serverskim CA sistemima postoji i centralni RAO koji potvrđuje sve zahteve koji dođu putem WEB servera CA i odobrava formiranje sertifikata.

5.8 Digitalni sertifikati, struktura i standardi

Digitalni sertifikati predstavljaju element kojim se utvrđuje veza između identiteta subjekta i njegovog javnog ključa za primenu asimetričnog kriptografskog algoritma.

Raspolaganje javnim ključem potpisnika je uslov za pouzdanu verifikaciju digitalnog potpisa. Naime strana koja vrši verifikaciju mora biti sigurna da dati javni ključ predstavlja kriptografski par sa privatnim ključem kojim je poruka digitalno potpisana.

68

Javni i tajni ključ asimetričnog kriptografskog algoritma su dve velike brojne veličine i nemaju determinističku vezu sa identitetom bilo kog pravnog ili fizičkog lica. U tom smislu, digitalni sertifikati predstavljaju mehanizam za pouzdano pridruživanje datog para brojeva identitetu nekog subjekta, tako da se ta veza ne može falsifikovati. Na taj način digitalni sertifikati predstavljaju elektronske ekvivalente nekoj vrsti “digitalne lične karte” ili “digitalnog pasoša”. Da bi se dobio digitalni sertifikat, mora se prvo formirati zahtev za dobijanje sertifikata (Certificate Request), koji se dostavlja određenom CA u cilju izdavanja digitalnog sertifikata. Ovaj zahtev sadrži sve podatke o korisniku koji će se pojaviti i u digitalnom sertifikatu.

Zahtev za sertifikat je digitalno potpisan (samopoptisan) u cilju garancije njegovog integriteta. Sertifikaciono telo proverava autentičnost dobijenog zahteva korišćenjem javnog ključa koji je u njemu sadržan. Pored toga, digitalnim potpisom zahteva za dobijanjem sertifikata, korisnik dokazuje Sertifikacionom telu da poseduje privatni ključ koji je matematički par sa javnim ključem koji je sadržan u datom zahtevu za dobijanje sertifikata. Postoje dva korišćena tipa zahteva za izdavanje digitalnog sertifikata, poznati kao PKCS#10 i RFC 2511. PKCS#10 format je daleko jednostavniji.

PKCS#10 tip zahteva za izdavanjem sertifikata sastoji se od sledeća 4 polja:

Broj verzije formata zahteva (od 1 do 3), Naziv vlasnika digitalnog sertifikata (DistinguishedName - Dname), Javni ključ vlasnika digitalnog sertifikata, Atributi.

Polje atributa sadrži one elemente za koje postoji potreba da se nađu u digitalnom sertifikatu, kao što je broj telefona, broj faksa, e-mail adresa, najviša vrednost finansijske transakcije u slučaju bankarskih sertifikata i druge karakteristike.

U ovom polju se može naći sve ono što ne potpada pod polje Dname a predstavlja jedinstveni string koji identifikuje vlasnika sertifikata. Pored toga, Dname predstavlja put kroz X.500 direktorijum, tako da se jedino može sastojati iz sledećih polja:

Dvoslovni niz koji označava državu, Region, Elektronska adresa, Firma, Odeljenje u firmi, Ime vlasnika sertifikata.

Imajući na raspolaganju digitalni sertifikat određenog subjekta, moguće je izvršiti verifikaciju digitalnog potpisa poruka koje je taj subjekt potpisao. Ukoliko je verifikacija uspešna, verifikator je siguran u integritet poruke, u autentičnost njenog potpisnika i u nemogućnost naknadnog poricanja datog potpisnika za izdavanje date poruke (ukoliko je potpis elektronski potpis realizovan na smart kartici).

69

U okviru sistema zaštite savremenih računarskih mreža, digitalni sertifikati se, između ostalog, mogu primenjivati za verifikaciju digitalnog potpisa, kontrolu pristupa subjekata kriptozaštićenim aplikacijama i u procedurama autentikacije.

Sadržaj digitalnog sertifikata, u skladu sa standardom ITU-T X.509v3, je prikazan je na slici 5.2.

Verzija formata sertifikataSerijski broj sertifikataIdentifikator algoritma kojim se vrši digitalni potpisNaziv Sertifikacionog tela koje je izdalo sertifikatRok važnosti sertifikataNaziv vlasnika sertifikataJavni ključ vlasnika sertifikataOdređeni specifični podaci koji se odnose na uslove korišćenja sertifikataDIGITALNI POTPIS SERTIFIKATA PRIVATNIM KLjUČEM SERTIFIKACIONOG TELA

Slika 5.2: Sadržaj ITU-T X.509v3 digitalnog sertifikata

5.8.1 ITU X.509 v3 sertifikat-struktura

Prema ovom standardu digitalni sertifikat se sastoji od tri dela. Prvi deo čine podaci značajni za sam sertifikat predstavljeni promenljivom tbsCertificate, drugi deo predstavlja identifikator algoritma za potpisivanje predstavljen promenljivom signatureAlgorithm i na kraju sam potpis predstavljen promenljivom signature.

Promenljiva tbsCertificate je strukturnog tipa i sadrži sledeća polja:

Verzija (Version) – predstavnja oznaku strukture digitalnog sertifikata koja je specificirana u standardu X.509 pri čemu su validne verzije 1 i 3,

Serijski broj (Serial Number) – redni broj izdatog sertifikata. Način dodeljivanja serijskih brojeva mora biti jedinstven tj. ime izdavača sertifikata (sertifikaciono telo) i redni broj sertifikata jedinstveno određuju sertifikat. Serijski broj sertifikata je vrednost koju dodeljuje cerifikacioni autoritet u trenutku kreiranja digitalnog sertifikata,

Identifikator algoritma digitalnog potpisa (Signature Algorithm) - oznaka asimetričnog kriptografskog algoritma (RSA, DSA) i korišćene hash funkcije (MD5, SHA1) koji su primenjeni u procesu generisanja digitalnog potpisa sertifikacionog tela,

Naziv izdavača digitalnog sertifikata (Issuer) - struktura koja identifikuje sertifikaciono telo (sertifikacioni autoritet, CA) koje je generisalo dati sertifikat i sastoji se iz sledećih elemenata:

o ime izdavača sertifikata (commonName),

70

o odelenje u organizaciji (organizationalUnitName),o organizacija (organization),o mesto (localityName),o elekronska adresa (emailAddress),o region ili republika u okviru države (stateOrProvinceName),o oznaka države (countryName).

Validnost – specificira se period unutar kojeg se sertifikat smatra važećim ukoliko nije opozvan. Rok važnosti sertifikata predstavlja vremenske okvire validnosti digitalnog sertifikata. U procesu verifikacije prihvata se samo sertifikat kome nije istekao rok važnosti. Navedeno polje se sastoji od dva elementa:

o Početak važnosti sertifikata (Valid From),o Kraj važnosti sertifikata (Valid To).

Vlasnik sertifikata (Subject) – identifikator (ime) vlasnika sertifikata kome se pridružuje javni ključ koji sadrži sertifikat. Naziv vlasnika digitalnog sertifikata je struktura koja identifikuje vlasnika digitalnog sertifikata i sastoji se od sledećih komponenti:

o ime vlasnika sertifikata,o odelenje u organizaciji,o organizacija,o mesto,o elekronska (e-mail) adresa ,o region ili republika u okviru države,o oznaka države.

Javni ključ (Public Key) – javni ključ vlasnika sertifikata i identifikator algoritma za koji je namenjen. Informacija o javnom ključu vlasnika sadrži numeričku reprezentaciju javnog ključa i identifikator asimetričnog algoritma (RSA, DSA, ECDSA) sa kojim se dati ključ primenjuje.

Polje dodatnih informacija (Extension) – sadrži skup polja (ekstenzije) koja, po potrebi, mogu nositi još neke informacije osim ovih osnovnih. Neke od ovih dodatnih informacija mogu posedovati atribut CRITICAL ili NONCRITICAL. Ukoliko aplikacija koja koristi sertifikat pronađe informaciju označenu sa CRITICAL i ne prepozna je, mora sertifikat odbaciti kao neispravan.

Digitalni potpis (Digital Signature) sertifikata od strane CA.

Polje dodatnih informacija može sadržati informacije pomoću kojih se identifikuje javni ključ kojim se sertifikat proverava, ukoliko izdavač ima više parova javnih i tajnih ključeva. Takođe dato polje može da sadrži informacije o nameni javnog ključa koji vlasnik sertifikata poseduje, opis uslova pod kojima je sertifikat kreiran i zašta se može koristiti, alternativna imena izdavača i vlasnika sertifikata.

Prema dosadašnjim iskustvima ovakva struktura sertifikata ispunjava zahteve savremenih kriptografkih sistema zaštite. Shodno tome, većina (ako ne i svi) savremenih sistema zaštite, koji uključuju infrastrukturu sistema sa javnim ključevima

71

(PKI sisteme), bazira se na primeni X.509 digitalnih sertifikata. Dati sertifikati se još nazivaju PKI digitalni sertifikati.

5.8.2 Ekstenzije u sertifikatu

Ekstenzije u sertifikatu su uvedene kada je definisan X.509v3 standard za format sertifikata. U prethodnim verzijama (v1, v2) ukoliko bilo koja informacija, koja nije iz domena Dname, treba da se unese u sertifikat, ona je upisivana kao deo Dname strukture.

Upotreba ekstenzija čini savremene sertifikate izuzetno fleksibilnim, time što se povećava mogućnost uvođenja i podrške novih PKI aplikacija. Dakle, ekstenzije se mogu koristiti u cilju pridruživanja novih atributa korisniku u odnosu na one informacije koje se mogu uneti u Dname strukturu.

Ekstenzije mogu biti takođe korišćene za kreiranje hijerarhije digitalnih sertifikata. Takođe, postoji nekoliko predefinisanih i međunarodno prepoznatih ekstenzija. Pored toga, mogu se takođe realizovati nove ekstenzije za privatne potrebe korišćenjem generičkih ekstenzija.

Polja za ekstenzije u sertifikatu mogu biti korišćena da se obezbede identifikacione informacije, autorizacioni podaci i polja kontrole pristupa. Ukratko, ekstenzije sertifikata mogu biti korišćene da sadrže informacije za koje korisnik smatra da mogu biti korisne u procesu analize digitalnih sertifikatu.

Sve ekstenzije u sertifikatu mogu biti označene kao kritične (critical) ili nekritične (noncritical). Ako je ekstenzija označena kao nekritična, to znači da će, ako neka PKI aplikacija ne prepozna datu ekstenziju, ona biti ignorisana i da će se dati sertifikat dalje normalno procesirati.

Ekstenziju treba označiti kao kritičnu ako se želi da se osigura da ograničenje na korišćenje datog sertifikata, koje se uvodi pomenutom ekstenzijom, neće moći da se prenebregne od strane bilo koje aplikacije. Neke ekstenzije moraju biti obavezno proglašene kritičnim u skladu sa standardom X509v3. Međutim, za većinu ekstenzija se preporučuje da budu nekritične.

Potrebno je, takođe, pažljivo procenjivati potrebu za dodavanjem svake ekstenzije jer one doprinose uvećanju samog sertifikata. Takođe, što više ekstenzija se doda to je veća verovatnoća da će u budućnosti neke informacije iz ekstenzija biti nevalidne i da će se zbog toga morati povući sertifikat. U tom smislu, preporuka je da se u sertifikat dodaju samo suštinski važne ekstenzije i da se ne povećava nepotrebno veličina sertifikata dodavanjem nepotrebnih informacija.

Ekstenzije su karakteristične za verziju 3 digitalnih cerifikata. U polju ekstenzija se nalaze dodatne informacije vezane za vlasnika i izdavača sertifikata. Standardne ekstenzije u sertifikatu su:

Identifikator ključa autoriteta (Authority Key Identifier), Identifikator ključa subjekta (Subject Key Identifier), Upotreba ključa (Key Usage),

72

Period korišćenja privatnog ključa (Private Key Usage Period), Politike sertifikacije (Certificate Policies), Mapiranje politike (Policy Mappings), Alternativno ime subjekta (Subject Alternative Name), Alternativno ime izdavača sertifikata (Issuer Alternative Name), Direktorijumski atributi subjekta (Subject Directory Attributes), Osnovna ograničenja (Basic Constraints), Ograničenja vezana za ime subjekta (Name Constraints), Ograničenja vezana za primenjenu politiku (Policy Constraints), Prošireno korišćenje ključa (Extended Key Usage), Distributivne tačke za listu povučenih sertifikata (CRL (Certificate Revocation

List) Distribution Points).

Navedene ekstenzije u sertifikatu su predložene od strane PKIX radne grupe (Internet X.509 Public Key Infrastructure Certificate and CRL profile, RFC2459, RFC3280 i RFC5280).

5.8.2.1 Identifikator ključa autoriteta (Authority Key Identifier)

Kada sertifikaciono telo (autoritet) ima više različitih privatnih asimetričnih ključeva namenjenih za izdavanje digitalnih sertifikata različitim grupama korisnika, ili u različitom vremenskom periodu, identifikator ključa autoriteta omogućava identifikaciju javnog ključa CA koji odgovara privatnom ključu korišćenom za digitalno potpisivanje datog korisničkog sertifikata.

Pomenuta identifikacija može biti bazirana bilo na identifikatoru ključa (identifikator ključa subjekta (hash vrednost javnog ključa) u ekstenziji sertifikata) ili na imenu CA i serijskom broju.

Usklađen CA sertifikat je sertifikat koji uključuje ekstenziju osnovnih ograničenja a vrednost CA u toj ekstenziji je „true“. U cilju olakšanog formiranja veze sertifikata, polje keyIdentifier u ekstenziji authorityKeyIdentifier mora biti uključeno u svim usklađenim CA sertifikatima.

Ukoliko se radi o samopotpisanom CA sertifikatu, identifikator ključa autoriteta može biti izostavljen zato što su u tom slučaju identifikatori ključeva subjekta i autoriteta identični.

Vrednost polja keyIdentifier se izvodi iz javnog ključa koji se koristi u procesu verifikacije digitalnog potpisa sertifikata ili primenom metoda koja generiše jedinstvene vrednosti.

Ako se koristi ekstenzija identifikator ključa autoriteta ona treba da bude označena kao nekritična.

5.8.2.2 Identifikator ključa subjekta (Subject Key Identifier)

73

Identifikator ključa subjekta je namenjen za identifikaciju javnog ključa datog subjekta. U cilju olakšanog formiranja veze sertifikata i privatnog ključa, ova ekstenzija se mora pojaviti u svim usklađenim CA sertifikatima.

Vrednost identifikatora ključa subjekta mora biti vrednost smeštena u polje identifikatora ključa u ekstenziji identifikator ključa autoriteta. Za CA sertifikate, identifikator ključa subjekta treba da bude izveden iz javnog ključa ili primenom metoda koji generiše jedinstvene vrednosti.

Uobičajene metode za generisanje identifikatora ključa iz javnog ključa su:

keyIdentifier – sačinjen od 160-bitne SHA-1 hash vrednosti izračunate nad vrednošću BIT STRING polja subjectPublicKey (isključujući tag, dužinu i broj neiskorišćenih bita),

keyIdentifier – sačinjen od 4-bitnog polja vrednosti 0100 praćenih sa poslednjih 60 bita (najmanje značajnih) SHA-1 hash vrednosti izračunate u odnosu na BIT STRING vrednost polja subjectPublicKey.

Jedan uobičajeni metod za generisanje jedinstvenih vrednosti je monotono uvećavanje sekvence celobrojnih vrednosti. Povoljnija varijanta je da se jedinstvene vrednosti koje se koriste u sertifikatu (serijski broj, jedinstven identifikator korisnika u okviru CA, itd.) generišu na odgovarajući slučajan način, uz obezbeđenje da se izgenerisani slučajni brojevi ne ponavljaju.

U slučaju da je krajnji korisnik dobio više sertifikata, naročito od više CA, identifikator ključa subjekta omogućuje brzu identifikaciju skupa sertifikata koji sadrže određeni javni ključ. Ova ekstenzija treba da bude uključena u sve sertifikate krajnjih korisnika sa ciljem da se omogući aplikacijama da identifikuju odgovarajuće sertifikate.

Za sertifikate krajnjih korisnika, identifikatori ključa subjekta treba da budu izvedeni iz javnog ključa, korišćenjem jednog od dva već pomenuta uobičajena metoda.

Ako se koristi ekstenzija identifikator ključa subjekta ona treba da bude označena kao nekritična ekstenzija.

5.8.2.3 Korišćenje ključa (Key Usage)

Ekstenzija pod imenom korišćenje ključa (Key Usage) definiše svrhu ključa koji se sadrži u sertifikatu (javni ključ), kao i njemu odgovarajućeg privatnog ključa.

Moguće je definisati sledeće primene ključa:

kreiranje digitalnog potpisa poruka (digitalSignature vrednost) označava da se taj par ključeva koristi za realizaciju digitalnog potpisa,

slična primena je i neporecivost (nonRepudiation), ova vrednost mora da bude navedena u kvalifikovanim sertifikatima,

šifrovanje i dešifrovanje simetričnog ključa (keyEncipherment) koje se primenjuje u procesu kreiranja digitalne envelope,

šifrovanje i dešifrovanje poruka (dataEncipherment), kreiranje digitalnog potpisa sertifikata (certificateSigning),

74

kreiranje digitalnog potpisa CRL liste (CRLSigning).

Ako se koristi ekstenzija korišćenje ključa ona treba da bude označena kao kritična ekstenzija.

5.8.2.4 Period korišćenja privatnog ključa (Private Key Usage Period)

Ova ekstenzija omogućava CA da specificira period važnosti privatnog ključa subjekta, koji, prema ovoj ekstenziji, može biti i različit u odnosu na period važnosti sertifikata.

Ova ekstenzija je namenjena za korišćenje u odnosu na ključ za digitalno potpisivanje i sastoji se od dve opcione komponente: notBefore i notAfter.

Međutim, PKIX radna grupa se izjasnila protiv korišćenja ove ekstenzije i CA koji poštuju X.509 standardni profil ne smeju da generišu sertifikate sa kritičnom ekstenzijom u smislu perioda korišćenja privatnog ključa.

5.8.2.5 Politike sertifikacije (Certificate Policies)

Ova ekstenzija sadrži sekvencu od jednog ili više parametara određenih politika koji označavaju politiku sertifikacije pod kojom je dati sertifikat izdat, kao i svrhe za koje se dati sertifikat može koristiti.

U cilju uspostavljanja interoperabilnosti, predloženo je da ovi parametri treba da sadrže samo identifikatore objekata (Object Identifier, OID). Kada je nedovoljna primena samo identifikatora objekata, predlaže se upotreba opcionih kvalifikatora. Ova specifikacija definiše dva tipa kvalifikatora koji se koriste od strane onih koji izrađuju politiku sertifikacije sertifikacionih tela. Tipovi kvalifikatora su CPS Pointer i User Notice kvalifikatori.

Kvalifikator CPS Pointer sadrži pokazivač na Certificate Practice Statement (CPS) koje publikuje CA. Kvalifikator User Notice je namenjen za prikazivanje strana u komunikaciji kada se koristi sertifikat.

Aplikacije koje imaju specifične zahteve u odnosu na politiku sertifikacije treba da imaju listu politika koje prihvataju i porede ih sa identifikatorima objekata politike u sertifikatima koje procesiraju.

X.509 standard omogućava da ova ekstenzija bude ili kritična ili nekritična. Ako je definisana kao kritična, sistem za validaciju sertifikata mora imati mogućnost da jednoznačno interpretira ovu ekstenziju (uključujući opcioni kvalifikator), ili mora da odbaci dati sertifikat.

5.8.2.6 Mapiranje politike (Policy Mapping)

Ova ekstenzija se koristi samo u CA sertifikatima. U njoj se prikazuju jedan ili više parova identifikatora objekata (OID). Svaki par uključuje issuerDomainPolicy i subjectDomainPolicy. Uparivanje označava da CA koje izdaje digitalne sertifikate

75

primenjuje njenu issuerDomainPolicy ekvivalentnu subjectDomainPolicy od CA koje je izdalo digitalni sertifikat datom subjektu.

Korisnici CA koje izdaje sertifikate mogu prihvatiti issuerDomainPolicy za određene aplikacije. Mapiranje politika govori korisnicima CA koje izdaje sertifikate koje politike, pridružene CA datog subjekta, su uporedive sa politikama koje oni prihvataju.

Važno je istaći da CA i aplikacije mogu da podrže ovu ekstenziju, koja mora biti nekritična.

5.8.2.6 Alternativno ime subjekta (Subject Alternative Name)

Ova ekstenzija omogućava dodatnim identitetima da budu povezani sa subjektom sertifikata.

Definisane opcije uključuju sledeće:

Internet e-mail adresu, IP adresu, DNS ime, URI – Uniform Resource Identifier.

Ostale opcije postoje, uključujući kompletnu lokalnu definiciju opcija.

Uvek kada višestruka imena, ili višestruke forme jednog imena, treba da budu uključene u sertifikat, ekstenzija alternativnog imena subjekta treba da se koristi. S obzirom da je alternativno ime subjekta takođe priključeno javnom ključu, CA mora verifikovati sve delove ekstenzija.

Ako je jedini identitet subjekta u sertifikatu predstavljen u formi alternativnog imena, kao što je e-mail adresa, tada se mora osigurati da je Dname subjekta prazna sekvenca i da je subjectAltName ekstenzija prisutna i označena kao kritična.

Moguće je ograničiti alternativna imena subjekta na isti način kao i Dname subjekta korišćenjem ekstenzije ograničenja imena.

5.8.2.7 Alternativno ime izdavaoca (Issuer Alternative Name)

Kao i u slučaju alternativnog imena subjekta, ova ekstenzija se može koristiti u cilju pridruživanja Internet identifikacionih karakteristika CA.

Alternativno ime izdavaoca treba da bude prikazano na isti način kao i alternativno ime subjekta i ova ekstenzija se ne sme označiti kao kritična.

5.8.2.8 Direktorijumski atributi subjekta (Subject Directory Attributes)

X.509 standard i PKIX radna grupa ne prepoznaju ovu ekstenziju kao suštinski deo profila, ali se može iskoristiti u lokalnim okruženjima.

Ako se ova ekstenzija koristi, ne treba biti označena kao kritična.

76

5.8.2.9 Osnovna ograničenja (Basic Constraints)

Ova ekstenzija identifikuje da li je subjekt sertifikata sertifikaciono telo, kao i dužinu sertifikacionog puta (Certification Path) datog CA.

Preko navedene ekstenzije se specificira da li vlasnik datog sertifikata može da generiše digitalne sertifikate za ostale korisnike (Subject Type=CA) ili ne (Subject Type=End Entity).

Polje pathLenConstraint ima značenje samo ako je vrednost CA u ovoj ekstenziji postavljeno na „true“. U tom slučaju, ovo polje daje maksimalan broj CA sertifikata koji mogu pratiti ovaj sertifikat u okviru sertifikacionog puta. Vrednost nula označava da samo sertifikati krajnjih korisnika mogu biti u datom sertifikacionom putu. Kada ovo polje ne postoji, ne postoji ograničenje na dozvoljenu dužinu sertifikacionog puta.

Ova ekstenzija ne treba da se pojavljuje u sertifikatima krajnjih korisnika a u slučajevima kada se koristi, mora da bude kritična ekstenzija u svim CA sertifikatima.

5.8.2.10 Ograničenja imena (Name Constraints)

Ova ekstenzija se može jedino koristiti u CA sertifikatu. Ova ekstenzija označava prostor imena u koji treba da se smeste sva imena u naknadnim sertifikatima u datom sertifikacionom putu. Ograničenja se mogu primeniti na pravo (distinguished) ili alternativno ime subjekta. Ograničenja se primenjuju samo kada je data forma imena prisutna. Ako nema imena tog tipa u sertifikatu, sertifikat je prihvatljiv.

Ograničenja se definišu u obliku dozvoljenih i isključenih podgrana imena. Bilo koje ime koje spada u ograničenje definisano u isključenoj podgrani, polje excludedSubtrees, nije validno bez obzira na informacije koje stoje u polju permittedSubtrees. Za URI, ograničenje se primenjuje na host deo imena.

Ako se koristi ova ekstenzija ona treba da bude označena kao kritična.

5.8.2.11 Ograničenja politike (Policy Constraints)

Ova ekstenzija se može koristiti u sertifikatima koji su izdati određenim CA. Ova ekstenzija ograničava validaciju sertifikacionog puta na dva načina. Ekstenzija može biti korišćena da spreči mapiranje politika ili u cilju zahteva da svaki sertifikat u putu sadrži prihvatljiv identifikator politike.

Ako je polje inhibitPolicyMapping prisutno, njegova vrednost označava broj dodatnih sertifikata koji mogu da se pojave u sertifikacionom putu pre nego što je sprečeno mapiranje politika. Na primer, vrednost jedan označava da se procedura mapiranja politike može procesirati u sertifikatima izdatim od strane subjekta datog sertifikata, ali ne i u dodatnim sertifikatima u sertifikacionom putu.

Ako je polje requiredExplicitPolicy prisutno, naknadno izdati sertifikati će uključivati prihvatljiv identifikator politike. Vrednost ovog polja označava broj dodatnih sertifikata koji mogu da se pojave u sertifikacionom putu pre nego što se zahteva eksplicitna

77

politika. Identifikator prihvatljive politike je identifikator politike koja se zahteva od strane korisnika sertifikacionog puta ili identifikator politike koja je označena kao ekvivalentna kroz proceduru mapiranja politika.

Usklađena CA ne smeju da izdaju sertifikate kada je ograničenje politike null sekvenca. To znači da najmanje jedno od dva polja (inhibitPolicyMapping ili requiredExplicitPolicy) mora da bude prisutno. Ukoliko se koristi ova ekstenzija, ona može biti označena kao kritična ili nekritična.

5.8.2.12 Prošireno korišćenje ključa (Enhanced Key Usage)

Ova ekstenzija označava jednu ili više namena za koje se sertifikovani javni ključ može koristiti, zajedno sa, ili umesto osnovne svrhe koja je označena u ekstenziji korišćenja ključa.

Data ekstenzija definiše dodatnu namenu para ključeva asimetričnog algoritma specificiranog u digitalnom sertifikatu. Moguće je definisati sledeća proširenja primene ključa:

digitalno potpisivanje izvršnog programa (CodeSigning), digitalno potpisivanje poruka koje se prenose posredstvom elektronske pošte

(Secure Email), autentikacija servera prilikom kreiranja kriptografskog tunela sa klijentskim

računarom (Server Authentication), autentikacija klijenta prilikom kreiranja kriptografskog tunela sa serverskim

računarom (Client Authentication). logovanje na domen pute smart kartica (Smart Card logon), itd.

Ako se ova ekstenzija koristi, ona može biti označena kao kritična ili nekritična.

Ako je ekstenzija označena kao kritična, tada se sertifikat može koristiti samo za jednu od navedenih svrha.

Ako je ekstenzija označena kao nekritična, tada ona označava namenjenu svrhu ili svrhe primene ključa i može biti korišćena za pronalaženje korektnog ključa/sertifikata korisnika koji ima višestruke ključeve/sertifikate, i u tom slučaju, se može koristiti samo kao savetodavno polje.

Ako sertifikat sadrži kritično polje korišćenja ključa i kritično polje proširenog korišćenja ključa, tada oba polja moraju da se procesiraju nezavisno i sertifikat može biti korišćen samo u svrhe koje su konzistentne sa oba polja. Ako nema takve svrhe, sertifikat ce ne može koristiti.

5.8.2.13 CRL distributivne tačke

Ova ekstenzija označava kako se mogu dobiti informacije o CRL. Ova ekstenzija je podržana od strane CA i aplikacija.

Ako se ova ekstenzija koristi, ona treba da bude označena kao nekritična.

78

5.8.3 Najčešće korišćene ekstenzije

Najčešće ekstenzije prisutne u verziji v3 digitalnih cerifikata su:

Osnovna ograničenja (Basic Constraints). Preko navedene ekstenzije se specificira da li vlasnik datog sertifikata može da generiše digitalne sertifikate za ostale korisnike (Subject Type=CA) ili ne (Subject Type=End Entity).

Specifikacija primene ključa (Key Usage). Data ekstenzija određuje namenu ključa asimetričnog algoritma specificiranog u digitalnom cerifikatu. Moguće je definisati sledeće primene ključa:

o kreiranje digitalnog potpisa poruka (Digital Signature),o dešifrovanje poruka čime se može ostvariti funkcija neporecivosti (Non-

Repudiation),o šifrovanje simetričnog ključa (KeyEncipherment) koje se primenjuje u

procesu kreiranja sesijskog ključa ili digitalne envelope,o šifrovanje poruka (DataEncipherment),o kreiranje digitalnog potpisa sertifikata (Certificate Signing).

Dodatna specifikacija primene ključa (Enhanced Key Usage). Data ekstenzija definiše dodatnu namenu ključa asimetričnog algoritma specificiranog u digitalnom cerifikatu. Moguće je definisati sledeća proširenja primene ključa:

o digitalno potpisivanje izvršnog programa (CodeSigning),o digitalno potpisivanje poruka koje se prenose posredstvom elektronske

pošte (Secure Email),o autentikacija servera prilikom kreiranja kriptografskog tunela sa

klijentskim računarom (Server Authentication),o autentikacija klijenta prilikom kreiranja kriptografskog tunela sa

serverskim računarom (Client Authentication).

Politika primene digitalnog sertifikata (Certificate Policy). Data ekstenzija pobliže definiše politiku i način primene datog digitalnog cerifikata. Svaka politika primene sertifikata je predstavljena sa:

o oznakom date politike (Policy Qualified Id),o vrednošću koja opisuje način primene sertifikata u skladu sa

specificiranom politikom (Qualified).

5.9 Metode registracije korisnika

CA može bilo da dobije javni ključ od samog korisnika i da ga sertifikuje, ili da generiše za svakog korisnika par javnog i privatnog ključa asimetričnog kriptografskog sistema i da distribuira zajedno privatni ključ i PKI digitalni sertifikat.

Iz razloga sigurnosti i logističkih povoljnosti, u izvesnim slučajevima se smatra boljom praksom ako korisnik sam generiše par asimetričnih javnih ključeva (javni i tajni

79

ključ), a zatim da zahtev za izdavanjem sertifikata koji sadrži njegov javni ključ dostavi CA na sertifikaciju.

Ovaj metod obezbeđuje da se privatni ključ uvek čuva na jednoj lokaciji – kod korisnika. Međutim, pomenuti razlozi sigurnosti se mogu opravdati samo sa stanovišta korisnika. Sa stanovišta PKI sistema (CA), sigurnije je da samo CA bude nadležno za generisanje parova asimetričnih ključeva jer se jedino na taj način može kontrolisati i održati jedinstven kvalitet izgenerisanih ključeva i jedinstvenost procedure bezbednog čuvanja izgenerisanih ključeva. U tom slučaju, privatni ključevi se distribuiraju korisnicima na bezbednim medijumima, kao što su smart kartice ili USB smart tokeni.

Da bi se dobio digitalni sertifikat, mora se prvo formirati zahtev za dobijanje sertifikata – certificate request, i da se dostavi određenom CA u cilju izdavanja digitalnog sertifikata. Ovaj zahtev sadrži sve lične informacije koje će se pojaviti i u vašem digitalnom sertifikatu.

Postoje generalno dva moguća načina generisanja para javnog i privatnog ključa i kreiranje digitalnog sertifikata na bazi javnog ključa:

CA generiše par javnog i privatnog ključa, formira digitalni sertifikat i dostavlja privatni ključ i sertifikat vlasniku,

Generisanje para javnog i privatnog ključa lokalno od strane samog vlasnika sertifikata korišćenjem hardverskih ili softverskih mehanizama. Zatim se izvrši kreiranje zahteva za izdavanjem sertifikata koji sadrži javni ključ vlasnika koji se šalje ka CA.

U okviru datog PKI sistema, politika rada po kojoj se izdaju sertifikati od strane CA određuje nivo poverenja koje će strane u komunikaciji imati u datom sertifikatu. To je publikovano u okviru osnovnih dokumenata sertifikacionog tela: Politika sertifikacije (Certificate Policy - CP ) i Praktična pravila rada (Certificate Practise Statement – CPS). Tako su definisane politike po kojima se izdaju sertifikati sa različitim nivoima pouzdanosti i, u skladu sa tim, definišu se različite metode registracije koje moraju biti primenjene u vezi lica koja zahtevaju sertifikate.

U stvari, proces registracije podrazumeva prikupljanje i odgovarajuću proveru različitih podataka od krajnjih korisnika, direktno u ličnom kontaktu ili u indirektnom udaljenom zahtevu preko gejtveja (na primer web pretraživačkog programa).

U smislu procesa registracije, politika sertifikacije PKI sistema detaljno definiše sledeće:

kako treba primeniti proces registracije, koje informacije o licima je potrebno proveriti ili zapisati, broj parova asimetričnih ključeva (i samim tim broj različitih sertifikata) koje

treba generisati za datog korisnika (tipično se različiti parovi ključeva generišu za digitalno potpisivanje i za digitalnu envelopu (šifrovanje)),

gde će se i na kom medijumu generisati ključevi; ključevi mogu biti generisani od strane samih korisnika, od strane RAO ili od strane CA, i mogu biti

80

sačuvani na hard disku, disketi, mini CD medijumu, smart kartici ili nekom drugom tokenu.

Format sertifikata koji treba da se generišu, Dodatne poslovne informacije koje treba da budu prikupljene za vreme

procesa registracije.

U stvari, postoje generalno dve opcije za generisanje asimetričnih ključeva (kod samog korisnika ili u CA) kao i dve opcije za registraciju (udaljena ili u ličnom kontaktu). Moguće je ostvariti više različitih kombinacija. U politici sertifikacije datog PKI sistema su definisane kombinacije koje su dozvoljene u datom PKI sistemu.

5.9.1 Registracija u ličnom kontaktu

Za određene PKI sisteme, direktne registracione procedure na bazi ličnog kontakta predstavljaju jedini bezbedni način za korektnu autentikaciju krajnjih korisnika i distribuciju i generisanje ključeva i sertifikata.

U Intranet okruženju, organizacija može da primeni politiku rada prema kojoj korisnici moraju lično da kontaktiraju osobu nadležnu za poslove bezbednosti (ili RAO) u cilju preuzimanja tokena ili smart kartice sa njihovim ključevima i sertifikatima. Ova registracija zahteva da korisnik pokaže ID karticu zaposlenih, ličnu kartu, vozačku dozvolu, pasoš ili neki drugi metod identifikacije.

U Internet okruženju, organizacije sa javnim poslovnicama, kao što su banke, pošte, itd., mogu zahtevati od korisnika da lično dođu u datu poslovnicu i daju svoje lične podatke.

Registracija ličnim kontaktom se odvija tako što službenik koji koristi aplikaciju RAO modula unese lične informacije korisnika i potvrdi zahtev za izdavanje sertifikata (svojim digitalnim potpisom). Ključevi se mogu generisati od strane same RAO aplikacije i sačuvani na disku u zaštićenom obliku putem lozinke izabrane od strane korisnika, ili korisnik može da generiše sopstvene ključeve, a da dostavi samo zahtev za izdavanje sertifikata do RAO modula. Ključevi se takođe mogu generisati i centralno u samom CA, ukoliko je tako predviđeno Politikom sertifikacije.

Određene RA aplikacije mogu koristiti i određene terminalne uređaje za akviziciju biometričkih podataka, kao što je fotografija, otisak prsta, glas, parametri zenice oka, itd., i da te netekstualne podatke takođe čuvaju u odgovarajućem obliku u bazi podataka.

Kada se izgeneriše digitalni sertifikat za datog korisnika, taj sertifikat može biti sačuvan na disketi, mini CD medijumu, hard disku, smart kartici ili na nekom drugom tokenu.

Proces izdavanja digitalnog sertifikata na bazi ličnog dolaska vlasnika u RA uobičajeno se sastoji iz sledećih koraka:

Budući vlasnik digitalnog sertifikata dostavlja RAO svoje podatke lično, RAO formira zahtev za izdavanje sertifikata na bazi dobijenih podataka,

81

RAO šalje kreirani zahtev do baze, označava ga kao procesirani i digitalno ga potpisuje,

RA uzima procesirani zahtev iz baze, verifikuje ga, digitalno potpisuje i šalje ga kao zaštićenu standardizovanu poruku putem TCP/IP konekcije do CA.

CA verifikuje dobijeni zahtev. Ukoliko je zahtev validan, CA izdaje i potpisuje digitalni sertifikat u X.509 standardnom formatu za dati zahtev i smešta ga u bazu podataka,

CA publikuje sertifikate na X.500/LDAP direktorijum. CA takođe periodično publikuje listu povučenih sertifikata (CRL – Certificate Revocation List) i listu povučenih autoriteta (ARL – Authority Revocation List). Sve liste koje se izdaju moraju biti digitalno potpisane. ARL se referiše na sertifikate samih PKI komponenata (samo CA, CAO, RA, RAO, itd.), dok se CRL odnosi na vlasnike digitalnih sertifikata u okviru datog PKI sistema.

CA šalje izdati sertifikat do RA preko TCP/IP. Digitalni sertifikat se sadrži u zaštićenoj (digitalno potpisanoj i šifrovanoj) standardizovanoj poruci.

RA verifikuje datu poruku, digitalno je potpisuje i pridružuje je bazi podataka, RAO preuzima izdati sertifikat iz baze, verifikuje ga i čuva ga u zahtevanom

formatu (PKCS#7, PKCS#12, ili drugi). RAO obezbeđuje dostavljanje digitalnog sertifikata vlasniku koji ga je tražio.

Prethodno navedeni proces predstavlja proces koji se sprovodi u slučaju da su CA, RA i RAO tradicionalno bazirane klijent-server aplikacije.

U slučaju da se radi o modernijim WEB višeslojnim CA sistemima, proces registracije korisnika se sastoji u sledećim koracima:

Budući vlasnik digitalnog sertifikata dostavlja RAO svoje podatke lično, RAO formira zahtev za izdavanje sertifikata na bazi dobijenih podataka, RAO digitalno potpisuje kreirani zahtev i šalje ga do CA (WEB server CA), CA (WEB server CA) verifikuje dobijeni zahtev. Ukoliko je zahtev validan, CA

izdaje i potpisuje digitalni sertifikat u X.509 standardnom formatu za dati zahtev i smešta ga u bazu podataka,

CA publikuje sertifikate na X.500/LDAP direktorijum. CA takođe periodično publikuje listu povučenih sertifikata (CRL – Certificate Revocation List) i listu povučenih autoriteta (ARL – Authority Revocation List). Sve liste koje se izdaju moraju biti digitalno potpisane. ARL se referiše na sertifikate samih PKI komponenata (samo CA, CAO, RA, RAO, itd.), dok se CRL odnosi na vlasnike digitalnih sertifikata u okviru datog PKI sistema.

CA šalje izdati sertifikat do RAO preko TCP/IP. Digitalni sertifikat se sadrži u zaštićenoj (digitalno potpisanoj i šifrovanoj) standardizovanoj poruci.

RA verifikuje datu poruku i obezbeđuje dostavljanje digitalnog sertifikata vlasniku koji ga je tražio.

Umesto prethodna dva koraka, moguće je da korisnik sam direktno dobavi sertifikat od strane CA.

5.9.2 Udaljena registracija

U mnogim slučajevima, zahteva se metoda registracije koja se ne oslanja na registraciju ličnim kontaktom. Najčešće, ove metode se primenjuju kada je korisnik udaljen od RA. U tom slučaju, omogućuje se registracija putem slanja zahteva za

82

izdavanje sertifikata korišćenjem Internet pretraživačkih programa i WEB komunikacije, e-mail servisa ili VPN konekcija.

Međutim, najčešće se u ove svrhe koristi metoda registracije korišćenjem WEB komunikacije. U tim slučajevima, korisnik svoj zahtev dostavlja do baze RA preko web komunikacije. Korišćenjem RAO modula se dati zahtev dalje procesira na isti način kao i u slučaju registracije putem ličnog kontakta. Alternativno, ako politika rada to dozvoljava, moguće je da RA bude konfigurisano tako da se dobijeni zahtevi automatski prosleđuju do CA, bez potvrđivanja od strane RAO.

Proces udaljene sertifikacije uobičajeno uključuje sledeće korake:

Budući vlasnik digitalnog sertifikata dostavlja zahtev za izdavanje sertifikata - certificate service request (CSR - obično u PKCS#10 formatu) do web servera CA (web sajt CA) preko TCP/IP mreže,

WEB server CA šalje dobijeni zahtev preko TCP/IP mreže do RA gde se dobijeni zahtev digitalno potpisuje i smešta u bazu podataka RA. Za ovu svrhu, postoji odgovarajuće RA na lokaciji CA,

Operator RA (RAO) preuzima dobijeni zahtev iz baze podataka i procesira ga, RAO zatim vraća procesirani zahtev nazad u bazu pri čemu ga prethodno

digitalno potpisuje i označava kao procesiranog, RA uzima procesirani zahtev iz baze, digitalno ga potpisuje i šalje ga kao

zaštićenu standardizovanu poruku preko TCP/IP konekcije do CA, CA verifikuje dobijeni zahtev. Ukoliko je zahtev validan, CA izdaje i potpisuje

digitalni sertifikat u X.509 standardnom formatu i smešta ga u bazu podataka, CA publikuje sertifikate na X.500/LDAP direktorijum. CA takođe periodično

publikuje listu povučenih sertifikata (CRL – Certificate Revocation List) i listu povučenih autoriteta (ARL – Authority Revocation List). Sve liste koje se izdaju moraju biti digitalno potpisane. ARL se referiše na sertifikate samih PKI komponenata (samo CA, CAO, RA, RAO, itd.), dok se CRL odnosi na vlasnike digitalnih sertifikata u okviru datog PKI sistema.

CA šalje izdati sertifikat do RA preko TCP/IP. Digitalni sertifikat se sadrži u zaštićenoj standardizovanoj poruci.

RA verifikuje datu poruku, digitalno je potpisuje i pridružuje je bazi podataka, RA uzima digitalni sertifikat iz svoje baze podataka i šalje ga do web servera

preko TCP/IP mreže. Web server omogućuje pristup digitalnom sertifikatu od strane vlasnika koji ga

je zahtevao. U zavisnosti od konfiguracije, digitalni sertifikat se čuva na određenom direktorijumu na hard disku a URL adresa se šalje elektronskom poštom vlasniku.

Prethodno navedeni proces predstavlja proces koji se sprovodi u slučaju da su CA, RA i RAO tradicionalno bazirane klijent-server aplikacije. U slučaju da se radi o modernijim WEB višeslojnim CA sistemima, proces registracije korisnika se vrši na sličan način s tim što jedino u okviru CA nema baze RA već centralni RAO zahteve za certifikatima direktno proverava i potvrđuje iz centralne baze CA.

83

5.10 Sistemi za distribuciju sertifikata

Distribucija sertifikata je jedna od osnovnih funkcija koje dati PKI sistem treba da realizuje na fleksibilan način. Postoje tri različita tipa distribucije sertifikata:

dostavljanje izdatih sertifikata do krajnjeg korisnika, publikovanje CA sertifikata, publikovanje izdatih i povučenih sertifikata krajnjih korisnika na odgovarajući

način (putem odgovarajućih direktorijuma) u cilju da budu dostupni svim drugim korisnicima, kao i svim zainteresovanim stranama.

Sve ovo treba da bude realizovano tako da bude u službi krajnjeg korisnika i da koristi organizacionoj infrastrukturi.

Sertifikati za krajnje korisnike moraju biti isporučeni licu koje je podnelo zahtev na način i u formatu koji odgovara njegovim potrebama. Na primer, sertifikati koji su zahtevani ličnim kontaktom mogu biti izdati bilo u softveru bilo na kriptografskom hardveru, kao na primer smart kartici. Sertifikati izdati na osnovu udaljenih zahteva uglavnom su distribuirani na isti način kao što su zahtevi i stigli, na primer WEB komunikacijom.

Sertifikat samog CA mora biti javan i raspoloživ koliko god je to moguće. Svaki korisnik u sistemu mora da poseduje sertifikat CA pre nego što počne da koristi servise datog PKI sistema. Sertifikat CA je neophodan da bi se verifikovao digitalni potpis sertifikata svih učesnika u sistemu – tj. da bi se proverila autentičnost veze između identiteta određenog učesnika u sistemu i njegovog javnog ključa asimetričnog kriptografskog sistema.

Sertifikat CA, kao i ostali izdati sertifikati u sistemu, mogu biti isporučivani u različitim formatima, kao i publikovani na X.500 ili LDAP direktorijumu. Takođe, sledeća lista formata za zapis sertifikata treba da bude podržana u sistemu: PEM; DER, PKCS#7 i PKCS#10.

Korišćenje direktorijuma može značajno poboljšati funkcionalnost sistema. Naime, u cilju šifrovanja poruke i njenog slanja u obliku digitalne envelope, neophodno je posedovati sertifikat namenjenog primaoca. Takođe, u cilju verifikacije digitalnog potpisa neke poruke, potrebno je imati sertifikat potpisnika i mogućnost da se izvrši validacija datog sertifikata (da li je u važećem roku i da li nije povučen). Zbog ovih razloga, obično se sertifikati i CRL smeštaju na direktorijum koji je raspoloživ svim ovlašćenim učesnicima u sistemu. Međutim, ne postoji obaveza CA da publikuje izdate sertifikate.

Sertifikati i CRL mogu biti publikovani i na WEB sajtu CA, raspoloživi preko OCSP servisa ili da budu distribuirani e-mail servisom do svih učesnika u sistemu, u zavisnosti od utvrđene politike rada CA.

84

5.11 Upravljanje životnim vekom sertifikata

U okviru Politike certifikacije datog sertifikacionog tela neophodno je specificirati procedure upravljanja životnim vekom certifikata, kao što su: povlačenje, obnavljanje i suspenzija. U nastavku su opisane pomenute procedure.

5.11.1 Obnavljanje sertifikata

Korisnički sertifikati važe ograničeni vremenski period, na primer godinu dana, što je propisano u okviru Politike certifikacije CA. Takođe može biti propisan period pre isteka perioda važnosti sertifikata kada će se u okviru aplikacije zaštite, dati korisnik automatski upozoriti da je blizu vreme isticanja validnosti sertifikata i da ga treba obnoviti. Ukoliko korisnici poseduju dva sertifikata čiji periodi validnosti ne moraju da se poklapaju, obnavljanje se vrši posebno za svaki od ta dva certifikata (dva serijska broja) koji su povezani istim registarskim brojem (unique ID) – jedinstvenim identifikatorom korisnika u datom sertifikacionom telu.

Potrebno je dodatno istaći da se obnavljanje mora izvršiti pre isteka roka važnosti sertifikata. Ako period važnosti certifikata istekne, moraju se generisati potpuno novi certifikati (novi ključevi) za datog korisnika. Takođe, treba istaći da se obnavljanje vrši tako da uvek bude izdat novi certifikat koji ima rok važnosti tačno godinu dana posle datuma obnavljanja, uz obezbeđenje da bude uvek validan. Dakle, obnavljanje se vrši na period od na primer 12 meseci od datume obnavljanja. Ovo se reguliše u okviru administratorske aplikacije CA.

5.11.2 Povlačenje sertifikata

Korisnički sertifikati se mogu povući (opozvati) iz generalno dva tipa razloga:

Došlo je do nekih promena informacija iz sertifikata za datog korisnika, Došlo je do gubitka asimetričnog privatnog kljča korisnika ili je iz bilo kog

razloga došlo do kompromitacije privatnog ključa datog korisnika.

U oba slučaja, korisnik je dužan da odmah prijavi CA ili RA nastalu promenu. Politikom sertifikacije su specificirani odgovarajući službenici CA (najčešće RAO i CAO) koji imaju pravo povlačenja sertifikata.

Potrebno je dodatno istaći da se povlačenje, kao i obnavljanje, ukoliko korisnik ima dva sertifikata uvek mora izvršiti za oba sertifikata koji su izdati.

5.11.3 Suspenzija sertifikata

Postoji mogućnost i privremene suspenzije sertifikata određenog korisnika koja se vrši ako je primenjena odgovarajuća suspenzivna mera pružanja usluga sertifikacije datom licu, ili zbog odlaska na duže odsustvo (možda čak i godišnji odmor).

Procedura suspenzije je praktično ista kao i procedura povlačenja sertifikata jer sertifikati fizički idu na CRL listu. Razlika je u tome što suspendovani sertifikati mogu

85

ponovo biti aktivni posle isteka suspenzije dok se jednom povučeni certifikati ne mogu nikada ponovo aktivirati. Proceduru suspenzije sertifikata uglavnom vrše ista lica kao i u slučaju povlačenja.

5.12 Lista povučenih sertifikata

Za vreme životnog veka sertifikata (obično je to period od jedne do pet godina) moguće je da se steknu razlozi da se dati sertifikat proglasi nevažećim i da se datom korisniku ne dozvoli pristup sistemu.

U tom smislu, povlačenje sertifikata se odnosi na praksu proglašavanja nevažećim javnog ključa datog korisnika, čime se automatski i njegov tajni ključ proglašava nevažećim i datom korisniku se tako onemogućava validno digitalno potpisivanje poruka.

Međutim, od suštinske je važnosti da informacija o povučenosti datog sertifikata bude što je moguće pre javno objavljena i dostupna svim učesnicima u sistemu (direktorijum, WEB sajt ili OCSP servis). Funkcija povlačenja sertifikata je u odgovornosti CAO, RAO, kao i samih krajnjih korisnika.

Obeležja PKI sistema koja podržavaju servis povlačenja sertifikata uključuju:

Kreiranje liste povučenih sertifikata (CRL) verzije 2, Kreiranje interfejsa za povlačenje sertifikata u okviru CAO i RAO, Obezbeđivanje da se, ako je to u skladu sa politikom rada CA, zahtevi za

povlačenjem sertifikata dostavljaju i od strane samih krajnjih korisnika, Publikovanje CRL na direktorijumu i korišćenje OCSP servisa, Korišćenje distributivnih tačaka za sertifikate (CDP – Certificate Distribution

Points) koje omogućavaju deljenje CRL na manje delove i stoga njihovo brže pretraživanje,

Korišćenje funkcije suspenzije sertifikata, umesto povlačenja jer se suspendovan sertifikat može ponovo učiniti validnim kasnije dok se jednom povučeni sertifikat ne može učiniti ponovo validnim nego se mora izdati novi sertifikat,

Zapisivanje razloga za povlačenje sertifikata što je omogućeno korišćenjem CRL verzija 2,

Periodično publikovanje CRL ili njeno ažuriranje sa svakom novom promenom u smislu dodavanja povučenih sertifikata. Vreme i učestanost ažuriranja CRL je propisano u Politici sertifikacije CA,

Zapisivanje vremena povlačenja sertifikata što je omogućeno korišćenjem CRL verzije 2,

Opciono uključivanje lozinki u politiku izdavanja sertifikata koje omogućavaju krajnjim korisnicima da povuku njihove sopstvene sertifikate.

Lista povučenih sertifikata (CRL – Certificate Revocation List) omogućuje klijentima i serverima, kao i drugim entitetima koji komuniciraju u datom PKI sistemu, proveru validnosti digitalnih sertifikata druge strane u komunikaciji.

CRL je binarna datoteka koja sadrži sledeće informacije:

86

Listu povučenih sertifikata sa razlogom njihovog povlačenja, Naziv izdavaoca CRL, Vreme kada je CRL izdato, Vreme kada će sledeća verzija CRL biti publikovana.

Veoma važno je istaći da u slučaju kada CA koje izdaje sertifikate istovremeno publikuje i CRL, tada je CRL digitalno potpisana od strane CA, čime se omogućuje svim korisnicima da budu sigurni u informacije koje CRL sadrži.

Pristup CRL i provera validnosti sertifikata se vrši kada je potrebno koristiti javni ključ iz PKI sertifikata određenog korisnika kome treba poslati šifrovanu poruku ili treba verifikovati digitalni potpis primljene poruke od strane tog korisnika.

Bilo koja od pomenutih aktivnosti treba da sadrži sledeće korake:

Proveriti validnost digitalnog sertifikata datog korisnika, Uzeti serijski broj sertifikata, Pristupiti (učitati) CRL (obično se to radi download-ovanjem sa X.500

direktorijuma korišćenjem LDAP pretrage i LDAP odgovora ili uzimanjem iz lokalno sačuvane CRL),

Proveriti digitalni potpis CRL, vreme njenog publikovanja i vreme kada će sledeća verzija biti publikovana,

Proveriti da li se dati sertifikat nalazi u CRL (na bazi serijskog broja), Alarmirati datog korisnika ako je sertifikat povučen, Izvršiti željenu kriptografsku aplikaciju ukoliko se sertifikat ne nalazi u CRL ili

ako namenjeni korisnik, nakon alarma, preduzme aktivnosti da njegov sertifikat ne bude više u CRL.

Uobičajeno, CA je odgovorno za neporecivost transakcija, obezbeđujući audit log datoteke i čuvajući sve publikovane verzije CRL.

Alternativno, korisnička aplikacija može realizovati mehanizme kojima se obezbeđuje neporecivost transakcija. Međutim, u tom slučaju, za svaku izvršenu transakciju, mora se čuvati sama poruka kao i CRL koje je korišćeno u trenutku kada je verifikovan digitalni potpis poruke (ili je poruka šifrovana javnim ključem korisnika). Jedino ste tada u mogućnosti da dokažete da ste koristili javni ključ namenjenog korisnika za verifikaciju ili šifrovanje u trenutku kada njegov digitalni sertifikat nije bio povučen.

Prednosti CRL:

CRL je široko podržana tehnologija u okviru PKI industrije, CRL može biti distribuirano do krajnjih korisnika na različite načine, uključujući

push i pull metodu, CRL može biti arhivirano da obezbedi neporecivost za prethodno izvršene

transakcije, CA izdaje i PKI sertifikate i CRL, Mnoge PKI aplikacije mogu dobiti CRL sa X.500 direktorijuma korišćenjem

DAP/LDAP protokola.

87

Prepoznata su sledeća ograničenja upotrebe CRL:

Korisnik mora imati tekuću verziju CRL u trenutku verifikacije digitalnog potpisa ili šifrovanja podataka. Pošto je CRL datoteka, korisnikova aplikacija mora obezbediti novu verziju CRL, ako je kopija na njegovom lokalnom sistemu zastarela. U velikom PKI okruženju, korisnik može imati potrebu da obezbeđuje CRL veoma često, a samo CRL može biti veoma veliko. Stoga, sve to može značajno usporiti rad neke PKI aplikacije zbog neophodnosti da se uvek obezbeđuje poslednja verzija CRL sa veoma zauzetog direktorijumskog servera (ili neke druge CRL distribucione tačke).

CRL se kreira i publikuje periodično, pri čemu je taj period određen Prakitčnim pravilom rada CA (CPS – Certificate Practice Statement). U sistemu je potrebno veoma studiozno evaluirati koliko često treba kreirati i publikovati CRL u okviru datog PKI sistema. Prečesto publikovanje CRL može zagušiti čitavu infrastrukturu, dok nedovoljno često publikovanje može rezultovati u potencijalnoj mogućnosti da se neki sertifikati koriste iako su već povučeni.

CA periodično kreira CRL datoteku na bazi primljenih zahteva za povlačenjem izdatih digitalnih sertifikata. Po kreiranju, CRL uključuje informacije od kada je CRL validna, do kada je validna i kada će se kreirati nova verzija CRL koja će zameniti prethodnu verziju. Kao što je ranije rečeno, CA digitalno potpisuje CRL tako da krajnji korisnici mogu biti sigurni u integritet i autentičnost informacija u okviru CRL.

Kada istekne važnost digitalnih sertifikata, njihov status u vezi povučenosti se više ne prikazuje u okviru CRL. Ova mera pomaže da se minimizuje veličina CRL za vreme rada datog CA a i smatra se da status povučenosti nema značaja za sertifikat kome je istekla važnost.

Pored procedure povlačenja sertifikata, postoji i još jedno specijalno stanje koje se naziva suspenzija sertifikata. Za razliku od jednom povučenog sertifikata, suspendovan sertifikat ima karakteristiku da ponovo može biti validan. CA obično suspenduje sertifikate kada postoji bilo kakva sumnja da je tajni ključ korisnika kompromitovan ili izgubljen. To takođe može biti veoma korisno stanje sertifikata u slučajevima kada je krajnji korisnik siguran da jedno vreme neće koristiti svoj tajni ključ.

Suspendujući svoj sertifikat, krajnji korisnik u stvari onemogućuje korišćenje svog tajnog ključa sve dok CA ne učini dati sertifikat ponovo validnim. Uslovi pod kojima se vrši suspenzija, prestanak suspenzije ili povlačenje sertifikata definisano je u CPS datog CA. Serijski broj suspendovanog sertifikata je uključen u CRL uz navedenu karakteristiku povlačenja: „suspendovan“. Ako je sertifikat ponovo validan, njegov serijski broj se briše iz naredne publikovane verzije CRL.

Profil CRL koji odgovara standardu X.509v2 (RFC 2459) definiše osnovni skup informacija koje se očekuju da budu sadržane u svakoj CRL. Pomenuti profil takođe definiše lokacije u okviru CRL za često korišćene atribute, kao i zajedničke reprezentacije tih atributa.

Prema pomenutom standardu, profil nazvan certificateList sadrži sledeća polja:

88

tbsCertList koje sadrži sledeće podatke:

o version – kada se koriste ekstenzije, kako je specificirano standardom X.509 v2 profilom, ovo polje mora postojati i mora specificirati verziju 2,

o signature – sadrži identifikator algoritma kojim se digitalno potpisuje CRL,

o issuer – predstavlja izdavaoca CRL (najčešće je to CA koje izdaje digitalne sertifikate),

o thisUpdate – ukazuje na datum publikovanja date CRL,o nextUpdate – ukazuje na datum kada će sledeća verzija CRL biti

publikovana. Nova verzija može biti publikovana i pre navedenog datuma, ali nikako kasnije od toga.

o RevokedCertificates – digitalni sertifikati povučeni od strane CA su jedinstveno identifikovani njihovim serijskim brojem. Vreme povlačenja i druge CRL ekstenzije su takođe definisane.

o CRLextensions – polje koje može biti korišćeno samo ako se radi o verziji 2 i sadrži dodatne atribute koji mogu biti od koristi, kao što su: redni broj CRL, distribucionu tačku, itd.

signatureAlgorithm – sadrži identifikator algoritma koji CA koristi za digitalno potpisivanje polja tbsCertList i mora sadržati isti algoritam kao i prethodno navedeno polje signature.

signatureValue – sadrži digitalni potpis polja tbsCertList kodovan po standardu ASN.1 DER.

CA je odgovorno za odgovarajuću distribuciju i raspoloživost CRL za okruženje koje opslužuje. Najčešće je to postignuto izlaganjem CRL na X.500 direktorijumskom serveru, kao tipičnom servisu podržanom od strane CA. Nakon toga je u odgovornosti krajnjeg korisnika, ili njegove softverske aplikacije, da preuzima CRL iz X.500 direktorijuma.

Postoje i alternativni načini distribucije CRL, kao što je slanje CRL svim korisnicima putem elektronske pošte (push metod) ili objavljivanje CRL na odgovarajućem WEB sajtu CA sa koga korisnici mogu preuzeti (download-ovati) CRL datoteku (pull metod kao što je i preuzimanje CRL sa X.500 direktorijumskog servera). Pomenute dve alternative su manje prisutne u PKI okruženju iz razloga pogodnosti X.500 pristupa i široke rasprostranjenosti primene LDAP komunikacionog protokola korišćenog za interakciju sa X.500 direktorijumom.

DAP (Directory Access Protocol) je jedan od četiri protokola definisanih u okviru X.500 standarda u cilju podrške otvorenim i standardizovanim direktorijumskim servisima. Direktorijum, u X.500 standardnom smislu, predstavlja specijalnu formu baze podataka koja je dizajnirana da bude posebno pogodna za korišćenje na Internet-u i drugim distribuiranim sistemima. X.500 standard definiše dve osnovne komponente direktorijuma:

Direktorijumski sistemski agent (DSA) – za upravljanje informacijama u okviru direktorijuma,

89

Direktorijumski korisnički agent (DUA) – korisnička aplikacija koja omogućuje korisnički pristup direktorijumskim servisima.

DAP definiše protokol komunikacije između DUA i DSA koji omogućuje uspostavu konekcije između klijentske aplikacije i direktorijuma, preuzimanje informacije iz direktorijuma i ažuriranje informacija unutar direktorijuma.

LDAP (Lightweight Directory Access Protocol) pojednostavljuje pristup direktorijumskim servisima koji su modelovani na bazi X.500 standarda. LDAP ima slične funkcije kao i DAP ali radi direktno na TCP/IP protokolu.

5.13 Opis procedure generisanja i zaštite asimetričnih ključeva Sertifikacionog tela

S obzirom da je CA srce čitavog PKI sistema, osnovni zahtev bezbednosti koji se postavlja pred PKI sistem je potpuna bezbednost samog CA. Ako je CA sistem kompromitovan internim ili eksternim napadom, i čitav PKI sistem je kompromitovan.

Konkretno, CA sistem mora da realizuje sledeće:

Potpunu bezbednost tajnih i privatnih ključeva CA, Da spreči napade spoljašnjih zlonamernih korisnika, Da obezbedi redudantnost sistema i obezbeđenje operativnosti (kontinuitet

poslovanja) u slučaju bilo kakve havarije, Da obezbedi personalnu identifikaciju svih aktivnosti koje se sprovode od

strane CAO i RAO.

Dakle, sistem bezbednosti CA treba da osigura potpunu bezbednost tajnih i privatnih ključeva, integritet podataka i konstatnu raspoloživost sistema.

Ove performanse sistema se ostvaruju primenom smart kartica za kontrolu pristupa važnim resursima sistema, za digitalno potpisivanje i zaštitu tajnosti poruka, kao i primenom hardverskih bezbednosnih modula (HSM – Hardware Security Module) za ostvarivanje bezbednosno najkritičnijih aplikacija u sistemu (generisanje privatnog ključa CA i digitalno potpisivanje sertifikata (izdavanje sertifikata), kao i za generisanje tajnih simetričnih ključeva).

U tom smislu, tajni ključevi CA i RA sistema, kao i njihovih operatora, treba da su zaštićeni kriptografskim mehanizmima najvišeg nivoa. Svi važni podaci korišćeni od strane CA i RA se čuvaju u bazama podataka, što olakšava primenu redudantnih mehanizama u cilju sprečavanja gubitka podataka.

Sve interakcije i razmene podataka između elemenata PKI sistema se digitalno potpisuju i šifruju u postupku digitalne envelope što osigurava nemogućnost pristupa datoj komunikaciji od strane zlonamernih korisnika.

Obeležja koja bi trebalo da su podržana od strane konkretnog CA sistema:

90

CA sistem treba da podrži korišćenje hardverskog bezbednosnog modula (HSM) za generisanje tajnog ključa samog CA, za bezbedno skladištenje podataka i za digitalno potpisivanje sertifikata.

Sistem treba da podrži korišćenje smart kartica za bezbedno čuvanje podataka, kontrolu pristupa i generisanje/distribuciju ključeva i sertifikata na svim ključnim tačkama datog PKI sistema.

Korišćenje standardnih poruka (u standardnom formatu) digitalno potpisane i šifrovane (digitalna envelopa) za svu komunikaciju između pojedinih elemenata i modula PKI sistema.

Svaki pristup bazama podataka treba da ima jedinstveni procesni broj. CA sistem treba da ima mogućnost da bezbedno arhivira korisničke parove

asimetričnih ključeva za šifrovanje u proceduri digitalne envelope u cilju omogućenja njihovog naknadnog oporavka u slučaju da je potrebno dešifrovati podatke koji su šifrovani pomoću ovih ključeva.

Potrebno je da dati PKI sistem prođe određenu zvaničnu sertifikaciju od strane ovlašćenih laboratorija za tu svrhu u smislu sposobnosti za realizaciju aktivnosti za koje je dati sistem namenjen.

Kao što je već rečeno, bezbednost PKI sistema je određena bezbednošću pre svega privatnog ključa CA, ali i svih ostalih tajnih ključeva koji se koriste u sistemu. Ovaj nivo bezbednosti se može ostvariti samo uz korišćenje odgovarajućeg kriptografskog hardvera kako na strani korisnika sistema, tako i na strani samih ključnih elemenata u sistemu.

U tom smislu, potrebno je koristiti smart kartice, kao kriptografski hardver prilagođen korišćenju za krajnje korisnike i za operatere u okviru PKI sistema, i hardverske kriptografske module (HSM), neophodne za korišćenje u serverskim aplikacijama i u samom CA sistemu.

U sistemima u kojima se zahteva najviši nivo bezbednosti, HSM moduli se predviđaju za korišćenje i na nivou RAO i CAO operatora. U cilju obezbeđenja funkcije neporecivosti u sistemu, potrebno je da krajnji korisnici svoj asimetrični par ključeva generišu i čuvaju na kriptografskom hardveru (smart kartici).

Drugim rečima, fundamentalni zahtev i svrha kriptografskog hardvera je da osigura da privatni ključ nikad ne napusti hardverski modul, u kom slučaju bi eventualno mogao biti kompromitovan.

5.13.1 Opšta obeležja HSM

Hardverski bezbednosni moduli, realizovani u vidu računarskih koprocesora, predstavljaju veoma bitnu karakteristiku savremenih rešenja zaštite računarskih mreža. Ovi moduli povećavaju performanse sistema tako što se vremenski kritične kriptografske funkcije izvršavaju na specijalizovanom hardveru a ne u softveru host računara.

Postojanje hardverskog koprocesorskog kriptografskog modula od suštinske je važnosti za realizaciju kvalitetnog i performantnog sistema zaštite, kao i za ispunjenje koncepta poverljive aplikacije u punom smislu.

91

Svi bezbednosni mehanizmi (kriptografski algoritmi i funkcije kontrole pristupa) smešteni su na hardverskom modulu i nikada se ne učitavaju u radnu memoriju korisnikovog računara.

Osnovne funkcije navedenih proizvoda su povećanje bezbednosti sistema i ubrzavanje kriptografskih funkcija, kao što su asimetrični i simetrični kriptografski algoritmi.

Primena HSM modula je neophodan uslov za bezbednu realizaciju funkcija Sertifikacionog tela.

HSM uređaji uglavnom realizuju standardne javne asimetrične i simetrične kriptografske i hash algoritme, kao što su: RSA, DSA, DES, 3-DES, RC2, RC4, SHA-1, MD2, MD5, itd.

Postoje eksterni kriptografski moduli, koji mogu imati bolje performanse u smislu brzine i zaštite velike količine podataka. Interni kriptografski moduli su optimalni u slučaju kriptografskih sistema koji koriste princip rada sa porukama i primenjuju tehnologije digitalnog potpisa.

Hardverski kriptografski koprocesori se predviđaju za korišćenje u serverskim aplikacijama i eventualno u klijentskim aplikacijama gde se zahteva visok nivo bezbednosti (državni organi, vojska, policija, SMIP, specijalizovane službe).

Sa druge strane, za najširi vid korišćenja sistema zaštite (npr. pojedinci), korišćenje smart kartica kao poverljive hardverske platforme je primerenije. U stvari, svi ti sistemi sa povišenim nivoom bezbednosti predstavljaju uglavnom kombinovane softversko-hardverske sisteme, pri čemu je hardverski deo ili koprocesor ili smart kartica.

Sistemi sa najvišim nivoom bezbednosti koriste kombinovani softversko-hardverski sistem koji se sastoji od softverske aplikacije, kriptografskog koprocesora za realizaciju kriptografskih algoritama i smart kartica, kao bezbednih nosioca ključeva i digitalnih certifikata.

Postoje i domaći HSM moduli. Uprošćena blok šema jednog domaćeg HSM modula je prikazana na slici 5.3.

92

NST2000

DSP

ISA или PCI интерфејс ка магистрали

Меморијски подсистем

Специјализо-вани I/O

контролер

Контрола тастатуре

Контрола читача

Генератор случајних бројева

Сат у ре

Тастатура

Читач smart картица

Real-time clock

Slika 5.3: Pojednostavljeni blok dijagram jednog domaćeg prototipa hardverskog koprocesorskog modula

HSM moduli u okviru sertifikacionih tela imaju sledeću funkcionalnost:

Generisanje ključeva na HSM – generisanje para ključeva asimetričnog kriptografskog algoritma, kao i zahtevanog broja simetričnih ključeva (opciono), realizuje se unutar HSM.

Bezbedno čuvanje kriptografskih parametara – ključevi i ostali kriptografski parametri se bezbedno čuvaju (u šifrovanom obliku) na HSM modulu.

Bezbedni back-up kriptografskog materijala – ključevi i drugi kriptografski parametri se mogu bezbedno sačuvati (back-up-ovati) na smart karticama ili drugim HSM modulima.

HSM mora realizovati funkciju detekcije pokušaja zlonamernog pristupa modulu (tamperproof) – modul treba da obezbedi detekciju zlonamernog pristupa i uništenje bezbednosnog materijala na modulu ako je detektovan pristup.

Modul mora biti sposoban da realizuje kriptografske funkcije – ovo je jedna od osnovnih namena HSM i ovi moduli su optimizovani za realizaciju funkcija generisanja ključeva, kao i realizaciju simetričnih i asimetričnih kriptografskih algoritama mnogo efikasnije nego u softveru ili na smart karticama.

Bezbedno korišćenje PIN broja – modul se aktivira unošenjem PIN broja.

93

5.13.2 Opšta obeležja smart kartica

Smart kartice nude značajno viši nivo bezbednosti u odnosu na samo softverska rešenja za realizaciju funkcija:

bilateralne autentikacije, digitalnog potpisa, bezbednog čuvanja tajnih podataka i logovanja na sistem.

S obzirom da poseduju memoriju koja je mikroprocesorski zaštićena od neautorizovanog pristupa, skladištenje osetljivih informacija kao što su kriptografski ključevi, digitalni sertifikati, lozinke i druge forme ličnih informacija na smart karticama je značajno bezbednije nego na drugim medijumima (kao na primer disketama ili mini CD medijumima).

Smart kartice takođe mogu realizovati asimetrične kriptografske algoritme za primenu digitalnog potpisa, kao i komercijalne simetrične algoritme. Iskustva iz savremenih Internet mreža pokazala su da su smart kartice neuporedivo bezbednije od softverskih sistema baziranih na standardnim lozinkama.

U savremenim računarskim mrežama predlažu se smart kartice za:

generisanje digitalnog potpisa, generisanje asimetričnih ključeva, za bezbednu identifikaciju subjekata i kao portabilni nosioci javnih i tajnih kriptografskih parametara.

Kartica sadrži javno dostupni deo i PIN (Personal Identification Number) kodom zaštićeni deo memorije u kojima se smeštaju kriptografski parametri.

Postoji nekoliko vrsta smart kartica:

Memorijske kartice, Mikroprocesorske smart kartice sa korišćenje PIN koda za pristup, Mikroprocesorske smart kartice sa PKI mogućnostima (generisanje i čuvanje

asimetričnih ključeva, digitalno potpisivanje).

Što se tiče tipa mikroprocesora implementiranih na smart karticama, ranije su to pretežno bili 8-bitni mikrokontroleri, i to najčešće iz klase Intel 80C51 mikrokontrolera, a sada su to 16-bitni i 32-bitni mikrokontroleri.

Jedan primer logičke arhitekture mikrokontrolera smart kartice koja ima PKI mogućnosti – digitalni potpis na samoj kartici (PKI smart kartica) je dat na Slici 5.4.

Ovaj čip je osmobitni čip i predstavlja jedan od ranije najzastupljenijih čipova koji su se koristili na smart karticama. U poslednje vreme su sve popularnije smart kartice bazirane na 16-bitnim i 32-bitnim mikrokontrolerima.

94

Slika 5.4: Primer arhitekture čipa mikroprocesorske smart kartice sa PKI mogućnostima – Phillips P8WE50xx familija kripto kontrolera

Ovi čipovi po pravilu poseduju dodatne kripto koprocesore za realizaciju asimetričnih kriptografskih algoritama – digitalno potpisivanje (na primer FameX kripto čip, kao najčešće korišćeni kriptokontroler za realizaciju asimetričnih kriptografskih algoritama u smart karticama) i za realizaciju simetričnih algoritama (DES-3 kripto koprocesor) za realizaciju zaštićene razmene podataka (secure messaging) između smart kartice i odgovarajućeg softvera na računaru (tzv. middleware).

Primena smart kartica umnogome zavisi od operativnog sistema implementiranog na primenjenom čipu, kao i od eventualnih preprogramiranih aplikacija. U odnosu na primenjene operativne sisteme, smart kartice se dele na:

smart kartice sa privatnim operativnim sistemom, Multos kartice i JAVA smart kartice.

Smart kartice sa privatnim operativnim sistemom su mnogo rasprostranjenije i njihove osnovne karakteristike su:

niska cena, mogućnost rada na jednostavnijim mikroprocesorima (8-bitnim), male mogućnosti prilagođenja (kastomizacije) implementiranih funkcija na

smart kartici i ove kartice su uglavnom jednoaplikativne kartice.

Sa druge strane, Multos i JAVA kartice nude veću mogućnost kastomizacije zahvaljujući postojanju Multos i JAVA virtualnih mašina koja izvršavaju na samoj

95

VSS VDD CLK

Power-On/OffReset

SecuritySensors

ResetGenerator

ClockInput Filter

80C51CPU

InterruptSystem

RAM

DataMemory

Timers

16 bit T0

16 bit T1

ROM

ProgramMemory

ROM

ProgramMemory

I/O1 I/O2

I/O

ProgrammableI/O

ISO - UART

I/O1 I/O2

I/O

ProgrammableI/O

ISO - UART

True RandomNumber Generator

True RandomNumber Generator

EEPROM

Data &ProgramMemory

EEPROM

Data &ProgramMemory

RSTRST

FameXPhase Driver

DES-3

Crypto coprocessor

Triple DES coprocessor

kartici Multos ALU-ove (Application Load Unit) i JAVA aplete definisane od strane korisnika.

Međutim, s obzirom da su se pojavile u skorije vreme, Multos i JAVA kartice mogu biti skuplje od “običnih” kartica i bolje rade na čipovima koji se baziraju na jačim mikroprocesorima (16-bitni i 32-bitni).

Multos i JAVA kartice su multiaplikativne kartice.

U smart kartičnoj industriji postoji nekoliko grupa učesnika:

proizvođači čipova, proizvođači operativnih sistema i aplikacija, proizvođači-integratori kompletne kartice (čip, plastika, implementacija čipa,

ugradnja operativnog sistema) i i sporučioci kompletnih sistema za masovnu produkciju i personalizaciju

(vizuelnu i logičku) smart kartica.

Neke kompanije su osposobljene za realizaciju više gore pomenutih operacija, a neke su specijalizovane samo za jednu operaciju. Tako na primer, NXP (Phillips), Infineon, Atmel, ST Microelectronics, Samsung, Renesas, itd. su tradicionalni proizvođači čipova, dok su: Gemalto, Oberthur, Giesecke & Devrient, Sagem-Orga, AustriaCard, itd. proizvođači operativnih sistema i aplikacija za smart kartice.

Posebno su od interesa kombinovane smart kartice (kontaktne i beskontaktne – imaju kontaktni čip i beskontaktni čip sa antenom) koje mogu, pored PKI primene za kriptozaštićene aplikacije (kontaktni čip), da se koriste i za kontrolu pristupa u određene prostorije u organizaciji, itd. (beskontaktni čip), tj. kao Corporate ID kartice koje bi služile kao identifikacione kartice, kao i uređaji za logičku i fizičku kontrolu pristupa. Najnoviji tip smart kartica su dual-interface kartice koje imaju jedan čip koja ima i kontaktni i beskontaktni interfejs.

U okviru PKI sistema, smart kartice imaju sledeću funkcionalnost i obeležja:

Generisanje ključeva na smart kartici – generisanje para ključeva asimetričnog kriptografskog algoritma realizuje se unutar smart kartice.

Bezbedno čuvanje kriptografskih parametara – ključevi se bezbedno čuvaju u zaštićenom delu memorije smart kartice i ne postoji mogućnost da asimetrični ključ generisan na kartici bude iščitan sa kartice.

Generisanje digitalnog potpisa na samoj kartici, Smart kartice su same po sebi tamperproof moduli (ne može se neovlašćeno

iščitati sadržaj smart kartica, tj. PIN kodom zaštićene memorije).

Kod primene smart kartica, neophodno je posedovati sledeće:

smart karticu sa čipom koji omogućava primenu asimetričnih kriptoalgoritama (na primer RSA – RSA koprocesor u samom čipu smart kartice),

instaliranu PKI aplikaciju na samoj smart kartici koja prihvata veći broj parova asimetrični privatni ključ – sertifikat (ova aplikacija obično automatski dolazi sa smart karticom),

96

čitač smart kartica koji ima instaliran odgovarajući drajver na računaru, middleware softver koji obezbeđuje proizvođač operativnog sistema smart

kartica (može biti od samog proizvođača ili od neke treće strane koja je angažovana od strane proizvođača) koji se sastoji, između ostalog, i od:

o CSP (Cryptographic Service Provider) za rad sa datom karticom iz Microsoft baziranih aplikacija,

o PKCS#11 biblioteke za rad sa karticom iz aplikacija koje ne koriste Microsoft komponente (MS CAPI),

o Neke vrste Token manager-a koji služi za administraciju kartice (pregled sadržaja kartice, PIN i PUK administracija, brisanje objekata, itd.).

Za potrebe konkretnog projekta u okviru informacionog sistema Organizaciji, pored MS Enterprise Root CA koje je domenski integrisano (Active Directory) i koje izdaje sertifikate korisnicima na bazi asimetričnog para ključeva koji je izgenerisan na samoj smart kartici korisnika, neophodno je na svakoj radnoj stanici u sistemu instalirati čitač smart kartica i odgovarajući middleware za datu karticu koja.

5.14 Server za arhiviranje ključeva

PKI sistem treba da bude sposoban da se oporavi u smislu pune funkcionalnosti u slučaju sistemskih ili komunikacionih oštećenja koja se mogu desiti u korišćenju. Dakle, potrebno je da sistem ima realizovanu strategiju oporavka i neometanog daljeg rada u slučaju oštećenja prouzrokovanog višom silom.

Uglavnom su dva osnovna kritična elementa PKI sistema: privatni i tajni ključevi, kao i baza podataka. Ukoliko se realizuje pouzdana back-up funkcija ovih elemenata, čitav PKI sistem će biti sposoban da se kompletno oporavi i da se vrati u prethodno stanje.

Interna baza podataka PKI sistema (baza podataka CA i RA) koristi se uglavnom:

Za čuvanje svih zahteva za izdavanje sertifikata, izdatih sertifikata i CRL, Kao baza za razmenu poruka između CA i RA, Za čuvanje log fajlova u čitavom sistemu i svih aktivnosti koje su realizovane

od strane operatora, Za čuvanje detalja o registracionim politikama, Za čuvanje registracionih informacija koje nisu uključene u sertifikate (kao na

primer atributi definisani od strane samih korisnika, skenirane fotografije, biometrički podaci, itd.), ...

Bezbednost čitavog sistema je ojačana tako što je svaki unos u bazu, ili postupak čitanja, digitalno potpisan uz pomoć privatnog ključa određenog procesa ili operatora koji je datu transakciju uradio. Pored toga, svaki zahtev za izdavanje sertifikata poseduje pridruženi identifikacioni broj transakcije, koji se koristi tokom procesiranja datog zahteva u datom PKI sistemu.

97

Korišćenje postupka digitalne envelope znači da šifrovanu informaciju može pročitati samo korisnik kome je ta informacija namenjena.

Svaka organizacija koja svoju bezbednost bazira na PKI sistemu želi da bude sposobna i da može naknadno, u izuzetnim slučajevima, da dešifruje neke podatke. U tom smislu, ne sme se dopustiti da privatni asimetrični ključevi, kojima se jedino mogu dešifrovati simetrični ključevi, kojima su šifrovane određene poruke, izgube jer su tada izgubljene i te šifrovane poruke. Ovaj zahtev povlači za sobom sledeće:

Važnim podacima firme, koji su šifrovani i namenjeni nekom službeniku, ne može se pristupiti ukoliko dati službenik u tom trenutku nije prisutan,

Podaci se ne mogu dešifrovati ako je tajni ključ izgubljen ili oštećen, Podaci se ne mogu dešifrovati ako je lozinka zaboravljena, Krajnji korisnici mogu biti onda demotivisani (ili u strahu) da šifruju važne

podatke plašeći se da ti podaci kasnije neće moći biti dešifrovani.

Navedeni problemi se mogu razrešiti ako bi se kopije tajnih ključeva čuvale na bezbednom mestu. To bi omogućilo oporavak u svakom trenutku šifrovanih podataka.

Međutim, to bi takođe omogućilo verovatnoću pronevere digitalnih potpisa od strane zlonamerne osobe koja ima pristup bazi tajnih ključeva. To je neprihvatljivo sa stanovišta postizanja funkcije neporecivosti u sistemu.

Ovi problemi se na zadovoljavajući način mogu rešiti tako što se u sistemu omogući korisnicima da imaju više parova asimetričnih ključeva, a posledično i više sertifikata (po jedan sertifikat na svaki par ključeva). Jedan par ključeva treba da bude za šifrovanje, a drugi za digitalno potpisivanje.

Najprihvatljivija šema sa svih aspekata je da par ključeva za digitalno potpisivanje generiše sam korisnik, po mogućstvu na kriptografskom hardveru (smart kartici) koji obezbeđuje funkciju neporecivosti, a da par ključeva za šifrovanje (digitalnu envelopu) generiše CA za datog korisnika i da mu ih dostavlja. U tom slučaju, CA može čuvati kopiju privatnog ključa za šifrovanje na serveru za arhiviranje podataka, što omogućuje potpun oporavak šifrovanih podataka (ukoliko na primer korisnik izgubi smart karticu), bez uticaja na funkciju neporecivosti datog korisnika.

Server za arhiviranje ključeva (Arhiv Server (AS)) ima funkciju da bezbedno uskladišti privatne ključeve asimetričnog kriptografskog sistema krajnjih korisnika koji se primenjuju u okviru postupka digitalne envelope. Ova funkcija omogućuje kasniji oporavak datih ključeva, kao i eventualnog dešifrovanja šifrovanih poruka (postupkom digitalne envelope), u slučajevima gubitka ili oštećenja ključeva, ili u slučajevima kada određeni autoritet nalaže dešifrovanje poruka (u sudskim ili arbitražnim procesima, itd.).

Ključevi se čuvaju na serveru za arhiviranje ključeva jedino u slučaju da je to izričito predviđeno politikom rada PKI sistema.

98

5.14.1 Funkcionalnost servera za arhiviranje ključeva

Server za arhiviranje ključeva šifruje privatni ključ koga treba uskladištiti primenom određenog simetričnog algoritma sa odgovarajućim DEK (Data Encipherement Key) ključem, jedinstvenim za svaki privatni ključ koji se arhivira. Tako šifrovani privatni ključ se smešta u posebnu bazu podataka (AS baza podataka).

DEK ključ se takođe šifruje posebnim simetričnim algoritmom i posebnim ključem i takođe se smešta u bazu podataka.

Digitalno potpisivanje poruka – sve poruke poslate od strane arhiv servera su digitalno potpisane.

Verifikacija poruka – sve digitalno potpisane poruke koje arhiv server dobija se procesiraju u smislu verifikacije digitalnog potpisa u cilju provere autentičnosti potpisnika i integriteta sadržaja poruke.

Arhiviranje podataka – svi podaci i log fajlovi se arhiviraju u AS bazi podataka. Sve arhivirane informacije su digitalno potpisane od strane AS. Svaki ulazni slog ima jedinstveni procesni broj.

5.14.2 Obeležja Arhiv servera

Poseduje grafički interfejs jednostavan za korišćenje sa interfejsom koji se može prilagoditi korisnikovim potrebama.

Arhiv server treba da podrži različite hardverske elemente, kao što su: smart kartice, hardverske bezbednosne module (HSM – Hardware Security Module), kao i druge tokene.

5.15 Standardi koji se odnose na funkcionisanje PKI sistema

Standardi koji se odnose na funkcionisanje PKI sistema neophodni su za definisanje:

Procedure registracije subjekata, Formata sertifikata, Formata lista opozvanih sertifikata, Formata poruka pri registraciji (zahtevi i odobrenja izdavanja sertifikata), Formata digitalnih sertifikata, Autentikacionih protokola.

Najvažnije telo zaduženo za interoperabilnost PKI standarda je PKI radna grupa IETF (Internet Engineering Task Force) organizacije, poznata i kao PKIX grupa (nastalo od “PKI for X.509 certificates”). PKIX specifikacija se bazira na dve grupe standarda:

ITU-T X.509 standardi PKCS standardi definisani od strane RSA Data Security

Ošteprihvaćeni i najviše korišćen standard koji podržava PKI sisteme je ITU-T X.509 čija osnovna svrha je u definisanju standardnog formata digitalnih sertifikata. Verzija

99

3 ovog standarda koja je trenutno važeća, usvojena je 1996. godine. Međutim, ovaj standard nije namenjen za definisanje kompletnih funkcija PKI sistema.

Standardom X509 definisana je struktura, postupak dobijanja i način predstavljanja sertifikata. Struktura sertifikata opisuje se korišćenjem ASN.1 metoda za opisivanje apstraktnih tipova.

U nastavku će biti navedene njegove osnovne karakteristike i struktura sertifikata koja je u skladu sa ovom notacijom. Softverski sistem za proizvodnju digitalnih sertifikata koristi ASN.1 notaciju za opis strukture sertifikata.

5.15.1 Abstract sintax notation one - ASN.1

Open System Interconnections (OSI) je standard kojim su definisana pravila za međusobno povezivanje računarskih sistema i to od osnovnog, fizičkog nivoa, do aplikativnog nivoa. Da bi standard bio nezavistan od implementacionih karakteristika pojedinačnih sistema objekti se opisuju na apstraktan način, kroz podatke koje sadrže, servise koje pružaju i komunikacione interfejse prema spoljašnjoj sredini. Sistem koji se primenjuje u OSI definisan je standardom X.208 i poznat je pod imenom Abstract Syntax Notation One (ASN.1).

Abstract Syntax Notation One je metod za opisivanje apstraktnih tipova podataka i način za kodiranje vrednosti nekog tipa definisanog ovom metodom. Prema ovom standardu tip je definisan skupom svojih vrednosti i postoje četiri osnovna oblika tipova:

Prosti tipovi, predstavljaju skupove osnovnih vrednosti, Strukturni tipovi koji se sastoje od komponenti, Vezani tipovi, oni se izvode iz drugih tipova, Ostali tipovi.

Tipovi i njihove vrednosti mogu se imenovati i ta se imena mogu koristiti u definisanju drugih tipova i vrednosti. Operator dodeljivanja se označava sa . Svaki ASN.1 tip (osim CHOICE i ANY) određen je pripadnošću klasi i jednim nenegativnim brojem. Postoje četiri klase:

Univerzalna, za tipove čije je značenje isto nezavisno od aplikacije, Aplikativna, za tipove kod kojih je značenje definisano unutar aplikacije, Privatne za tipove čije značenje je vezano za lokalno okruženje, Konteksno-zavisna za tipove čije je značenje specifično u okviru strukturnih

tipova.

Dva tipa se smatraju jednakim ako i samo ako pripadaju istoj klasi i imaju isti broj. Ovim mehanizmom se može opisati svaki apstraktni tip podataka.

Sledeće pitanje adresirano ovim standardom je način predstavljanja vrednosti apstraktno definisanog tipa. To pitanje se razrešava formulisanjem osnovnih pravila za kodiranje, Basic Encoding Rules (BER), kojima se svaka ASN.1 vrednost predstavlja kao niz bajtova. Ovaj, osnovni način kodiranja, nije jednoznačan tj. ista vrednost se može kodirati na više različitih načina. Načini kodiranja su sledeći:

100

Primitivni - sa unapred poznatom dužinom podatka, Konstruktivni - sa unapred poznatom dužinom podatka, Konstruktivni - sa nepoznatom dužinom podatka.

Kod vrednosti nekog tipa sastoji se od najmanje prva tri bloka, od sledeća četiri:

Identifikacioni deo - kojim se jednoznačno određuje tip podatka (klasa i broj), metod kodiranja (primitivni ili kostruktivni),

Specifikacija dužine podatka - kojom se kod podataka sa određenom dužinom specificira broj bajtova za registrovanje podatka ili, ako dužina nije unapred poznata, sadrži kod kojim se ta situacija identifikuje,

Sadržaj - niz bajtova kojim se reprezentuje vrednost, Oznaka za kraj podatka - ukoliko nije unapred poznate dužine.

Napomenuli smo ranije da BER kodiranje nije jednoznačno što može izazivati probleme u situacijama kada je jednoznačnost zahtevana osobina. Zbog toga je formulisan niz ograničenja na pravila BER kodiranja tako da se postigne jednoznačnost u kodiranju vrednosti nekog ASN.1 tipa.

Taj restriktivni skup pravila se označava sa DER (Distinguished Encoding Rules). Grubo govoreći, jednoznačnost se postiže zahtevajući da kod vrednosti bude minimalan u pogledu dužine (broja bajtova).

Dakle, ovim sistemom smo u mogućnosti da opišemo i predstavimo vrednost proizvoljnog apstraktnog tipa.

5.15.2 ITU X.509 v3 sertifikat-struktura

Prema ovom standardu sertifikat se sastoji od tri dela. Prvi deo čine podaci značajni za sam sertifikat predstavljeni promenljivom tbsCertificate, drugi deo predstavlja identifikator algoritma za potpisivanje predstavljen promenljivom signatureAlgorithm i na kraju sam potpis predstavljen promenljivom signature.

Promenljiva tbsCertificate je strukturnog tipa i sadrži sledeća polja:

Verzija – označava verziju standarda koja je primenjena pri generisanju sertifikata,

Serijski broj – redni broj izdatog sertifikata. Način dodeljivanja brojeva mora biti jedinstven tj. ime izdavača sertifikata i redni broj sertifikata jedinstveno određuju sertifikat,

Potpis – sadrži identifikator algoritma kojim izdavač sertifikata vrši potpis sertifikata,

Validnost – specificira se period unutar kojeg se sertifikat smatra važećim ako nije opozvan,

Vlasnik sertifikata – identifikator (ime) vlasnika sertifikata kome se pridružuje javni ključ koji sadrži sertifikat,

Javni ključ – javni ključ vlasnika sertifikata i identifikator algoritma za koji je namenjen,

101

Jedinstveni identifikatori – polje koje omogućava ponovnu upotrebu imena prisutnih u sertifikatu,

Polje dodatnih informacija – sadrži skup polja koja po potrebi mogu nositi još neke informacije osim ovih osnovnih. Neke od ovih dodatnih informacija mogu nositi atribut CRITICAL ili NONCRITICAL. Ukoliko aplikacija koja barata sertifikatom naiđe na informaciju označenu sa CRITICAL i ne raspozna je, mora sertifikat odbaciti kao neispravan.

Polje dodatnih informacija može sadržati informacije pomoću kojih se identifikuje javni ključ kojim se sertifikat proverava, ukoliko izdavač ima više parova javnih i privatnih ključeva. Zatim informacije o nameni javnog ključa koji sertifikat sadrži, opis uslova pod kojima je sertifikat dobijen i pod kojim se i zašta može koristiti, alternativna imena izdavača i vlasnika sertifikata.

Prema dosadašnjim iskustvima ovakva struktura sertifikata ispunjava sve zahteve koje je praksa postavila.

5.15.3 ITU X.509 v2 lista opozvanih sertifikata

Prema ovom standardu lista opozvanih sertifikata se sastoji od tri dela. Prvi deo čini lista opozvanih sertifikata predstavljena promenljivom tbsCertList, drugi deo predstavlja identifikator algoritma za potpisivanje liste opozvanih sertifikata predstavljen promenljivom signatureAlgorithm i na kraju sam potpis predstavljen promenljivom signature.

Promenljiva tbsCertList je strukturnog tipa i sadrži sledeća polja:

Verzija – označava verziju standarda koja je primenjena pri generisanju liste opozvanih sertifikata,

Potpis – sadrži identifikator algoritma kojim izdavač liste opozvanih sertifikata vrši potpis liste opozvanih sertifikata,

Ime izdavača liste – identifikuje izdavača liste, Datum izdavanja tekuće liste opozvanih sertifikata, Datum sledećeg ažuriranja liste opozvanih sertifikata, Spisak opozvanih sertifikata, Polje dodatnih informacija.

Spisak opozvanih sertifikata se sastoji od niza rednih brojeva sertifikata koji zajedno sa identifikatorom izdavača sertifikata na jedinstven način određuju opozvani sertifikat.

5.15.4 X.509 v2 lista opozvanih sertifikata - formiranje

Izdavač sertifikata registruje i formira zahteve za opoziv sertifikata shodno svojoj politici, formira novu listu opozvanih sertifikata. Zatim se kao i kod generisanja sertifikata od BER koda korišćenjem dogovorenih algoritama formira otisak i potpis liste opozvanih sertifikata.

102

U cilju dodatne standardizacione podrške X.509 standardu, proizvođači, korisnici i komiteti za standarde su se uglavnom okrenuli korišćenju de facto PKI standarda, definisanih u PKCS (Public Key Cryptographic Standards).

PKCS predstavlja seriju standarda koji pokrivaju funkcije PKI sistema u oblastima registracije, obnavljanja izdatih digitalnih sertifikata i distribucije lista opozvanih sertifikata.

Za interoperabilnost PKI sistema, najvažnija su sledeća četiri PKCS standarda:

PKCS#1 standard za opis realizacije procedura digitalnog potpisivanja i digitalne envelope na bazi RSA asimetričnog kriptografskog algoritma.

PKCS#7 standard za sintaksu kriptografskih poruka (Cryptographic Message Syntax Standard),

PKCS#10 standard za sintaksu zahteva za izdavanje digitalnog sertifikata (Certificate Request Syntax Standard),

PKCS#12 standard za sintaksu razmene ličnih informacija (Personal Information Exchange Syntax Standard).

5.16 Tipovi Sertifikacionih tela i mogući načini realizacije

Postoji nekoliko tipova CA, od kojih su četiri tipa najznačajnija:

Pojedinačna CA određenih preduzeća (corporate CA), CA zatvorenih grupa korisnika, CA vertikalnih industrija (finansijski sistemi, medicina, telekom, ...), Javna CA (domaća – internacionalna).

Što se tiče načina realizacije CA, postoje generalno tri načina:

Korišćenje usluga postojećeg CA (outsourced CA), Izgradnja sopstvenog CA u okviru date organizacije na bazi inostrane CA

tehnologije (insourced CA), Izgradnja sopstvenog CA u okviru date organizacije na bazi domaće CA

tehnologije (insourced CA).

Prva varijanta predstavlja najpovoljnije rešenje za kompaniju koja želi da implementira PKI tehnologiju isključivo u svojoj organizaciji (za svoje zaposlene i saradnike) a ne želi da investira previše u rešenje CA. U tom smislu, određene organizacije koje predstavljaju javna međunarodna CA (kao što su GlobalSign i VeriSign) nude outsourced CA rešenje u kome oni praktično izdaju digitalne sertifikate korisnicima date organizacije, koja u tom slučaju igra ulogu RA.

Međutim, ukoliko organizacija pretenduje da ima određene ekonomske koristi od javne prodaje digitalnih sertifikata zainteresovanim korisnicima iz njihovog domena, tada su prikladnije druge dve varijante realizacije CA. To rešenje je onda značajno skuplje od prvo pomenutog rešenja outsourced CA.

103

Od dve navedene insourced varijante, varijanta koja podrazumeva stranu CA tehnologiju je sigurno skuplja nego varijanta sa domaćom tehnologijom. Sa druge strane, realizacija CA sa domaćom tehnologijom omogućuje adaptivnost i skalabilnost rešenja u skladu sa definisanom politikom korisnika.

5.17 Generički model realizacije CA kao softverskog-hardverskog sistema za generisanje digitalnih sertifikata

Kao što je ranije više puta rečeno, u okviru realizacije kompletnog PKI sistema, ključna je realizacija softversko-hardverskog sistema CA za generisanje digitalnih sertifikata i odgovarajućih kriptografskih ključeva.

Osnovne karakteristike jednog mogućeg sistema (generički model) za generisanje digitalnih sertifikata i odgovarajućih ključeva su:

Realizovan u skladu sa važećim svetskim standardima, Primenjen X.509 v3 standard za sertifikate, Primenjen X.509 v2 standard za liste opozvanih sertifikata, PKCS standardi – najnovije verzije, Modularna realizacija, Fleksibilnost – prilagodljivost potrebama korisnika, Crypto Bezbedan sistem – primena najnovijih rezultata iz oblasti generisanja

kriptografskih ključeva i primene kriptografskih algoritama.

Kao jedan primer centralnog sistemskog okruženja CA, navešćemo uprošćenu blok šemu prikazanu na slici 5.4, kao primer CA koje predstavlja višeslojnu WEB aplikaciju.

104

Firewall

WEB server CA

ЦАО Baza podataka

CA

Crypto engine CA

HSM

Interna mreža CA – OnLine CA

Sistem CA

LDAP server

Ruter

Eksterna mreža

DMZ zona

Aplikativni server CA Root CA

HSM

Root CA – OffLine CA

Slika 5.4: Uprošćena blok šema WEB baziranog sertifikacionog tela

Kao što se vidi sa slike 5.4, sertifikaciono telo se sastoji od OnLine i OffLine dela. OffLine deo predstavlja RootCA koje se koristi samo u izuetnim slučajevima kada se formira asimetrični privatni ključ i sertifikat za novi Intermediate CA u hijerarhijskoj strukturi, slika 5.5, koja preovladava u savremenim PKI sistemima.

Root CA se nalazi u potpuno odvojenoj prostoriji od ostalog dela CA i u njemu postoji trezor u kome se čuvaju delovi za aktivaciju privatnog ključa Root CA koji se propisanom procedurom distribuirane odgovornosti koriste u slučajevima generisanja novog Intermediate sertifikacionog tela (ta procedura se naziva „CA ceremonija“).

U proceduri CA ceremonije, potrebno je da prisustvuje odgovarajući minimalan broj specijalnih službenika CA koji imaju pristup pojedinim delovima za aktivaciju privatnog ključa, koji se čuvaju u posebnim pretincima u trezoru i to najčešće u obliku smart kartica.

Dakle, odgovarajući broj smart kartica mora biti prisutno da bi se u HSM uređaju Root CA mogao aktivirati privatni ključ Root CA u skladu sa Praktičnim pravilima rada sertifikacionog tela.

105

Root CA

Intermediate CA Intermediate CA Intermediate CA

Intermediate CA Intermediate CA Intermediate CA …

Slika 5.5: Hijerarhijska struktura sertifikacionih tela

Nakon toga se u HSM uređaju izvrši generisanje asimetričnog para ključeva za novi Intermediate CA i izgeneriše se njegov sertifikat primenom digitalnog potpisa na bazi privatnog ključa Root CA. Tako dobijenim privatnim ključem i sertifikatom isprogramira se najčešće smart kartica Intermediate CA koja se zatim postavi u HSM uređaj novog, posebno za taj Intermediate CA obezbeđenog, Crypto Engine servera.

Alternativno rešenje je da se asimetrični par ključeva intermediate CA izgeneriše u okviru HSM uređaja a zatim se javni ključ u obliku PKCS#10 zahteva za izdavanjem sertifikata ručno prenese na root CA konzolu gde se izgeneriše sertifikat koji se zatim vrati i dowload-uje na HSM uređaj intermediate CA.

Zatim se obriše privatni ključ Root CA iz HSM uređaja i specijalne smart kartice sa delovima za aktivaciju privatnog ključa se vrate u trezor.

Dakle, kao što se može zaključiti, moguće je da istovremeno rade više Intermediate CA u OnLine modu rada, tj. da više Intermediate CA Crypto Engine servera bude aktivirano u OnLine rad generisanja digitalnih sertifikata.

OnLine procedura se odvija na sledeći način. Zahtevi za izdavanjem sertifikata čiji je digitalni potpis uspešno proveren od strane WEB servera CA (bilo da se radi o samopotpisanim zahtevima (PKCS#10 format) koje su korisnici dostavili direktno do WEB servera CA ili su to zahtevi potpisani od strane odgovarajućeg RAO u okviru RA gde je korisnik fizički došao da mu se izda sertifikat) se od strane aplikativnog servera CA upučuju do odgovarajućeg Intermediate CA Crypto Engine servera iz kog domena je dati korisnik.

Na datom Crypto Engine serveru (u okviru HSM uređaja datog servera) izvrši se formiranje digitalnog sertifikata (u slučaju samopotpisanog zahteva) ili se izvrši generisanje asimetričnog para ključeva i formiranje digitalnog sertifikata za datog korisnika. Ovi podaci se vraćaju aplikativnom serveru koji ih smešta u bazu podataka CA i šalje ih na odgovarajuči način direktno korisniku ili u RA gde je korisnik podneo zahtev.

106

U DMZ zoni sistema CA se, pored WEB servera CA, nalazi i LDAP server koji služi za publikovanje CRL i ARL lista, kao i eventualno za publikaciju izdatih digitalnih sertifikata.

Potrebno je istaći da navedeni primer realizacije sistema CA predstavlja samo jedan mogući način realizacije i da se realne realizacije sistema više ili manje razlikuju u domenima načina generisanja ključeva za korisnike, načinu distribucije ključeva i sertifikata, kao i u načinu publikacije CRL liste. Međutim, i pored razlika, osnovni principi i koncepti savremenih sertifikacionih tela se poklapaju sa navedenim primerom.

5.18 Organizacioni aspekti funkcionisanja PKI sistema

U strukturi PKI sistema datog informacionog sistema, CA predstavlja tačku najvišeg poverenja, ali istovremeno i tačku najvišeg rizika. Osnovni i najvažniji zahtev koji se postavlja pred CA je čuvanje tajnosti privatnog ključa CA za primenu asimetričnog kriptografskog algoritma kojim se vrši digitalni potpis izdatih digitalnih sertifikata, i čuvanje tajnosti ostalih kriptografskih ključeva koji se dodeljuju ovlašćenim učesnicima u informacionom sistemu.

Stoga se, pored kriptografskih tehnika, moraju primeniti i druge mere iz oblasti fizičke i organizacione zaštite kako bi se ostvarila sveukupna bezbednost PKI sistema. Pomenute mere se odnose na prostorije, zaposlena lica i uređaje.

5.18.1 Bezbednosne procedure u odnosu na ljudski faktor

Ovlašćena lica CA odgovorna su za uspostavu i kontrolu funckionisanja celokupnog PKI sistema. U njihovoj odgovornosti je formiranje digitalnih sertifikata, sprovođenje svih procedura rad u CA i RA propisanih u okviru politike sertifikacije CA, kao i politike zaštite celokupnog informacionog sistema.

Prilikom izbora kadra koji će biti zaposlen na poslovima iz nadležnosti CA, moraju se sprovesti odgovarajuće bezbednosne provere, imajući u vidu potencijalnu štetu koju nesavesna lica mogu da naprave. Slični zahtevi, u blažoj formi, treba da budu primenjeni za lica iz sastava RA, kao i na administratore zaštite. Najviši bezbednosni zahtevi postavljaju se pred službenike koji se bave proizvodnjom ključeva i generisanjem digitalnih sertifikata, kao i personalizacijom smart kartica.

Kao što je već rečeno, privatni ključ CA za primenu asimetričnog kriptografskog algoritma kojim se vrši digitalni potpis izdatih digitalnih sertifikata predstavlja podatak najvišeg stepena tajnosti. Korišćenje ovog ključa ne sme biti u nadležnosti samo jedne osobe, već se mora primeniti princip raspodele odgovornosti na minimalno dva ovlašćena lica. Ova lica poseduju specijalne smart kartice na kojima se nalaze delovi pomenutog tajnog ključa. Po principu raspodele odgovornosti, validan digitalni sertifikat se može izdati tek ako se od tajnih podataka sa obe kartice formira potpuni podatak za aktivaciju privatnog ključa CA za primenu digitalnog potpisa.

107

U svakom slučaju, u okviru informacionog sistema u koga treba ugraditi jake mehanizme zaštite treba formirati organizacionu celinu koja će se baviti realizacijom poslova iz nadležnosti CA. Ova organizaciona celina može biti posebna organizaciona jedinica, ili poslovati kao organizacioni deo šire organizacione jedinice koja je zadužena za čitav sistem zaštite.

5.18.1.1 Organizacija poslovnih uloga

Neodgovarajuća organizacija poslovnih uloga ili funkcija u CA može biti uzrok bezbednosnih problema bilo da su izazvani slučajno ili sa namerom. Ljudi odabrani da obavljaju poslovne uloge moraju biti izvanredno odgovorni ili se u suprotnom slučaju dovodi do slabljenja integriteta CA.

Dva principa se koriste da bi povećali verovatnoću uspešnog obavljanja poslovnih uloga. Prvi je poverljivost i dobra obučenost zaposlenih, a drugi je podela poslovnih funkcija na više od jedne osobe, tako da bilo koja maliciozna aktivnost zahteva dogovor bar dve osobe.

Na poslovima CA možemo uočiti četiri eventualne poslovne uloge: administrator, referent, nadzornik i operater.

Administrator treba da obavlja sledeće poslove:

Instalacija, konfiguracija i održavanje CA, Kreira i održava sistemski CA nalog, Konfiguriše profile sertifikata i parametre sistema provere (audit), Generiše i organizuje čuvanje kriptografskih klučeva CA.

Administrator ne izdaje sertifikate korisnicima.

Referent je odgovoran za rad sa klijentskim sertifikatima:

Registruje nove korisnike i zahteve za izdavanjem sertifikata, Verifikuje identitet korisnika i tačnost podataka u sertifikatu, Izvršava generisanje sertifikata, Obrađuje zahtev za opoziv sertifikata.

Nadzornik pregleda, održava i arhivira audit logove i proverava usklađenost tekućih procesa sa CPS.

Operator je zadužen za obavljanje rutinskih poslova na opremi CA kao što je sistemski backup i opopravak sistema, izmena medijuma i sl.

5.18.1.2 Princip razdvajanja poslovnih uloga

Princip razdvajanja poslovnih uloga različito se implementira u zavisnosti od nivoa pouzdanosti koji može biti testni, rudimentarni, osnovni, srednji ili visoki.

108

U osnovnom nivou pouzdanosti postoje četiri poslovne uloge. Pojedinac može imati više uloga, ali ne istovremenu ulogu administratora i referenta. Potrebne su bar dve osobe.

I u srednjem nivou pouzdanosti imamo četiri uloge. Ograničenje je da referent ne može imati ulogu administratora ili nadzornika. Potrebne su bar dve osobe.

U visokom nivou pouzdanosti četiri poslovne uloge obavljaju bar tri osobe tako da su nespojive funkcije administratora, referenta i nadzornika. Ipak, preporuka je da svaku od poverljivih uloga obavlja posebna osoba.

5.18.1.3 Izbor zaposlenih

Izbor zaposlenih za poverljive poslovne uloge obavlja se na osnovu kriterijuma odanosti, poverenja, integriteta i zaposleni mora biti državljanin zemlje u kojoj CA radi. Zahtevi za izbor zaposlenih koji rade, upravljaju, nadziru ili kontrolišu rad CA obično je definisan u CPS.

5.18.1.4 Obuka zaposlenih

Svi zaposleni koji obavlju poverljive poslove uloge treba da imaju redovne odgovarajuće kurseve i obuke iz sledećih oblasti:

CA/RA bezbednosni principi i mehanizmi, Sve PKI softverske verzije u upotrebi u CA, Sve PKI dužnosti koje obavlja ili može da obavlja, Procedure oporavka sistema usled vanrednih događaja ili elementarnih

nepogoda i nastavak rada.

Zaposlenima treba organizovati obuku u slučaju zanavljanja softvera, hardvera, izmeštanja ili relociranja poslovnog sistema.

Zaposlene treba upoznati sa opštim aktima CA kao što je politika sertifikacije, CPS, statuti ili relevantni ugovori

5.18.1.5 Sankcije za neovlašćene aktivnosti

Zaposleni treba da budu svesni sankcija za slučaj izvođenja neovlašćenih aktivnosti kao što je raskid radnog odnosa i zapis u radnoj biografiji.

5.18.2 Bezbednosne procedure u odnosu na prostorije i uređaje

Poslovi generisanja ključeva, formiranja digitalnih sertifikata, personalizacije smart kartica, kao i ažuriranje lista izdatih i povučenih sertifikata, moraju se izvršavati u specijalnim prostorijama koje su izdvojene za tu namenu.

Potrebno je obezbediti organizacione i tehničke preduslove kako bi samo ovlašćena lica imala pristup ovim prostorijama. Pri tome se moraju koristiti tehničke metode zaštite prostora i kontrole fizičkog pristupa kako bi se vodila automatizovana evidencija o boravku ljudstva u tim prostorijama.

109

Uređaji na kojima se proizvode kriptografski ključevi i formiraju digitalni sertifikati moraju biti namenjeni isključivo za tu vrstu poslova. Rukovanje tim uređajima ograničeno je na ovlašćene službenike primenom prethodno navedenih tehničkih mera zaštite.

Aktivnosti koje se vrše na uređajima moraju se automatizovano evidentirati (mora postojati automatizovan evidencioni zapis, audit-log, kako bi se naknadnom supervizijom mogli rekonstruisati postupci operatera).

Arhiviranje svih izdatih digitalnih sertifikata mora se vršiti na medijumima na kojima je obezbeđena minimalna trajnost zapisa od 10 godina. Sve tajne informacije koje se generišu u okviru CA štite se kriptografskim tehnikama i tako obrađene odlažu u memoriju.

Arhivirani podaci moraju biti smešteni na najmanje dva nezavisna medijuma, back-up copy, i moraju biti overeni digitalnim potpisom ovlašćenih lica CA. Sve pomenute procedure se obezbeđuju korišćenjem hardverskih kriptografskih modula koji će se koristiti u okviru CA za generisanje digitalnog potpisa sertifikata koji se izdaju.

Hardverski kriptografski koprocesorski modul se dakle koristi za bezbednu implementaciju kriptografskih funkcija generisanja ključeva na bazi slučajnog niza, digitalnog potpisivanja sertifikata i šifrovanja u okviru CA.

5.18.3 Sistemi fizičke i logičke kontrole pristupa u okviru Sertifikacionog tela

KI (CA, RA) oprema treba da bude zaštićena od neautorizovanog pristupa, a posebno ona u kojoj je instaliran i aktiviran HSM uređaj. Kontrola fizičkog pristupa je neophodna čak i u slučaju da HSM uređaj trenutno nije u funkciji ili nije instaliran.

Zaštitni mehanizmi treba da budu u skladu sa nivoom pretnji PKI radnom okuženju i nivoom pouzdanosti (assurance) certifikata i dokumenata sa kojima se radi.

5.18.3.1 Lokacija

Lokacija i konstrukcija mesta na kojoj je smešten CA treba da bude u skladu sa zahtevima za mesta na kojima se radi ili gde se čuvaju vrlo osetljive informacije. Pored toga neophodna je stalna čuvarska služba i primena protivprovalnih senzora koji treba da obezbede fizičku zaštitu od neautorizovanog pristupa CA opremi i informacijama.

5.18.3.2 Fizički pristup

Oprema CA mora uvek da bude zaštićena od neautorizovanog pristupa, posebno kada i dok je HSM uređaj instaliran i aktivan. Kontrola fizičkog pristupa mora biti primenjena kako bi bio smanjen rizik od malicioznog pristupa opremi CA čak i ako HSM uređaj nije trenutno instaliran ili aktivan.

Zaštitni mehanizmi treba da budu u skladu sa nivoom mogućih pretnji i nivoom pouzdanosti certifikata koje CA izdaje.

110

Ako CA izdaje certifikate sa osnovnim, srednjim i visokim nivoom pouzdanosti u skladu sa tim nivoom pouzdanosti treba da budu i mere fizičke zaštite radnih prostorija CA.

Za osnovni nivo pouzdanosti certifikata neophodno je:

hardverske komponente CA opreme obezbediti od neovlašćenog pristupa, prenosne memorijske medijume i papire koji sadrže poverljive informacije

čuvati u bezbednim ormarima.

U koliko se radi o elektronskim certifikatima srednjeg ili visokog nivoa pouzdanosti neophodno je, dodatno, obezbediti:

stalni fizički ili elektronski nadzor za slučaj upada, periodični pregled evidencije pristupa opremi, istovremeno fizičko prisustvo dve ovlašćene osobe kada radi kompjeterski

sistem ili HSM uređaj CA.

U slučaju da se koriste pokretni kriptografski moduli, neophodno ih je deaktivirati pre skladištenja, a aktivacione podatke čuvati u bezbednim ormarima odvojeno od kriptografskih modula.

U slučaju da se radne prostorije ostavljaju bez stalno zaposlenih neophodno je propisati listu neophodnih provera koje treba da obavi stalno fizičko obezbedjenje, kao na primer:

proveriti da je sva oprema ugašena sem sistema koji drži bazu sertifikata i koja može biti stalno javno dostupna,

proveriti da su bezbedni ormari dobro zaključani (zapečaćeni), proveriti brave na vratima, ventilacione cevi i druge otvore, proveriti sigurnosni sistem protiv upada.

5.18.3.3 Napajanje električnom energijom

Napajanje električnom energijom mora biti izvedeno tako da je obezbeđeno rezervno napajanje minimalno dovoljno za:

završetak unosa podataka ili dovršetka započetog posla, čuvanje trenutnog stanja i regularnog zaustavljanja računarskog sistema.

5.18.3.4 Čuvanje podataka na prenosnim medijuma

Podaci CA moraju biti čuvani tako da obezbede zaštitu od oštećenja u slučaju vanrednih situacija izazvanih vodom, vatrom ili elektromagnetnim zračenjem.

Mediji koji sadrže rezervne kopije, arhivske ili evidencione podatke moraju se čuvati na dve fizički odvojene lokacije od radnih prostorija CA.

111

5.18.3.5 Rad sa rezervnim kopijama

Za sve CA koje rade na osnovnom ili višem nivou poverenja, mora se obavljati periodični i puni sistemski backup dovoljan da se sistem oporavi i posle potpunog pada računarskog sistema, u skladu sa CPS.

Backup se mora obaviti i sačuvati van radnih prostorija CA bar jednom u toku sedmice. Najmanje jedna potpuna kopija mora biti sačuvana na udaljenoj lokaciji. Ta potpuna kopija mora biti dovoljna da se računarski sistem potpuno regeneriše (aplikativni softver, baza, sistemski softver, drajveri).

5.19.3.6 Ostalo

Takođe, vrlo važna su pitanja obezbeđenja prostorija CA od vanrednih situacija koje mogu nastati usled nepogoda izazvanih vodom, vatrom ili drugim prirodnim nepogodama.

Posebno treba regulisati pitanje uništavanja i odlaganja otpadnog materijala kao sto su papir, filmovi, trake, ostećeni medijumi i sl.

5.19 Osnovni dokumenti rada Sertifikacionog tela

Bilo koje bezbednosne mere koje se primenjuju u okviru neke računarske mreže, koje između ostalog mogu da uključuju mrežne barijere (firewall), ID kartice ili kontrolu pristupa do PKI infrastrukture zahtevaju postojanje sveobuhvatne bezbednosne politike (politika zaštite) rada date mreže.

Ova politika definiše procedure koje omogućuju pristup korporacijskim resursima ili informacijama, i koje onemogućuju neautorizovanim korisnicima pristup tim resursima. Ova bezbednosna politika uključuje postavku i detaljnu definiciju funkcija koje treba da realizuju svi elementi PKI infrastrukture datog sistema.

U toj bezbednosnoj politici, posebno mesto treba da zauzimaju specifične procedure, profili i ograničenja vezana za sertifikate i zahteve za izdavanje sertifikata. Ovaj deo bezbednosne politike se naziva Politika sertifikacije, koja predstavlja poseban dokument.

Upravljanje politikom rada određenog PKI sistema vrši sertifikaciono telo. U tom smislu, sve PKI aplikacije koje koriste softverske i hardverske kriptografske mehanizme centralno se upravljaju, što redukuje troškove i povećava nivo kontrole.

Sertifikaciono telo pre početka rada utvrđuje Opšta pravila pružanja usluge sertifikacije koja korisnicima obezbeđuju dovoljno informacija na osnovu kojih se mogu odlučiti o prihvatanju usluga i o obimu usluga.

Pomenuta Opšta pravila se sastoje iz dva osnovna dokumenta:

Politika sertifikacije (Certificate Policy) i

112

Praktična pravila pružanja usluge Sertifikacije (Certification Practices Statement) (u daljem tekstu: Praktična pravila).

5.19.1 Politika sertifikacije – opšti koncept

Politika sertifikacije, tj. politika po kojoj se izdaju sertifikati u datom PKI sistemu, treba da propiše sve procedure koje se odnose na korišćenje i izdavanje sertifikata. Ova politika uključuje sledeće:

Pod kojim uslovima se izdaju sertifikati, Koje informacije treba da budu uključene u sertifikat, Za koju svrhu se koristi dati sertifikat, i Šta se dešava kada istekne važnost sertifikata (kada sertifikat dođe do kraja

svog životnog veka).

Generisanje politike sertifikacije je veoma veliki i složen posao koji treba da bude nedeljivi deo korporacijske bezbednosne politike. Mogući postupak generisanja politike sertifikacije bi se mogao podeliti na četiri glavna dela:

Odlučivanje koji sve elementi jedinstvenog imena (distinguished name – Dname) koji jedinstveno identifikuju korisnika treba da se pojave u svim sertifikatima koji su izdati u skladu sa politikom sertifikacije (neki elementi mogu biti opcioni),

Određivanje koje ekstenzije će se pojaviti u sertifikatima izdatim u skladu sa ovom politikom,

Odlučivanje koje dodatne registracione informacije treba da budu prikupljane u cilju izdavanja sertifikata. Ove informacije se ne publikuju u sertifikatu, i

Određivanje dodatnih operacionih ograničenja koja treba da budu sprovedena u vezi izdavanja i korišćenja sertifikata.

Sertifikaciono telo je odgovorno za pružanje kompletnih usluga sertifikacije, koje uključuju sledeće servise, i to:

Registraciju korisnika, Formiranje digitalnih sertifikata, Distribuciju digitalnih sertifikata korisnicima, Upravljanje procedurom opoziva digitalnih sertifikata i Obezbeđivanje statusa opozvanosti digitalnih sertifikata.

Sertifikaciono telo može, pored gore navedenih servisa, da obezbedi i:

formiranje asimetričnog para ključeva za korisnike, kao i distribuciju privatnog ključa i sertifikata korisniku na bezbedan način,

sredstvo za formiranje kvalifikovanog elektronskog potpisa korisnicima i pridruženu lozinku (ili PIN kod) za aktivaciju sredstva, kao i njihovu bezbednu distribuciju do korisnika, ako je to u skladu sa svojim Opštim i Internim pravilima rada.

Na slici 5.6 su ilustrativno prikazani servisi koje pruža sertifikaciono telo.

113

Slika 5.6: Ilustracija servisa koje pruža sertifikaciono telo

5.19.2 Relativni odnos dokumenata Politika sertifikacije i Praktična pravila rada

Opšta pravila funkcionisanja sertifikacionog tela, iz člana 6. ovog Pravilnika, treba da budu u skladu sa dokumentima RFC 2527 “Internet X.509 Public Key Infrastructure. Certificate Policy and Certification Practices Framework” i ETSI TS 101 456 “Policy Requirements for Certification Authorities Issuing Qualified Certificates”.

Politika sertifikacije i Praktična pravila su javni dokumenti i njihov relativni odnos se zasniva na sledećim principima.

5.19.2.1 Svrha dokumenata

Politika sertifikacije definiše predmet rada sertifikacionog tela dok Praktična pravila definišu procese i način njihovog korišćenja pri formiranju i upravljanju kvalifikovanim elektronskim sertifikatima.

Politika sertifikacije definiše zahteve poslovanja sertifikacionog tela dok Praktična pravila definišu operativne procedure u cilju ispunjenja tih zahteva. Praktična pravila definišu način na koji sertifikaciono telo ispunjava tehničke, organizacione i proceduralne zahteve poslovanja koji su identifikovani u Politici sertifikacije.

114

5.19.2.2 Nivo specifikacije

Politika sertifikacije je manje specifičan i detaljan dokument u odnosu na Praktična pravila koja predstavljaju mnogo detaljniji opis načina poslovanja, kao i poslovne i operativne procedure koje sertifikaciono telo primenjuje u izdavanju i upravljanju kvalifikovanim elektronskim sertifikatima.

U okviru dokumentacije sa opisom rada sertifikacionog tela postoje i dokumenti sa još nižim nivoom opštosti (višim nivoom specifičnosti operativnih procedura sertifikacionog tela) koja se nazivaju Interna pravila rada CA o kojima će biti više reči kasnije.

U Internim pravilima rada se daje detaljni opis specifičnih procedura koje su neophodne za kompletiranje praktičnih procedura identifikovanim u Praktičnim pravilima rada. Interna pravila predstavljaju dokumenta u kojima se definišu interne operativne procedure koje specificiraju određene poslove i odgovornosti u okviru organizacije.

Za razliku od Opštih pravila rada, Interna pravila rada predstavljaju poverljiv dokument sertifikacionog tela i na njih se ne odnose utvrđena pravila i obavezan sadržaj koji su navedeni u RFC i ETSI standardizacionim dokumentima.

Na primer, Politika sertifikacije definiše zahtev za bezbednim upravljanjem privatnog ključa sertifikacionog tela, Praktična pravila definišu na primer dualnu kontrolu i bezbedne procedure čuvanja ključeva a Interna pravila opisuju odgovarajuću proceduru u detalje sa lokacijama, pristupnim listama i procedurama pristupa.

5.19.2.3 Različiti pristup dokumenata

Politika sertifikacije se definiše nezavisno od specifičnog operativnog okruženja sertifikacionog tela, dok Praktična pravila daju detaljan opis organizacione strukture, operativnih procedura, kao i fizičko i računarsko okruženje sertifikacionog tela.

Štaviše, moguće je da u određenim širim i sveobuhvatnijim PKI sistemima postoji univerzalna Politika sertifikacije, u smislu zajednički dogovorenih zahteva koje treba da ispune sertifikaciona tela. Međutim, Praktična provila rada moraju uvek biti definisana od strane samog sertifikacionog tela.

5.19.3 Sadržaj dokumenata Politika sertifikacije i Praktična pravila rada

Sadržaj dokumenta Politika sertifikacije, prema ETSI TS 101 456 “Policy Requirements for Certification Authorities Issuing Qualified Certificates”, obuhvata sledeća poglavlja i teme, i to:

Opšte odredbe o radu sertifikacionog tela

o Pojam sertifikacionog tela,o Sertifikacione usluge,o Obuhvat dokumenta Politika sertifikacije,

115

o Obuhvat dokumenta Praktična pravila pružanja usluge sertifikacije,o Korisnici usluga sertifikacije.

Uvodne odredbe o Politici izdavanja kvalifikovanih elektronskih sertifikata Obaveze i odgovornosti

o Obaveze sertifikacionog tela,o Obaveze korisnika,o Odgovornost sertifikacionog tela,o Odgovornost korisnika.

Funkcionalni zahtevi za rad sertifikacionog tela

o Operativna pravila rada sertifikacionog telao Procedure upravljanja životnim ciklusom kriptografskih ključeva

Generisanje ključa sertifikacionog tela, Procedure čuvanja i formiranja rezervnih kopija ključeva

sertifikacionog tela, Distribucija javnog ključa sertifikacionog tela, Korišćenje ključa sertifikacionog tela, Kraj životnog ciklusa ključa sertifikacionog tela, Upravljanje životnim ciklusom kriptografskog hardvera koji se

koristi za generisanje kvalifikovanih sertifikata, Upravljanje ključevima korisnika za identifikaciju i digitalnu

envelopu, Procedura pripreme sredstava za formiranje kvalifikovanog

elektronskog potpisa.

o Procedure upravljanja životnim ciklusom sertifikata

Metode registracije korisnika, Izdavanje sertifikata, Distribucija sertifikata, Obnavljanje sertifikata, Suspenzija sertifikata, Opoziv sertifikata, Način publikacije liste opozvanih sertifikata.

o Upravljanje operativnim radom sertifikacionog tela

Upravljanje u skladu sa bezbednosnim principima, Upravljanje i klasifikacija najvažnijih informacija i podataka u

okviru sertifikacionog tela, Kadrovski resursi, Sistem fizičke bezbednosti i bezbednosti okruženja, Upravljanje radom sertifikacionog tela, Upravljanje sistemom kontrole pristupa, Upotreba i održavanje bezbednih kriptografskih sistema,

116

Upravljanje procedurama kontinualnog poslovanja u incidentnim situacijama,

Prestanak rada sertifikacionog tela, Usaglašenost rada sa kriterijumima za rad sertifikacionih tela

koja izdaju kvalifikovane elektronske sertifikate u skladu sa Zakonom o elektronskom potpisu i ovim Pravilnikom,

Formiranje i čuvanje dokumentacije koja se odnosi na kvalifikovane elektronske sertifikate,

o Organizacija rada sertifikacionih tela.

Sertifikaciono telo demonstrira sposobnost za obezbeđivanje usluga izdavanja digitalnih sertifikata, tako što mora:

Imati Praktična pravila, i u njima definisane procedure, u kojima se specificira način ispunjenja svih zahteva za izdavanjem digitalnih sertifikata koji su identifikovani u Politici sertifikacije.

Učiniti raspoloživim Praktična pravila rada svim korisnicima i drugim zainteresovanim stranama.

Objaviti svim korisnicima i potencijalnim zainteresovanim stranama uslove korišćenja digitalnih sertifikata.

Imati upravnu strukturu najvišeg nivoa koja će imati konačnu autorizaciju i odgovornost za objavljivanje Praktičnih pravila rada sertifikacionog tela.

Imati upravnu strukturu operativnog nivoa u sertifikacionom telu koja je odgovorna za ispravnu primenu Praktičnih pravila rada.

Definisati proces periodične analize i održavanja Praktičnih pravila rada. Imati odobrene, od strane upravne strukture najvišeg nivoa, sve izmene u

Praktičnim pravilima, tj. nove verzije Praktičnih pravila i, nakon odobravanja, odmah javno objavljene.

5.10.4 Interna pravila rada sertifikacionog tela

Sertifikaciono telo utvrđuje i posebna Interna pravila rada sertifikacionog tela i zaštite sistema sertifikacije u kojima su sadržani i detaljno opisani postupci i mere koje se primenjuju prilikom izdavanja i rukovanja digitalnim sertifikatima. Interna pravila nisu javni dokument i predstavljaju poslovnu tajnu sertifikacionog tela.

Interna pravila rada sertifikacionog tela sadrže detaljne odredbe o:

Sistemu fizičke kontrole pristupa u pojedine prostorije sertifikacionog tela, Sistemu logičke kontrole pristupa računarskim resursima sertifikacionog tela, Sistemu za čuvanje privatnog ključa sertifikacionog tela, Sistemu distribuirane odgovornosti pri formiranju privatnog ključa

sertifikacionog tela i Postupcima i radnjama u vanrednim situacijama (požari, poplave, zemljotresi,

druge vremenske nepogode, zlonamerni upadi u prostorije ili informacioni sistem sertifikacionog tela).

117

Interna pravila se baziraju na bezbednosnoj politici sertifikacionog tela u smislu fizičke zaštite i zaštite sistemskog okruženja za generisanje digitalnih sertifikata, pripremu sredstava za formiranje digitalnog potpisa i upravljanje opozivom, koja definiše i kontrolu fizičkog pristupa, zaštitu od prirodnih katastrofa, zaštitu od požara, zaštitu od nestanka električne energije i prekida rada telekomunikacionih linija, zaštitu od strukturnih kolapsa, zaštitu od poplava, zaštitu od krađe, loma i upada u sistem, oporavak nakon katastrofe, itd.

5.19.5 Upravljanje radom PKI sistema

Jedna od osnovnih obeležja politike sertifikacije treba da bude u mogućnosti upravljanja radom čitavog PKI sistema. Na veoma visokom nivou, politike sertifikacije se dele na one koje se odnose na prikupljanje zahteva za izdavanjem sertifikata u ličnom kontaku i na one koje dobijaju zahteve udaljenim putem (npr. putem WEB komunikacije).

Prihvatljiva veličina ključa – zadatak ovog dela politike sertifikacije je da obezbedi da dužina ključeva koji se generišu u okviru CA i dužina ključeva koje koriste elementi PKI sistema (CAO, CA, RAO, RA) za digitalno potpisivanje ne budu kraći od onih koji se zahtevaju u bezbednosnoj politici datog sistema.

Prihvatljivi asimetrični kriptografski algoritmi – i u ovom slučaju politika sertifikacije treba da obezbedi da se lista prihvatljivih (od strane politike bezbednosti) asimetričnih algoritama koristi za digitalno potpisivanje i digitalnu envelopu. Ova lista tipično sadrži sledeće algoritme RSA, DSA i ECDSA.

Prihvatljivi hash algoritmi – identično kao u prethodne dve tačke, politika sertifikacije treba da definiše prihvatljivu listu hash algoritama. Najčešće se koriste MD5 i SHA-1 algoritmi, a u poslednje vreme i SHA-224, SHA-256, SHA-384 i SHA-512.

Izvor generisanja ključeva – ovo operaciono ograničenje se uglavnom odnosi na politiku sertifikacije u vezi registracije ličnim kontaktom, i konkretno se odnosi na to kako treba da se generiše asimetrični par ključeva za datog korisnika. Moguće opcije su: generisanje ključeva korišćenjem funkcija iz PKCS#11 standardnog interfejsa na smart kartici ili tokenu, lokalno generisanje ključeva u okviru RAO modula u softveru i učitavanje zahteva za izdavanjem sertifikata u PKCS#10 formatu iz odgovarajuće datoteke, tokena ili smart kartice.

Period validnosti sertifikata – ovaj period se definiše konkretno u okviru CPS dokumenta. Minimalno ovaj period može biti jedan dan a maksimalno do kraja isteka važnosti sertifikata samog CA.

Zamena sertifikata – kada sertifikat dođe do kraja svog životnog veka, politika sertifikacije treba da precizno definiše postupak kojim se vrši izdavanje novog sertifikata kao i procedure (ručne ili automatske) obaveštavanja korisnika i same procedure zamene.

Arhiviranje privatnog ključa – u skladu sa bezbednosnom politikom, za određene asimetrične parove ključeva predviđa se arhiviranje tajnog ključa za kasniji oporavak šifrovanih poruka u slučaju potrebe.

Lozinka za potrebe povlačenja sertifikata – normalno se sertifikati povlače na osnovu zahteva od CAO ili RAO modula koji ima funkciju izdavanja sertifikata. Međutim, moguće je dozvoliti krajnjem korisniku mogućnost da pošalje zahtev

118

za povlačenje svog sertifikata putem WEB komunikacije ali uz korišćenje lozinke koja je definisana tokom procedure registracije datog korisnika.

5.20 Kriterijumi koje CA treba da ispuni da bi izdavalo kvalifikovane sertifikate

Prema Zakonu o elektronskom potpisu i podzakonskim aktima, kvalifikovani elektronski potpis mora da ispunjava sledeće uslove:

isključivo je povezan sa potpisnikom, nedvosmisleno identifikuje potpisnika, nastaje korisšćenjem podataka kojima potpisnik samostalno upravlja i koja su

isključivo pod nadzorom potpisnika, kreiran je primenom odgovarajućih algoritama i parametara kojima se

omogućava uvid u bilo koju izmenu izvornih podataka, bazira se na kvalifikovanog elektronskom sertifikatu potpisnika i formiran je sredstvima za formiranje kvalifikovanog elektronskog potpisa.

Dalje, prema Zakonu o elektronskom potpisu, kvalifikovan elektronski potpis u odnosu na podatke u elektronskom obliku:

ima istu pravnu snagu kao i svojeručni potpis, odnosno svojeručni potpis i pečat u odnosu na podatke u papirnom obliku i

prihvatljiv je kao dokazni materijal u pravnim poslovima.

Dakle, da bi se ostvario kvalifikovani elektronski potpis neophodno je da potpisnik ima kvalifikovani elektronski sertifikat koga izdaje sertifikaciono telo koje ispunjava određene uslove definisane u Zakonu o elektronskom potpisu i Direktivi Evropske Unije o elektronskim potpisisma 1999/93/EC od 19.01.2000. godine.

Drugim rečima, CA koje izdaje kvalifikovane elektronske sertifikate treba da ispuni uslove za izdavanje kvalifikovanih sertifikata u skladu sa Direktivom Evropske unije o elektronskim potpisima i domaćem Zakonom o elektronskom potpisu.

Prema Direktivi, sertifikaciono telo koje izdaje kvalifikovane sertifikate treba da ispuni sledeće zahteve (Annex II):

Da demonstrira neophodnu sposobnost za pružanje sertifikacionih usluga, Da garantuje pouzdan rad i da obezbedi pouzdane servise prikaza lista

važećih i povučenih sertifikata, Da obezbedi neophodnu preciznost u vezi datuma i vremena izdavanja ili

povlačenja sertifikata, Da pouzdano verifikuje identitet vlasnika sertifikata i, ako je potrebno, bilo kog

specifičnog atributa vlasnika, Da zapošljava radnike koji poseduju ekspertska znanja, iskustvo i kvalifikacije

neophodne za servise koji se obezbeđuju; posebno na upravnom nivou, ekspertizu u oblasti elektronskog potpisa i familijarnost sa propisanim bezbednosnim procedurama,

119

Da koristi proverene sisteme i proizvode koji obezbeđuju tehničku i kriptografsku bezbednost procesa koji se podržavaju primenom ovih sistema,

Da primenjuje mere protiv kompromitacije sertifikata i garantuje tajnost procesa generisanja para ključeva za digitalno potpisivanje ukoliko se taj par generiše kod sertifikacionog tela,

Da obezbedi odgovarajuća materijalna sredstva za siguran i bezbedan rad i da omogući određenu šemu osiguranja od lažiranja sertifikata,

Da vrši zapisivanje svih relevantnih informacija koja se tiču sertifikata u odgovarajućem periodu vremena (posebno za slučajeve kada se zahteva uvid u evidenciju sertifikata za pravne svrhe); ovi zapisi mogu biti elektronski,

Da ne čuva ili kopira tajni ključ za generisanje kvalifikovanog elektronskog potpisa vlasnika sertifikata za koga Sertifikaciono telo obezbeđuje servis generisanja para ključeva za digitalno potpisivanje,

Da precizno upozna osobu koja zahteva izdavanje sertifikata sa svim uslovima korišćenja sertifikata,

Da koristi proverene sisteme za čuvanje sertifikata u formi koja se može verifikovati, sa sledećim karakteristikama:

o Da samo autorizovane osobe mogu pristupati sistemu i vršiti izmene,o Da se informacije mogu proveravati u smislu autentičnosti,o Da su informacije o sertifikatima javno raspoložive,o Da su bilo kakve tehničke promene koje bi uticale na kompromitaciju

bezbednosnih zahteva sistema zabranjene za operatera.

U skladu sa ovim kriterijuma, u članu 18. Zakona o elektronskom potpisu su definisani kriterijumi koje treba da ispune sertifikaciona tela u cilju izdavanja kvalifikovanih elektronskih sertifikata, koje navodimo u nastavku.

Sertifikaciono telo za izdavanje kvalifikovanih elektronskih sertifikata mora ispunjavati sledeće uslove:

1. sposobnost za pouzdano obavljanje usluga izdavanja elektronskih sertifikata,2. bezbedno i ažurno vođenje registra korisnika kao i sprovođenje bezbednog i

trenutnog opoziva elektronskog sertifikata,3. obezbeđivanje tačnog utvrđivanja datuma i vremena izdavanja ili opoziva

elektronskog sertifikata,4. da izvršava proveru identiteta i, ako je potrebno, i drugih dodatnih obeležja

osobe kojoj se izdaje sertifikat, na pouzdan način i u skladu sa propisima,5. da ima zaposleno osoblje sa specijalističkim znanjima, iskustvom i stručnim

kvalifikacijama potrebnim za vršenje usluge izdavanja elektronskih sertifikata, a naročito u odnosu na: sposobnosti na upravljačkom nivou, stručnost u primeni tehnologija elektronskog potpisa i odgovarajućih sigurnosnih procedura i bezbednu primenu odgovarajućih administrativnih i upravljačkih postupaka koji su usaglašeni sa priznatim standardima,

6. da koristi pouzdane sisteme i proizvode koji su zaštićeni od neovlašćenih izmena i koji obezbeđuju tehničku i kriptografsku sigurnost procesa,

7. da preduzima mere protiv falsifikovanja elektronskih sertifikata, a u slučajevima u kojima generiše podatke za formiranje elektronskog potpisa da garantuje tajnost procesa formiranja tih podataka,

120

8. da obezbedi finansijske resurse za osiguranje od rizika i odgovornosti za moguću štetu nastalu vršenjem usluge izdavanja elektronskih sertifikata,

9. da obezbedi čuvanje svih relevantnih informacija koje se odnose na elektronske sertifikate u određenom vremenskom periodu, a posebno za pružanje podataka o elektronskim sertifikatima za potrebe pravnih postupaka. Ovi podaci se mogu čuvati i u elektronskom obliku,

10.da ne čuva i ne kopira podatke za formiranje elektronskog potpisa za lica u čije ime pruža tu uslugu,

11.da obezbedi sisteme za fizičku zaštitu uređaja, opreme i podataka, i sigurnosna rešenja za zaštitu od neovlašćenog pristupa,

12.da informiše lica koja traže izdavanje kvalifikovanog elektronskog sertifikata o tačnim uslovima izdavanja i korišćenja tog sertifikata, uključujući bilo koja ograničenja u korišćenju, kao i o postupcima za rešavanje pritužbi i žalbi. Takve informacije, koje mogu biti dostavljene elektronski, moraju biti napisane i pripremljene u razumljivom obliku na srpskom jeziku. Odgovarajući delovi tih informacija moraju biti raspoloživi na zahtev trećim licama koja koriste elektronski sertifikat,

13.da koristi pouzdan sistem upravljanja elektronskim sertifikatima u obliku koji omogućava njihovu proveru kako bi:

i. unos i promene radila samo ovlašćena lica,ii. mogla biti proverena autentičnost informacija iz sertifikata,iii. elektronski sertifikati bili javno raspoloživi za pretraživanje samo u onim

slučajevima za koje je vlasnik sertifikata dao saglasnost,iv. bilo koja tehnička promena koja bi mogla da naruši bezbedonosne

zahteve bila poznata sertifikacionom telu.

5.20.1. Sposobnost za pouzdano obavljanje usluga izdavanja elektronskih sertifikata

Sertifikaciono telo mora da demonstrira sposobnost za pružanje usluga sertifikacije i pouzdanu organizaciju rada.

Pored toga, sertifikaciono telo mora da obezbedi:

1. Opšta i Interna pravila rada, kao i operativne procedure, koja nisu diskriminatorska,

2. dostupnost svojih servisa svim korisnicima čije su aktivnosti u skladu sa objavljenim Opštim pravilima rada,

3. poslovanje u svojstvu pravnog lica u skladu sa odgovarajućom domaćom zakonskom regulativom,

4. sistem kvaliteta i sistem bezbednog upravljanja kvalifikovanim elektronskim sertifikatima u skladu sa uslugama sertifikacije koje pruža,

5. adekvatnu šemu osiguranja za odgovornosti koje mogu da proisteknu u vršenju njegovih aktivnosti,

6. finansijsku stabilnost i dovoljne resurse koji se zahtevaju u pružanju usluga sertifikacije u skladu sa Politikom sertifikacije,

7. dovoljan broj zaposlenih sa neophodnim obrazovanjem, nivoom obučenosti, tehničkim znanjima i iskustvom u odnosu na tip i obuhvat poslova koji se zahtevaju pri pružanju usluga sertifikacije,

121

8. politiku i procedure za rešavanje žalbi i sporova sa korisnicima ili drugim zainteresovanim stranama u vezi pružanja usluga sertifikacije,

9. nezavisnost delova sertifikacionog tela uključenih u poslove generisanja kvalifikovanih elektronskih sertifikata i upravljanja opozivom od drugih spoljnih organizacija u sferi pružanja usluga sertifikacije. Posebno upravna struktura sertifikacionog tela, kao i zaposleni sa bezbednosnim funkcijama-rolama, moraju biti zaštićeni od bilo kakvih finansijskih i drugih pritisaka koji mogu uticati na poverenje u usluge sertifikacije koje pruža sertifikaciono telo,

10.propisno dokumentovanu strukturu delova sertifikacionog tela povezanih sa generisanjem kvalifikovanih elektronskih sertifikata i upravljanjem opozivom radi obezbeđivanja nepristrasnosti u pružanju usluga sertifikacije.

Sertifikaciono telo obezbeđuje da u slučaju katastrofa, uključujući i kompromitaciju asimetričnog privatnog ključa sertifikacionog tela, operativni rad bude obnovljen što je moguće pre a u skladu sa Opštim i Internim pravilima rada.

Posebno, u slučaju kompromitacije svog asimetričnog privatnog ključa, sertifikaciono telo obezbeđuje:

1. informisanje svih korisnika i drugih zainteresovanih strana o kompromitaciji privatnog ključa,

2. javno objavljivanje informacije o tome da izdati kvalifikovani elektronski sertifikati, kao i informacije o statusu opozvanosti kvalifikovanih elektronskih sertifikata, više nisu važeći,

3. opoziv svih izdatih kvalifikovanih elektronskih sertifikata odmah a najdalje u roku od 24 časa u skladu sa Zakonom o elektronskom potpisu i podzakonskim aktima.

Sertifikaciono telo vrši demonstraciju kompletnog poslovanja, usaglašenog sa Opštim i Internim pravilima poslovanja, pred odgovarajućom komisijom akreditacionog tela, koja se sastoji od:

1. Procedure identifikacije korisnika kome se izdaje kvalifikovani elektronski sertifikat,

2. Procedure pripreme zahteva za izdavanjem kvalifikovanog elektronskog sertifikata u registracionom autoritetu,

3. Procedure dostavljanja zahteva do sertifikacionog tela,4. Procedure generisanja kvalifikovanog elektronskog sertifikata,5. Korišćenje bezbednih sistema za čuvanje podataka za generisanje

kvalifikovanih elektronskih potpisa,6. Korišćenje bezbednih hardverskih sredstava za formiranje kvalifikovanog

elektronskog potpisa (hardverski moduli zaštite (HSM – Hardware Security Module)),

7. Procedure opoziva sertifikata,8. Procedure obnavljanja sertifikata,9. Procedure suspenzije sertifikata,10.Način publikacije liste povučenih i suspendovanih sertifikata,11.Sistema fizičke kontrole pristupa u prostorije sertifikacionog tela,12.Sistema logičke kontrole pristupa računarskim resursima sertifikacionog tela,

122

13.Sistema za javno publikovanje osnovnih informacija o pružanju usluga sertifikacije, kao i Opštih pravila rada sertifikacionog tela.

5.20.2 Bezbedno i ažurno vođenje registra korisnika kao i sprovođenje bezbednog i trenutnog opoziva elektronskog sertifikata

Sertifikaciono telo vodi ažurnu i bezbednu evidenciju izdatih, opozvanih i suspendovanih kvalifikovanih elektronskih sertifikata koja mora biti javno dostupna, u skladu sa Zakonom o elektronskom potpisu. Tačnost i validnost ovih evidencija sertifikaciono telo garantuje svojim kvalifikovanim elektronskim potpisom.

5.20.3 Obezbeđivanje tačnog utvrđivanja datuma i vremena izdavanja ili opoziva elektronskog sertifikata

Za pouzdano određivanje vremena izdavanja i opoziva kvalifikovanih elektronskih sertifikata sertifikaciono telo mora obezbediti hardverski izvor tačnog vremena. Tačno vreme izdavanja kvalifikovanog elektronskog sertifikata sertifikaciono telo ugrađuje u izdati kvalifikovani elektronski sertifikat. Tačno vreme izdavanja i opoziva kvalifikovanih elektronskih sertifikata sertifikaciono telo čuva u evidenciji izdatih i opozvanih kvalifikovanih elektronskih sertifikata.

5.20.4 Obezbeđivanje pouzdane registracija korisnika

Sertifikaciono telo vrši registraciju korisnika, odnosno pouzdanu identifikaciju i autentikaciju korisnika kojima izdaje kvalifikovane elektronske sertifikate, u skladu sa Zakonom o elektronskom potpisu. Postupke registracije vrši ovlašćeni službenik sertifikacionog tela ili registracionog tela na udaljenoj registracionoj lokaciji koje uspostavlja sertifikaciono telo za potrebe registracije korisnika.

Sertifikaciono telo obezbeđuje da zahtevi korisnika za izdavanje kvalifikovanih elektronskih sertifikata budu kompletni, pouzdani i autorizovani, u skladu sa Zakonom o elektronskom potpisu i vrši registraciju korisnika u skladu sa sledećim principima:

1. Korisnik se identifikuje kao fizičko lice sa specifičnim atributima koji mogu označavati organizacionu jedinicu ili ulogu u organizaciji gde je zaposlen.

2. Pre uspostavljanja ugovornog odnosa sa korisnikom, sertifikaciono telo javno informiše korisnika na jasnom i razumljivom jeziku o svim relevantnim uslovima korišćenja kvalifikovanih elektronskih sertifikata.

3. Sertifikaciono telo verifikuje identitet korisnika u skladu sa važećim zakonskim propisima.

4. Za pouzdanu proveru identiteta korisnika u postupku registracije zahteva se fizičko prisustvo korisnika u sertifikacionom telu ili u registracionom autoritetu.

5. Ako je potrebno, sertifikaciono telo verifikuje i bilo koji specifični atribut korisnika kome se izdaje kvalifikovani elektronski sertifikat.

6. Ukoliko se radi o fizičkom licu kao individualnom korisniku, identitet korisnika mora da bude proveren na osnovu zakonom propisanog ličnog identifikacionog dokumenta.

123

7. Ukoliko se radi o korisniku koji se identifikuje kao pripadnik pravnog lica ili neke organizacije, dokaz njegovog identiteta mora da sadrži sledeće elemente, i to:

i. Zakonom propisani lični identifikacioni dokumenat,ii. Pravno valjane podatke o registraciji pravnog lica ili organizacije,iii. Dokaz da je korisnik ovlašćen od strane tog pravnog lica ili organizacije

za dobijanje kvalifikovanog elektronskog sertifikata.

8. Sertifikaciono telo je odgovorno za pouzdanost i tačnost informacija sadržanih u kvalifikovanom elektronskom sertifikatu.

9. Korisnik mora obezbediti tačne i pouzdane informacije o fizičkoj adresi, ili drugim atributima, koji opisuju kako se korisnik može kontaktirati.

10.Sertifikaciono telo čuva sve informacije korišćene za verifikaciju identiteta korisnika i dokumentaciju korišćenu za identifikaciju, kao i bilo koja ograničenja njene važnosti.

11.Sertifikaciono telo mora da sklopi Ugovor, i da čuva potpisani Ugovor, sa korisnikom koji uključuje:

i. Obaveze korisnika,ii. Obavezu korisnika da koristi sredstvo za formiranje kvalifikovanog

elektronskog potpisa koje obezbeđuje sertifikaciono telo ako je to u skladu sa Opštim pravilima rada,

iii. Obavezu sertifikacionog tela da čuva podatke korišćene u registraciji korisnika i sve informacije o životnom ciklusu izdatog kvalifikovanog elektronskog sertifikata korisnika, kao i prosleđivanje ovih informacija trećim stranama pod istim uslovima kako je zahtevano Politikom sertifikacije u slučaju prestanka sa radom sertifikacionog tela,

iv. Uslove za publikaciju sertifikata,v. Potvrdu da su informacije sadržane u sertifikatu korektne.

12.Prethodno navedena dokumenta se čuvaju u vremenskom periodu koji je specificiran u korisnikovom Ugovoru i neophodna su radi obezbeđenja dokaza o poslovima sertifikacije u pravnim procedurama.

13.Ako asimetrični par ključeva korisnika nije generisan od strane sertifikacionog tela, proces generisanja zahteva za kvalifikovanim elektronskim sertifikatom mora da obezbedi da korisnik poseduje asimetrični privatni ključ koji je matematički, na bazi asimetričnog kriptografskog algoritma, povezan sa javnim ključem koji je prezentiran za sertifikaciju. Da bi sertifikaciono telo bilo sigurno da se privatni ključ korisnika zaista nalazi u sredstvu za formiranje kvalifikovanog elektronskog potpisa, proces generisanja zahteva za dobijanjem kvalifikovanog elektronskog sertifikata treba da osigura da je asimetrični par ključeva generisan isključivo na tom sredstvu za formiranje kvalifikovanog elektronskog potpisa.

14.Sertifikaciono telo obezbeđuje poštovanje nacionalne regulative u vezi zaštite podataka za vreme procesa registracije korisnika.

5.20.5 Obezbeđivanje neophodnih kadrovskih resursa i upravljanja operativnim radom sertifikacionog tela

124

Sertifikaciono telo obezbeđuje kadrovske resurse u skladu sa zahtevima za pouzdano i bezbedno funkcionisanje sertifikacionog tela koje izdaje kvalifikovane elektronske sertifikate na osnovu Zakona o elektronskom potpisu i podzakonskih akata.

Posebno, sertifikaciono telo obezbeđuje neophodne kadrovske resurse u skladu sa sledećim principima:

1. Zaposleni u sertifikacionom telu moraju da poseduju ekspertsko znanje, iskustvo i neophodnu kvalifikaciju za usluge koje sertifikaciono telo nudi, kao i za odgovarajuće poslovne funkcije.

2. Uloge i funkcije bezbednosti, specificirane u Opštim pravilima rada sertifikacionog tela, moraju biti dokumentovane i detaljno specificirane sa opisima svakog radnog mesta u sertifikacionom telu. Poslovne funkcije od najvišeg nivoa poverljivosti, od kojih najviše zavisi bezbednost funkcionisanja sertifikacionog tela, moraju biti posebno i jasno identifikovane.

3. Zaposleni u sertifikacionom telu (stalni i privremeni) moraju imati opise poslova definisane sa stanovišta razdvajanja dužnosti i privilegija. Opisi poslova moraju razlikovati opšte poslove i specifične funkcije sertifikacionog tela. Preporučuje se da opisi poslova uključe i definicije zahteva za specifičnim veštinama i iskustvom koja se traže od zaposlenih.

4. Zaposleni moraju da izvršavaju administrativne i upravljačke procedure i procese koji su u skladu sa procedurama upravljanja bezbednosti informacionog sistema sertifikacionog tela. Ove procedure moraju biti u skladu sa standardom ISO/IEC 17799.

5. Zaposleni u upravnoj strukturi sertifikacionog tela moraju da poseduju ekspertizu u tehnologiji elektronskog potpisa, da su dobro upoznati sa bezbednosnim procedurama za zaposlene i sa odgovornostima u domenu bezbednosti, kao i da imaju odgovarajuća iskustva u primeni bezbednih informacionih sistema i proceni rizika.

6. Svi zaposleni u sertifikacionom telu sa bezbednosnim funkcijama ne smeju imati sukobe interesa koji mogu uticati na nepristrasnost rada sertifikacionog tela.

7. Bezbednosne funkcije u sertifikacionom telu uključuju sledeće odgovornosti:

i. Administratori bezbednosti: Sveukupna odgovornost za administriranje i implementaciju bezbednosnih funkcija i procedura, kao i upravljanje aktivnostima na dodatnom unapređenju poslova generisanja, opoziva i suspenzije kvalifikovanih elektronskih sertifikata.

ii. Sistem administratori: Autorizovani za instalaciju, konfigurisanje i održavanje bezbednih sistema sertifikacionog tela za registraciju korisnika, generisanje kvalifikovanih elektronskih sertifikata, obezbeđenje sredstava za formiranje kvalifikovanog elektronskog potpisa za korisnike i upravljanje opozivom kvalifikovanih elektronskih sertifikata.

iii. Sistem operatori: Odgovorni za rad bezbednih sistema sertifikacionog tela u tekućem radu na dnevnom nivou i autorizovani za implementaciju sistema za formiranje rezervnih kopija i procedure oporavka.

iv. Sistem evidentičari: Autorizovani za pregledanje i održavanje arhiva i log fajlova bezbednih sistema sertifikacionog tela.

125

8. Zaposlenima u sertifikacionom telu moraju biti formalno dodeljene bezbednosne funkcije od strane više upravne strukture nadležne za bezbednost.

9. Sertifikaciono telo ne sme dodeliti bezbednosne ni upravne funkcije osobama koje su osuđivane ili koje su na bilo koji način kažnjavane u odnosu na njihovu podobnost za rad na odgovornim funkcijama. Zaposleni ne smeju imati pristup bezbednosnim funkcijama pre završetka neophodnih provera.

Pored toga, sertifikaciono telo obezbeđuje bezbedno i korektno funkcionisanje svojih sistema, sa minimalnim rizikom od kvarova u skladu sa sledećim principima:

1. zaštićen integritet sistema sertifikacionog tela, kao i informacija, od virusa, malicioznog i neautorizovanog softvera,

2. minimalnu štetu usled mogućih incidenata korišćenjem procedura izveštavanja i odgovarajućih odgovora. Sertifikaciono telo mora da reaguje brzo i koordinirano u cilju odgovora na bezbednosne incidente i da ograniči uticaj bezbednosnih upada,

3. bezbedno korišćenje memorijskih medija u skladu sa unapred specificiranim šemama klasifikacije informacija. Mediji koji sadrže bezbednosno osetljive podatke moraju biti bezbedno arhivirani ukoliko nisu u operativnom radu.

4. uspostaviti i implementirati procedure za sve bezbedne i administrativne funkcije-role koje imaju uticaj na pružanje usluga sertifikacije. Svaki zaposleni iz upravne strukture sertifikacionog tela je odgovoran za planiranje i efektivnu implementaciju Opštih pravila rada sertifikacionog tela.

5. stalni nadzor tekućih i budućih potreba za kapacitetom sistema sertifikacionog tela radi obezbeđenja adekvatne procesne snage i memorijskih kapaciteta.

5.20.6 Korišćenje pouzdanih i bezbednih kriptografskih sistema

Sertifikaciono telo mora da koristi bezbedne sisteme i proizvode koji su zaštićeni od neovlašćenih modifikacija. Zahtevi za bezbedne sisteme mogu biti ispunjeni korišćenjem sistema definisanim u skladu sa ISO/IEC 15408 standardom ili drugim odgovarajućim standardom.

Sertifikaciono telo pre početka obavljanja usluga sertifikacije, kao i periodično tokom operativnog rada, vrši analizu rizika kojom identifikuje kritične servise koji zahtevaju korišćenje bezbednih sistema i visoke nivoe sigurnosti.

Sertifikaciono telo obezbeđuje da su njegovi asimetrični ključevi generisani u strogo kontrolisanim i bezbednim uslovima, u skladui sa sledećim:

1. Generisanje asimetričnih ključeva vrši u fizički zaštićenom okruženju, od strane i uz minimalan broj zaposlenih autorizovanih za izvršavanje ove funkcije, uz najmanje dvostruku kontrolu a prema zahtevima i procedurama definisanim u Praktičnim pravilima rada sertifikacionog tela.

2. Generisanje asimetričnih ključeva vrši u sredstvu koje:

i. zadovoljava zahteve iz standarda FIPS PUB 140-1 i 140-2 nivo 3 i viši, ili

126

ii. zadovoljava zahteve iz standarda CEN Workshop Agreement 14167-3 “Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures - Part 3: Cryptographic Modules for CSP Key Generation Services - Protection Profile (CMCKG-PP)” ili

iii. predstavlja bezbedni sistem koji ima nivo sigurnosti EAL4 ili viši, u skladu sa ISO/IEC 15408 standardom ili zadovoljava zahteve ekvivalentnih kriterijuma bezbednosti.

3. Generisanje ključeva vrši korišćenjem algoritma propisanog za svrhu generisanja kvalifikovanih elektronskih sertifikata.

4. Usklađivanje primenjene dužina ključa i asimetričnog kriptografskog algoritma za formiranje kvalifikovanog elektronskog potpisa kvalifikovanih elektronskih sertifikata sa standardom CEN Workshop Agreement 14167-2 “Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures - Part 2 Cryptographic Module for CSP Signing Operations - Protection Profile (MCSO-PP)”.

Takođe, sertifikaciono telo obezbeđuje zaštitu tajnosti i integritet asimetričnih privatnih ključeva, u skladu sa sledećim principima:

1. Čuvanje i korišćenje privatnog ključa za formiranje kvalifikovanog elektronskog potpisa u bezbednom kriptografskom uređaju koji:

i. zadovoljava zahteve iz standarda FIPS PUB 140-1 i 140-2 nivo 3 i viši, ili

ii. zadovoljava zahteve iz standarda CEN Workshop Agreement 14167-3 “Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures - Part 3: Cryptographic Modules for CSP Key Generation Services - Protection Profile (CMCKG-PP)” ili

iii. predstavlja bezbedni sistem koji ima nivo sigurnosti EAL4 ili viši, u skladu sa ISO/IEC 15408 standardom ili zadovoljava zahteve ekvivalentnih kriterijuma bezbednosti.

2. da su delovi privatnog ključa koji se nalaze izvan kriptografskog uređaja šifrovani korišćenjem propisanog simetričnog algoritma i dužine ključa koji omogućavaju, prema sadašnjem nivou kriptografskih znanja, pouzdanu odbranu od kriptoanalitičkih napada.

3. čuvanje privatnog ključa, uz obezbeđenje rezervne kopije, i rekonstrukcija samo od strane onih zaposlenih koji imaju bezbedne funkcije-role, uz korišćenje najmanje dvostruke kontrole u fizički obezbeđenom okruženju. Broj zaposlenih u sertifikacionom telu koji su autorizovani da izvršavaju ove funkcije mora biti minimalan i da zadovolji zahteve i procedure definisane u Praktičnim pravilima rada sertifikacionog tela.

4. da rezervne kopije privatnih ključeva za formiranje kvalifikovanog elektronskog potpisa kvalifikovanih elektronskih sertifikata imaju isti ili viši nivo bezbednosnih kontrola u odnosu na ključeve koji se operativno koriste.

5. da se merama logičke kontrole pristupa onemogući neovlašćeno aktiviranje kriptografskog uređaja sa privatnim ključem sertifikacionog tela i da se ključ ne može iščitati spolja.

127

http://www.cenorm.be/cenorm/businessdomains/businessdomains/informationsocietystandardizationsystem/published+cwas/cwa141672.pdf

Sertifikaciono telo obezbeđuje da njegov asimetrični javni ključ koji služi za verifikaciju kvalifikovanog elektronskog potpisa kvalifikovanih elektronskih sertifikata bude raspoloživ svim korisnicima i drugim zainteresovanim stranama na način kojim se obezbeđuje autentičnost i integritet javnog ključa. Sertifikaciono telo može svoj asimetrični javni ključ distribuirati korisnicima i drugim zainteresovanim stranama u obliku kvalifikovanog elektronskog sertifikata koji može biti izdat od strane:

1. drugog sertifikacionog tela (na primer intermediate sertifikat sertifikacionog tela izdat od strane root sertifikacionog tela),

2. samog tog sertifikacionog tela – root sertifikat ili takozvani “samopotpisani” kvalifikovani elektronski sertifikat, uz primenu neophodnih dodatnih mera radi provere autentičnosti samopotpisanog sertifikata. Jedna od mera može biti korišćenje hash vrednosti kompletnog sertifikata koja je raspoloživa na poverljiv način (na primer objavljena na WEB sajtu sertifikacionog tela).

Sertifikaciono telo koristi svoj asimetrični privatni ključ u skladu sa Opštim i Internim pravilima rada, a naročito obezbeđuje:

1. da se koristi isključivo za formiranje kvalifikovanog elektronskog potpisa kvalifikovanih elektronskih sertifikata, kao i kvalifikovanog elektronskog potpisa statusa opozvanosti sertifikata,

2. da se koristi samo u okviru fizički zaštićenih prostorija sertifikacionog tela.

Sertifikaciono telo obezbeđuje da se njegovi asimetrični privatni ključevi ne koriste nakon isteka njihovog životnog ciklusa, u skladu sa Opštim i Internim pravilima rada. opije privatnih ključeva kojima je istekao životni ciklus oraju biti:

1. uništene na način kojim se obezbeđuje da se privatni ključ ne može rekonstruisati ili

2. sačuvane na način kojim se obezbeđuje zaštita od ponovnog korišćenja.

Sertifikaciono telo osigurava bezbednost kriptografskih uređaja koji se koriste za generisanje i čuvanje ključeva i formiranje kvalifikovanog elektronskog potpisa tokom životnog ciklusa uređaja, u skladu sa Internim pravilima rada, a posebno obezbeđuje da:

1. kriptografski uređaj nije kompromitovan tokom transporta,2. kriptografski uređaj nije kompromitovan za vreme čuvanja u sertifikacionom

telu,3. procedure instalacije, aktivacije, kreiranja rezervnih kopija i rekontrukcije

asimetričnog privatnog ključa u kriptografskom uređaju vrši samo uz istovremenu kontrolu najmanje dva zaposlena sa bezbednim funkcijama-rolama,

4. kriptografski uređaj funkcioniše korektno i5. obezbedi da se privatni ključevi sertifikacionog tela koji su čuvani u

kriptografskom uređaju unište nakon životnog ciklusa uređaja.

5.20.7 Zahvevi za obezbeđenjem zaštite od falsifikovanja sertifikata i tajnosti generisanih ključeva

128

Sertifikaciono telo mora osigurati bezbedan proces generisanja kvalifikovanih elektronskih sertifikata radi obezbeđenja njihove autentičnosti i integriteta.

U tom smislu, sertifikaciono telo obezbeđuje:

1. da se kvalifikovani elektronski sertifikati generišu u skladu sa formatom definisanim u dokumentu ETSI ESI TS 101 862,

2. da je procedura generisanja kvalifikovanog elektronskog sertifikata bezbedno povezana sa odgovarajućim procedurama registracije korisnika, obnavljanja sertifikata ili obnavljanja ključa, uključujući sve opcije generisanja asimetričnog javnog ključa od strane korisnika,

3. u slučaju da sertifikaciono telo generiše korisnikove ključeve:

i. da je procedura generisanja kvalifikovanog elektronskog sertifikata bezbedno povezana sa procedurom generisanja asimetričnog para ključeva od strane sertifikacionog tela,

ii. da je privatni ključ, ili sredstvo za formiranje kvalifikovanog elektronskog potpisa, bezbedno dostavljeno do registrovanog korisnika,

4. jedinstvenost dodeljenog imena korisniku u okviru domena sertifikacionog tela (za vreme radnog veka sertifikacionog tela mora se obezbediti da korisničko ime koje se dodeli u postupku generisanja sertifikata ne može nikada da se pridruži drugom korisniku),

5. tajnost i integritet registracionih podataka, i to posebno u slučajevima razmene podataka sa korisnikom ili u slučaju razmene informacija između distribuiranih komponenti sertifikacionog tela.

6. verifikaciju registracionih podataka koji su razmenjeni sa autentikovanim operatorom registracionog autoriteta, u slučaju da je korišćena eksterna služba za obezbeđivanje registracionih poslova.

Sertifikaciono telo obezbeđuje da zahtevi za obnavljanje kvalifikovanih elektronskih sertifikata i/ili zahtevi za izdavanje kvalifikovanih elektronskih sertifikata korisnicima kojima su prethodni sertifikati bili opozvani, budu kompletni, tačni i autorizovani.

U zahtevu za obnavljanjem sertifikata, sertifikaciono telo mora uneti ažurirane informacije o korisniku i sve druge izmene koje su prethodno verifikovane na isti način kao i u postupku registracije korisnika.

Sertifikaciono telo će izdati novi kvalifikovani elektronski sertifikat koristeći prethodno sertifikovani javni ključ korisnika samo ako je njegova kriptografska bezbednost još uvek dovoljna za predviđeni novi životni ciklus sertifikata i ako ne postoje indikacije da je korisnikov privatni ključ kompromitovan.

5.20.8 Zahtevi za odgovornošću i osiguranjem od rizika

Sertifikaciono telo je odgovorno da su svi sertifikacioni servisi navedeni u Politici sertifikacije konzistentni i implementirani u skladu sa Praktičnim pravilima. Pružanje usluga sertifikacije reguliše se posebnim Ugovorom između sertifikacionog tela i korisnika, u kome se definišu sledeće obaveze korisnika:

129

1. da dostavi tačne i kompletne informacije sertifikacionom telu u skladu sa procedurom registracije definisanom u Politici sertifikacije koja je izrađena u skladu sa Zakonom o elektronskom potpisu i podzakonskim aktima,

2. da isključivo koristi asimetrični par ključeva za formiranje kvalifikovanog elektronskog potpisa u skladu sa Ugovorom,

3. da onemogući neovlašćen pristup svom privatnom ključu, 4. da, ukoliko sam generiše asimetrični par ključeva:

i. za generisanje koristi propisani algoritam usaglašen za potrebe formiranja kvalifikovanog elektronskog potpisa,

ii. koristi propisanu dužinu ključa i propisani algoritam za formiranje kvalifikovanog elektronskog potpisa,

iii. obezbedi da jedino on poseduje svoj privatni ključ,

5. da koristi kvalifikovani elektronski sertifikat samo uz kvalifikovani elektronski potpis koji je formiran sredstvima za formiranje kvalifikovanog elektronskog potpisa,

6. da, ukoliko zahteva kvalifikovani elektronski sertifikat od sertifikacionog tela koje ispunjava uslove navedene u Zakonu o elektronskom potpisu i podzakonskom aktu, generiše par ključeva za formiranje kvalifikovanog elektronskog potpisa u sredstvu za formiranje kvalifikovanog elektronskog potpisa koje je u potpunosti pod njegovom kontrolom,

7. da odmah obavesti sertifikaciono telo ako se, pre isteka važnosti sertifikata koji je naznačen u samom sertifikatu, bilo koji od sledećih događaja desi:

i. korisnikov privatni ključ je izgubljen, ukraden ili postoji osnovana sumnja da je kompromitovan ili

ii. kontrola nad korišćenjem korisnikovog privatnog ključa je izgubljena iz razloga kompromitacije aktivacionih podataka (PIN kod ili lozinka) za sredstvo za formiranje kvalifikovanog elektronskog potpisa ili drugih razloga i/ili

iii. netačnost ili izmena sadržaja kvalifikovanog elektronskog sertifikata,

8. da prekine korišćenje svog privatnog ključa ukoliko postoji osnovana sumnja u kompromitaciju ključa ili kontrolu nad aktivacionim podacima za sredstvo za formiranje kvalifikovanog elektronskog potpisa.

Zainteresovane strane koje u jednom uspostavljenom PKI sistemu koriste kvalifikovane elektronske sertifikate imaju obavezu da:

1. provere važnost i ispravnost statusa suspenzije ili opoziva kvalifikovanog elektronskog sertifikata korišćenjem statusnih informacija koje je odgovarajuće sertifikaciono telo javno publikovalo (u zavisnosti od Opštih pravila rada sertifikacionog tela i primenjenih mehanizama za publikovanje informacija o statusu opoziva kvalifikovanih elektronskih sertifikata postoji mogućnost kašnjenja do jednog dana u ažuriranju statusnih informacija),

2. uzmu u obzir sva ograničenja u korišćenju kvalifikovanog elektronskog sertifikata koja su naznačena u samom sertifikatu ili publikovana u Opštim pravilima rada sertifikacionog tela.

130

Sertifikaciono telo obezbeđuje finansijske resurse za osiguranje od rizika i odgovornosti za moguću štetu nastalu vršenjem usluga izdavanja kvalifikovanih elektronskih sertifikata u skladu sa Zakonom o elektronskom potpisu i podzakonskim aktima. Način osiguranja, kao i odgovarajući iznos sredstava, moraju biti jasno navedeni u Opštim pravilima rada sertifikacionog tela.

5.20.9 Zahvevi za čuvanjem svih relevantnih informacija

Sertifikaciono telo mora da obezbedi čuvanje svih relevantnih informacija koje se tiču kvalifikovanih elektronskih sertifikata u vremenskom periodu definisanom u skladu sa Opštim pravilima rada, i to posebno u cilju obezbeđenja dokaza o izvršenoj sertifikaciji za pravne svrhe. Informacije koje se čuvaju uključuju podatke o registraciji korisnika i informacije o značajnim događajima vezanim za operativni rad sertifikacionog tela, kao i za upravljanje ključevima i sertifikatima.


1. tajnost i integritet tekućih i arhiviranih zapisa o kvalifikovanim elektronskim sertifikatima,

2. kompletno i pouzdano arhiviranje informacija o kvalifikovanim elektronskim sertifikatima u skladu sa objavljenim Opštim pravilima rada,

3. da su zapisi u vezi kvalifikovanih elektronskih sertifikata, kao i registracione i druge informacije o korisniku, raspoloživi za potrebe pravnih poslova kao dokaz izvršene sertifikacije.

4. pouzdano arhiviranje tačnog vremena značajnih događaja u sertifikacionom telu.

5. da se informacije u vezi kvalifikovanih elektronskih sertifikata čuvaju onoliko vremena koliko je potrebno da se koriste u pravnim poslovima vezanim za elektronske potpise.

6. evidentiranje svih događaja na način da se ne mogu lako obrisati ili uništiti (izuzev u cilju prenosa na dugotrajne medije za čuvanje) u okviru vremenskog perioda u kome se moraju čuvati.

7. dokumentovanje specifičnih događaja i podataka koji treba da se evidentiraju.8. evidentiranje svih događaja koji se odnose na registraciju korisnika, uključujući

i zahteve za obnavljanjem sertifikata, a naročito:

i. Tip identifikacionog dokumenta koji je prezentovan od strane korisnika,ii. Jedinstevni identifikacioni podatak o korisniku preuzet iz identifikacionog

dokumenta,iii. Mesto čuvanja kopija aplikativnih i identifikacionih dokumenata,

uključujući i potpisan Ugovor sa korisnikom,iv. Specifične elemente iz Ugovora sa korisnikom,v. Identitet službenika registracione lokacije koji je izvršio registraciju

korisnika,vi. Podatke o metodi koja je korišćena za validaciju identifikacionih

dokumenata,vii. Ime sertifikacionog tela koje je primilo registracione informacije i/ili ime

registracionog autoriteta koje je poslalo informacije.

9. zaštitu privatnosti podataka korisnika.

131

10.evidentiranje svih događaja u vezi sa životnim ciklusom ključeva sertifikacionog tela.

11.evidentiranje svih događaja u vezi sa životnim ciklusom kvalifikovanih elektronskih sertifikata.

12.evidentiranje svih događaja u vezi sa životnim ciklusom ključeva kojima upravlja sertifikaciono telo, uključujući i korisničke ključeve ako su generisani u sertifikacionom telu.

13.evidentiranje svih događaja koji se odnose na pripremu sredstava za formiranje kvalifikovanog elektronskog potpisa.

14.da se svi zahtevi i izveštaji koji se odnose na proceduru opoziva sertifikata evidentiraju, uključujući i sve odgovarajuće aktivnosti.

Sertifikaciono telo obezbeđuje minimalnu moguću štetu korisnicima i drugim zainteresovanim stranama u slučaju njegovog prestanka rada i kontinuirano čuvanje podataka koje se zahteva u pravnim procedurama kao dokaz izvršene usluge sertifikacije, a posebno obezbeđuje da:

1. pre prestanka pružanja usluga sertifikacije, izvršava sledeće aktivnosti:

i. informiše sve korisnike i druge zainteresovane strane o prestanku rada,ii. uništava, ili potpuno onemogućava korišćenje, svojih asimetričnih

privatnih ključeva koji su korišćeni za formiranje kvalifikovanog elektronskog potpisa kvalifikovanih elektronskih sertifikata.

2. obezbeđuje neophodna finansijska sredstva za realizaciju gore navedenih zahteva.

3. Opštim pravilima rada definiše proceduru prestanka rada, koja obuhvata:

i. obaveštavanje zainteresovanih strana,ii. eventualni prenos obaveza drugim sertifikacionim telima,iii. proceduru opoziva izdatih kvalifikovanih elektronskih sertifikata kojima

nije istekao rok važnosti.

5.20.10 Zahtevi za bezbednim uslovima za korisnike za koje se generišu podaci za formiranje elektronskog potpisa

Sertifikaciono telo obezbeđuje da su ključevi korisnika koje ono generiše, generisani bezbedno i da je osigurana tajnost privatnog ključa korisnika.


1. da se asimetrični par korisničkih ključeva generiše korišćenjem algoritma koji je propisan da zadovolji zahteve koji se primenjuju za kvalifikovane elektronske potpise.

2. da su asimetrični ključevi korisnika propisane dužine i korišćeni u propisanom asimetričnom kriptografskom algoritmu u cilju da se zadovolje propisani zahtevi za implementacijom kvalifikovanog elektronskog potpisa.

3. da se korisnički ključevi bezbedno generišu i čuvaju pre nego što se dostave korisniku.

132

4. da je asimetrični privatni ključ bezbedno dostavljen korisniku na takav način da je tajnost ključa obezbeđena i da pri isporuci samo korisnik ima pristup svom privatnom ključu.

Ukoliko sertifikaciono telo obezbeđuje sredstva za formiranje kvalifikovanog elektronskog potpisa za korisnike, to čini na bezbedan način u skladu sa standardom ISO/IEC 15408 ili drugim odgovarajućim standardom, a posebno obezbeđuje da:

1. priprema sredstva za formiranje kvalifikovanog elektronskog potpisa mora biti bezbedno kontrolisana od strane sertifikacionog tela,

2. sredstva za formiranje kvalifikovanog elektronskog potpisa moraju biti bezbedno čuvana i distribuirana,

3. deaktiviranje i reaktiviranje sredstava za formiranje kvalifikovanog elektronskog potpisa mora biti bezbedno kontrolisano od strane sertifikacionog tela,

4. ukoliko sredstva za formiranje kvalifikovanog elektronskog potpisa imaju pridružene aktivacione podatke (PIN kod ili lozinka) isti moraju biti bezbedno pripremljeni i distribuirani odvojeno u odnosu na sredstvo za formiranje kvalifikovanog elektronskog potpisa. Odvojeno slanje može biti obezbeđeno ili dostavom u različito vreme ili na različiti način.

5.20.11 Zahtevi za sisteme fizičke zaštite uređaja, opreme i podataka i sigurnosna rešenja zaštite od neovlašćenog pristupa

Sertifikaciono telo obezbeđuje kontrolu fizičkog pristupa svojim bezbednosno kritičnim resursima, kao i minimizaciju rizika u pristupu svojim ključnim elementima.

U tom smislsu, sertifikaciono telo obezbeđuje:

1. da se fizički pristup prostorijama u kojima se obavlja generisanje kvalifikovanih elektronskih sertifikata, priprema sredstava za formiranje kvalifikovanog elektronskog potpisa i upravljanje procedurom opoziva sertifikata, ograniči samo na pouzdano autorizovane osobe.

2. da su implementirane neophodne mere u cilju izbegavanja gubitaka, oštećenja ili kompromitovanja ključnih resursa i eliminisanje mogućnosti prekida poslovnih aktivnosti.

3. da se implementiraju odgovarajuće mere za sprečavanje kompromitacije ili krađe informacija i/ili uređaja za procesiranje informacija.

4. da su prostorije u kojima se vrši generisanje kvalifikovanih elektronskih sertifikata, priprema sredstava za formiranje kvalifikovanog elektronskog potpisa i upravljanje opozivom, takve da se operativni rad u njima odvija u okruženju koje obezbeđuje fizičku zaštitu sertifikacionih servisa i resursa od kompromitacije prouzrokovane neautorizovanim pristupom sistemu i podacima.

5. da je fizička zaštita uspostavljena kreiranjem jasno definisanih bezbednosnih perimetara (tj. fizičkih barijera) kojima se štite procesi generisanja kvalifikovanih elektronskih sertifikata, obezbeđenja sredstava za formiranje kvalifikovanog elektronskog potpisa i upravljanje opozivom. Bilo koji deo poslovne zgrade koji se deli sa drugim organizacijama mora biti izvan ovih perimetara.

133

6. da su implementirane odgovarajuće fizičke mere i kontrole bezbednosnog okruženja u cilju zaštite prostorija i sistemskih elemenata sertifikacionog tela.

7. da su implementirane odgovarajuće mere u cilju zaštite uređaja, informacija, memorijskih medija i softvera od otuđivanja sa lokacije bez propisne autorizacije.

8. da su sistemi fizičke zaštite i zaštite bezbednosnog okruženja u skladu sa ISO/IEC 17799 standardom kao uputstvom za fizičku bezbednost i bezbednost okoline.

9. da se i druge specifične bezbednosne funkcije mogu primeniti u okviru istog bezbednog prostora koji obezbeđuje pristup samo autorizovanim zaposlenim osobama.

Sertifikaciono telo obezbeđuje da je pristup sistemu sertifikacije ograničen isključivo na pouzdano autorizovane osobe, a naročito obezbeđuje:

1. implementaciju kontrola na mrežnom nivou (na primer firewall-i) u cilju zaštite interne mreže sertifikacionog tela od eksternih mrežnih domena kojima može pristupiti treća strana. Potrebno je da su firewall-ovi konfigurisani tako da zabrane sve protokole i pristupe koji se ne koriste u operativnom radu sertifikacionog tela.

2. pouzdanu zaštitu osetljivih podataka, koji uključuju i podatke o registraciji korisnika, tokom prolaska kroz delove mreže koji nisu bezbedni.

3. efikasnu i pouzdanu administraciju korisničkih pristupa (uključujući operatore, administratore i bilo koje specifične korisnike koji imaju direktan pristup sistemu) u cilju održavanja bezbednosti sistema, uključujući i upravljanje nalozima korisnika, evidentiranje i mogućnost modifikacije i zabrane pristupa.

4. strogo ograničen pristup informacijama i aplikativnim funkcijama sistema u skladu sa Opštim pravilima rada i Politikom kontrole pristupa, identifikovanom u njima, kao i dovoljnu računarsko-bezbednosnu kontrolu u cilju razdvajanja bezbednih funkcija – rola u sistemu koje su identifikovane u Opštim pravilima rada, uključujući razdvajanje funkcija administratora bezbednosti i operatera, a posebno rad sa korisničkim programima za upravljanje sistemom mora biti posebno ograničeno i strogo kontrolisano.

5. pouzdanu identifikaciju i autentikaciju zaposlenih u sertifikacionom telu pre korišćenja kritičnih operacija vezanih za procedure upravljanja sertifikatima.

6. evidentiranje svih aktivnosti zaposlenih u sertifikacionom telu na osnovu odgovarajućih korisničkih naloga i log fajlova.

7. pouzdanu zaštitu bezbednosno osetljivih podataka, koji uključuju i registracione podatke korisnika, od neautorizovanog pristupa na osnovu ponovnog korišćenja prethodno obrisanih ili arhiviranih podataka.

8. da se lokalne mrežne komponente (ruteri i sl.) čuvaju u fizički zaštićenom okruženju i da se njihova konfiguracija periodično kontroliše u cilju ispitivanja usklađenosti sa zahtevima specificiranim u Opštim i Internim pravilima rada.

9. uređaje za kontinualno monitorisanje i alarmiranje (sistemi za detekciju napada i sistemi za monitorisanje kontrole pristupa i alarma) za pouzdanu detekciju, registraciju i reakciju na bilo kakav neautorizovani i/ili neregularni pokušaj pristupa resursima koja se koriste za pružanje usluga sertifikacije.

10.da aplikacija za distribuciju sertifikata mora primeniti sistem logičke kontrole pristupa u cilju sprečavanja pokušaja dodavanja ili brisanja odgovarajućih sertifikata i modifikacije drugih pridruženih informacija.

134

11.da aplikacija za dobijanje statusa opoziva sertifikata primenjuje sistem logičke kontrole pristupa u cilju sprečavanja pokušaja modifikacije informacija o statusu opoziva sertifikata.

5.20.12 Zahtevi za raspoloživošću informacija o uslovima izdavanja i korišćenja sertifikata

Sertifikaciono telo obezbeđuje da su sve potrebne informacije o uslovima izdavanja i korišćenja kvalifikovanih elektronskih sertifikata raspoložive korisnicima i drugim zainteresovanim stranama. Sertifikaciono telo obezbeđuje raspoloživost informacija i podataka o svom poslovanju, i to:

1. Opšta pravila rada sertifikacionog tela koja su trenutno važeća,2. Ograničenja u korišćenju Opštih pravila rada,3. Obaveze korisnika,4. Informacije o načinu provere važnosti kvalifikovanih elektronskih sertifikata,

uključujući i zahteve za proveru statusa opoziva sertifikata,5. Ograničenja odgovornosti koja uključuju slučajeve za koje sertifikaciono telo

prihvata (ili odbija) odgovornost,6. Vremenski period čuvanja registracionih informacija korisnika,7. Vremenski period čuvanja log fajlova za evidentiranje,8. Procedure za rešavanje žalbi i sporova,9. Pravni sistem koji se primenjuje i10. Informaciju o statusu eventualne akreditacije.

Sertifikaciono telo obezbeđuje da su navedene informacije neprekidno raspoložive korišćenjem jednostavnih vidova komunikacije (Internet i sl.) sa obezbeđenim integritetom tokom vremena, da mogu se prenositi elektronskim putem i da su prikazane na potpuno razumljiv način.

5.20.13 Zahtevi za sistem upravljanja sertifikatima

Sertifikaciono telo obezbeđuje uvid u izdate, opozvane i suspendovane kvalifikovane elektronske sertifikate svim korisnicima i drugim zainteresovanim stranama.


1. da je izdati kvalifikovani elektronski sertifikat raspoloživ korisniku kome je sertifikat izdat,

2. da su kvalifikovani elektronski sertifikati rapoloživi trećim licima samo u onim slučajevima za koje je dobijen pristanak korisnika, a u skladu sa Opštim pravilima rada sertifikacionog tela,

3. raspoloživost informacija o uslovima izdavanja i korišćenja kvalifikovanih elektronskih sertifikata svim zainteresovanim stranama u sistemu,

4. da se primenjeni uslovi mogu lako identifikovati za dati sertifikat,5. da su gore navedene informacije raspoložive 24 časa na dan, 7 dana u

sedmici. Nakon pada sistema, ili delimičnog gubitka mogućnosti za obezbeđenje servisa, sertifikaciono telo mora da primeni sve raspoložive mere

135

da ovaj informacioni servis bude ponovo aktivan što pre, ali najkasnije do isteka roka predviđenog u Opštim pravilima rada sertifikacionog tela.

Gore navedene informacije moraju biti javno dostupne.

5.21 Aspekti interoperabilnosti PKI sistema

5.21.1 Kriterijumi i proces krossertifikacije

Krossertifikacija predstavlja proces uspostavljanja poslovnog poverenja između dva CA koji se nalaze ili u istom ili u različitim PKI domenima. Ta dva CA mogu biti bilo gde u svom hijerarhijskom PKI domenu (root CA, potčinjeni CA ili nadređeni CA).

U slučaju da se radi o istom PKI domenu imamo potčinjeni CA i nadređeni CA. Nadređeni CA sertifikuje sertifikacioni ključ drugog, podređenog CA. Nadređeni CA može biti root CA čiji javni ključ služi kao osnov poverenja u bezbednosnom domenu. U slučaju da se radi istom PKI domenu proces interoperabilnosti je uslovljen tehničkim uslovima i politikom nadredjenog CA.

Komplikovaniji slučaj je krossertifikacija dva CA iz različitih PKI domena. U ovom slučaju se može utvrditi procedura i kriterijumi za krossertifikaciju. Ta procedura može da bude organizovana na sledeći način.

Faze krossertifikacije mogu biti: iniciranje postupka, poredjenje politika, test, ugovaranje i održavanje sistema. Proces sertifikacije mogu voditi dva CA međusobno ili svaki od CA sa posebnom institucijom koja je specijalizovana za krossertifikaciju.

Ta posebna institucija se naziva BCA (Bridge Certification Authority). U slučaju retkih odnosa krossertifikacije postojanje posebne institucije nije opravdano. Ali, u slučaju masovnog procesa krossertifikacije, naročito u slučaju kada se radi o krossertifikaciji jednog ili više manjih CA sa vladinim ili nekim drugim masovnim CA, postojanje posebne institucije je koja vodi proces krossertifikacije je od izuzetne važnosti.

5.21.1.1 Faza inicijacije krossertifikacije

Faza inicijacije počinje popunjavanjem zahteva, preliminarnim pregledom forme i kompletnosti dokumentacije. Vlada može propisati neophodne uslove koje kandidat treba da ispuni za započinjanje procesa krossertifikacije. Zahtev može da podnese druga vladina organizacija, komercijalna organizacija koja ima brojne kontakte sa vladinim organizacijama, nekomercijalna organizacija koja, takođe, ima brojne poslovne kontakte sa vladinim organizacijama ili čak organizacija iz druge države.

Spisak neophodnih opštih akata može biti: dokumenta o pravnoj zasnovanosti PKI entiteta, pravnoj nadležnosti, finansijskoj sposobnosti za podnošenje finansijskog rizika i osiguranja za izdate sertifikate.

Kandidat treba da poseduje niz sledećih dokumenata: politiku sertifikacije CA (certificate policy), praktična pravila rada CPS, bezbednosnu politiku, detaljan opis

136

tehnologije rada, dokumentaciju o tehnološkoj kompatibilnosti sistema, očekivani nivo poverenja u kros sertifikate, pravni status i finansijske mogućnosti.

Dokumentovana organizacija posla CA mora biti implementirana i demonstrirana.

Kandidat za kros-sertifikaciju mora da se odluči koje elemente svoje politike i prakse želi da sertifikuje. Slično treba da uradi i drugi kandidat ili kandidati i da se kroz proces kros-sertifikacije načini zajednička politika i praksa koja će važiti za kros-sertifikat. Takodje je neophodno odrediti zajednički nivo poverenja.

Kao što se vidi radi se o vrlo osetljivom i dugotrajnom procesu, pogotovu ako se radi o više kandidata.

5.21.1.2 Poređenje i usklađivanje politika

Proces poređenja i usklađivanja politika kandidata za krossertifikaciju naziva se mapiranje politika. Proces mapiranja politika obuhvata poređenje dve ili više politika kako po sličnosti tako i po razlikama. Poređenjem je neophodno obuhvatiti politiku, praksu i procedure koje moraju biti usklađene. Lista kategorija koje se porede obuhvaćena je matricom mapiranja. Analiza matrice mapiranja pokazuje elemente poslovanja različitih CA koji su uporedivi ili ekvivalentni i na osnovu kojih se može napraviti zajednička politika ili doneti dogovor o usklađivanju bitnih elemenata politike.

Dokumenti sertifikacione politike različitih kandidata mogu biti organizovani na posebne načine, imati delove koji se drugačije zovu, terminologija ne mora biti usklađena, mogu postojati reference na različita spoljna dokumenta. Na primer, ključni izraz poverljiv može za jednu sertifikacionu politiku značiti jedno, a sasvim nešto drugo za nekog drugog kandidata za krossertifikaciju.

Rezultati mapiranja politika upisuju se u matricu mapiranja. Posebno treba naglasiti elemente koji nisu prisutni u sertifikacionoj politici, a postoje u matrici mapiranja. Prikupljanje podataka i popunjavanje matrice mapiranja je vrlo važan proces i ne može biti vremenski ograničen. Ne završava se sve dok se ne prikupe svi neophodni podaci.

Kroz proces mapiranja politika utvrđuje se mera ili stepen usaglašenosti razičitih stvari sa ciljem da se uspostavi što značajniji stepen poverenja ili da se odredi mera različitosti. Ako je to potrebno, kroz proces usaglašavanja je moguće dovesti do povećanog stepena usaglašenosti.

Po utvrdjivanju ekvivalencije generiše se krossertifikat koji predstavlja potvrdu medjusobnog poverenja izmrđu dva ili više sertifikacionih entiteta.

5.21.1.3 Testiranje

Kroz proces testiranja tehničke interoperabilnosti proverava se i potvrđuje saglasnost tehnoloških sistema kandidata za krossertifikaciju. Cilj je da se utvrdi da li je moguća razmena kros-sertifikata i da li su obostrano dostupni direktorijumi sa javnim

137

podacima. Pogodno je da postoje testna okruženja, kao kopije produkcionog, i da se na njima radi kao na prototipu, a da se zatim pređe na produkciju.

Minimum neophodnih testova bi obuhvatao: mrežnu povezanost po potrebnom skupu protokola; interoperabilnost sistema direktorijuma; obostrano prepoznavanje kros-sertifikata izdatih od strane drugog kandidata; testiranje procedure provere sertifikata izdatog klijentu od drugog kandidata i mogućnost razmene liste povučenih sertifikata. Uspešnim okončanjem testiranja tehničke interoperabilnosti ispunjeni su tehnički zahtevi za krossertifikaciju.

5.21.1.4 Ugovaranje

Posle faza potvrde tehničke interoperabilnosti i mapiranja politika analiriza se usklađenost dobijenih podataka sa očekivanim nivoom međusobnog poverenja. U koliko su svi izveštaji povoljni pristupa se kreiranju finalnog dokumenta, ugovora u kome su definisana obostrana prava, obaveze i specifičnosti kandidata.

5.21.1.5 Održavanje sistema

Posle uspešnog procesa krossertifikacije, potpisivanja ugovora i izdavanja krossertifikata bivši kandidati, a sad članovi, svoje odnose periodično analiziraju. Samim Ugovorom je predviđena dinamika periodične analize trenutne politike i prakse rada svakog od potpisnika.

Članovi mogu raskinuti ugovor ako nema obostranog interesa za postojanje kros-sertifikata ili se ne poštuju preuzete obaveze bilo da su u domenu sertifikacione politike ili tehničke interoperabilnosti.

5.22 Dosadašnja iskustva u izgradnji Sertifikacionih tela

Svetski trendovi u razvoju i primeni tehnika zaštite informacionih sistema i savremenih kriptografskih protokola su u sve većoj primeni PKI sistema i bezbednosnih mehanizama baziranih na smart karticama.

U tome prednjače zemlje Evropske unije ali situacija ni izdaleka nije ujednačena i stepen primene PKI sistema se razlikuje od zemlje do zemlje.

U razvijenim zapadnim zemljama, najvažnije aplikacije elektronskog poslovanja koje se razmatraju i primenjuju i u kojima se primenjuju bezbednosnni mehanizmi su:

e-banking e-Invoicing, e-Contracts i e-Government.

Osnovni elementi kojima se karakteriše stanje u zapadnim zemljama (i to pre svega u zemljama Evropske unije) sa stanovišta primene bezbednosnih mehanizama su:

138

Većina zemalja članica Evropske unije donele su zakone o elektronskim potpisima u svojim zemljama u skladu sa EU Direktivom o elektronskim potpisima u roku koji je propisan (19.07.2001.). Pored toga, i mnoge druge zemlje u Evropi i svetu su usvojile odgovarajuće zakone koje su manje ili više usklađene sa evropskom Direktivom. Međutim, bez obzira na generalnu usklađenost svih zakona međusobno, postoje određena otvorena pitanja za koja postoje različite interpretacije u pojedinim zakonima iz razloga što ta pitanja ni u Direktivi nisu najpreciznije definisana. Otvorena pitanja utiču na to da se razmatra mogućnost ažuriranja teksta Direktive o elektronskim potpisima. Među najznačajnijim otvorenim pitanjima međunarodne tehnološke i pravne usklađenosti propisa o elektronskom poslovanju i elektronskom potpisu nalaze se:

o Problem standardizacije tehnološkog postupka generisanja kvalifikovanog elektronskog potpisa (kako se pravna regulativa pojedinih zemalja odnosi prema međunarodnim standardizacionim inicija-tivama u domenu elektronskog potpisa (npr. EESSI – European Electronic Signature Standardization Initiative)),

o Problem akreditacije i supervizije certifikacionih tela u različitim zemljama,

o Pravni status elektronskih certifikata koji ne zadovoljavaju uslove da budu kvalifikovani elektronski certifikata, i kako se to rešava u pojedinim zemljama,

o Problem odgovornosti certifikacionih tela i kako se on u pojedinim zemljama rešava,

o Problem u nepostojanju dovoljnog broja praktičnih realizacija sistema sa primenom kvalifikovanog digitalnog potpisa i nejasne situacije u vezi toga kada je on stvarno potreban,

o Problem u nedovoljno preciznim definicijama (od zemlje do zemlje) uređaja za generisanje kvalifikovanog digitalnog potpisa.

U svetu se sve više i više razmatraju i uvode sistemi masovnog korišćenja smart kartica kao ID dokumenata, ali uglavnom u manjim zemljama (Estonija, Finska, Belgija, Švedska, Hong Kong, Makao, Malezija). Ove smart kartice se uglavnom uvode u obliku multiaplikativnih smart kartica koje treba da omoguće korišćenje u postojećim i budućim e-government aplikacijama.

Takođe, postoje primeri uvođenja smart kartica kao zdravstvenih knjižica (Slovenija, Tajvan),

U svetu postoje primeri sve većeg uvođenja elektronskog bankarstva na bazi smart kartica (pre svega u domenu zaštićene veze firma – banka) ali ne u očekivanom broju (što pogotovo važi u domenu elektronskog plaćanja fizičkih lica),

U svetu postoji sve više primera migracije na EMV (Europay Mastercard Visa) platformu primene smart kartica umesto magnetnih platnih kartica, ali za sada uglavnom u obliku SDA (Static Data Authentication) modusa.

U svakom slučaju, u svetu se polako uvodi PKI tehnologija uz rešavanje u hodu manjih ili većih problema na koje se nailazi. U tom smislu, na ISSE 2002 iznet podatak da je tek 20 % PKI sistema u svetu u proizvodnji a da je čak 80 % tek u pilot fazi, slika 5.7.

139

Jedan od najvećih izazova i problema je u interoperabilnosti PKI sistema. Naime, današnji PKI sistemi se mogu posmatrati uglavnom kao zasebna ostrva, slika 5.8, između kojih je prilično komplikovano realizovati komunikaciju. U cilju prevazilaženja ovih problema, u svetu se razmatraju različite inicijative i realizuju se različiti projekti koji na različite načine rešavaju problem interoperabilnosti PKI sistema, kao što su projekti: EuroPKI, PKI Challenge, Bridge CA, i drugi.

Pored toga, treba napomenuti da se u svetu sve više i više uvode biometrijski sistemi u kombinaciji sa primenom smart kartica, i to kako za logovanje na različite aplikacije, tako i za logovanje na sam PC računar (Win Logon procedure). Ovi sistemi ne služe samo za logovanje korisnika na klijentske radne stanice već i za prijavljivanje korisnika na čitav mrežni sistem – proverom njegovih bezbednosnih parametara (najčešće X.509 digitalnih certifikata u centralnoj bazi podataka), slika 5.9.

Slika 5.7: Stanje realizacije PKI sistema u svetu

140

Slika 5.8: Različiti PKI sistemi kao zasebna ostrva u sistemima elektronskog poslovanja

Slika 5.9: Primena otiska prsta u cilju biometrijske autentikacije korisnika na centralnom mrežnom serveru baze podataka

141

6. Implementacija Sistema upravljanja informatičkom bezbednošću u Organizaciji po standardu ISO/IEC 27001:2005

6.1 Uvod

U ovom poglavlju je razmatrana moguća uspostava Sistema upravljanja informatičkom bezbednošću (ISMS – Information Security Management System) u skladu sa ISO/IEC 27001:2005 standardom u Organizaciji. Posebno su razmatrani aspekti bezbednog upravljanja elektronskom dokumentacijom, kao i sam proces sertifikacije.

6.2 Istorijat ISO/IEC 27001:2005 standarda

Međunarodni standard ISO/IEC 27001 je pripremljen da obezbedi jedan model za uspostavu, implementaciju, operativni rad, nadzor, pregled, održavanje i poboljšavanje Sistema za upravljanje informatičkom bezbednošću (ISMS – Information Security Management System).

Usvajanje ISMS sistema treba da bude strateška odluka za jednu organizaciju. Dizajn i implementacija ISMS sistema u organizaciji je pod uticajem njenih potreba i ciljeva, bezbednosnih zahteva, procesa koji se izvršavaju, kao i uslovljen veličinom i strukturom organizacije.

Očekuje se da jedna implementacija ISMS sistema treba da bude prilagođena potrebama organizacije, na primer jednostavna situacija zahteva jednostavno ISMS rešenje.

ISO 27001 standard je usvojio procesni pristup za uspostavu, implementaciju, operativni rad, nadzor, pregled, održavanje i poboljšavanje ISMS sistema. Organizacija mora da identifikuje i upravlja mnogim aktivnostima u cilju da funkcioniše efektivno. Bilo koja aktivnost koja koristi resurse i upravlja se u cilju da omogući transformaciju nekih ulaza u izlaze može se posmatrati kao proces. Često izlaz jednog procesa direktno formira ulaz za sledeći proces, itd. Primena sistema procesa u okviru organizacije, zajedno sa identifikacijom i interakcijom tih procesa, kao i njihovo upravljanje može se posmatrati kao „procesni prilaz”.

Procesni prilaz upravljanju informatičke bezbednosti koji je predstavljen u ISO 27001 standardu naglašava važnost:

a. Razumevanja zahteva za informatičkom bezbednošću u organizaciji, kao i potrebe da se uspostavi politika i ciljevi informatičke bezbednosti;

b. Implementacije i primene kontrola za upravljanje rizicima informatičke bezbednosti u organizaciji u kontekstu sveukupnih poslovnih rizika organizacije;

c. Nadzora i pregleda performansi i efektivnosti ISMS sistema; d. Kontinualnog poboljšanja na bazi objektivnog merenja.

142

ISO/IEC 27001 standard usvaja “Plan-Do-Check-Act” (PDCA) model, slika 6.1, koji se primenjuje da struktuira sve ISMS procese. Naime, ISMS sistem uzima kao ulaz zahteve za informatičkom bezbednošću, kao i očekivanja zainteresovanih strana, i kroz neophodne akcije i procese proizvodi izlaze informatičke bezbednosti koji zadovoljavaju pomenute zahteve i očekivanja.

Plan (uspostava ISMS sistema)

Uspostava ISMS politike, ciljeva, procesa i procedura koji su relevantni za upravljanje rizikom i poboljšanje informatičke bezbednosti u cilju dobijanja rezultata koji su u skladu sa sveukupnim politikama i ciljevima organizacije.

Do (implementacija i operativni rad ISMS sistema)

Implementacija i operativni rad ISMS politike, kontrola, procesa i procedura.

Check (nadzor i pregled ISMS sistema)

Ocenjivanje i, tamo gde je to primenjljivo, merenje performansi procesa u odnosu na ISMS politiku, ciljeve i praktično iskustvo, kao i izveštavanje o rezultatuma menadžemntu za svrhu pregleda.

Act (održavanje i poboljšavanje ISMS sistema)

Primena korektivnih i preventivnih akcija, baziranih na rezultatima internog ISMS audita i pregleda od strane menadžmenta ili drugih relevantnih informacija, u cilju postizanja kontinualnog poboljšanja ISMS sistema.

Slika 6.1: PDCA model po ISO 27001 standardu

143

Istorijat geneze dokumenata vezanih za standarde ISO 17799 i 27001, kao i za BS 7799 može se prikazati na sledeći način (veza između izlistanih standarda je prikazana i na slici 6.2):

Industrijska radna grupa – januar 1993, Izdat kod prakse (Code of Practice) – septembar 1993, BS 7799: Part 1 publikovan – februar 1995, BS 7799: Part 2 publikovan – februar 1998, BS 7799: Part 1 i Part 2 – april 1999, ISO 17799 (BS 7799-1) – publikovan 2000, BS 7799-2 – publikovan 2002, ISO/IEC 17799: 2005 – nova verzija u 2005. godini, publikovana u junu 2005.

ISO 17799: 2000 verzija povučena. ISO/IEC 27001: 2005 – nova verzija standarda u 2005. godini, publikovana u

novembru 2005. BS 7799-2: 2002 verzija povučena.

Slika 6.2: Veze izmedju različitih standarda

Dakle, danas aktuelni standardi u domenu informatičke bezbednosti su:

ISO/IEC 27002: 2005 – Information Technology – Security Techniques – Code of practice for information security management (nekada 17799 standard),

o Obezbeđuje smernice najboljeprakse za ISMS sistemo Definiše skup ciljeva kontrola, kontrola, kao i smernica za

implementaciju.o Ne može se koristiti za ocenjivanje i sertifikaciju.

144

ISO/IEC 27001:2005 – Information Technology – Security Techniques – Information Security Management Systems – Requirements

o Definiše specifične zahteve za uspostavu, implementaciju, operativni rad, nadzor, pregled, održavanje i poboljšanje dokumentovanog ISMS sistema.

o Izrađen da osigura adekvatne bezbednosne kontrole da zaštiti informaciona dobra i dokumentuje ISMS sistem.

o Može se koristiti za ocenjivanje i sertifikaciju.

6.3 Uspostava i upravljanje ISMS sistemom

6.3.1 Uspostava ISMS (Plan)

U cilju uspostave ISMS sistema organizacija treba da izvrši sledeće aktivnosti:

a) Definiše okvir i granice ISMS u skladu sa karakteristikama svog poslovanja, organizacije, lokacijom, imovinom i tehnologijama, uključujući i relevantne detalje;

b) Definiše ISMS politiku u skladu sa karakteristikama svog poslovanja, organizacije, lokacijom, imovinom i tehnologijama tako da:

1. Uključi okvir za postavljanje ciljeva i uspostavi opšte viđenje pravca i principa za aktivnosti povezane sa informatičkom bezbednošću;

2. Uzme u obzir poslovne i pravne ili regulatorne zahteve, kao i ugovorne bezbednosne obaveze;

3. Uskladi se sa kontekstom strateškog upravljanja rizikom u organizaciji u kome je uključena uspostava i održavanje ISMS;

4. Uspostave se kriterijumi u odnosu na koje će se rizici evaluirati,5. Odobrena je od strane menadžmenta.

Napomena: U okviru ISO/IEC 27001, ISMS politika (ili Top Level Security Policy) predstavlja nadskup politika informatičke bezbednosti koje treba da se definišu u pojedinim oblastima koje standard pokriva.

c) Definiše pristup ocenjivanju rizika u organizaciji

1. Identifikuje metodologiju ocenjivanja rizika koja odgovara ISMS sistemu, kao i identifikovanim pravnim, regulatornim i poslovnim zahtevima za informatičku bezbednost,

2. Razvije kriterijume za prihvatanje rizika, kao i za identifikaciju prihvatljivog nivoa rizika.

145

Odabrana metodologija ocenjivanja rizika treba da osigura da ocena rizika proizvede uporedive i reproduktabilne rezultate.

d) Identifikuje rizike

1. Identifikuje dobra u granicama okvira ISMS sistema, kao i vlasnike pomenutih dobara. Termin vlasnik identifikuje pojedinca ili entitet koji ima od strane menadžmenta odobrenu odgovornost za kontrolu proizvodnje, razvoja, održavanje, korišćenja i obezbeđivanja dobra, Termin vlasnik ne znači da ta osoba poseduje bilo kakva vlasnička prava nad tim dobrom organizacije.

2. Identifikuje pretnje nad ovim dobrima.3. Identifikuje ranjivosti koje mogu biti iskorišćene od strane navedenih

pretnji. 4. Identifikuje uticaje koje gubici na tajnosti, integritetu i raspoloživosti

mogu imati nad dobrima organizacije.

e) Analizira i evaluira rizike1. Ocenjuje poslovne uticaje na organizaciju koji mogu da rezultuju na

bazi bezbednosnih ispada, uzimajući u obzir gubitke na tajnosti, integritet i raspoloživost dobara.

2. Ocenjuje realnu verovatnoću bezbednosnih ispada koji se dešavaju u svetlu preovlađujućih pretnji i ranjivosti, kao i uticaje koji su pridruženi tim dobrima, kao i trenutno implementirane kontrole.

3. Ocenjuje nivoe rizika.4. Određuje da li su rizici prihvatljivi ili se zahteva odgovarajući tretman

korišćenjem uspostavljenih kriterijuma za prihvatanje rizika.

f) Identifikuje i evaluira opcije tretmana rizikaMoguće aktivnosti uključuju:

1. Primena odgovarajućih kontrola.2. Svesno i objektivno prihvatanje rizika, obezbeđujući da oni jasno

zadovoljavaju politike i kriterijume organizacije za prihvatanje rizika.3. Izbegavanje rizika.4. Prebacivanje pridruženih poslovnih rizika na druge strane, kao na

primer: dobavljače, osiguranje, itd.

g) Selektuje ciljeve kontrola, kao i same kontrole, za tretman rizikaCiljevi kontrola i same kontrole treba da budu izabrane i implementirane da zadovolje zahteve koji su identifikovani u procesima ocene i tretmana rizika. Ovaj izbor treba da uzme u obzir kriterijume za prihvatanje rizika, kao i eventualne pravne, regulatorne i ugovorne zahteve.

h) Dobije odobrenje od menadžmenta za predložene preostale (rezidualne) rizike

i) Dobije autorizaciju od strane menadžemnta da implementira i pusti u operativni rad ISMS sistem

146

j) Pripremi Izjavu o primenljivosti (Statement of Applicatbility)Izjava o primenljivosti treba da bude pripremljena tako da uključuje sledeće:

1. Izabrane ciljeve kontrola, kao i same kontrole, kao i razloge zašto su izabrani.

2. Ciljeve kontrola i same kontrole koje su trenutno implementirane.3. Isključivanje bilo kojih ciljeva kontrola i samih kontrola koje su

definisane ISO/IEC 27001 standardom, kao i obrazloženje za njihovo isključivanje.

Napomena: Izjava o primenljivosti obezbeđuje rezime o odlukama koje se tiču tretiranja rizika. Obrazloženi izuzeci obezbeđuju jednu dodatnu proveru da nijedna kontrola nije nehotično izostavljena.

6.3.2 Implementacija i operativni rad ISMS sistema (Do)

U cilju implementacije i uspostave operativnog rada ISMS sistema organizacija treba da izvrši sledeće aktivnosti:

a) Formuliše plan tretiranja rizika u kome identifikuje odgovarajuće upravne akcije, resurse, odgovornosti i prioritete za upravljanje rizicima informatičke bezbednosti.

b) Implementira plan tretiranja rizika u cilju postizanja identifikovanih ciljeva kontrola, koje uključuju razmatranje budžeta, kao i dodeljivanja uloga i odgovornosti.

c) Implementira izabrane kontrole da bi se zadovoljili postavljeni ciljevi kontrola.

d) Definiše kako da se meri efektivnost izabranih kontrola, ili grupa kontrola, kao i da specificira kako ove mere treba da se koriste da bi se ocenila efektivnost kontrola a da bi se dobili uporedivi i reprodukabilni rezultati. Merenje efektivnosti kontrola omogućava menadžerima i zaposlenima da odrede koliko dobro primenjene kontrole postižu postavljene ciljeve kontrola.

e) Implementiraju obuku i programe za podizanje svesti zaposlenih o informatičkoj bezbednosti.

f) Upravljaju operativnim radom ISMS sistemag) Upravljaju resursima neophodnim za ISMSh) Implementiraju procedure, kao i druge kontrole, koje omogućavaju

promptnu detekciju bezbednosnih događaja i odgovore na bezbednosne incidente.

6.3.3 Nadzor i preispitivanje ISMS sistema (Check)

U cilju nadzora i preispitivanja implementiranog ISMS sistema organizacija treba da izvrši sledeće aktivnosti:

a) Izvrši procedure nadzora i preispitivanja, kao i druge kontrole, za:

1. Promptnu detekciju grešaka u rezultatima procesiranja.

147

2. Promptnu identifikaciju pokušanih i uspešnih bezbednosnih proboja i incidenata.

3. Omogućenje menadžmentu da odredi da li su bezbednosne aktivnosti delegirane zaposlenima, ili implementirane putem informacionih tehnologija, implementirane kako se i očekivalo.

4. Pomoć u vezi detekcije bezbednosnih događaja korišćenjem indikatora čime se sprečavaju bezbednosni incidenti.

5. Određivanje da li su akcije preduzete u cilju rešavanja bezbednosnih ispada bile efektivne.

b) Primeni regularna preipitivanja efektivnosti ISMS sistema (uključujući zadovoljavanje ISMS politike i ciljeva, kao i preispitivanje bezbednosnih kontrola) uzimajući u obzir rezultate bezbednosnih auditinga, incidenata, rezultata merenja efektivnosti, sugestija, kao i povratnih informacija od svih zainteresovanih strana.

c) Meri efektivnost kontrola u cilju verifikacije da su zadovoljeni bezbednosni zahtevi.

d) Preispituje ocenjivanje rizika u planiranim intervalima, kao i preispitivanje preostalih rizika i identifikovanih prihvatljivih nivoa rizika, uzimajući u obzir promene na:

1. Organizaciju.2. Tehnologiju.3. Poslovne ciljeve i procese.4. Identifikovane pretnje.5. Efektivnost implementiranih kontrola i6. Eksternim događajima, kao što su promene pravnog ili regulatornog

okruženja, izmenjenim ugovornim obavezama, kao i promene u društvenoj klimi.

e) Sprovodi interna ISMS ispitivavanja (audite) u planiranim intervalima. Interni adutiti (nekad se zovu i auditi prve strane (first party audits)) se sprovode od, ili u ime same organizacije za interne svrhe.

f) Primeni regularno preispitivanje od strane menadžementa ISMS sistema u cilju da opseg sistema ostaje adekvatan i da su identifikovana poboljšanja ISMS procesa.

g) Ažurira bezbednosne planove da se uzmu u obzir nalazi aktivnosti nadzora i preispitivanja.

h) Zapisuje akcije i događaje koji mogu imati uticaj na efektivnost ili performanse ISMS sistema.

6.3.4 Održavanje i poboljšanje ISMS sistema (Act)

U cilju održavanja i poboljšanja ISMS sistema organizacija treba da izvrši sledeće aktivnosti:

148

a) Implementira identifikovana poboljšanja ISMS sistema.b) Izvrši odgovarajuće korektivne i preventivne akcije. Primeniti naučene

lekcije iz bezbednosnih iskustava drugih organizacija, kao i onih same organizacije.

c) Razmeni informacije o akcijama i poboljšanjima do svih zaiteresovanih strana sa nivoom detaljnosti koji odgovara okolnostima i, tamo gde je to relevantno, dogovara o tome kako da se nastavi dalje.

d) Osigura da poboljšanja dostignu njihove željene ciljeve.

6.4 Zahtevi za dokumentacijom

6.4.1 Opšte odredbe

Dokumentacija treba da uključi zapise o odlukama menadžmenta, osigura da se akcije mogu pratiti u skladu sa odlukama menadžmenta i politikama, kao i da osigura da zapisani rezultati budu reproduktabilni.

Važno je da postoji mogućnost da se demonstrira veza unazad između izabranih kontrola i rezultata procesa ocene i tretiranja rizika, kao i unazad ka izrađenoj ISMS politici i definisanim ciljevima.

ISMS dokumentacija treba da uključi:

a) ISMS politiku i u njoj definisane ciljeve ISMS sistema.b) Opseg ISMS sistema.c) Procedure i kontrole kao podrška ISMS sistemu.d) Opis metodologije ocene rizika.e) Izveštaj o oceni rizika.f) Plan tretiranja rizika.g) Dokumentovane procedure koje se zahtevaju od strane organizacije da

bi se osiguralo efektivno planiranje, operativni rad i kontrola procesa informatičke bezbednosti, kao i da se meri efektivnost kontrola.

h) Zapisi koji se zahtevaju ovim standardom.i) Izjava o primenljivosti.

Izraz dokumentovana procedura u ovom standardu znači da je procedura uspostavljena, dokumentovana, implementirana i da se održava.

6.4.2 Kontrola dokumenata

Dokumenti koji se zahtevaju u okviru ISMS sistema moraju biti zaštićeni i kontrolisani. Jedna dokumentovana procedura treba da bude uspostavljena da definiše upravne akcije koje su neophodne za:

a) Potvrdu adekvatnosti dokumenata pre njihovog publikovanja,

149

b) Pregled i ažuriranje dokumenata kada je to neophodno, kao i ponovno potvrđivanje dokumenta.

c) Osiguranje da su promene, kao i tekući status revizije dokumenta, identifikovani.

d) Osiguranje da su relevantne verzije primenljivih dokumenata raspoložive na mestima (tačkama) korišćenja.

e) Osiguranje da dokumenti zadržavaju čitkost i laku identifikabilnost.f) Osiguranje da su dokumenti raspoloživi onima kojih ih trebaju, kao i da su

preneti, sačuvani i isporučeni u skladu sa procedurama koje su primenljive u odnosu na njihovu klasifikaciju.

g) Osiguranje da su identifikovani dokumenti koji potiču od spoljne strane.h) Osiguranje da je distribucija dokumenta kontrolisana.i) Sprečavanje nenamernog korišćenja dokumenata koji više ne važe.j) Primenu pogodne identifikacije dokumenata ukoliko se čuvaju za kasnije

korišćenje u bilo koju svrhu.

6.4.3 Kontrola zapisa

Zapisi moraju biti uspsotavljeni i održavani da obebede dokaz o usklađenosti sa zahtevima i efektivnim operativnim radom ISMS sistema. Zapisi moraju biti zaštićeni i kontrolisani. ISMS sistem treba da uzme u obzir bilo koji relevantni legalni ili regulatorni zahtev i ugovornu obavezu. Zapisi treba da ostanu čitki, lako identifikabilni i da se mogu uvek dobiti kada zatreba. Kontrole koje se zahtevaju za identifikaciju, skladištenje, zaštitu, dobijanje, vreme čuvanja i otkrivanje zapisa moraju biti dokumentovane i implementirane. Zapisi takođe treba da budu čuvani o performansama procesa i svim pojavama značajnih bezbednosnih incidenata koji se odnose na ISMS sistem. Primeri zapisa su knjige posetilaca, audit izveštaji i kompletirane forme za autorizacju pristupa.

6.5 Odgovornost menadžmenta

6.5.1 Posvećenost menadžmenta

Menadžment treba da obezbedi dokaz svoje posvećenosti i privrženosti za uspostavu, implementaciju, operativni rad, nadzor, pregled, održavanje i poboljšavanje ISMS sistema putem:

a) Uspostave ISMS politike.b) Osiguranja da su ISMS ciljevi i planovi uspostavljeni.c) Uspostavljanja uloga i odgovornosti za informatičku bezbednost.d) Razmenom informacija sa zaposlenima u organizaciji o važnosti

zadovoljenja ciljeva informatičke bezbednosti i saglasnosti sa politikom informatičke bezbednosti, njihove zakonske odgovornosti, kao i potrebu za stalim poboljšanjem.

e) Obezbeđenjem dovoljnih resursa za uspostavu, implementaciju, operativni rad, nadzor, pregled, održavanje i poboljšavanje ISMS sistema.

150

f) Odlučivanja o kriterijumima za prihvatanje rizika i prihvatljivih nivoa rizika.g) Osiguravanja da će interni ISMS auditi biti sprovedeni.h) Sprovođenja upravnih pregleda ISMS sistema.

6.6 Upravljanje resursima

6.6.1 Obezbeđivanje resursa

Organizacija treba da odredi i obezbedi resurse koji su potrebni za:

a) Uspostavu, implementaciju, operativni rad, nadzor, pregled, održavanje i poboljšavanje ISMS sistema.

b) Osiguranje da procedure informatičke bezbednosti podržavaju poslovne zahteve.

c) Identifikaciju i razmatranje legalnih i regulatornih zahteva i ugovornih bezbednosnih obaveza.

d) Održavanje adekvatne bezbednosti korektnom primenom svih implementiranih kontrola.

e) Sprovođenje pregleda kada je to neophodno, kao i odgovarajuća reakcija u odnosu na rezultate takvih pregleda.

f) Poboljšavanje efektivnosti ISMS sistema tamo gde se to zahteva.

6.6.2 Obuka, svesnost i kompetencija

Organizacija mora da osigura da su svi zaposleni kojima su dodeljene odgovornosti definisane ISMS sistemom kompetentni da sprovode zahtevane zadatke putem:

a) Određivanja neophodnih kompetencija za zaposlene koji sprovode posao koji se odnosi na ISMS sistem.

b) Obezbeđenja obuka ili sprovođenja drugih aktivnosti (na primer: zapošljavanjem kompetentnog ljudstva) u cilju zadovoljenja njihovih potreba.

c) Evaluacijom efektivnosti sprovedenih akcija.d) Održavanjem zapisa o edukaciji, obuci, veštinama, iskustvu i

kvalifikacijama.

Organizacija treba takođe da osigura da su svi relevantni zaposleni svesni relevantnosti i važnosti njihovih aktivnosti u vezi informatičke bezbednosti, kao i kako oni treba da doprinesu postizanju ISMS ciljeva.

6.7 Interni ISMS auditi

Organizacija treba da sprovodi interne ISMS audite u planiranim intervalima u cilju određivanja da li su ciljevi kontrola, same kontrole, procesi i procedure njihovog ISMS sistema:

151

a) Saglasni sa zahtevima ovog standarda i relevantnom legislativom i regulativom.

b) Saglasni sa identifikovanim zahtevima za informatičku bezbednost.c) Efektivno implementirani i održavani.d) Sprovode se kao što je očekivano.

Program audita treba da bude planiran, da uzme u razmatranje status i važnost procesa i oblasti koje treba da budu auditovane, kao i rezultate prethodnih audita. Kriterijumi audita, opseg, frekvencija i metode treba da budu definisani. Izbor auditora i sprovođenje audita treba da osiguraju objektivnost i nepristrasnost procesa audita. Auditori ne treba da vrše ispitivanje (audit) njihovog sopstvenog rada.

Odgovornosti i zahtevi za planiranje i sprovođenje audita, kao i za izveštavanje o rezultatima i održavnaju zapisa treba da budu definisane u dokumentovanoj proceduri.

Menadžment koji je odgovoran za oblast koja će biti ispitivana mora da osigura da se akcije sprovode bez neprikadnih kašnjenja u cilju eliminisanja uočenih nesaglasnosti i njihovih uzroka. Prateće aktivnosti treba da uključe verifikaciju akcija koje se sprovode, kao i izveštavanje o rezultatima verifikacije.

6.8 Upravni pregled ISMS sistema

6.8.1 Opšte odredbe

Menadžment treba da pregleda ISMS sistem u organizaciji u planiranim intervalima (najmanje jednom godišnje) da bi osigurali njegovu kontinualnu pogodnost, adevatnost i efektivnost. Ovaj pregled treba da uključi mogućnosti ocenjivanja za poboljšavanje i potrebu za izmenama ISMS sistema, uključujući politiku informatičke bezbednosti i ciljeva informatičke bezbednosti. Rezultati pregleda treba da budu jasno dokumentovani a zapisi treba da budu održavani.

6.8.2 Ulazi za pregled

Ulaz za upravni pregled treba da uključi:

a) Rezultate ISMS audita i pregleda.b) Povratne informacije od zainteresovanih strana.c) Tehnike, proizvode i procedure koje bi se mogle koristiti u organizaciji u

cilju poboljšanja ISMS performansi i efektivnosti.d) Status preventivnih i korektivnih akcija.e) Ranjivosit ili pretnje po informacioni sistem organizacije koje nisu

adekvatno razmotrene u prethodnim ocenama rizika.f) Rezultate merenja efektivnosti.g) Prateće aktivnosti od prethodnih upravnih pregleda.h) Bilo koje izmene koje mogu da utiču na ISMS sistem.i) Preporuke za poboljšanje.

152

6.8.3 Izlazi upravnog pregleda

Izlaz upravnog pregleda mora da uključi bilo koje odluke i akcije koje se odnose na sledeće:

a) Poboljšanje efektivnosti ISMS sistema.b) Ažuriranje planova za ocenu i tretiranje rizika.c) Modifikaciju procedura i kontrola pomoću kojih se realizuje informatička

bezbednost, ako je to neophodno, u cilju odgovora na interne ili eksterne događaje koji mogu da utiču na ISMS sistem, uključujući promene:

1. Poslovnih zahteva2. Bezbednosnih zahteva3. Poslovnih procesa kojima se realizuju postojeći poslovni zahtevi4. Regulatornih ili legalnih zahteva5. Ugovornih obaveza6. Nivoa rizika i/ili kriterijuma za prihvatanje rizika

d) Resurse koji su potrebni.e) Poboljšanja u odnosu na to kako se efektivnost kontrola može meriti.

6.9 Poboljšanje ISMS sistema

6.9.1 Kontinualno poboljšavanje

Organizacija treba kontinualno da poboljšava efektivnost ISMS sistema kroz korišćenje politike informatičke bezbednosti, ciljeva informatičke bezbednosti, rezultata audita, analize nadziranih događaja, korektivnih i preventivnih akcija i upravnog pregleda.

6.9.2 Korektivne akcije

Organizacija treba da preduzme akcije da eliminiše uzroke nesaglasnosti sa zahtevima ISMS sistema u cilju da spreči njihovo ponovno pojavljivanje. Dokumentovana procedura za korektivne akcije treba da definiše zahteve za:

a) Identifikaciju nesaglasnosti.b) Određivanje uzroka nesaglasnosti.c) Evaluaciju potrebe za akcijama koje treba preduzeti da bi se osiguralo da

se nesaglasnosti neće ponovo pojaviti.d) Određivanje i implementaciju neophodnih korektivnih akcija.e) Zapisivanje rezultata preduzetih akcija.f) Pregled preduzetih akcija.

153

6.9.3 Preventivne akcije

Organizacija treba da odredi akcije da eliminiše uzrok potencijalnih nesaglasnosti sa zahtevima ISMS sistema u cilju sprečavanja njihovog pojavljivanja. Preventivne akcije treba da budu odgovarajuće uticaju koje mogu imati potencijalni problemi.

Dokumentovana procedura za preventivne akcije treba da definiše zahteve za:

a) Identifikaciju potencijalnih nesaglasnosti i njihovih uzroka.b) Evaluaciju potrebe za akcijama u cilju sprečavanja pojave nesaglasnosti.c) Određivanje i implementaciju neophodnih preventivnih akcija.d) Zapisivanje rezultata preduzetih akcija.e) Pregled preduzetih preventivnih akcija.

Organizacija treba da identifikuje izmenjene rizike i da identifikuje zahteve za preventivnim akcijama sa fokusiranom pažnjom na značajno izmenjene rizike. Prioritet preventivnih akcija treba da bude određen na bazi rezultata ocene rizika.

U prilogu E su detaljnije razrađeni principi i metodologije bezbednosti i risk menadžmenta.

6.10 Proces sertifikacije prema ISO/IEC 27001:2005 standardu

Proces sertifikovanja sprovodi sertifikaciono telo koje je akreditovano za sertifikaciju po standardu ISO/IEC 27001. Proces ocenjivanja i sertifikacije implementiranog ISMS sistema se sastoji od sledećih faza:

Pred-sertifikacija i sertifikacija

o Korak 0 - Pred-ocenjivanje o Korak 1 – Audit dokumentacijeo Korak 2 – Audit implementacije

Post-sertifikacija

o Kontinualno nadgledanje tokom 3 naredne godineo Ponovna sertifikacija (re-certification) nakon 3 godine od sertifikacije

Procesu prethodi inicijalni zahtev sertifikacionog tela da organizacijia popuni i pošalje potpisanu aplikacionu formu koja uključuje opseg ISMS sistema koga treba sertifikovati, kao i izjavu da će sve informacije neophodne za evaluaciju ISMS sistema biti dostavljene.

Dodatno, organizacija treba da dostavi opis ISMS sistema koje treba da se sertifikuje, kao i svu dokumentaciju i standarde koji se mogu primeniti na ISMS sistem. Korak 0 se, eventualno, može sastojati od: ocenjivanja ocene rizika u organizaciji, ocenjivanja Izjave o primenljivosti i uspostave plana audita.

154

Ocenjivanje procesa ocene rizika u organizaciji se najčešće vrši kroz odgovarajuće intervjue sa menadžmentom i zaposlenima koji su odgovorni/uključeni u proces ocene rizika.

Ocenjivanje Izjave o primenljivosti predstavlja ocenu rezultata analize rizika, izbora kontrola sa obrazloženjem, kao i ocenu same dokumentovane Izjave o primenljivosti. Korak 0 može trajati od jednog do dva dana na lokaciji organizacije.

Audit program/plan koji se izrađuje se sastoji od odgovarajuće matrice sistema upravljanja sa aspekta ciljeva kontrola, odgovornih lica, odeljenja i procesa (ova matrica pokriva čitav trogodišnji sertifikacioni period), kao i plana intervjua za korake 1 i 2 (izbor ciljeva kontrola, procesa i službi/odeljenja).

Korak 1 – predstavlja značajan deo procesa ocenjivanja po ISO/IEC 27001 standardu. Sertifikaciono telo treba da dobije dokumentaciju o dizajnu ISMS sistema, uključujući izveštaj o oceni rizika, Izjavu o primenljivosti, kao i ključne elemente ISMS sistema.

Ovaj korak audita uključuje, ali se ne ograničava samo na to, pregled dobijenih dokumenata. Audit dokumentacije se u opštem slučaju sprovodi u samoj organizaciji (on site) i sastoji se od sledećih aktivnosti:

Ispitivanje saglasnosti ISMS okvira sa ISO/IEC 27001 standardom, Pregleda se politika bezbednosti, opseg, ocena rizika (ako nije pregledana u

koraku 0), upravljanje rizikom, izbor kontrola i izjava o primenljivosti (takođe ako nije pregeldana u koraku 0).

Politike, standardi, operativne procedure i radne instrukcije. Odgovarajuće pokrivanje dokumentima izabranih bezbednosnih kontrola. Upravljanje i dostupnost dokumenata. Auditori verovatno neće detaljno pregledati specifične procedure ali očekuju

da postoji infrastruktura dokumenata koja, pored specifičnih politika, obuhvata standarde, procedure i radne instrukcije. Eventualno će biti pregledani uzorci pojedinih dokumenata.

Pregled dokumenata treba da bude završen pre početka koraka 2. Rezultati aktivnosti u koraku 1 se dokumentuju u pisanom izveštaju. Iako sve zavisi od procesa sertifikacije i izabranog sertifikacionog tela, korak 1 bi takođe mogao da traje od jednog do dva dana na lokaciji organizacije.

Korak 2 – Audit implementacije predstavlja verifikaciju implementacije i operativnog rada ISMS sistema. U ovom koraku, jedna ili više lokacija organizacije će biti posećena od strane jednog ili više auditora u skladu sa unapred definisnim planom audita, a na bazi rezultata iz Koraka 0 i 1.

Cilj ove ili ovih poseta je da se potvrdi da je organizacija saglasna sa svim politikama, ciljevima i procedurama, kao i da je ISMS sistem u skladu sa svim identifikovanim bezbednosnim zahtevima. Prva aktivnost u ovom procesu je razmatranje ispravki detektovanih nesaglasnosti iz koraka 1 – Audita dokumentacije.

155

Nakon toga se vrši ocenjivanje implementacije i efektivnosti upravljačkog sistema po PDCA modelu, kao i ocenjivanje implementacije i efektivnosti primenjenih bezbednosnih kontrola. Naime, cilj je da se oceni funkcionisanje ISMS sistema u realnom slučaju a na bazi rezultata internih audita, upravnog pregleda, praćenja korektivnih i preventivnih mera, identifikacije novih rizika i ponovnog ocenjivanja postojećih rizika, itd.

Broj dana trajanja koraka 2 sertifikacije zavisi od veličine i kompleksnosti ISMS sistema i same organizacije. Nakon završenog procesa verifikacije tim lider ocenjivačkog tima daje predlog ali se ne donosi finalna odluka koja se potvrđuje od strane sertifikacionog tela.

Nakon uspešno završenog procesa, izdaje se sertifikat po ISO/IEC 27001 standardu. Sertifikat je validan za period od tri godine, isključujući moguću suspenziju ili povlačenje sertifikacije. Sertifikat se izdaje sa sadržajem koji se odnosi na opseg ISMS sistema i referencira se na Izjavu o primenljivosti koja je raspoloživa u vreme ocenjivanja.

Sertifikaciono telo će sprovoditi nadzorne posete i nakon tri godine, ponovna sertifikacija je neophodna. Naime, kontinualni nadzor ISMS sistema (Surveillance Audit) sprovodi sertifikaciono telo u opštem slučaju dva puta godišnje. Cilj ovog audita je da se pokrije opseg sertifikacije tokom trogodišnjeg ciklusa.

Moguće je da se sprovedu i vanredni dodatni auditi ukoliko je potrebno (specijalne posete sertifikacionog tela). Na kraju ovog perioda, sertifikaciono telo može produžiti validnost sertifikata za novi period od tri godine pod uslovom pozitivnog rezultata procesa ponovnog ocenjivanja.

Vremenski zahtevi procesa ocenjivanja zavise od različitih faktora:

Veličine opsega aktivnosti koje su pokrivene procesom ocenjivanja, Brojem lokacija u organizaciji koje se posećuju u okviru ocenjivanja, Poslovnih funkcija u okviru opsega ocenjivanja, Eventualnih drugih sertifikacija koje se mogu uzeti u obzir.

Čitava ideja sertifikacije po ISO/IEC 27001 standardu je kontinualno upravljanje i poboljšanje vašeg sistema upravljanja informatičkom bezbednošću. PDCA model je jedan ciklični proces koji vam pomaže da ažurirate vaš sistem informatičke bezbednosti.

Postoje nekoliko stvari koje možete činiti u cilju osiguranja da se održava željeni nivo bezbednosti prema ISO/IEC 27001 standardu, kao što su:

Stalna provera da li bezbednosne kontrole rade i da li su efektivne, Praćenje promena koje mogu imati uticaj na ISMS sistem, kao što su izmene

u rizicima po vašu organizaciju, izmene u poslovnim aktivnostima, itd., i poboljšavanje sistema gde god je to neophodno.

Svrha ovih provera nadzora i ponovnog ocenjivanja je da se verifikuje da je ISMS sistem i dalje u saglasnosti sa zahtevima ISO/IEC 27001 standarda, kao i da je ISMS

156

sistem ispravno implementiran i održavan (Da li je opseg ISMS sistema i dalje validan? Da li su primenjeni bezbednosni mehanizmi i dalje efektivni? Da li postoji odgovarajući program nadzora i poboljšanja? itd.).

Neke promene će se verovatno desiti u vašoj organizaciji pre ili kasnije, kao na primer: promene u fokusu organizacije, promene IT sistema, promene u proizvodima ili promene koje se više odnose na informatičku bezbednost, kao što su nove pretnje i ranjivosti.

Sve te promene mogu imati uticaj na rizike po vašu organizaciju, tako da kadgod se desi neka značajnija promena, vaša ocena rizika treba da bude preispitana i po potrebi ažurirana, a nove bezbednosne kontrole treba da budu identifikovane kada god je to neophodno.

Sve nove bezbednosne kontrole koje su identifikovane tokom provere trenutnog statusa informatičke bezbednosti u organizaciji treba da budu implementirane, što uključuje:

Implementaciju svih neophodnih promena, ažuriranja, novih bezbednosnih kontrola, modifikovanih procedura, itd.

Ažuriranje dokumentacije i zapisa gde god se to zahteva. Revidiranje ISMS sistema ukoliko je potrebno i osiguranje da revizije dostižu

željene ciljeve. Kada se sva poboljšanja implementiraju, neophodno je informisati sve

zainteresovane jer to može imati implikacije na njihov posao.

157

Documents

Skripta Zastita Racunarskih i Poslovnih Sistema 01