Apeiron Pitanja i odgovori 2 1. Faktori autentikacije korisnika Jedno -, dvo i tro komponentni sistemi autentikacije korisnika.

a. Sistemi jake autentikacije dvo komponentni sistemi sa ukljuenom challengeresponse procedurom. Pojavni oblici onoga to se ima: disketa, mini CD, hardverski token, smart kartica, USB smart kartica. Autentikacioni sistemi najvieg kvaliteta dvo ili trokomponentni sistemi autentikacije sa PKI challenge-response procedurom. Jaka autentikacija ovlaenih uesnika u nekom distribuiranom raunarskom sistemu je jedna od najvanijih bezbednosnih funkcija koju dati informacioni sistem treba da implementira. Nain prijavljivanja legalnog korisnika na odreenu raunarsku mreu ili informacioni sistem korienjem standardne procedure unosom korisnikog imena i lozinke sigurno nije dovoljno pouzdano niti dovoljno bezbedno. Naime, postoje tehnike primenom kojih nelegalni korisnik moe u realnom vremenu izvriti rekonstrukciju poverljivih parametara (korisniko ime i lozinka) legalnog korisnika. Komponente (faktori) autentikacije korisnika su: ono to se zna (npr. PIN, username/lozinka), ono to se poseduje (npr. token, smart kartica) i odreena biometrijska karakteristika korisnika (npr. otisak prsta, itd.). Metode jake autentikacije predstavljaju u stvari dvofaktorsku ili dvokomponentnu autentikaciju uz najee primenu odgovarajue challenge-response procedure. 2. S/MIME

Sertifikati dokaz identiteta strana u komunikaciji

3.PKCS#7 standard za digitalno potpisanu i ifrovanu (envelopa) poruku PKCS#7 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. PKCS#7 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#7 standard verzije 2.1 i da su njime znaajno izmenjene preporuke date u PKCS#7 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#7 standard verzije 2.1 je neophodno primeniti u mehanizmima zatite u specijalizovanim raunarskim mreama i informacionim sistemima. 4. Zatita web transakcija 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. Klijentska offline aplikacija (standalone) sa ugraenom kriptografskom bibliotekom treba da ima sledee kriptografske karakteristike: Primena mehanizmima zatite na aplikativnom nivou kojima se obezbeuju sledee funkcije: o o o Autentinost potpisnika (asimetrini kriptografski algoritam i tehnologija digitalnog potpisa), Zatita integriteta fajlova (asimetrini kriptografski algoritam i tehnologija digitalnog potpisa), Obezbeenje neporecivosti (asimetini kriptografski algoritam i generisanje kljueva na samim smart karticama i tehnologija digitalnog potpisa), Zatita tajnosti podataka (simetrini kriptografski algoritam i tehnologija digitalne envelope).

Skraenica Secure / Multi Purpose Internet Mail Extension Predstavlja bezbednosno proirenje standardnog MIME formata za e-mail poruke Digitalna envelopa, digitalni potpis Bazira se na: postojeim javnim kriptografskim standardima (PKCS) standard za poruke (MIME) standard digitalnih certifikata (X.509) iroko prihvaen standard

S / MIME (Secure / Multipurpose Internet Mail Extensions) je protokol koji osigurava digitalne potpise i enkripciju Internet MIME poruka. S / MIME, koja koristi RSA (Rivest-Shamir-Adleman) javni-klju za ifriranje tehnologije, je sigurna metoda za slanje e-pote. S / MIME definira kako digitalni certifikat i kodiranje informacije mogu se osigurati kao dio tijela poruke. S / MIME protokolu slijedi sintaksu kako je propisano u PCKS # 7 (Public-Key Cryptography Standard format broj 7). S / MIME predloena je od strane RSA kao standard za Internet Engineering Task Force (IETF). PGP / MIME je alternativa za S / MIME. S / MIME kriptografske prua sigurnosne usluge za e-aplikacije kao to su: integritet poruke, autentifikaciju, a ne-povreda porijekla, privatnosti i sigurnost podataka. Funkcionalnost S / MIME je ugraen u veinu recentnih izdanja sustava e-potu programa ukljuujui Gmail, Outlook Express, Apple Mail, Mozilla Thunderbird, The Bat!, Lotus Notes, Netscape Communicator, Gnus, KMail, Balsa, i Sun Java Messaging . S/MIME je IETF standard koji definie zatitu elektronikih poruka, a ukljuuje enkripciju sadraja i digitalno potpisivanje. Rije je o elementu sigurnosti na nivou aplikacije, to znai da se zatita i provjera poruka odvija u klijentu elektronike pote. Budui da S/MIME nije jedini dostupni standard ove namjene, niti je podran u svim klijentima elektronike pote, njegova upotreba moe biti poneto nepraktina. Metode na koje se oslanja S/MIME su pouzdani kriptografski algoritmi za (de)kriptiranje sadraja, izraunavanje saetaka poruka te za generisanje i provjeru digitalnih potpisa. Zatiene poruke umeu se kao prilog u jasni MIME format i tako alju kroz Internet.

Koriste se tehnologije digitalnog potpisa i digitalne envelope. Univerzalnost u odnosu na smart kartice i itae smart kartice. Klijentska aplikacija 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. Bazira se na kriptografskim operacijama koje se izvravaju na samoj smart kartici: digitalni potpis i deifrovanje simetrinog kljua kod digitalne envelope . Bazira se na PKCS de facto standardima za zatitu, i to: o o PKCS#1 za digitalni potpis i digitalnu envelopu, PKCS#7 za format zatienih podataka, PKCS#11 standardni interfejs za pristup smart karticama.

o
S/MIME zatita Digitalni potpis Digitalna envelopa zatita tajnosti podataka provera autentinosti potpisnika zatita integriteta podataka neporecivost

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. 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. Klijentska i serverska kripto komponenta treba da u ovom trenutku podri sledee kriptografske algoritme i pridruene duine kljueva: o Asimetrini algoritmi RSA algoritam (koji se izvrava na smart kartici) sa duinom asimetrinog kljua od 2048 bita. Hash algoritmi SHA-1, SHA-224, SHA-256, SHA-384 ili SHA-512.

