ZATITA RAUNARSKIH I

POSLOVNIH SISTEMA
Skripta

Dr Milan Markovi

Banja Luka, Januar 2009.

Sadraj
1. UVOD...................................................................................................................................................................5
2. SAVREMENE RAUNARSKE MREE, INFORMACIONI SISTEMI I SISTEMI ZATITE...............6
2.1 SAVREMENE RAUNARSKE MREE I TCP/IP PROTOKOL.................................................................................6
2.2 TRENDOVI U SISTEMIMA ZATITE SAVREMENIH RAUNARSKIH MREA.........................................................7
2.3 POTENCIJALNI NAPADI NA SAVREMENE RAUNARSKE MREE I MOGUI NAINI ODBRANE.........................10
2.4 PRIMERI NAPADA NA SAVREMENE RAUNARSKE MREE..............................................................................11
2.4.1 Kraa identiteta - phishing................................................................................................................12
2.4.2 Prislukivanje......................................................................................................................................12
2.4.3 Modifikacija podataka........................................................................................................................12
2.4.4 Identity spoofing (IP address spoofing)..........................................................................................12
2.4.5 Napadi na lozinke...............................................................................................................................13
2.4.6 Denial-of-service napad....................................................................................................................13
2.4.7 Man-in-the-middle napad..................................................................................................................14
2.4.8 Napad kompromitacije kljua...........................................................................................................14
2.4.9 Sniffer napad.......................................................................................................................................14
2.4.10 Napad na aplikativnom nivou.........................................................................................................14
2.5 TEHNOLOGIJE ZATITE SAVREMENIH RAUNARSKIH MREA........................................................................15
3. PRIMENA KRIPTOGRAFSKIH METODA ZATITE U INFORMACIONOM SISTEMU..................16
3.1 SIMETRINI KRIPTOGRAFSKI ALGORITMI.......................................................................................................16
3.1.1 Blok ifarski sistemi...........................................................................................................................17
3.1.2 Kriptografski modovi blok ifarskih algoritama..............................................................................30
3.1.3 Sekvencijalni ifarski sistemi............................................................................................................36
3.1.4 Komparativna analiza blok i sekvencijalnih ifarskih sistema.....................................................40
3.2 ASIMETRINI KRIPTOGRAFSKI ALGORITMI.....................................................................................................41
3.2.1 PKCS#1 standard..............................................................................................................................41
3.2.2 RSA algoritam.....................................................................................................................................44
3.3 MESSAGE DIGEST ALGORITMI........................................................................................................................48
3.3.1 MD5 message digest algoritam.......................................................................................................49
3.4 PRIMENA KRIPTOGRAFSKIH ALGORITAMA U INFORMACIONIM SISTEMIMA....................................................51
4. VIESLOJNA ARHITEKTURA SISTEMA ZATITE SAVREMENIH RAUNARSKIH MREA.....52
4.1 ZATITA NA APLIKATIVNOM NIVOU...............................................................................................................53
4.2 ZATITA NA TRANSPORTNOM NIVOU.............................................................................................................55
4.3 ZATITA NA MRENOM NIVOU.......................................................................................................................56
5. OSNOVE PKI SISTEMA.................................................................................................................................58
5.1 UVOD U SISTEME SA JAVNIM KLJUEVIMA (PKI PUBLIC KEY INFRASTRUCTURE)......................................58
5.1.1 Podrka razliitim politikama rada PKI sistema............................................................................58
5.1.2 Bezbednost sistema..........................................................................................................................59
5.1.3 Skalabilnost.........................................................................................................................................59
5.1.4 Fleksibilnost........................................................................................................................................59
5.1.5 Jednostavno korienje.....................................................................................................................60
5.1.6 Otvorenost sistema............................................................................................................................60
5.2 KOMPONENTE PKI SISTEMA..........................................................................................................................60
5.2.1 Moduli PKI sistema............................................................................................................................62
5.3 SERTIFIKACIONO TELO (CA CERTIFICATION AUTHORITY)..........................................................................63
5.3.1 Funkcionalnost CA.............................................................................................................................64
5.3.2 Obeleja CA........................................................................................................................................65
5.4 OPERATOR SERTIFIKACIONOG TELA (CAO)...................................................................................................65
5.4.1 Funkcionalnost CAO..........................................................................................................................65
5.4.2 Obeleja CAO.....................................................................................................................................66

5.5 REGISTRACIONO TELO (RA)..........................................................................................................................66

5.5.1 Funkcionalnost RA.............................................................................................................................66
5.5.2 Obeleja RA........................................................................................................................................67
5.6 OPERATOR REGISTRACIONOG TELA (RAO)...................................................................................................67
5.6.1 Funkcionalnost RAO..........................................................................................................................67
5.6.2 Obeleja RAO.....................................................................................................................................68
5.7 SERTIFIKACIONO TELO KAO WEB VIESLOJNA APLIKACIJA...........................................................................68
5.8 DIGITALNI SERTIFIKATI, STRUKTURA I STANDARDI........................................................................................68
5.8.1 ITU X.509 v3 sertifikat-struktura......................................................................................................70
5.8.2 Ekstenzije u sertifikatu.......................................................................................................................72
5.8.3 Najee koriene ekstenzije.........................................................................................................79
5.9 METODE REGISTRACIJE KORISNIKA...............................................................................................................79
5.9.1 Registracija u linom kontaktu.........................................................................................................81
5.9.2 Udaljena registracija..........................................................................................................................82
5.10 SISTEMI ZA DISTRIBUCIJU SERTIFIKATA.......................................................................................................84
5.11 UPRAVLJANJE IVOTNIM VEKOM SERTIFIKATA............................................................................................85
5.11.1 Obnavljanje sertifikata.....................................................................................................................85
5.11.2 Povlaenje sertifikata.......................................................................................................................85
5.11.3 Suspenzija sertifikata.......................................................................................................................85
5.12 LISTA POVUENIH SERTIFIKATA...................................................................................................................86
5.13 OPIS PROCEDURE GENERISANJA I ZATITE ASIMETRINIH KLJUEVA SERTIFIKACIONOG TELA..................90
5.13.1 Opta obeleja HSM.......................................................................................................................91
5.13.2 Opta obeleja smart kartica.........................................................................................................94
5.14 SERVER ZA ARHIVIRANJE KLJUEVA............................................................................................................97
5.14.1 Funkcionalnost servera za arhiviranje kljueva..........................................................................99
5.14.2 Obeleja Arhiv servera....................................................................................................................99
5.15 STANDARDI KOJI SE ODNOSE NA FUNKCIONISANJE PKI SISTEMA...............................................................99
5.15.1 Abstract sintax notation one - ASN.1..........................................................................................100
5.15.2 ITU X.509 v3 sertifikat-struktura..................................................................................................101
5.15.3 ITU X.509 v2 lista opozvanih sertifikata.....................................................................................102
5.15.4 X.509 v2 lista opozvanih sertifikata - formiranje.......................................................................102
5.16 TIPOVI SERTIFIKACIONIH TELA I MOGUI NAINI REALIZACIJE.................................................................103
5.17 GENERIKI MODEL REALIZACIJE CA KAO SOFTVERSKOG-HARDVERSKOG SISTEMA ZA GENERISANJE
DIGITALNIH SERTIFIKATA....................................................................................................................................104
5.18 ORGANIZACIONI ASPEKTI FUNKCIONISANJA PKI SISTEMA........................................................................107
5.18.1 Bezbednosne procedure u odnosu na ljudski faktor................................................................107
5.18.2 Bezbednosne procedure u odnosu na prostorije i ureaje.....................................................109
5.18.3 Sistemi fizike i logike kontrole pristupa u okviru Sertifikacionog tela.................................110
5.19 OSNOVNI DOKUMENTI RADA SERTIFIKACIONOG TELA..............................................................................112
5.19.1 Politika sertifikacije opti koncept.............................................................................................113
5.19.2 Relativni odnos dokumenata Politika sertifikacije i Praktina pravila rada...........................114
5.19.3 Sadraj dokumenata Politika sertifikacije i Praktina pravila rada.........................................115
5.10.4 Interna pravila rada sertifikacionog tela......................................................................................117
5.19.5 Upravljanje radom PKI sistema....................................................................................................118
5.20 KRITERIJUMI KOJE CA TREBA DA ISPUNI DA BI IZDAVALO KVALIFIKOVANE SERTIFIKATE.........................119
5.20.1. Sposobnost za pouzdano obavljanje usluga izdavanja elektronskih sertifikata.................121
5.20.2 Bezbedno i aurno voenje registra korisnika kao i sprovoenje bezbednog i trenutnog
opoziva elektronskog sertifikata...............................................................................................................123
5.20.3 Obezbeivanje tanog utvrivanja datuma i vremena izdavanja ili opoziva elektronskog
sertifikata.....................................................................................................................................................123
5.20.4 Obezbeivanje pouzdane registracija korisnika.......................................................................123
5.20.5 Obezbeivanje neophodnih kadrovskih resursa i upravljanja operativnim radom
sertifikacionog tela.....................................................................................................................................125
5.20.6 Korienje pouzdanih i bezbednih kriptografskih sistema.......................................................126
5.20.7 Zahvevi za obezbeenjem zatite od falsifikovanja sertifikata i tajnosti generisanih kljueva
......................................................................................................................................................................129
5.20.8 Zahtevi za odgovornou i osiguranjem od rizika.....................................................................130
5.20.9 Zahvevi za uvanjem svih relevantnih informacija...................................................................131
5.20.10 Zahtevi za bezbednim uslovima za korisnike za koje se generiu podaci za formiranje
elektronskog potpisa..................................................................................................................................132

5.20.11 Zahtevi za sisteme fizike zatite ureaja, opreme i podataka i sigurnosna reenja zatite
od neovlaenog pristupa.........................................................................................................................133
5.20.12 Zahtevi za raspoloivou informacija o uslovima izdavanja i korienja sertifikata........135
5.20.13 Zahtevi za sistem upravljanja sertifikatima..............................................................................135
5.21 ASPEKTI INTEROPERABILNOSTI PKI SISTEMA............................................................................................136
5.21.1 Kriterijumi i proces krossertifikacije.............................................................................................136
5.22 DOSADANJA ISKUSTVA U IZGRADNJI SERTIFIKACIONIH TELA..................................................................138
6. IMPLEMENTACIJA SISTEMA UPRAVLJANJA INFORMATIKOM BEZBEDNOU U
ORGANIZACIJI PO STANDARDU ISO/IEC 27001:2005............................................................................142
6.1 UVOD...........................................................................................................................................................142
6.2 ISTORIJAT ISO/IEC 27001:2005 STANDARDA.............................................................................................142
6.3 USPOSTAVA I UPRAVLJANJE ISMS SISTEMOM..............................................................................................145
6.3.1 Uspostava ISMS (Plan)...................................................................................................................145
6.3.2 Implementacija i operativni rad ISMS sistema (Do)...................................................................147
6.3.3 Nadzor i preispitivanje ISMS sistema (Check)............................................................................147
6.3.4 Odravanje i poboljanje ISMS sistema (Act).............................................................................148
6.4 ZAHTEVI ZA DOKUMENTACIJOM..................................................................................................................149
6.4.1 Opte odredbe..................................................................................................................................149
6.4.2 Kontrola dokumenata......................................................................................................................149
6.4.3 Kontrola zapisa.................................................................................................................................150
6.5 ODGOVORNOST MENADMENTA..................................................................................................................150
6.5.1 Posveenost menadmenta...........................................................................................................150
6.6 UPRAVLJANJE RESURSIMA...........................................................................................................................151
6.6.1 Obezbeivanje resursa...................................................................................................................151
6.6.2 Obuka, svesnost i kompetencija....................................................................................................151
6.7 INTERNI ISMS AUDITI.................................................................................................................................151
6.8 UPRAVNI PREGLED ISMS SISTEMA..............................................................................................................152
6.8.1 Opte odredbe..................................................................................................................................152
6.8.2 Ulazi za pregled................................................................................................................................152
6.8.3 Izlazi upravnog pregleda.................................................................................................................153
6.9 POBOLJANJE ISMS SISTEMA......................................................................................................................153
6.9.1 Kontinualno poboljavanje..............................................................................................................153
6.9.2 Korektivne akcije..............................................................................................................................153
6.9.3 Preventivne akcije............................................................................................................................154
6.10 PROCES SERTIFIKACIJE PREMA ISO/IEC 27001:2005 STANDARDU...........................................................154

1. UVOD
Ovaj dokument predstavlja skriptu za izvoenje predmeta Zatita raunarskih i
poslovnih sistema na Fakultetu poslovne informatike Univerziteta Apeiron u Banja
Luci.
U okviru ovog kursa analiziraju se kljuna pitanja bezbednosti u raunarskim
mreama i informacionim sistemima. Analiziraju se takoe osnovne bezbednosne
karakteristike savremenih raunarskih mrea bazirane na Internet tehnologijama i dat
je prikaz tehnika i kriptografskih protokola kojima se navedeni bezbednosni problemi
reavaju.
Razmatraju su trendovi u zatiti raunarskih mrea, potencijalni napadi, mogui
naini odbrane, tehnologije zatite, standardni kriptografski algoritmi, digitalni potpis,
digitalna envelopa, PKCS standardi i vieslojna arhitektura zatite. Opisane su
tehnike zatite na aplikativnom, transportnom i mrenom nivou ISO/OSI modela koje
se baziraju na primjeni infrastrukture sistema sa javnim kljuevima.
Pored toga, razmatraju se softverska, softversko/hardverska i hardverska rjeenja
zatite. U tom smislu, razmatrane su procedure jake autentikacije, kao i primena
tokena, smart kartica i HSM urjeaja.
U okviru kursa se posebno razmatra infrastruktura sistema sa javnim kljuevima (PKI
- Public Key Infrastructure) koja omoguuje ambijent za pouzdanu primjenu
elektronskog poslovanja i koja se najee bazira na kombinovanoj primeni
asimetrinih i simetrinih kriptografskih sistema. PKI sistemi se baziraju na digitalnim
sertifikatima kao jednoznanim elektronskim identifikatorima ovlaenih uesnika u
raunarskoj mrei. Dodatno se razmatraju komponente PKI sistema, sertifikaciono
telo (CA), registraciona tela (RA), PKI aplikacije, kao i primjeri realizacije PKI sistema
i PKI aplikacija. Takoe su razmatrani i aspekti primene odgovarajue Evropske i
domae Zakonske regulative u domenu digitalnog potpisa i PKI sistema.
Na kraju se razmatraju aspekti implementacije sistema upravljanja informatikom
bezbednou u skladu sa svetskim standardima (ISO/IEC 27001:2005).
Ova skripta slui radi lakeg praenja predavanja na predmetu Zatita raunarskih 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.

2. SAVREMENE RAUNARSKE MREE, INFORMACIONI

SISTEMI I SISTEMI ZATITE
2.1 Savremene raunarske mree i TCP/IP protokol
Savremene raunarske mree se uglavnom baziraju na Internet tehnologijama i
protokolima koji su podloni moguim napadima koji naruavaju bezbednost
podataka i identiteta subjekata.
Kljuni problem lei u injenici da podaci krue i egzistiraju u elektronskom obliku koji
nije neposredno vidljiv i zbog toga postaju izloeni novim vrstama napada, a osnovni
razlozi za to lee u samim osnovnim karakteristikama arhitekture raunarskih mrea
Internet/Intranet tipa:

TCP/IP protokoli nisu projektovani da zadovolje zahteve za zatitom

informacija,
Internet je mrea sa komutacijom paketa u kojoj se jednostavno pristupa
informacijama koje se prenose i mogue je ubacivanje poruka nepoznatog
porekla i sadraja.

U cilju reavanja navedenih problema, uporedo sa razvojem raunarskih mrea,

razvijaju se i specijalizovani softverski i hardverski sistemi zatite.
Danas u svetu postoji veliki broj proizvoaa tehnoloki kvalitetnih proizvoda za
razliite nivoe zatite savremenih mrea. U ovim proizvodima su ugraeni javni defacto standardni kriptografski algoritmi. Ovi algoritmi obezbeuju dovnoljni nivo
bezbednosti za veinu komercijalnih informacionih sistema i raunarskih mrea.
Iako pomenuti proizvodi predstavljaju veoma kvalitetna reenja sa stanovita
tehnologije realizacije, oni se ne preporuuju za primenu u TCP/IP raunarskim
mreama sa bezbedno osetljivim podacima. Osnovni razlog je nepostojanje potpune
sigurnosti u kriptografski kvalitet ovih reenja, npr. ona se ne mogu verifikovati na
nivou izvornog koda.
Najkvalitetnija kriptografska reenja koja se primenjuju u savremenim raunarskim
mreama baziraju se na primeni simetrinih kriptografskih sistema za zatitu tajnosti
(u specijalnim sluajevima po mogustvu uz korienje sopstvenih simetrinih
algoritama vieg kriptografskog kvaliteta), tehnologije digitalnog potpisa na bazi
asimetrinih kriptografskih sistema, digitalnih certifikata i hardverskih modula (smart
kartice i kriptografski koprocesori).
Ovakvi sistemi zatite su projektovani da se uspeno odbrane od potencijalnih
opasnosti i napada u cilju ugroavanja bezbedno osetljivih resursa informacionih
sistema.
Kriptografski algoritmi koji se primenjuju u sistemima zatite Internet/Intranet
raunarskih mrea dele se u dve velike grupe:

Simetrini kriptografski algoritmi,

Asimetrini kriptografski algoritmi.

Podela je izvedena na osnovu posedovanja informacija neophodnih za ifrovanje i

deifrovanje. Primenom simetrinih kriptografskih algoritama se, kao i u
tradicionalnim sistemima zatite, ostvaruje funkcija zatite tajnosti u savremenim
informacionim sistemima.
Sa druge strane, primenom asimetrinih kriptografskih algoritama i tehnologije
digitalnog potpisa ostvaruju se sledee funkcije u savremenim raunarskim
mreama:

Autentinost strane koja je poslala digitalno potpisanu poruku,

Zatita integriteta podataka u poruci koja je poslata,
Neporecivost elektornskog potpisnika za sadraj date poruke.

2.2 Trendovi u sistemima zatite savremenih raunarskih mrea

Uporedo sa razvojem i implementacijom raunarskih mrea Interenet tipa, razvijaju
se i razliiti mehanizmi zatite specijalizovani za odbranu od pojedinih vrsta napada.
U startu treba biti svestan da raunarske mree Internet tipa, pored toga to
omoguavaju izuzetno poveanje efikasnosti rada i smanjenje trokova, predstavljaju
kritinu taku bezbednosti date organizacije sa stanovita bezbednosti informacija
koje se u sistemu prenose.
U svetu postoji veliki broj razliitih pregleda i analiza opasnosti korienja
raunarskih mrea na bazi Internet tehnologija izraenih od strane relevantnih
institucija. Jedna takva analiza ukazuje na tipove napada, u procentima prijavljenih
napada, Slika 2.1, kao i prosene gubitke prouzrokovane tim napadima u 2001.
godini, Slika 2.2.

Slika 2.1: Tipovi prijavljenih napada na raunarske mree u procentima

Prema jednom slinom pregledu amerikog instituta za zatitu raunara (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 mreama u prethodnoj godini.
Takoe, prema istoj analizi, u prethodnih 5 godina, 66 razmatranih subjekata je
prijavilo ukupan gubitak proizveden kraom 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: Proceni gubici u 2001. godini

Ova analiza je takoe potvrdila sledee trendove u korienju raunarskih mrea
Internet tipa u poslednje vreme:

Razvoj sve ireg spektra moguih napada.

Napadi na korporacijske raunarske mree Internet tipa mogu biti eksterni i
interni. Iako su prethodnih godina napadi na raunarske mree Internet tipa
bili preteno eksterni, novije analize (kao to je i prethodno pomenuta analiza
CSI) pokazuju da mnogo veu tetu i finansijske gubitke nanosi irok spektar
internih napada. Razlozi za to lee u samoj prirodi mrea Internet tipa u kojima
interni uesnici nisu samo zaposleni u datoj korporaciji (za koje postoji
odreeni stepen poverenja), ve i poslovni partneri, zaposleni u firmama
podrunicama, kooperanti, dostavljai, itd., koji iz razloga jednostavnosti
korienja i poveanja efikasnosti i produktivnosti rada imaju vrlo slian, ako
ne i isti, pristup korporacijskoj mrei kao i zaposleni u datoj korporaciji.
U poslednje vreme su zabeleeni veoma veliki finansijski gubici prouzrokovani
napadima na raunarske mree Internet tipa.
Uoeno je da primena samo komercijalnih tehnologija zatite informacija ne
moe uvek predstavljati pouzdano reenje odbrane od potencijalnih napada
ve da se ponekad mora koncipirati i primeniti slojevita i sveobuhvatna politika

zatite koja e pored komercijalnih tehnologija zatite obavezno ukljuiti i

primenu kvalitetnijih, sopstveno realizovanih mehanizama zatite, kao i
mehanizama kontrole pristupa i organizacionih elemenata zatite date
raunarske mree Internet tipa.
Sa druge strane, SANS Institut je obavio istraivanja koja su rezultovala u definisanju
tri liste osnovnih greaka koje omoguavaju razliite vrste napada na mree Internet
tipa i pojedinane radne stanice u mrei.
Prva lista se odnosi na krajnje korisnike i definie sledeih pet najveih
bezbednosnih greaka:

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,
Korienje modema dok ste vezani u lokalnoj raunarskoj mrei (LAN).

Druga lista se odnosi na korporacijske uprave (management) i definie sledeih

sedam najveih bezbednosnih greaka koje utiu na slabosti korporacijske
raunarske mree:

Neobezbeenje odgovarajueg broja slubenika koji treba da uspostave i

odravaju sistem zatite u okviru korporacije,
Primena samo organizacionih vidova zatite bez primene (i bez prihvatanja
neophodnosti primene) mehanizama zatite informacija,
Reavanje samo pojedinanih bezbednosnih problema bez primene mera i
stvaranja uslova za kreiranje kompletnog sistema zatite koji bi osigurao
reenje najireg spektra bezbednosnih problema,
Korienje samo mrenih barijera (firewall) u korporacijskoj raunarskoj mrei,
Neshvatanje koliko vrede intelektualno vlasnitvo i poslovna reputacija firme,
Primena kratkotrajnih reenja pojedinanih situacija to dovodi do brzog
umnoavanja bezbednosnih problema,
Pretvaranje da e se bezbednosni problemi reiti sami od sebe ako se
ignoriu.

Trea lista se odnosi na informatike profesionalce i definie sledeih deset najveih

bezbednosnih greaka:

Prikljuivanje raunarskog sistema na Internet bez prethodne primene svih

neophodnih bezbednosnih mera da se to uini,
Prikljuivanje test i razvojnih sistema na Internet sa default lozinkama,
Propust da se sistem aurira sa reenjima nekih bezbednosnih problema,
Korienje 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 odravanju i testiranju procedure back-up-a sistema,
Korienje nepotrebnih Internet servisa,
Primena mrenih barijera sa pravilima koja ne osiguravaju bezbedno osetljivi
dolazei i odlazei saobraaj,
Propust u implementaciji i auriranju softverskog paketa za detekciju virusa,
Propust u edukaciji korisnika u odnosu na to ta je potrebno uiniti kada se
uoi potencijalni bezbednosni problem.

Imajui u vidu prethodno reeno, u nastavku su sumirani najei vidovi potencijalnih

napada i mogue odbrane u okviru TCP/IP distribuiranih raunarskih sistema.

2.3 Potencijalni napadi na savremene raunarske mree i mogui

naini odbrane
Najei vidovi napada na raunarske mree Internet/Intranet tipa su:

Prislukivanje neovlaeno pristupanje podacima u otvorenom obliku i

lozinkama,
Lano predstavljanje neautorizovani pristup podacima ili kreiranje
neautorizovanih podataka,
Napad tipa ukidanja servisa (denial-of-service) onemoguavanje
funkcionisanja mrenih servisa i resursa,
Ponavljanje poslatih poruka neovlaena kontrola komunikacije subjekata i
ponavljanje, izmena ili spreavanje prenosa podataka,
Pogaanje lozinke neovlaeni pristup podacima uz pomo otkrivene
lozinke,
Kriptoanaliza otkrivanje tajnih kljueva otkrivanje podataka u otvorenom
obliku na bazi ifrata i otkrivenog tajnog kljua,
Napadi tipa Trojanskog konja distribucija zlonamernih programa na radne
stanice,
Virusi unitenje podataka.

Iako pomenuti napadi nisu specifini samo za TCP/IP raunarske mree oni su tu
najvie ispoljeni jer se daleko najvei broj raunarskih mrea u svetu bazira na
Internet tehnologijama.
Mogui naini odbrane od navedenih napada su sledei:

ifrovanje zatita tajnosti podataka i lozinki,

Primena tehnologije digitalnog potpisa provera autentinosti, zatita
integriteta podataka i obezbeenje neporecivosti za sadraj poslate poruke,
Procedura jake autentikacije bezbedna meusobna autentikacija strana u
komunikaciji,
Korienje jakih kljueva i esta izmena kljueva spreavanje metoda
kriptoanalize,

10

Zatita adresa servera zatita od napada tipa ukidanje servisa,

Korienje digitalnih certifikata kao jednoznanih identifikacionih parametara
subjekata u komunikaciji,
Korienje smart kartica za generisanje digitalnog potpisa i bezbedno uvanje
kljueva i drugih kriptografskih parametara,
Vienivoska antivirusna zatita.

U cilju odbrane od navedenih potencijalnih napada na mreu, najsvrsishodnije je

primeniti kombinovane metode zatite koje se sastoje od veine gore navedenih
metoda.

2.4 Primeri napada na savremene raunarske mree

Internet je uveo revoluciju u nain na koji kompanije posluju s obzirom da je to
izuzetno efikasan, jeftin i fleksibilan protokol.
Meutim, postojee metode koje se koriste za rutiranje paketa u mrei ine ih
ranjivim u odnosu na veliki opseg bezbednosnih rizika, kao to su: spoofing, sniffing i
session hijacking. Takoe, TCP/IP protokol ne obezbeuje nikakvu formu
neporecivosti za ugovorne i finansijske transakcije.
Pored toga to moraju da obezbede interno okruenje, organizacije moraju da
obezbede i komunikaciju izmeu udaljenih kancelarija, poslovnih partnera, korisnika i
zaposlenih koji putuju ili rade sa udaljenog mesta. Prenoenje poruka putem
Interneta ili Intraneta do tih razliitih entiteta predstavlja jedan oigledan rizik, imajui
u vidu nedostatak zatite u postojeoj Internet mrei. Kontrola i upravljanje
bezbednou i pristupom pomenutih entiteta u poslovnom okruenju kompanije je od
izuzetnog znaaja.
Bez primene bezbednosnih mehanizama, i javne i privatne mree su ranjive na
neovlaeno nadgledanje i pristup. Interni napadi mogu biti rezultat minimalne ili
nepostojee Intranet bezbednosti.
Rizici koji dolaze spolja u jednoj privatnoj mrei potiu od konekcija na Internet i
ekstranet. Kontrola pristupa korisnika samo na bazi password-a ne moe da zatiti
podatke koji se prenose kroz mreu.
Bez primene kontrola i mera bezbednosti, vai podaci i sistemi mogu biti predmet
napada. Neki napadi su pasivni u kojima se informacije samo mpnitoriu. Drugi
napadi su aktivni i informacije se menjaju sa ciljem menjanja ili unitenja samih
podataka ili same mree putem koje se vri prenos podataka. Vae mree i podaci su
ranjivi na bilo koji od tipova napada koji su navedeni u nastavku ukoliko niste
primenili odgovarajue bezbednosne mere.
U nastavku, daemo osnovne informacije i listu uobiajenih mrenih napada koje se
primenjuju na fiksne i mobilne TCP/IP raunarske mree. Jedan dobar pregled ovih
ranjivosti se moe nai na Microsoft resursima (www.microsoft.com).

Kraa identiteta - phishing

11

Prislukivanje
Modifikacija podataka
Spoofing identiteta (IP address spoofing)
Napadi na lozinke
Denial-of-service (DoS) napad
Man-in-the-middle napad
Napad kompromitacije kljua
Sniffer napad
Napad na aplikativnom nivou

2.4.1 Kraa identiteta - phishing

To je jedan od danas najpopularnijih napada. U najkraem, napad se ogleda u
pretvaranju da se radi o validno web sajtu odreene organizacije, kao i da se radi o
validnoj aktivnosti (resetovanje, neke administrativne aktivnosti, itd.) u vezi
korisnikih tajnih parametara pristupa sistemu (credentials). U tom smislu, napada
trai od korisnika da dostavi napadau svoje tajne parametre (brojeve kartica ili bilo
ta drugo).
Drugim reima, phishing predstavlja simuliranje pravog bankarskog web sajta ili
email adrese u cilju jednostavnog sakupljanja tajnih parametara krajnjih korisnika koji
se zatim koriste za eventualnu krau 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 omoguuje
jednostavnu masovnu zloupotrebu, koja privlai organizovan kriminal.
2.4.2 Prislukivanje
U optem sluaju, veliki deo mrenih komunikacija se realizuje u otvorenom obliku
(neifrovano), to omoguuje napadau koji je pristupio putevima podataka u mrei
da monitorie i ita saobraaj. Kada napada prislukuje komunikaciju, to se naziva
sniffing ili snooping. Mogunost da prislukiva monitorie mreu je generalno
najvei bezbednosni problem sa kojim se admnistratori susreu u jednoj organizaciji.
Ukoliko se ne primene jaki kriptografski mehanizmi ifrovanja, podaci mogu biti itani
od strane neovlaenih lica tokom prolaska kroz mreu.
2.4.3 Modifikacija podataka
Nakon to napada doe u poziciju da moe da ita podatke koji prolaze kroz
raunarsku mreu orgnaizacije, naredni logiki korak je esto da ih modifikuje. esto,
napada moe menjati podatke u paketima na nain da niti primalac niti poiljalac
mogu to primetiti.
2.4.4 Identity spoofing (IP address spoofing)

12

Veina mrea i operativnih sistema koristi IP adrese u cilju identifikacije validnog

raunara na mrei. U nekim sluajevima, mogue je da se zloupotrebi IP adresa od
strane zlonamernog korisnika (napadaa). Taj napad je poznat kao identity spoofing.
Napada moe koristiti specijalne programme da konstruie IP pakete koji se
pojavljuju na mrei kao da potiu sa validnih adresa u okviru Intranet-a (internet
mree) date organizacije. Nakon dobijanja pristupa mrei sa validnom IP adresom,
napada moe modifikovati, rerutirati ili brisati podatke.
Napada takoe moe sprovoditi i druge tipove napada, kao to je opisano u
narednim sekcijama.
2.4.5 Napadi na lozinke
Uobiajena stvar u veini operativnih sistema i mrenih bezbednosnih planova je
korienje sistema kontrole pristupa na bazi lozinki. Naime, najee je pristup kako
samom raunaru tako i mrenim resursima odreen korisnikim imenom (user name)
i lozinkom (password).
Ranije verzije komponenata operativnih sistema nisu uvek titile informacije o
identitetu korisnika tokom njihovog puta kroz mreu u cilju validacije. To je moglo da
omogui prislukivau da dobije validno korisniko ime i lozinku i da ih iskoristi da
dobije pristup mrei kao validan koristnik.
Kada napada nae i pristupi validnom korisnikom nalogu, on e imati ista prava
kao i aktielni korisnik. Na primer, ukoliko korisnik ima administratorska prava,
napada moe kreirati dodatne naloge za kasniji pristup.
Nakon to dobije pristup mrei sa validnim nalogom, napada moe realizovati bilo
koju od sledeih aktivnosti:

Da dobije liste validnih korisnika i imena raunara, kao i mrenih informacija,

Da modifikuje konfiguracije servera i same raunarske mree, ukljuujui i
kontrolu pristupa i ruting tabele,
Da modifikuje, rerutira ili obrie podatke.

2.4.6 Denial-of-service napad

Za razliku od napada na lozinke, Denial-of-Service (DoS) napad spreava normalno
korienje raunara ili raunarske mree od strane validnih korisnika.
Nakon to dobije pristup mrei, napada moe realizovati bilo koju od aktivnosti:

Da prevari zaposlene informacionog sistema tako da oni nisu u mogunosti da

odmah detektuju napad. Na taj nain, napada ima mogunost da kreira
dodatne napade,

13

Da alje nevalidne podatke aplikacijama ili mrenim servisima, prouzokujui

na taj nain da se prekine rad aplikacija ili servisa ili da ne rade na uobiajen
nain,
Da alje veliku gomilu saobraaja sve dok se raunar ili itava mrea ne
ugase,
Da blokira saobraaj to rezultuje u nemogunosti pristupa mrenim resursima
od strane autorizovani korisnika.

2.4.7 Man-in-the-middle napad

Kao to i sam ime kae, man-in-the-middle napad se ostvaruje kada neko
neovlaeno, postavljen izmeu dva validna korisnika koji komuniciraju, vri aktivno
monitorisanje, prihvatanje i kontrolu komunikacije i to bez znanja ovlaenih
korinsika.
Na primer, napada moe da dogovori/uspostavi kljueve za ifrovanje sa oba
ovlaena korisnika. Svaki korisnik tada alje ifrovane podatke napadau koji moe
da deifruje podatke.
Kada raunari komuniciraju na niskim nivoima mrenog sloja, raunari mogu ne biti u
mogunosti da odrede sa kojim raunarima u mrei oni u stvari razmenjuju podatke.
2.4.8 Napad kompromitacije kljua
Klju predstavlja tajni kod ili broj koji se zahteva za ifrovanje, deifrovanje ili
validaciju zatienih informacija. Iako odreivanje/rekonstrukcija kljua predstavlja
jedan teak i raunarski intenzivan process za napadaa, to je mogue realizovati.
Kada napada doe do kljua, taj klju se posmatra kao kompromitovan klju.
Napada koristi kompromitovan klju da dobije pristup zatienoj komunikaciji pri
emu niti poiljalac niti primalac nisu svesni da su predmet napada.
Uz korienje kompromitovanog kljua, napada moe deifrovati ili modifikovati
podatke. Napada takoe moe pokuati da koristi kompromitovan klju da izrauna
dodatne kljueve koji mogu omoguiti pristup drugim zatienim komunikacijama.
2.4.9 Sniffer napad
Sniffer je aplikacija ili ureaj koji moe da ita, monitorie i preuzima podatke i pakete
koji se razmenjuju u mrei. Ukoliko paketi paketi podataka nisu ifrovani, sniffer
program moe imati poptpun uvid u podatke koji su unutar paketa.
Korienjem sniffer programa, napada moe realizovati sledee operacije:

Analizirati mreu i informacije o pristupu, eventualno prouzrokujui da mrea

prestane da odgovara ili postane neispravna,
Pristupiti i itati privatnu komunikaciju.

14

2.4.10 Napad na aplikativnom nivou

Napad na aplikativnom nivu cilja aplikatvine servere prouzrokujui greku u
operativnom sistemu servera ili aplikacijama. To moe rezultovati da napada dobije
mogunost da preskoi normalne kontrole pristupa. Napada koristi prednosti takve
situacije, zadobijna kontrolu nad aplikacijom, sistemom ili mreom i moe sprovesti
neku od sledeih operacija:

Da ita, dodaje, brie ili modifikuje podatke ili operativni sistem,

Da ubaci virus koji e koristiti raunare i softverske aplikacije da kopira viruse
kroz celu raunarsku mreu,
Da uvede sniffer program u cilju analize mree i da dobije informacije koje e
eventualno moi da se koriste da se prouzrokuje da mrea prestane da
odgovara ili postane neispravna,
Da se na neuobiajen nain prekine rad aplikacija ili operativnih sistema,
Da se deaktiviraju druge bezbednosne kontrole da bi se omoguili budui
napadi.

U prilogu A su date dodatne informacije o potencijalnim napadima na raunarske

mree i moguim nainima odbrane, kao i detaljne informacije o pitanju antivirusne
zatite.

2.5 Tehnologije zatite savremenih raunarskih mrea

U cilju zatite informacionih sistema i savremenih raunarskih mrea od gore
navedenih napada, neophodno je uspostaviti sistem bezbednosti u organizaciji u
kome e se primenjivati sledee tehnologije zatite:

Tehnologija digitalnog potpisa bazirana na asimetrinim ifarskim sistemima,

Zatita tajnosti podataka primenom simetrinih ifarskih sistema,
Infrastruktura sistema sa javnim kljuevima (PKI Public Key Infrastructure).

15

3. PRIMENA KRIPTOGRAFSKIH METODA ZATITE U

INFORMACIONOM SISTEMU
Kriptografski algoritmi koji se primenjuju u sistemima zatite Internet/Intranet
raunarskih mrea dele se u dve velike grupe:

Simetrini kriptografski algoritmi,

Asimetrini kriptografski algoritmi.

Podela je izvedena na osnovu posedovanja informacija neophodnih za ifrovanje i

deifrovanje.

3.1 Simetrini kriptografski algoritmi

Grupu simetrinih kriptografskih algoritama predstavljaju algoritmi kod kojih je klju
za ifrovanje identian kljuu za deifrovanje, Slika 3.1. Algoritmi iz ove grupe se
takoe nazivaju i algoritmi sa tajnim kljuem jer je tajnost kljua koji se koristi i za
ifrovanje i za deifrovanje esencijalna za bezbednost poruka u sistemu.
Ovi sistemi predstavljaju osnovu tradicionalne kriptoloke teorije i razvijaju se ve
veoma dugi niz godina. S obzirom da zatita informacija teinu primenu ima u
poslovima vezanim za dravne strukture (vojska, policija i diplomatija), ovi sistemi su
bili iskljuivo tajni sistemi, namenski definisani i realizovani od strane nadlenih
dravnih institucija.

Kriptoanalitiar

X
Izvor
poruke

EA

DA

Odredite

Bezbedni kanal

Izvor
kljua

Slika 3.1: Simetrini kriptografski sistemi

16

Sa porastom intenziteta i primene elektronskih oblika komunikacija javila se potreba

za definisanjem javnih simetrinih kriptografskih algoritama pa je u poslednjih
desetak godina definisano vie javnih simetrinih 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. Imajui u vidu eksplozivni razvoj poslovnih i finansijskih
sistema u poslednje vreme, javni simetrini kriptografski algoritmi su postali
dominantni u pogledu korienja.
Meutim, nijedan od njih nije usvojen kao generalni standard ve pomenuti sistemi
uglavnom koriste odgovarajue liste moguih kriptografskih algoritama. Na taj nain,
kao parametar komunikacije, bira se i identifikator simetrinog ifarskog algoritma
koji e se koristiti pri datoj transakciji.
Iako je po masovnosti komercijalna upotreba simetrinih kriptografskih algoritama
daleko prevazila upotrebu u tajnom sektoru (vezanom za dravne strukture), glavni
teorijski rezultati se i dalje deavaju u oblasti tajne kriptologije i tajnih sistema. Velika
veina drava ima specijalizovane organizacije koje se bave dizajniranjem i analizom
raznih vrsta ifarskih sistema (npr. NSA u SAD). Stepeni dostignua u toj oblasti
najee nisu javno poznati i nalaze se u sferi pretpostavki.
Postoje dve osnovne vrste simetrinih ifarskih sistema:

blok ifarski sistemi,

sekvencijalni ifarski sistemi (stream cipher).

3.1.1 Blok ifarski sistemi

Blok ifarski sistemi procesiraju blokove neifrovanog signala - otvorenog teksta (OT)
i ifrovanog signala ifrata (ST), obino u blokovima ija je veliina 64 bita ili vie.
Sekvencijalni ifarski sistemi procesiraju nizove bita, bajtova ili rei (16 ili 32 bita) OT
i ST.
Ako se u toku procesa ifrovanja jedne poruke nekim blok ifarskim sistemom vie
puta pojavljuje isti blok otvorenog teksta (OT) rezultat e biti uvek isti blok ifrata
(ST), to nije sluaj kod sekvencijalnih ifarskih sistema.
Kod sekvencijalnih ifarskih sistema verovatnoa da isti niz bita, bajtova ili rei OT pri
svakom pojavljivanju u jednoj poruci proizvodi isti ifrat tei 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 nali 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, daemo kratak
opis AES simetrinog blok kriptografskog algoritma.
3.1.1.1 DES (Data Encryption Standard)
DES je zvanino objavljen 1976. godine. Iako se danas smatra nesigurnim za veinu
aplikacija zbog veoma kratkog kljua (56 bita), on predstavlja teoretsku osnovu za
sve blok ifarske algoritme. Na osnovu njega su izgraeni i njegovi naslednici koji su
danas u upotrebi (AES, 3DES).
DES je simetrini blok ifarski algoritam koji za ulaz uzima string fiksne duine i
serijom komplikovanih transformacija ga transformie u ifrovani tekst iste duine.
Kod DES-a veliina bloka je 64 bita.
Poto spada u simetrine algoritme, dekripcija se moe izvriti samo uz poznavanje
kljua kojim je izvreno 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 identinih faza, koje se nazivaju rundama, slika 3.2. Osim njih
postoje i inicijalna i zavrna permutacija, koje su inverzne operacije. Meutim, one
nemaju kriptografski znaaj.
Pre poetka glavnih rundi blok se se dijeli na dve 32-bitne polovine koje se
procesiraju naizmenino. Ovo ukrtanje se naziva Feistel-ova ema. Feistel-ova
struktura osigurava da su enkripcija i dekripcija vrlo slini procesi. Jedina razlika je da
se potkljuevi primenjuju u obrnutom redosledu u dekripciji. Ostatak algoritma je
identian. Ovo uveliko olakava 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 pomou odgovarajueg potkljua. Izlaz iz F funkcije se tada kombinuje sa
drugom polovinom bloka pomou XOR operacije. Zatim polovine bloka zamene
mjesta prije poetka sljedee runde. Nakon zavrne runde polovine ne menjaju
mjesta.
Feistel-ova (F) funkcija
Operie sa 32-bitnom polovinom bloka i sastoji se od 4 faze, slika 3.3:
1. Ekspanzija 32-bitna polovina bloka se proiruje do 48 bita koristei
ekspanzionu permutaciju, tj. dupliciranjem nekih bita.
2. Miksanje sa kljuem rezultat se kombinuje sa potkljuem koristei XOR
operaciju. esnaest 48-bitnih potkljueva (po jedan za svaku rundu) se izvode
iz glavnog kljua koritenjem algoritma key schedule.
3. Supstitucija nakon miksanja sa potkljuem 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 pomoe nelinearne transformacije. S-boxovi predstavljaju jezgro sigurnosti DES-a. Bez njih bi algoritam bio linearan i
samim tim bi njegovo razbijanje bilo trivijalno.
4. Permutacija 32 bita izalih iz S-box-ova se rearaniraju pomou 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 koritenjem DES-a tri puta, slika 3.4.
Kad je otkriveno da 56-bitni klju DES-a nije dovoljan da se algoritam zatiti od brute
force napada, 3DES je izabran kao jednostavan nain da se proiri klju bez potrebe
prebacivanja na novi algoritam. Koritenje tri koraka je esencijalno u spreavanju
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 obinom DES-u i ne bi bila sigurnija.
Najjednostavnija varijanta 3DES-a ima sljedeu emu:
DES(k3;DES(k2;DES(k1;M))),
gde je M blok poruke koja se enkriptuje, a k1, k2, i k3 su DES kljuevi. Ova varijanta
se popularno naziva EEE poto su sve tri DES operacije enkripcije. Da bi se
pojednostavnila interoperabilnost izmeu DES-a i 3DES-a srednji korak se obino
zamenjuje dekripcijom (EDE mod):
DES(k3;DES-1(k2;DES(k1;M))).

20

Na taj nain se jedna DES enkripcija sa kljuem k predstavlja kao 3DES-EDE gdje je
k1 = k2 = k3 = k. Izbor dekripcije kao srednjeg koraka ne utie na sigurnost algoritma.

Slika 3.4: 3-DES algoritam

Uopteno, 3DES sa tri razliita kljua ima duinu kljua od 168 bita - tri DES kljua
po 56 bita, ali zbog meet-in-the-middle napada efektivna duina je samo 112 bita.
3DES lagano izlazi iz upotrebe i uveliko se zamijenjuje sa AES-om. Izuzetak je
industriji elektronskog plaanja 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 bri. 3DES daje neto bolje performanse u
hardverskim implementacijama, ali i tu AES daje bolje rezultate. Konano, AES nudi
veu sigurnost: vei blok i potencijalno dui klju.
3.1.1.3 IDEA
Ovo je simetrini blok ifarski algoritam.
injenice:

enkriptuje blok veliine 64 bita;

21

koristi klju duine 128 bita;

52 potkljua duine 16 bita;
koristi jedan par potkljueva po rundi;
koristi 8 unakrsnih runda (iteracije) kod enkriptovanja;
dekripcija se vri inverznom enkripcijom.

Prednosti:

do sada je izdrao 'napade' akademske zajednice

IDEA koristi 52 potkljua duine 16 bitova i ima 8 rundi enkripcija poruke. Po dva
potkljua se koriste u svakoj rundi (16), zatim etiri potkljua se koriste pre svake
runde (32), a poslednja etiri potkljua koriste se nakon zadnje runde (4) =
16+32+4=52.
Potkljuevi se dobijaju tako to se 128 bitni klju razdeli u prvih 8 potkljueva (K1-K8)
veliine 16 bita. Zatim se sledeih 8 potkljueva dobije tako to se 25 puta napravi
kruni pomeraj ulevo svakog od prethodno napravljenih potkljueva. Postupak se
ponavlja dok se ne kreiraju svi potkljuevi.
Iako je generisanje kljueva pravilno, to bi ukazalo na slabost algoritma, do sada je
ovaj algoritam izdrao sva nastojanja akademskih ustanova na njegovom razbijanju.
3.1.1.4 AES algoritam
Kao to je ve reeno, u toku 2001. godine, NIST (National Institute of Standards and
Technology) organizacija u SAD je objavila standard za simetrine 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 istraivai: Joan Daemen i Vincent Rijmen. Rijndael
predstavlja blok ifarski algoritam koji podrava promenljivu duinu bloka informacije
(128, 192 i 256 bita) kao i promenljivu duinu kljua (128, 192 i 256 bita).
Naime, poruke ifrovane DES algoritmom su se, zbog nedostataka u samom
algoritmu (bezbedonosni nedostaci u supstitucionim s-tabelama), male duine kljua
(56-bita) i poveane procesne moi raunara, mogle deifrovati za samo par asova.
Nakon selekcione procedure, za realizaciju AES standarda izabran je Rijndael
algoritam koga su realizovali belgijski mateatiari: Joan Daemen i Vincent Rijmen.
Rijndael je blok ifarski algoritam koji podrava promenljivu duinu bloka otvorenog
teksta (128, 192 i 256 bita) kao i promenljivu duinu kljua (128, 192 i 256 bita).
Rijndael algoritam je u odnosu na konkuretske algoritme (MARS, RC6, Serpent,
Twofish) bio bri i zahtevao je manje operativne memorije u procesu ifrovanja i
deifrovanja poruka. Rijndael algoritam sa 128-bitnom duinom kljua je bri za oko
2.5 puta u odnosu na 3-DES algoritam.

22

AES algoritam realizuje operacije ifrovanja i deifrovanja bloka podataka u

promenljivom broju ciklusa. Broj ciklusa zavisi od veliine kljua i iznosi 10/12/14 za
veliinu kljua 128/192/256 bita, respektivno. Pre poetka ifrovanja ili deifrovanja
vri se ekspanzija kljua.
Realizacija ifrovanja u AES algoritmu
U realizaciji ifarske transformacije bloka podataka otvorenog teksta se izvravaju
etiri razliita tipa funkcija koje se primenjuju nad elementima matrice meurezultata
dimenzija 44 bajta:

nelinearna zamena bajtova pomou supstitucione tabele (funkcija ByteSub),

promena mesta bajtova unutar istog reda (funkcija ShiftRow),
transformacija bajtova unutar iste kolone (funkcija MixColumns),
sabiranje po modulu dva sa odgovarajuem delom kljua (funkcija
AddRoundKey).

U poslednjem ciklusu ifrovanja se ne obavlja transformacija bajtova unutar iste

kolone (funkcija MixColumns).
U Rijndael algoritmu sve operacije sabiranja i mnoenja se vre nad elementima
konanog polja (pored konanih polja od r-elemenata (r-prost broj) postoje i konana
polja od q=rm elemenata, gde je m prirodan broj; navedena konana polja se nazivaju
i polja Galoa (Galois Field) u oznaci GF(rm), u ast francuskog matematiara Galoa
(E. Galois)) od 256 elemenata (u oznaci GF(28) ):

pri sabiranju bajtova primenjuju se bitska operacija sabiranja po modulu dva,

rezultat mnoenja dve vrednosti je proizvod po modulu vrednosti nerazloivog
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 nerazloivog polinoma:

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

(3.1.1.2)

Svaki elemenat konanog polja, a(x), ima jednoznanu inverznu vrednost, ainv(x),
koja zadovoljava uslov:
a(x)*ainv(x) mod m(x)=1

(3.1.1.3)

Da bi se ubrzao proces mnoenja u skupu od 256 elemenata konanog polja

formiraju se logaritamska i antilogaritamska tabela. Vrednost svakog elementa
konanog polja p moe 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 konanog polja x postoji

23

odgovarajua vrednost L koja zadovoljava uslov {x}={03}L. U antilogaritamskoj tabeli

za svaki elemenat konanog polja x postoji odgovarajua vrednost E koja
zadovoljava uslov {E}={03}x.
U procesu mnoenja dva elementa konanog polja a i b, pomou logaritamske tabele
se odrede koeficijenti i takvi da je a={03} i b= {03}. Mnoenjem vrednosti a i b
dobija se vrednost ab= {03}+. Traeni proizvod se dobija kada se iz
antilogaritamske tabele iz ulaza x= + odredi vrednost E = ab.
Logaritamska i antilogaritamska tabela se takoe mogu koristiti za pronalaenje
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
veliine, se dobija kada se iz antilogaritamske tabele iz ulaza x=255- , proita
vrednost E.
U procesu ifrovanja se realizuju sledee funkcije:
1. Funkcija ByteSub vri nelinearnu transformaciju bajta ulazne poruke pomou
supstitucione s-tabele (tkz. S-box tabele). Pri kreiranju supstitucione s-tabele,
vrednost ulaza x (x=0255) se dobija u dva koraka:

odreivanje inverzne vrednosti ulazne veliine xinv x pomou logaritamske

i antilogaritamske tabele, prema prethodno opisanom mehanizmu.
vrednost datog ulaza supstitucione s-tabele se dobija odreivanjem vrednosti
svakog bita i unutar bajta (0 i 8):

xi 1 xi1 xi14 mod 8 xi15 mod 8 xi16 mod 8 xi17 mod 8 ci ,

(3.1.1.4)

gde je: c={63h},

Navedeni postupak se moe prikazati i u matrinom obliku:

24

 x7
1
x 6
1

1 1 1 1
0 1 1 1

x51 0 0 1 1
1
x4 0 0 0 1
x 1 1 0 0 0
3
1
x2 1 1 0 0
x 1 1 1 1 0
1
1
x0 1 1 1 1

(3.1.1.5)

1 0 0 0 x

1 1 0 0 x
1 1 1 0 x

1 1 1 1 x
1 1 1 1 x

0 1 1 1 x

00 11 x

0 0 0 1 x

1
7
1
6
1
5
1
4
1
3
1
2
1
1
1
0

0

1

1

0
0

0
1

1

Nakon kreiranja s-tabele vri 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 vrednou iz odgovarajueg ulaza iz s-tabele.

a0, 0

a0, 1

a1, 0

a1, 1

a2, 0

a2, 1

a0, 2
ai, j

a2, 2

a0, 3

sbox

b0, 0

b0, 1

a1, 3

B1, 0

b1, 1

a2, 3

B2, 0

b2, 1

b0, 2
bi, j

b2, 2

b0, 3
b1, 3
b2, 3

25

a3, 0

a3, 1

a3, 2

a3, 3

B3, 0

b3, 1

b3, 2

b3, 3

Slika 3.5: Grafiki prikaz nelinearne transformacije poruke pomou s-tabele

2. Funkcija ShiftRows obavlja operaciju nad elementima u redovima matrice
podataka dobijene nakon nelinearne transformacije pomou s-tabele. Pravilo po
kome se vri promena mesta bajta unutar istog reda matrice je prikazano sledeim
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 meurezultata je prikazana na Slici 3.6.

Slika 3.6: Grafiki prikaz promene mesta bajtova u redu matrice meurezultata
3. Funkcija MixColumns vri transformaciju elemenata kolone matrice meurezultata
nakon realizacije funkcije ShiftRows. Elementi kolone matrice se posmatraju kao
koeficijenti polinoma, pri emu svaki koeficijent predstavlja elemenat konanog polja
GF(28). Zatim se, tako dobijeni polinomi, mnoe sa konstantnim polinomom
n(x)='03'x3 + '01'x2 + '01'x + '02' po modulu x4 +1. Navedeno modularno mnoenje se
moe prikazati i u matrinom obliku:

e3,c 02
e
2,c 03
e1,c 01

e0,c 01

01
02
03
01

01
01
02
02

03
01
01

03

d 3, c
d
2 ,c

d1,c

d 0 ,c

(3.1.1.7)

gde je: 0c4.

Nain na koji se vri transformacija kolona matrice je prikazana na Slici 3.7.

26

d0, 0

D0, 1

d1, 0

D1, 1

d2, 0
d3, 0

d0, j

a0, 2

c(x)

e0, j

e0, 0

e0, 1

d1, 3

e1, 0

e1, 1

D2, 1

a2,d22, j d2, 3

e2, 0

e2, 1

b2,e2

e2, 3

d3, 1

a3, 2

e3, 0

e3, 1

b3, 2

e3, 3

d1, j

d3, j

d0, 3

d3, 3

b0, 2

e1, j

2, j

e0, 3
e1, 3

e3, j

Slika 3.7: Grafiki prikaz promene mesta bajtova u kolonama matrice meurezultata
4. Funkcija AddRoundKey vri operaciju eksluzivne disjunkcije nad elemenata
matrice, dobijene nakon izvrenja funkcije MixColumn, i matricom odgovarajueg
dela ekspandovanog kljua, Slika 3.8.
e0,

e0,

e0,

e0,

k0,

k0,

k0,

k0,

e1,
e2,
e3,

e1,
e2,
e3,

e1,
e2,
e3,

e1,
e2,

k1,

e3,

k2,
k3,

k1,
k2,
k3,

k1,
k2,
k3,

k1,
k2,
k3,

r0, 0

r0, 1

r0, 2

r0, 3

r1, 0

r1, 1

r1, 2

r1, 3

r2, 0

r2, 1

r2, 2

r2, 3

r3, 0

r3, 1

r3, 2

r3, 3

Slika 3.8: Grafiki prikaz funkcije AddRoundKey

Optimizacija realizacije ifrovanja u AES algoritmu
Tranformacija kolone ulazne matrice kroz jedan ceo ciklus ifrovanja se moe
matematiki prikazati sledeim nizom izraza:

r0, j
r
1, j
r2, j

r3, j
e0, j 02
e
1, j 01
e2, j 01

e3, j 03

e0, j

k 0, j

k
e1, j
1, j
e2, j k 2, j

e3, j k 3, j
03 01 01
02 03 01

01 02 03

01 01 02

(funkcija AddRoundKey)

d 0, j
d
1, j

d 2, j

d 3, j

(funkcija MixColumns)

(3.1.1.8)

(3.1.1.9)

27

 d 0, j
d
1, j
d 2, j

d 3, j

b0, j
b1, j 1

b2, j 2

(funkcija ShiftRows)

(3.1.1.10)

b3, j 3

b0, j s a0, j
b
sa
1, j 1
1, j 1
b2, j 2 s a 2, j 2

b3, j 3 s a3, j 3

(funkcija ByteSub)

(3.1.1.11)

Sumarno se dobija sledei izraz koji opisuje proces transformacije j-te kolone
0 j 4 ulaznog podataka u jednom ciklusu ifrovanja.

s a3, j 3

r0, j

1, j
r2, j

r3, j

s a0, j
s a1, j 1
s a 2 , j 2

02 03 01 01
01 02 03 01

01 01 02 03

03 01 01 02

k 0, j
k
1, j

k 2, j

k 3, j

(3.1.1.12)

Mnoenje matrica moe se prikazati i sledeim izrazom:

r0, j
r
1, j s a
0, j
r2, j

r 3, j

02
01
s a1, j 1
01

03

03
02
s a 2, j 2
01

01

01
03
s a3, j 3
02

01

01 k 0, j
01 k
1, j

03 k 2, j
k
02 3, j

(3.1.1.13)

inilac mnoenja s[ ai , j ] se dobija odreivanjem vrednosti ulaza ai , j supstitucione

s-tabele. Da bi se ubrzao proces mnoenja mogu se kreirati 4 tabele:

s a 2

T0 a s a
s a
s a 3

s a 3

T1 a s a 2
s a
s a

s a

T2 a s a 2
s a 3
s a

s a

T2 a s a
s a 3
s a 2

(3.1.1.14)

Svaka od etiri tabele sadri 256 etvorobajtnih rei, tako da je ukupan memorijski
prostor potreban za njihovo skladitenje 4KB. Primenom datih tabela, transformacija
j-te kolone ulaznog podatka u jednom ciklusu ifrovanja se moe predstaviti izrazom:

r j T0 a 0, j T1 a1, j 1 T2 a 2, j 2 T3 a3, j 3 k j

(3.1.1.15)

Definiimo funkciju RowByte(W) koja vri rotaciju svakog bajta ulazne rei za jedno
mesto udesno W=b3b2b1b0 (bi , i-ti bajt rei), tako da je izlazna re oblika W=b2b1b0b3.

28

Veza izmeu tabela T0 , T1 , T2 i T3 se moe prikazati sledeom relacijom:

Ti a RotByte Ti 1 a

(3.1.1.16)

Transformacija j-te kolone matrice ulaznog podatka u jednom ciklusu ifrovanja se

moe predstaviti sledeim izrazom:

r j k j T0 a 0, j RotByte T0 a1, j 1 RotByte T0 a 2, j 2 RotByte T0 a 3, j 3

(3.1.1.1

7)
Primenom ove formule umesto etiri tabele sa ukupno 1024 etvorobajtnih rei (4KB)
potrebno je kreirati jednu tabelu od 256 rei (1KB), ali ciklus ifrovanja traje neznatno
due, za tri dodatne operacije rotacije bajta unutar rei (funkcija RotByte).
Realizacija deifrovanja u AES algoritmu
Proces deifrovanja poruke je slian procesu ifrovanja. U procesu deifrovanja se
primenjuju etiri razliita tipa funkcija nad elementima matrice meurezultata
dimenzija 44 bajta:

nelinearna zamena bajtova pomou 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 odgovarajuim delom kljua (funkcija
AddRoundKey).

U poslednjem ciklusu deifrovanja se ne obavlja transformacija bajtova unutar iste

kolone (funkcija InvMixColumns).
U procesu deifrovanja se realizuju sledee funkcije:
1. Nelinearna transformacija ulazne matrice dimenzija 44 bajta se vri pomou
inverzne supstitucione s-tabele. U procesu kreiranja inverzne supstitucione s-tabele
vrednost za svaki od ulaza x (x=0..255) se odreuje u dva koraka:

transformacija vrednosti ulaznog bajta x se realizuje odreivanjem vrednosti

svakog bita i unutar bajta (0 i 8):
xi x i 2

mod 8

x i 5

mod 8

x i 7

mod 8

di

(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= x 1 .

2. Funkcija InvShiftRows obavlja operacije nad elementima u redovima matrice

meurezultata, dobijenom nakon prethodno opisane transformacije. Pravilo po kome

29

se vri promena mestu bajta unutar istog reda matrice se moe prikazati sledeim
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 meurezultata je prikazana na Slici 3.9.
3. Funkcija InvMixColumns vri transformaciju elemenata kolone matrice dobijene
nakon izvrenja funkcije InvShiftRows. Elementi kolone matrice se posmatraju kao
koeficijenti polinoma, pri emu svaki koeficijent predstavlja elemenat konanog polja
GF(28). Zatim se, tako dobijeni polinomi, mnoe sa konstantnim polinomom
p(x)='0B'x3 + '0D'x2 + '09'x + '0E' po modulu x4 +1. Navedeno modularno mnoenje se
moe prikazati u matrinom obliku:

e3,c
e
2 ,c

e1,c

e0,c

0 E 09 0 D 0 B d 3,c
0 B 0 E 09 0 D d
2 ,c

0 D 0 B 0 E 09 d1,c

09 0 D 0 B 0 E d 0,c

(3.1.1.20)

gde je: 0c4.

Slika 3.9: Grafiki prikaz promene mesta bajtova u redu matrice meurezultata
4. Funkcija AddRoundKey vri sabiranje po modulu dva elementa matrice, dobijena
nakon izvrenja funkcije InvMixColumns, sa odgovarajuim delom kljua za
deifrovanje:

30

 r3,c
r
2 ,c
r1,c

r0,c

e3,c
e
2,c
e1,c

e0 , c

k 3,c
k
2,c
k1,c

k 0 ,c

(3.1.1.21)

3.1.2 Kriptografski modovi blok ifarskih algoritama

Kriptografski mod predstavlja nain upotrebe bazinog ifarskog algoritma i najee
je kombinacija neke vrste povratne petlje i odreenih jednostavnih operacija.
Operacije koje se primenjuju nad algoritmom su uglavnom jednostavne jer je
bezbednost odreena bazinim ifarskim algoritmom a ne kriptografskim modom.
Blok ifarski sistemi se primenjuju u razliitim 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 najlaki nain primene blok ifarskih sistema blok OT se ifruje u blok ST, Slika 3.10. Svaki OT blok se ifruje nezavisno. Sa
kriptoloke strane, ECB mod je najproblematiniji.
Naime, ako kriptoanalitiar poseduje parove OT i ST za nekoliko poruka, mogue je
da tokom konverzacije dve strane formira pravu kodnu knjigu, skup odgovarajuih
parova ST i OT, i bez poznavanja kljua.
U veini realnih situacija: fragmenti poruka tee ponavljanju, razliite poruke imaju
zajednike delove, odreeni raunarski generisane poruke (kao e-mail) imaju
regularnu strukturu, poruke mogu biti veoma redundantne i imati veoma duge nizove
nula i pauze. Ovi problemi su najistaknutiji na poetku i na kraju poruke, gde se u
dobro definisanim zaglavljima i futnotama mogu nalaziti informacije o poiljaocu,
primaocu, datumu, itd.

31

Formiranje reprezentativne kodne knjige ne samo da omoguava treoj strani pristup

informacijama ve joj dodatno omoguava da moe modifikovati i ponavljati ifrovane
poruke (tzv. block replay problem) bez poznavanja kljua i algoritma, u sluaju da ima
mogunost presretanja ifrovanih poruka izmeu dve strane. Ovi problemi su inicirali
uspostavljanje zavisnosti izmeu susednih blokova ifrata kroz definisanje novih
kriptografskih modova blok ifarskih sistema.

Slika 3.10: Grafiki prikaz rada u ECB modu

3.1.2.2 Mod ulanavanja blokova (CBC Cipher Block Chaining)
Mehanizam ulanavanja povezuje blokove ifrata tako to se rezultat ifrovanja
prethodnih blokova koristi pri ifrovanju tekueg bloka.
Drugim reima, svaki blok se koristi za modifikaciju ifrovanja sledeeg bloka tako da

svaki blok ST zavisi ne samo od tekueg bloka OT ve i od svih prethodnih blokova

OT. Naini na koje se to moe ostvariti su raznovrsni.

Slika 3.11: Grafiki prikaz rada u CBC modu

32

U CBC modu, Slika 3.11, taj uticaj se realizuje tako to se izvrava operacija
ekskluzivno ili (XOR) izmeu 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 sadraj povratnog registra se spregnu operacijom
ekskluzivne disjunkcije i tako dobijeni blok se transformie 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 nain, rezultat ifrovanja svakog bloka zavisi od svih prethodnih blokova.
Proces deifrovanja sledi direktno i odvija se na sledei nain:
1. U povratni registar se smesti inicijalna vrednost.
2. Blok ifrata C deifruje se primenom transformacije E 1 , tako dobijeni blok
teksta i sadraj 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 deifrovanje.
Matematiki, proces ifrovanja i deifrovanja moe se prikazati na sledei nain,
relacijama (3.1.1.22) i (3.1.1.23), respektivno:
CTi E k (OTi CTi 1 )

(3.1.1.22)

OTi CTi 1 Dk (CTi )

(3.1.1.23)
CBC mod prouzrokuje da se identini blokovi OT ifruju u razliite ST blokove samo
ako su neki prethodni blokovi razliiti. Dve kompletno identine poruke e se ipak
ifrovati u iste ST.
Ovaj problem se moe reiti tako to se za prvi blok podataka uzima neka sluajna
veliina. Ovaj blok sluajnih podataka se naziva inicijalizacioni vektor (IV). Kada
primalac deifruje ovaj blok, on prosto smeta IV u povratni registar. Tekue vreme
sistema (timestamp) esto predstavlja dobro reenje za IV. Primenom IV, identine
poruke se ifruju u razliite ST.
Primenom IV, eliminisana je mogunost primene block replay metode. tavie, IV ne
mora da bude tajni podatak i moe se preneti otvoreno, zajedno sa ST, uz upotrebu
nekog od mehanizama zatite integriteta.
Meutim, moda ne tako oigledno kao u ECB modu, i u CBC modu postoje
odreeni bezbednosni problemi koji se mogu manifestovati kao odreena mogunost
da kriptoanalitiar dodaje odreene blokove na krajeve poruka koje se razmenjuju i u
injenici da veoma duge poruke i dalje nisu imune na pojavljivanje odreenih
identinih oblika iako se vri proces ulanavanja.

33

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 veliine r bita (r < n veliina bloka), to u CBC modu nije mogue.
Ovim modom se prevazilazi osnovni problem CBC moda - da ifrovanje i prenos
podataka ne mogu poeti sve dok se ne primi kompletan blok podataka. U CFB
modu, podaci se ifruju u manjim jedinicama od aktuelne veliine bloka i ovaj mod se
oznaava kao r-bitni CFB mod, gde je r manje ili jednako od veliine bloka osnovnog
blok ifarskog sistema.
Proces ifrovanja se odvija na sledei nain, Slika 3.12:
1. Otvoreni tekst se podeli u blokove veliine r bita, formira se inicijalni vektor
veliine n bita i smesti u povratni registar. Odabere se K, klju za ifarsku
transformaciju.
2. Formira se izlazni blok, O, tako to se izvri ifarska transformacija kljuem K
tekueg sadraja povratnog registra.
3. Blok ifrata se formira tako to se operacija ekskluzivne disjunkcije izvri nad
tekuim blokom otvorenog teksta i r bita najmanje teine bloka O.
4. Sadraj povratnog registra se pomera za r bita u levo i na mesto r bita
najmanje teine se smeta formirani blok ifrata.
Koraci 2-4 se ponavljaju sve dok ima blokova otvorenog teksta. Deifrovanje se
odvija na slian nain.
1. Formira se inicijalni vektor veliine n bita i smesti u povratni registar. Odabere
se K, klju za ifarsku transformaciju.
2. Formira se izlazni blok, O, tako to se ivri ifarska transformacija kljuem K
tekueg sadraja povratnog registra.
3. Blok otvorenog teksta se formira tako to se operacija ekskluzivne disjunkcije
izvri nad tekuim blokom ifrata i r bita najmanje teine bloka O.
4. Sadraj povratnog registra se pomera za r bita ulevo i na mesto r bita
najmanje teine se smeta tekui blok ifrata.
Inicijalizacioni vektor ima istu ulogu kao i u CBC modu, da sprei pojavljivanje istih
ifrata u sluaju istih poruka ifrovanih jednakim kljuevima. Iz opisa naina
transformacije jasno je da je za ispravno deifrovanje neophodno da je prethodnih
n
k

blokova ifrata ispravno deifrovano.

S obzirom da se i u procesu ifrovanja i u procesu deifrovanja koristi ista ifarska

transformacija, to algoritam kojim se formira blok O ne moe biti iz klase algoritama
sa javnim kljuem.

34

Slika 3.12: Grafiki 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, spreava
propagaciju greke i ima poboljane bezbednosne karakteristike. OFB mod rada
takoe omoguava prenos podataka u jedinicama manjim od veliine bloka.
Transformacija otvorenog teksta se odvija na sledei nain, slika 3.13:
1. Otvoreni tekst se podeli u blokove veliine r bita, formira se inicijalni vektor
veliine n bita i smesti u povratni registar. Odabere se K, klju za ifarsku
transformaciju.
2. Formira se izlazni blok, O, tako to se izvri ifarska transformacija kljuem K
tekueg sadraja povratnog registra .
3. Blok ifrata se formira tako to se operacija ekskluzivne disjunkcije izvri nad
tekuim blokom otvorenog teksta i r bita najmanje teine bloka O.
4. Blok O postaje sadraj povratnog registra.
Koraci 2-4 se ponavljaju sve dok ima blokova otvorenog teksta. Deifrovanje se
odvija na slian nain.

Formira se inicijalni vektor veliine n bita i smesti u povratni registar. Odabere

se K, klju za ifarsku transformaciju.
Formira se izlazni blok, O, tako to se ivri ifarska transformacija kljuem K
tekueg sadraja povratnog registra.
Blok otvorenog teksta se formira tako to se operacija ekskluzivne disjunkcije
izvri nad tekuim blokom ifrata i r bita najmanje teine bloka O.

35

Sadraj povratnog registra zameni se formiranim blokom O.

Koraci 2-4 se izvravaju sve dok ima blokova za deifrovanje.

Prethodno izloeni opis je prema standardu ISO 10116. Postoje takoe i druge
varijacije na ovu temu (npr. FIPS-81) ali se ova izloena verzija smatra, za sada,
najbezbednijom.

Slika 3.13: Grafiki prikaz rada u OFB modu

Pored toga to se radom u ovom modu onemoguava propagacija greke, dobra
osobina ovog moda rada je i to to se vei deo izraunavanja moe izvriti off-line,
nakon ega se vri samo XOR-ovanje izlaza algoritma i jedinica OT.
Detaljna analiza OFB moda rada je pokazala da ovaj mod rada treba koristiti samo u
sluaju da je r jednako duini bloka n. Drugim reima, 64-bitne blok ifarske
algoritme treba koristiti u 64-bitnom OFB modu.
3.1.2.5 Izbor odgovarajueg moda rada blok ifarskog sistema
Jedan od etiri bazina moda rada ECB, CBC, OFB ili CFB pogodan je za skoro
svaku aplikaciju. Koji e se mod koristiti zavisi od korisnikovih specifinih zahteva.
Ako su jednostavnost i brzina najbitniji, ECB mod je pravi izbor, kao najlaki i najbri
mod za korienje blok ifarskih sistema. Meutim, ECB mod je najslabiji sa
bezbednosne take gledita i ne preporuuje se za ifrovanje poruka. Sa druge
strane, ECB mod je veoma dobar za ifrovanje kratkih sluajnih podataka, kao to su
na primer kljuevi, 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. Takoe, ako je aplikacija softverski bazirana,
CBC je skoro uvek najbolje reenje. 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 izmeu terminala i host

36

raunara. OFB mod rada se najee koristi u sinhronim sistemima visokih brzina
gde se ne tolerie propagacija greaka.
3.1.3 Sekvencijalni ifarski sistemi
Sekvencijalni ifarski sistemi predstavljaju vrlo vanu klasu ifarskih algoritama. Oni
transformiu pojedinane karaktere (najee bite i bajtove otvorenog teksta)
koristei transformaciju koja pored kljua zavisi na odreeni nain i od vremenskog
trenutka u kojem se primenjuje, za razliku od blokovskih ifarskih sistema koji
transformiu blokove otvorenog teksta nepromenljivom transformacijom tokom
ifrovanja cele poruke.
Kao i obino, 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 duina bloka jedan karakter (bit, bajt ili mainska re (word) duine 16,
24 ili 32 bita).
Generalno govorei sekvencijalni ifarski sistem sastoji se od generatora niza kljua
(keystream generator) koji generie niz jedinica kljua k1, k2, , ki, i funkcije f koja
se primenjuje na niz jedinica OT: p1, p2, , pi, proizvodei niz jedinica ST: c1, c2, ,
ci, na bazi sledee relacije:
ci f ( k i , pi )

(3.1.3.1)

Na drugom kraju komunikacije, primenom inverzne funkcije na parove jedinica ifrata

i jedinica kljua dobijaju se jedinice poslatog OT. Naime:
pi f

( ki , ci )

(3.1.3.2)
jer je funkcija f tako odabrana da je
pi f

( ki , f ( ki , pi ))

(3.1.3.3)

Zbog jednostavnosti obrade za f se najee koristi ekskluzivna disjunkcija (XOR

operacija). Bezbednost nizovnog ifarskog sistema primarno je odreena
kriptolokim kvalitetom generatora niza kljua.
3.1.3.1 Klasifikacija sekvencijalnih ifarskih sistema
Klasifikacija sekvencijalnih ifarskih sistema se moe vriti po razliitim kriterijumima,
po nainu na koji se generie niz kljua, po tipu primenjenog algoritma (sa javnim ili
tajnim kljuem), itd. Osnovna je podela po nainu na koji se generie niz kljua. U
tom smislu postoje sistemi sa sluajnim i pseudo-sluajnim nizom.
Sistemi sa sluajnim nizom kod ovih sistema niz kljua se generie na sluajan
nain, tako to se jedinice kljua generiu nezavisno i sluajno. Ako se prema

37

prethodnim oznakama za funkciju f uzme ekskluzivna disjunkcija, tada se dobija

takozvani one time pad sistem za koji se moe 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 najkrai klju kojim se
postie apsolutna sigurnost. Naime, enon je u svojim radovima pokazao da je
neophodan uslov za apsolutnu bezbednost da entropija kljua bude vea ili jednaka
od entropije poruke. Kako je kod ovog sistema entropija kljua jednaka duini poruke,
ija entropija ne moe biti vea od njene duine, to sledi da je ovo zbilja optimalan
sistem u navedenom smislu.
Nedostatak ovog sistema je u injenici da oba uesnika komunikacije moraju imati
isti niz kljua koji mora biti tajan, to proizvodi, ponekad nepremostive, probleme u
upravljanju kljuevima jer treba obezbediti i dostaviti stranama u komunikaciji velike
koliine kljueva kako bi mogle nesmetano da komuniciraju.
Sistemi sa pseudosluajnim nizom kod ovih sistema se na osnovu inicijalne
vrednosti i dogovorenog algoritma generie niz jedinica kljua. Posedovanjem
identine inicijalne vrednosti, obe strane u komunikaciji su u stanju da produkuju isti
niz jedinica kljua i da ostvare bezbednu komunikaciju. Kako je generisanje jedinica
kljua deterministiko, niz kljua je u potpunosti definisan sa:

Poetnim unutranjim stanjem inicijalna vrednost kojom se definie poetno

stanje generatora kljua,
Funkcijom narednog stanja koja na bazi prethodnog unutranjeg stanja
generie novo unutranje stanje,
Izlaznom funkcijom koja na osnovu unutranjeg stanja generie izlaznu
jedinicu kljua.

Posledica injenice da je niz kljua deterministiki je da je on nuno periodian. Iako

su ovo na izgled injenice koje ovakve sisteme znaajno dezavuiu, stvari ne stoje
tako loe, i ti problemi se mogu sasvim uspeno prevazii. Naime, bezbednost
ovakvih sistema direktno zavisi od veliine inicijalnih podataka i kvaliteta
dogovorenog algoritma. Dobro dizajnirani algoritmi ovog tipa pruaju zatitu koja je
po kvalitetu vrlo blizu apsolutno bezbednim sistemima.
Sekvencijalni ifarski sistemi sa pseudosluajnim nizom se dele u dve velike grupe:

Sinhroni sekvencijalni ifarski sistemi

Samosinhroniui sekvencijalni ifarski sistemi

Sinhroni sekvencijalni ifarski sistemi su oni kod kojih se niz kljua generie
nezavisno od otvorenog teksta i ifrata, slika 3.14.
Proces ifrovanja se moe opisati sledeim skupom jednaina:
i 1 f ( i , k )
z i g ( i , k )
c i h ( z i , mi )

(3.1.3.4)

38

Gde se poetno stanje, 0, odreuje na osnovu inicijalne vrednosti k, f je funkcija

sledeeg stanja, g je funkcija koja produkuje niz kljua zi a h izlazna funkcija koja od
otvorenog teksta mi i niza kljua zi formira ifrat ci .
Kod ovih sistema niz kljua se generie nezavisno od niza jedinica poruke. Na obe
strane u komunikaciji se istovremeno generiu nizovi kljua. Uesnici u komunikaciji
su u stanju da razmenjuju poruke sve dotle dok su algoritmi za generisanje niza
kljua sinhronizovani meu sobom.
Ukoliko se desi gubitak ili umetanje jednog ili vie jedinica tokom prenosa ST,
deifrovanje e biti nekorektno. U sluaju takvog dogaaja, generatori niza kljua na
predajnoj i prijemnoj strani moraju se resinhronizovati, pre nego to nastave
komunikaciju.
Sa druge strane, u ovim sitemima se ne propagira greka i svaki pogrean bit u
prenosu ostae i u deifrovanom obliku pogrean, ali ta greka nee uticati ni na
prethodne ni na budue bite za prenos.
Prethodno navedena osobina moe posluiti aktivnom protivniku kao osnova za
razliite vrste pokuaja kompromitovanja ovakvog sistema.

Slika 3.14: Grafiki prikaz rada sinhronih sekvencijalnih ifarskih sistema

Samosinhroniui asinhroni sistemi su oni kod kojih je niz kljua dobija u funkciji
inicijalne vrednosti, dogovorenog algoritma i izvesnog konstantnog broja prethodnih
jedinica ifrata, Slika 3.15. Proces ifrovanja se opisuje sledeim skupom jednaina:
i (ci t , ci t 1,, ci 1 )
z i g ( i , k )
c i h ( z i , mi )

(3.1.3.5)
Gde je 0 (c t , , c 1 ) inicijalno stanje, poetno stanje odreuje se na osnovu
inicijalne vrednosti k, f je funkcija sledeeg stanja, g je funkcija koja produkuje niz

39

kljua zi a h izlazna funkcija koja od otvorenog teksta mi i niza kljua zi formira

ifrat ci .
Kod ovih sistema mogue je ostvariti samosinhronizaciju zato to deifrovanje zavisi
samo od fiksnog broja prethodnih jedinica ifrata, tako da je mogue sinhronizaciju
ponovo uspostaviti vraanjem na odreeni broj dobro primljenih znakova ifrata.

Slika 3.15: Grafiki prikaz rada samosinhroniuih sistema sa pseudo-sluajnim

nizom
Kod ovih sistema propagacija greke je takoe ograniena na fiksiran broj
uzastopnih jedinica a posle toga se preostale jedinice ifrata mogu ispravno
deifrovati.
Sekvencijalni ifarski sistemi imaju veliku ulogu u zatiti masovnih podataka zato to
obezbeuju kvalitetnu zatitu a pri realizaciji obezbeuju veliku brzinu obrade.
Teorija analize i sinteze sekvencijalnih ifarskih sistema sa pseudosluajnim nizom je
veoma razvijena i u glavnom jedna podstie drugu na razvoj.

3.1.3.2 RC4 algoritam

RC4 je najkoriteniji 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 poetak izlaznog niza nije odbaen ili kada se jedan klju
koristi dvaput.

40

RC4 je jednostavan za opis. Ima 256 S-box-ova. Ulazi su permutacija brojeva od 0

do 255, a permutacija je funkcija kljua promenljive duine. Ima dva brojaa, i i j,
postavljena na 0. Za generisanje sluajnog bajta koristi se sledei algoritam:
i = (i + 1) mod 256
j = (j + Si) mod 256
zamijeni Si i Sj
t = (Si + Sj) mod 256
K = 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 bra nego kod DES-a).
Inicijalizacija S-box-ova je takoe lagana.
Prvo se popunjavaju linearno: S0 = 0, S1 = 1,..., S255 = 255.
Zatim se generie drugi 256-bajtni niz kljua, ponavljajui klju koliko je potrebno da
se popuni cijeli niz: K0, K1,..., K255. Indeks j se postavlja na 0. Tada se izvrava
sljedea petlja:
for i = 0:255
j = (j + Si + Ki) mod 256
zameni 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
sluajno.
3.1.4 Komparativna analiza blok i sekvencijalnih ifarskih sistema
Iako su blok i sekvencijalni ifarski sistemi veoma razliiti, blok sistemi se mogu
implementirati kao sekvencijalni sistemi i obrnuto. Razlike se najvie iskazuju u
implementaciji ovih sistema. Naime, sekvencijalni ifarski sistemi koji ifruju i
deifruju svaku jedinicu OT nisu previe pogodni za softverske implementacije. Oni
su pogodni za ifrovanje i deifrovanje podataka u realnom vremenu, i to posebno
ako su realizovani u hardveru.
Sa druge strane, blok ifarski sistemi su laki za implementaciju u softveru zato to
esto izbegavaju vremenski zahtevne bitske manipulacije i zato to rade nad
podacima u raunarski podeljenim blokovima. Postoje neki specifini momenti gde
ifrovanje jedinica OT moe biti od interesa i u raunarskim sistemima, kao na primer
ifrovanje veze izmeu tastature i procesora, ali i u tom sluaju blok koji se ifruje
treba da bude najmanje irine magistrale podataka.
U savremenom razvoju kriptologije svedoci smo sve intenzivnijeg korienja 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.

41

U savremenim softverskim i hardverskim proizvodima za zatitu finansijskih,

poslovnih i dravnih raunarskih mrea uglavnom se podrava itav skup najvie
korienih blok i sekvencijalnih algoritama (de facto standardnih algoritama).

3.2 Asimetrini kriptografski algoritmi

Asimetrini kriptografski algoritmi predstavljaju jedno od najveih dostignua
kriptologije druge polovine dvadesetog veka. Otkriveni su u procesu reavanja
problema vezanih za zatitu tajnosti i distribuciju kljueva koji je esto bio aktuelan u
primenama simetrinih kriptografskh algoritama.
Naime, u asimetrinim ifarskim sistemima se koriste razliiti kljuevi za ifrovanje i
deifrovanje, tzv. javni i tajni klju, tako da klju za ifrovanje moe imati svako a
samo posednik kljua za deifrovanje moe deifrovati poruku.
Meutim, visoka raunarska zahtevnost ovih algoritama utie na performanse
sistema u kojima se primenjuju, tako da se ne preporuuje primena za zatitu tajnosti
informacija u sistemima sa velikim protokom informacija.
Ovo naravno ne dezavuie automatski ove algoritme jer nain na koji je uz korienje
ovakvih algoritama mogue ostvariti funkcije integriteta, autentinosti i neporicanja
ima nesumnjivu prednost nad tradicionalnim tehnikama.
U literaturi je opisano vie algoritama sa javnim kljuem ali sa stanovita kvaliteta,
otpornosti na razne vrste napada, efikasnost i lakou implementacije te
rasprostranjenost, nisu svi podjednako dobri. U tom smislu se kao prirodni izbor
namee RSA algoritam koji vie od dvadeset godina odoleva svim teorijskim i
tehnolokim napadima.
Opis i nain upotrebe ovog algoritma propisani su u standardu PKCS#1. Pored RSA
algoritma mogue 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 korienjem RSA
asimetrinog algoritma i najee se koristi za konstrukciju digitalnog koverta i
digitalnog potpisa.
U sluaju digitalnog koverta, sadraj poruke se prvo ifruje odreenim simetrinim
algoritmom (kao to su DES, 3-DES, RC2, RC4, IDEA, AES, ili neki namenski
privatni algoritmi). Zatim se tajni klju primenjenog simetrinog algoritma koji je
upotrebljen za ifrovanje date poruke ifruje RSA algoritmom upotrebom javnog
kljua korisnika kome je data poruka namenjena (RSA public key operacija).
Tako ifrovan sadraj poruke i tajni klju kojim je ta poruka ifrovana zajedno
predstavljaju digitalni koverat.

42

Postupak ifrovanja i deifrovanja 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 deifrovanje

U sluaju digitalnog potpisa, Slika 3.18, sadraj koji treba da se potpie, 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 koristei privatni klju potpisnika poruke (RSA private key operacija), klju

43

A. ifrovani otisak poruke predstavlja digitalni potpis date poruke, S, i postaje njen
pridrueni deo.
Kada ovakva poruka stigne do primaoca kojem je namenjena izvrava se postupak
verifikacije digitalnog potpisa. Ovaj postupak se sastoji od deifrovanja otiska
dobijene poruke primenom RSA algoritma uz upotrebu javnog kljua poiljaoca
poruke, klju B. Po deifrovanju digitalnog potpisa primalac poruke izvri isti
message digest postupak nad dobijenom porukom, M1.
Ako je dobijeni otisak poruke, H1, identian sa deifrovanom vrednou otiska,
verifikacija je uspela, u protivnom verifikacija je negativna.
Ukoliko je verifikacija uspela, primalac poruke je siguran u sledee:

Autentinost poiljaoca jer je uspeno deifrovao otisak poruke primenom

RSA algoritma sa javnim kljuem datog poiljaoca,
Integritet poslate poruke ako su izraunati i deifrovani otisci date poruke
identini zakljuuje se da poruka na prenosnom putu nije menjana, i
Nemogunost da poiljalac naknadno porekne da je tu poruku poslao jer je
njegov digitalni potpis uspeno verifikovan i ukoliko je potpisnik koristio
privatni klju generisan na smart kartici.

Slika 3.18: Procedura digitalnog potpisa i verifikacije

Da bi dati primalac bio u mogunosti da prima poruke od datog poiljaoca i sprovede
proces verifikacije digitalnog potpisa mora imati mogunost pristupa javnom kljuu
poiljaoca. Pristup i distribucija javnih kljueva se mogu organizovati na razliite
naine a najee se realizuju u procesu utvrivanja identiteta putem razmene
digitalnih certifikata.

44

PKCS#1 standardom se pored bezbednosnih mehanizama definie i unutranja

struktura validnih poruka ime se omoguava dodatni mehanizam verifikacije
ispravnosti poruka. Naime, svaka poruka koja ima naruenu strukturu se smatra
neispravnom i odbacuje se.
Treba posebno naglasiti da je trenutno aktuelan i vaei PKCS#1 standard verzije
2.1 i da su njime znaajno izmenjene preporuke date u PKCS#1 standardu verzije
1.5, koje se odnose na format bloka podataka koji podlee operacijama ifrovanja i
potpisivanja. Razlog za ovakve drastine promene lei u injenici da prema verziji 1.5
pri formiranju bloka za ifrovanje postoji niz bita na poetku bloka koji je uvek isti.
To se moe iskoristiti da se bez poznavanja tajnih informacija, samo uz poznavanje
ifrata doe do otvorenog teksta. Ovde treba naglasiti da ovim nije kompromitovana
bezbednost samog RSA algoritma ve je, grubo govorei, nain njegove upotrebe
bio takav da je pod odreenim 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 identina 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 zatite u specijalizovanim raunarskim
mreama 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 deifrovanja poruka prikazana je u sledeim
teoremama.
Teorema 1: Linearna kongruencija
ax b mod m

(3.2.2.1)

ima reenje ako i samo ako je NZD(a,m)b (NZD-najvei zajedniki delilac), i u tom
sluaju, ako je x 0 jedno reenje kongruencije, onda je opte reenje
m

x x0 mod
d

(3.2.2.2)

gde je d NZD a , m .
Posledica 1a: Ako su brojevi a i m relativno prosti, tj. NZD a, m 1 , onda linearna
kongruencija ax b mod m ima tano jedno nekongruentno reenje po modulu m.

45

Teorema 2: (Kineska teorema o ostacima) Ako su n1 , n 2 , , nk po parovima relativno

prosti celi brojevi, tada sistem kongruencija:

x a1 mod n1
x a 2 mod n2
...

x ak mod nk

(3.2.2.3)

ima jedinstveno reenje po modulu n n1 n2 nk .

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

(3.2.2.4)

gde je sa n oznaen broj prirodnih brojeva, ne veih od n, uzajamno prostih sa

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

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

(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 1 e p 1 q 1 i neka su brojevi e i proizvod
p 1 q 1 relativno proste veliine. Tada postoji prirodan broj d takav da je:
d e 1 mod p 1 q 1

(3.2.2.7)

i za svaki prirodan broj a, 0 a n vai:

a ed a mod n

(3.2.2.8)

Dokaz:
Kako su brojevi e i proizvod brojeva p 1 q 1 relativno proste veliine tada se
moe, na osnovu teoreme 2, zakljuiti da postoji prirodan broj d takav da je
ispunjeno:
e d 1 mod

p 1 q 1

(3.2.2.9)

46

Dati proizvod se moe predstaviti na sledei nain:

e d 1 A p 1 q 1

(3.2.2.10)

gde je A prirodan broj.

Moe se dokazati da za proizvoljan broj a vai

a ed a mod n .

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

(3.2.2.4):
a ed a 1 A p 1 q 1 mod n

a ( a p 1 q 1 ) A mod n

mod n
mod n

a 1A
a

(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):
a ed a mod( p) 0 mod( p)

(3.2.2.12)

a ed a 1 A p 1 q 1 mod(q )
a ed a ( a q 1 ) A p 1 mod(q )
a ed a 1 A p 1) mod(q )

(3.2.2.13)

a ed a mod(q )

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

kongruencija:
a ed X mod p
(3.2.2.14)
a ed X mod q

ima jedinstveno reenje X koje je manje od n=pq. Prema prethodnom a je jedno

takvo reenje pa prema tome i jedino. Na isti nain se postupa u sluaju da je
NZD(a,n)=q. Prema prethodno navedenom, pokazuje se da je u bilo kom sluaju
zadovoljeno a ed a mod(n) .
Algoritam za transformaciju poruka baziran na navedenoj teoremi odvija se na
sledei nain.
Neka je M poruka koju je potrebno transformisati.

Prvi korak u realizaciji algoritma je odabir prostih pozitivnih brojeva p, q i

odreivanje vrednosti njihovog proizvoda n=pq.
U sledeem koraku bira se prirodan broj e, 1 e p 1 q 1 takav da je
NZD e, p 1 q 1 1 .

47

Nakon odabira vrednosti za e se izraunava broj d takav da je

d e 1 mod p 1 q 1 .

Proces transformacije poruka odvija se na sledei nain. Ako se sa M oznai

numeriki ekvivalent poruke M i napie u obliku M=M1M2 Mk gde je 0 Mi < n, i=1,
2, , k; tada se za svako Mi, i=1, 2, , k izrauna:
e

Ci M i mod(n)

(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 rekonstruie poruku
tako to znajui vrednosti d, p i q izraunava:
d

Ci M i mod(n)

(3.2.2.16)

i ulanavanjem formira originalnu poruku M=M1M2 Mk. Korektnost navedenog

naina transformacije i rekonstrukcije poruka direktna je posledica teoreme 4.
Ureeni par (e,n) je javni klju a ureena trojka (d,p,q) je tajni klju RSA algoritma.
Po bezbednosnoj klasifikaciji prethodni algoritam spada u klasu raunski bezbednih
sistema. Sigurnost ovog algoritma bazira se na nepoznavanju efikasnog algoritma za
faktorizaciju prirodnih brojeva i direktno zavisi od veliine broja n (koja se moe
izraavati brojem cifara u dekadnom ili binarnom zapisu).
Pored asimetrinog kriptografskog algoritma, u asimetrinim sistemima je od
izuzetne vanosti izbor odgovarajueg algoritma za generisanje asimetrinog para
kljueva. U sluaju da je asimetrini algoritam RSA algoritam, generisanje kljueva
se odnosi na generisanje velikih sluajnih prostih brojeva. U tom smislu, takoe su
veoma znaajni algoritmi za proveru da li su izgenerisani kljuevi prosti brojevi.
Testovi da li je odgovarajui 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
sloen ili se ponaa kao prost. U prvom sluaju broj je sigurno sloen, i kao takav ne
moe biti prost, a u drugom sluaju postoji verovatnoa da se ponaa 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 moe dokazati da je broj prost.
Generalno ove metode su raunarski veoma zahtevne. U ovu grupu testova spadaju
Poklingtonov test, test Jakobijevih suma i test zasnovan na eliptikim krivim.
U ovom generikom modelu predlae se Miler-Rabinov test koji se odvija prema
sledeoj proceduri ( n je broj koji se proverava da li je prost):

48

1.
2.
3.
4.
5.

Stavimo n 1 2 k m gde je t neparan broj

Izaberimo sluajno broj a, 0 a n 1.
b a m mod n
Ako je b 1 mod n tada je

Od i 0 do k 1 radi

n prost i kraj.

Ako je b 1 mod n tada je

inae b b 2 mod n
6. n je sloen i kraj

n prost i kraj,

Moe se pokazati da je verovatnoa greke ovog algoritma, verovatnoa da se broj

proglasi prostim kada on to nije, jednaka

1
. Nezavisnim izborom razliitih vrednosti
4

za a i sukcesivnim ponavljanjem testa greka se moe uiniti proizvoljno malom.

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

3.3 Message digest algoritmi

Takozvane jednokorane hash ili message digest funkcije H(M) izvravaju se nad
porukom M proizvoljne duine, proizvodei hash vrednost h=H(M) fiksne duine m.
Hash funkcije treba da zadovolje sledee karakteristike:

Za datu poruku M, treba da je relativno jednostavno izgenerisati h,

Za dato h, treba da je izuzetno teko izraunati M tako da je H(M)=h,
Za dato M, treba da je izuzetno teko nai drugu poruku M takvu da je
ispunjeno H(M)=H(M).

Algoritam MD5 zadovoljava gore navedene karakteristike i predstavlja jedan od

najee korienih hash algoritama. Pored toga ovaj algoritam je specificiran za
korienje u okviru standarda PKCS#1. Algoritam MD5 produkuje 128-bitnu hash
vrednost. Pored ovog algoritma, kao to je vee reeno, mogua je opcija korienja
SHA-1 hash algoritma koji produkuje 160-bitnu hash vrednost. U nastavku je kao
primer dat kratak opis MD5 algoritma.
Meutim, u poslednjih par godina se dolo do saznanja da poemnuti hash algoritmi,
posebno MD5, imaju prilino velike slabosti i da se vie ne preporuuju za korienje.
Umesto tog algoritma, predlae se korienje novih SHA algoritama: SHA-224, SHA256, SHA-384 i SHA-512.
3.3.1 MD5 message digest algoritam
Nakon odreenog inicijalnog procesiranja, MD5 algoritam procesira ulaznu poruku u
blokovima od 512 bita, podeljenim u 16 podblokova duine 32 bita. Naime, prvo se
poruka proiruje na taj nain da se dobije poruka koja je po duini tano 64 bita kraa
od odgovarajueg multipla od 512 bita.

49

Proirivanje je vrlo jednostavno, prvo se na kraj poruke doda jedan bit jedinice,
praen zahtevanim brojem nula. Zatim se 64-bitna reprezentacija duine poruke
prikljui rezultatu. Ova dva koraka slue u cilju formiranja poruke ija je duina tano
multipl od 512 bita, to se zahteva u algoritmu, obezbeujui pri tome da razliite
poruke nee izgledati isto nakon pomenutog proirivanja. Izlaz algoritma predstavlja
skup od 4 32-bitna bloka, spojena tako da jednoznano formiraju 128-bitnu hash
vrednost.
Algoritam se sastoji od sledeih koraka:

Prvo se poruka obradi tako da je njena duina tano multipl od 512 bita,
Zatim se inicijalizuju 4 32-bitne promenljive (tzv. promenljive ulanavanja):
A=0x01234567
B=0x89abcdef
C=0xfedcba98
D=0x76543210

Zatim poinje glavna petlja algoritma koja se izvrava za sve blokove duine
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 sline. Svaka faza
koristi razliitu operaciju 16 puta, koja se sastoji od primene odreene
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 Z
I(X,Y,Z) = Y (X v ( Z ))
gde navedeni funkcijski znaci predstavljaju ( - XOR funkcija, ^ - AND funkcija, v OR funkcija, i - NOT funkcija).

50

B
C
D

B
C
D

+
1

+
+

Slika 3.19: Glavna petlja MD5 algoritma

Mj

ti

<<< S

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
sledei nain:
FF(a,b,c,d,Mj,s,ti) oznaava: a = b + ((a + F(b,c,d) + Mj + ti) <<< s)
GG(a,b,c,d,Mj,s,ti) oznaava: a = b + ((a + G(b,c,d) + Mj + ti) <<< s)
HH(a,b,c,d,Mj,s,ti) oznaava: a = b + ((a + H(b,c,d) + Mj + ti) <<< s)
II(a,b,c,d,Mj,s,ti) oznaava: 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.

51

3.4 Primena kriptografskih algoritama u informacionim sistemima

U prethodnom tekstu bilo je rei o kriptografskim tehnikama koje se mogu koristiti pri
dizajniranju i realizaciji sistema za zatitu informacija. Kriptografske tehnike koje se
koriste smo svrstali u dve grupe, simetrine i asimetrine kriptografske sisteme. Sa
stanovita bezbednosnih usluga jasno je da se uz manje ili vee probleme pri
realizaciji u svakom od ovih sistema moe realizovati veina osnovnih bezbednosnih
servisa.
U obe vrste sistema neosporno se moe postii poverljivost podataka. injenica je
da simetrini sistemi na bazi sluajnog i pseudosluajnog niza pruaju vii nivo
bezbednosti od asimetrinih sistema pri istim duinama kljueva. Takoe, asimetrini
sistemi su znatno sporiji od simetrinih sistema i neophodni su im kljuevi znatno
vee duine. Sa druge strane kod simetrinih sistema u sluaju intenzivnog
saobraaja javlja se problem distribucije kljueva.
to se tie utvrivanja autentinosti i identiteta subjekta u komunikaciji to se izuzetno
kvalitetno realizuje u asimetrinim sistemima korienjem tehnike digitalnog potpisa
uz upotrebu digitalnih certifikata. U simetrinim sistemima takoe se mogu realizovati
sistemi za autentikaciju, najpoznatiji je Kerberos, ali sa stanovita logike samog
procesa autentifikacije tu postoji jedna nepremostiva tekoa. Naime u takvim
sistemima uvek postoji trea strana od poverenja koja aktivno uestvuje u procesu
autentikacije, te kao takva predstavlja potencijalni izvor opasnosti.
to se tie zatite integriteta podataka u oba sistema se pomenuti servis relativno
lako realizuje a kao kriterijum se uzima uspeno deifrovanje (struktura i sadraj
poruke).
Kod realizacije servisa neporicanja kod simetrinih sistema se javlja problem
postojanja aktivne tree strane od poverenja koja u spornim situacijama vri
arbitrau. Prednost asimetrinih sistema u ovom sluaju je u tome to je subjekt sam
u stanju da prui dokaze uea drugog entiteta u transakciji ukoliko su ostali
bezbednosni mehanizmi sistema adekvatni (pasivna trea strana od poverenja).
Iz prethodnog izlaganja prirodno proistiu zakljuci o koncepciji sistema zatite u
savremenim informacionim sistemima i raunarskim mreama. Najjednostavnije i
najloginije 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 zatite je
formiranje hibridnog sistema koji koristi dobre osobine i jednih i drugih sistema, pa
tako za utvrivanje autentinosti, zatite integriteta i obezbeenje neporicanja treba
koristiti asimetrine sisteme a za zatitu tajnosti podataka simetrine kriptografske
algoritme.
Od algoritama sa javnim kljuem 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 uinila ga je vaeim de
facto standardom u toj klasi.

52

4. VIESLOJNA ARHITEKTURA SISTEMA ZATITE

SAVREMENIH RAUNARSKIH MREA
U cilju optimalne odbrane informacionih sistema i savremenih raunarskih mrea od
potencijalnih opasnosti i raznovrsnih napada kojima se ugroavaju razliiti servisi i
resursi, predlae se arhitektura sistema zatite koja se sastoji od mehanizama zatite
primenjenih na tri nezavisna bezbednosna nivoa koji su namenjeni za odbranu od
razliitih tipova napada.
Ovi nivoi su projektovani da minimizuju i ogranie moguu tetu tako to eventualno
ugroavanje jednog nivoa ne moe kompromitovati ostale bezbednosne nivoe
arhitekture sistema zatite.
U tom smislu, mehanizmi zatite informacionog sistema mogu da se sastoje od
primenjenih mehanizama na sledea tri nivoa:

Zatita s kraja na kraj (end-to-end security) na aplikativnom nivou koja se

zasniva na primeni tehnologije digitalnog potpisa na bazi asimetrinih
kriptografskih algoritama i zatite tajnosti podataka primenom simetrinih
kriptografskih algoritama. Primenom ovog nivoa zatite globalno se
obezbeuje:
o provera autentinosti korisnika servisa kako u smislu komunikacije
(end-user authentication) tako i (opciono) u smislu kontrole pristupa
mrei (access control),
o zatita integriteta podataka koji se prenose,
o zatita od mogunosti naknadnog poricanja odgovornosti za poslate
podatke i
o zatita tajnosti podataka.

Ovaj nivo zatite generalno slui za odbranu od internih napada.

Zatita na transportnom nivou predstavlja zatitu tajnosti podataka primenom
simetrinih kriptografskih algoritama i autentikacije vorova komunikacionog
segmenta mree na transportnom nivou. Ovaj nivo titi mreu od eksternih
napada primenom kriptografskih tunela (zatienih sesija) izmeu vorita
komunikacionog segmenta mree na transportnom nivou na bazi simetrinih
kriptografskih sistema i primenom procedure jake autentikacije izmeu
vorita mree ime se obezbeuje provera autentinosti strana u
komunikaciji.
Zatita na mrenom IP nivou obezbeuje kriptografsku i logiku zatitu na
nivou IP paketa koji se razmenjuju izmeu mrenih vorova i titi itavu mreu
od eksternih napada korienjem zatitnih mehanizama koje prua
standardna komunikaciona oprema. Ova zatita se bazira na ostvarivanju
kriptografskih tunela na IP nivou na bazi IPSec protokola zatite putem koga
se ostvaruju Virtuelne Privatne Mree (VPN Virtual Private Network).
Sutina predloga primene vieslojne arhitekture zatite je u preporuci korienja
kombinovanih mehanizama zatite na vie razliitih nivoa ISO/OSI modela. Dakle,

53

ukoliko nije mogue koristiti mehanizme na svim nivoima, kao minimalna arhitektura,
predlae se primena kombinacije mehanizama na dva nivoa, i to:

Zatita na aplikativnom nivou (kao obavezna) i

Dodatna zatita na transportnom ili mrenom nivou.

Na taj nain, sistem se brani kako od internih (aplikativna zatita) tako i od eksternih
napada (transportna ili mrena zatita).

4.1 Zatita na aplikativnom nivou

U cilju realizacije mehanizama zatite na aplikativnom nivou u okviru informacionog
sistema Organizacije, predlae se primena digitalnog potpisa i digitalne envelope, na
bazi smart kartica za korisnike.
Za realizaciju zatite na aplikativnom nivou, neophodno je primeniti odgovarajuu
kriptografsku biblioteku kako na klijentu, u okviru odgovarajue klijentske aplikacije
(standalone) ili Internet browser programa, tako i za primenu na odgovarajuem 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 ugraenom kriptografskom
bibliotekom (ili odgovarajuom ActiveX kontrolom) ili web pretraivaki program iz
koga se poziva odgovarajua ActiveX kontrola (ili JAVA aplet u non-Windows
baziranim aplikativnim sistemima), treba da ima sledee kriptografske karakteristike:

Primena mehanizmima zatite na aplikativnom nivou kojima se obezbeuju

sledee funkcije:
o Autentinost potpisnika (asimetrini kriptografski algoritam i tehnologija
digitalnog potpisa),
o Zatita integriteta fajlova (asimetrini kriptografski algoritam i
tehnologija digitalnog potpisa),
o Obezbeenje neporecivosti (asimetini kriptografski algoritam i
generisanje kljueva na samim smart karticama i tehnologija digitalnog
potpisa),
o Zatita tajnosti podataka (simetrini kriptografski algoritam i tehnologija
digitalne envelope).

Koriste se tehnologije digitalnog potpisa i digitalne envelope.

Univerzalnost u odnosu na smart kartice i itae smart kartice. Ugraena
ActiveX kontrola na klijentu, kao i kriptografske biblioteke ugraene na
serveru, koristi odgovarajui middleware (koji se sastoji od: CSP
(Cryptographic Service Provider), PKCS#11 bibilioteke i token menadera za
administraciju smart kartice) za pristup smart karticama. Na ovaj nain,
klijentska i serverska aplikacija su nezavisne od konkretne smart kartice koja
e biti koriena a i prelaz na drugi tip kartice je u potpunosti direktan.

54

Klijentska aplikacija (bilo standalone bilo da se koristi web pretraivaki

program) sa ugraenom kripto kontrolom mora da obezbedi funkciju provere
autentinosti korisnika na bazi njegove smart kartice i odgovarajueg PIN-a
pre nego to se omogui korienje same aplikacije, tj. aplikacija ne moe da
se startuje bez korienja odgovarajue smart kartice ovlaenog korisnika.
Pri tome, provera nije samo da li se odreena kartica nalazi u itau kartica
ve se mora proveriti i sertifikat korisnika (proverom validnosti, da li je izdat od
CA kome se veruje i provera statusa povuenosti).
Bazira se na kriptografskim operacijama koje se izvravaju na samoj smart
kartici: digitalni potpis (tj. RSA private key encryption) i deifrovanje
simetrinog kljua kod digitalne envelope (digital envelope retrieval). Ostale
kriptografske operacije (ifrovanje/ deifrovanje simetrinim algoritmima,
kreiranje hash vrednosti podataka koji se digitalno potpisuju, verifikacija
digitalnog potpisa) se izvravaju u klijentskom i serverskom softveru
(softverski deo kripto komponenti na klijentu i serveru).
Bazira se na PKCS de facto standardima za zatitu, i to:
o PKCS#1 za digitalni potpis i digitalnu envelopu,
o PKCS#7 za format zatienih 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 zatienih
fajlova.
Aplikacija pri realizaciji bezbednosnih mehanizama treba da koristi standardne
naine pristupa smart karticama: CSP (Cryptographic Service Provider) i
PKCS#11 biblioteka, i stoga je nezavisna od konkretne smart kartice koja e
biti koriena tako da je prelaz na drugi tip kartice u potpunosti direktan.
Klijentska standalone aplikacija, ili odgovarajue stranice web aplikacije, treba
da omogue:
o Izbor sertifikata potpisnika (koji stoje u Personal Store-u) ukoliko na
datoj radnoj stanici postoji vei broj korisnikih 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 moe 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 uspene ili neuspene verifikacije
digitalnog potpisa i/ili uspenog ili neuspenog deifrovanja datih
podataka.

Klijentska i serverska kripto komponenta treba da u ovom trenutku podri

sledee kriptografske algoritme i pridruene duine kljueva:

55

o Asimetrini algoritmi RSA algoritam (koji se izvrava na smart kartici)

sa duinom asimetrinog kljua od 2048 bita.
o Hash algoritmi SHA-1, SHA-224, SHA-256, SHA-384 ili SHA-512.
o Simetrini algoritmi 3DES algoritam sa duinom kljua od 168 bita ili
AES algoritam sa duinama kljua 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 utvreno da su kriptografski slabi
za korienje. Takoe, aplikacija treba da obezbedi promenu duina
odgovarajuih kriptografskih kljueva ukoliko se ukae potreba za tim.
Aplikacija treba da bude otvorena za eventualnu ugradnju privatnih simetrinih
algoritama kreiranih i verifikovanih od strane nadlene institucije za poslove
kriptozatite u zemlji, ukoliko postoje zahtevi za to.
U okviru aplikacije (klijentske i serverske) treba obezbediti funkciju verifikacije
digitalnog potpisa odgovarajuih podataka (koji se razmenjuju izmeu
korisnika i sistema ili podataka/dokumenata koji su arhivirani i pregledaju se u
okviru sistema) koji se sastoji od sledea dva koraka (tim redom):
o Provera digitalnog potpisa podataka na osnovu javnog kljua iz
digitalnog sertifikata potpisnika (koji je doao uz digitalno potpisane
podatke u samoj formatiranoj poruci),
o Provera samog digitalnog sertifikata. Ova provera se izvrava na
sledei nain:

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 povuen, tj. da li se nalazi na
vaeoj CRL listi koje izdaje dato CA.

U okviru mehanizama zatite na aplikativnom nivou mogla bi se integrisati i

odgovarajua 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 zatite na transportnom nivou to je
opisano u nastavku a to se i predlae za primenu u okviru informacionog sistema
Organizacije.

4.2 Zatita na transportnom nivou

U vezi realizacije transportnih mehanizama zatite, predlae se primena standardnog
SSL (Secure Sockets Layer) protokola (novija verzija je TLS (Transport Layer
Security) protokol) izmeu korisnika i web servera (ili web servisa).
U stvari, u informacionom sistemu Organizacije predlae se primena:

56

SSL protokola sa serverskom autentikacijom neophodan je SSL serverski

sertifikat izdat za dati web server i
SSL protokola sa klijentskom i serverskom autentikacijom na bazi digitalnih
sertifikata i smart kartica korisnika. U ovom sluaju je takoe neophodno da
web server (ili odgovarajui web servis) ima SSL serverski sertifikat.

Naime, za potrebe autentikacije korisnika informacionog sistema Organizacije,

predlae se primena zatite na transportnom nivou i jake autentikacije korisnika na
bazi SSL protokola sa klijentskom i serverskom autentikacijom.
Dakle, u ovom sluaju nije samo dovoljno da web server poseduje sertifikat
(serverska autentikacija) ve je neophodno da u sistemu postoji/koristi se i
odgovarajue Sertifikaciono telo (CA) koje izdaje sertifikate klijentima na smart
karticama. Na ovaj nain se postie da samo klijenti sa smart karticama i
odgovarajuim digitalnim sertifikatima mogu da pristupe datom web serveru, a samim
tim da izvravaju poslovne procese u okviru informacionog sistema Organizacije.

4.3 Zatita na mrenom nivou

Umesto SSL protokola na transportnom nivou, ili dodatno njemu, mogu se koristiti i
kriptografski mehanizmi zatite na mrenom nivou koji se najee baziraju na IPSec
protokolu zatite i uspostavi virtuelnih privatnih mrea (VPN Virtual Private
Network).
U zavisnosti od naina komunikacije kao i protokolima koji se koriste za
komunikaciju, kriptografske VPN mree se najee baziraju na istom IPSec
protokolu zatite ili na kombinacijama PPTP/IPSec ili L2TP/IPSec.
U okviru informacionog sistema Organizacije generalno se predlae primena IPSec
protokola na bazi digitalnih sertifikata vorova u raunarskoj mrei (ili izmeu klijenta
i VPN servera).
U tom smislu, VPN mrea, koja se bazira na IPSec protokolu, moe se uspostaviti
izmeu dva rutera ili rutera i firewall-a, ili izmeu VPN klijenta i VPN koncentratora
(ruter ili firewall ureaj) opet na bazi digitalnih sertifikata.
Sa druge strane, neophodno je primeniti firewall ureaje u cilju podizanja sveukupne
zatite i kontrole pristupa sistemu. Jedan primer mogue primene firewall ureaja dat
je na slici 4.1.
Na slici 4.1 je dat mogui primer jedne viestruke firewall konfiguracije u kojoj se
jedan nivo firewall ureaja (npr. prevashodno paketski filtri) koristi za prvu odbranu i
razdvajanje eksterne mree, DMZ zone i interne mree, dok se drugi nivo firewall
ureaja (npr. prevashodno aplikativni firewall ureaji) koriste za zatitu najosetljivijih
delova informacionog sistema baza podataka.
Web vieslojne aplikativne konfiguracije u Organizaciji bi se, prema Slici 4.1,
sastojale od web servera u DMZ zoni, aplikativnog servera u internoj mrei i baze
podataka u najbezbednijem delu interne mree (back end server network). Firewall

57

konfiguracija prikazana na Slici 4.1 se moe realizovati sa fie firewall ureaja sa 2 ili
3 interfejsa, ili jednim parom firewall ureaja sa vie interfejsa (5 i vie).
Takoe, potrebno je razmotriti i primenu drugih nekriptografskih mehanizama
zatite u Organizaciji, i to: antivirusne zatite, patch management, web content
filtriranja, Intrusion Prevention Sistema (IPS), end-point security mehanizama, itd.
Meutim, pomenuti mehanizmi nisu predmet ove studije. Predmet ove Studije zatite
su pre svega kriptografski mehanizmi zatite.

WAN
mrea

VPN zone
DMZ
Cisco PIX515, FO

Layer 2 sw itch

Layer 3 sw itch

Outside

LAN Segment: Veza

PIX - Layer 3
switchevi

Layer 3 sw itch

Internal
network

Back End
Server
Network

Slika 4.1: Jedan primer mogue primene viestruke firewall konfiguracije

58

5. OSNOVE PKI SISTEMA

5.1 Uvod u sisteme sa javnim kljuevima (PKI public key
infrastructure)
Infrastruktura sistema sa javnim kljuevima (PKI Public Key Infrastructure)
omoguuje ambijent za pouzdanu primenu elekronskog poslovanja i ona se najee
bazira na kombinovanoj primeni asimetrinih i simetrinih ifarskih sistema.
PKI infrastruktura se sastoji od vie komponenata, aplikacija i dokumenata koji
definiu nain realizacije etiri osnovne kriptografske funkcije u elektronskom
poslovanju:

Zatita tajnosti realizuje se primenom simetrinih kriptografskih sistema,

Autentinost realizuje se primenom asimetrinih ifarskih sistema,
Integritet podataka realizuje se primenom asimetrinih ifarski sistema,
Neporecivost transakcija realizuje se primenom asimetrinih ifarskih
sistema.

Dok se funkcije zatite tajnosti i integriteta podataka mogu realizovati i primenom

tradicionalnih simetrinih tehnika, funkcije autentinosti i neporecivosti transakcija
zahtevaju primenu asimetrinih kriptografskih sistema u okviru uspostavljenog PKI
sistema.
Najbolje karakteristike pokazuju sistemi u kojima su realizovane sve pomenute etiri
funkcije. PKI sistemi obezbeuju pouzdan metod za realizaciju funkcija provere
autentinosti i neporicanja transakcija koji je baziran na precizno utvrenoj politici
rada.
PKI sistemi su brzo postali kljuna karika svih sistema elektronske trgovine i
korporacijske bezbednosti i sigurno e dominirati u bezbednosnim sistemima
budunosti.
Osnovni funkcionalni zahtevi koje treba da ispuni odreeni PKI sistem navedeni su u
nastavku.
5.1.1 Podrka razliitim politikama rada PKI sistema
PKI sistem mora omoguiti podrku za primenu razliitih bezbednosnih politika
krajnjeg korisnika. Ova funkcionalnost omoguuje adaptaciju sistema na promene
zakonske, poslovne i drugih politika rada koje utiu na realizaciju PKI sistema.
S obzirom da PKI sistemi predstavljaju infrastrukturu u kojoj su, pored tehnikih
aspekata, veoma bitni i znaajni legalni i proceduralno-organizacioni aspekti,
mogunost adaptacije sistema na promene politike funkcionisanja predstavlja jedan
od kljunih zahteva.

59

5.1.2 Bezbednost sistema

S obzirom da Sertifikaciono telo (Certification Authority CA) predstavlja centralni
deo PKI sistema sa najvanijim ciljem da uspostavi jedinstvenu taku poverenja u
itavom sistemu, osnovni zahtev koji se postavlja je najvia bezbednost samog CA.
Naime, ako je CA kompromitovano (tj. ako je privatni klju asimetrinog
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
zatititi na najviem nivou.
5.1.3 Skalabilnost
Komercijalno dostupni PKI sistemi su skalabilno dizajnirani tako da se kreu od malih
konfiguracija koje rade na jednom PC raunaru 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 viestruka RA sa vie operatora,
organizovana kao podreeni inioci viestrukom hijerarhijskom sistemu CA, koji su
pod jurisdikcijom jednog Root CA sistema.
Kao druga veoma znaajna osobina, PKI sistem mora podrati eventualno
proirivanje sistema dodavanjem odreenih modula bez potrebe zaustavljanja rada
sistema. Drugim reima, ako se data organizacija proiruje, ili ako se zahtevi za PKI
tehnologijom poveavaju, to se mora reiti dodavanjem odgovarajuih specifinih PKI
modula.
5.1.4 Fleksibilnost
Odreeni PKI sistem treba da je dizajniran tako da bude fleksibilan u cilju lakog
reavanja razliitih PKI zahteva.
U ova obeleja su ukljueni:

Viestruki sistemi za registraciju i dostavu sertifikata i kljueva potrebno je

da dati PKI sistem podrava razliite mehanizme registracije i dostave PKI
parametara, ukljuujui: e-mail servis, web komunikaciju, linu dostavu, VPN i
drugo.
Podrka razliitim bezbednosnim modulima, malim hardverskim modulima
(tokenima) i smart karticama,
Podrka primeni razliitih kriptografskih algoritama, kako javnih, tako i
privatnih algoritama definisanih od strane dizajnera ili samih korisnika sistema,
Viestruki sistemi publikacije izdatih i povuenih sertifikata koji ukljuuju
razliite eksterne direktorijumske servise (LDAP i X.500), kao i publikaciju na
hard disk u cilju olakavanja procesa publikacije,

60

Podrka razliitim metodama provere validnosti (povuenosti) digitalnih

sertifikata, kao to su CRL (Certificate Revocation List), CRL distribucione
take i OCSP (Online Certificate Status Protocol),
Podrka kompleksnim PKI hijerarhijama PKI sistem mora podrati hijerarhiju
sertifikacionih tela (bilo koje dubine), viestruka registraciona tela (RA),
viestruke operatore RA, i mora podrati proceduru meu-sertifikacije (crosscertification) sa drugim CA,
Podrka viestrukim kljuevima i sertifikatima po korisniku politika rada PKI
sistema, i samog Sertifikacionog tela (CA), treba da predvidi korienje
viestrukih kljueva i sertifikata po korisniku, a da se korienje ovih kljueva
tako konfigurie da se odvojeni kljuevi koriste za digitalno potpisivanje i za
ifrovanje (u okviru digitalne envelope),
Sistem treba da podri fleksibilni autorizacioni proces svaki zahtev za
izdavanjem sertifikata moe biti autorizovan od strane jedne ili vie ovlaenih
osoba, to treba definisati u politici rada CA. Dodatno, sistem treba da
omogui da se zahtevi za izdavanje sertifikata procesiraju i automatski, bez
potrebe za primenom specifine procedure autorizacije.

5.1.5 Jednostavno korienje

U svakom PKI sistemu najvaniji subjekti su:

Administrator bezbednosti PKI sistema koji uspostavlja i monitorie rad

itavog PKI sistema,
Administrator CA,
Operatori RA koji sakupljaju registracione informacije i koji mogu da autorizuju
proces sertifikacije i povlaenja 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 korienje, i da korisnici jedini imaju
pristup funkcijama koje su im omoguene za korienje. Ovo minimizuje proces
obuke neophodne za svaki tip korisnika i redukuje mogue probleme koje oni mogu
imati u cilju korienja sistema.
5.1.6 Otvorenost sistema
U cilju eventualnih zahteva za interoperabilnou, PKI sistem mora zadovoljavati
osobinu da se bazira na otvorenim standardima, od kojih je najvaniji X.509 standard
za format digitalnog sertifikata.

5.2 Komponente PKI sistema

Kao to je ve reeno, infrastruktura sistema sa javnim kljuevima (PKI sistem)
predstavlja kombinaciju hardverskih i softverskih proizvoda, politika i procedura. PKI
sistemi omoguuju osnovno bezbednosno okruenje koje se zahteva u sistemima
elektronskog poslovanja (e-business) u kome korisnici, koji se ne poznaju ili su

61

distribuirani po svetu i nalaze se na velikim udaljenostima, mogu komunicirati

bezbedno kroz mreu poverenja.
PKI sistemi se baziraju na digitalnim identitetima (digital IDs) poznatim pod nazivom
digitalni sertifikati koji igraju ulogu svojevrsnih digitalnih pasoa ili digitalnih linih
karata, i koji povezuju ime vlasnika datog sertifikata sa njegovim javnim kljuem
asimetrinog kriptografskog sistema, kao to je na primer RSA algoritam, koji slui za
verifikaciju digitalnog potpisa.
Bezbednost PKI sistema se bazira na politici zatite informacionog sistema u kome
se primenjuje. Politika zatite uspostavlja i definie osnovne pravce i strategiju
razvoja bezbednosti informacionog sistema date organizacije, i propisuje procedure i
principe korienja kriptografskih mehanizama u sistemu. Tipino, bezbednosna
politika propisuje na koji se nain upravlja kljuevima i ostalim neophodnim
informacijama u sistemu, i propisuje neophodne nivoe kontrole koji odgovaraju
nivoima rizika.
PKI sistem se sastoji od sledeih osnovnih komponenata:

Osnovni dokumenti rada PKI sistema:

o Politika sertifikacije (CP Certificate Policy) utvruje osnovne
principe rada sertifikacionog tela i ostalih komponenata PKI sistema.
o Praktina pravila rada (CPS Certificate Practice Statement)
predstavlja dokument koji praktino opisuje rad Sertifikacionog tela.
CPS predstavlja jedan detaljan dokument koji sadri operativne
procedure za realizaciju principa koji su navedeni u politici sertifikacije i
predstavlja praktinu podrku sistemu. Tipino, CPS ukljuuje definicije
kako je CA formirano i nain rada, kako se generiu digitalni sertifikati,
kako se povlae, kako e kljuevi biti generisani, registrovani i
sertifikovani, gde e se uvati i kako e biti raspoloivi korisnicima.

Sertifikaciono telo (CA) je najvanija 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 Generie digitalne sertifikate tako to povezuje identifikacione podatke
odreenog korisnika u sistemu sa njegovim javnim kljuem
asimetrinog kriptografskog sistema, i sve to potvruje svojim digitalnim
potpisom svih podataka u sertifikatu,
o Upravlja rokom vanosti izdatih digitalnih sertifikata,
o Obezbeuje funkciju povlaenja izdatih digitalnih sertifikata u
sluajevima kada za to postoje uslovi, i u tom smislu, publikuje liste
povuenih sertifikata (CRL Certificate Revocation List).
U postupku formiranja PKI sistema, organizacija moe da realizuje sopstveno
CA, ili da koristi usluge CA servisa, realizovanog od neke tree strane od
poverenja.

62

Registraciono telo (RA) obezbeuje interfejs izmeu korisnika i CA. RA

prihvata zahteve i proverava autentinost korisnika i prosleuje standardni
zahtev za izdavanje digitalnog sertifikata. Kvalitet procedure provere identiteta
korisnika odreuje nivo poverenja koji se ugrauje u dati sertifikat.
Sistemi za distribuciju sertifikata Generisani digitalni sertifikati se mogu
distribuirati na razliite naine, u zavisnosti od strukture itavog PKI sistema,
kao na primer direktno korisnicima ili preko direktorijumskog servera.
Direktorijumski server moe ve postojati u datom informacionom sistemu
same organizacije, ili moe biti isporuen kao deo itavog PKI reenja. U
poslednje vreme, smart kartice predstavljaju naei nain distribucije
sertifikata korisnicima.
PKI aplikacije itav PKI sistem se kreira da podri rad veeg broja aplikacija
u kojima se koriste digitalni sertifikati i tehnoogija digitalnog potpisa, kao to
su:
o
o
o
o
o

Zatita WEB transakcija,

Zatita e-mail servisa,
VPN virtuelne privatne mree,
Bezbedno upravljanje elektronskom dokumentacijom,
Identity and Access Management sistemi, itd.

5.2.1 Moduli PKI sistema

U cilju zadovoljenja neophodnih zahteva koji se postavljaju pred sistem zatite,
praktine implementacije PKI sistema i samog CA u obliku softversko-hardverskih
sistema moraju biti modularno realizovane.
Svi moduli komuniciraju meusobno korienjem baze podataka, ili korienjem
zatienih TCP/IP konekcija. Shodno tome, osnovni moduli PKI sistema su:

Sertifikaciono telo (CA) digitalno potpisuje digitalne sertifikate i publikuje

sertifikate i liste povuenih sertifikata (CA je kompleksna komponenta i takoe
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 lino podnete
zahteve za izdavanjem sertifikata,
Arhivni server ovo je opcioni modul koji se koristi za eventualno uvanje
korisnikih parova kljueva za ifrovanje digitalnom envelopom, ukoliko je ta
opcija predviena politikom sertifikacije datog PKI sistema.

Tradicionalni PKI sistemi su bili bazirani na client-server tehnologijama dok su noviji

sistemi veinom web bazirani aplikativni sistemi vieslojne aplikativne infrastrukture.
U nastavku su detaljnije opisani navedeni moduli i to prvo sa stanovita tradicionalnih
client-server tehnologija a zatim i sa stanovita novih web batiranih reenja.

63

5.3 Sertifikaciono telo (CA Certification Authority)

Sertifikaciono telo ili Sertifikacioni autoritet (CA) predstavlja jezgro itavog PKI
sistema. itavo poverenje sadrano u PKI infrastrukturi zavisi od digitalnog potpisa
CA koji se formira na bazi asimetrinog kriptografskoh algoritma (npr. RSA) i
asimetrinog privatnog kljua CA.
CA funkcionie 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 asimetrinog kriptografskog sistema korisnika, smeta
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 trea strana od poverenja (Trusted Third
Party), proverila da dati javni klju pripada definisanom korisniku i da svojim
potpisom sertifikuje da je to istinito.
U najkraem, ideja se sastoji u tome da odreeno ovlaeno eksterno telo (CA)
preuzme line podatke odreenog korisnika i njegov javni klju, formatira sve te
podatke na standardni nain, u obliku digitalnog sertifikata, koga zatim digitalno
potpie.

HSM
Smart

Crypto
engine

(CA
engine)
- Directory
Manager
- Archive
Manager
- Scheduler

X.500
/LDA
P

64

Slika 5.1: U proeni grafiki prikaz funkcionalnosti CA

Digitalni sertifikat, na osnovu digitalnog potpisa CA, predstavlja pouzdanu vezu
identiteta odreenog korisnika i njegovog javnog kljua. Naime, ime vlasnika
sertifikata, javni klju i dodatne informacije kao to su: datum izdavanja i rok vanosti,
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
pretraivanje (browser) i kriptografski softverski sistemi mogu procesirati.
Koncept funkcionalnost CA je grafiki prikazan na slici 5.1.
5.3.1 Funkcionalnost CA

CA prihvata potvrene zahteve za generisanjem i povlaenjem sertifikata od

registracionih tela (RA) i CAO i isporuuje digitalne sertifikate i potvrdne
poruke.
Ako je tako predvieno utvrenom politikom rada (Politika sertifikacije), CA
takoe dostavlja krajnjim korisnicima asimetrini par kljueva za ifrovanje
(digitalna envelopa) koji se arhiviraju u bazi kljueva u arhivnom serveru.
Digitalno potpisivanje sertifikata CA je odgovorno za digitalno potpisivanje
infrastrukturnih sertifikata (sertifikati ovlaenih korisnika u okviru samog PKI
sistema) i sertifikata krajnjih korisnika. CA takoe digitalno potpisuje sertifikate
podreenih CA, kao i drugih CA u sluaju unakrsne sertifikacije (crosscertification).
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
autentinosti 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 odgovarajui jedinstveni procesni broj.
Publikacija sertifikata i drugih neophodnih parametara CA opciono publikuje
sertifikate i CRL na LDAP ili X.500 direktorijume. CA podrava i publikaciju
pomenutih parametara u okviru fajl strukture na hard disku, kao jedan od
mehanizama publikacije sertifikata koji se moe lako kastomizovati.
Opciono CA moe publikovati CRL i na OCSP (Online Certification Status)
serveru.
Generisanje asimetrinog para kljueva CA generie svoj sopstveni par
kljueva za asimetrini kriptografski algoritam.
Provera jedinstvenog imena Dname i javnih kljueva CA moe opciono da
proverava da li svi izdati digitalni sertifikati imaju jedinstveno Dname i javni
klju.

65

5.3.2 Obeleja CA

CA treba da podri razliite hardverske elemente, kao to su: smart kartice za

krajnje korisnike, hardverske bezbednosne module (HSM Hardware Security
Module) i druge sline tokene.
CA treba da podri mogunost korienja DAP i LDAP mehanizama.
CA obezbeuje viestruko generisanje parova asimetrinog kljua. Opciono,
CA moe imati individualni par kljueva za svaku od funkcija: digitalno
potpisivanje sertifikata, digitalno potpisivanje CRL, ifrovanje podataka,
ifrovanje kljua.
CA podrava promenljivo vreme publikovanja CRL.
CA opciono treba da podri OCSP servise.
CA treba da podri itavu paletu simetrinih i asimetrinih kljueva. to se tie
asimetrinih kriptografskih tehnika, CA bi trebalo da podrava sledee
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 kontrolie sve administratorske funkcije u sistemu i dodeljuje odgovarajue
privilegije ostalim uesnicima u PKI sistemu (administratorima, modulima i
eventualno podsistemima).
5.4.1 Funkcionalnost CAO

CAO prosleuje potvrene zahteve za izdavanjem sertifikata direktno CA.

Zahtevi za izdavanjem sertifikata se smetaju u CA bazu podataka.
Kreiranje politike rada CA CAO je odgovoran za kreiranje i odravanje
aktuelne politike izdavanja sertifikata. CAO takoe odrava politike i procedure
rada drugih CA i svih RA.
Auriranje novih verzija politike rada CA i celog PKI sistema CAO dinamiki
dostavlja nove verzije politike i procedura rada do individualnih operatora
registracionih tela (RAO) u cilju obezbeenja da se svi digitalni sertifikati uvek
izdaju u uslovima aurnih aktuelnih verzija politike datog PKI sistema.
Povlaenje sertifikata svaki sertifikat moe biti povuen od strane CAO.
Zahtevi za povlaenjem sertifikata se smetaju u CA bazu podataka.
Razvoj PKI sistema CAO moe dodati nove module ili aplikacije u PKI
sistem i dati im odgovarajue privilegije.

66

Generisanje kljueva CAO moe biti odgovoran za generisanje

odgovarajuih kljueva (simetrinih i asimetrinih) za korisnike, ukoliko CA vri
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 autentinosti potpisnika i
integriteta sadraja poruke.
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 Obeleja CAO

CAO treba da podri razliite hardverske elemente, kao to su: smart kartice
za krajnje korisnike, hardverske bezbednosne module (HSM Hardware
Security Module) i druge tokene.
Poseduje grafiki interfejs, jednostavan za korienje.
Procesira sertifikate i CRL.
Svaki CAO moe imati razliite nivoe privilegija.

5.5 Registraciono telo (RA)

Registraciono telo (RA) igra ulogu rutera izmeu operatora registracionog tela (RAO)
i CA. RA moe imati svoju sopstvenu politiku rada, koja se odrava lokalno ili od
strane CAO. RA moe 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 obraen sluaj korienja RA u obliku klijent-server aplikacije.
5.5.1 Funkcionalnost RA

RA prosleuje potvrene zahteve za izdavanjem ili povlaenjem sertifikata,

dobijene od RAO, do CA. RA dobija sertifikate i potvrdne poruke od strane CA
i dostavlja ih do RAO.
RA prosleuje zahteve za izdavanjem ili povlaenjem sertifikata, dobijene od
korisnika putem odreenog 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
autentinosti potpisnika i integriteta sadraja poruke.

67

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 Obeleja RA

RA treba da podri razliite hardverske elemente, kao to su: smart kartice za

krajnje korisnike, hardverske bezbednosne module (HSM Hardware Security
Module) i druge tokene.
Opcija automatskog potvrivanja u sluaju da je to politikom rada
predvieno, RA moe biti podeeno tako da automatski potvruje (digitalno
potpisuje) sve udaljene zahteve koji stiu bez potrebe za intervencijom RAO.

5.6 Operator registracionog tela (RAO)

Operator registracionog tela (RAO) ima prvenstvenu funkciju da potvruje (digitalno
potpisuje) zahteve za izdavanjem ili povlaenjem sertifikata koji e dalje biti
procesirani od strane CA.
Meutim, u sluaju da politika rada CA (politika sertifikacije) to predvia i dozvoljava,
RAO moe realizovati i funkciju generisanja kljueva za krajnjeg korisnika.
Tradicionalno, RAO se realizuje kao klijent-server aplikacija u kombinaciji sa RA, a
osnovna funkcionalnost i obeleja bie prikazana u nastavku.
5.6.1 Funkcionalnost RAO

RAO prima zahteve za izdavanjem sertifikata preko RA, ili ih kreira direktno u
linom kontaktu sa krajnjim korisnikom (face-to-face manner).
RAO je odgovoran za potvrivanje ili odbijanje zahteva za izdavanjem
sertifikata od krajnjeg korisnika koji su dobijeni u linom kontaktu ili
elektronskom komunikacijom (ova funkcija zavisi od utvrene politike rada PKI
sistema).
RAO alje potvrene zahteve za izdavanjem ili povlaenjem sertifikata do RA.
RAO moe generisati kljueve (asimetrini par kljueva) za krajnjeg korisnika
u softveru ili na kriptografskom hardveru (HSM), ukoliko je to politikom rada
predvieno.
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
autentinosti potpisnika i integriteta sadraja poruke.
ifrovanje podataka sve poruke koje se razmenjuju preko RAO modula su
ifrovane putem tehnologije digitalne envelope u PKCS#7 formatu.

68

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 Obeleja RAO

RAO treba da podri razliite hardverske elemente, kao to su: smart kartice,
hardverske bezbednosne module (HSM Hardware Security Module) i druge
tokene.
Poseduje grafiki interfejs jednostavan za korienje.

5.7 Sertifikaciono telo kao web vieslojna aplikacija

U prethodnim poglavljima smo opisali najvanije 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
zatienom TCP/IP vezom sa CA.
Meutim, u poslednje vreme, implementacije PKI sistema se u sve veoj i veoj meri
baziraju na vieslojnim aplikacijama, i to pre svega WEB vieslojnim aplikacijama.
Dakle, u novijim sistemima postoji WEB server CA i poseban aplikativni server CA
koji prosleuje zahteve CA crypto engine serveru u cilju formiranja digitalnih
sertifikata. U ovakvoj realizaciji, ne postoji RA, ve se funkcije RA i RAO kombinuju i
integriu u okviru Internet browser programa sa ciljem WEB komunikacije sa CA. Na
taj nain, najvei deo procesiranja se prebacuje na sentralni aplikativni server CA, a
RAO postaje tanki klijent.
U ovom sluaju, RAO priprema zahteve za izdavanjem i povlaenjem sertifikata,
digitalno ih potpisuje i po mogustvu ifruje, i prosleuje ih do WEB servera CA na
dalju obradu.
RAO moe, ali u najveem broju sluajeva ne uva nikakvu dokumentaciju u vezi
registracije korisnika ve se evidencija u potpunosti centralizuje u CA. RAO svojim
digitalnim potpisom potvruje da su podaci koje dostavlja za korisnika koji zahteva
sertifikat autentini i tani. Ovaj potpis se proverava na strani WEB servera CA.
U sluaju 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 sluajeve, u
nekim centralnim serverskim CA sistemima postoji i centralni RAO koji potvruje sve
zahteve koji dou putem WEB servera CA i odobrava formiranje sertifikata.

69

5.8 Digitalni sertifikati, struktura i standardi

Digitalni sertifikati predstavljaju element kojim se utvruje veza izmeu identiteta
subjekta i njegovog javnog kljua za primenu asimetrinog kriptografskog algoritma.
Raspolaganje javnim kljuem potpisnika je uslov za pouzdanu verifikaciju digitalnog
potpisa. Naime strana koja vri verifikaciju mora biti sigurna da dati javni klju
predstavlja kriptografski par sa privatnim kljuem kojim je poruka digitalno potpisana.
Javni i tajni klju asimetrinog kriptografskog algoritma su dve velike brojne veliine i
nemaju deterministiku vezu sa identitetom bilo kog pravnog ili fizikog lica. U tom
smislu, digitalni sertifikati predstavljaju mehanizam za pouzdano pridruivanje datog
para brojeva identitetu nekog subjekta, tako da se ta veza ne moe falsifikovati. Na
taj nain digitalni sertifikati predstavljaju elektronske ekvivalente nekoj vrsti digitalne
line karte ili digitalnog pasoa.
Da bi se dobio digitalni sertifikat, mora se prvo formirati zahtev za dobijanje sertifikata
(Certificate Request), koji se dostavlja odreenom CA u cilju izdavanja digitalnog
sertifikata. Ovaj zahtev sadri 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 autentinost dobijenog zahteva korienjem
javnog kljua koji je u njemu sadran. Pored toga, digitalnim potpisom zahteva za
dobijanjem sertifikata, korisnik dokazuje Sertifikacionom telu da poseduje privatni
klju koji je matematiki par sa javnim kljuem koji je sadran u datom zahtevu za
dobijanje sertifikata.
Postoje dva koriena 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 sledea 4 polja:

Broj verzije formata zahteva (od 1 do 3),

Naziv vlasnika digitalnog sertifikata (DistinguishedName - Dname),
Javni klju vlasnika digitalnog sertifikata,
Atributi.

Polje atributa sadri one elemente za koje postoji potreba da se nau u digitalnom
sertifikatu, kao to je broj telefona, broj faksa, e-mail adresa, najvia vrednost
finansijske transakcije u sluaju bankarskih sertifikata i druge karakteristike.
U ovom polju se moe nai 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 moe sastojati iz sledeih polja:

Dvoslovni niz koji oznaava dravu,

Region,
Elektronska adresa,

70

Firma,
Odeljenje u firmi,
Ime vlasnika sertifikata.

Imajui na raspolaganju digitalni sertifikat odreenog subjekta, mogue je izvriti

verifikaciju digitalnog potpisa poruka koje je taj subjekt potpisao. Ukoliko je
verifikacija uspena, verifikator je siguran u integritet poruke, u autentinost njenog
potpisnika i u nemogunost naknadnog poricanja datog potpisnika za izdavanje date
poruke (ukoliko je potpis elektronski potpis realizovan na smart kartici).
U okviru sistema zatite savremenih raunarskih mrea, digitalni sertifikati se,
izmeu ostalog, mogu primenjivati za verifikaciju digitalnog potpisa, kontrolu pristupa
subjekata kriptozatienim aplikacijama i u procedurama autentikacije.
Sadraj digitalnog sertifikata, u skladu sa standardom ITU-T X.509v3, je prikazan je
na slici 5.2.
Verzija formata sertifikata
Serijski broj sertifikata
Identifikator algoritma kojim se vri digitalni potpis
Naziv Sertifikacionog tela koje je izdalo sertifikat
Rok vanosti sertifikata
Naziv vlasnika sertifikata
Javni klju vlasnika sertifikata
Odreeni specifini podaci koji se odnose na uslove
korienja sertifikata
DIGITALNI POTPIS SERTIFIKATA PRIVATNIM KLjUEM
SERTIFIKACIONOG TELA
Slika 5.2: Sadraj 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
znaajni 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 sadri sledea 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. Nain dodeljivanja
serijskih brojeva mora biti jedinstven tj. ime izdavaa sertifikata (sertifikaciono
telo) i redni broj sertifikata jedinstveno odreuju sertifikat. Serijski broj

71

sertifikata je vrednost koju dodeljuje cerifikacioni autoritet u trenutku kreiranja

digitalnog sertifikata,
Identifikator algoritma digitalnog potpisa (Signature Algorithm) - oznaka
asimetrinog kriptografskog algoritma (RSA, DSA) i koriene hash funkcije
(MD5, SHA1) koji su primenjeni u procesu generisanja digitalnog potpisa
sertifikacionog tela,
Naziv izdavaa digitalnog sertifikata (Issuer) - struktura koja identifikuje
sertifikaciono telo (sertifikacioni autoritet, CA) koje je generisalo dati sertifikat i
sastoji se iz sledeih elemenata:
o
o
o
o
o
o
o

ime izdavaa sertifikata (commonName),

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

Validnost specificira se period unutar kojeg se sertifikat smatra vaeim

ukoliko nije opozvan. Rok vanosti sertifikata predstavlja vremenske okvire
validnosti digitalnog sertifikata. U procesu verifikacije prihvata se samo
sertifikat kome nije istekao rok vanosti. Navedeno polje se sastoji od dva
elementa:
o Poetak vanosti sertifikata (Valid From),
o Kraj vanosti sertifikata (Valid To).

Vlasnik sertifikata (Subject) identifikator (ime) vlasnika sertifikata kome se

pridruuje javni klju koji sadri sertifikat. Naziv vlasnika digitalnog sertifikata
je struktura koja identifikuje vlasnika digitalnog sertifikata i sastoji se od
sledeih komponenti:
o
o
o
o
o
o
o

ime vlasnika sertifikata,

odelenje u organizaciji,
organizacija,
mesto,
elekronska (e-mail) adresa ,
region ili republika u okviru drave,
oznaka drave.

Javni klju (Public Key) javni klju vlasnika sertifikata i identifikator algoritma
za koji je namenjen. Informacija o javnom kljuu vlasnika sadri numeriku
reprezentaciju javnog kljua i identifikator asimetrinog algoritma (RSA, DSA,
ECDSA) sa kojim se dati klju primenjuje.
Polje dodatnih informacija (Extension) sadri 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.

72

Ukoliko aplikacija koja koristi sertifikat pronae informaciju oznaenu sa

CRITICAL i ne prepozna je, mora sertifikat odbaciti kao neispravan.
Digitalni potpis (Digital Signature) sertifikata od strane CA.

Polje dodatnih informacija moe sadrati informacije pomou kojih se identifikuje

javni klju kojim se sertifikat proverava, ukoliko izdava ima vie parova javnih i tajnih
kljueva. Takoe dato polje moe da sadri informacije o nameni javnog kljua koji
vlasnik sertifikata poseduje, opis uslova pod kojima je sertifikat kreiran i zata se
moe koristiti, alternativna imena izdavaa i vlasnika sertifikata.
Prema dosadanjim iskustvima ovakva struktura sertifikata ispunjava zahteve
savremenih kriptografkih sistema zatite. Shodno tome, veina (ako ne i svi)
savremenih sistema zatite, koji ukljuuju infrastrukturu sistema sa javnim kljuevima
(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
poveava mogunost uvoenja i podrke novih PKI aplikacija. Dakle, ekstenzije se
mogu koristiti u cilju pridruivanja novih atributa korisniku u odnosu na one
informacije koje se mogu uneti u Dname strukturu.
Ekstenzije mogu biti takoe koriene za kreiranje hijerarhije digitalnih sertifikata.
Takoe, postoji nekoliko predefinisanih i meunarodno prepoznatih ekstenzija. Pored
toga, mogu se takoe realizovati nove ekstenzije za privatne potrebe korienjem
generikih ekstenzija.
Polja za ekstenzije u sertifikatu mogu biti koriena da se obezbede identifikacione
informacije, autorizacioni podaci i polja kontrole pristupa. Ukratko, ekstenzije
sertifikata mogu biti koriene da sadre informacije za koje korisnik smatra da mogu
biti korisne u procesu analize digitalnih sertifikatu.
Sve ekstenzije u sertifikatu mogu biti oznaene kao kritine (critical) ili nekritine
(noncritical). Ako je ekstenzija oznaena kao nekritina, to znai da e, ako neka PKI
aplikacija ne prepozna datu ekstenziju, ona biti ignorisana i da e se dati sertifikat
dalje normalno procesirati.
Ekstenziju treba oznaiti kao kritinu ako se eli da se osigura da ogranienje na
korienje datog sertifikata, koje se uvodi pomenutom ekstenzijom, nee moi da se
prenebregne od strane bilo koje aplikacije. Neke ekstenzije moraju biti obavezno
proglaene kritinim u skladu sa standardom X509v3. Meutim, za veinu ekstenzija
se preporuuje da budu nekritine.

73

Potrebno je, takoe, paljivo procenjivati potrebu za dodavanjem svake ekstenzije jer
one doprinose uveanju samog sertifikata. Takoe, to vie ekstenzija se doda to je
vea verovatnoa da e u budunosti neke informacije iz ekstenzija biti nevalidne i
da e se zbog toga morati povui sertifikat. U tom smislu, preporuka je da se u
sertifikat dodaju samo sutinski vane ekstenzije i da se ne poveava nepotrebno
veliina sertifikata dodavanjem nepotrebnih informacija.
Ekstenzije su karakteristine za verziju 3 digitalnih cerifikata. U polju ekstenzija se
nalaze dodatne informacije vezane za vlasnika i izdavaa sertifikata. Standardne
ekstenzije u sertifikatu su:

Identifikator kljua autoriteta (Authority Key Identifier),

Identifikator kljua subjekta (Subject Key Identifier),
Upotreba kljua (Key Usage),
Period korienja privatnog kljua (Private Key Usage Period),
Politike sertifikacije (Certificate Policies),
Mapiranje politike (Policy Mappings),
Alternativno ime subjekta (Subject Alternative Name),
Alternativno ime izdavaa sertifikata (Issuer Alternative Name),
Direktorijumski atributi subjekta (Subject Directory Attributes),
Osnovna ogranienja (Basic Constraints),
Ogranienja vezana za ime subjekta (Name Constraints),
Ogranienja vezana za primenjenu politiku (Policy Constraints),
Proireno korienje kljua (Extended Key Usage),
Distributivne take za listu povuenih sertifikata (CRL (Certificate Revocation
List) Distribution Points).

Navedene ekstenzije u sertifikatu su predloene od strane PKIX radne grupe

(Internet X.509 Public Key Infrastructure Certificate and CRL profile, RFC2459,
RFC3280 i RFC5280).
5.8.2.1 Identifikator kljua autoriteta (Authority Key Identifier)
Kada sertifikaciono telo (autoritet) ima vie razliitih privatnih asimetrinih kljueva
namenjenih za izdavanje digitalnih sertifikata razliitim grupama korisnika, ili u
razliitom vremenskom periodu, identifikator kljua autoriteta omoguava
identifikaciju javnog kljua CA koji odgovara privatnom kljuu korienom za digitalno
potpisivanje datog korisnikog sertifikata.
Pomenuta identifikacija moe biti bazirana bilo na identifikatoru kljua (identifikator
kljua subjekta (hash vrednost javnog kljua) u ekstenziji sertifikata) ili na imenu CA i
serijskom broju.
Usklaen CA sertifikat je sertifikat koji ukljuuje ekstenziju osnovnih ogranienja a
vrednost CA u toj ekstenziji je true. U cilju olakanog formiranja veze sertifikata,
polje keyIdentifier u ekstenziji authorityKeyIdentifier mora biti ukljueno u svim
usklaenim CA sertifikatima.

74

Ukoliko se radi o samopotpisanom CA sertifikatu, identifikator kljua autoriteta moe

biti izostavljen zato to su u tom sluaju identifikatori kljueva subjekta i autoriteta
identini.
Vrednost polja keyIdentifier se izvodi iz javnog kljua koji se koristi u procesu
verifikacije digitalnog potpisa sertifikata ili primenom metoda koja generie
jedinstvene vrednosti.
Ako se koristi ekstenzija identifikator kljua autoriteta ona treba da bude oznaena
kao nekritina.

5.8.2.2 Identifikator kljua subjekta (Subject Key Identifier)

Identifikator kljua subjekta je namenjen za identifikaciju javnog kljua datog
subjekta. U cilju olakanog formiranja veze sertifikata i privatnog kljua, ova
ekstenzija se mora pojaviti u svim usklaenim CA sertifikatima.
Vrednost identifikatora kljua subjekta mora biti vrednost smetena u polje
identifikatora kljua u ekstenziji identifikator kljua autoriteta. Za CA sertifikate,
identifikator kljua subjekta treba da bude izveden iz javnog kljua ili primenom
metoda koji generie jedinstvene vrednosti.
Uobiajene metode za generisanje identifikatora kljua iz javnog kljua su:

keyIdentifier sainjen od 160-bitne SHA-1 hash vrednosti izraunate nad

vrednou BIT STRING polja subjectPublicKey (iskljuujui tag, duinu i broj
neiskorienih bita),
keyIdentifier sainjen od 4-bitnog polja vrednosti 0100 praenih sa
poslednjih 60 bita (najmanje znaajnih) SHA-1 hash vrednosti izraunate u
odnosu na BIT STRING vrednost polja subjectPublicKey.

Jedan uobiajeni metod za generisanje jedinstvenih vrednosti je monotono

uveavanje sekvence celobrojnih vrednosti. Povoljnija varijanta je da se jedinstvene
vrednosti koje se koriste u sertifikatu (serijski broj, jedinstven identifikator korisnika u
okviru CA, itd.) generiu na odgovarajui sluajan nain, uz obezbeenje da se
izgenerisani sluajni brojevi ne ponavljaju.
U sluaju da je krajnji korisnik dobio vie sertifikata, naroito od vie CA, identifikator
kljua subjekta omoguuje brzu identifikaciju skupa sertifikata koji sadre odreeni
javni klju. Ova ekstenzija treba da bude ukljuena u sve sertifikate krajnjih korisnika
sa ciljem da se omogui aplikacijama da identifikuju odgovarajue sertifikate.
Za sertifikate krajnjih korisnika, identifikatori kljua subjekta treba da budu izvedeni iz
javnog kljua, korienjem jednog od dva ve pomenuta uobiajena metoda.
Ako se koristi ekstenzija identifikator kljua subjekta ona treba da bude oznaena
kao nekritina ekstenzija.

75

5.8.2.3 Korienje kljua (Key Usage)

Ekstenzija pod imenom korienje kljua (Key Usage) definie svrhu kljua koji se
sadri u sertifikatu (javni klju), kao i njemu odgovarajueg privatnog kljua.
Mogue je definisati sledee primene kljua:

kreiranje digitalnog potpisa poruka (digitalSignature vrednost) oznaava da se

taj par kljueva koristi za realizaciju digitalnog potpisa,
slina primena je i neporecivost (nonRepudiation), ova vrednost mora da bude
navedena u kvalifikovanim sertifikatima,
ifrovanje i deifrovanje simetrinog kljua (keyEncipherment) koje se
primenjuje u procesu kreiranja digitalne envelope,
ifrovanje i deifrovanje poruka (dataEncipherment),
kreiranje digitalnog potpisa sertifikata (certificateSigning),
kreiranje digitalnog potpisa CRL liste (CRLSigning).

Ako se koristi ekstenzija korienje kljua ona treba da bude oznaena kao kritina
ekstenzija.
5.8.2.4 Period korienja privatnog kljua (Private Key Usage Period)
Ova ekstenzija omoguava CA da specificira period vanosti privatnog kljua
subjekta, koji, prema ovoj ekstenziji, moe biti i razliit u odnosu na period vanosti
sertifikata.
Ova ekstenzija je namenjena za korienje u odnosu na klju za digitalno
potpisivanje i sastoji se od dve opcione komponente: notBefore i notAfter.
Meutim, PKIX radna grupa se izjasnila protiv korienja ove ekstenzije i CA koji
potuju X.509 standardni profil ne smeju da generiu sertifikate sa kritinom
ekstenzijom u smislu perioda korienja privatnog kljua.
5.8.2.5 Politike sertifikacije (Certificate Policies)
Ova ekstenzija sadri sekvencu od jednog ili vie parametara odreenih politika koji
oznaavaju politiku sertifikacije pod kojom je dati sertifikat izdat, kao i svrhe za koje
se dati sertifikat moe koristiti.
U cilju uspostavljanja interoperabilnosti, predloeno je da ovi parametri treba da
sadre samo identifikatore objekata (Object Identifier, OID). Kada je nedovoljna
primena samo identifikatora objekata, predlae se upotreba opcionih kvalifikatora.
Ova specifikacija definie dva tipa kvalifikatora koji se koriste od strane onih koji
izrauju politiku sertifikacije sertifikacionih tela. Tipovi kvalifikatora su CPS Pointer i
User Notice kvalifikatori.

76

Kvalifikator CPS Pointer sadri 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 specifine 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 omoguava da ova ekstenzija bude ili kritina ili nekritina. Ako je
definisana kao kritina, sistem za validaciju sertifikata mora imati mogunost da
jednoznano interpretira ovu ekstenziju (ukljuujui 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 vie
parova identifikatora objekata (OID). Svaki par ukljuuje issuerDomainPolicy i
subjectDomainPolicy. Uparivanje oznaava da CA koje izdaje digitalne sertifikate
primenjuje njenu issuerDomainPolicy ekvivalentnu subjectDomainPolicy od CA koje
je izdalo digitalni sertifikat datom subjektu.
Korisnici CA koje izdaje sertifikate mogu prihvatiti issuerDomainPolicy za odreene
aplikacije. Mapiranje politika govori korisnicima CA koje izdaje sertifikate koje politike,
pridruene CA datog subjekta, su uporedive sa politikama koje oni prihvataju.
Vano je istai da CA i aplikacije mogu da podre ovu ekstenziju, koja mora biti
nekritina.
5.8.2.6 Alternativno ime subjekta (Subject Alternative Name)
Ova ekstenzija omoguava dodatnim identitetima da budu povezani sa subjektom
sertifikata.
Definisane opcije ukljuuju sledee:

Internet e-mail adresu,

IP adresu,
DNS ime,
URI Uniform Resource Identifier.

Ostale opcije postoje, ukljuujui kompletnu lokalnu definiciju opcija.

Uvek kada viestruka imena, ili viestruke forme jednog imena, treba da budu
ukljuene u sertifikat, ekstenzija alternativnog imena subjekta treba da se koristi. S
obzirom da je alternativno ime subjekta takoe prikljueno javnom kljuu, 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 oznaena kao kritina.

77

Mogue je ograniiti alternativna imena subjekta na isti nain kao i Dname subjekta
korienjem ekstenzije ogranienja imena.
5.8.2.7 Alternativno ime izdavaoca (Issuer Alternative Name)
Kao i u sluaju alternativnog imena subjekta, ova ekstenzija se moe koristiti u cilju
pridruivanja Internet identifikacionih karakteristika CA.
Alternativno ime izdavaoca treba da bude prikazano na isti nain kao i alternativno
ime subjekta i ova ekstenzija se ne sme oznaiti kao kritina.
5.8.2.8 Direktorijumski atributi subjekta (Subject Directory Attributes)
X.509 standard i PKIX radna grupa ne prepoznaju ovu ekstenziju kao sutinski deo
profila, ali se moe iskoristiti u lokalnim okruenjima.
Ako se ova ekstenzija koristi, ne treba biti oznaena kao kritina.
5.8.2.9 Osnovna ogranienja (Basic Constraints)
Ova ekstenzija identifikuje da li je subjekt sertifikata sertifikaciono telo, kao i duinu
sertifikacionog puta (Certification Path) datog CA.
Preko navedene ekstenzije se specificira da li vlasnik datog sertifikata moe da
generie digitalne sertifikate za ostale korisnike (Subject Type=CA) ili ne (Subject
Type=End Entity).
Polje pathLenConstraint ima znaenje samo ako je vrednost CA u ovoj ekstenziji
postavljeno na true. U tom sluaju, ovo polje daje maksimalan broj CA sertifikata
koji mogu pratiti ovaj sertifikat u okviru sertifikacionog puta. Vrednost nula oznaava
da samo sertifikati krajnjih korisnika mogu biti u datom sertifikacionom putu. Kada
ovo polje ne postoji, ne postoji ogranienje na dozvoljenu duinu sertifikacionog puta.
Ova ekstenzija ne treba da se pojavljuje u sertifikatima krajnjih korisnika a u
sluajevima kada se koristi, mora da bude kritina ekstenzija u svim CA sertifikatima.
5.8.2.10 Ogranienja imena (Name Constraints)
Ova ekstenzija se moe jedino koristiti u CA sertifikatu. Ova ekstenzija oznaava
prostor imena u koji treba da se smeste sva imena u naknadnim sertifikatima u
datom sertifikacionom putu. Ogranienja se mogu primeniti na pravo (distinguished)
ili alternativno ime subjekta. Ogranienja se primenjuju samo kada je data forma
imena prisutna. Ako nema imena tog tipa u sertifikatu, sertifikat je prihvatljiv.
Ogranienja se definiu u obliku dozvoljenih i iskljuenih podgrana imena. Bilo koje
ime koje spada u ogranienje definisano u iskljuenoj podgrani, polje
excludedSubtrees, nije validno bez obzira na informacije koje stoje u polju
permittedSubtrees. Za URI, ogranienje se primenjuje na host deo imena.

78

Ako se koristi ova ekstenzija ona treba da bude oznaena kao kritina.
5.8.2.11 Ogranienja politike (Policy Constraints)
Ova ekstenzija se moe koristiti u sertifikatima koji su izdati odreenim CA. Ova
ekstenzija ograniava validaciju sertifikacionog puta na dva naina. Ekstenzija moe
biti koriena da sprei mapiranje politika ili u cilju zahteva da svaki sertifikat u putu
sadri prihvatljiv identifikator politike.
Ako je polje inhibitPolicyMapping prisutno, njegova vrednost oznaava broj dodatnih
sertifikata koji mogu da se pojave u sertifikacionom putu pre nego to je spreeno
mapiranje politika. Na primer, vrednost jedan oznaava da se procedura mapiranja
politike moe 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 ukljuivati
prihvatljiv identifikator politike. Vrednost ovog polja oznaava broj dodatnih sertifikata
koji mogu da se pojave u sertifikacionom putu pre nego to se zahteva eksplicitna
politika. Identifikator prihvatljive politike je identifikator politike koja se zahteva od
strane korisnika sertifikacionog puta ili identifikator politike koja je oznaena kao
ekvivalentna kroz proceduru mapiranja politika.
Usklaena CA ne smeju da izdaju sertifikate kada je ogranienje politike null
sekvenca. To znai da najmanje jedno od dva polja (inhibitPolicyMapping ili
requiredExplicitPolicy) mora da bude prisutno.
Ukoliko se koristi ova ekstenzija, ona moe biti oznaena kao kritina ili nekritina.
5.8.2.12 Proireno korienje kljua (Enhanced Key Usage)
Ova ekstenzija oznaava jednu ili vie namena za koje se sertifikovani javni klju
moe koristiti, zajedno sa, ili umesto osnovne svrhe koja je oznaena u ekstenziji
korienja kljua.
Data ekstenzija definie dodatnu namenu para kljueva asimetrinog algoritma
specificiranog u digitalnom sertifikatu. Mogue je definisati sledea proirenja
primene kljua:

digitalno potpisivanje izvrnog programa (CodeSigning),

digitalno potpisivanje poruka koje se prenose posredstvom elektronske pote
(Secure Email),
autentikacija servera prilikom kreiranja kriptografskog tunela sa klijentskim
raunarom (Server Authentication),
autentikacija klijenta prilikom kreiranja kriptografskog tunela sa serverskim
raunarom (Client Authentication).
logovanje na domen pute smart kartica (Smart Card logon), itd.

Ako se ova ekstenzija koristi, ona moe biti oznaena kao kritina ili nekritina.
Ako je ekstenzija oznaena kao kritina, tada se sertifikat moe koristiti samo za
jednu od navedenih svrha.

79

Ako je ekstenzija oznaena kao nekritina, tada ona oznaava namenjenu svrhu ili
svrhe primene kljua i moe biti koriena za pronalaenje korektnog
kljua/sertifikata korisnika koji ima viestruke kljueve/sertifikate, i u tom sluaju, se
moe koristiti samo kao savetodavno polje.
Ako sertifikat sadri kritino polje korienja kljua i kritino polje proirenog
korienja kljua, tada oba polja moraju da se procesiraju nezavisno i sertifikat moe
biti korien samo u svrhe koje su konzistentne sa oba polja. Ako nema takve svrhe,
sertifikat ce ne moe koristiti.
5.8.2.13 CRL distributivne take
Ova ekstenzija oznaava kako se mogu dobiti informacije o CRL. Ova ekstenzija je
podrana od strane CA i aplikacija.
Ako se ova ekstenzija koristi, ona treba da bude oznaena kao nekritina.
5.8.3 Najee koriene ekstenzije
Najee ekstenzije prisutne u verziji v3 digitalnih cerifikata su:

Osnovna ogranienja (Basic Constraints). Preko navedene ekstenzije se

specificira da li vlasnik datog sertifikata moe da generie digitalne sertifikate
za ostale korisnike (Subject Type=CA) ili ne (Subject Type=End Entity).
Specifikacija primene kljua (Key Usage). Data ekstenzija odreuje namenu
kljua asimetrinog algoritma specificiranog u digitalnom cerifikatu. Mogue je
definisati sledee primene kljua:
o kreiranje digitalnog potpisa poruka (Digital Signature),
o deifrovanje poruka ime se moe ostvariti funkcija neporecivosti (NonRepudiation),
o ifrovanje simetrinog kljua (KeyEncipherment) koje se primenjuje u
procesu kreiranja sesijskog kljua ili digitalne envelope,
o ifrovanje poruka (DataEncipherment),
o kreiranje digitalnog potpisa sertifikata (Certificate Signing).

Dodatna specifikacija primene kljua (Enhanced Key Usage). Data ekstenzija

definie dodatnu namenu kljua asimetrinog algoritma specificiranog u
digitalnom cerifikatu. Mogue je definisati sledea proirenja primene kljua:
o digitalno potpisivanje izvrnog programa (CodeSigning),
o digitalno potpisivanje poruka koje se prenose posredstvom elektronske
pote (Secure Email),
o autentikacija servera prilikom kreiranja kriptografskog tunela sa
klijentskim raunarom (Server Authentication),
o autentikacija klijenta prilikom kreiranja kriptografskog tunela sa
serverskim raunarom (Client Authentication).

80

Politika primene digitalnog sertifikata (Certificate Policy). Data ekstenzija

poblie definie politiku i nain primene datog digitalnog cerifikata. Svaka
politika primene sertifikata je predstavljena sa:
o oznakom date politike (Policy Qualified Id),
o vrednou koja opisuje nain primene sertifikata u skladu sa
specificiranom politikom (Qualified).

5.9 Metode registracije korisnika

CA moe bilo da dobije javni klju od samog korisnika i da ga sertifikuje, ili da
generie za svakog korisnika par javnog i privatnog kljua asimetrinog
kriptografskog sistema i da distribuira zajedno privatni klju i PKI digitalni sertifikat.
Iz razloga sigurnosti i logistikih povoljnosti, u izvesnim sluajevima se smatra boljom
praksom ako korisnik sam generie par asimetrinih javnih kljueva (javni i tajni
klju), a zatim da zahtev za izdavanjem sertifikata koji sadri njegov javni klju
dostavi CA na sertifikaciju.
Ovaj metod obezbeuje da se privatni klju uvek uva na jednoj lokaciji kod
korisnika. Meutim, pomenuti razlozi sigurnosti se mogu opravdati samo sa
stanovita korisnika. Sa stanovita PKI sistema (CA), sigurnije je da samo CA bude
nadleno za generisanje parova asimetrinih kljueva jer se jedino na taj nain moe
kontrolisati i odrati jedinstven kvalitet izgenerisanih kljueva i jedinstvenost
procedure bezbednog uvanja izgenerisanih kljueva. U tom sluaju, privatni kljuevi
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 odreenom CA u cilju izdavanja digitalnog
sertifikata. Ovaj zahtev sadri sve line informacije koje e se pojaviti i u vaem
digitalnom sertifikatu.
Postoje generalno dva mogua naina generisanja para javnog i privatnog kljua i
kreiranje digitalnog sertifikata na bazi javnog kljua:

CA generie par javnog i privatnog kljua, formira digitalni sertifikat i dostavlja

privatni klju i sertifikat vlasniku,
Generisanje para javnog i privatnog kljua lokalno od strane samog vlasnika
sertifikata korienjem hardverskih ili softverskih mehanizama. Zatim se izvri
kreiranje zahteva za izdavanjem sertifikata koji sadri javni klju vlasnika koji
se alje ka CA.

U okviru datog PKI sistema, politika rada po kojoj se izdaju sertifikati od strane CA
odreuje 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 Praktina pravila rada (Certificate Practise Statement
CPS). Tako su definisane politike po kojima se izdaju sertifikati sa razliitim nivoima

81

pouzdanosti i, u skladu sa tim, definiu se razliite metode registracije koje moraju

biti primenjene u vezi lica koja zahtevaju sertifikate.
U stvari, proces registracije podrazumeva prikupljanje i odgovarajuu proveru
razliitih podataka od krajnjih korisnika, direktno u linom kontaktu ili u indirektnom
udaljenom zahtevu preko gejtveja (na primer web pretraivakog programa).
U smislu procesa registracije, politika sertifikacije PKI sistema detaljno definie
sledee:

kako treba primeniti proces registracije,

koje informacije o licima je potrebno proveriti ili zapisati,
broj parova asimetrinih kljueva (i samim tim broj razliitih sertifikata) koje
treba generisati za datog korisnika (tipino se razliiti parovi kljueva generiu
za digitalno potpisivanje i za digitalnu envelopu (ifrovanje)),
gde e se i na kom medijumu generisati kljuevi; kljuevi mogu biti generisani
od strane samih korisnika, od strane RAO ili od strane CA, i mogu biti
sauvani na hard disku, disketi, mini CD medijumu, smart kartici ili nekom
drugom tokenu.
Format sertifikata koji treba da se generiu,
Dodatne poslovne informacije koje treba da budu prikupljene za vreme
procesa registracije.

U stvari, postoje generalno dve opcije za generisanje asimetrinih kljueva (kod

samog korisnika ili u CA) kao i dve opcije za registraciju (udaljena ili u linom
kontaktu). Mogue je ostvariti vie razliitih kombinacija. U politici sertifikacije datog
PKI sistema su definisane kombinacije koje su dozvoljene u datom PKI sistemu.
5.9.1 Registracija u linom kontaktu
Za odreene PKI sisteme, direktne registracione procedure na bazi linog kontakta
predstavljaju jedini bezbedni nain za korektnu autentikaciju krajnjih korisnika i
distribuciju i generisanje kljueva i sertifikata.
U Intranet okruenju, organizacija moe da primeni politiku rada prema kojoj korisnici
moraju lino da kontaktiraju osobu nadlenu za poslove bezbednosti (ili RAO) u cilju
preuzimanja tokena ili smart kartice sa njihovim kljuevima i sertifikatima. Ova
registracija zahteva da korisnik pokae ID karticu zaposlenih, linu kartu, vozaku
dozvolu, paso ili neki drugi metod identifikacije.
U Internet okruenju, organizacije sa javnim poslovnicama, kao to su banke, pote,
itd., mogu zahtevati od korisnika da lino dou u datu poslovnicu i daju svoje line
podatke.
Registracija linim kontaktom se odvija tako to slubenik koji koristi aplikaciju RAO
modula unese line informacije korisnika i potvrdi zahtev za izdavanje sertifikata
(svojim digitalnim potpisom). Kljuevi se mogu generisati od strane same RAO
aplikacije i sauvani na disku u zatienom obliku putem lozinke izabrane od strane
korisnika, ili korisnik moe da generie sopstvene kljueve, a da dostavi samo zahtev

82

za izdavanje sertifikata do RAO modula. Kljuevi se takoe mogu generisati i

centralno u samom CA, ukoliko je tako predvieno Politikom sertifikacije.
Odreene RA aplikacije mogu koristiti i odreene terminalne ureaje za akviziciju
biometrikih podataka, kao to je fotografija, otisak prsta, glas, parametri zenice oka,
itd., i da te netekstualne podatke takoe uvaju u odgovarajuem obliku u bazi
podataka.
Kada se izgenerie digitalni sertifikat za datog korisnika, taj sertifikat moe biti
sauvan na disketi, mini CD medijumu, hard disku, smart kartici ili na nekom drugom
tokenu.
Proces izdavanja digitalnog sertifikata na bazi linog dolaska vlasnika u RA
uobiajeno se sastoji iz sledeih koraka:

Budui vlasnik digitalnog sertifikata dostavlja RAO svoje podatke lino,

RAO formira zahtev za izdavanje sertifikata na bazi dobijenih podataka,
RAO alje kreirani zahtev do baze, oznaava ga kao procesirani i digitalno ga
potpisuje,
RA uzima procesirani zahtev iz baze, verifikuje ga, digitalno potpisuje i alje
ga kao zatienu 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 smeta ga u
bazu podataka,
CA publikuje sertifikate na X.500/LDAP direktorijum. CA takoe periodino
publikuje listu povuenih sertifikata (CRL Certificate Revocation List) i listu
povuenih autoriteta (ARL Authority Revocation List). Sve liste koje se izdaju
moraju biti digitalno potpisane. ARL se referie 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 sadri u
zatienoj (digitalno potpisanoj i ifrovanoj) standardizovanoj poruci.
RA verifikuje datu poruku, digitalno je potpisuje i pridruuje je bazi podataka,
RAO preuzima izdati sertifikat iz baze, verifikuje ga i uva ga u zahtevanom
formatu (PKCS#7, PKCS#12, ili drugi).
RAO obezbeuje dostavljanje digitalnog sertifikata vlasniku koji ga je traio.

Prethodno navedeni proces predstavlja proces koji se sprovodi u sluaju da su CA,

RA i RAO tradicionalno bazirane klijent-server aplikacije.
U sluaju da se radi o modernijim WEB vieslojnim CA sistemima, proces registracije
korisnika se sastoji u sledeim koracima:

Budui vlasnik digitalnog sertifikata dostavlja RAO svoje podatke lino,

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 smeta ga u bazu podataka,

83

CA publikuje sertifikate na X.500/LDAP direktorijum. CA takoe periodino

publikuje listu povuenih sertifikata (CRL Certificate Revocation List) i listu
povuenih autoriteta (ARL Authority Revocation List). Sve liste koje se izdaju
moraju biti digitalno potpisane. ARL se referie 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 sadri u
zatienoj (digitalno potpisanoj i ifrovanoj) standardizovanoj poruci.
RA verifikuje datu poruku i obezbeuje dostavljanje digitalnog sertifikata
vlasniku koji ga je traio.
Umesto prethodna dva koraka, mogue je da korisnik sam direktno dobavi
sertifikat od strane CA.

5.9.2 Udaljena registracija

U mnogim sluajevima, zahteva se metoda registracije koja se ne oslanja na
registraciju linim kontaktom. Najee, ove metode se primenjuju kada je korisnik
udaljen od RA. U tom sluaju, omoguuje se registracija putem slanja zahteva za
izdavanje sertifikata korienjem Internet pretraivakih programa i WEB
komunikacije, e-mail servisa ili VPN konekcija.
Meutim, najee se u ove svrhe koristi metoda registracije korienjem WEB
komunikacije. U tim sluajevima, korisnik svoj zahtev dostavlja do baze RA preko
web komunikacije. Korienjem RAO modula se dati zahtev dalje procesira na isti
nain kao i u sluaju registracije putem linog kontakta. Alternativno, ako politika rada
to dozvoljava, mogue je da RA bude konfigurisano tako da se dobijeni zahtevi
automatski prosleuju do CA, bez potvrivanja od strane RAO.
Proces udaljene sertifikacije uobiajeno ukljuuje sledee korake:

Budui vlasnik digitalnog sertifikata dostavlja zahtev za izdavanje sertifikata certificate service request (CSR - obino u PKCS#10 formatu) do web servera
CA (web sajt CA) preko TCP/IP mree,
WEB server CA alje dobijeni zahtev preko TCP/IP mree do RA gde se
dobijeni zahtev digitalno potpisuje i smeta u bazu podataka RA. Za ovu
svrhu, postoji odgovarajue RA na lokaciji CA,
Operator RA (RAO) preuzima dobijeni zahtev iz baze podataka i procesira ga,
RAO zatim vraa procesirani zahtev nazad u bazu pri emu ga prethodno
digitalno potpisuje i oznaava kao procesiranog,
RA uzima procesirani zahtev iz baze, digitalno ga potpisuje i alje ga kao
zatienu 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 smeta ga u bazu podataka,
CA publikuje sertifikate na X.500/LDAP direktorijum. CA takoe periodino
publikuje listu povuenih sertifikata (CRL Certificate Revocation List) i listu
povuenih autoriteta (ARL Authority Revocation List). Sve liste koje se izdaju
moraju biti digitalno potpisane. ARL se referie na sertifikate samih PKI

84

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 sadri u
zatienoj standardizovanoj poruci.
RA verifikuje datu poruku, digitalno je potpisuje i pridruuje je bazi podataka,
RA uzima digitalni sertifikat iz svoje baze podataka i alje ga do web servera
preko TCP/IP mree.
Web server omoguuje pristup digitalnom sertifikatu od strane vlasnika koji ga
je zahtevao. U zavisnosti od konfiguracije, digitalni sertifikat se uva na
odreenom direktorijumu na hard disku a URL adresa se alje elektronskom
potom vlasniku.

Prethodno navedeni proces predstavlja proces koji se sprovodi u sluaju da su CA,

RA i RAO tradicionalno bazirane klijent-server aplikacije. U sluaju da se radi o
modernijim WEB vieslojnim CA sistemima, proces registracije korisnika se vri na
slian nain s tim to jedino u okviru CA nema baze RA ve centralni RAO zahteve
za certifikatima direktno proverava i potvruje iz centralne baze CA.

5.10 Sistemi za distribuciju sertifikata

Distribucija sertifikata je jedna od osnovnih funkcija koje dati PKI sistem treba da
realizuje na fleksibilan nain. Postoje tri razliita tipa distribucije sertifikata:

dostavljanje izdatih sertifikata do krajnjeg korisnika,

publikovanje CA sertifikata,
publikovanje izdatih i povuenih sertifikata krajnjih korisnika na odgovarajui
nain (putem odgovarajuih direktorijuma) u cilju da budu dostupni svim
drugim korisnicima, kao i svim zainteresovanim stranama.

Sve ovo treba da bude realizovano tako da bude u slubi krajnjeg korisnika i da
koristi organizacionoj infrastrukturi.
Sertifikati za krajnje korisnike moraju biti isporueni licu koje je podnelo zahtev na
nain i u formatu koji odgovara njegovim potrebama. Na primer, sertifikati koji su
zahtevani linim 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 nain kao to su zahtevi i stigli, na primer WEB
komunikacijom.
Sertifikat samog CA mora biti javan i raspoloiv koliko god je to mogue. Svaki
korisnik u sistemu mora da poseduje sertifikat CA pre nego to pone da koristi
servise datog PKI sistema. Sertifikat CA je neophodan da bi se verifikovao digitalni
potpis sertifikata svih uesnika u sistemu tj. da bi se proverila autentinost veze
izmeu identiteta odreenog uesnika u sistemu i njegovog javnog kljua
asimetrinog kriptografskog sistema.

85

Sertifikat CA, kao i ostali izdati sertifikati u sistemu, mogu biti isporuivani u razliitim
formatima, kao i publikovani na X.500 ili LDAP direktorijumu. Takoe, sledea lista
formata za zapis sertifikata treba da bude podrana u sistemu: PEM; DER, PKCS#7 i
PKCS#10.
Korienje direktorijuma moe znaajno poboljati funkcionalnost sistema. Naime, u
cilju ifrovanja poruke i njenog slanja u obliku digitalne envelope, neophodno je
posedovati sertifikat namenjenog primaoca. Takoe, u cilju verifikacije digitalnog
potpisa neke poruke, potrebno je imati sertifikat potpisnika i mogunost da se izvri
validacija datog sertifikata (da li je u vaeem roku i da li nije povuen). Zbog ovih
razloga, obino se sertifikati i CRL smetaju na direktorijum koji je raspoloiv svim
ovlaenim uesnicima u sistemu. Meutim, ne postoji obaveza CA da publikuje
izdate sertifikate.
Sertifikati i CRL mogu biti publikovani i na WEB sajtu CA, raspoloivi preko OCSP
servisa ili da budu distribuirani e-mail servisom do svih uesnika u sistemu, u
zavisnosti od utvrene politike rada CA.

5.11 Upravljanje ivotnim vekom sertifikata

U okviru Politike certifikacije datog sertifikacionog tela neophodno je specificirati
procedure upravljanja ivotnim vekom certifikata, kao to su: povlaenje, obnavljanje
i suspenzija. U nastavku su opisane pomenute procedure.
5.11.1 Obnavljanje sertifikata
Korisniki sertifikati vae ogranieni vremenski period, na primer godinu dana, to je
propisano u okviru Politike certifikacije CA. Takoe moe biti propisan period pre
isteka perioda vanosti sertifikata kada e se u okviru aplikacije zatite, 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 vri 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 istai da se obnavljanje mora izvriti pre isteka roka vanosti
sertifikata. Ako period vanosti certifikata istekne, moraju se generisati potpuno novi
certifikati (novi kljuevi) za datog korisnika. Takoe, treba istai da se obnavljanje vri
tako da uvek bude izdat novi certifikat koji ima rok vanosti tano godinu dana posle
datuma obnavljanja, uz obezbeenje da bude uvek validan. Dakle, obnavljanje se
vri na period od na primer 12 meseci od datume obnavljanja. Ovo se regulie u
okviru administratorske aplikacije CA.
5.11.2 Povlaenje sertifikata
Korisniki sertifikati se mogu povui (opozvati) iz generalno dva tipa razloga:

86

Dolo je do nekih promena informacija iz sertifikata za datog korisnika,

Dolo je do gubitka asimetrinog privatnog klja korisnika ili je iz bilo kog
razloga dolo do kompromitacije privatnog kljua datog korisnika.

U oba sluaja, korisnik je duan da odmah prijavi CA ili RA nastalu promenu.

Politikom sertifikacije su specificirani odgovarajui slubenici CA (najee RAO i
CAO) koji imaju pravo povlaenja sertifikata.
Potrebno je dodatno istai da se povlaenje, kao i obnavljanje, ukoliko korisnik ima
dva sertifikata uvek mora izvriti za oba sertifikata koji su izdati.
5.11.3 Suspenzija sertifikata
Postoji mogunost i privremene suspenzije sertifikata odreenog korisnika koja se
vri ako je primenjena odgovarajua suspenzivna mera pruanja usluga sertifikacije
datom licu, ili zbog odlaska na due odsustvo (moda ak i godinji odmor).
Procedura suspenzije je praktino ista kao i procedura povlaenja sertifikata jer
sertifikati fiziki idu na CRL listu. Razlika je u tome to suspendovani sertifikati mogu
ponovo biti aktivni posle isteka suspenzije dok se jednom povueni certifikati ne
mogu nikada ponovo aktivirati. Proceduru suspenzije sertifikata uglavnom vre ista
lica kao i u sluaju povlaenja.

5.12 Lista povuenih sertifikata

Za vreme ivotnog veka sertifikata (obino je to period od jedne do pet godina)
mogue je da se steknu razlozi da se dati sertifikat proglasi nevaeim i da se datom
korisniku ne dozvoli pristup sistemu.
U tom smislu, povlaenje sertifikata se odnosi na praksu proglaavanja nevaeim
javnog kljua datog korisnika, ime se automatski i njegov tajni klju proglaava
nevaeim i datom korisniku se tako onemoguava validno digitalno potpisivanje
poruka.
Meutim, od sutinske je vanosti da informacija o povuenosti datog sertifikata bude
to je mogue pre javno objavljena i dostupna svim uesnicima u sistemu
(direktorijum, WEB sajt ili OCSP servis). Funkcija povlaenja sertifikata je u
odgovornosti CAO, RAO, kao i samih krajnjih korisnika.
Obeleja PKI sistema koja podravaju servis povlaenja sertifikata ukljuuju:

Kreiranje liste povuenih sertifikata (CRL) verzije 2,

Kreiranje interfejsa za povlaenje sertifikata u okviru CAO i RAO,
Obezbeivanje da se, ako je to u skladu sa politikom rada CA, zahtevi za
povlaenjem sertifikata dostavljaju i od strane samih krajnjih korisnika,
Publikovanje CRL na direktorijumu i korienje OCSP servisa,

87

Korienje distributivnih taaka za sertifikate (CDP Certificate Distribution

Points) koje omoguavaju deljenje CRL na manje delove i stoga njihovo bre
pretraivanje,
Korienje funkcije suspenzije sertifikata, umesto povlaenja jer se
suspendovan sertifikat moe ponovo uiniti validnim kasnije dok se jednom
povueni sertifikat ne moe uiniti ponovo validnim nego se mora izdati novi
sertifikat,
Zapisivanje razloga za povlaenje sertifikata to je omogueno korienjem
CRL verzija 2,
Periodino publikovanje CRL ili njeno auriranje sa svakom novom promenom
u smislu dodavanja povuenih sertifikata. Vreme i uestanost auriranja CRL
je propisano u Politici sertifikacije CA,
Zapisivanje vremena povlaenja sertifikata to je omogueno korienjem
CRL verzije 2,
Opciono ukljuivanje lozinki u politiku izdavanja sertifikata koje omoguavaju
krajnjim korisnicima da povuku njihove sopstvene sertifikate.

Lista povuenih sertifikata (CRL Certificate Revocation List) omoguuje 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 sadri sledee informacije:

Listu povuenih sertifikata sa razlogom njihovog povlaenja,

Naziv izdavaoca CRL,
Vreme kada je CRL izdato,
Vreme kada e sledea verzija CRL biti publikovana.

Veoma vano je istai da u sluaju kada CA koje izdaje sertifikate istovremeno

publikuje i CRL, tada je CRL digitalno potpisana od strane CA, ime se omoguuje
svim korisnicima da budu sigurni u informacije koje CRL sadri.
Pristup CRL i provera validnosti sertifikata se vri kada je potrebno koristiti javni klju
iz PKI sertifikata odreenog korisnika kome treba poslati ifrovanu poruku ili treba
verifikovati digitalni potpis primljene poruke od strane tog korisnika.
Bilo koja od pomenutih aktivnosti treba da sadri sledee korake:

Proveriti validnost digitalnog sertifikata datog korisnika,

Uzeti serijski broj sertifikata,
Pristupiti (uitati) CRL (obino se to radi download-ovanjem sa X.500
direktorijuma korienjem LDAP pretrage i LDAP odgovora ili uzimanjem iz
lokalno sauvane CRL),
Proveriti digitalni potpis CRL, vreme njenog publikovanja i vreme kada e
sledea verzija biti publikovana,
Proveriti da li se dati sertifikat nalazi u CRL (na bazi serijskog broja),
Alarmirati datog korisnika ako je sertifikat povuen,

88

Izvriti eljenu kriptografsku aplikaciju ukoliko se sertifikat ne nalazi u CRL ili

ako namenjeni korisnik, nakon alarma, preduzme aktivnosti da njegov
sertifikat ne bude vie u CRL.

Uobiajeno, CA je odgovorno za neporecivost transakcija, obezbeujui audit log

datoteke i uvajui sve publikovane verzije CRL.
Alternativno, korisnika aplikacija moe realizovati mehanizme kojima se obezbeuje
neporecivost transakcija. Meutim, u tom sluaju, za svaku izvrenu transakciju,
mora se uvati sama poruka kao i CRL koje je korieno u trenutku kada je
verifikovan digitalni potpis poruke (ili je poruka ifrovana javnim kljuem korisnika).
Jedino ste tada u mogunosti da dokaete da ste koristili javni klju namenjenog
korisnika za verifikaciju ili ifrovanje u trenutku kada njegov digitalni sertifikat nije bio
povuen.
Prednosti CRL:

CRL je iroko podrana tehnologija u okviru PKI industrije,

CRL moe biti distribuirano do krajnjih korisnika na razliite naine, ukljuujui
push i pull metodu,
CRL moe biti arhivirano da obezbedi neporecivost za prethodno izvrene
transakcije,
CA izdaje i PKI sertifikate i CRL,
Mnoge PKI aplikacije mogu dobiti CRL sa X.500 direktorijuma korienjem
DAP/LDAP protokola.

Prepoznata su sledea ogranienja upotrebe CRL:

Korisnik mora imati tekuu verziju CRL u trenutku verifikacije digitalnog

potpisa ili ifrovanja podataka. Poto je CRL datoteka, korisnikova aplikacija
mora obezbediti novu verziju CRL, ako je kopija na njegovom lokalnom
sistemu zastarela. U velikom PKI okruenju, korisnik moe imati potrebu da
obezbeuje CRL veoma esto, a samo CRL moe biti veoma veliko. Stoga,
sve to moe znaajno usporiti rad neke PKI aplikacije zbog neophodnosti da
se uvek obezbeuje poslednja verzija CRL sa veoma zauzetog
direktorijumskog servera (ili neke druge CRL distribucione take).
CRL se kreira i publikuje periodino, pri emu je taj period odreen Prakitnim
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. Preesto publikovanje CRL moe zaguiti
itavu infrastrukturu, dok nedovoljno esto publikovanje moe rezultovati u
potencijalnoj mogunosti da se neki sertifikati koriste iako su ve povueni.

CA periodino kreira CRL datoteku na bazi primljenih zahteva za povlaenjem izdatih

digitalnih sertifikata. Po kreiranju, CRL ukljuuje 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 reeno, CA digitalno potpisuje CRL tako da krajnji korisnici
mogu biti sigurni u integritet i autentinost informacija u okviru CRL.

89

Kada istekne vanost digitalnih sertifikata, njihov status u vezi povuenosti se vie ne
prikazuje u okviru CRL. Ova mera pomae da se minimizuje veliina CRL za vreme
rada datog CA a i smatra se da status povuenosti nema znaaja za sertifikat kome
je istekla vanost.
Pored procedure povlaenja sertifikata, postoji i jo jedno specijalno stanje koje se
naziva suspenzija sertifikata. Za razliku od jednom povuenog sertifikata,
suspendovan sertifikat ima karakteristiku da ponovo moe biti validan. CA obino
suspenduje sertifikate kada postoji bilo kakva sumnja da je tajni klju korisnika
kompromitovan ili izgubljen. To takoe moe biti veoma korisno stanje sertifikata u
sluajevima kada je krajnji korisnik siguran da jedno vreme nee koristiti svoj tajni
klju.
Suspendujui svoj sertifikat, krajnji korisnik u stvari onemoguuje korienje svog
tajnog kljua sve dok CA ne uini dati sertifikat ponovo validnim. Uslovi pod kojima
se vri suspenzija, prestanak suspenzije ili povlaenje sertifikata definisano je u CPS
datog CA. Serijski broj suspendovanog sertifikata je ukljuen u CRL uz navedenu
karakteristiku povlaenja: suspendovan. Ako je sertifikat ponovo validan, njegov
serijski broj se brie iz naredne publikovane verzije CRL.
Profil CRL koji odgovara standardu X.509v2 (RFC 2459) definie osnovni skup
informacija koje se oekuju da budu sadrane u svakoj CRL. Pomenuti profil takoe
definie lokacije u okviru CRL za esto koriene atribute, kao i zajednike
reprezentacije tih atributa.
Prema pomenutom standardu, profil nazvan certificateList sadri sledea polja:

tbsCertList koje sadri sledee 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 sadri identifikator algoritma kojim se digitalno potpisuje
CRL,
o issuer predstavlja izdavaoca CRL (najee je to CA koje izdaje
digitalne sertifikate),
o thisUpdate ukazuje na datum publikovanja date CRL,
o nextUpdate ukazuje na datum kada e sledea verzija CRL biti
publikovana. Nova verzija moe biti publikovana i pre navedenog
datuma, ali nikako kasnije od toga.
o RevokedCertificates digitalni sertifikati povueni od strane CA su
jedinstveno identifikovani njihovim serijskim brojem. Vreme povlaenja i
druge CRL ekstenzije su takoe definisane.
o CRLextensions polje koje moe biti korieno samo ako se radi o
verziji 2 i sadri dodatne atribute koji mogu biti od koristi, kao to su:
redni broj CRL, distribucionu taku, itd.

signatureAlgorithm sadri identifikator algoritma koji CA koristi za digitalno

potpisivanje polja tbsCertList i mora sadrati isti algoritam kao i prethodno
navedeno polje signature.

90

signatureValue sadri digitalni potpis polja tbsCertList kodovan po standardu

ASN.1 DER.

CA je odgovorno za odgovarajuu distribuciju i raspoloivost CRL za okruenje koje

opsluuje. Najee je to postignuto izlaganjem CRL na X.500 direktorijumskom
serveru, kao tipinom servisu podranom od strane CA. Nakon toga je u
odgovornosti krajnjeg korisnika, ili njegove softverske aplikacije, da preuzima CRL iz
X.500 direktorijuma.
Postoje i alternativni naini distribucije CRL, kao to je slanje CRL svim korisnicima
putem elektronske pote (push metod) ili objavljivanje CRL na odgovarajuem 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 okruenju iz razloga pogodnosti X.500 pristupa i
iroke rasprostranjenosti primene LDAP komunikacionog protokola korienog za
interakciju sa X.500 direktorijumom.
DAP (Directory Access Protocol) je jedan od etiri protokola definisanih u okviru
X.500 standarda u cilju podrke otvorenim i standardizovanim direktorijumskim
servisima. Direktorijum, u X.500 standardnom smislu, predstavlja specijalnu formu
baze podataka koja je dizajnirana da bude posebno pogodna za korienje na
Internet-u i drugim distribuiranim sistemima.
X.500 standard definie dve osnovne komponente direktorijuma:

Direktorijumski sistemski agent (DSA) za upravljanje informacijama u okviru

direktorijuma,
Direktorijumski korisniki agent (DUA) korisnika aplikacija koja omoguuje
korisniki pristup direktorijumskim servisima.

DAP definie protokol komunikacije izmeu DUA i DSA koji omoguuje uspostavu
konekcije izmeu klijentske aplikacije i direktorijuma, preuzimanje informacije iz
direktorijuma i auriranje informacija unutar direktorijuma.
LDAP (Lightweight Directory Access Protocol) pojednostavljuje pristup
direktorijumskim servisima koji su modelovani na bazi X.500 standarda. LDAP ima
sline funkcije kao i DAP ali radi direktno na TCP/IP protokolu.

5.13 Opis procedure generisanja i zatite asimetrinih kljueva

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 sledee:

Potpunu bezbednost tajnih i privatnih kljueva CA,

Da sprei napade spoljanjih zlonamernih korisnika,

91

Da obezbedi redudantnost sistema i obezbeenje operativnosti (kontinuitet

poslovanja) u sluaju 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

kljueva, integritet podataka i konstatnu raspoloivost sistema.
Ove performanse sistema se ostvaruju primenom smart kartica za kontrolu pristupa
vanim resursima sistema, za digitalno potpisivanje i zatitu tajnosti poruka, kao i
primenom hardverskih bezbednosnih modula (HSM Hardware Security Module) za
ostvarivanje bezbednosno najkritinijih aplikacija u sistemu (generisanje privatnog
kljua CA i digitalno potpisivanje sertifikata (izdavanje sertifikata), kao i za
generisanje tajnih simetrinih kljueva).
U tom smislu, tajni kljuevi CA i RA sistema, kao i njihovih operatora, treba da su
zatieni kriptografskim mehanizmima najvieg nivoa. Svi vani podaci korieni od
strane CA i RA se uvaju u bazama podataka, to olakava primenu redudantnih
mehanizama u cilju spreavanja gubitka podataka.
Sve interakcije i razmene podataka izmeu elemenata PKI sistema se digitalno
potpisuju i ifruju u postupku digitalne envelope to osigurava nemogunost pristupa
datoj komunikaciji od strane zlonamernih korisnika.
Obeleja koja bi trebalo da su podrana od strane konkretnog CA sistema:

CA sistem treba da podri korienje hardverskog bezbednosnog modula

(HSM) za generisanje tajnog kljua samog CA, za bezbedno skladitenje
podataka i za digitalno potpisivanje sertifikata.
Sistem treba da podri korienje smart kartica za bezbedno uvanje
podataka, kontrolu pristupa i generisanje/distribuciju kljueva i sertifikata na
svim kljunim takama datog PKI sistema.
Korienje standardnih poruka (u standardnom formatu) digitalno potpisane i
ifrovane (digitalna envelopa) za svu komunikaciju izmeu pojedinih
elemenata i modula PKI sistema.
Svaki pristup bazama podataka treba da ima jedinstveni procesni broj.
CA sistem treba da ima mogunost da bezbedno arhivira korisnike parove
asimetrinih kljueva za ifrovanje u proceduri digitalne envelope u cilju
omoguenja njihovog naknadnog oporavka u sluaju da je potrebno
deifrovati podatke koji su ifrovani pomou ovih kljueva.
Potrebno je da dati PKI sistem proe odreenu zvaninu sertifikaciju od strane
ovlaenih laboratorija za tu svrhu u smislu sposobnosti za realizaciju
aktivnosti za koje je dati sistem namenjen.

Kao to je ve reeno, bezbednost PKI sistema je odreena bezbednou pre svega

privatnog kljua CA, ali i svih ostalih tajnih kljueva koji se koriste u sistemu. Ovaj
nivo bezbednosti se moe ostvariti samo uz korienje odgovarajueg kriptografskog
hardvera kako na strani korisnika sistema, tako i na strani samih kljunih elemenata
u sistemu.

92

U tom smislu, potrebno je koristiti smart kartice, kao kriptografski hardver prilagoen
korienju za krajnje korisnike i za operatere u okviru PKI sistema, i hardverske
kriptografske module (HSM), neophodne za korienje u serverskim aplikacijama i u
samom CA sistemu.
U sistemima u kojima se zahteva najvii nivo bezbednosti, HSM moduli se predviaju
za korienje i na nivou RAO i CAO operatora. U cilju obezbeenja funkcije
neporecivosti u sistemu, potrebno je da krajnji korisnici svoj asimetrini par kljueva
generiu i uvaju na kriptografskom hardveru (smart kartici).
Drugim reima, fundamentalni zahtev i svrha kriptografskog hardvera je da osigura
da privatni klju nikad ne napusti hardverski modul, u kom sluaju bi eventualno
mogao biti kompromitovan.
5.13.1 Opta obeleja HSM
Hardverski bezbednosni moduli, realizovani u vidu raunarskih koprocesora,
predstavljaju veoma bitnu karakteristiku savremenih reenja zatite raunarskih
mrea. Ovi moduli poveavaju performanse sistema tako to se vremenski kritine
kriptografske funkcije izvravaju na specijalizovanom hardveru a ne u softveru host
raunara.
Postojanje hardverskog koprocesorskog kriptografskog modula od sutinske je
vanosti za realizaciju kvalitetnog i performantnog sistema zatite, kao i za ispunjenje
koncepta poverljive aplikacije u punom smislu.
Svi bezbednosni mehanizmi (kriptografski algoritmi i funkcije kontrole pristupa)
smeteni su na hardverskom modulu i nikada se ne uitavaju u radnu memoriju
korisnikovog raunara.
Osnovne funkcije navedenih proizvoda su poveanje bezbednosti sistema i
ubrzavanje kriptografskih funkcija, kao to su asimetrini i simetrini kriptografski
algoritmi.
Primena HSM modula je neophodan uslov za bezbednu realizaciju funkcija
Sertifikacionog tela.
HSM ureaji uglavnom realizuju standardne javne asimetrine i simetrine
kriptografske i hash algoritme, kao to su: RSA, DSA, DES, 3-DES, RC2, RC4, SHA1, MD2, MD5, itd.
Postoje eksterni kriptografski moduli, koji mogu imati bolje performanse u smislu
brzine i zatite velike koliine podataka. Interni kriptografski moduli su optimalni u
sluaju kriptografskih sistema koji koriste princip rada sa porukama i primenjuju
tehnologije digitalnog potpisa.
Hardverski kriptografski koprocesori se predviaju za korienje u serverskim
aplikacijama i eventualno u klijentskim aplikacijama gde se zahteva visok nivo
bezbednosti (dravni organi, vojska, policija, SMIP, specijalizovane slube).

93

Sa druge strane, za najiri vid korienja sistema zatite (npr. pojedinci), korienje
smart kartica kao poverljive hardverske platforme je primerenije. U stvari, svi ti
sistemi sa povienim nivoom bezbednosti predstavljaju uglavnom kombinovane
softversko-hardverske sisteme, pri emu je hardverski deo ili koprocesor ili smart
kartica.
Sistemi sa najviim 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 kljueva i
digitalnih certifikata.
Postoje i domai HSM moduli. Uproena blok ema jednog domaeg HSM modula
je prikazana na slici 5.3.

Slika 5.3: Pojednostavljeni blok dijagram jednog domaeg prototipa hardverskog

koprocesorskog modula
HSM moduli u okviru sertifikacionih tela imaju sledeu funkcionalnost:

Generisanje kljueva na HSM generisanje para kljueva asimetrinog

kriptografskog algoritma, kao i zahtevanog broja simetrinih kljueva
(opciono), realizuje se unutar HSM.
Bezbedno uvanje kriptografskih parametara kljuevi i ostali kriptografski
parametri se bezbedno uvaju (u ifrovanom obliku) na HSM modulu.

94

Bezbedni back-up kriptografskog materijala kljuevi i drugi kriptografski

parametri se mogu bezbedno sauvati (back-up-ovati) na smart karticama ili
drugim HSM modulima.
HSM mora realizovati funkciju detekcije pokuaja zlonamernog pristupa
modulu (tamperproof) modul treba da obezbedi detekciju zlonamernog
pristupa i unitenje 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 kljueva, kao i realizaciju simetrinih i asimetrinih kriptografskih
algoritama mnogo efikasnije nego u softveru ili na smart karticama.
Bezbedno korienje PIN broja modul se aktivira unoenjem PIN broja.

5.13.2 Opta obeleja smart kartica

Smart kartice nude znaajno vii nivo bezbednosti u odnosu na samo softverska
reenja za realizaciju funkcija:

bilateralne autentikacije,
digitalnog potpisa,
bezbednog uvanja tajnih podataka i
logovanja na sistem.

S obzirom da poseduju memoriju koja je mikroprocesorski zatiena od

neautorizovanog pristupa, skladitenje osetljivih informacija kao to su kriptografski
kljuevi, digitalni sertifikati, lozinke i druge forme linih informacija na smart karticama
je znaajno bezbednije nego na drugim medijumima (kao na primer disketama i li mini
CD medijumima).
Smart kartice takoe mogu realizovati asimetrine kriptografske algoritme za primenu
digitalnog potpisa, kao i komercijalne simetrine algoritme. Iskustva iz savremenih
Internet mrea pokazala su da su smart kartice neuporedivo bezbednije od
softverskih sistema baziranih na standardnim lozinkama.
U savremenim raunarskim mreama predlau se smart kartice za:

generisanje digitalnog potpisa,

generisanje asimetrinih kljueva,
za bezbednu identifikaciju subjekata i
kao portabilni nosioci javnih i tajnih kriptografskih parametara.

Kartica sadri javno dostupni deo i PIN (Personal Identification Number) kodom
zatieni deo memorije u kojima se smetaju kriptografski parametri.
Postoji nekoliko vrsta smart kartica:

95

Memorijske kartice,
Mikroprocesorske smart kartice sa korienje PIN koda za pristup,
Mikroprocesorske smart kartice sa PKI mogunostima (generisanje i uvanje
asimetrinih kljueva, digitalno potpisivanje).

to se tie tipa mikroprocesora implementiranih na smart karticama, ranije su to

preteno bili 8-bitni mikrokontroleri, i to najee iz klase Intel 80C51
mikrokontrolera, a sada su to 16-bitni i 32-bitni mikrokontroleri.
Jedan primer logike arhitekture mikrokontrolera smart kartice koja ima PKI
mogunosti 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.

VSS

VDD

CLK

Power-On/Of
Reset

Clock
Input Filter

RAM

Crypto
coprocessor

Triple DES
coprocessor

EEPROM

Security
Sensors

Phase Driver

Data
Memory

FameX

DES-3

Data &
Program
Memory

Reset
Generator

True Random
Number Generator

80C51
CPU
Timers

Interrupt
System

16 bit
T0

16 bit
T1

I/O

ROM

Program
Memory

Programmable
I/O
ISO - UART

RST
I/O1

I/O2

Slika 5.4: Primer arhitekture ipa mikroprocesorske smart kartice sa PKI

mogunostima Phillips P8WE50xx familija kripto kontrolera
Ovi ipovi po pravilu poseduju dodatne kripto koprocesore za realizaciju asimetrinih
kriptografskih algoritama digitalno potpisivanje (na primer FameX kripto ip, kao
najee korieni kriptokontroler za realizaciju asimetrinih kriptografskih algoritama
u smart karticama) i za realizaciju simetrinih algoritama (DES-3 kripto koprocesor)
za realizaciju zatiene razmene podataka (secure messaging) izmeu smart kartice
i odgovarajueg softvera na raunaru (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:

96

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,
mogunost rada na jednostavnijim mikroprocesorima (8-bitnim),
male mogunosti prilagoenja (kastomizacije) implementiranih funkcija na
smart kartici i
ove kartice su uglavnom jednoaplikativne kartice.

Sa druge strane, Multos i JAVA kartice nude veu mogunost kastomizacije

zahvaljujui postojanju Multos i JAVA virtualnih maina koja izvravaju na samoj
kartici Multos ALU-ove (Application Load Unit) i JAVA aplete definisane od strane
korisnika.
Meutim, s obzirom da su se pojavile u skorije vreme, Multos i JAVA kartice mogu biti
skuplje od obinih kartica i bolje rade na ipovima koji se baziraju na jaim
mikroprocesorima (16-bitni i 32-bitni).
Multos i JAVA kartice su multiaplikativne kartice.
U smart kartinoj industriji postoji nekoliko grupa uesnika:

proizvoai ipova,
proizvoai operativnih sistema i aplikacija,
proizvoai-integratori kompletne kartice (ip, plastika, implementacija ipa,
ugradnja operativnog sistema) i i
sporuioci kompletnih sistema za masovnu produkciju i personalizaciju
(vizuelnu i logiku) smart kartica.

Neke kompanije su osposobljene za realizaciju vie 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
proizvoai ipova, dok su: Gemalto, Oberthur, Giesecke & Devrient, Sagem-Orga,
AustriaCard, itd. proizvoai 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
kriptozatiene aplikacije (kontaktni ip), da se koriste i za kontrolu pristupa u
odreene prostorije u organizaciji, itd. (beskontaktni ip), tj. kao Corporate ID kartice
koje bi sluile kao identifikacione kartice, kao i ureaji za logiku i fiziku 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 sledeu funkcionalnost i obeleja:

97

Generisanje kljueva na smart kartici generisanje para kljueva asimetrinog

kriptografskog algoritma realizuje se unutar smart kartice.
Bezbedno uvanje kriptografskih parametara kljuevi se bezbedno uvaju u
zatienom delu memorije smart kartice i ne postoji mogunost da asimetrini
klju generisan na kartici bude iitan sa kartice.
Generisanje digitalnog potpisa na samoj kartici,
Smart kartice su same po sebi tamperproof moduli (ne moe se neovlaeno
iitati sadraj smart kartica, tj. PIN kodom zatiene memorije).

Kod primene smart kartica, neophodno je posedovati sledee:

smart karticu sa ipom koji omoguava primenu asimetrinih kriptoalgoritama

(na primer RSA RSA koprocesor u samom ipu smart kartice),
instaliranu PKI aplikaciju na samoj smart kartici koja prihvata vei broj parova
asimetrini privatni klju sertifikat (ova aplikacija obino automatski dolazi sa
smart karticom),
ita smart kartica koji ima instaliran odgovarajui drajver na raunaru,
middleware softver koji obezbeuje proizvoa operativnog sistema smart
kartica (moe biti od samog proizvoaa ili od neke tree strane koja je
angaovana od strane proizvoaa) koji se sastoji, izmeu 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 slui za administraciju kartice (pregled
sadraja 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 asimetrinog para kljueva koji je izgenerisan na samoj
smart kartici korisnika, neophodno je na svakoj radnoj stanici u sistemu instalirati
ita smart kartica i odgovarajui middleware za datu karticu koja.

5.14 Server za arhiviranje kljueva

PKI sistem treba da bude sposoban da se oporavi u smislu pune funkcionalnosti u
sluaju sistemskih ili komunikacionih oteenja koja se mogu desiti u korienju.
Dakle, potrebno je da sistem ima realizovanu strategiju oporavka i neometanog
daljeg rada u sluaju oteenja prouzrokovanog viom silom.
Uglavnom su dva osnovna kritina elementa PKI sistema: privatni i tajni kljuevi, 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:

98

Za uvanje svih zahteva za izdavanje sertifikata, izdatih sertifikata i CRL,

Kao baza za razmenu poruka izmeu 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 ukljuene u sertifikate (kao na
primer atributi definisani od strane samih korisnika, skenirane fotografije,
biometriki podaci, itd.), ...

Bezbednost itavog sistema je ojaana tako to je svaki unos u bazu, ili postupak
itanja, digitalno potpisan uz pomo privatnog kljua odreenog procesa ili operatora
koji je datu transakciju uradio. Pored toga, svaki zahtev za izdavanje sertifikata
poseduje pridrueni identifikacioni broj transakcije, koji se koristi tokom procesiranja
datog zahteva u datom PKI sistemu.
Korienje postupka digitalne envelope znai da ifrovanu informaciju moe proitati
samo korisnik kome je ta informacija namenjena.
Svaka organizacija koja svoju bezbednost bazira na PKI sistemu eli da bude
sposobna i da moe naknadno, u izuzetnim sluajevima, da deifruje neke podatke.
U tom smislu, ne sme se dopustiti da privatni asimetrini kljuevi, kojima se jedino
mogu deifrovati simetrini kljuevi, kojima su ifrovane odreene poruke, izgube jer
su tada izgubljene i te ifrovane poruke. Ovaj zahtev povlai za sobom sledee:

Vanim podacima firme, koji su ifrovani i namenjeni nekom slubeniku, ne

moe se pristupiti ukoliko dati slubenik u tom trenutku nije prisutan,
Podaci se ne mogu deifrovati ako je tajni klju izgubljen ili oteen,
Podaci se ne mogu deifrovati ako je lozinka zaboravljena,
Krajnji korisnici mogu biti onda demotivisani (ili u strahu) da ifruju vane
podatke plaei se da ti podaci kasnije nee moi biti deifrovani.

Navedeni problemi se mogu razreiti ako bi se kopije tajnih kljueva uvale na

bezbednom mestu. To bi omoguilo oporavak u svakom trenutku ifrovanih podataka.
Meutim, to bi takoe omoguilo verovatnou pronevere digitalnih potpisa od strane
zlonamerne osobe koja ima pristup bazi tajnih kljueva. To je neprihvatljivo sa
stanovita postizanja funkcije neporecivosti u sistemu.
Ovi problemi se na zadovoljavajui nain mogu reiti tako to se u sistemu omogui
korisnicima da imaju vie parova asimetrinih kljueva, a posledino i vie sertifikata
(po jedan sertifikat na svaki par kljueva). Jedan par kljueva treba da bude za
ifrovanje, a drugi za digitalno potpisivanje.
Najprihvatljivija ema sa svih aspekata je da par kljueva za digitalno potpisivanje
generie sam korisnik, po mogustvu na kriptografskom hardveru (smart kartici) koji
obezbeuje funkciju neporecivosti, a da par kljueva za ifrovanje (digitalnu
envelopu) generie CA za datog korisnika i da mu ih dostavlja. U tom sluaju, CA
moe uvati kopiju privatnog kljua za ifrovanje na serveru za arhiviranje podataka,

99

to omoguuje potpun oporavak ifrovanih podataka (ukoliko na primer korisnik

izgubi smart karticu), bez uticaja na funkciju neporecivosti datog korisnika.
Server za arhiviranje kljueva (Arhiv Server (AS)) ima funkciju da bezbedno
uskladiti privatne kljueve asimetrinog kriptografskog sistema krajnjih korisnika koji
se primenjuju u okviru postupka digitalne envelope. Ova funkcija omoguuje kasniji
oporavak datih kljueva, kao i eventualnog deifrovanja ifrovanih poruka
(postupkom digitalne envelope), u sluajevima gubitka ili oteenja kljueva, ili u
sluajevima kada odreeni autoritet nalae deifrovanje poruka (u sudskim ili
arbitranim procesima, itd.).
Kljuevi se uvaju na serveru za arhiviranje kljueva jedino u sluaju da je to izriito
predvieno politikom rada PKI sistema.

5.14.1 Funkcionalnost servera za arhiviranje kljueva

Server za arhiviranje kljueva ifruje privatni klju koga treba uskladititi

primenom odreenog simetrinog algoritma sa odgovarajuim DEK (Data
Encipherement Key) kljuem, jedinstvenim za svaki privatni klju koji se
arhivira. Tako ifrovani privatni klju se smeta u posebnu bazu podataka (AS
baza podataka).
DEK klju se takoe ifruje posebnim simetrinim algoritmom i posebnim
kljuem i takoe se smeta 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 autentinosti
potpisnika i integriteta sadraja 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 Obeleja Arhiv servera

Poseduje grafiki interfejs jednostavan za korienje sa interfejsom koji se

moe prilagoditi korisnikovim potrebama.
Arhiv server treba da podri razliite 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,

100

Formata sertifikata,
Formata lista opozvanih sertifikata,
Formata poruka pri registraciji (zahtevi i odobrenja izdavanja sertifikata),
Formata digitalnih sertifikata,
Autentikacionih protokola.

Najvanije telo zadueno 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

Oteprihvaeni i najvie korien standard koji podrava PKI sisteme je ITU-T X.509
ija osnovna svrha je u definisanju standardnog formata digitalnih sertifikata. Verzija
3 ovog standarda koja je trenutno vaea, usvojena je 1996. godine. Meutim, ovaj
standard nije namenjen za definisanje kompletnih funkcija PKI sistema.
Standardom X509 definisana je struktura, postupak dobijanja i nain predstavljanja
sertifikata. Struktura sertifikata opisuje se korienjem 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
meusobno povezivanje raunarskih sistema i to od osnovnog, fizikog nivoa, do
aplikativnog nivoa. Da bi standard bio nezavistan od implementacionih karakteristika
pojedinanih sistema objekti se opisuju na apstraktan nain, kroz podatke koje
sadre, servise koje pruaju i komunikacione interfejse prema spoljanjoj 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
nain 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.

101

Tipovi i njihove vrednosti mogu se imenovati i ta se imena mogu koristiti u definisanju

drugih tipova i vrednosti. Operator dodeljivanja se oznaava sa :: . Svaki ASN.1 tip
(osim CHOICE i ANY) odreen je pripadnou klasi i jednim nenegativnim brojem.
Postoje etiri klase:

Univerzalna, za tipove ije je znaenje isto nezavisno od aplikacije,

Aplikativna, za tipove kod kojih je znaenje definisano unutar aplikacije,
Privatne za tipove ije znaenje je vezano za lokalno okruenje,
Konteksno-zavisna za tipove ije je znaenje specifino u okviru strukturnih
tipova.

Dva tipa se smatraju jednakim ako i samo ako pripadaju istoj klasi i imaju isti broj.
Ovim mehanizmom se moe opisati svaki apstraktni tip podataka.
Sledee pitanje adresirano ovim standardom je nain predstavljanja vrednosti
apstraktno definisanog tipa. To pitanje se razreava formulisanjem osnovnih pravila
za kodiranje, Basic Encoding Rules (BER), kojima se svaka ASN.1 vrednost
predstavlja kao niz bajtova. Ovaj, osnovni nain kodiranja, nije jednoznaan tj. ista
vrednost se moe kodirati na vie razliitih naina. Naini kodiranja su sledei:

Primitivni - sa unapred poznatom duinom podatka,

Konstruktivni - sa unapred poznatom duinom podatka,
Konstruktivni - sa nepoznatom duinom podatka.

Kod vrednosti nekog tipa sastoji se od najmanje prva tri bloka, od sledea etiri:

Identifikacioni deo - kojim se jednoznano odreuje tip podatka (klasa i broj),

metod kodiranja (primitivni ili kostruktivni),
Specifikacija duine podatka - kojom se kod podataka sa odreenom duinom
specificira broj bajtova za registrovanje podatka ili, ako duina nije unapred
poznata, sadri kod kojim se ta situacija identifikuje,
Sadraj - niz bajtova kojim se reprezentuje vrednost,
Oznaka za kraj podatka - ukoliko nije unapred poznate duine.

Napomenuli smo ranije da BER kodiranje nije jednoznano to moe izazivati

probleme u situacijama kada je jednoznanost zahtevana osobina. Zbog toga je
formulisan niz ogranienja na pravila BER kodiranja tako da se postigne
jednoznanost u kodiranju vrednosti nekog ASN.1 tipa.
Taj restriktivni skup pravila se oznaava sa DER (Distinguished Encoding Rules).
Grubo govorei, jednoznanost se postie zahtevajui da kod vrednosti bude
minimalan u pogledu duine (broja bajtova).
Dakle, ovim sistemom smo u mogunosti da opiemo i predstavimo vrednost
proizvoljnog apstraktnog tipa.
5.15.2 ITU X.509 v3 sertifikat-struktura

102

Prema ovom standardu sertifikat se sastoji od tri dela. Prvi deo ine podaci znaajni
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 sadri sledea polja:

Verzija oznaava verziju standarda koja je primenjena pri generisanju

sertifikata,
Serijski broj redni broj izdatog sertifikata. Nain dodeljivanja brojeva mora
biti jedinstven tj. ime izdavaa sertifikata i redni broj sertifikata jedinstveno
odreuju sertifikat,
Potpis sadri identifikator algoritma kojim izdava sertifikata vri potpis
sertifikata,
Validnost specificira se period unutar kojeg se sertifikat smatra vaeim ako
nije opozvan,
Vlasnik sertifikata identifikator (ime) vlasnika sertifikata kome se pridruuje
javni klju koji sadri sertifikat,
Javni klju javni klju vlasnika sertifikata i identifikator algoritma za koji je
namenjen,
Jedinstveni identifikatori polje koje omoguava ponovnu upotrebu imena
prisutnih u sertifikatu,
Polje dodatnih informacija sadri 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 naie na informaciju oznaenu sa CRITICAL i ne raspozna je,
mora sertifikat odbaciti kao neispravan.

Polje dodatnih informacija moe sadrati informacije pomou kojih se identifikuje

javni klju kojim se sertifikat proverava, ukoliko izdava ima vie parova javnih i
privatnih kljueva. Zatim informacije o nameni javnog kljua koji sertifikat sadri, opis
uslova pod kojima je sertifikat dobijen i pod kojim se i zata moe koristiti,
alternativna imena izdavaa i vlasnika sertifikata.
Prema dosadanjim 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 sadri sledea polja:

103

Verzija oznaava verziju standarda koja je primenjena pri generisanju liste

opozvanih sertifikata,
Potpis sadri identifikator algoritma kojim izdava liste opozvanih sertifikata
vri potpis liste opozvanih sertifikata,
Ime izdavaa liste identifikuje izdavaa liste,
Datum izdavanja tekue liste opozvanih sertifikata,
Datum sledeeg auriranja liste opozvanih sertifikata,
Spisak opozvanih sertifikata,
Polje dodatnih informacija.

Spisak opozvanih sertifikata se sastoji od niza rednih brojeva sertifikata koji zajedno
sa identifikatorom izdavaa sertifikata na jedinstven nain odreuju 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 korienjem dogovorenih algoritama formira otisak i potpis
liste opozvanih sertifikata.
U cilju dodatne standardizacione podrke X.509 standardu, proizvoai, korisnici i
komiteti za standarde su se uglavnom okrenuli korienju 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, najvanija su sledea etiri PKCS standarda:

PKCS#1 standard za opis realizacije procedura digitalnog potpisivanja i

digitalne envelope na bazi RSA asimetrinog 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 linih informacija (Personal
Information Exchange Syntax Standard).

5.16 Tipovi Sertifikacionih tela i mogui naini realizacije

Postoji nekoliko tipova CA, od kojih su etiri tipa najznaajnija:

Pojedinana CA odreenih preduzea (corporate CA),

CA zatvorenih grupa korisnika,
CA vertikalnih industrija (finansijski sistemi, medicina, telekom, ...),

104

Javna CA (domaa internacionalna).

to se tie naina realizacije CA, postoje generalno tri naina:

Korienje usluga postojeeg 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 domae CA
tehnologije (insourced CA).

Prva varijanta predstavlja najpovoljnije reenje za kompaniju koja eli da

implementira PKI tehnologiju iskljuivo u svojoj organizaciji (za svoje zaposlene i
saradnike) a ne eli da investira previe u reenje CA. U tom smislu, odreene
organizacije koje predstavljaju javna meunarodna CA (kao to su GlobalSign i
VeriSign) nude outsourced CA reenje u kome oni praktino izdaju digitalne
sertifikate korisnicima date organizacije, koja u tom sluaju igra ulogu RA.
Meutim, ukoliko organizacija pretenduje da ima odreene ekonomske koristi od
javne prodaje digitalnih sertifikata zainteresovanim korisnicima iz njihovog domena,
tada su prikladnije druge dve varijante realizacije CA. To reenje je onda znaajno
skuplje od prvo pomenutog reenja outsourced CA.
Od dve navedene insourced varijante, varijanta koja podrazumeva stranu CA
tehnologiju je sigurno skuplja nego varijanta sa domaom tehnologijom. Sa druge
strane, realizacija CA sa domaom tehnologijom omoguuje adaptivnost i
skalabilnost reenja u skladu sa definisanom politikom korisnika.

5.17 Generiki model realizacije CA kao softverskog-hardverskog

sistema za generisanje digitalnih sertifikata
Kao to je ranije vie puta reeno, u okviru realizacije kompletnog PKI sistema,
kljuna je realizacija softversko-hardverskog sistema CA za generisanje digitalnih
sertifikata i odgovarajuih kriptografskih kljueva.
Osnovne karakteristike jednog mogueg sistema (generiki model) za generisanje
digitalnih sertifikata i odgovarajuih kljueva su:

Realizovan u skladu sa vaeim 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 kljueva i primene kriptografskih algoritama.

105

Kao jedan primer centralnog sistemskog okruenja CA, naveemo uproenu blok
emu prikazanu na slici 5.4, kao primer CA koje predstavlja vieslojnu WEB
aplikaciju.

Slika 5.4: Uproena 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 sluajevima kada se
formira asimetrini 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 kljua Root CA koji se
propisanom procedurom distribuirane odgovornosti koriste u sluajevima generisanja
novog Intermediate sertifikacionog tela (ta procedura se naziva CA ceremonija).
U proceduri CA ceremonije, potrebno je da prisustvuje odgovarajui minimalan broj
specijalnih slubenika CA koji imaju pristup pojedinim delovima za aktivaciju
privatnog kljua, koji se uvaju u posebnim pretincima u trezoru i to najee u obliku
smart kartica.
Dakle, odgovarajui broj smart kartica mora biti prisutno da bi se u HSM ureaju
Root CA mogao aktivirati privatni klju Root CA u skladu sa Praktinim pravilima rada
sertifikacionog tela.

106

Slika 5.5: Hijerarhijska struktura sertifikacionih tela

Nakon toga se u HSM ureaju izvri generisanje asimetrinog para kljueva za novi
Intermediate CA i izgenerie se njegov sertifikat primenom digitalnog potpisa na bazi
privatnog kljua Root CA. Tako dobijenim privatnim kljuem i sertifikatom
isprogramira se najee smart kartica Intermediate CA koja se zatim postavi u HSM
ureaj novog, posebno za taj Intermediate CA obezbeenog, Crypto Engine servera.
Alternativno reenje je da se asimetrini par kljueva intermediate CA izgenerie u
okviru HSM ureaja a zatim se javni klju u obliku PKCS#10 zahteva za izdavanjem
sertifikata runo prenese na root CA konzolu gde se izgenerie sertifikat koji se zatim
vrati i dowload-uje na HSM ureaj intermediate CA.
Zatim se obrie privatni klju Root CA iz HSM ureaja i specijalne smart kartice sa
delovima za aktivaciju privatnog kljua se vrate u trezor.
Dakle, kao to se moe zakljuiti, mogue je da istovremeno rade vie Intermediate
CA u OnLine modu rada, tj. da vie Intermediate CA Crypto Engine servera bude
aktivirano u OnLine rad generisanja digitalnih sertifikata.
OnLine procedura se odvija na sledei nain. Zahtevi za izdavanjem sertifikata iji je
digitalni potpis uspeno 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 odgovarajueg RAO u okviru RA
gde je korisnik fiziki doao da mu se izda sertifikat) se od strane aplikativnog
servera CA upuuju do odgovarajueg Intermediate CA Crypto Engine servera iz kog
domena je dati korisnik.
Na datom Crypto Engine serveru (u okviru HSM ureaja datog servera) izvri se
formiranje digitalnog sertifikata (u sluaju samopotpisanog zahteva) ili se izvri
generisanje asimetrinog para kljueva i formiranje digitalnog sertifikata za datog
korisnika. Ovi podaci se vraaju aplikativnom serveru koji ih smeta u bazu podataka
CA i alje ih na odgovarajui nain direktno korisniku ili u RA gde je korisnik podneo
zahtev.

107

U DMZ zoni sistema CA se, pored WEB servera CA, nalazi i LDAP server koji slui
za publikovanje CRL i ARL lista, kao i eventualno za publikaciju izdatih digitalnih
sertifikata.
Potrebno je istai da navedeni primer realizacije sistema CA predstavlja samo jedan
mogui nain realizacije i da se realne realizacije sistema vie ili manje razlikuju u
domenima naina generisanja kljueva za korisnike, nainu distribucije kljueva i
sertifikata, kao i u nainu publikacije CRL liste. Meutim, 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 taku najvieg
poverenja, ali istovremeno i taku najvieg rizika. Osnovni i najvaniji zahtev koji se
postavlja pred CA je uvanje tajnosti privatnog kljua CA za primenu asimetrinog
kriptografskog algoritma kojim se vri digitalni potpis izdatih digitalnih sertifikata, i
uvanje tajnosti ostalih kriptografskih kljueva koji se dodeljuju ovlaenim
uesnicima u informacionom sistemu.
Stoga se, pored kriptografskih tehnika, moraju primeniti i druge mere iz oblasti fizike
i organizacione zatite kako bi se ostvarila sveukupna bezbednost PKI sistema.
Pomenute mere se odnose na prostorije, zaposlena lica i ureaje.
5.18.1 Bezbednosne procedure u odnosu na ljudski faktor
Ovlaena lica CA odgovorna su za uspostavu i kontrolu funckionisanja celokupnog
PKI sistema. U njihovoj odgovornosti je formiranje digitalnih sertifikata, sprovoenje
svih procedura rad u CA i RA propisanih u okviru politike sertifikacije CA, kao i
politike zatite celokupnog informacionog sistema.
Prilikom izbora kadra koji e biti zaposlen na poslovima iz nadlenosti CA, moraju se
sprovesti odgovarajue bezbednosne provere, imajui u vidu potencijalnu tetu koju
nesavesna lica mogu da naprave. Slini zahtevi, u blaoj formi, treba da budu
primenjeni za lica iz sastava RA, kao i na administratore zatite. Najvii bezbednosni
zahtevi postavljaju se pred slubenike koji se bave proizvodnjom kljueva i
generisanjem digitalnih sertifikata, kao i personalizacijom smart kartica.
Kao to je ve reeno, privatni klju CA za primenu asimetrinog kriptografskog
algoritma kojim se vri digitalni potpis izdatih digitalnih sertifikata predstavlja podatak
najvieg stepena tajnosti. Korienje ovog kljua ne sme biti u nadlenosti samo
jedne osobe, ve se mora primeniti princip raspodele odgovornosti na minimalno dva
ovlaena lica. Ova lica poseduju specijalne smart kartice na kojima se nalaze delovi
pomenutog tajnog kljua. Po principu raspodele odgovornosti, validan digitalni
sertifikat se moe izdati tek ako se od tajnih podataka sa obe kartice formira potpuni
podatak za aktivaciju privatnog kljua CA za primenu digitalnog potpisa.

108

U svakom sluaju, u okviru informacionog sistema u koga treba ugraditi jake

mehanizme zatite treba formirati organizacionu celinu koja e se baviti realizacijom
poslova iz nadlenosti CA. Ova organizaciona celina moe biti posebna
organizaciona jedinica, ili poslovati kao organizacioni deo ire organizacione jedinice
koja je zaduena za itav sistem zatite.
5.18.1.1 Organizacija poslovnih uloga
Neodgovarajua organizacija poslovnih uloga ili funkcija u CA moe biti uzrok
bezbednosnih problema bilo da su izazvani sluajno ili sa namerom. Ljudi odabrani
da obavljaju poslovne uloge moraju biti izvanredno odgovorni ili se u suprotnom
sluaju dovodi do slabljenja integriteta CA.
Dva principa se koriste da bi poveali verovatnou uspenog obavljanja poslovnih
uloga. Prvi je poverljivost i dobra obuenost zaposlenih, a drugi je podela poslovnih
funkcija na vie od jedne osobe, tako da bilo koja maliciozna aktivnost zahteva
dogovor bar dve osobe.
Na poslovima CA moemo uoiti etiri eventualne poslovne uloge: administrator,
referent, nadzornik i operater.
Administrator treba da obavlja sledee poslove:

Instalacija, konfiguracija i odravanje CA,

Kreira i odrava sistemski CA nalog,
Konfigurie profile sertifikata i parametre sistema provere (audit),
Generie i organizuje uvanje kriptografskih klueva 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 tanost podataka u sertifikatu,
Izvrava generisanje sertifikata,
Obrauje zahtev za opoziv sertifikata.

Nadzornik pregleda, odrava i arhivira audit logove i proverava usklaenost

tekuih procesa sa CPS.
Operator je zaduen 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 razliito se implementira u zavisnosti od nivoa
pouzdanosti koji moe biti testni, rudimentarni, osnovni, srednji ili visoki.

109

U osnovnom nivou pouzdanosti postoje etiri poslovne uloge. Pojedinac moe imati
vie uloga, ali ne istovremenu ulogu administratora i referenta. Potrebne su bar dve
osobe.
I u srednjem nivou pouzdanosti imamo etiri uloge. Ogranienje je da referent ne
moe 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 dravljanin zemlje u kojoj CA
radi. Zahtevi za izbor zaposlenih koji rade, upravljaju, nadziru ili kontroliu rad CA
obino je definisan u CPS.
5.18.1.4 Obuka zaposlenih
Svi zaposleni koji obavlju poverljive poslove uloge treba da imaju redovne
odgovarajue kurseve i obuke iz sledeih oblasti:

CA/RA bezbednosni principi i mehanizmi,

Sve PKI softverske verzije u upotrebi u CA,
Sve PKI dunosti koje obavlja ili moe da obavlja,
Procedure oporavka sistema usled vanrednih dogaaja ili elementarnih
nepogoda i nastavak rada.

Zaposlenima treba organizovati obuku u sluaju zanavljanja softvera, hardvera,

izmetanja ili relociranja poslovnog sistema.
Zaposlene treba upoznati sa optim aktima CA kao to je politika sertifikacije, CPS,
statuti ili relevantni ugovori
5.18.1.5 Sankcije za neovlaene aktivnosti
Zaposleni treba da budu svesni sankcija za sluaj izvoenja neovlaenih aktivnosti
kao to je raskid radnog odnosa i zapis u radnoj biografiji.
5.18.2 Bezbednosne procedure u odnosu na prostorije i ureaje
Poslovi generisanja kljueva, formiranja digitalnih sertifikata, personalizacije smart
kartica, kao i auriranje lista izdatih i povuenih sertifikata, moraju se izvravati u
specijalnim prostorijama koje su izdvojene za tu namenu.
Potrebno je obezbediti organizacione i tehnike preduslove kako bi samo ovlaena
lica imala pristup ovim prostorijama. Pri tome se moraju koristiti tehnike metode

110

zatite prostora i kontrole fizikog pristupa kako bi se vodila automatizovana

evidencija o boravku ljudstva u tim prostorijama.
Ureaji na kojima se proizvode kriptografski kljuevi i formiraju digitalni sertifikati
moraju biti namenjeni iskljuivo za tu vrstu poslova. Rukovanje tim ureajima
ogranieno je na ovlaene slubenike primenom prethodno navedenih tehnikih
mera zatite.
Aktivnosti koje se vre na ureajima 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 vriti na medijumima na kojima je
obezbeena minimalna trajnost zapisa od 10 godina. Sve tajne informacije koje se
generiu u okviru CA tite se kriptografskim tehnikama i tako obraene odlau u
memoriju.
Arhivirani podaci moraju biti smeteni na najmanje dva nezavisna medijuma, back-up
copy, i moraju biti overeni digitalnim potpisom ovlaenih lica CA. Sve pomenute
procedure se obezbeuju korienjem 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 kljueva na bazi sluajnog niza,
digitalnog potpisivanja sertifikata i ifrovanja u okviru CA.
5.18.3 Sistemi fizike i logike kontrole pristupa u okviru Sertifikacionog tela
KI (CA, RA) oprema treba da bude zatiena od neautorizovanog pristupa, a
posebno ona u kojoj je instaliran i aktiviran HSM ureaj. Kontrola fizikog pristupa je
neophodna ak i u sluaju da HSM ureaj trenutno nije u funkciji ili nije instaliran.
Zatitni mehanizmi treba da budu u skladu sa nivoom pretnji PKI radnom okuenju i
nivoom pouzdanosti (assurance) certifikata i dokumenata sa kojima se radi.
5.18.3.1 Lokacija
Lokacija i konstrukcija mesta na kojoj je smeten 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 sluba i primena protivprovalnih senzora
koji treba da obezbede fiziku zatitu od neautorizovanog pristupa CA opremi i
informacijama.
5.18.3.2 Fiziki pristup
Oprema CA mora uvek da bude zatiena od neautorizovanog pristupa, posebno
kada i dok je HSM ureaj instaliran i aktivan. Kontrola fizikog pristupa mora biti
primenjena kako bi bio smanjen rizik od malicioznog pristupa opremi CA ak i ako
HSM ureaj nije trenutno instaliran ili aktivan.

111

Zatitni mehanizmi treba da budu u skladu sa nivoom moguih pretnji i nivoom

pouzdanosti certifikata koje CA izdaje.
Ako CA izdaje certifikate sa osnovnim, srednjim i visokim nivoom pouzdanosti u
skladu sa tim nivoom pouzdanosti treba da budu i mere fizike zatite radnih
prostorija CA.
Za osnovni nivo pouzdanosti certifikata neophodno je:

hardverske komponente CA opreme obezbediti od neovlaenog pristupa,

prenosne memorijske medijume i papire koji sadre poverljive informacije
uvati u bezbednim ormarima.

U koliko se radi o elektronskim certifikatima srednjeg ili visokog nivoa pouzdanosti

neophodno je, dodatno, obezbediti:
stalni fiziki ili elektronski nadzor za sluaj upada,
periodini pregled evidencije pristupa opremi,
istovremeno fiziko prisustvo dve ovlaene osobe kada radi kompjeterski
sistem ili HSM ureaj CA.
U sluaju da se koriste pokretni kriptografski moduli, neophodno ih je deaktivirati pre
skladitenja, a aktivacione podatke uvati u bezbednim ormarima odvojeno od
kriptografskih modula.
U sluaju da se radne prostorije ostavljaju bez stalno zaposlenih neophodno je
propisati listu neophodnih provera koje treba da obavi stalno fiziko obezbedjenje,
kao na primer:

proveriti da je sva oprema ugaena sem sistema koji dri bazu sertifikata i
koja moe biti stalno javno dostupna,
proveriti da su bezbedni ormari dobro zakljuani (zapeaeni),
proveriti brave na vratima, ventilacione cevi i druge otvore,
proveriti sigurnosni sistem protiv upada.

5.18.3.3 Napajanje elektrinom energijom

Napajanje elektrinom energijom mora biti izvedeno tako da je obezbeeno rezervno
napajanje minimalno dovoljno za:

zavretak unosa podataka ili dovretka zapoetog posla,

uvanje trenutnog stanja i
regularnog zaustavljanja raunarskog sistema.

5.18.3.4 uvanje podataka na prenosnim medijuma

Podaci CA moraju biti uvani tako da obezbede zatitu od oteenja u sluaju
vanrednih situacija izazvanih vodom, vatrom ili elektromagnetnim zraenjem.

112

Mediji koji sadre rezervne kopije, arhivske ili evidencione podatke moraju se uvati
na dve fiziki odvojene lokacije od radnih prostorija CA.
5.18.3.5 Rad sa rezervnim kopijama
Za sve CA koje rade na osnovnom ili viem nivou poverenja, mora se obavljati
periodini i puni sistemski backup dovoljan da se sistem oporavi i posle potpunog
pada raunarskog sistema, u skladu sa CPS.
Backup se mora obaviti i sauvati van radnih prostorija CA bar jednom u toku
sedmice. Najmanje jedna potpuna kopija mora biti sauvana na udaljenoj lokaciji. Ta
potpuna kopija mora biti dovoljna da se raunarski sistem potpuno regenerie
(aplikativni softver, baza, sistemski softver, drajveri).
5.19.3.6 Ostalo
Takoe, vrlo vana su pitanja obezbeenja prostorija CA od vanrednih situacija koje
mogu nastati usled nepogoda izazvanih vodom, vatrom ili drugim prirodnim
nepogodama.
Posebno treba regulisati pitanje unitavanja i odlaganja otpadnog materijala kao sto
su papir, filmovi, trake, osteeni medijumi i sl.

5.19 Osnovni dokumenti rada Sertifikacionog tela

Bilo koje bezbednosne mere koje se primenjuju u okviru neke raunarske mree,
koje izmeu ostalog mogu da ukljuuju mrene barijere (firewall), ID kartice ili
kontrolu pristupa do PKI infrastrukture zahtevaju postojanje sveobuhvatne
bezbednosne politike (politika zatite) rada date mree.
Ova politika definie procedure koje omoguuju pristup korporacijskim resursima ili
informacijama, i koje onemoguuju neautorizovanim korisnicima pristup tim
resursima. Ova bezbednosna politika ukljuuje postavku i detaljnu definiciju funkcija
koje treba da realizuju svi elementi PKI infrastrukture datog sistema.
U toj bezbednosnoj politici, posebno mesto treba da zauzimaju specifine procedure,
profili i ogranienja vezana za sertifikate i zahteve za izdavanje sertifikata. Ovaj deo
bezbednosne politike se naziva Politika sertifikacije, koja predstavlja poseban
dokument.
Upravljanje politikom rada odreenog PKI sistema vri sertifikaciono telo. U tom
smislu, sve PKI aplikacije koje koriste softverske i hardverske kriptografske
mehanizme centralno se upravljaju, to redukuje trokove i poveava nivo kontrole.
Sertifikaciono telo pre poetka rada utvruje Opta pravila pruanja usluge
sertifikacije koja korisnicima obezbeuju dovoljno informacija na osnovu kojih se
mogu odluiti o prihvatanju usluga i o obimu usluga.
Pomenuta Opta pravila se sastoje iz dva osnovna dokumenta:

113

Politika sertifikacije (Certificate Policy) i

Praktina pravila pruanja usluge Sertifikacije
Statement) (u daljem tekstu: Praktina pravila).

(Certification

Practices

5.19.1 Politika sertifikacije opti koncept

Politika sertifikacije, tj. politika po kojoj se izdaju sertifikati u datom PKI sistemu, treba
da propie sve procedure koje se odnose na korienje i izdavanje sertifikata. Ova
politika ukljuuje sledee:

Pod kojim uslovima se izdaju sertifikati,

Koje informacije treba da budu ukljuene u sertifikat,
Za koju svrhu se koristi dati sertifikat, i
ta se deava kada istekne vanost sertifikata (kada sertifikat doe do kraja
svog ivotnog veka).

Generisanje politike sertifikacije je veoma veliki i sloen posao koji treba da bude
nedeljivi deo korporacijske bezbednosne politike. Mogui postupak generisanja
politike sertifikacije bi se mogao podeliti na etiri glavna dela:

Odluivanje 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),
Odreivanje koje ekstenzije e se pojaviti u sertifikatima izdatim u skladu sa
ovom politikom,
Odluivanje koje dodatne registracione informacije treba da budu prikupljane u
cilju izdavanja sertifikata. Ove informacije se ne publikuju u sertifikatu, i
Odreivanje dodatnih operacionih ogranienja koja treba da budu sprovedena
u vezi izdavanja i korienja sertifikata.

Sertifikaciono telo je odgovorno za pruanje kompletnih usluga sertifikacije, koje

ukljuuju sledee servise, i to:

Registraciju korisnika,
Formiranje digitalnih sertifikata,
Distribuciju digitalnih sertifikata korisnicima,
Upravljanje procedurom opoziva digitalnih sertifikata i
Obezbeivanje statusa opozvanosti digitalnih sertifikata.

Sertifikaciono telo moe, pored gore navedenih servisa, da obezbedi i:

formiranje asimetrinog para kljueva za korisnike, kao i distribuciju privatnog

kljua i sertifikata korisniku na bezbedan nain,
sredstvo za formiranje kvalifikovanog elektronskog potpisa korisnicima i
pridruenu lozinku (ili PIN kod) za aktivaciju sredstva, kao i njihovu bezbednu

114

distribuciju do korisnika, ako je to u skladu sa svojim Optim i Internim

pravilima rada.
Na slici 5.6 su ilustrativno prikazani servisi koje prua sertifikaciono telo.

Slika 5.6: Ilustracija servisa koje prua sertifikaciono telo

5.19.2 Relativni odnos dokumenata Politika sertifikacije i Praktina pravila rada
Opta 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 Praktina pravila su javni dokumenti i njihov relativni odnos se
zasniva na sledeim principima.
5.19.2.1 Svrha dokumenata
Politika sertifikacije definie predmet rada sertifikacionog tela dok Praktina pravila
definiu procese i nain njihovog korienja pri formiranju i upravljanju kvalifikovanim
elektronskim sertifikatima.

115

Politika sertifikacije definie zahteve poslovanja sertifikacionog tela dok Praktina

pravila definiu operativne procedure u cilju ispunjenja tih zahteva. Praktina pravila
definiu nain na koji sertifikaciono telo ispunjava tehnike, organizacione i
proceduralne zahteve poslovanja koji su identifikovani u Politici sertifikacije.
5.19.2.2 Nivo specifikacije
Politika sertifikacije je manje specifian i detaljan dokument u odnosu na Praktina
pravila koja predstavljaju mnogo detaljniji opis naina 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 niim nivoom optosti (viim nivoom specifinosti operativnih procedura
sertifikacionog tela) koja se nazivaju Interna pravila rada CA o kojima e biti vie rei
kasnije.
U Internim pravilima rada se daje detaljni opis specifinih procedura koje su
neophodne za kompletiranje praktinih procedura identifikovanim u Praktinim
pravilima rada. Interna pravila predstavljaju dokumenta u kojima se definiu interne
operativne procedure koje specificiraju odreene poslove i odgovornosti u okviru
organizacije.
Za razliku od Optih pravila rada, Interna pravila rada predstavljaju poverljiv
dokument sertifikacionog tela i na njih se ne odnose utvrena pravila i obavezan
sadraj koji su navedeni u RFC i ETSI standardizacionim dokumentima.
Na primer, Politika sertifikacije definie zahtev za bezbednim upravljanjem privatnog
kljua sertifikacionog tela, Praktina pravila definiu na primer dualnu kontrolu i
bezbedne procedure uvanja kljueva a Interna pravila opisuju odgovarajuu
proceduru u detalje sa lokacijama, pristupnim listama i procedurama pristupa.
5.19.2.3 Razliiti pristup dokumenata
Politika sertifikacije se definie nezavisno od specifinog operativnog okruenja
sertifikacionog tela, dok Praktina pravila daju detaljan opis organizacione strukture,
operativnih procedura, kao i fiziko i raunarsko okruenje sertifikacionog tela.
tavie, mogue je da u odreenim irim i sveobuhvatnijim PKI sistemima postoji
univerzalna Politika sertifikacije, u smislu zajedniki dogovorenih zahteva koje treba
da ispune sertifikaciona tela. Meutim, Praktina provila rada moraju uvek biti
definisana od strane samog sertifikacionog tela.
5.19.3 Sadraj dokumenata Politika sertifikacije i Praktina pravila rada
Sadraj dokumenta Politika sertifikacije, prema ETSI TS 101 456 Policy
Requirements for Certification Authorities Issuing Qualified Certificates, obuhvata
sledea poglavlja i teme, i to:

116

Opte odredbe o radu sertifikacionog tela

o
o
o
o
o

Uvodne odredbe o Politici izdavanja kvalifikovanih elektronskih sertifikata

Obaveze i odgovornosti
o
o
o
o

Pojam sertifikacionog tela,

Sertifikacione usluge,
Obuhvat dokumenta Politika sertifikacije,
Obuhvat dokumenta Praktina pravila pruanja usluge sertifikacije,
Korisnici usluga sertifikacije.

Obaveze sertifikacionog tela,

Obaveze korisnika,
Odgovornost sertifikacionog tela,
Odgovornost korisnika.

Funkcionalni zahtevi za rad sertifikacionog tela

o Operativna pravila rada sertifikacionog tela
o Procedure upravljanja ivotnim ciklusom kriptografskih kljueva

Generisanje kljua sertifikacionog tela,

Procedure uvanja i formiranja rezervnih kopija kljueva
sertifikacionog tela,
Distribucija javnog kljua sertifikacionog tela,
Korienje kljua sertifikacionog tela,
Kraj ivotnog ciklusa kljua sertifikacionog tela,
Upravljanje ivotnim ciklusom kriptografskog hardvera koji se
koristi za generisanje kvalifikovanih sertifikata,
Upravljanje kljuevima 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,
Nain publikacije liste opozvanih sertifikata.

o Upravljanje operativnim radom sertifikacionog tela

Upravljanje u skladu sa bezbednosnim principima,

117

Upravljanje i klasifikacija najvanijih informacija i podataka u

okviru sertifikacionog tela,
Kadrovski resursi,
Sistem fizike bezbednosti i bezbednosti okruenja,
Upravljanje radom sertifikacionog tela,
Upravljanje sistemom kontrole pristupa,
Upotreba i odravanje bezbednih kriptografskih sistema,
Upravljanje procedurama kontinualnog poslovanja u incidentnim
situacijama,
Prestanak rada sertifikacionog tela,
Usaglaenost 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 obezbeivanje usluga izdavanja
digitalnih sertifikata, tako to mora:

Imati Praktina pravila, i u njima definisane procedure, u kojima se specificira

nain ispunjenja svih zahteva za izdavanjem digitalnih sertifikata koji su
identifikovani u Politici sertifikacije.
Uiniti raspoloivim Praktina pravila rada svim korisnicima i drugim
zainteresovanim stranama.
Objaviti svim korisnicima i potencijalnim zainteresovanim stranama uslove
korienja digitalnih sertifikata.
Imati upravnu strukturu najvieg nivoa koja e imati konanu autorizaciju i
odgovornost za objavljivanje Praktinih pravila rada sertifikacionog tela.
Imati upravnu strukturu operativnog nivoa u sertifikacionom telu koja je
odgovorna za ispravnu primenu Praktinih pravila rada.
Definisati proces periodine analize i odravanja Praktinih pravila rada.
Imati odobrene, od strane upravne strukture najvieg nivoa, sve izmene u
Praktinim pravilima, tj. nove verzije Praktinih pravila i, nakon odobravanja,
odmah javno objavljene.

5.10.4 Interna pravila rada sertifikacionog tela

Sertifikaciono telo utvruje i posebna Interna pravila rada sertifikacionog tela i zatite
sistema sertifikacije u kojima su sadrani 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 sadre detaljne odredbe o:

Sistemu fizike kontrole pristupa u pojedine prostorije sertifikacionog tela,

118

Sistemu logike kontrole pristupa raunarskim resursima sertifikacionog tela,

Sistemu za uvanje privatnog kljua sertifikacionog tela,
Sistemu distribuirane odgovornosti pri formiranju privatnog kljua
sertifikacionog tela i
Postupcima i radnjama u vanrednim situacijama (poari, poplave, zemljotresi,
druge vremenske nepogode, zlonamerni upadi u prostorije ili informacioni
sistem sertifikacionog tela).

Interna pravila se baziraju na bezbednosnoj politici sertifikacionog tela u smislu

fizike zatite i zatite sistemskog okruenja za generisanje digitalnih sertifikata,
pripremu sredstava za formiranje digitalnog potpisa i upravljanje opozivom, koja
definie i kontrolu fizikog pristupa, zatitu od prirodnih katastrofa, zatitu od poara,
zatitu od nestanka elektrine energije i prekida rada telekomunikacionih linija,
zatitu od strukturnih kolapsa, zatitu od poplava, zatitu od krae, loma i upada u
sistem, oporavak nakon katastrofe, itd.
5.19.5 Upravljanje radom PKI sistema
Jedna od osnovnih obeleja politike sertifikacije treba da bude u mogunosti
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
linom kontaku i na one koje dobijaju zahteve udaljenim putem (npr. putem WEB
komunikacije).

Prihvatljiva veliina kljua zadatak ovog dela politike sertifikacije je da

obezbedi da duina kljueva koji se generiu u okviru CA i duina kljueva
koje koriste elementi PKI sistema (CAO, CA, RAO, RA) za digitalno
potpisivanje ne budu krai od onih koji se zahtevaju u bezbednosnoj politici
datog sistema.
Prihvatljivi asimetrini kriptografski algoritmi i u ovom sluaju politika
sertifikacije treba da obezbedi da se lista prihvatljivih (od strane politike
bezbednosti) asimetrinih algoritama koristi za digitalno potpisivanje i digitalnu
envelopu. Ova lista tipino sadri sledee algoritme RSA, DSA i ECDSA.
Prihvatljivi hash algoritmi identino kao u prethodne dve take, politika
sertifikacije treba da definie prihvatljivu listu hash algoritama. Najee se
koriste MD5 i SHA-1 algoritmi, a u poslednje vreme i SHA-224, SHA-256,
SHA-384 i SHA-512.
Izvor generisanja kljueva ovo operaciono ogranienje se uglavnom odnosi
na politiku sertifikacije u vezi registracije linim kontaktom, i konkretno se
odnosi na to kako treba da se generie asimetrini par kljueva za datog
korisnika. Mogue opcije su: generisanje kljueva korienjem funkcija iz
PKCS#11 standardnog interfejsa na smart kartici ili tokenu, lokalno
generisanje kljueva u okviru RAO modula u softveru i uitavanje zahteva za
izdavanjem sertifikata u PKCS#10 formatu iz odgovarajue datoteke, tokena ili
smart kartice.
Period validnosti sertifikata ovaj period se definie konkretno u okviru CPS
dokumenta. Minimalno ovaj period moe biti jedan dan a maksimalno do kraja
isteka vanosti sertifikata samog CA.

119

Zamena sertifikata kada sertifikat doe do kraja svog ivotnog veka, politika
sertifikacije treba da precizno definie postupak kojim se vri izdavanje novog
sertifikata kao i procedure (rune ili automatske) obavetavanja korisnika i
same procedure zamene.
Arhiviranje privatnog kljua u skladu sa bezbednosnom politikom, za
odreene asimetrine parove kljueva predvia se arhiviranje tajnog kljua za
kasniji oporavak ifrovanih poruka u sluaju potrebe.
Lozinka za potrebe povlaenja sertifikata normalno se sertifikati povlae na
osnovu zahteva od CAO ili RAO modula koji ima funkciju izdavanja sertifikata.
Meutim, mogue je dozvoliti krajnjem korisniku mogunost da poalje zahtev
za povlaenje svog sertifikata putem WEB komunikacije ali uz korienje
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 sledee uslove:

iskljuivo je povezan sa potpisnikom,

nedvosmisleno identifikuje potpisnika,
nastaje korisenjem podataka kojima potpisnik samostalno upravlja i koja su
iskljuivo pod nadzorom potpisnika,
kreiran je primenom odgovarajuih algoritama i parametara kojima se
omoguava 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 svojeruni potpis, odnosno svojeruni potpis i
peat 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
odreene uslove definisane u Zakonu o elektronskom potpisu i Direktivi Evropske
Unije o elektronskim potpisisma 1999/93/EC od 19.01.2000. godine.
Drugim reima, CA koje izdaje kvalifikovane elektronske sertifikate treba da ispuni
uslove za izdavanje kvalifikovanih sertifikata u skladu sa Direktivom Evropske unije o
elektronskim potpisima i domaem Zakonom o elektronskom potpisu.
Prema Direktivi, sertifikaciono telo koje izdaje kvalifikovane sertifikate treba da ispuni
sledee zahteve (Annex II):

Da demonstrira neophodnu sposobnost za pruanje sertifikacionih usluga,

120

Da garantuje pouzdan rad i da obezbedi pouzdane servise prikaza lista

vaeih i povuenih sertifikata,
Da obezbedi neophodnu preciznost u vezi datuma i vremena izdavanja ili
povlaenja sertifikata,
Da pouzdano verifikuje identitet vlasnika sertifikata i, ako je potrebno, bilo kog
specifinog atributa vlasnika,
Da zapoljava radnike koji poseduju ekspertska znanja, iskustvo i kvalifikacije
neophodne za servise koji se obezbeuju; posebno na upravnom nivou,
ekspertizu u oblasti elektronskog potpisa i familijarnost sa propisanim
bezbednosnim procedurama,
Da koristi proverene sisteme i proizvode koji obezbeuju tehniku i
kriptografsku bezbednost procesa koji se podravaju primenom ovih sistema,
Da primenjuje mere protiv kompromitacije sertifikata i garantuje tajnost
procesa generisanja para kljueva za digitalno potpisivanje ukoliko se taj par
generie kod sertifikacionog tela,
Da obezbedi odgovarajua materijalna sredstva za siguran i bezbedan rad i
da omogui odreenu emu osiguranja od lairanja sertifikata,
Da vri zapisivanje svih relevantnih informacija koja se tiu sertifikata u
odgovarajuem periodu vremena (posebno za sluajeve 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 obezbeuje servis
generisanja para kljueva za digitalno potpisivanje,
Da precizno upozna osobu koja zahteva izdavanje sertifikata sa svim uslovima
korienja sertifikata,
Da koristi proverene sisteme za uvanje sertifikata u formi koja se moe
verifikovati, sa sledeim karakteristikama:
o
o
o
o

Da samo autorizovane osobe mogu pristupati sistemu i vriti izmene,

Da se informacije mogu proveravati u smislu autentinosti,
Da su informacije o sertifikatima javno raspoloive,
Da su bilo kakve tehnike 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
sledee uslove:
1. sposobnost za pouzdano obavljanje usluga izdavanja elektronskih sertifikata,
2. bezbedno i aurno voenje registra korisnika kao i sprovoenje bezbednog i
trenutnog opoziva elektronskog sertifikata,
3. obezbeivanje tanog utvrivanja datuma i vremena izdavanja ili opoziva
elektronskog sertifikata,
4. da izvrava proveru identiteta i, ako je potrebno, i drugih dodatnih obeleja
osobe kojoj se izdaje sertifikat, na pouzdan nain i u skladu sa propisima,

121

5. da ima zaposleno osoblje sa specijalistikim znanjima, iskustvom i strunim

kvalifikacijama potrebnim za vrenje usluge izdavanja elektronskih sertifikata,
a naroito u odnosu na: sposobnosti na upravljakom nivou, strunost u
primeni tehnologija elektronskog potpisa i odgovarajuih sigurnosnih
procedura i bezbednu primenu odgovarajuih administrativnih i upravljakih
postupaka koji su usaglaeni sa priznatim standardima,
6. da koristi pouzdane sisteme i proizvode koji su zatieni od neovlaenih
izmena i koji obezbeuju tehniku i kriptografsku sigurnost procesa,
7. da preduzima mere protiv falsifikovanja elektronskih sertifikata, a u
sluajevima u kojima generie podatke za formiranje elektronskog potpisa da
garantuje tajnost procesa formiranja tih podataka,
8. da obezbedi finansijske resurse za osiguranje od rizika i odgovornosti za
moguu tetu nastalu vrenjem usluge izdavanja elektronskih sertifikata,
9. da obezbedi uvanje svih relevantnih informacija koje se odnose na
elektronske sertifikate u odreenom vremenskom periodu, a posebno za
pruanje 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 prua tu uslugu,
11. da obezbedi sisteme za fiziku zatitu ureaja, opreme i podataka, i
sigurnosna reenja za zatitu od neovlaenog pristupa,
12. da informie lica koja trae izdavanje kvalifikovanog elektronskog sertifikata o
tanim uslovima izdavanja i korienja tog sertifikata, ukljuujui bilo koja
ogranienja u korienju, kao i o postupcima za reavanje pritubi i albi.
Takve informacije, koje mogu biti dostavljene elektronski, moraju biti napisane
i pripremljene u razumljivom obliku na srpskom jeziku. Odgovarajui delovi tih
informacija moraju biti raspoloivi na zahtev treim licama koja koriste
elektronski sertifikat,
13. da koristi pouzdan sistem upravljanja elektronskim sertifikatima u obliku koji
omoguava njihovu proveru kako bi:
i. unos i promene radila samo ovlaena lica,
ii. mogla biti proverena autentinost informacija iz sertifikata,
iii. elektronski sertifikati bili javno raspoloivi za pretraivanje samo u onim
sluajevima za koje je vlasnik sertifikata dao saglasnost,
iv. bilo koja tehnika promena koja bi mogla da narui bezbedonosne
zahteve bila poznata sertifikacionom telu.
5.20.1. Sposobnost za pouzdano obavljanje usluga izdavanja elektronskih
sertifikata
Sertifikaciono telo mora da demonstrira sposobnost za pruanje usluga sertifikacije i
pouzdanu organizaciju rada.
Pored toga, sertifikaciono telo mora da obezbedi:
1. Opta i Interna pravila rada, kao i operativne procedure, koja nisu
diskriminatorska,
2. dostupnost svojih servisa svim korisnicima ije su aktivnosti u skladu sa
objavljenim Optim pravilima rada,

122

3. poslovanje u svojstvu pravnog lica u skladu sa odgovarajuom domaom

zakonskom regulativom,
4. sistem kvaliteta i sistem bezbednog upravljanja kvalifikovanim elektronskim
sertifikatima u skladu sa uslugama sertifikacije koje prua,
5. adekvatnu emu osiguranja za odgovornosti koje mogu da proisteknu u
vrenju njegovih aktivnosti,
6. finansijsku stabilnost i dovoljne resurse koji se zahtevaju u pruanju usluga
sertifikacije u skladu sa Politikom sertifikacije,
7. dovoljan broj zaposlenih sa neophodnim obrazovanjem, nivoom obuenosti,
tehnikim znanjima i iskustvom u odnosu na tip i obuhvat poslova koji se
zahtevaju pri pruanju usluga sertifikacije,
8. politiku i procedure za reavanje albi i sporova sa korisnicima ili drugim
zainteresovanim stranama u vezi pruanja usluga sertifikacije,
9. nezavisnost delova sertifikacionog tela ukljuenih u poslove generisanja
kvalifikovanih elektronskih sertifikata i upravljanja opozivom od drugih spoljnih
organizacija u sferi pruanja usluga sertifikacije. Posebno upravna struktura
sertifikacionog tela, kao i zaposleni sa bezbednosnim funkcijama-rolama,
moraju biti zatieni od bilo kakvih finansijskih i drugih pritisaka koji mogu
uticati na poverenje u usluge sertifikacije koje prua sertifikaciono telo,
10. propisno dokumentovanu strukturu delova sertifikacionog tela povezanih sa
generisanjem kvalifikovanih elektronskih sertifikata i upravljanjem opozivom
radi obezbeivanja nepristrasnosti u pruanju usluga sertifikacije.
Sertifikaciono telo obezbeuje da u sluaju katastrofa, ukljuujui i kompromitaciju
asimetrinog privatnog kljua sertifikacionog tela, operativni rad bude obnovljen to
je mogue pre a u skladu sa Optim i Internim pravilima rada.
Posebno, u sluaju kompromitacije svog asimetrinog privatnog kljua, sertifikaciono
telo obezbeuje:
1. informisanje svih korisnika i drugih zainteresovanih strana o kompromitaciji
privatnog kljua,
2. javno objavljivanje informacije o tome da izdati kvalifikovani elektronski
sertifikati, kao i informacije o statusu opozvanosti kvalifikovanih elektronskih
sertifikata, vie nisu vaei,
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 vri demonstraciju kompletnog poslovanja, usaglaenog sa Optim
i Internim pravilima poslovanja, pred odgovarajuom 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,

123

5. Korienje bezbednih sistema za uvanje podataka za generisanje

kvalifikovanih elektronskih potpisa,
6. Korienje bezbednih hardverskih sredstava za formiranje kvalifikovanog
elektronskog potpisa (hardverski moduli zatite (HSM Hardware Security
Module)),
7. Procedure opoziva sertifikata,
8. Procedure obnavljanja sertifikata,
9. Procedure suspenzije sertifikata,
10. Nain publikacije liste povuenih i suspendovanih sertifikata,
11. Sistema fizike kontrole pristupa u prostorije sertifikacionog tela,
12. Sistema logike kontrole pristupa raunarskim resursima sertifikacionog tela,
13. Sistema za javno publikovanje osnovnih informacija o pruanju usluga
sertifikacije, kao i Optih pravila rada sertifikacionog tela.
5.20.2 Bezbedno i aurno voenje registra korisnika kao i sprovoenje
bezbednog i trenutnog opoziva elektronskog sertifikata
Sertifikaciono telo vodi aurnu i bezbednu evidenciju izdatih, opozvanih i
suspendovanih kvalifikovanih elektronskih sertifikata koja mora biti javno dostupna, u
skladu sa Zakonom o elektronskom potpisu. Tanost i validnost ovih evidencija
sertifikaciono telo garantuje svojim kvalifikovanim elektronskim potpisom.
5.20.3 Obezbeivanje tanog utvrivanja datuma i vremena izdavanja ili
opoziva elektronskog sertifikata
Za pouzdano odreivanje vremena izdavanja i opoziva kvalifikovanih elektronskih
sertifikata sertifikaciono telo mora obezbediti hardverski izvor tanog vremena. Tano
vreme izdavanja kvalifikovanog elektronskog sertifikata sertifikaciono telo ugrauje u
izdati kvalifikovani elektronski sertifikat. Tano vreme izdavanja i opoziva
kvalifikovanih elektronskih sertifikata sertifikaciono telo uva u evidenciji izdatih i
opozvanih kvalifikovanih elektronskih sertifikata.
5.20.4 Obezbeivanje pouzdane registracija korisnika
Sertifikaciono telo vri registraciju korisnika, odnosno pouzdanu identifikaciju i
autentikaciju korisnika kojima izdaje kvalifikovane elektronske sertifikate, u skladu sa
Zakonom o elektronskom potpisu. Postupke registracije vri ovlaeni slubenik
sertifikacionog tela ili registracionog tela na udaljenoj registracionoj lokaciji koje
uspostavlja sertifikaciono telo za potrebe registracije korisnika.
Sertifikaciono telo obezbeuje da zahtevi korisnika za izdavanje kvalifikovanih
elektronskih sertifikata budu kompletni, pouzdani i autorizovani, u skladu sa
Zakonom o elektronskom potpisu i vri registraciju korisnika u skladu sa sledeim
principima:
1. Korisnik se identifikuje kao fiziko lice sa specifinim atributima koji mogu
oznaavati organizacionu jedinicu ili ulogu u organizaciji gde je zaposlen.

124

2. Pre uspostavljanja ugovornog odnosa sa korisnikom, sertifikaciono telo javno

informie korisnika na jasnom i razumljivom jeziku o svim relevantnim
uslovima korienja kvalifikovanih elektronskih sertifikata.
3. Sertifikaciono telo verifikuje identitet korisnika u skladu sa vaeim zakonskim
propisima.
4. Za pouzdanu proveru identiteta korisnika u postupku registracije zahteva se
fiziko prisustvo korisnika u sertifikacionom telu ili u registracionom autoritetu.
5. Ako je potrebno, sertifikaciono telo verifikuje i bilo koji specifini atribut
korisnika kome se izdaje kvalifikovani elektronski sertifikat.
6. Ukoliko se radi o fizikom licu kao individualnom korisniku, identitet korisnika
mora da bude proveren na osnovu zakonom propisanog linog
identifikacionog dokumenta.
7. Ukoliko se radi o korisniku koji se identifikuje kao pripadnik pravnog lica ili
neke organizacije, dokaz njegovog identiteta mora da sadri sledee
elemente, i to:
i. Zakonom propisani lini identifikacioni dokumenat,
ii. Pravno valjane podatke o registraciji pravnog lica ili organizacije,
iii. Dokaz da je korisnik ovlaen od strane tog pravnog lica ili organizacije
za dobijanje kvalifikovanog elektronskog sertifikata.
8. Sertifikaciono telo je odgovorno za pouzdanost i tanost informacija sadranih
u kvalifikovanom elektronskom sertifikatu.
9. Korisnik mora obezbediti tane i pouzdane informacije o fizikoj adresi, ili
drugim atributima, koji opisuju kako se korisnik moe kontaktirati.
10. Sertifikaciono telo uva sve informacije koriene za verifikaciju identiteta
korisnika i dokumentaciju korienu za identifikaciju, kao i bilo koja
ogranienja njene vanosti.
11. Sertifikaciono telo mora da sklopi Ugovor, i da uva potpisani Ugovor, sa
korisnikom koji ukljuuje:
i. Obaveze korisnika,
ii. Obavezu korisnika da koristi sredstvo za formiranje kvalifikovanog
elektronskog potpisa koje obezbeuje sertifikaciono telo ako je to u
skladu sa Optim pravilima rada,
iii. Obavezu sertifikacionog tela da uva podatke koriene u registraciji
korisnika i sve informacije o ivotnom ciklusu izdatog kvalifikovanog
elektronskog sertifikata korisnika, kao i prosleivanje ovih informacija
treim stranama pod istim uslovima kako je zahtevano Politikom
sertifikacije u sluaju prestanka sa radom sertifikacionog tela,
iv. Uslove za publikaciju sertifikata,
v. Potvrdu da su informacije sadrane u sertifikatu korektne.
12. Prethodno navedena dokumenta se uvaju u vremenskom periodu koji je
specificiran u korisnikovom Ugovoru i neophodna su radi obezbeenja dokaza
o poslovima sertifikacije u pravnim procedurama.
13. Ako asimetrini par kljueva korisnika nije generisan od strane sertifikacionog
tela, proces generisanja zahteva za kvalifikovanim elektronskim sertifikatom
mora da obezbedi da korisnik poseduje asimetrini privatni klju koji je
matematiki, na bazi asimetrinog kriptografskog algoritma, povezan sa

125

javnim kljuem 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
asimetrini par kljueva generisan iskljuivo na tom sredstvu za formiranje
kvalifikovanog elektronskog potpisa.
14. Sertifikaciono telo obezbeuje potovanje nacionalne regulative u vezi zatite
podataka za vreme procesa registracije korisnika.
5.20.5 Obezbeivanje neophodnih kadrovskih resursa i upravljanja operativnim
radom sertifikacionog tela
Sertifikaciono telo obezbeuje 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 obezbeuje neophodne kadrovske resurse u skladu sa
sledeim principima:
1. Zaposleni u sertifikacionom telu moraju da poseduju ekspertsko znanje,
iskustvo i neophodnu kvalifikaciju za usluge koje sertifikaciono telo nudi, kao i
za odgovarajue poslovne funkcije.
2. Uloge i funkcije bezbednosti, specificirane u Optim pravilima rada
sertifikacionog tela, moraju biti dokumentovane i detaljno specificirane sa
opisima svakog radnog mesta u sertifikacionom telu. Poslovne funkcije od
najvieg nivoa poverljivosti, od kojih najvie 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 stanovita razdvajanja dunosti i privilegija. Opisi
poslova moraju razlikovati opte poslove i specifine funkcije sertifikacionog
tela. Preporuuje se da opisi poslova ukljue i definicije zahteva za specifinim
vetinama i iskustvom koja se trae od zaposlenih.
4. Zaposleni moraju da izvravaju administrativne i upravljake 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 odgovarajua 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 ukljuuju sledee odgovornosti:
i. Administratori bezbednosti: Sveukupna odgovornost za administriranje i
implementaciju bezbednosnih funkcija i procedura, kao i upravljanje

126

aktivnostima na dodatnom unapreenju poslova generisanja, opoziva i

suspenzije kvalifikovanih elektronskih sertifikata.
ii. Sistem administratori: Autorizovani za instalaciju, konfigurisanje i
odravanje bezbednih sistema sertifikacionog tela za registraciju
korisnika,
generisanje
kvalifikovanih
elektronskih
sertifikata,
obezbeenje 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 tekuem radu na dnevnom nivou i autorizovani za implementaciju
sistema za formiranje rezervnih kopija i procedure oporavka.
iv. Sistem evidentiari: Autorizovani za pregledanje i odravanje arhiva i log
fajlova bezbednih sistema sertifikacionog tela.
8. Zaposlenima u sertifikacionom telu moraju biti formalno dodeljene
bezbednosne funkcije od strane vie upravne strukture nadlene za
bezbednost.
9. Sertifikaciono telo ne sme dodeliti bezbednosne ni upravne funkcije osobama
koje su osuivane ili koje su na bilo koji nain kanjavane u odnosu na njihovu
podobnost za rad na odgovornim funkcijama. Zaposleni ne smeju imati pristup
bezbednosnim funkcijama pre zavretka neophodnih provera.
Pored toga, sertifikaciono telo obezbeuje bezbedno i korektno funkcionisanje svojih
sistema, sa minimalnim rizikom od kvarova u skladu sa sledeim principima:
1. zatien integritet sistema sertifikacionog tela, kao i informacija, od virusa,
malicioznog i neautorizovanog softvera,
2. minimalnu tetu usled moguih incidenata korienjem procedura izvetavanja
i odgovarajuih odgovora. Sertifikaciono telo mora da reaguje brzo i
koordinirano u cilju odgovora na bezbednosne incidente i da ogranii uticaj
bezbednosnih upada,
3. bezbedno korienje memorijskih medija u skladu sa unapred specificiranim
emama klasifikacije informacija. Mediji koji sadre 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 pruanje usluga sertifikacije. Svaki zaposleni
iz upravne strukture sertifikacionog tela je odgovoran za planiranje i efektivnu
implementaciju Optih pravila rada sertifikacionog tela.
5. stalni nadzor tekuih i buduih potreba za kapacitetom sistema sertifikacionog
tela radi obezbeenja adekvatne procesne snage i memorijskih kapaciteta.
5.20.6 Korienje pouzdanih i bezbednih kriptografskih sistema
Sertifikaciono telo mora da koristi bezbedne sisteme i proizvode koji su zatieni od
neovlaenih modifikacija. Zahtevi za bezbedne sisteme mogu biti ispunjeni
korienjem sistema definisanim u skladu sa ISO/IEC 15408 standardom ili drugim
odgovarajuim standardom.

127

Sertifikaciono telo pre poetka obavljanja usluga sertifikacije, kao i periodino tokom
operativnog rada, vri analizu rizika kojom identifikuje kritine servise koji zahtevaju
korienje bezbednih sistema i visoke nivoe sigurnosti.
Sertifikaciono telo obezbeuje da su njegovi asimetrini kljuevi generisani u strogo
kontrolisanim i bezbednim uslovima, u skladui sa sledeim:
1. Generisanje asimetrinih kljueva vri u fiziki zatienom okruenju, od
strane i uz minimalan broj zaposlenih autorizovanih za izvravanje ove
funkcije, uz najmanje dvostruku kontrolu a prema zahtevima i procedurama
definisanim u Praktinim pravilima rada sertifikacionog tela.
2. Generisanje asimetrinih kljueva vri u sredstvu koje:
i. zadovoljava zahteve iz standarda FIPS PUB 140-1 i 140-2 nivo 3 i vii,
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 vii, u
skladu sa ISO/IEC 15408 standardom ili zadovoljava zahteve
ekvivalentnih kriterijuma bezbednosti.
3. Generisanje kljueva vri korienjem algoritma propisanog za svrhu
generisanja kvalifikovanih elektronskih sertifikata.
4. Usklaivanje primenjene duina kljua i asimetrinog 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).
Takoe, sertifikaciono telo obezbeuje zatitu tajnosti i integritet asimetrinih
privatnih kljueva, u skladu sa sledeim principima:
1. uvanje i korienje privatnog kljua za formiranje kvalifikovanog elektronskog
potpisa u bezbednom kriptografskom ureaju koji:
i. zadovoljava zahteve iz standarda FIPS PUB 140-1 i 140-2 nivo 3 i vii,
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 vii, u
skladu sa ISO/IEC 15408 standardom ili zadovoljava zahteve
ekvivalentnih kriterijuma bezbednosti.
2. da su delovi privatnog kljua koji se nalaze izvan kriptografskog ureaja
ifrovani korienjem propisanog simetrinog algoritma i duine kljua koji

128

omoguavaju, prema sadanjem nivou kriptografskih znanja, pouzdanu

odbranu od kriptoanalitikih napada.
3. uvanje privatnog kljua, uz obezbeenje rezervne kopije, i rekonstrukcija
samo od strane onih zaposlenih koji imaju bezbedne funkcije-role, uz
korienje najmanje dvostruke kontrole u fiziki obezbeenom okruenju. Broj
zaposlenih u sertifikacionom telu koji su autorizovani da izvravaju ove
funkcije mora biti minimalan i da zadovolji zahteve i procedure definisane u
Praktinim pravilima rada sertifikacionog tela.
4. da rezervne kopije privatnih kljueva za formiranje kvalifikovanog elektronskog
potpisa kvalifikovanih elektronskih sertifikata imaju isti ili vii nivo
bezbednosnih kontrola u odnosu na kljueve koji se operativno koriste.
5. da se merama logike kontrole pristupa onemogui neovlaeno aktiviranje
kriptografskog ureaja sa privatnim kljuem sertifikacionog tela i da se klju ne
moe iitati spolja.
Sertifikaciono telo obezbeuje da njegov asimetrini javni klju koji slui za
verifikaciju kvalifikovanog elektronskog potpisa kvalifikovanih elektronskih sertifikata
bude raspoloiv svim korisnicima i drugim zainteresovanim stranama na nain kojim
se obezbeuje autentinost i integritet javnog kljua. Sertifikaciono telo moe svoj
asimetrini javni klju distribuirati korisnicima i drugim zainteresovanim stranama u
obliku kvalifikovanog elektronskog sertifikata koji moe 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 autentinosti samopotpisanog sertifikata. Jedna od mera moe biti
korienje hash vrednosti kompletnog sertifikata koja je raspoloiva na
poverljiv nain (na primer objavljena na WEB sajtu sertifikacionog tela).
Sertifikaciono telo koristi svoj asimetrini privatni klju u skladu sa Optim i Internim
pravilima rada, a naroito obezbeuje:
1. da se koristi iskljuivo za formiranje kvalifikovanog elektronskog potpisa
kvalifikovanih elektronskih sertifikata, kao i kvalifikovanog elektronskog
potpisa statusa opozvanosti sertifikata,
2. da se koristi samo u okviru fiziki zatienih prostorija sertifikacionog tela.
Sertifikaciono telo obezbeuje da se njegovi asimetrini privatni kljuevi ne koriste
nakon isteka njihovog ivotnog ciklusa, u skladu sa Optim i Internim pravilima rada.
opije privatnih kljueva kojima je istekao ivotni ciklus oraju biti:
1. unitene na nain kojim se obezbeuje da se privatni klju ne moe
rekonstruisati ili
2. sauvane na nain kojim se obezbeuje zatita od ponovnog korienja.
Sertifikaciono telo osigurava bezbednost kriptografskih ureaja koji se koriste za
generisanje i uvanje kljueva i formiranje kvalifikovanog elektronskog potpisa tokom
ivotnog ciklusa ureaja, u skladu sa Internim pravilima rada, a posebno obezbeuje
da:

129

1. kriptografski ureaj nije kompromitovan tokom transporta,

2. kriptografski ureaj nije kompromitovan za vreme uvanja u sertifikacionom
telu,
3. procedure instalacije, aktivacije, kreiranja rezervnih kopija i rekontrukcije
asimetrinog privatnog kljua u kriptografskom ureaju vri samo uz
istovremenu kontrolu najmanje dva zaposlena sa bezbednim funkcijamarolama,
4. kriptografski ureaj funkcionie korektno i
5. obezbedi da se privatni kljuevi sertifikacionog tela koji su uvani u
kriptografskom ureaju unite nakon ivotnog ciklusa ureaja.
5.20.7 Zahvevi za obezbeenjem zatite od falsifikovanja sertifikata i tajnosti
generisanih kljueva
Sertifikaciono telo mora osigurati bezbedan proces generisanja kvalifikovanih
elektronskih sertifikata radi obezbeenja njihove autentinosti i integriteta.
U tom smislu, sertifikaciono telo obezbeuje:
1. da se kvalifikovani elektronski sertifikati generiu u skladu sa formatom
definisanim u dokumentu ETSI ESI TS 101 862,
2. da je procedura generisanja kvalifikovanog elektronskog sertifikata bezbedno
povezana sa odgovarajuim procedurama registracije korisnika, obnavljanja
sertifikata ili obnavljanja kljua, ukljuujui sve opcije generisanja asimetrinog
javnog kljua od strane korisnika,
3. u sluaju da sertifikaciono telo generie korisnikove kljueve:
i. da je procedura generisanja kvalifikovanog elektronskog sertifikata
bezbedno povezana sa procedurom generisanja asimetrinog para
kljueva 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 korisniko
ime koje se dodeli u postupku generisanja sertifikata ne moe nikada da se
pridrui drugom korisniku),
5. tajnost i integritet registracionih podataka, i to posebno u sluajevima razmene
podataka sa korisnikom ili u sluaju razmene informacija izmeu distribuiranih
komponenti sertifikacionog tela.
6. verifikaciju registracionih podataka koji su razmenjeni sa autentikovanim
operatorom registracionog autoriteta, u sluaju da je koriena eksterna
sluba za obezbeivanje registracionih poslova.
Sertifikaciono telo obezbeuje da zahtevi za obnavljanje kvalifikovanih elektronskih
sertifikata i/ili zahtevi za izdavanje kvalifikovanih elektronskih sertifikata korisnicima
kojima su prethodni sertifikati bili opozvani, budu kompletni, tani i autorizovani.

130

U zahtevu za obnavljanjem sertifikata, sertifikaciono telo mora uneti aurirane

informacije o korisniku i sve druge izmene koje su prethodno verifikovane na isti
nain kao i u postupku registracije korisnika.
Sertifikaciono telo e izdati novi kvalifikovani elektronski sertifikat koristei prethodno
sertifikovani javni klju korisnika samo ako je njegova kriptografska bezbednost jo
uvek dovoljna za predvieni novi ivotni ciklus sertifikata i ako ne postoje indikacije
da je korisnikov privatni klju kompromitovan.
5.20.8 Zahtevi za odgovornou i osiguranjem od rizika
Sertifikaciono telo je odgovorno da su svi sertifikacioni servisi navedeni u Politici
sertifikacije konzistentni i implementirani u skladu sa Praktinim pravilima. Pruanje
usluga sertifikacije regulie se posebnim Ugovorom izmeu sertifikacionog tela i
korisnika, u kome se definiu sledee obaveze korisnika:
1. da dostavi tane i kompletne informacije sertifikacionom telu u skladu sa
procedurom registracije definisanom u Politici sertifikacije koja je izraena u
skladu sa Zakonom o elektronskom potpisu i podzakonskim aktima,
2. da iskljuivo koristi asimetrini par kljueva za formiranje kvalifikovanog
elektronskog potpisa u skladu sa Ugovorom,
3. da onemogui neovlaen pristup svom privatnom kljuu,
4. da, ukoliko sam generie asimetrini par kljueva:
i. za generisanje koristi propisani algoritam usaglaen za potrebe
formiranja kvalifikovanog elektronskog potpisa,
ii. koristi propisanu duinu kljua 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, generie par kljueva 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 vanosti sertifikata
koji je naznaen u samom sertifikatu, bilo koji od sledeih dogaaja desi:
i. korisnikov privatni klju je izgubljen, ukraden ili postoji osnovana sumnja
da je kompromitovan ili
ii. kontrola nad korienjem korisnikovog privatnog kljua je izgubljena iz
razloga kompromitacije aktivacionih podataka (PIN kod ili lozinka) za
sredstvo za formiranje kvalifikovanog elektronskog potpisa ili drugih
razloga i/ili
iii. netanost ili izmena sadraja kvalifikovanog elektronskog sertifikata,

131

8. da prekine korienje svog privatnog kljua ukoliko postoji osnovana sumnja u

kompromitaciju kljua 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 vanost i ispravnost statusa suspenzije ili opoziva kvalifikovanog
elektronskog sertifikata korienjem statusnih informacija koje je odgovarajue
sertifikaciono telo javno publikovalo (u zavisnosti od Optih pravila rada
sertifikacionog tela i primenjenih mehanizama za publikovanje informacija o
statusu opoziva kvalifikovanih elektronskih sertifikata postoji mogunost
kanjenja do jednog dana u auriranju statusnih informacija),
2. uzmu u obzir sva ogranienja u korienju kvalifikovanog elektronskog
sertifikata koja su naznaena u samom sertifikatu ili publikovana u Optim
pravilima rada sertifikacionog tela.
Sertifikaciono telo obezbeuje finansijske resurse za osiguranje od rizika i
odgovornosti za moguu tetu nastalu vrenjem usluga izdavanja kvalifikovanih
elektronskih sertifikata u skladu sa Zakonom o elektronskom potpisu i podzakonskim
aktima. Nain osiguranja, kao i odgovarajui iznos sredstava, moraju biti jasno
navedeni u Optim pravilima rada sertifikacionog tela.
5.20.9 Zahvevi za uvanjem svih relevantnih informacija
Sertifikaciono telo mora da obezbedi uvanje svih relevantnih informacija koje se tiu
kvalifikovanih elektronskih sertifikata u vremenskom periodu definisanom u skladu sa
Optim pravilima rada, i to posebno u cilju obezbeenja dokaza o izvrenoj
sertifikaciji za pravne svrhe. Informacije koje se uvaju ukljuuju podatke o registraciji
korisnika i informacije o znaajnim dogaajima vezanim za operativni rad
sertifikacionog tela, kao i za upravljanje kljuevima i sertifikatima.
U tom smislu, sertifikaciono telo obezbeuje:
1. tajnost i integritet tekuih i arhiviranih zapisa o kvalifikovanim elektronskim
sertifikatima,
2. kompletno i pouzdano arhiviranje informacija o kvalifikovanim elektronskim
sertifikatima u skladu sa objavljenim Optim pravilima rada,
3. da su zapisi u vezi kvalifikovanih elektronskih sertifikata, kao i registracione i
druge informacije o korisniku, raspoloivi za potrebe pravnih poslova kao
dokaz izvrene sertifikacije.
4. pouzdano arhiviranje tanog vremena znaajnih dogaaja 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 dogaaja na nain da se ne mogu lako obrisati ili unititi
(izuzev u cilju prenosa na dugotrajne medije za uvanje) u okviru vremenskog
perioda u kome se moraju uvati.
7. dokumentovanje specifinih dogaaja i podataka koji treba da se evidentiraju.

132

8. evidentiranje svih dogaaja koji se odnose na registraciju korisnika, ukljuujui

i zahteve za obnavljanjem sertifikata, a naroito:
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,
ukljuujui i potpisan Ugovor sa korisnikom,
iv. Specifine elemente iz Ugovora sa korisnikom,
v. Identitet slubenika registracione lokacije koji je izvrio registraciju
korisnika,
vi. Podatke o metodi koja je koriena za validaciju identifikacionih
dokumenata,
vii. Ime sertifikacionog tela koje je primilo registracione informacije i/ili ime
registracionog autoriteta koje je poslalo informacije.
9. zatitu privatnosti podataka korisnika.
10. evidentiranje svih dogaaja u vezi sa ivotnim ciklusom kljueva
sertifikacionog tela.
11. evidentiranje svih dogaaja u vezi sa ivotnim ciklusom kvalifikovanih
elektronskih sertifikata.
12. evidentiranje svih dogaaja u vezi sa ivotnim ciklusom kljueva kojima
upravlja sertifikaciono telo, ukljuujui i korisnike kljueve ako su generisani u
sertifikacionom telu.
13. evidentiranje svih dogaaja koji se odnose na pripremu sredstava za
formiranje kvalifikovanog elektronskog potpisa.
14. da se svi zahtevi i izvetaji koji se odnose na proceduru opoziva sertifikata
evidentiraju, ukljuujui i sve odgovarajue aktivnosti.
Sertifikaciono telo obezbeuje minimalnu moguu tetu korisnicima i drugim
zainteresovanim stranama u sluaju njegovog prestanka rada i kontinuirano uvanje
podataka koje se zahteva u pravnim procedurama kao dokaz izvrene usluge
sertifikacije, a posebno obezbeuje da:
1. pre prestanka pruanja usluga sertifikacije, izvrava sledee aktivnosti:
i. informie sve korisnike i druge zainteresovane strane o prestanku rada,
ii. unitava, ili potpuno onemoguava korienje, svojih asimetrinih
privatnih kljueva koji su korieni za formiranje kvalifikovanog
elektronskog potpisa kvalifikovanih elektronskih sertifikata.
2. obezbeuje neophodna finansijska sredstva za realizaciju gore navedenih
zahteva.
3. Optim pravilima rada definie proceduru prestanka rada, koja obuhvata:
i. obavetavanje zainteresovanih strana,
ii. eventualni prenos obaveza drugim sertifikacionim telima,
iii. proceduru opoziva izdatih kvalifikovanih elektronskih sertifikata kojima
nije istekao rok vanosti.

133

5.20.10 Zahtevi za bezbednim uslovima za korisnike za koje se generiu podaci

za formiranje elektronskog potpisa
Sertifikaciono telo obezbeuje da su kljuevi korisnika koje ono generie, generisani
bezbedno i da je osigurana tajnost privatnog kljua korisnika.
U tom smislu, sertifikaciono telo obezbeuje:
1. da se asimetrini par korisnikih kljueva generie korienjem algoritma koji
je propisan da zadovolji zahteve koji se primenjuju za kvalifikovane
elektronske potpise.
2. da su asimetrini kljuevi korisnika propisane duine i korieni u propisanom
asimetrinom kriptografskom algoritmu u cilju da se zadovolje propisani
zahtevi za implementacijom kvalifikovanog elektronskog potpisa.
3. da se korisniki kljuevi bezbedno generiu i uvaju pre nego to se dostave
korisniku.
4. da je asimetrini privatni klju bezbedno dostavljen korisniku na takav nain
da je tajnost kljua obezbeena i da pri isporuci samo korisnik ima pristup
svom privatnom kljuu.
Ukoliko sertifikaciono telo obezbeuje sredstva za formiranje kvalifikovanog
elektronskog potpisa za korisnike, to ini na bezbedan nain u skladu sa standardom
ISO/IEC 15408 ili drugim odgovarajuim standardom, a posebno obezbeuje 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
pridruene 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 moe biti obezbeeno ili
dostavom u razliito vreme ili na razliiti nain.
5.20.11 Zahtevi za sisteme fizike zatite ureaja, opreme i podataka i
sigurnosna reenja zatite od neovlaenog pristupa
Sertifikaciono telo obezbeuje kontrolu fizikog pristupa svojim bezbednosno
kritinim resursima, kao i minimizaciju rizika u pristupu svojim kljunim elementima.
U tom smislsu, sertifikaciono telo obezbeuje:
1. da se fiziki pristup prostorijama u kojima se obavlja generisanje kvalifikovanih
elektronskih sertifikata, priprema sredstava za formiranje kvalifikovanog

134

2.
3.
4.

5.

6.
7.
8.
9.

elektronskog potpisa i upravljanje procedurom opoziva sertifikata, ogranii

samo na pouzdano autorizovane osobe.
da su implementirane neophodne mere u cilju izbegavanja gubitaka, oteenja
ili kompromitovanja kljunih resursa i eliminisanje mogunosti prekida
poslovnih aktivnosti.
da se implementiraju odgovarajue mere za spreavanje kompromitacije ili
krae informacija i/ili ureaja za procesiranje informacija.
da su prostorije u kojima se vri generisanje kvalifikovanih elektronskih
sertifikata, priprema sredstava za formiranje kvalifikovanog elektronskog
potpisa i upravljanje opozivom, takve da se operativni rad u njima odvija u
okruenju koje obezbeuje fiziku zatitu sertifikacionih servisa i resursa od
kompromitacije prouzrokovane neautorizovanim pristupom sistemu i
podacima.
da je fizika zatita uspostavljena kreiranjem jasno definisanih bezbednosnih
perimetara (tj. fizikih barijera) kojima se tite procesi generisanja
kvalifikovanih elektronskih sertifikata, obezbeenja 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.
da su implementirane odgovarajue fizike mere i kontrole bezbednosnog
okruenja u cilju zatite prostorija i sistemskih elemenata sertifikacionog tela.
da su implementirane odgovarajue mere u cilju zatite ureaja, informacija,
memorijskih medija i softvera od otuivanja sa lokacije bez propisne
autorizacije.
da su sistemi fizike zatite i zatite bezbednosnog okruenja u skladu sa
ISO/IEC 17799 standardom kao uputstvom za fiziku bezbednost i
bezbednost okoline.
da se i druge specifine bezbednosne funkcije mogu primeniti u okviru istog
bezbednog prostora koji obezbeuje pristup samo autorizovanim zaposlenim
osobama.

Sertifikaciono telo obezbeuje da je pristup sistemu sertifikacije ogranien iskljuivo

na pouzdano autorizovane osobe, a naroito obezbeuje:
1. implementaciju kontrola na mrenom nivou (na primer firewall-i) u cilju zatite
interne mree sertifikacionog tela od eksternih mrenih domena kojima moe
pristupiti trea 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 zatitu osetljivih podataka, koji ukljuuju i podatke o registraciji
korisnika, tokom prolaska kroz delove mree koji nisu bezbedni.
3. efikasnu i pouzdanu administraciju korisnikih pristupa (ukljuujui operatore,
administratore i bilo koje specifine korisnike koji imaju direktan pristup
sistemu) u cilju odravanja bezbednosti sistema, ukljuujui i upravljanje
nalozima korisnika, evidentiranje i mogunost modifikacije i zabrane pristupa.
4. strogo ogranien pristup informacijama i aplikativnim funkcijama sistema u
skladu sa Optim pravilima rada i Politikom kontrole pristupa, identifikovanom
u njima, kao i dovoljnu raunarsko-bezbednosnu kontrolu u cilju razdvajanja
bezbednih funkcija rola u sistemu koje su identifikovane u Optim pravilima
rada, ukljuujui razdvajanje funkcija administratora bezbednosti i operatera, a

135

posebno rad sa korisnikim programima za upravljanje sistemom mora biti

posebno ogranieno i strogo kontrolisano.
5. pouzdanu identifikaciju i autentikaciju zaposlenih u sertifikacionom telu pre
korienja kritinih operacija vezanih za procedure upravljanja sertifikatima.
6. evidentiranje svih aktivnosti zaposlenih u sertifikacionom telu na osnovu
odgovarajuih korisnikih naloga i log fajlova.
7. pouzdanu zatitu bezbednosno osetljivih podataka, koji ukljuuju i
registracione podatke korisnika, od neautorizovanog pristupa na osnovu
ponovnog korienja prethodno obrisanih ili arhiviranih podataka.
8. da se lokalne mrene komponente (ruteri i sl.) uvaju u fiziki zatienom
okruenju i da se njihova konfiguracija periodino kontrolie u cilju ispitivanja
usklaenosti sa zahtevima specificiranim u Optim i Internim pravilima rada.
9. ureaje 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
pokuaj pristupa resursima koja se koriste za pruanje usluga sertifikacije.
10. da aplikacija za distribuciju sertifikata mora primeniti sistem logike kontrole
pristupa u cilju spreavanja pokuaja dodavanja ili brisanja odgovarajuih
sertifikata i modifikacije drugih pridruenih informacija.
11. da aplikacija za dobijanje statusa opoziva sertifikata primenjuje sistem logike
kontrole pristupa u cilju spreavanja pokuaja modifikacije informacija o
statusu opoziva sertifikata.
5.20.12 Zahtevi za raspoloivou informacija o uslovima izdavanja i korienja
sertifikata
Sertifikaciono telo obezbeuje da su sve potrebne informacije o uslovima izdavanja i
korienja kvalifikovanih elektronskih sertifikata raspoloive korisnicima i drugim
zainteresovanim stranama. Sertifikaciono telo obezbeuje raspoloivost informacija i
podataka o svom poslovanju, i to:
1.
2.
3.
4.

Opta pravila rada sertifikacionog tela koja su trenutno vaea,

Ogranienja u korienju Optih pravila rada,
Obaveze korisnika,
Informacije o nainu provere vanosti kvalifikovanih elektronskih sertifikata,
ukljuujui i zahteve za proveru statusa opoziva sertifikata,
5. Ogranienja odgovornosti koja ukljuuju sluajeve 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 reavanje albi i sporova,
9. Pravni sistem koji se primenjuje i
10. Informaciju o statusu eventualne akreditacije.
Sertifikaciono telo obezbeuje da su navedene informacije neprekidno raspoloive
korienjem jednostavnih vidova komunikacije (Internet i sl.) sa obezbeenim
integritetom tokom vremena, da mogu se prenositi elektronskim putem i da su
prikazane na potpuno razumljiv nain.

136

5.20.13 Zahtevi za sistem upravljanja sertifikatima

Sertifikaciono telo obezbeuje uvid u izdate, opozvane i suspendovane kvalifikovane
elektronske sertifikate svim korisnicima i drugim zainteresovanim stranama.
U tom smislu, sertifikaciono telo obezbeuje:
1. da je izdati kvalifikovani elektronski sertifikat raspoloiv korisniku kome je
sertifikat izdat,
2. da su kvalifikovani elektronski sertifikati rapoloivi treim licima samo u onim
sluajevima za koje je dobijen pristanak korisnika, a u skladu sa Optim
pravilima rada sertifikacionog tela,
3. raspoloivost informacija o uslovima izdavanja i korienja 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 raspoloive 24 asa na dan, 7 dana u
sedmici. Nakon pada sistema, ili deliminog gubitka mogunosti za
obezbeenje servisa, sertifikaciono telo mora da primeni sve raspoloive mere
da ovaj informacioni servis bude ponovo aktivan to pre, ali najkasnije do
isteka roka predvienog u Optim 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 izmeu dva
CA koji se nalaze ili u istom ili u razliitim PKI domenima. Ta dva CA mogu biti bilo
gde u svom hijerarhijskom PKI domenu (root CA, potinjeni CA ili nadreeni CA).
U sluaju da se radi o istom PKI domenu imamo potinjeni CA i nadreeni CA.
Nadreeni CA sertifikuje sertifikacioni klju drugog, podreenog CA. Nadreeni CA
moe biti root CA iji javni klju slui kao osnov poverenja u bezbednosnom domenu.
U sluaju da se radi istom PKI domenu proces interoperabilnosti je uslovljen
tehnikim uslovima i politikom nadredjenog CA.
Komplikovaniji sluaj je krossertifikacija dva CA iz razliitih PKI domena. U ovom
sluaju se moe utvrditi procedura i kriterijumi za krossertifikaciju. Ta procedura moe
da bude organizovana na sledei nain.
Faze krossertifikacije mogu biti: iniciranje postupka, poredjenje politika, test,
ugovaranje i odravanje sistema. Proces sertifikacije mogu voditi dva CA meusobno
ili svaki od CA sa posebnom institucijom koja je specijalizovana za krossertifikaciju.
Ta posebna institucija se naziva BCA (Bridge Certification Authority). U sluaju retkih
odnosa krossertifikacije postojanje posebne institucije nije opravdano. Ali, u sluaju
masovnog procesa krossertifikacije, naroito u sluaju kada se radi o krossertifikaciji

137

jednog ili vie manjih CA sa vladinim ili nekim drugim masovnim CA, postojanje
posebne institucije je koja vodi proces krossertifikacije je od izuzetne vanosti.
5.21.1.1 Faza inicijacije krossertifikacije
Faza inicijacije poinje popunjavanjem zahteva, preliminarnim pregledom forme i
kompletnosti dokumentacije. Vlada moe propisati neophodne uslove koje kandidat
treba da ispuni za zapoinjanje procesa krossertifikacije. Zahtev moe da podnese
druga vladina organizacija, komercijalna organizacija koja ima brojne kontakte sa
vladinim organizacijama, nekomercijalna organizacija koja, takoe, ima brojne
poslovne kontakte sa vladinim organizacijama ili ak organizacija iz druge drave.
Spisak neophodnih optih akata moe biti: dokumenta o pravnoj zasnovanosti PKI
entiteta, pravnoj nadlenosti, finansijskoj sposobnosti za podnoenje finansijskog
rizika i osiguranja za izdate sertifikate.
Kandidat treba da poseduje niz sledeih dokumenata: politiku sertifikacije CA
(certificate policy), praktina pravila rada CPS, bezbednosnu politiku, detaljan opis
tehnologije rada, dokumentaciju o tehnolokoj kompatibilnosti sistema, oekivani nivo
poverenja u kros sertifikate, pravni status i finansijske mogunosti.
Dokumentovana organizacija posla CA mora biti implementirana i demonstrirana.
Kandidat za kros-sertifikaciju mora da se odlui koje elemente svoje politike i prakse
eli da sertifikuje. Slino treba da uradi i drugi kandidat ili kandidati i da se kroz
proces kros-sertifikacije naini zajednika politika i praksa koja e vaiti za krossertifikat. Takodje je neophodno odrediti zajedniki nivo poverenja.
Kao to se vidi radi se o vrlo osetljivom i dugotrajnom procesu, pogotovu ako se radi
o vie kandidata.
5.21.1.2 Poreenje i usklaivanje politika
Proces poreenja i usklaivanja politika kandidata za krossertifikaciju naziva se
mapiranje politika. Proces mapiranja politika obuhvata poreenje dve ili vie politika
kako po slinosti tako i po razlikama. Poreenjem je neophodno obuhvatiti politiku,
praksu i procedure koje moraju biti usklaene. Lista kategorija koje se porede
obuhvaena je matricom mapiranja. Analiza matrice mapiranja pokazuje elemente
poslovanja razliitih CA koji su uporedivi ili ekvivalentni i na osnovu kojih se moe
napraviti zajednika politika ili doneti dogovor o usklaivanju bitnih elemenata
politike.
Dokumenti sertifikacione politike razliitih kandidata mogu biti organizovani na
posebne naine, imati delove koji se drugaije zovu, terminologija ne mora biti
usklaena, mogu postojati reference na razliita spoljna dokumenta. Na primer,
kljuni izraz poverljiv moe za jednu sertifikacionu politiku znaiti jedno, a sasvim
neto 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.

138

Prikupljanje podataka i popunjavanje matrice mapiranja je vrlo vaan proces i ne

moe biti vremenski ogranien. Ne zavrava se sve dok se ne prikupe svi neophodni
podaci.
Kroz proces mapiranja politika utvruje se mera ili stepen usaglaenosti raziitih
stvari sa ciljem da se uspostavi to znaajniji stepen poverenja ili da se odredi mera
razliitosti. Ako je to potrebno, kroz proces usaglaavanja je mogue dovesti do
poveanog stepena usaglaenosti.
Po utvrdjivanju ekvivalencije generie se krossertifikat koji predstavlja potvrdu
medjusobnog poverenja izmru dva ili vie sertifikacionih entiteta.
5.21.1.3 Testiranje
Kroz proces testiranja tehnike interoperabilnosti proverava se i potvruje saglasnost
tehnolokih sistema kandidata za krossertifikaciju. Cilj je da se utvrdi da li je mogua
razmena kros-sertifikata i da li su obostrano dostupni direktorijumi sa javnim
podacima. Pogodno je da postoje testna okruenja, kao kopije produkcionog, i da se
na njima radi kao na prototipu, a da se zatim pree na produkciju.
Minimum neophodnih testova bi obuhvatao: mrenu povezanost po potrebnom skupu
protokola; interoperabilnost sistema direktorijuma; obostrano prepoznavanje krossertifikata izdatih od strane drugog kandidata; testiranje procedure provere sertifikata
izdatog klijentu od drugog kandidata i mogunost razmene liste povuenih sertifikata.
Uspenim okonanjem testiranja tehnike interoperabilnosti ispunjeni su tehniki
zahtevi za krossertifikaciju.
5.21.1.4 Ugovaranje
Posle faza potvrde tehnike interoperabilnosti i mapiranja politika analiriza se
usklaenost dobijenih podataka sa oekivanim nivoom meusobnog poverenja. U
koliko su svi izvetaji povoljni pristupa se kreiranju finalnog dokumenta, ugovora u
kome su definisana obostrana prava, obaveze i specifinosti kandidata.
5.21.1.5 Odravanje sistema
Posle uspenog procesa krossertifikacije, potpisivanja ugovora i izdavanja
krossertifikata bivi kandidati, a sad lanovi, svoje odnose periodino analiziraju.
Samim Ugovorom je predviena dinamika periodine analize trenutne politike i
prakse rada svakog od potpisnika.
lanovi mogu raskinuti ugovor ako nema obostranog interesa za postojanje krossertifikata ili se ne potuju preuzete obaveze bilo da su u domenu sertifikacione
politike ili tehnike interoperabilnosti.

139

5.22 Dosadanja iskustva u izgradnji Sertifikacionih tela

Svetski trendovi u razvoju i primeni tehnika zatite informacionih sistema i
savremenih kriptografskih protokola su u sve veoj primeni PKI sistema i
bezbednosnih mehanizama baziranih na smart karticama.
U tome prednjae zemlje Evropske unije ali situacija ni izdaleka nije ujednaena i
stepen primene PKI sistema se razlikuje od zemlje do zemlje.
U razvijenim zapadnim zemljama, najvanije 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 karakterie stanje u zapadnim zemljama (i to pre svega

u zemljama Evropske unije) sa stanovita primene bezbednosnih mehanizama su:

Veina 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 odgovarajue zakone koje su manje ili vie
usklaene sa evropskom Direktivom. Meutim, bez obzira na generalnu
usklaenost svih zakona meusobno, postoje odreena otvorena pitanja za
koja postoje razliite interpretacije u pojedinim zakonima iz razloga to ta
pitanja ni u Direktivi nisu najpreciznije definisana. Otvorena pitanja utiu na to
da se razmatra mogunost auriranja teksta Direktive o elektronskim
potpisima. Meu najznaajnijim otvorenim pitanjima meunarodne tehnoloke
i pravne usklaenosti propisa o elektronskom poslovanju i elektronskom
potpisu nalaze se:
o Problem
standardizacije
tehnolokog
postupka
generisanja
kvalifikovanog elektronskog potpisa (kako se pravna regulativa
pojedinih zemalja odnosi prema meunarodnim standardizacionim
inicija-tivama u domenu elektronskog potpisa (npr. EESSI European
Electronic Signature Standardization Initiative)),
o Problem akreditacije i supervizije certifikacionih tela u razliitim
zemljama,
o Pravni status elektronskih certifikata koji ne zadovoljavaju uslove da
budu kvalifikovani elektronski certifikata, i kako se to reava u
pojedinim zemljama,
o Problem odgovornosti certifikacionih tela i kako se on u pojedinim
zemljama reava,
o Problem u nepostojanju dovoljnog broja praktinih realizacija sistema
sa primenom kvalifikovanog digitalnog potpisa i nejasne situacije u vezi
toga kada je on stvarno potreban,

140

o Problem u nedovoljno preciznim definicijama (od zemlje do zemlje)

ureaja za generisanje kvalifikovanog digitalnog potpisa.

U svetu se sve vie i vie razmatraju i uvode sistemi masovnog korienja

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
omogue korienje u postojeim i buduim e-government aplikacijama.
Takoe, postoje primeri uvoenja smart kartica kao zdravstvenih knjiica
(Slovenija, Tajvan),
U svetu postoje primeri sve veeg uvoenja elektronskog bankarstva na bazi
smart kartica (pre svega u domenu zatiene veze firma banka) ali ne u
oekivanom broju (to pogotovo vai u domenu elektronskog plaanja fizikih
lica),
U svetu postoji sve vie 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 sluaju, u svetu se polako uvodi PKI tehnologija uz reavanje u hodu

manjih ili veih 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.
Jedan od najveih izazova i problema je u interoperabilnosti PKI sistema. Naime,
dananji PKI sistemi se mogu posmatrati uglavnom kao zasebna ostrva, slika 5.8,
izmeu kojih je prilino komplikovano realizovati komunikaciju. U cilju prevazilaenja
ovih problema, u svetu se razmatraju razliite inicijative i realizuju se razliiti projekti
koji na razliite naine reavaju problem interoperabilnosti PKI sistema, kao to su
projekti: EuroPKI, PKI Challenge, Bridge CA, i drugi.
Pored toga, treba napomenuti da se u svetu sve vie i vie uvode biometrijski sistemi
u kombinaciji sa primenom smart kartica, i to kako za logovanje na razliite aplikacije,
tako i za logovanje na sam PC raunar (Win Logon procedure). Ovi sistemi ne slue
samo za logovanje korisnika na klijentske radne stanice ve i za prijavljivanje
korisnika na itav mreni sistem proverom njegovih bezbednosnih parametara
(najee X.509 digitalnih certifikata u centralnoj bazi podataka), slika 5.9.

141

Slika 5.7: Stanje realizacije PKI sistema u svetu

Slika 5.8: Razliiti PKI sistemi kao zasebna ostrva u sistemima elektronskog
poslovanja

142

Slika 5.9: Primena otiska prsta u cilju biometrijske autentikacije korisnika na

centralnom mrenom serveru baze podataka

6. Implementacija Sistema upravljanja informatikom

bezbednou u Organizaciji po standardu ISO/IEC
27001:2005
6.1 Uvod
U ovom poglavlju je razmatrana mogua uspostava Sistema upravljanja
informatikom bezbednou (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

Meunarodni standard ISO/IEC 27001 je pripremljen da obezbedi jedan model za
uspostavu, implementaciju, operativni rad, nadzor, pregled, odravanje i
poboljavanje Sistema za upravljanje informatikom bezbednou (ISMS
Information Security Management System).
Usvajanje ISMS sistema treba da bude strateka odluka za jednu organizaciju.
Dizajn i implementacija ISMS sistema u organizaciji je pod uticajem njenih potreba i
ciljeva, bezbednosnih zahteva, procesa koji se izvravaju, kao i uslovljen veliinom i
strukturom organizacije.
Oekuje se da jedna implementacija ISMS sistema treba da bude prilagoena
potrebama organizacije, na primer jednostavna situacija zahteva jednostavno ISMS
reenje.

143

ISO 27001 standard je usvojio procesni pristup za uspostavu, implementaciju,

operativni rad, nadzor, pregled, odravanje i poboljavanje ISMS sistema.
Organizacija mora da identifikuje i upravlja mnogim aktivnostima u cilju da
funkcionie efektivno. Bilo koja aktivnost koja koristi resurse i upravlja se u cilju da
omogui transformaciju nekih ulaza u izlaze moe se posmatrati kao proces. esto
izlaz jednog procesa direktno formira ulaz za sledei proces, itd. Primena sistema
procesa u okviru organizacije, zajedno sa identifikacijom i interakcijom tih procesa,
kao i njihovo upravljanje moe se posmatrati kao procesni prilaz.
Procesni prilaz upravljanju informatike bezbednosti koji je predstavljen u ISO 27001
standardu naglaava vanost:
a. Razumevanja zahteva za informatikom bezbednou u organizaciji, kao i
potrebe da se uspostavi politika i ciljevi informatike bezbednosti;
b. Implementacije i primene kontrola za upravljanje rizicima informatike
bezbednosti u organizaciji u kontekstu sveukupnih poslovnih rizika
organizacije;
c. Nadzora i pregleda performansi i efektivnosti ISMS sistema;
d. Kontinualnog poboljanja na bazi objektivnog merenja.
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 informatikom bezbednou, kao i oekivanja zainteresovanih strana, i
kroz neophodne akcije i procese proizvodi izlaze informatike bezbednosti koji
zadovoljavaju pomenute zahteve i oekivanja.
Plan (uspostava ISMS sistema)
Uspostava ISMS politike, ciljeva, procesa i procedura koji su relevantni za upravljanje
rizikom i poboljanje informatike 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 praktino iskustvo, kao i izvetavanje o rezultatuma
menademntu za svrhu pregleda.
Act (odravanje i poboljavanje ISMS sistema)
Primena korektivnih i preventivnih akcija, baziranih na rezultatima internog ISMS
audita i pregleda od strane menadmenta ili drugih relevantnih informacija, u cilju
postizanja kontinualnog poboljanja ISMS sistema.

144

Slika 6.1: PDCA model po ISO 27001 standardu

Istorijat geneze dokumenata vezanih za standarde ISO 17799 i 27001, kao i za BS
7799 moe se prikazati na sledei nain (veza izmeu 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 povuena.
ISO/IEC 27001: 2005 nova verzija standarda u 2005. godini, publikovana u
novembru 2005. BS 7799-2: 2002 verzija povuena.

145

Slika 6.2: Veze izmedju razliitih standarda

Dakle, danas aktuelni standardi u domenu informatike bezbednosti su:

ISO/IEC 27002: 2005 Information Technology Security Techniques Code

of practice for information security management (nekada 17799 standard),
o Obezbeuje smernice najboljeprakse za ISMS sistem
o Definie skup ciljeva kontrola, kontrola, kao i
implementaciju.
o Ne moe se koristiti za ocenjivanje i sertifikaciju.

smernica

za

ISO/IEC 27001:2005 Information Technology Security Techniques

Information Security Management Systems Requirements
o Definie specifine zahteve za uspostavu, implementaciju, operativni
rad, nadzor, pregled, odravanje i poboljanje dokumentovanog ISMS
sistema.
o Izraen da osigura adekvatne bezbednosne kontrole da zatiti
informaciona dobra i dokumentuje ISMS sistem.
o Moe se koristiti za ocenjivanje i sertifikaciju.

146

6.3 Uspostava i upravljanje ISMS sistemom

6.3.1 Uspostava ISMS (Plan)

U cilju uspostave ISMS sistema organizacija treba da izvri sledee aktivnosti:
a) Definie okvir i granice ISMS u skladu sa karakteristikama svog
poslovanja, organizacije, lokacijom, imovinom i tehnologijama, ukljuujui i
relevantne detalje;
b) Definie ISMS politiku u skladu sa karakteristikama svog poslovanja,
organizacije, lokacijom, imovinom i tehnologijama tako da:
1. Ukljui okvir za postavljanje ciljeva i uspostavi opte vienje pravca i
principa za aktivnosti povezane sa informatikom bezbednou;
2. Uzme u obzir poslovne i pravne ili regulatorne zahteve, kao i
ugovorne bezbednosne obaveze;
3. Uskladi se sa kontekstom stratekog upravljanja rizikom u
organizaciji u kome je ukljuena uspostava i odravanje ISMS;
4. Uspostave se kriterijumi u odnosu na koje e se rizici evaluirati,
5. Odobrena je od strane menadmenta.
Napomena: U okviru ISO/IEC 27001, ISMS politika (ili Top Level Security
Policy) predstavlja nadskup politika informatike bezbednosti koje treba da
se definiu u pojedinim oblastima koje standard pokriva.
c) Definie pristup ocenjivanju rizika u organizaciji
1. Identifikuje metodologiju ocenjivanja rizika koja odgovara ISMS
sistemu, kao i identifikovanim pravnim, regulatornim i poslovnim
zahtevima za informatiku bezbednost,
2. Razvije kriterijume za prihvatanje rizika, kao i za identifikaciju
prihvatljivog nivoa rizika.
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 menadmenta odobrenu odgovornost za kontrolu
proizvodnje, razvoja, odravanje, korienja i obezbeivanja dobra,
Termin vlasnik ne znai da ta osoba poseduje bilo kakva vlasnika
prava nad tim dobrom organizacije.
2. Identifikuje pretnje nad ovim dobrima.
3. Identifikuje ranjivosti koje mogu biti iskoriene od strane navedenih
pretnji.

147

4. Identifikuje uticaje koje gubici na tajnosti, integritetu i raspoloivosti

mogu imati nad dobrima organizacije.
e) Analizira i evaluira rizike
1. Ocenjuje poslovne uticaje na organizaciju koji mogu da rezultuju na
bazi bezbednosnih ispada, uzimajui u obzir gubitke na tajnosti,
integritet i raspoloivost dobara.
2. Ocenjuje realnu verovatnou bezbednosnih ispada koji se deavaju
u svetlu preovlaujuih pretnji i ranjivosti, kao i uticaje koji su
pridrueni tim dobrima, kao i trenutno implementirane kontrole.
3. Ocenjuje nivoe rizika.
4. Odreuje da li su rizici prihvatljivi ili se zahteva odgovarajui tretman
korienjem uspostavljenih kriterijuma za prihvatanje rizika.
f) Identifikuje i evaluira opcije tretmana rizika
Mogue aktivnosti ukljuuju:
1. Primena odgovarajuih kontrola.
2. Svesno i objektivno prihvatanje rizika, obezbeujui da oni jasno
zadovoljavaju politike i kriterijume organizacije za prihvatanje rizika.
3. Izbegavanje rizika.
4. Prebacivanje pridruenih poslovnih rizika na druge strane, kao na
primer: dobavljae, osiguranje, itd.
g) Selektuje ciljeve kontrola, kao i same kontrole, za tretman rizika
Ciljevi 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 menadmenta za predloene preostale (rezidualne)
rizike
i) Dobije autorizaciju od strane menademnta da implementira i pusti u
operativni rad ISMS sistem
j) Pripremi Izjavu o primenljivosti (Statement of Applicatbility)
Izjava o primenljivosti treba da bude pripremljena tako da ukljuuje
sledee:
1. Izabrane ciljeve kontrola, kao i same kontrole, kao i razloge zato su
izabrani.
2. Ciljeve kontrola i same kontrole koje su trenutno implementirane.
3. Iskljuivanje bilo kojih ciljeva kontrola i samih kontrola koje su
definisane ISO/IEC 27001 standardom, kao i obrazloenje za
njihovo iskljuivanje.
Napomena: Izjava o primenljivosti obezbeuje rezime o odlukama koje se tiu
tretiranja rizika. Obrazloeni izuzeci obezbeuju jednu dodatnu proveru da nijedna
kontrola nije nehotino izostavljena.

148

6.3.2 Implementacija i operativni rad ISMS sistema (Do)

U cilju implementacije i uspostave operativnog rada ISMS sistema organizacija treba
da izvri sledee aktivnosti:
a) Formulie plan tretiranja rizika u kome identifikuje odgovarajue upravne
akcije, resurse, odgovornosti i prioritete za upravljanje rizicima informatike
bezbednosti.
b) Implementira plan tretiranja rizika u cilju postizanja identifikovanih ciljeva
kontrola, koje ukljuuju razmatranje budeta, kao i dodeljivanja uloga i
odgovornosti.
c) Implementira izabrane kontrole da bi se zadovoljili postavljeni ciljevi
kontrola.
d) Definie 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 omoguava menaderima i
zaposlenima da odrede koliko dobro primenjene kontrole postiu
postavljene ciljeve kontrola.
e) Implementiraju obuku i programe za podizanje svesti zaposlenih o
informatikoj bezbednosti.
f) Upravljaju operativnim radom ISMS sistema
g) Upravljaju resursima neophodnim za ISMS
h) Implementiraju procedure, kao i druge kontrole, koje omoguavaju
promptnu detekciju bezbednosnih dogaaja 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
izvri sledee aktivnosti:
a) Izvri procedure nadzora i preispitivanja, kao i druge kontrole, za:
1. Promptnu detekciju greaka u rezultatima procesiranja.
2. Promptnu identifikaciju pokuanih i uspenih bezbednosnih proboja i
incidenata.
3. Omoguenje menadmentu da odredi da li su bezbednosne aktivnosti
delegirane zaposlenima, ili implementirane putem informacionih
tehnologija, implementirane kako se i oekivalo.
4. Pomo u vezi detekcije bezbednosnih dogaaja korienjem indikatora
ime se spreavaju bezbednosni incidenti.
5. Odreivanje da li su akcije preduzete u cilju reavanja bezbednosnih
ispada bile efektivne.
b) Primeni regularna preipitivanja efektivnosti ISMS sistema (ukljuujui
zadovoljavanje ISMS politike i ciljeva, kao i preispitivanje bezbednosnih
kontrola) uzimajui u obzir rezultate bezbednosnih auditinga, incidenata,

149

rezultata merenja efektivnosti, sugestija, kao i povratnih informacija od svih

zainteresovanih strana.
c) Meri efektivnost kontrola
bezbednosni zahtevi.

u cilju verifikacije da su zadovoljeni

d) Preispituje ocenjivanje rizika u planiranim intervalima, kao i

preispitivanje preostalih rizika i identifikovanih prihvatljivih nivoa rizika,
uzimajui u obzir promene na:
1.
2.
3.
4.
5.
6.

Organizaciju.
Tehnologiju.
Poslovne ciljeve i procese.
Identifikovane pretnje.
Efektivnost implementiranih kontrola i
Eksternim dogaajima, kao to su promene pravnog ili regulatornog
okruenja, izmenjenim ugovornim obavezama, kao i promene u
drutvenoj 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 menadementa ISMS
sistema u cilju da opseg sistema ostaje adekvatan i da su identifikovana
poboljanja ISMS procesa.
g) Aurira bezbednosne planove da se uzmu u obzir nalazi aktivnosti
nadzora i preispitivanja.
h) Zapisuje akcije i dogaaje koji mogu imati uticaj na efektivnost ili
performanse ISMS sistema.
6.3.4 Odravanje i poboljanje ISMS sistema (Act)
U cilju odravanja i poboljanja ISMS sistema organizacija treba da izvri sledee
aktivnosti:
a) Implementira identifikovana poboljanja ISMS sistema.
b) Izvri odgovarajue korektivne i preventivne akcije. Primeniti nauene
lekcije iz bezbednosnih iskustava drugih organizacija, kao i onih same
organizacije.
c) Razmeni informacije o akcijama i poboljanjima 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 poboljanja dostignu njihove eljene ciljeve.

150

6.4 Zahtevi za dokumentacijom

6.4.1 Opte odredbe

Dokumentacija treba da ukljui zapise o odlukama menadmenta, osigura da se
akcije mogu pratiti u skladu sa odlukama menadmenta i politikama, kao i da osigura
da zapisani rezultati budu reproduktabilni.
Vano je da postoji mogunost da se demonstrira veza unazad izmeu izabranih
kontrola i rezultata procesa ocene i tretiranja rizika, kao i unazad ka izraenoj ISMS
politici i definisanim ciljevima.
ISMS dokumentacija treba da ukljui:
a)
b)
c)
d)
e)
f)
g)

ISMS politiku i u njoj definisane ciljeve ISMS sistema.

Opseg ISMS sistema.
Procedure i kontrole kao podrka ISMS sistemu.
Opis metodologije ocene rizika.
Izvetaj o oceni rizika.
Plan tretiranja rizika.
Dokumentovane procedure koje se zahtevaju od strane organizacije da
bi se osiguralo efektivno planiranje, operativni rad i kontrola procesa
informatike 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 znai da je procedura
uspostavljena, dokumentovana, implementirana i da se odrava.
6.4.2 Kontrola dokumenata
Dokumenti koji se zahtevaju u okviru ISMS sistema moraju biti zatieni i
kontrolisani. Jedna dokumentovana procedura treba da bude uspostavljena da
definie upravne akcije koje su neophodne za:
a) Potvrdu adekvatnosti dokumenata pre njihovog publikovanja,
b) Pregled i auriranje dokumenata kada je to neophodno, kao i ponovno
potvrivanje dokumenta.
c) Osiguranje da su promene, kao i tekui status revizije dokumenta,
identifikovani.
d) Osiguranje da su relevantne verzije primenljivih dokumenata raspoloive
na mestima (takama) korienja.
e) Osiguranje da dokumenti zadravaju itkost i laku identifikabilnost.
f) Osiguranje da su dokumenti raspoloivi onima kojih ih trebaju, kao i da su
preneti, sauvani i isporueni u skladu sa procedurama koje su primenljive
u odnosu na njihovu klasifikaciju.
g) Osiguranje da su identifikovani dokumenti koji potiu od spoljne strane.
h) Osiguranje da je distribucija dokumenta kontrolisana.

151

i) Spreavanje nenamernog korienja dokumenata koji vie ne vae.

j) Primenu pogodne identifikacije dokumenata ukoliko se uvaju za kasnije
korienje u bilo koju svrhu.
6.4.3 Kontrola zapisa
Zapisi moraju biti uspsotavljeni i odravani da obebede dokaz o usklaenosti sa
zahtevima i efektivnim operativnim radom ISMS sistema. Zapisi moraju biti zatieni 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, skladitenje, zatitu, dobijanje, vreme uvanja i otkrivanje zapisa
moraju biti dokumentovane i implementirane. Zapisi takoe treba da budu uvani o
performansama procesa i svim pojavama znaajnih bezbednosnih incidenata koji se
odnose na ISMS sistem. Primeri zapisa su knjige posetilaca, audit izvetaji i
kompletirane forme za autorizacju pristupa.

6.5 Odgovornost menadmenta

6.5.1 Posveenost menadmenta

Menadment treba da obezbedi dokaz svoje posveenosti i privrenosti za
uspostavu, implementaciju, operativni rad, nadzor, pregled, odravanje i
poboljavanje ISMS sistema putem:
a)
b)
c)
d)

e)
f)
g)
h)

Uspostave ISMS politike.

Osiguranja da su ISMS ciljevi i planovi uspostavljeni.
Uspostavljanja uloga i odgovornosti za informatiku bezbednost.
Razmenom informacija sa zaposlenima u organizaciji o vanosti
zadovoljenja ciljeva informatike bezbednosti i saglasnosti sa politikom
informatike bezbednosti, njihove zakonske odgovornosti, kao i potrebu za
stalim poboljanjem.
Obezbeenjem dovoljnih resursa za uspostavu, implementaciju, operativni
rad, nadzor, pregled, odravanje i poboljavanje ISMS sistema.
Odluivanja o kriterijumima za prihvatanje rizika i prihvatljivih nivoa rizika.
Osiguravanja da e interni ISMS auditi biti sprovedeni.
Sprovoenja upravnih pregleda ISMS sistema.

6.6 Upravljanje resursima

6.6.1 Obezbeivanje resursa
Organizacija treba da odredi i obezbedi resurse koji su potrebni za:

152

a) Uspostavu, implementaciju, operativni rad, nadzor, pregled, odravanje i

poboljavanje ISMS sistema.
b) Osiguranje da procedure informatike bezbednosti podravaju poslovne
zahteve.
c) Identifikaciju i razmatranje legalnih i regulatornih zahteva i ugovornih
bezbednosnih obaveza.
d) Odravanje adekvatne bezbednosti korektnom primenom svih
implementiranih kontrola.
e) Sprovoenje pregleda kada je to neophodno, kao i odgovarajua reakcija u
odnosu na rezultate takvih pregleda.
f) Poboljavanje 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) Odreivanja neophodnih kompetencija za zaposlene koji sprovode posao
koji se odnosi na ISMS sistem.
b) Obezbeenja obuka ili sprovoenja drugih aktivnosti (na primer:
zapoljavanjem kompetentnog ljudstva) u cilju zadovoljenja njihovih
potreba.
c) Evaluacijom efektivnosti sprovedenih akcija.
d) Odravanjem zapisa o edukaciji, obuci, vetinama, iskustvu i
kvalifikacijama.
Organizacija treba takoe da osigura da su svi relevantni zaposleni svesni
relevantnosti i vanosti njihovih aktivnosti u vezi informatike 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
odreivanja da li su ciljevi kontrola, same kontrole, procesi i procedure njihovog
ISMS sistema:
a) Saglasni sa zahtevima ovog standarda i relevantnom legislativom i
regulativom.
b) Saglasni sa identifikovanim zahtevima za informatiku bezbednost.
c) Efektivno implementirani i odravani.
d) Sprovode se kao to je oekivano.
Program audita treba da bude planiran, da uzme u razmatranje status i vanost
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 sprovoenje audita treba da osiguraju objektivnost i nepristrasnost procesa
audita. Auditori ne treba da vre ispitivanje (audit) njihovog sopstvenog rada.

153

Odgovornosti i zahtevi za planiranje i sprovoenje audita, kao i za izvetavanje o

rezultatima i odravnaju zapisa treba da budu definisane u dokumentovanoj
proceduri.
Menadment koji je odgovoran za oblast koja e biti ispitivana mora da osigura da se
akcije sprovode bez neprikadnih kanjenja u cilju eliminisanja uoenih nesaglasnosti
i njihovih uzroka. Pratee aktivnosti treba da ukljue verifikaciju akcija koje se
sprovode, kao i izvetavanje o rezultatima verifikacije.

6.8 Upravni pregled ISMS sistema

6.8.1 Opte odredbe
Menadment treba da pregleda ISMS sistem u organizaciji u planiranim intervalima
(najmanje jednom godinje) da bi osigurali njegovu kontinualnu pogodnost,
adevatnost i efektivnost. Ovaj pregled treba da ukljui mogunosti ocenjivanja za
poboljavanje i potrebu za izmenama ISMS sistema, ukljuujui politiku informatike
bezbednosti i ciljeva informatike bezbednosti. Rezultati pregleda treba da budu
jasno dokumentovani a zapisi treba da budu odravani.
6.8.2 Ulazi za pregled
Ulaz za upravni pregled treba da ukljui:
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 poboljanja 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) Pratee aktivnosti od prethodnih upravnih pregleda.
h) Bilo koje izmene koje mogu da utiu na ISMS sistem.
i) Preporuke za poboljanje.
6.8.3 Izlazi upravnog pregleda
Izlaz upravnog pregleda mora da ukljui bilo koje odluke i akcije koje se odnose na
sledee:
a) Poboljanje efektivnosti ISMS sistema.
b) Auriranje planova za ocenu i tretiranje rizika.
c) Modifikaciju procedura i kontrola pomou kojih se realizuje informatika
bezbednost, ako je to neophodno, u cilju odgovora na interne ili eksterne
dogaaje koji mogu da utiu na ISMS sistem, ukljuujui promene:

154

1.
2.
3.
4.
5.
6.

Poslovnih zahteva
Bezbednosnih zahteva
Poslovnih procesa kojima se realizuju postojei poslovni zahtevi
Regulatornih ili legalnih zahteva
Ugovornih obaveza
Nivoa rizika i/ili kriterijuma za prihvatanje rizika

d) Resurse koji su potrebni.

e) Poboljanja u odnosu na to kako se efektivnost kontrola moe meriti.

6.9 Poboljanje ISMS sistema

6.9.1 Kontinualno poboljavanje
Organizacija treba kontinualno da poboljava efektivnost ISMS sistema kroz
korienje politike informatike bezbednosti, ciljeva informatike bezbednosti,
rezultata audita, analize nadziranih dogaaja, korektivnih i preventivnih akcija i
upravnog pregleda.
6.9.2 Korektivne akcije
Organizacija treba da preduzme akcije da eliminie uzroke nesaglasnosti sa
zahtevima ISMS sistema u cilju da sprei njihovo ponovno pojavljivanje.
Dokumentovana procedura za korektivne akcije treba da definie zahteve za:
a) Identifikaciju nesaglasnosti.
b) Odreivanje uzroka nesaglasnosti.
c) Evaluaciju potrebe za akcijama koje treba preduzeti da bi se osiguralo da
se nesaglasnosti nee ponovo pojaviti.
d) Odreivanje i implementaciju neophodnih korektivnih akcija.
e) Zapisivanje rezultata preduzetih akcija.
f) Pregled preduzetih akcija.

6.9.3 Preventivne akcije

Organizacija treba da odredi akcije da eliminie uzrok potencijalnih nesaglasnosti sa
zahtevima ISMS sistema u cilju spreavanja njihovog pojavljivanja. Preventivne
akcije treba da budu odgovarajue uticaju koje mogu imati potencijalni problemi.
Dokumentovana procedura za preventivne akcije treba da definie zahteve za:
a) Identifikaciju potencijalnih nesaglasnosti i njihovih uzroka.
b) Evaluaciju potrebe za akcijama u cilju spreavanja pojave nesaglasnosti.

155

c) Odreivanje 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 panjom na znaajno izmenjene rizike.
Prioritet preventivnih akcija treba da bude odreen na bazi rezultata ocene rizika.
U prilogu E su detaljnije razraeni principi i metodologije bezbednosti i risk
menadmenta.

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 sledeih faza:

Pred-sertifikacija i sertifikacija
o Korak 0 - Pred-ocenjivanje
o Korak 1 Audit dokumentacije
o Korak 2 Audit implementacije

Post-sertifikacija
o Kontinualno nadgledanje tokom 3 naredne godine
o Ponovna sertifikacija (re-certification) nakon 3 godine od sertifikacije

Procesu prethodi inicijalni zahtev sertifikacionog tela da organizacijia popuni i poalje

potpisanu aplikacionu formu koja ukljuuje 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, moe sastojati od: ocenjivanja ocene rizika u
organizaciji, ocenjivanja Izjave o primenljivosti i uspostave plana audita.
Ocenjivanje procesa ocene rizika u organizaciji se najee vri kroz odgovarajue
intervjue sa menadmentom i zaposlenima koji su odgovorni/ukljueni u proces
ocene rizika.
Ocenjivanje Izjave o primenljivosti predstavlja ocenu rezultata analize rizika, izbora
kontrola sa obrazloenjem, kao i ocenu same dokumentovane Izjave o primenljivosti.
Korak 0 moe trajati od jednog do dva dana na lokaciji organizacije.
Audit program/plan koji se izrauje se sastoji od odgovarajue matrice sistema
upravljanja sa aspekta ciljeva kontrola, odgovornih lica, odeljenja i procesa (ova

156

matrica pokriva itav trogodinji sertifikacioni period), kao i plana intervjua za korake
1 i 2 (izbor ciljeva kontrola, procesa i slubi/odeljenja).
Korak 1 predstavlja znaajan deo procesa ocenjivanja po ISO/IEC 27001
standardu. Sertifikaciono telo treba da dobije dokumentaciju o dizajnu ISMS sistema,
ukljuujui izvetaj o oceni rizika, Izjavu o primenljivosti, kao i kljune elemente ISMS
sistema.
Ovaj korak audita ukljuuje, ali se ne ograniava samo na to, pregled dobijenih
dokumenata. Audit dokumentacije se u optem sluaju sprovodi u samoj organizaciji
(on site) i sastoji se od sledeih 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 (takoe
ako nije pregeldana u koraku 0).
Politike, standardi, operativne procedure i radne instrukcije.
Odgovarajue pokrivanje dokumentima izabranih bezbednosnih kontrola.
Upravljanje i dostupnost dokumenata.
Auditori verovatno nee detaljno pregledati specifine procedure ali oekuju
da postoji infrastruktura dokumenata koja, pored specifinih politika, obuhvata
standarde, procedure i radne instrukcije. Eventualno e biti pregledani uzorci
pojedinih dokumenata.

Pregled dokumenata treba da bude zavren pre poetka koraka 2. Rezultati

aktivnosti u koraku 1 se dokumentuju u pisanom izvetaju. Iako sve zavisi od
procesa sertifikacije i izabranog sertifikacionog tela, korak 1 bi takoe 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 vie lokacija organizacije e biti
poseena od strane jednog ili vie 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.
Nakon toga se vri ocenjivanje implementacije i efektivnosti upravljakog sistema po
PDCA modelu, kao i ocenjivanje implementacije i efektivnosti primenjenih
bezbednosnih kontrola. Naime, cilj je da se oceni funkcionisanje ISMS sistema u
realnom sluaju a na bazi rezultata internih audita, upravnog pregleda, praenja
korektivnih i preventivnih mera, identifikacije novih rizika i ponovnog ocenjivanja
postojeih rizika, itd.
Broj dana trajanja koraka 2 sertifikacije zavisi od veliine i kompleksnosti ISMS
sistema i same organizacije. Nakon zavrenog procesa verifikacije tim lider

157

ocenjivakog tima daje predlog ali se ne donosi finalna odluka koja se potvruje od
strane sertifikacionog tela.
Nakon uspeno zavrenog procesa, izdaje se sertifikat po ISO/IEC 27001 standardu.
Sertifikat je validan za period od tri godine, iskljuujui moguu suspenziju ili
povlaenje sertifikacije. Sertifikat se izdaje sa sadrajem koji se odnosi na opseg
ISMS sistema i referencira se na Izjavu o primenljivosti koja je raspoloiva 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 optem sluaju dva puta godinje. Cilj ovog
audita je da se pokrije opseg sertifikacije tokom trogodinjeg ciklusa.
Mogue je da se sprovedu i vanredni dodatni auditi ukoliko je potrebno (specijalne
posete sertifikacionog tela). Na kraju ovog perioda, sertifikaciono telo moe produiti
validnost sertifikata za novi period od tri godine pod uslovom pozitivnog rezultata
procesa ponovnog ocenjivanja.
Vremenski zahtevi procesa ocenjivanja zavise od razliitih faktora:

Veliine opsega aktivnosti koje su pokrivene procesom ocenjivanja,

Brojem lokacija u organizaciji koje se poseuju 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

poboljanje vaeg sistema upravljanja informatikom bezbednou. PDCA model je
jedan ciklini proces koji vam pomae da aurirate va sistem informatike
bezbednosti.
Postoje nekoliko stvari koje moete initi u cilju osiguranja da se odrava eljeni nivo
bezbednosti prema ISO/IEC 27001 standardu, kao to su:

Stalna provera da li bezbednosne kontrole rade i da li su efektivne,

Praenje promena koje mogu imati uticaj na ISMS sistem, kao to su izmene
u rizicima po vau organizaciju, izmene u poslovnim aktivnostima, itd., i
poboljavanje 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
sistem ispravno implementiran i odravan (Da li je opseg ISMS sistema i dalje
validan? Da li su primenjeni bezbednosni mehanizmi i dalje efektivni? Da li postoji
odgovarajui program nadzora i poboljanja? itd.).
Neke promene e se verovatno desiti u vaoj organizaciji pre ili kasnije, kao na
primer: promene u fokusu organizacije, promene IT sistema, promene u proizvodima
ili promene koje se vie odnose na informatiku bezbednost, kao to su nove pretnje
i ranjivosti.

158

Sve te promene mogu imati uticaj na rizike po vau organizaciju, tako da kadgod se
desi neka znaajnija promena, vaa ocena rizika treba da bude preispitana i po
potrebi aurirana, a nove bezbednosne kontrole treba da budu identifikovane kada
god je to neophodno.
Sve nove bezbednosne kontrole koje su identifikovane tokom provere trenutnog
statusa informatike bezbednosti u organizaciji treba da budu implementirane, to
ukljuuje:

Implementaciju svih neophodnih promena, auriranja, novih bezbednosnih

kontrola, modifikovanih procedura, itd.
Auriranje dokumentacije i zapisa gde god se to zahteva.
Revidiranje ISMS sistema ukoliko je potrebno i osiguranje da revizije dostiu
eljene ciljeve.
Kada se sva poboljanja implementiraju, neophodno je informisati sve
zainteresovane jer to moe imati implikacije na njihov posao.

159