Simetrini algoritmi 3DES algoritam sa duinom kljua od 168 bita ili AES algoritam sa duinama kljua od 128, 192 ili 256 bita.

5. PGP Pretty Good Privacy, osnovne karakteristike: Raspoloive verzije za razliite operativne sisteme, Bazira se na primeni testiranih algoritama kao to su: RSA, IDEA, MD5.

Digitalni potpis: RSA + MD5

Nije razvijan niti kontrolisan od nekog dravnog tela za standarde. Kriptografska hash vrednost poruke se dobija primenom MD5 algoritma. Digitalni potpis, dobijen primenom, nad sadrajem hash-a, operacije sa privatnim RSA kljuem, dodaje se poruci.

Tajnost: RSA + IDEA

Klijent inicira konekciju Klijent alje client version number (3.1 za TLS). alje ClientNonce (28 random bajta plus 4 bajta kao oznaku vremena). alje listu podranih kripto algoritama (Oznaka algoritama za razmenu kljua, postupaka ifrovanja, oznake hash funkcija. Npr. TLS_RSA_WITH_3DES_EDE_CBC_SHA). M2: S C: ServerHello, ServerCertChain, ServerHelloDone Server alje server version number. alje ServerNonce i SessionID. Selektuje jedan kriptomehanizam iz liste podranih algoritama klijentske strane (Npr. TLS_RSA_WITH_3DES_EDE_CBC_SHA). alje ServerCertChain poruku (Omoguava da klijent izvri autentikaciju javnog kljua servera). Optional CertRequest poruka (Izostavlja se ukoliko se ne vri autentikacija klijenta). I na kraju, ServerHelloDone poruka. M3: C S: ClientKeyExchange, ChangeCipherSpec, ClientFinished

Poruka ClientKeyExchange sadri ifrat dobijen primenom, nad pre_master_secret, operacije sa javnim kljuem servera. Poruka ChangeCipherSpec oznaava da je na klijentskoj strani izvren odabir mehanizama ifrovanja, za datu sesiju, u skladu sa indikatorom dobijenim od servera.

Poruka se ifruje korienjem IDEA algoritma, primenom jednokratnog sesijskog kljua koga generie poiljalac. Sesijski klju se ifruje sa javnim RSA kljuem primaoca i dodaje se poruci. Kompresija podataka: ZIP algoritam Poruka se moe, pre realizacije kriptografskih operacija, saeti (kompresovati) korienjem ZIP algoritma. ifrovana poruka se konvertuje u ASCII string. Autentikacija: Poiljalac kreira poruku. SHA-1 se koristi za kreiranje 160-bitnog hash otiska poruke. Otisak poruke se se ifruje korienjem RSA algoritma primenom privatnog kljua, i rezultat ifrovanja se dodaje poruci. Primalac koristi RSA algoritam (operacija sa javnim kljuem poiljaoca) da bi izvrio deifrovanje hash koda. Primalac generie vrednost hash koda primljene poruke i komparira sa deifrovanom vrednou izvornog hash koda, i ukoliko su te vrednosti identine, poruka se prihvata kao autentina.

alje poruku korienjem SSL Change Cipher Spec. Protocol.

(optional) ClientCertificate, ClientCertificateVerify poruke. Samo kada se vri autentikacija klijenta.

Zavrna, ClientFinished poruka.

MAC vrednost nad svim poslatim porukama. MAC se odreuje korienjem master_secret. M4: S C: ChangeCipherSpec, ServerFinished

ChangeCipherSpec oznaava da je server prihvatio, za datu sesiju, odabrani mehanizam ifrovanja. Na kraju se alje ServerFinished poruka.

MAC vrednost nad svim poslatim porukama MAC se izraunava korienjem master_secret. Server moe iskljuivo da odredi MAC vrednost ukoliko je izvrio deifrovanje pre_master_secret u koraku M3.

Tajnost: Poiljalac kreira poruku i psudosluajnu 128-bitnu vrednost koja se koristi kao sesijski klju iskljuivo za datu poruku.Poruka se ifruje primenom CAST-128/IDEA / 3DES algoritma korienjem sesijskog kljua. Sesijski klju se ifruje RSA algoritmom primenom operacije sa javnim kljuem primaoca. ifrovana vrednost se dodaje na sadraj poruke. Primalac koristi RSA algoritam (operacija sa privatnim kljuem) da bi izvrio deifrovanje sesijskog kljua. Sesijski klju se koristi za deifrovanje poruke.

7. IPSec IPsec (Internet Protokol security) je standard i skup protokola (opcionalan za IPv4, a obavezan za IPv6) koji obuhvaa mehanizme za zatitu prometa na razini treeg sloja OSI modela - kriptiranjem i/ili autentifikacijom IP paketa.

6. SSL serverska i klijentska autentikacija SSL je protokol zatite na transportnom nivou namenjen za zatitu tajnosti podataka i ouvanja autentinosti poruka npr. izmeu web client-a i web servera. M1: C S: ClientHello

IPsec osigurava ispunjenje sljedeih sigurnosnih zahtjeva: tajnost (confidentiality; iskljuivo ovlatena osoba moe pristupiti podacima), besprijekornost (integrity; nemogunost promijene podataka od strane neovlatene osobe), autentinost (authentication; verifikacija identiteta poiljaoca), raspoloivost (availability; dostupnost podacima unato neoekivanim dogaajima, npr. DOS napad i sl.). Spomenuti zatitni mehanizmi IPsec-a zasnivaju se na: Sigurnosnim protokolima: Encapsulating Security Payload (ESP) i Authentication Header (AH)), Specifinoj arhitekturi: Security Association (SA) unosi u Security Association Database (SAD) u jezgru OS-a i Security Policy (SP) unosi u Security Policy Database (SPD) u jezgru OS-a. Algoritmima za autentifikaciju i kriptiranje (npr. DES, 3DES, RSA, DH, SHA1, MD5 i dr). Protokolima za razmjenu kljueva: Internet Key Exchange ( IKE), Internet Key Exchange v2 (IKEv2), Kerberized Internet Negotiation of Keys (KINK), Just Fast Keying (JFK) i dr. Protokol IPsec je namenski bezbedonosni protokol koji poseduje sve atribute za formiranje Virtuelnih privatnih mrea preko Interneta. Sa enkapsulacijom IPsec protokol omoguuje autentifikaciju i enkripciju svakog IP paketa u prenosu. To je veoma sloen protokol koji sadri dva tipa AH(Authentication Header) i ESP(Encapsulating Security Payload), a svaki taj tip ima dva moda transport i tunel. ESP format IPsec protokola obezbeuje autentifikaciju, integritet i privatnost podataka, dok AH format obezbeuje samo autentifikaciju i integritet. U transpornom modu svaki od ova dva tipa bezbedno prenose postojei IP paket od izvora do odredita, dok u tunel modu se postojei paket stavlja unutar novog IP paketa sa IP adresom gejtveja virtuelne privatne mree koji je krajnja taka tunela. Ipsec protokol ukljuuje u sebe vei broj drugih protokola pomou kojih obavlja funkcije autentifikacije, integriteta i privatnosti, kao osnovnoh bezbedonosnih elemenata virtuelne privatne mree. Za autentifikaciju IPsec protokol koristi PKI (Public Key Infrastructure) tehniku javnog i privatnog kljua sa infrastrukturom Digitalnog sertifikata preko Sertifikacionih tela (X.509 Sertificate) /10/. IKE (Internet Key Exchange) protokol /11/ sa Diffie-Hellman algoritmom /12/ se koriste u procesu razmene kjueva i pregovaranju bezbedonosnih elemenata. U okviru IPsec protokola integritet podataka obezbeuju protokoli HMAC-MD5 /13/ i HMAC-SHA-1 /14/, a privatnost IP paketa je obezbeena enkripcijom sa 3DES (DES) algoritmom /15/. S obzirom da IPsec AH tip ne obuhvata enkripciju, za virtuelne privatne mree koristi se uglavnom ESP tip, i to tunel mod, koji obuhvata enkripciju i IP zaglavlja polaznog paketa. Na slici 3a je prikazana enkapsulacija IP paketa sa IPsec ESP protokolom u tunel modu. Orginalni IP paket je kriptovan i autentifikovan sa ESP zaglavljem i prirepkom , a novo IP zaglavlje definie IP adresu krajnje take tunela. 8.Firewall ureaji Mrene barijere (firewall) mogu biti raunari, ruteri, radne stanice ili njihove kombinacije koje imaju osnovnu funkciju da definiu kojim se informacijama i servisima interne mree moe pristupiti iz spoljnjeg sveta i kome je, iz interne mree, dozvoljeno da koristi informacije i usluge spoljnjih segmenata mree. Ove barijere se uobiajeno instaliraju na takama gde se spajaju bezbedno osetljive interne mree i nebezbedne spoljnje mree. U zavisnosti od potreba, firewall se sastoji od jedne ili vie funkcionalnih komponenti iz sledeeg skupa: ruter paketskog filtriranja, gejtvej na aplikacionom nivou (Application Level Gateway proksi) i gejtvej na transportnom nivou (Circuit Level Gateway). Postoje etiri vana primera mrenih barijera: Packet Filtering Firewall, Dual-Homed Firewal (sadri dve mrene kartice), Screened Host Firewall (sastoji se od rutera paketskog filtriranja i gejtveja na aplikativnom nivou) i Screened Subnet Firewall (sastoji se od dva rutera paketskog filtriranja i gejtveja na aplikativnom nivou). Paketski filtri

Aplikacijski filtri

Hibridni filtri

Protokolski filtri

9.Softverska i hardverska reenja zatite Reenja sistema zatite TCP/IP raunarskih mrea koja se baziraju na potpuno softverskim mehanizmima ne pruaju najvii nivo bezbednosti sistema niti nude potpunu odbranu od potencijalnih napada na mreu, kao na primer od napada tipa Trojanskog konja. Hardverski bezbednosni moduli, realizovani u vidu raunarskih koprocesora, predstavljaju veoma bitnu karakteristiku savremenih reenja zatite raunarskih mrea.

Osnovne funkcije navedenih proizvoda su poveanje bezbednosti sistema i ubrzavanje kriptografskih funkcija, kao to su asimetrini i simetrini kriptografski algoritmi. Hardverski kriptografski koprocesori se predviaju za korienje u serverskim aplikacijama i eventualno u klijentskim aplikacijama gde se zahteva visok nivo bezbednosti (vojska, policija, SMIP, specijalizovane slube). Za najiri vid korienja sistema zatite (npr. pojedinci), korienje smart kartica kao poverljive hardverske platforme je primerenije. Smart kartica-Mikroprocesorski upravljana uz posedovanje PIN kodom zatienih delova memorije. Kriptografske funkcije se realizuju na smart karticama:

Asimetrini algoritam. PKI sistemi se baziraju na primeni kriptografskog hardvera, kako za korisnike (smart kartice), tako i za CA (HSM). Korisniki kljuevi mogu da budu izgenerisani na HSM i uvani, zajedno sa sertifikatom, na smart kartici. Osnovna svrha kriptografskog hardvera CA je da se tajni kljuevi CA nikada ne pojavljuju u otvorenoj formi van HSM. Sve kriptografske funkcije treba da se izvravaju na HSM modulu. Generisanje i uvanje kljueva mora biti realizovano u okviru HSM. Treba na odgovarajui nain realizovati zatieni back-up kljueva i ostalih kripto parametara. HSM mora posedovati funkciju detekcije pokuaja naruavanja bezbednosti HSM.

Generisanje i uvanje kljueva,

Contactless ili smart kartice bez kontaktnih povrina Kontaktni izvodi kod kartica sa kontaktima izvedeni su prema standardu ISO 7816. Pouzdanost ovih kartica je u novije vrijeme znaajno poveana na osnovu iskustva steenog u njihovoj proizvodnji. Ipak, njihove kontaktne povrine su i dalje jedan od najeih razloga za pojavu greaka ili kvara. Osjetljive su na razne tetne uticaje, vibracije u mobilnim telefonima koje utiu na kvalitet ostvarenog kontakta, kao i na pojavu vlage ili prljavtine na kontaktim povrinama. Takoe pranjenje statikog elektriciteta moe otetiti unutranje elektronske komponente. Nabrojani tehniki problemi i se mogu otkloniti uvoenjem bez-kontaktnih kartica. Ovaj tip kartice ne mora biti prisutan u itau da bi se podaci sa nje oitali. Distanca od itaa moe biti oko metar udaljenosti, to znaajno olakava mnoge aspekte njene upotrebe. Pored toga, elektronska logika je potpuno integrisana u telu kartice i nije vidiljiva na njenoj povrini. Ipak, zbog kompatibilnosti sa velikim brojem standardnih kontaktnih itaa koji su i danas u upotrebi u mnogim sferama, bez-kontaktne kartice se esto proizvode sa pridruenim kontaktnim izvodima. Ove kartice se nazivajudual-interface kartice ili combicard kartice. 11. Arhitektura i operativni sistemi smart kartica Postoji nekoliko vrsta smart kartica: Memorijske kartice, Mikroprocesorske smart kartice sa korienjem 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, preteno su to 8bitni mikrokontroleri, i to najee iz klase Intel 80C51 mikrokontrolera. U poslednje vreme se pojavljuju i smart kartice bazirane na 16-bitnim i 32-bitnim mikrokontrolerima. 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 softvera na PC raunaru. Primena smart kartica umnogome zavisi od operativnog sistema implementiranog na primenjenom ipu, kao i od eventualnih preprogramiranih aplikacija. U odnosu na primenjene operativne sisteme, smart kartice se dele na: smart kartice sa privatnim operativnim sistemom 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) i male mogunosti prilagoenja (kastomizacije) implementiranih funkcija na smart kartici. Sa druge strane, JAVA kartice nude veu mogunost kastomizacije zahvaljujui postojanju JAVA virtualne maine koja izvrava JAVA aplete definisane od strane korisnika na samoj kartici. Meutim, s obzirom da su se pojavile u skorije vreme, JAVA kartice su skuplje od obinih kartica i bolje rade na ipovima koji se baziraju na jaim mikroprocesorima (16-bitni i 32-bitni). 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 isporuioci 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, Phillips i Siemens-Infineon su tradicionalni proizvoai ipova, dok su: GemPlus, SchlumbergerSema, Oberthur, Bull, Giesecke & Devrient, Datacard, ActivCard, Orga, 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 kompaniji, itd. (beskontaktni ip). U okviru PKI sistema, smart kartice imaju sledeu funkcionalnost i obeleja: Generisanje kljueva na smart kartici generisanje para kljueva asimetrinog kriptografskog algoritma, kao i zahtevanog broja simetrinih kljueva (opciono), realizuje se unutar smart kartice. Bezbedno uvanje kriptografskih parametara kljuevi i se bezbedno uvaju u zatienom delu memorije smart kartice. Smart kartice su same po sebi tamperproof moduli. Smart kartica je sposobna da realizuje kriptografske funkcije na samoj kartici ali sporije nego na HSM modulima. 12. 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.

10. Tipovi smart kartica Postoji nekoliko vrsta smart kartica: Memorijske kartice, Mikroprocesorske smart kartice sa korienjem, Smart kartice bez kontaktnih povrina. Memorijske kartice Ovaj tip kartice je prvi put masovnije korien u vidu telefonskih kartica. To su pretplatnike kartice kod kojih se tokom njihove upotrebe smanjuje inicijalna vrednost kredita za telefoniranje. Osnovna sigurnosna potreba, da se korisnik sprei da sam uveava iznova vrednost kredita, nije ostvariva korienjem kartica sa magnetnom trakom, jer bi svaki korisnik sa potrebnom opremom to mogao da izvede.

U tom smislu upotreba smart memorijskih kartica je daleko praktinija, obzirom da ovaj tip kartica sadri potrebnu elektronsku logiku koja spreava naknadne manipulacije sa vrijednostima zabiljeenim na kartici u momentu izdavanja. Podaci potrebni nekoj aplikaciji se nalaze unutar memorije, obino EEPROM tipa. Pristup memoriji kontrolie sigurnosna logika, koja se u najprostijem obliku sastoji od zabrane upisivanja i brisanja podataka u memoriji ili nekim njenim segmentima. Smart kartice sa mikroprocesorom Centralni dio ovih kartica ini mikroprocesorski ip obino okruen dodatnim funkcionalnim blokovima: mask ROM-om, EEPROM-omom i RAM-om kao i I/O portom, to sve zajedno pripada pod termin mikrokontroler.

Unutar ROM ipa se nalazi operativni sistem kartice koji se tamo postavlja tokom proizvodnje kartice. Sadraj ovog ROM ipa je identian kod svake kartice i ne moe se kasnije menjati. EEPROM ip predstavlja NVM memoriju ili memoriju koja uva podatke i bez napajanja i u koju se podaci mogu upisivati i iz nje itati, a kontrolu njenih funkcija vri unutranji operativni sistem. RAM ip predstavlja radnu memoriju procesora, a ova memorija gubi sve podatke prestankom njenog napajanja. Serisjki I/O interfejs se sastoji od jednog registra preko koga se podaci prenose bit po bit.

Smart kartice sa mikroprocesorom mogu imatu irok spektar primene. U jednostavnijim sluajevima sadre jednu aplikaciju za odreenu namjenu, ali za dananje interne operativne sisteme, uobiajeno je da rade sa vie aplikacija istovremeno. Tada je praksa da interni OS inicijalno dolazi u smanjenom obimu sa osnovnim komponentama, a da se prilikom instalacije naknadnih aplikacija zajedno sa tim aplikacijama dodaju specifini dijelovi operativnog sistema. Novi momenti u razvoju ovih kartica omoguavaju dodavanje aplikacija ak i kada je ve obavljena personalizacija kartice i kada je ona izdata korisniku. Za tu namjenu na tritu se ve dostupne kartice sa snanijim procesorima i veim kapacitetom memorije. Da bi se spreile eventualne manipulacije prilikom naknadnog dodavanja aplikacija, koriste se posebne hardverske i softverske preventivne mjere.

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, SHA-1, 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). 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 softverskohardverske 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.

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. 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. Dname predstavlja put kroz X.500 direktorijum, tako da se jedino moe sastojati iz sledeih polja: Dvoslovni niz koji oznaava dravu, Region, Elektronska adresa, Firma, Odeljenje u firmi,

NST2000
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. 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.

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. 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 X.509, je prikazan je na slici.

14. Komponente PKI sistema

13. Digitalni sertifikati sadraj 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. Digitalni sertifikati predstavljaju mehanizam za pouzdano pridruivanje asimetrinog para brojeva (privatni i javni klju) identitetu nekog subjekta, tako da se ta veza ne moe falsifikovati.

Osnovni dokument rada PKI sistema - Politika sertifikacije (CP Certificate Policy), CPS Certificate Practice Statement Sertifikaciono telo (CA) Registraciono telo (RA)

DSP

Sistemi za distribuciju sertifikata PKI aplikacije

Osnovni dokument rada PKI sistema - Politika sertifikacije (CP Certificate Policy) utvruje osnovne principe rada sertifikacionog tela i ostalih komponenata PKI sistema. CPS Certificate Practice Statement predstavlja dokument koji praktino opisuje rad Sertifikacionog tela (CA Certification Authority) i neophodan je u sluaju komercijalnog CA. CPS predstavlja jedan detaljan dokument koji sadri operacione 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:

Ovlaeno eksterno telo (CA) preuzima line podatke odreenog korisnika i njegov javni klju, formatira sve te podatke na standardni nain, u obliku digitalnog sertifikata, koga zatim digitalno potpie. Digitalni sertifikat, na osnovu digitalnog potpisa CA, predstavlja pouzdanu vezu identiteta odreenog korisnika i njegovog javnog kljua. 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 i kriptografski softverski sistemi mogu procesirati.

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, Upravlja rokom vanosti izdatih digitalnih sertifikata,

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. Registraciono telo (RA) obezbeuje interfejs izmeu korisnika i CA.

Slika: sertifikaciono tijelo

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, 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 i sertifikata krajnjih korisnika. CA takoe digitalno potpisuje sertifikate podreenih CA, kao i drugih CA u sluaju unakrsne sertifikacije (cross certification). Publikovanje CRL (Certificate Revocation List) CA digitalno potpisuje sve informacije objavljene u formi CRL. 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 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. 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 Certificate Status Protocol) 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.

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 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. PKI aplikacije itav PKI sistem se kreira da podri rad veeg broja aplikacija, kao to su:

Zatita WEB transakcija, Zatita e-mail servisa, VPN virtuelne privatne mree, Bezbedno upravljanje elektronskom dokumentacijom, Sistemi dvo-faktorske autentikacije,

Sistemi upravljanja identitetom, ... 15. Sertifikaciono tijelo 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 kriptografskog algoritma i asimetrinog privatnog kljua CA. CA funkcionie na bazi sopstvene fleksibilne politike rada, i kontrolisano je od strane CAO i drugih administratora. Sertifikaciono telo predstavlja softversko-hardversku aplikaciju koja, kao ulazni parametar, uzima javni klju asimetrinog kriptografskog sistema, smeta ga u okvir digitalnog sertifikata i sve to, zajedno sa ostalim podacima, digitalno potpisuje u cilju garancije da dati javni klju pripada definisanom korisniku (vlasniku datog digitalnog sertifikata). Za razliku od samopotpisanih sertifikata, digitalni sertifikati potpisani od strane CA koji se izdaju korisnicima impliciraju da je CA, kao trea strana od poverenja, proverila da dati javni klju pripada definisanom korisniku i da svojim potpisom sertifikuje da je to istinito.

CA treba da podri razliite hardverske elemente, kao to su: smart kartice za krajnje korisnike, hardverski bezbednosni moduli (HSM Hardware Security Module) i drugi tokeni. 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 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.

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.

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. 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.

Modul operatora Sertifikacionog tela (CAO) predstavlja modul za administraciju, nadzor i bezbednost CA i itavog PKI sistema koji se bazira na datom CA. CAO kontrolie sve administratorske funkcije u sistemu i dodeljuje odgovarajue privilegije ostalim administratorima, modulima i podsistemima. 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 politike izdavanja sertifikata. CAO takoe odrava politike i procedure rada 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 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. Generisanje kljueva CAO je 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 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). CAO treba da podri razliite hardverske elemente, kao to su: smart kartice za krajnje korisnike, hardverski bezbednosni moduli (HSM Hardware Security Module) i drugi tokeni. Poseduje grafiki interfejs, jednostavan za korienje. Procesira sertifikate i CRL. Svaki CAO moe imati razliite nivoe privilegija.

Svaki ulazni slog ima jedinstveni procesni broj. RA treba da podri razliite hardverske elemente, kao to su: smart kartice za krajnje korisnike, hardverski bezbednosni moduli (HSM Hardware Security Module) i drugi tokeni. 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. 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 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. 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 u PKCS#7 formatu. Arhiviranje podataka svi podaci i log fajlovi se arhiviraju u bazi podataka RA. Sve arhivirane informacije su digitalno potpisane od strane RAO. Svaki ulazni slog ima jedinstveni procesni broj.

16. 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.

RAO treba da podri razliite hardverske elemente, kao to su: smart kartice, hardverski bezbednosni moduli (HSM Hardware Security Module) i drugi tokeni.

Poseduje grafiki interfejs jednostavan za korienje. 17. Osnovni dokumenti rada CA

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 certifikate i zahteve za izdavanje certifikata. Ovaj deo bezbednosne politike se naziva Politika certifikacije, koja predstavlja poseban dokument. Upravljanje politikom rada odreenog PKI sistema vri certifikaciono telo. U tom smislu, sve PKI aplikacije koje koriste softverske i hardverske kriptografske mehanizme centralno se upravljaju, to redukuje trokove i poveava nivo kontrole. Certifikaciono telo pre poetka rada utvruje Opta pravila pruanja usluge certifikacije 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:

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

Certifikaciono telo moe, pored gore navedenih servisa, da obezbedi i: formiranje asimetrinog para kljueva za korisnike, kao i distribuciju privatnog kljua i certifikata korisniku na bezbedan nain, sredstvo za formiranje kvalifikovanog elektronskog potpisa korisnicima i pridruenu lozinku (ili PIN kod) za aktivaciju sredstva, kao i njihovu bezbednu distribuciju do korisnika, ako je to u skladu sa svojim Optim i Internim pravilima rada.

Sadraj dokumenta Politika certifikacije, prema ETSI TS 101 456 Policy Requirements for Certification Authoritites Issuing Qualified Certificates, obuhvata sledea poglavlja i teme, i to:

Politika certifikacije (Certificate Policy) i Praktina pravila pruanja usluge Certifikacije (CPS Certification Practice Statement (u daljem tekstu: Praktina pravila)).

Opte odredbe o radu certifikacionog tela Pojam certifikacionog tela, Certifikacione usluge, Obuhvat dokumenta Politika certifikacije, Obuhvat dokumenta Praktina pravila pruanja usluge certifikacije, Korisnici usluga certifikacije.

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

Uvodne odredbe o Politici izdavanja kvalifikovanih elektronskih certifikata Obaveze i odgovornosti

Pod kojim uslovima se izdaju certifikati, Koje informacije treba da budu ukljuene u certifikat, Za koju svrhu se koristi dati certifikat, i ta se deava kada istekne vanost certifikata (kada certifikat doe do kraja svog ivotnog veka).

Obaveze certifikacionog tela, Obaveze korisnika, Odgovornost certifikacionog tela, Odgovornost korisnika.

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

Funkcionalni zahtevi za rad certifikacionog tela a) Operativna pravila rada certifikacionog tela b) Procedure upravljanja ivotnim ciklusom kriptografskih kljueva

Odluivanje koji sve elementi jedinstvenog imena (distinguished name Dname) koji jedinstveno identifikuju korisnika treba da se pojave u svim certifikatima koji su izdati u skladu sa politikom certifikacije (neki elementi mogu biti opcioni), Odreivanje koje ekstenzije e se pojaviti u certifikatima izdatim u skladu sa ovom politikom, Odluivanje koje dodatne registracione informacije treba da budu prikupljane u cilju izdavanja certifikata. Ove informacije se ne publikuju u certifikatu, i Odreivanje dodatnih operacionih ogranienja koja treba da budu sprovedena u vezi izdavanja i korienja certifikata.

Generisanje kljua certifikacionog tela, Procedure uvanja i formiranja rezervnih kopija kljueva certifikacionog tela, Distribucija javnog kljua certifikacionog tela, Korienje kljua certifikacionog tela, Kraj ivotnog ciklusa kljua certifikacionog tela, Upravljanje ivotnim ciklusom kriptografskog hardvera koji se koristi za generisanje kvalifikovanih certifikata,

Certifikaciono telo je odgovorno za pruanje kompletnih usluga certifikacije, koje ukljuuju sledee servise, i to:

Upravljanje kljuevima korisnika identifikaciju i digitalnu envelopu,

za

strukturnih kolapsa, zatitu od poplava, zatitu od krae, loma i upada u sistem, oporavak nakon katastrofe, itd.upadi u prostorije ili informacioni sistem certifikacionog tela).

Procedura pripreme sredstava za formiranje kvalifikovanog elektronskog potpisa.

18. Upravljanje ivotnim vekom ertifikata U okviru Politike sertifikacije datog certifikacionog tela neophodno je specificirati procedure upravljanja ivotnim vekom sertifikata, kao to su:

v) Procedure upravljanja ivotnim ciklusom certifikata Metode registracije korisnika, Izdavanje certifikata, Distribucija certifikata, Obnavljanje certifikata, Suspenzija certifikata, Opoziv certifikata, Nain publikacije liste opozvanih certifikata.

povlaenje, obnavljanje i suspenzija.

Obnavljanje sertifikata - Korisniki sertifikati vae ogranieni vremenski period, na primer godinu dana, to je propisano u okviru Politike sertifikacije CA. Moe biti propisan period pre isteka perioda vanosti certifikata kada e se u okviru sprcifine 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 mogu da se poklapaju, obnavljanje se moe istovremeno vriti za oba sertifikata (dva serijska broja) koji su povezani istim registarskim brojem korisnikim imenom. Potrebno je dodatno istai da se obnavljanje mora izvriti pre isteka roka vanosti certifikata. 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 sertifikat koji ima specificiran rok vanosti od datuma obnavljanja.

g) Upravljanje operativnim radom certifikacionog tela Upravljanje u skladu sa bezbednosnim principima, Upravljanje i klasifikacija najvanijih informacija i podataka u okviru certifikacionog tela, Kadrovski resursi,

Povlaenje ertifikata Sistem fizike bezbednosti i bezbednosti okruenja, Upravljanje radom certifikacionog tela, Upravljanje sistemom kontrole pristupa, Upotreba i odravanje kriptografskih sistema, bezbednih

Korisniki sertifikati se mogu povui (opozvati) iz generalno dva tipa razloga:

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

Upravljanje procedurama kontinualnog poslovanja u incidentnim situacijama, Prestanak rada certifikacionog tela, Usaglaenost rada sa kriterijumima za rad certifikacionih tela koja izdaju kvalifikovane elektronske certifikate u skladu sa Zakonom, Formiranje i uvanje dokumentacije koja se odnosi na kvalifikovane certifikate,

Dolo je do gubitka asimetrinog privatnog klja korisnika ili je iz bilo kog razloga dolo do kompromitacije 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 moe izvriti istovremeno za oba sertifikata koji su izdati 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 sertifikati ne mogu nikada ponovo aktivirati. Proceduru suspenzije sertifikata uglavnom vre ista lica kao i u sluaju povlaenja.

d) Organizacija rada certifikacionih tela.

Certifikaciono telo demonstrira sposobnost za obezbeivanje usluga izdavanja digitalnih certifikata, tako to mora: Imati Praktina pravila, i u njima definisane procedure, u kojima se specificira nain ispunjenja svih zahteva za izdavanjem digitalnih certifikata koji su identifikovani u Politici certifikacije. Uiniti raspoloivim Praktina pravila rada svim korisnicima i drugim zainteresovanim stranama. Objaviti svim korisnicima i potencijalnim zainteresovanim stranama uslove korienja digitalnih certifikata. Imati upravnu strukturu najvieg nivoa koja e imati konanu autorizaciju i odgovornost za objavljivanje Praktinih pravila rada certifikacionog tela. Imati upravnu strukturu operativnog nivoa u certifikacionom 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. Interna pravila se baziraju na bezbednosnoj politici certifikacionog tela u smislu fizike zatite i zatite sistemskog okruenja za generisanje digitalnih certifikata, 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

19. CRL (Lista povuenih sertifikata)

Lista povuenih sertifikata (CRL) 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 povlaenja,

sertifikata

sa

razlogom

njihovog

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

uvek obezbeuje poslednja verzija CRL sa veoma zauzetog direktorijumskog servera (ili neke druge CRL distribucione take).

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:

CRL se kreira i publikuje periodino, pri emu je taj period odreen Prakitnim pravilom rada CA (CPS). 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. CA digitalno potpisuje CRL tako da krajnji korisnici mogu biti sigurni u integritet i autentinost informacija u okviru CRL. 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. U sluaju suspenzije, 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. 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 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.

Proveriti validnost digitalnog sertifikata datog korisnika, Uzeti serijski broj sertifikata, Pristupiti (uitati) CRL (obino se to radi downloadovanjem 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, 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 certifikate 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

20. CA kao web vieslojna arhitektura 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

10

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. 21. Generiki model CA kao web vieslojne aplikativne arhitekture U okviru realizacije kompletnog PKI sistema, kljuna je realizacija softverskohardverskog 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. Bezbedan sistem primena najnovijih rezultata iz oblasti generisanja kriptografskih kljueva i primene kriptografskih algoritama.

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. 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. 22.Kvalifikovani elektronski potpis Prema Zakonu o elektronskom potpisu i podzakonskim aktima, kvalifikovani elektronski potpis mora da ispunjava sledee uslove:

Eksterna mrea

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 certifikatu potpisnika i formiran je sredstvima za formiranje kvalifikovanog

Ruter Sistem CA Firewall WEB server CA DMZ zona Crypto engine CA HSM Baza podataka CA Aplikativni server CA

elektronskog potpisa. LDAP Dalje, prema Zakonu o elektronskom potpisu, kvalifikovan elektronski potpis u odnosu server 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.

Root CA HSM Root CA OffLine

Interna mrea CA OnLine CA

Sertifikaciono telo se sastoji od OnLine i OffLine dela. OffLine deo predstavlja Root CA koje se koristi samo u izuetnim sluajevima kada se formira asimetrini privatni klju i sertifikat za novi Intermediate CA u hijerarhijskoj strukturi, 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. 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, HSM ili smart kartica, Intermediate CA koja se zatim postavi u HSM ureaj novog, posebno za taj Intermediate CA obezbeenog, Crypto Engine servera. Zatim se obrie privatni klju Root CA iz HSM ureaja i specijalne smart kartice sa delovima za aktivaciju kljua se vrate u trezor. 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 sertifikatima 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

Dakle, da bi se ostvario kvalifikovani elektronski potpis neophodno je da potpisnik ima kvalifikovani elektronski certifikat koga izdaje certifikaciono telo koje ispunjava odreene uslove definisane u Direktivi Evropske Unije o elektronskim potpisisma 1999/93/EC od 19.01.2000. godine. CA Drugim reima, CA koje izdaje kvalifikovane elektronske certifikate treba da ispuni uslove za izdavanje kvalifikovanih certifikata u skladu sa Direktivom Evropske unije o elektronskim potpisima i domaem Zakonom o elektronskom potpisu. , (Annex II):

Da demonstrira neophodnu sposobnost za pruanje certifikacionih usluga, Da garantuje pouzdan rad i da obezbedi pouzdane servise prikaza lista vaeih i povuenih certifikata, Da obezbedi neophodnu preciznost u vezi datuma i vremena izdavanja ili povlaenja certifikata, Da pouzdano verifikuje identitet vlasnika certifikata 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 certifikata i garantuje tajnost procesa generisanja para kljueva za digitalno potpisivanje ukoliko se taj par generie kod certifikacionog tela, Da obezbedi odgovarajua materijalna sredstva za siguran i bezbedan rad i da omogui odreenu emu osiguranja od lairanja certifikata,

11

Da vri zapisivanje svih relevantnih informacija koja se tiu certifikata u odgovarajuem periodu vremena (posebno za sluajeve kada se zahteva uvid u evidenciju certifikata za pravne svrhe); ovi zapisi mogu biti elektronski, Da ne uva ili kopira tajni klju za generisanje kvalifikovanog elektronskog potpisa vlasnika certifikata za koga Certifikaciono telo obezbeuje servis generisanja para kljueva za digitalno potpisivanje, Da precizno upozna osobu koja zahteva izdavanje certifikata sa svim uslovima korienja certifikata,

- elektronska pota - elektronski ugovori - pristup bezbednim web sajtovima (ssl autentikacija) - elektronsko potpisivanje dokumenata - verifikaciju elektronskog potpisa - ifrovanje i deifrovanje dokumenata u elektronskom obliku Certifikaciono tijelo koje izdaje kvalifikovane elektronske certifikate treba da ispuni uslove za izdavanje kvalifikovanih certifikata u skladu sa Direktivom Evropske unije o elektronskim potpisima i domaem Zakonom o elektronskom potpisu. Prema Direktivi, certifikaciono telo koje izdaje kvalifikovane certifikate treba da ispuni sledee zahteve (Annex II):

Da koristi proverene sisteme za uvanje certifikata u formi koja se moe verifikovati... U skladu sa ovim kriterijuma, u lanu 20. Zakona o elektronskom potpisu su definisani nai kriterijumi koje treba da ispune certifikaciona tela u cilju izdavanja kvalifikovanih elektronskih certifikata, koje navodimo u nastavku. Certifikaciono telo za izdavanje kvalifikovanih elektronskih certifikata mora ispunjavati sledee uslove:

Da demonstrira neophodnu sposobnost za pruanje certifikacionih usluga, Da garantuje pouzdan rad i da obezbedi pouzdane servise prikaza lista vaeih i povuenih certifikata, Da obezbedi neophodnu preciznost u vezi datuma i vremena izdavanja ili povlaenja certifikata, Da pouzdano verifikuje identitet vlasnika certifikata 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.

sposobnost za pouzdano obavljanje usluga izdavanja elektronskih certifikata, bezbedno i aurno voenje registra korisnika kao i sprovoenje bezbednog i trenutnog opoziva elektronskog certifikata, obezbeivanje tanog utvrivanja datuma i vremena izdavanja ili opoziva elektronskog certifikata, da izvrava proveru identiteta i, ako je potrebno, i drugih dodatnih obeleja osobe kojoj se izdaje certifikat, na pouzdan nain i u skladu sa propisima, da ima zaposleno osoblje sa specijalistikim znanjima, iskustvom i strunim kvalifikacijama potrebnim za vrenje usluge izdavanja elektronskih certifikata, 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, da koristi pouzdane sisteme i proizvode koji su zatieni od neovlaenih izmena i koji obezbeuju tehniku i kriptografsku sigurnost procesa.

24. Uspostava ISMS U cilju uspostave ISMS sistema organizacija treba da izvri sledee aktivnosti:

a) b)

Definie okvir i granice ISMS u skladu sa karakteristikama svog poslovanja, organizacije, lokacijom, imovinom i tehnologijama, ukljuujui i relevantne detalje; 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.

23.Kvalifikovani sertifikat Da bi se ostvario kvalifikovani elektronski potpis neophodno je da potpisnik ima kvalifikovani elektronski certifikat koga izdaje certifikaciono telo koje ispunjava odreene uslove definisane u Direktivi Evropske Unije o elektronskim potpisisma 1999/93/EC od 19.01.2000. godine. Elektronski sertifikat predstavlja mehanizam za pouzdano pridruivanje izmeu identiteta odreenog korisnika i njegovog javnog kljua za primenu asimetrinog kriptografskog algoritma tj. implicira da je sertifikaciono telo (izdavalac elektronskog sertifikata), kao trea strana od poverenja, proverila da dati javni klju pripada definisanom korisniku i da svojim potpisom sertifikuje da je to istinito. Raspolaganje javnim kljuem potpisnika je uslov za pouzdanu verifikaciju elektronskog potpisa. Naime strana koja vri verifikaciju mora biti sigurna da dati javni klju predstavlja kriptografski par sa tajnim kljuem kojim je poruka elektronski 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. Imajui na raspolaganju elektronski sertifikat odreenog subjekta, mogue je izvriti verifikaciju elektronskog 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. Na taj nain elektronski sertifikati predstavljaju elektronske ekvivalente nekoj vrsti elektronske line karte ili elektronskog pasoa. Kvalifikovani elektronski sertifikat je elektronski sertifikat izdat od strane kvalifikovanog sertifikacionog tela (akreditovanog od strane nadreenih dravnih organa) prema procedurama i uslovima propisanim Zakonom o elektronskom potpisu i prateim podzakonskim aktima.

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. 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. 4. Identifikuje uticaje koje gubici na tajnosti, integritetu i raspoloivosti mogu imati nad dobrima organizacije.

d)

Neke od mogunosti korienja elektronskih sertifikata: - transakcije elektronskog poslovanja pravnih lica - podnoenje elektronske pdv prijave - prijava, promena i odjava na obavezno zdravstveno osiguranje - transakcije elektronskog poslovanja graana

12

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. 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. 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. Dobije odobrenje od menadmenta za predloene preostale (rezidualne) rizike Dobije autorizaciju od strane menademnta da implementira i pusti u operativni rad ISMS sistem Pripremi Izjavu o primenljivosti (Statement of Applicatbility) Izjava o primenljivosti treba da bude pripremljena tako da ukljuuje sledee: 1. 2. 3. Izabrane ciljeve kontrola, kao i same kontrole, kao i razloge zato su izabrani. Ciljeve kontrola i same kontrole koje su trenutno implementirane. Iskljuivanje bilo kojih ciljeva kontrola i samih kontrola koje su definisane ISO/IEC 27001 standardom, kao i obrazloenje za njihovo iskljuivanje.

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.

f)

g)

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 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.

h) i) j)

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. 25. Bezbednosna risk analiza 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 o o Korak 0 - Pred-ocenjivanje Korak 1 Audit dokumentacije Korak 2 Audit implementacije

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

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.

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. 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 matrica

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.).

13

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. 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.

14