ApeironPitanja i odgovori 2

1. Faktori autentikacije korisnikaJedno -, dvo – i tro – komponentni sistemi autentikacije korisnika.Sistemi jake autentikacije – dvo – komponentni sistemi sa uključenom challenge-response procedurom.Pojavni oblici “onoga što se ima”: disketa, mini CD, hardverski token, smart kartica, USB smart kartica.Autentikacioni sistemi najvišeg kvaliteta – dvo– ili tro–komponentni sistemi autentikacije sa PKI challenge-response procedurom.Jaka autentikacija ovlašćenih učesnika u nekom distribuiranom računarskom sistemu je jedna od najvažnijih bezbednosnih funkcija koju dati informacioni sistem treba da implementira. Način prijavljivanja legalnog korisnika na određenu računarsku mrežu ili informacioni sistem korišćenjem standardne procedure unosom korisničkog imena i lozinke sigurno nije dovoljno pouzdano niti dovoljno bezbedno. Naime, postoje tehnike primenom kojih nelegalni korisnik može u realnom vremenu izvršiti rekonstrukciju poverljivih parametara (korisničko 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 određena biometrijska karakteristika korisnika (npr. otisak prsta, itd.). Metode jake autentikacije predstavljaju u stvari dvofaktorsku ili dvokomponentnu autentikaciju uz najčešće primenu odgovarajuće challenge-response procedure.

2. S/MIME Skraćenica Secure / Multi Purpose Internet Mail Extension

Predstavlja bezbednosno proširenje standardnog MIME formata za e-mail poruke

Digitalna envelopa, digitalni potpis Bazira se na:

postojećim javnim kriptografskim standardima (PKCS) standard za poruke (MIME) standard digitalnih certifikata (X.509)

Široko prihvaćen 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-pošte. 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 predložena je od strane RSA kao standard za Internet Engineering Task Force (IETF). PGP / MIME je alternativa za S / MIME. S / MIME kriptografske pruža sigurnosne usluge za e-aplikacije kao što su: integritet poruke, autentifikaciju, a ne-povreda porijekla, privatnosti i sigurnost podataka. Funkcionalnost S / MIME je ugrađen u većinu recentnih izdanja sustava e-poštu programa uključujući 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 definiše zaštitu elektroničkih poruka, a uključuje enkripciju sadržaja i digitalno potpisivanje. Riječ je o elementu sigurnosti na nivou aplikacije, što znači da se zaštita i provjera poruka odvija u klijentu elektroničke pošte. Budući da S/MIME nije jedini dostupni standard ove namjene, niti je podržan u svim klijentima elektroničke pošte, njegova upotreba može biti ponešto nepraktična. Metode na koje se oslanja S/MIME su pouzdani kriptografski algoritmi za (de)kriptiranje sadržaja, izračunavanje sažetaka poruka te za generisanje i provjeru digitalnih potpisa. Zaštićene poruke umeću se kao prilog u jasni MIME format i tako šalju kroz Internet.

S/MIME zaštita Digitalni potpis

provera autentičnosti potpisnika zaštita integriteta podataka neporecivost

Digitalna envelopa zaštita tajnosti podataka

Sertifikati dokaz identiteta strana u komunikaciji

3.PKCS#7 standard za digitalno potpisanu i šifrovanu (envelopa) porukuPKCS#7 standard opisuje metode šifrovanja podataka korišćenjem RSA asimetričnog algoritma i najčešće se koristi za konstrukciju digitalnog koverta i digitalnog potpisa. U slučaju digitalnog koverta, sadržaj poruke se prvo šifruje određenim simetričnim algoritmom (kao što su DES, 3-DES, RC2, RC4, IDEA, AES, ili neki namenski privatni algoritmi). Zatim se tajni ključ primenjenog simetričnog algoritma koji je upotrebljen za šifrovanje date poruke šifruje RSA algoritmom upotrebom javnog ključa korisnika kome je data poruka namenjena (RSA public key operacija). Tako šifrovan sadržaj poruke i tajni ključ kojim je ta poruka šifrovana zajedno predstavljaju digitalni koverat. PKCS#7 standardom se pored bezbednosnih mehanizama definiše i unutrašnja struktura validnih poruka čime se omogućava dodatni mehanizam verifikacije ispravnosti poruka. Naime, svaka poruka koja ima narušenu strukturu se smatra neispravnom i odbacuje se.

Treba posebno naglasiti da je trenutno aktuelan i važeći PKCS#7 standard verzije 2.1 i da su njime značajno izmenjene preporuke date u PKCS#7 standardu verzije 1.5, koje se odnose na format bloka podataka koji podleže operacijama šifrovanja i potpisivanja. Razlog za ovakve drastične promene leži u činjenici da prema verziji 1.5 pri formiranju bloka za šifrovanje postoji niz bita na početku bloka koji je uvek isti. To se može iskoristiti da se bez poznavanja tajnih informacija, samo uz poznavanje šifrata dođe do otvorenog teksta. Ovde treba naglasiti da ovim nije kompromitovana bezbednost samog RSA algoritma već je, grubo govoreći, način njegove upotrebe bio takav da je pod određenim uslovima dolazilo do oticanja informacija. U verziji 2.1 ovog standarda blok podataka koji se šifruje prethodno se kodira OAEP (Optimal Assymetric Encryption Padding) metodom koja ima dobre bezbednosne karakteristike tako da čak ni dva identična bloka podataka posle kodiranja ovim metodom ne daju isti rezultat. Time su izbegnute slabosti detektovane u verziji 1.5. PKCS#7 standard verzije 2.1 je neophodno primeniti u mehanizmima zaštite u specijalizovanim računarskim mrežama i informacionim sistemima.

4. Zaštita web transakcija na aplikativnom nivouU cilju realizacije mehanizama zaštite na aplikativnom nivou u okviru informacionog sistema organizacije, predlaže se primena digitalnog potpisa i digitalne envelope, na bazi smart kartica za korisnike. Klijentska offline aplikacija (standalone) sa ugrađenom kriptografskom bibliotekom treba da ima sledeće kriptografske karakteristike:

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

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

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

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

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

• Koriste se tehnologije digitalnog potpisa i digitalne envelope.

• Univerzalnost u odnosu na smart kartice i čitače smart kartice.• Klijentska aplikacija sa ugrađenom kripto kontrolom mora da obezbedi

funkciju provere autentičnosti korisnika na bazi njegove smart kartice i odgovarajućeg PIN-a pre nego što se omogući korišćenje same aplikacije, tj. aplikacija ne može da se startuje bez korišćenja odgovarajuće smart kartice ovlašćenog korisnika.

• Bazira se na kriptografskim operacijama koje se izvršavaju na samoj smart kartici: digitalni potpis i dešifrovanje simetričnog ključa kod digitalne envelope .

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

o PKCS#1 za digitalni potpis i digitalnu envelopu,o PKCS#7 za format zaštićenih podataka,

o PKCS#11 standardni interfejs za pristup smart karticama.

• Aplikacija treba da bude otvorena za stalnu dogradnju kako novih algoritama tako i za zamenu onih algoritama za koje je utvrđeno da su kriptografski slabi za korišćenje.

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

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

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

o Hash algoritmi – SHA-1, SHA-224, SHA-256, SHA-384 ili

SHA-512.

1

o Simetrični algoritmi – 3DES algoritam sa dužinom ključa od 168 bita ili AES algoritam sa dužinama ključa od 128, 192 ili 256 bita.

5. PGPPretty Good Privacy, osnovne karakteristike:

Raspoložive verzije za različite operativne sisteme, Bazira se na primeni testiranih algoritama kao što su: RSA,

IDEA, MD5.

Nije razvijan niti kontrolisan od nekog državnog tela za standarde.

Digitalni potpis: RSA + MD5

Kriptografska hash vrednost poruke se dobija primenom MD5 algoritma. Digitalni potpis, dobijen primenom, nad sadržajem hash-a, operacije sa privatnim RSA ključem, dodaje se poruci.

Tajnost: RSA + IDEA Poruka se šifruje korišćenjem IDEA algoritma, primenom

jednokratnog sesijskog ključa koga generiše pošiljalac. Sesijski ključ se šifruje sa javnim RSA ključem primaoca i dodaje se poruci.

Kompresija podataka: ZIP algoritam Poruka se može, pre realizacije kriptografskih operacija,

sažeti (kompresovati) korišćenjem ZIP algoritma.Šifrovana poruka se konvertuje u ASCII string. Autentikacija: Pošiljalac kreira poruku. SHA-1 se koristi za kreiranje 160-bitnog hash otiska poruke. Otisak poruke se se šifruje korišćenjem RSA algoritma primenom privatnog ključa, i rezultat šifrovanja se dodaje poruci. Primalac koristi RSA algoritam (operacija sa javnim ključem pošiljaoca) da bi izvršio dešifrovanje hash koda. Primalac generiše vrednost hash koda primljene poruke i komparira sa dešifrovanom vrednošću izvornog hash koda, i ukoliko su te vrednosti identične, poruka se prihvata kao autentična.

Tajnost: Pošiljalac kreira poruku i psudoslučajnu 128-bitnu vrednost koja se koristi kao sesijski ključ isključivo za datu poruku.Poruka se šifruje primenom CAST-128/IDEA /3DES algoritma korišćenjem sesijskog ključa. Sesijski ključ se šifruje RSA algoritmom primenom operacije sa javnim ključem primaoca. Šifrovana vrednost se dodaje na sadržaj poruke. Primalac koristi RSA algoritam (operacija sa privatnim ključem) da bi izvršio dešifrovanje sesijskog ključa. Sesijski ključ se koristi za dešifrovanje poruke.

6. SSL serverska i klijentska autentikacijaSSL je protokol zaštite na transportnom nivou namenjen za zaštitu tajnosti podataka i očuvanja autentičnosti poruka npr. između web client-a i web servera.

M1: C à S: ClientHello

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 podržanih kripto algoritama (Oznaka algoritama za razmenu ključa, postupaka šifrovanja, oznake hash funkcija.Npr. TLS_RSA_WITH_3DES_EDE_CBC_SHA).

M2: S à C: ServerHello, ServerCertChain, ServerHelloDoneServer šalje server version number.Šalje ServerNonce i SessionID. Selektuje jedan kriptomehanizam iz liste podržanih algoritama klijentske strane (Npr. TLS_RSA_WITH_3DES_EDE_CBC_SHA).Šalje ServerCertChain poruku (Omogućava da klijent izvrši autentikaciju javnog ključa servera).Optional CertRequest poruka (Izostavlja se ukoliko se ne vrši autentikacija klijenta).I na kraju, ServerHelloDone poruka.

M3: C à S: ClientKeyExchange, ChangeCipherSpec, ClientFinished

Poruka ClientKeyExchange sadrži šifrat dobijen primenom, nad pre_master_secret, operacije sa javnim ključem servera.

Poruka ChangeCipherSpec označava da je na klijentskoj strani izvršen odabir mehanizama šifrovanja, za datu sesiju, u skladu sa indikatorom dobijenim od servera.

Šalje poruku korišćenjem SSL Change Cipher Spec. Protocol.

(optional) ClientCertificate, ClientCertificateVerify poruke.

Samo kada se vrši autentikacija klijenta.

Završna, ClientFinished poruka.

MAC vrednost nad svim poslatim porukama. MAC se određuje korišćenjem master_secret.M4: S à C: ChangeCipherSpec, ServerFinished

ChangeCipherSpec označava da je server prihvatio, za datu sesiju, odabrani mehanizam šifrovanja.

Na kraju se šalje ServerFinished poruka.

MAC vrednost nad svim poslatim porukama

MAC se izračunava korišćenjem master_secret.

Server može isključivo da odredi MAC vrednost ukoliko je izvršio dešifrovanje pre_master_secret u koraku M3.

7. IPSec

IPsec (Internet Protokol security) je standard i skup protokola (opcionalan za IPv4, a obavezan za IPv6) koji obuhvaća mehanizme za zaštitu prometa na razini trećeg sloja OSI modela - kriptiranjem i/ili autentifikacijom IP paketa.

2

IPsec osigurava ispunjenje sljedećih sigurnosnih zahtjeva:

· tajnost (confidentiality; isključivo ovlaštena osoba može pristupiti podacima),· besprijekornost (integrity; nemogućnost promijene podataka od strane neovlaštene osobe),

· autentičnost (authentication; verifikacija identiteta pošiljaoca),· raspoloživost (availability; dostupnost podacima unatoč

neočekivanim događajima, npr. DOS napad i sl.).Spomenuti zaštitni mehanizmi IPsec-a zasnivaju se na:

· Sigurnosnim protokolima: Encapsulating Security Payload (ESP) i Authentication Header (AH)),

· Specifičnoj 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 ključeva: 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 privatnihmreža preko Interneta. Sa enkapsulacijom IPsec protokol omogućuje autentifikaciju i enkripciju svakog IP paketa uprenosu. To je veoma složen protokol koji sadrži dva tipa – AH(Authentication Header) i ESP(Encapsulating Security Payload), a svaki taj tip ima dva moda – transport i tunel. ESP format IPsec protokola obezbeđuje autentifikaciju, integritet i privatnost podataka, dok AH format obezbeđuje samo autentifikaciju i integritet. U transpornom modu svaki od ova dva tipa bezbedno prenose postojeći IP paket od izvora do odredišta, dok u tunel modu se postojeći paket stavlja unutar novog IP paketa sa IP adresom gejtveja virtuelne privatne mreže koji je krajnja tačka tunela. Ipsec protokol uključuje u sebe veći broj drugih protokola pomoću kojih obavlja funkcije autentifikacije, integriteta i privatnosti, kao osnovnoh bezbedonosnih elemenata virtuelne privatnemreže. Za autentifikaciju IPsec protokol koristi PKI (Public Key Infrastructure) tehniku javnog i privatnog ključa sainfrastrukturom 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 kjučeva i pregovaranju bezbedonosnih elemenata.U okviru IPsec protokola integritet podataka obezbeđuju protokoli HMAC-MD5 /13/ i HMAC-SHA-1 /14/, a privatnost IP paketa je obezbeđena enkripcijom sa 3DES (DES) algoritmom /15/. S obzirom da IPsec AH tip ne obuhvata enkripciju, za virtuelne privatne mreže 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 definiše IP adresu krajnje tačke tunela.

8.Firewall uređajiMrežne barijere (firewall) mogu biti računari, ruteri, radne stanice ili njihove kombinacije koje imaju osnovnu funkciju da definišu kojim se informacijama i servisima interne mreže može pristupiti iz spoljnjeg sveta i kome je, iz interne mreže, dozvoljeno da koristi informacije i usluge spoljnjih segmenata mreže. Ove barijere se uobičajeno instaliraju na tačkama gde se spajaju bezbedno osetljive interne mreže i nebezbedne spoljnje mreže.

U zavisnosti od potreba, firewall se sastoji od jedne ili više funkcionalnih komponenti iz sledećeg skupa: ruter paketskog filtriranja, gejtvej na aplikacionom nivou (Application Level Gateway – proksi) i gejtvej na transportnom nivou (Circuit Level Gateway). Postoje četiri važna primera mrežnih barijera: Packet Filtering Firewall, Dual-Homed Firewal (sadrži dve mrežne 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

Protokolski filtri

Aplikacijski filtri

Hibridni filtri

9.Softverska i hardverska rešenja zaštiteRešenja sistema zaštite TCP/IP računarskih mreža koja se baziraju na potpuno softverskim mehanizmima ne pružaju najviši nivo bezbednosti sistema niti nude potpunu odbranu od potencijalnih napada na mrežu, kao na primer od napada tipa Trojanskog konja. Hardverski bezbednosni moduli, realizovani u vidu računarskih koprocesora, predstavljaju veoma bitnu karakteristiku savremenih rešenja zaštite računarskih mreža.

3

Osnovne funkcije navedenih proizvoda su povećanje bezbednosti sistema i ubrzavanje kriptografskih funkcija, kao što su asimetrični i simetrični kriptografski algoritmi. Hardverski kriptografski koprocesori se predviđaju za korišćenje u serverskim aplikacijama i eventualno u klijentskim aplikacijama gde se zahteva visok nivo bezbednosti (vojska, policija, SMIP, specijalizovane službe). Za najširi vid korišćenja sistema zaštite (npr. pojedinci), korišćenje smart kartica kao poverljive hardverske platforme je primerenije. Smart kartica-Mikroprocesorski upravljana uz posedovanje PIN kodom zaštićenih delova memorije. Kriptografske funkcije se realizuju na smart karticama:

Generisanje i čuvanje ključeva,

Asimetrični algoritam. PKI sistemi se baziraju na primeni kriptografskog hardvera, kako za korisnike (smart kartice), tako i za CA (HSM).Korisnički ključevi mogu da budu izgenerisani na HSM i čuvani, zajedno sa sertifikatom, na smart kartici. Osnovna svrha kriptografskog hardvera CA je da se tajni ključevi CA nikada ne pojavljuju u otvorenoj formi van HSM. Sve kriptografske funkcije treba da se izvršavaju na HSM modulu. Generisanje i čuvanje ključeva mora biti realizovano u okviru HSM.Treba na odgovarajući način realizovati zaštićeni back-up ključeva i ostalih kripto parametara. HSM mora posedovati funkciju detekcije pokušaja narušavanja bezbednosti HSM.

10. Tipovi smart karticaPostoji nekoliko vrsta smart kartica: Memorijske kartice, Mikroprocesorske smart kartice sa korišćenjem, Smart kartice bez kontaktnih površina.

Memorijske karticeOvaj tip kartice je prvi put masovnije korišćen u vidu telefonskih kartica. To su pretplatničke kartice kod kojih se tokom njihove upotrebe smanjuje inicijalna vrednost kredita za telefoniranje. Osnovna sigurnosna potreba, da se korisnik spreči da sam uvećava iznova vrednost kredita, nije ostvariva korišćenjem kartica sa magnetnom trakom, jer bi svaki korisnik sa potrebnom opremom to mogao da izvede.

U tom smislu upotreba smart memorijskih kartica je daleko praktičnija, obzirom da ovaj

tip kartica sadrži potrebnu elektronsku logiku koja sprečava naknadne manipulacije sa

vrijednostima zabilježenim na kartici u momentu izdavanja.

Podaci potrebni nekoj aplikaciji se nalaze unutar memorije, obično EEPROM tipa. Pristup memoriji kontroliše 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 obično okružen 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. Sadržaj ovog ROM čipa je identičan kod svake kartice i ne može 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 vrši unutrašnji 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

slučajevima sadrže jednu aplikaciju za određenu namjenu, ali za današnje interne

operativne sisteme, uobičajeno je da rade sa više 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 specifični

dijelovi operativnog sistema.

Novi momenti u razvoju ovih kartica omogućavaju dodavanje aplikacija čak i kada je već obavljena personalizacija kartice i kada je ona izdata korisniku. Za tu namjenu na tržištu se već dostupne kartice sa snažnijim procesorima i većim kapacitetom memorije. Da bi se sprečile eventualne manipulacije prilikom naknadnog dodavanja aplikacija, koriste se posebne hardverske i softverske preventivne mjere.

Contactless ili smart kartice bez kontaktnih površina Kontaktni izvodi kod kartica sa kontaktima izvedeni su prema standardu ISO 7816. Pouzdanost ovih kartica je u novije vrijeme značajno povećana na osnovu iskustva stečenog u njihovoj proizvodnji. Ipak, njihove kontaktne površine su i dalje jedan od najčešćih razloga za pojavu grešaka ili kvara. Osjetljive su na razne štetne uticaje, vibracije u mobilnim telefonima koje utiču na kvalitet ostvarenog kontakta, kao i na pojavu vlage ili prljavštine na kontaktim površinama. Takođe pražnjenje statičkog elektriciteta može oštetiti unutrašnje elektronske komponente. Nabrojani tehnički problemi i se mogu otkloniti uvođenjem bez-kontaktnih kartica. Ovaj tip kartice ne mora biti prisutan u čitaču da bi se podaci sa nje očitali. Distanca od čitača može biti oko metar udaljenosti, što značajno olakšava mnoge aspekte njene upotrebe. Pored toga, elektronska logika je potpuno integrisana u telu kartice i nije vidiljiva na njenoj površini. Ipak, zbog kompatibilnosti sa velikim brojem standardnih kontaktnih čitača koji su i danas u upotrebi u mnogim sferama, bez-kontaktne kartice se često proizvode sa pridruženim kontaktnim izvodima. Ove kartice se nazivajudual-interface kartice ili combicard kartice.

11. Arhitektura i operativni sistemi smart karticaPostoji nekoliko vrsta smart kartica: Memorijske kartice, Mikroprocesorske smart kartice sa korišćenjem PIN koda za pristup, Mikroprocesorske smart kartice sa PKI mogućnostima (generisanje i čuvanje asimetričnih ključeva, digitalno potpisivanje). Što se tiče tipa mikroprocesora implementiranih na smart karticama, pretežno su to 8-bitni mikrokontroleri, i to najčešće 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 asimetričnih kriptografskih algoritama – digitalno potpisivanje (na primer FameX kripto čip, kao najčešće korišćeni kriptokontroler za realizaciju asimetričnih kriptografskih algoritama u smart karticama) i za realizaciju simetričnih algoritama (DES-3 kripto koprocesor) za realizaciju zaštićene razmene podataka (secure messaging) između smart kartice i softvera na PC računaru. 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, mogućnost rada na jednostavnijim mikroprocesorima (8-bitnim) i male mogućnosti prilagođenja (kastomizacije) implementiranih funkcija na smart kartici. Sa druge strane, JAVA kartice nude veću mogućnost kastomizacije zahvaljujući postojanju JAVA virtualne mašine koja izvršava JAVA aplete definisane od strane korisnika na samoj kartici. Međutim, s obzirom da su se pojavile u skorije vreme, JAVA kartice su skuplje od “običnih” kartica i bolje rade na čipovima koji se baziraju na jačim mikroprocesorima (16-bitni i 32-bitni). U smart kartičnoj industriji postoji nekoliko grupa učesnika: proizvođači čipova, proizvođači operativnih sistema i aplikacija, proizvođači-integratori kompletne kartice (čip, plastika, implementacija čipa, ugradnja operativnog sistema) i isporučioci kompletnih sistema za masovnu produkciju i personalizaciju (vizuelnu i logičku) smart kartica. Neke kompanije su osposobljene za realizaciju više gore pomenutih operacija, a neke su specijalizovane samo za jednu operaciju. Tako na primer, Phillips i Siemens-Infineon su tradicionalni proizvođači čipova, dok su: GemPlus, SchlumbergerSema, Oberthur, Bull, Giesecke & Devrient, Datacard, ActivCard, Orga, itd. proizvođači operativnih sistema i aplikacija za smart kartice. Posebno su od interesa kombinovane smart kartice (kontaktne i beskontaktne – imaju kontaktni čip i beskontaktni čip sa antenom) koje mogu, pored PKI primene za kriptozaštićene aplikacije (kontaktni čip), da se koriste i za kontrolu pristupa u određene prostorije u kompaniji, itd. (beskontaktni čip). U okviru PKI sistema, smart kartice imaju sledeću funkcionalnost i obeležja: Generisanje ključeva na smart kartici – generisanje para ključeva asimetričnog kriptografskog algoritma, kao i zahtevanog broja simetričnih ključeva (opciono), realizuje se unutar smart kartice. Bezbedno čuvanje kriptografskih parametara – ključevi i se bezbedno čuvaju u zaštićenom 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. HSMHardverski bezbednosni moduli, realizovani u vidu računarskih koprocesora, predstavljaju veoma bitnu karakteristiku savremenih rešenja zaštite računarskih mreža. Ovi moduli povećavaju performanse sistema tako što se vremenski kritične kriptografske funkcije izvršavaju na specijalizovanom hardveru a ne u softveru host računara.

Postojanje hardverskog koprocesorskog kriptografskog modula od suštinske je važnosti za realizaciju kvalitetnog i performantnog sistema zaštite, kao i za ispunjenje koncepta poverljive aplikacije u punom smislu.

4

Svi bezbednosni mehanizmi (kriptografski algoritmi i funkcije kontrole pristupa) smešteni su na hardverskom modulu i nikada se ne učitavaju u radnu memoriju korisnikovog računara. Osnovne funkcije navedenih proizvoda su povećanje bezbednosti sistema i ubrzavanje kriptografskih funkcija, kao što su asimetrični i simetrični kriptografski algoritmi. Primena HSM modula je neophodan uslov za bezbednu realizaciju funkcija Sertifikacionog tela. HSM uređaji uglavnom realizuju standardne javne asimetrične i simetrične kriptografske i hash algoritme, kao što su: RSA, DSA, DES, 3-DES, RC2, RC4, SHA-1, MD2, MD5, itd. Postoje eksterni kriptografski moduli, koji mogu imati bolje performanse u smislu brzine i zaštite velike količine podataka. Interni kriptografski moduli su optimalni u slučaju kriptografskih sistema koji koriste princip rada sa porukama i primenjuju tehnologije digitalnog potpisa. Hardverski kriptografski koprocesori se predviđaju za korišćenje u serverskim aplikacijama i eventualno u klijentskim aplikacijama gde se zahteva visok nivo bezbednosti (državni organi, vojska, policija, SMIP, specijalizovane službe). Sa druge strane, za najširi vid korišćenja sistema zaštite (npr. pojedinci), korišćenje smart kartica kao poverljive hardverske platforme je primerenije. U stvari, svi ti sistemi sa povišenim nivoom bezbednosti predstavljaju uglavnom kombinovane softversko-hardverske sisteme, pri čemu je hardverski deo ili koprocesor ili smart kartica. Sistemi sa najvišim nivoom bezbednosti koriste kombinovani softversko-hardverski sistem koji se sastoji od softverske aplikacije, kriptografskog koprocesora za realizaciju kriptografskih algoritama i smart kartica, kao bezbednih nosioca ključeva i digitalnih certifikata.

Postoje i domaći HSM moduli. Uprošćena blok šema jednog domaćeg HSM modula je prikazana na slici 5.3.

NST2000

DSP

ISA или PCI интерфејс ка магистрали

Меморијски подсистем

Специјализо -вани I/O

контролер

Контрола тастатуре

Контрола читача

Генератор случајних бројева

Сат у ре

Тастатура

Читач smart картица

Real -time clock

Slika 5.3: Pojednostavljeni blok dijagram jednog domaćeg prototipa hardverskog koprocesorskog modula

HSM moduli u okviru sertifikacionih tela imaju sledeću funkcionalnost:

• Generisanje ključeva na HSM – generisanje para ključeva asimetričnog kriptografskog algoritma, kao i zahtevanog broja simetričnih ključeva (opciono), realizuje se unutar HSM.

• Bezbedno čuvanje kriptografskih parametara – ključevi i ostali kriptografski parametri se bezbedno čuvaju (u šifrovanom obliku) na HSM modulu.

• Bezbedni back-up kriptografskog materijala – ključevi i drugi kriptografski parametri se mogu bezbedno sačuvati (back-up-ovati) na smart karticama ili drugim HSM modulima.

• HSM mora realizovati funkciju detekcije pokušaja zlonamernog pristupa modulu (tamperproof) – modul treba da obezbedi detekciju zlonamernog pristupa i uništenje bezbednosnog materijala na modulu ako je detektovan pristup.

• Modul mora biti sposoban da realizuje kriptografske funkcije – ovo je jedna od osnovnih namena HSM i ovi moduli su optimizovani za realizaciju funkcija generisanja ključeva, kao i realizaciju simetričnih i asimetričnih kriptografskih algoritama mnogo efikasnije nego u softveru ili na smart karticama.

• Bezbedno korišćenje PIN broja – modul se aktivira unošenjem PIN broja.

13. Digitalni sertifikati – sadržajDigitalni sertifikati predstavljaju element kojim se utvrđuje veza između identiteta subjekta i njegovog javnog ključa za primenu asimetričnog kriptografskog algoritma. Raspolaganje javnim ključem potpisnika je uslov za pouzdanu verifikaciju digitalnog potpisa. Digitalni sertifikati predstavljaju mehanizam za pouzdano pridruživanje asimetričnog para brojeva (privatni i javni ključ) identitetu nekog subjekta, tako da se ta veza ne može falsifikovati.

Digitalni sertifikati predstavljaju elektronske ekvivalente nekoj vrsti “digitalne lične karte” ili “digitalnog pasoša”. Da bi se dobio digitalni sertifikat, mora se prvo formirati zahtev za dobijanje sertifikata (Certificate request), koji se dostavlja određenom CA u cilju izdavanja digitalnog sertifikata. Ovaj zahtev sadrži sve podatke o korisniku koji će se pojaviti i u digitalnom sertifikatu. Zahtev za sertifikat je digitalno potpisan (samopoptisan) u cilju garancije njegovog integriteta. Sertifikaciono telo proverava autentičnost dobijenog zahteva korišćenjem javnog ključa koji je u njemu sadržan. Postoje dva korišćena tipa zahteva za izdavanje digitalnog sertifikata, poznati kao PKCS#10 i RFC 2511. PKCS#10 format je daleko jednostavniji. PKCS#10 tip zahteva za izdavanjem sertifikata sastoji se od sledeća 4 polja:

Broj verzije formata zahteva (od 1 do 3),

Naziv vlasnika digitalnog sertifikata (DistinguishedName -

Dname),

Javni ključ vlasnika digitalnog sertifikata,

Atributi.

Polje atributa sadrži one elemente za koje postoji potreba da se nađu u digitalnom sertifikatu, kao što je broj telefona, broj faksa, e-mail adresa, najviša vrednost finansijske transakcije u slučaju bankarskih sertifikata i druge karakteristike. U ovom polju se može naći sve ono što ne potpada pod polje Dname a predstavlja jedinstveni string koji identifikuje vlasnika sertifikata. Dname predstavlja put kroz X.500 direktorijum, tako da se jedino može sastojati iz sledećih polja:

Dvoslovni niz koji označava državu,

Region,

Elektronska adresa,

Firma,

Odeljenje u firmi,

Ime vlasnika sertifikata.

Imajući na raspolaganju digitalni sertifikat određenog subjekta, moguće je izvršiti verifikaciju digitalnog potpisa poruka koje je taj subjekt potpisao. Ukoliko je verifikacija uspešna, verifikator je siguran u integritet poruke, u autentičnost njenog potpisnika i u nemogućnost naknadnog poricanja datog potpisnika za izdavanje date poruke. U okviru sistema zaštite savremenih računarskih mreža, digitalni sertifikati se, između ostalog, mogu primenjivati za verifikaciju digitalnog potpisa, kontrolu pristupa subjekata kriptozaštićenim aplikacijama i u procedurama autentikacije. Sadržaj digitalnog sertifikata, u skladu sa standardom X.509, je prikazan je na slici.

В е р з и ја фо р м а т а ц е р т и фи ка т а С е р и јс ки б р о ј ц е р т и ф и ка т а

И д е н т и фи ка т о р а л го р и т м а ко ји м с е в р ш и д и ги т а л н и п о т п и с Н а з и в Ц е р т и фи ка ц и о н о г т е л а ко је је и з д а л о ц е р т и фи ка т

Р о к в а ж н о с т и ц е р т и фи ка т а Н а з и в в л а с н и к а ц е р т и ф и ка т а

Ј а в н и к љ уч в л а с н и ка ц е р т и фи ка т а О д р е ђе н и с п е ц и фи ч н и п о д а ц и ко ји с е о д н о с е н а ус л о в е

ко р и ш ће њ а ц е р т и фи ка т а

Д И Г И Т А Л Н И П О Т П И С Ц Е Р Т И Ф И К А Т А Т А Ј Н И М К Љ У Ч Е М Ц Е Р Т И Ф И К А Ц И О Н О Г

Т Е Л А

14. Komponente PKI sistema

Osnovni dokument rada PKI sistema - Politika sertifikacije (CP –

Certificate Policy),

CPS – Certificate Practice Statement

Sertifikaciono telo (CA)

Registraciono telo (RA)

5

Sistemi za distribuciju sertifikata

PKI aplikacije

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

CPS – Certificate Practice Statement – predstavlja dokument koji praktično opisuje rad Sertifikacionog tela (CA – Certification Authority) i neophodan je u slučaju komercijalnog CA. CPS predstavlja jedan detaljan dokument koji sadrži operacione procedure za realizaciju principa koji su navedeni u politici sertifikacije i predstavlja praktičnu podršku sistemu. Tipično, CPS uključuje definicije kako je CA formirano i način rada, kako se generišu digitalni sertifikati, kako se povlače, kako će ključevi biti generisani, registrovani i sertifikovani, gde će se čuvati i kako će biti raspoloživi korisnicima. Sertifikaciono telo (CA) – je najvažnija komponenta i osnova poverenja datog PKI sistema čiji je zadatak da upravlja digitalnim sertifikatima u njihovom čitavom životnom ciklusu. Osnovni zadaci CA su da:

Generiše digitalne sertifikate tako što povezuje

identifikacione podatke određenog korisnika u sistemu sa njegovim javnim ključem asimetričnog kriptografskog sistema, i sve to potvrđuje svojim digitalnim potpisom svih podataka u sertifikatu,

Upravlja rokom važnosti izdatih digitalnih sertifikata,

Obezbeđuje funkciju povlačenja izdatih digitalnih

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

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

Registraciono telo (RA) – obezbeđuje interfejs između korisnika i CA.

RA prihvata zahteve i proverava autentičnost korisnika i

prosleđuje standardni zahtev za izdavanje digitalnog sertifikata.

Kvalitet procedure provere identiteta korisnika određuje

nivo poverenja koji se ugrađuje u sertifikat.

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

PKI aplikacije – čitav PKI sistem se kreira da podrži rad većeg broja aplikacija, kao što su:

Zaštita WEB transakcija,

Zaštita e-mail servisa,

VPN – virtuelne privatne mreže,

Bezbedno upravljanje elektronskom dokumentacijom,

Sistemi dvo-faktorske autentikacije,

Sistemi upravljanja identitetom, ...

15. Sertifikaciono tijeloSertifikaciono telo ili Sertifikacioni autoritet (CA) predstavlja jezgro čitavog PKI sistema. Čitavo poverenje sadržano u PKI infrastrukturi zavisi od digitalnog potpisa CA koji se formira na bazi asimetričnog kriptografskog algoritma i asimetričnog privatnog ključa CA. CA funkcioniše 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č asimetričnog kriptografskog sistema, smešta 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 “treća strana od poverenja”, proverila da dati javni ključ pripada definisanom korisniku i da svojim potpisom sertifikuje da je to istinito.

Ovlašćeno eksterno telo (CA) preuzima lične podatke određenog korisnika i njegov javni ključ, formatira sve te podatke na standardni način, u obliku digitalnog sertifikata, koga zatim digitalno potpiše. Digitalni sertifikat, na osnovu digitalnog potpisa CA, predstavlja pouzdanu vezu identiteta određenog korisnika i njegovog javnog ključa. Ime vlasnika sertifikata, javni ključ i dodatne informacije kao što su: datum izdavanja i rok važnosti, ime CA koje je izdalo sertifikat, itd. formatiraju se u obliku digitalnog sertifikata u standardnom formatu (X.509 standard) tako da ga standardni programi za pretraživanje i kriptografski softverski sistemi mogu procesirati.

Slika: sertifikaciono tijelo

CA prihvata potvrđene zahteve za generisanjem i povlačenjem sertifikata

od registracionih tela (RA) i CAO i isporučuje digitalne sertifikate i potvrdne poruke.

Ako je tako predviđeno utvrđenom politikom rada, CA takođe dostavlja

krajnjim korisnicima asimetrični par ključeva za šifrovanje (digitalna envelopa) koji se arhiviraju u bazi ključeva u arhivnom serveru.

Digitalno potpisivanje sertifikata – CA je odgovorno za digitalno

potpisivanje infrastrukturnih sertifikata i sertifikata krajnjih korisnika. CA takođe digitalno potpisuje sertifikate podređenih CA, kao i drugih CA u slučaju unakrsne sertifikacije (cross certification).

Publikovanje CRL (Certificate Revocation List) – CA digitalno potpisuje

sve informacije objavljene u 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

autentičnosti 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 podržava i publikaciju pomenutih parametara u okviru fajl strukture na hard disku, kao jedan od mehanizama publikacije sertifikata koji se može lako kastomizovati.

Opciono – CA može publikovati CRL i na OCSP (OnLine Certificate

Status Protocol) serveru.

Generisanje asimetričnog para ključeva – CA generiše svoj sopstveni par

ključeva za asimetrični kriptografski algoritam.

Provera jedinstvenog imena Dname i javnih ključeva – CA može opciono

da proverava da li svi izdati digitalni sertifikati imaju jedinstveno Dname i javni ključ.

6

CA treba da podrži različite hardverske elemente, kao što su: smart kartice

za krajnje korisnike, hardverski bezbednosni moduli (HSM – Hardware Security Module) i drugi tokeni.

CA treba da podrži mogućnost korišćenja DAP i LDAP mehanizama.

CA obezbeđuje višestruko generisanje parova asimetričnog ključa.

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

CA podržava promenljivo vreme publikovanja CRL.

CA treba da podrži OCSP servise.

CA treba da podrži čitavu paletu simetričnih i asimetričnih ključeva. Što

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

Modul operatora Sertifikacionog tela (CAO) predstavlja modul za

administraciju, nadzor i bezbednost CA i čitavog PKI sistema koji se bazira na datom CA.

CAO kontroliše sve administratorske funkcije u sistemu i dodeljuje

odgovarajuće privilegije ostalim administratorima, modulima i podsistemima.

CAO prosleđuje potvrđene zahteve za izdavanjem sertifikata direktno CA.

Zahtevi za izdavanjem sertifikata se smeštaju u CA bazu podataka.

Kreiranje politike rada CA – CAO je odgovoran za kreiranje i održavanje

politike izdavanja sertifikata. CAO takođe održava politike i procedure rada CA i svih RA.

Ažuriranje novih verzija politike rada CA i celog PKI sistema – CAO

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

Povlačenje sertifikata – svaki sertifikat može biti povučen od strane CAO.

Zahtevi za povlačenjem sertifikata se smeštaju u CA bazu podataka.

Razvoj PKI sistema – CAO može dodati nove module ili aplikacije u PKI

sistem i dati im odgovarajuće privilegije.

Generisanje ključeva – CAO je odgovoran za generisanje odgovarajućih

ključeva (simetričnih i asimetričnih) za korisnike, ukoliko CA vrši tu funkciju.

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

digitalno potpisane.

Verifikacija potpisanih poruka – sve poruke koje CAO prima prolaze

proveru (verifikaciju) digitalnog potpisa u cilju provere autentičnosti potpisnika i integriteta sadržaja poruke.

Š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 podrži različite hardverske elemente, kao što su: smart

kartice za krajnje korisnike, hardverski bezbednosni moduli (HSM – Hardware Security Module) i drugi tokeni.

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

Procesira sertifikate i CRL.

Svaki CAO može imati različite nivoe privilegija.

16. Registraciono telo (RA)Registraciono telo (RA) igra ulogu rutera između operatora registracionog tela (RAO) i CA. RA može imati svoju sopstvenu politiku rada, koja se održava lokalno ili od strane CAO.

RA može biti klijent-server aplikacija koja ima svoju lokalnu bazu i koja sa jedne strane komunicira sa operatorom RA – RAO, a sa druge strane sa CA. U nastavku je obrađen slučaj korišćenja RA u obliku klijent-server aplikacije.

RA prosleđuje potvrđene zahteve za izdavanjem ili povlačenjem

sertifikata, dobijene od RAO, do CA. RA dobija sertifikate i potvrdne poruke od strane CA i dostavlja ih do RAO.

RA prosleđuje zahteve za izdavanjem ili povlačenjem sertifikata, dobijene

od korisnika putem određenog komunikacionog kanala, do RAO na proveru i potvrdu.

Digitalno potpisivanje poruka – sve poruke poslate od strane RA su

digitalno potpisane.

Verifikacija poruka – sve digitalno potpisane poruke koje RA dobija se

procesiraju u smislu verifikacije digitalnog potpisaa u cilju provere autentičnosti potpisnika i integriteta sadržaja poruke.

Šifrovanje podataka – sve poruke koje se razmenjuju preko RA su

šifrovane u PKCS#7 formatu.

Arhiviranje podataka – svi podaci i log fajlovi se arhiviraju u bazi

podataka RA.

Sve arhivirane informacije su digitalno potpisane od strane RA.

Svaki ulazni slog ima jedinstveni procesni broj.

RA treba da podrži različite hardverske elemente, kao što su: smart kartice

za krajnje korisnike, hardverski bezbednosni moduli (HSM – Hardware Security Module) i drugi tokeni.

Opcija automatskog potvrđivanja – u slučaju da je to politikom rada

predviđeno, RA može biti podešeno tako da automatski potvrđuje (digitalno potpisuje) sve udaljene zahteve koji stižu bez potrebe za intervencijom RAO.

Operator registracionog tela (RAO) ima prvenstvenu funkciju da potvrđuje

(digitalno potpisuje) zahteve za izdavanjem ili povlačenjem sertifikata koji će dalje biti procesirani od strane CA.

Međutim, u slučaju da politika rada CA to predviđa i dozvoljava, RAO

može realizovati i funkciju generisanja ključeva za krajnjeg korisnika.

Tradicionalno, RAO se realizuje kao klijent-server aplikacija u

kombinaciji sa RA, a osnovna funkcionalnost i obeležja biće prikazana u nastavku.

RAO prima zahteve za izdavanjem sertifikata preko RA, ili ih kreira

direktno u ličnom kontaktu sa krajnjim korisnikom (face-to-face manner).

RAO je odgovoran za potvrđivanje ili odbijanje zahteva za izdavanjem

sertifikata od krajnjeg korisnika koji su dobijeni u ličnom kontaktu ili elektronskom komunikacijom (ova funkcija zavisi od utvrđene politike rada PKI sistema).

RAO šalje potvrđene zahteve za izdavanjem ili povlačenjem sertifikata do

RA.

RAO može generisati ključeve (asimetrični par ključeva) za krajnjeg

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

Digitalno potpisivanje poruka – sve poruke poslate od strane RAO su

digitalno potpisane.

Verifikacija poruka – sve digitalno potpisane poruke koje RAO dobija se

procesiraju u smislu verifikacije digitalnog potpisa a u cilju provere autentičnosti potpisnika i integriteta sadržaja poruke.

Šifrovanje podataka – sve poruke koje se razmenjuju preko RAO modula

su šifrovane 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.

RAO treba da podrži različite hardverske elemente, kao što su: smart kartice, hardverski bezbednosni moduli (HSM – Hardware Security Module) i drugi tokeni.

7

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

17. Osnovni dokumenti rada CA

Bilo koje bezbednosne mere koje se primenjuju u okviru neke računarske

mreže, koje između ostalog mogu da uključuju mrežne barijere (firewall), ID kartice ili kontrolu pristupa do PKI infrastrukture zahtevaju postojanje sveobuhvatne bezbednosne politike (politika zaštite) rada date mreže.

Ova politika definiše procedure koje omogućuju pristup korporacijskim

resursima ili informacijama, i koje onemogućuju neautorizovanim korisnicima pristup tim resursima.

Ova bezbednosna politika uključuje postavku i detaljnu definiciju funkcija

koje treba da realizuju svi elementi PKI infrastrukture datog sistema.

U toj bezbednosnoj politici, posebno mesto treba da zauzimaju specifične

procedure, profili i ograničenja vezana za certifikate i zahteve za izdavanje certifikata.

Ovaj deo bezbednosne politike se naziva Politika certifikacije, koja

predstavlja poseban dokument.

Upravljanje politikom rada određenog PKI sistema vrši certifikaciono telo.

U tom smislu, sve PKI aplikacije koje koriste softverske i hardverske

kriptografske mehanizme centralno se upravljaju, što redukuje troškove i povećava nivo kontrole.

Certifikaciono telo pre početka rada utvrđuje Opšta pravila pružanja

usluge certifikacije koja korisnicima obezbeđuju dovoljno informacija na osnovu kojih se mogu odlučiti o prihvatanju usluga i o obimu usluga.

Pomenuta Opšta pravila se sastoje iz dva osnovna dokumenta:

Politika certifikacije (Certificate Policy) i

Praktična pravila pružanja usluge Certifikacije (CPS –

Certification Practice Statement (u daljem tekstu: Praktična pravila)).

Politika certifikacije, tj. politika po kojoj se izdaju certifikati u datom PKI

sistemu, treba da propiše sve procedure koje se odnose na korišćenje i izdavanje certifikata.

Ova politika uključuje sledeće:

Pod kojim uslovima se izdaju certifikati,

Koje informacije treba da budu uključene u certifikat,

Za koju svrhu se koristi dati certifikat, i

Šta se dešava kada istekne važnost certifikata (kada

certifikat dođe do kraja svog životnog veka).

Generisanje politike certifikacije je veoma veliki i složen posao koji treba

da bude nedeljivi deo korporacijske bezbednosne politike.

Mogući postupak generisanja politike certifikacije bi se mogao podeliti na

četiri glavna dela:

Odlučivanje koji sve elementi jedinstvenog imena

(distinguished name – Dname) koji jedinstveno identifikuju korisnika treba da se pojave u svim certifikatima koji su izdati u skladu sa politikom certifikacije (neki elementi mogu biti opcioni),

Određivanje koje ekstenzije će se pojaviti u certifikatima

izdatim u skladu sa ovom politikom,

Odlučivanje koje dodatne registracione informacije treba da

budu prikupljane u cilju izdavanja certifikata. Ove informacije se ne publikuju u certifikatu, i

Određivanje dodatnih operacionih ograničenja koja treba da

budu sprovedena u vezi izdavanja i korišćenja certifikata.

Certifikaciono telo je odgovorno za pružanje kompletnih usluga

certifikacije, koje uključuju sledeće servise, i to:

Registraciju korisnika,

Formiranje digitalnih certifikata,

Distribuciju digitalnih certifikata korisnicima,

Upravljanje procedurom opoziva digitalnih certifikata i

Obezbeđivanje statusa opozvanosti digitalnih certifikata.

Certifikaciono telo može, pored gore navedenih servisa, da obezbedi i:

formiranje asimetričnog para ključeva za korisnike, kao i

distribuciju privatnog ključa i certifikata korisniku na bezbedan način,

sredstvo za formiranje kvalifikovanog elektronskog potpisa

korisnicima i pridruženu lozinku (ili PIN kod) za aktivaciju sredstva, kao i njihovu bezbednu distribuciju do korisnika, ako je to u skladu sa svojim Opštim i Internim pravilima rada.

Sadržaj dokumenta Politika certifikacije, prema ETSI TS 101 456 “Policy

Requirements for Certification Authoritites Issuing Qualified Certificates”, obuhvata sledeća poglavlja i teme, i to:

Opšte odredbe o radu certifikacionog tela

Pojam certifikacionog tela,

Certifikacione usluge,

Obuhvat dokumenta Politika certifikacije,

Obuhvat dokumenta Praktična pravila pružanja usluge

certifikacije,

Korisnici usluga certifikacije.

Uvodne odredbe o Politici izdavanja kvalifikovanih elektronskih

certifikata

Obaveze i odgovornosti

Obaveze certifikacionog tela,

Obaveze korisnika,

Odgovornost certifikacionog tela,

Odgovornost korisnika.

Funkcionalni zahtevi za rad certifikacionog tela

a) Operativna pravila rada certifikacionog tela

b) Procedure upravljanja životnim ciklusom kriptografskih

ključeva

Generisanje ključa certifikacionog tela,

Procedure čuvanja i formiranja rezervnih

kopija ključeva certifikacionog tela,

Distribucija javnog ključa certifikacionog

tela,

Korišćenje ključa certifikacionog tela,

Kraj životnog ciklusa ključa certifikacionog

tela,

Upravljanje životnim ciklusom

kriptografskog hardvera koji se koristi za generisanje kvalifikovanih certifikata,

8

Upravljanje ključevima korisnika za

identifikaciju i digitalnu envelopu,

Procedura pripreme sredstava za formiranje

kvalifikovanog elektronskog potpisa.

v) Procedure upravljanja životnim ciklusom certifikata

Metode registracije korisnika,

Izdavanje certifikata,

Distribucija certifikata,

Obnavljanje certifikata,

Suspenzija certifikata,

Opoziv certifikata,

Način publikacije liste opozvanih certifikata.

g) Upravljanje operativnim radom certifikacionog tela

Upravljanje u skladu sa bezbednosnim

principima,

Upravljanje i klasifikacija najvažnijih

informacija i podataka u okviru certifikacionog tela,

Kadrovski resursi,

Sistem fizičke bezbednosti i bezbednosti

okruženja,

Upravljanje radom certifikacionog tela,

Upravljanje sistemom kontrole pristupa,

Upotreba i održavanje bezbednih

kriptografskih sistema,

Upravljanje procedurama kontinualnog

poslovanja u incidentnim situacijama,

Prestanak rada certifikacionog tela,

Usaglašenost 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,

d) Organizacija rada certifikacionih tela.

Certifikaciono telo demonstrira sposobnost za obezbeđivanje usluga izdavanja digitalnih certifikata, tako što mora:Imati Praktična pravila, i u njima definisane procedure, u kojima se specificira način ispunjenja svih zahteva za izdavanjem digitalnih certifikata koji su identifikovani u Politici certifikacije.Učiniti raspoloživim Praktična pravila rada svim korisnicima i drugim zainteresovanim stranama.Objaviti svim korisnicima i potencijalnim zainteresovanim stranama uslove korišćenja digitalnih certifikata.Imati upravnu strukturu najvišeg nivoa koja će imati konačnu autorizaciju i odgovornost za objavljivanje Praktičnih pravila rada certifikacionog tela.Imati upravnu strukturu operativnog nivoa u certifikacionom telu koja je odgovorna za ispravnu primenu Praktičnih pravila rada.Definisati proces periodične analize i održavanja Praktičnih pravila rada.Imati odobrene, od strane upravne strukture najvišeg nivoa, sve izmene u Praktičnim pravilima, tj. nove verzije Praktičnih pravila i, nakon odobravanja, odmah javno objavljene. Interna pravila se baziraju na bezbednosnoj politici certifikacionog tela u smislu fizičke zaštite i zaštite sistemskog okruženja za generisanje digitalnih certifikata, pripremu sredstava za formiranje digitalnog potpisa i upravljanje opozivom, koja definiše i kontrolu fizičkog pristupa, zaštitu od prirodnih katastrofa, zaštitu od požara, zaštitu od nestanka električne energije i prekida rada telekomunikacionih linija, zaštitu od

strukturnih kolapsa, zaštitu od poplava, zaštitu od krađe, loma i upada u sistem, oporavak nakon katastrofe, itd.upadi u prostorije ili informacioni sistem certifikacionog tela).

18. Upravljanje životnim vekom сertifikataU okviru Politike sertifikacije datog certifikacionog tela neophodno je specificirati procedure upravljanja životnim vekom sertifikata, kao što su:

povlačenje,

obnavljanje i

suspenzija.

Obnavljanje sertifikata - Korisnički sertifikati važe ograničeni vremenski period, na primer godinu dana, što je propisano u okviru Politike sertifikacije CA.

Može biti propisan period pre isteka perioda važnosti certifikata kada će se

u okviru sprcifične aplikacije zaštite, dati korisnik automatski upozoriti da je blizu vreme isticanja validnosti sertifikata i da ga treba obnoviti.

Ukoliko korisnici poseduju dva sertifikata čiji periodi validnosti mogu da

se poklapaju, obnavljanje se može istovremeno vršiti za oba sertifikata (dva serijska broja) koji su povezani istim registarskim brojem – korisničkim imenom.

Potrebno je dodatno istaći da se obnavljanje mora izvršiti pre isteka roka

važnosti certifikata.

Ako period važnosti certifikata istekne, moraju se generisati potpuno novi

certifikati (novi ključevi) za datog korisnika. Takođe, treba istaći da se obnavljanje vrši tako da uvek bude izdat novi sertifikat koji ima specificiran rok važnosti od datuma obnavljanja.

Povlačenje сertifikata

Korisnički sertifikati se mogu povući (opozvati) iz generalno dva tipa

razloga:

Došlo je do nekih promena informacija iz sertifikata za

datog korisnika,

Došlo je do gubitka asimetričnog privatnog kljča korisnika

ili je iz bilo kog razloga došlo do kompromitacije ključa datog korisnika.

U oba slučaja, korisnik je dužan da odmah prijavi CA ili RA nastalu promenu. Politikom sertifikacije su specificirani odgovarajući službenici CA (najčešće RAO i CAO) koji imaju pravo povlačenja sertifikata . Potrebno je dodatno istaći da se povlačenje, kao i obnavljanje, ukoliko korisnik ima dva sertifikata može izvršiti istovremeno za oba sertifikata koji su izdati

Suspenzija sertifikata

Postoji mogućnost i privremene suspenzije sertifikata određenog korisnika

koja se vrši ako je primenjena odgovarajuća suspenzivna mera pružanja usluga sertifikacije datom licu, ili zbog odlaska na duže odsustvo (možda čak i godišnji odmor).

Procedura suspenzije je praktično ista kao i procedura povlačenja

sertifikata jer sertifikati fizički idu na CRL listu.

Razlika je u tome što suspendovani sertifikati mogu ponovo biti aktivni

posle isteka suspenzije dok se jednom povučeni sertifikati ne mogu nikada ponovo aktivirati.

Proceduru suspenzije sertifikata uglavnom vrše ista lica kao i u slučaju

povlačenja.

19. CRL (Lista povučenih sertifikata)

Lista povučenih sertifikata (CRL) omogućuje klijentima i serverima, kao i

drugim entitetima koji komuniciraju u datom PKI sistemu, proveru validnosti digitalnih sertifikata druge strane u komunikaciji.

CRL je binarna datoteka koja sadrži sledeće informacije:

Listu povučenih sertifikata sa razlogom njihovog

povlačenja,

9

Naziv izdavaoca CRL,

Vreme kada je CRL izdato,

Vreme kada će sledeća verzija CRL biti publikovana.

Veoma važno je istaći da u slučaju kada CA koje izdaje sertifikate

istovremeno publikuje i CRL, tada je CRL digitalno potpisana od strane CA, čime se omogućuje svim korisnicima da budu sigurni u informacije koje CRL sadrži.

Pristup CRL i provera validnosti sertifikata se vrši kada je potrebno

koristiti javni ključ iz PKI sertifikata određenog korisnika kome treba poslati šifrovanu poruku ili treba verifikovati digitalni potpis primljene poruke od strane tog korisnika.

Bilo koja od pomenutih aktivnosti treba da sadrži sledeće korake:

Proveriti validnost digitalnog sertifikata datog korisnika,

Uzeti serijski broj sertifikata,

Pristupiti (učitati) CRL (obično se to radi download-

ovanjem sa X.500 direktorijuma korišćenjem LDAP pretrage i LDAP odgovora ili uzimanjem iz lokalno sačuvane CRL),

Proveriti digitalni potpis CRL, vreme njenog publikovanja i

vreme kada će sledeća verzija biti publikovana,

Proveriti da li se dati sertifikat nalazi u CRL (na bazi

serijskog broja),

Alarmirati datog korisnika ako je sertifikat povučen,

Izvršiti željenu kriptografsku aplikaciju ukoliko se sertifikat

ne nalazi u CRL ili ako namenjeni korisnik, nakon alarma, preduzme aktivnosti da njegov sertifikat ne bude više u CRL.

Uobičajeno, CA je odgovorno za neporecivost transakcija, obezbeđujući

audit log datoteke i čuvajući sve publikovane verzije CRL.

Alternativno, korisnička aplikacija može realizovati mehanizme kojima se

obezbeđuje neporecivost transakcija.

Međutim, u tom slučaju, za svaku izvršenu transakciju, mora se čuvati

sama poruka kao i CRL koje je korišćeno u trenutku kada je verifikovan digitalni potpis poruke (ili je poruka šifrovana javnim ključem korisnika).

Jedino ste tada u mogućnosti da dokažete da ste koristili javni ključ

namenjenog korisnika za verifikaciju ili šifrovanje u trenutku kada njegov digitalni sertifikat nije bio povučen.

Prednosti CRL:

CRL je široko podržana tehnologija u okviru PKI

industrije,

CRL može biti distribuirano do krajnjih korisnika na

različite načine, uključujući PUSH i PULL metodu,

CRL može biti arhivirano da obezbedi neporecivost za

prethodno izvršene transakcije,

CA izdaje i PKI certifikate i CRL,

Mnoge PKI aplikacije mogu dobiti CRL sa X.500

direktorijuma korišćenjem DAP/LDAP protokola. Prepoznata su sledeća ograničenja upotrebe CRL:

Korisnik mora imati tekuću verziju CRL u trenutku

verifikacije digitalnog potpisa ili šifrovanja podataka. Pošto je CRL datoteka, korisnikova aplikacija mora obezbediti novu verziju CRL, ako je kopija na njegovom lokalnom sistemu zastarela. U velikom PKI okruženju, korisnik može imati potrebu da obezbeđuje CRL veoma često, a samo CRL može biti veoma veliko. Stoga, sve to može značajno usporiti rad neke PKI aplikacije zbog neophodnosti da se

uvek obezbeđuje poslednja verzija CRL sa veoma zauzetog direktorijumskog servera (ili neke druge CRL distribucione tačke).

CRL se kreira i publikuje periodično, pri čemu je taj period

određen Prakitčnim pravilom rada CA (CPS). U sistemu je potrebno veoma studiozno evaluirati koliko često treba kreirati i publikovati CRL u okviru datog PKI sistema. Prečesto publikovanje CRL može zagušiti čitavu infrastrukturu, dok nedovoljno često publikovanje može rezultovati u potencijalnoj mogućnosti da se neki sertifikati koriste iako su već povučeni.

CA periodično kreira CRL datoteku na bazi primljenih zahteva za

povlačenjem izdatih digitalnih sertifikata.

Po kreiranju, CRL uključuje informacije od kada je CRL validna, do kada

je validna i kada će se kreirati nova verzija CRL koja će zameniti prethodnu verziju.

CA digitalno potpisuje CRL tako da krajnji korisnici mogu biti sigurni u

integritet i autentičnost informacija u okviru CRL.

Kada istekne važnost digitalnih sertifikata, njihov status u vezi

povučenosti se više ne prikazuje u okviru CRL.

Ova mera pomaže da se minimizuje veličina CRL za vreme rada datog CA

a i smatra se da status povučenosti nema značaja za sertifikat kome je istekla važnost.

U slučaju suspenzije, serijski broj suspendovanog sertifikata je uključen u

CRL uz navedenu karakteristiku povlačenja: “suspendovan”.

Ako je sertifikat ponovo validan, njegov serijski broj se briše iz naredne

publikovane verzije CRL.

CA je odgovorno za odgovarajuću distribuciju i raspoloživost CRL za

okruženje koje opslužuje.

Najčešće je to postignuto izlaganjem CRL na X.500 direktorijumskom

serveru, kao tipičnom servisu podržanom od strane CA.

Nakon toga je u odgovornosti krajnjeg korisnika, ili njegove softverske

aplikacije, da preuzima CRL iz X.500 direktorijuma.

Postoje i alternativni načini distribucije CRL, kao što je slanje CRL svim

korisnicima putem elektronske pošte (push metod) ili objavljivanje CRL na odgovarajućem WEB sajtu CA sa koga korisnici mogu preuzeti CRL datoteku (pull metod kao što je i preuzimanje CRL sa X.500 direktorijumskog servera).

Pomenute dve alternative su manje prisutne u PKI okruženju iz razloga

pogodnosti X.500 pristupa i široke rasprostranjenosti primene LDAP komunikacionog protokola korišćenog za interakciju sa X.500 direktorijumom.

DAP (Directory Access Protocol) je jedan od četiri protokola definisanih u

okviru X.500 standarda u cilju podrške otvorenim i standardizovanim direktorijumskim servisima.

Direktorijum, u X.500 standardnom smislu, predstavlja specijalnu formu

baze podataka koja je dizajnirana da bude posebno pogodna za korišćenje na Internet-u i drugim distribuiranim sistemima.

20. CA kao web višeslojna arhitekturaU poslednje vreme, implementacije PKI sistema se u sve većoj i većoj meri baziraju na višeslojnim aplikacijama, i to pre svega WEB višeslojnim aplikacijama. Dakle, u novijim sistemima postoji WEB server CA i poseban aplikativni server CA koji prosleđuje zahteve CA crypto engine serveru u cilju formiranja digitalnih sertifikata. U ovakvoj realizaciji, ne postoji RA, već se funkcije RA i RAO kombinuju i integrišu u okviru Internet browser programa sa ciljem WEB komunikacije sa CA. Na taj način, najveći deo procesiranja se prebacuje na sentralni aplikativni server CA, a RAO postaje tanki klijent. U ovom slučaju, RAO priprema zahteve za izdavanjem i povlačenjem sertifikata, digitalno ih potpisuje i po mogućstvu šifruje, i prosleđuje ih do WEB servera CA na dalju obradu. RAO može, ali u najvećem broju slučajeva ne čuva nikakvu dokumentaciju u vezi registracije korisnika već se evidencija u potpunosti centralizuje u CA. RAO svojim digitalnim potpisom potvrđuje da su podaci koje dostavlja za korisnika koji zahteva sertifikat autentični i tačni. Ovaj potpis se proverava na strani WEB servera CA.U slučaju WEB konfiguracije CA, korisnici mogu preko Interneta/Intraneta da dostavljaju direktno svoje zahteve i elektronski, direktno na WEB server CA, ukoliko je to u skladu

10

sa Politikom sertifikacije datog sertifikacionog tela. Za ove slučajeve, u nekim centralnim serverskim CA sistemima postoji i centralni RAO koji potvrđuje sve zahteve koji dođu putem WEB servera CA i odobrava formiranje sertifikata.

21. Generički model CA kao web višeslojne aplikativne arhitektureU okviru realizacije kompletnog PKI sistema, ključna je realizacija softversko-hardverskog sistema CA za generisanje digitalnih sertifikata i odgovarajućih kriptografskih ključeva. Osnovne karakteristike jednog mogućeg sistema (generički model) za generisanje digitalnih sertifikata i odgovarajućih ključeva su:

Realizovan u skladu sa važećim svetskim standardima,

Primenjen X.509 v3 standard za sertifikate,

Primenjen X.509 v2 standard za liste opozvanih sertifikata,

PKCS standardi – najnovije verzije,

Modularna realizacija,

Fleksibilnost – prilagodljivost potrebama korisnika.

Bezbedan sistem – primena najnovijih rezultata iz oblasti generisanja kriptografskih ključeva i primene kriptografskih algoritama.

Firewall

WEB server CA

ЦАО Baza podataka

CA

Crypto engine CA

HSM

Interna mreža CA – OnLine CA

Sistem CA

LDAP server

Ruter

Eksterna mreža

DMZ zona

Aplikativni server CA Root CA

HSM

Root CA – OffLine CA

Sertifikaciono telo se sastoji od OnLine i OffLine dela. OffLine deo predstavlja Root CA koje se koristi samo u izuetnim slučajevima kada se formira asimetrični 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 ključa Root CA koji se propisanom procedurom distribuirane odgovornosti koriste u slučajevima generisanja novog Intermediate sertifikacionog tela (ta procedura se naziva “CA ceremonija”). U proceduri CA ceremonije, potrebno je da prisustvuje odgovarajući minimalan broj specijalnih službenika CA koji imaju pristup pojedinim delovima za aktivaciju privatnog ključa, koji se čuvaju u posebnim pretincima u trezoru i to najčešće u obliku smart kartica. Dakle, odgovarajući broj smart kartica mora biti prisutno da bi se u HSM uređaju Root CA mogao aktivirati privatni ključ Root CA u skladu sa Praktičnim pravilima rada sertifikacionog tela. Nakon toga se u HSM uređaju izvrši generisanje asimetričnog para ključeva za novi Intermediate CA i izgeneriše se njegov sertifikat primenom digitalnog potpisa na bazi privatnog ključa Root CA. Tako dobijenim privatnim ključem i sertifikatom isprogramira se najčešće, HSM ili smart kartica, Intermediate CA koja se zatim postavi u HSM uređaj novog, posebno za taj Intermediate CA obezbeđenog, Crypto Engine servera. Zatim se obriše privatni ključ Root CA iz HSM uređaja i specijalne smart kartice sa delovima za aktivaciju ključa se vrate u trezor. Moguće je da istovremeno rade više Intermediate CA u OnLine modu rada, tj. da više Intermediate CA Crypto Engine servera bude aktivirano u OnLine rad generisanja digitalnih sertifikata. OnLine procedura se odvija na sledeći način. Zahtevi za izdavanjem sertifikata čiji je digitalni potpis uspešno proveren od strane WEB servera CA (bilo da se radi o samopotpisanim sertifikatima koje su korisnici dostavili direktno do WEB servera CA ili su to zahtevi potpisani od strane odgovarajućeg RAO u okviru RA gde je korisnik fizički

došao da mu se izda sertifikat) se od strane aplikativnog servera CA upućuju do odgovarajućeg Intermediate CA Crypto Engine servera iz kog domena je dati korisnik. Na datom Crypto Engine serveru (u okviru HSM uređaja datog servera) izvrši se formiranje digitalnog sertifikata (u slučaju samopotpisanog zahteva) ili se izvrši generisanje asimetričnog para ključeva i formiranje digitalnog sertifikata za datog korisnika. Ovi podaci se vraćaju aplikativnom serveru koji ih smešta u bazu podataka CA i šalje ih na odgovarajuči način direktno korisniku ili u RA gde je korisnik podneo zahtev. U DMZ zoni sistema CA se, pored WEB servera CA, nalazi i LDAP server koji služi za publikovanje CRL i ARL lista, kao i eventualno za publikaciju izdatih digitalnih sertifikata. Potrebno je istaći da navedeni primer realizacije sistema CA predstavlja samo jedan mogući način realizacije i da se realne realizacije sistema više ili manje razlikuju u domenima načina generisanja ključeva za korisnike, načinu distribucije ključeva i sertifikata, kao i u načinu publikacije CRL liste. Međutim, i pored razlika, osnovni principi i koncepti savremenih sertifikacionih tela se poklapaju sa navedenim primerom.

22.Kvalifikovani elektronski potpisPrema Zakonu o elektronskom potpisu i podzakonskim aktima, kvalifikovani elektronski potpis mora da ispunjava sledeće uslove:

isključivo je povezan sa potpisnikom,

nedvosmisleno identifikuje potpisnika,

nastaje korisšćenjem podataka kojima potpisnik samostalno upravlja i koja su isključivo pod nadzorom potpisnika,

kreiran je primenom odgovarajućih algoritama i parametara kojima se omogućava uvid u bilo koju izmenu izvornih podataka,

bazira se na kvalifikovanog elektronskom certifikatu potpisnika i

formiran je sredstvima za formiranje kvalifikovanog elektronskog potpisa.

Dalje, prema Zakonu o elektronskom potpisu, kvalifikovan elektronski potpis u odnosu na podatke u elektronskom obliku:

ima istu pravnu snagu kao i svojeručni potpis, odnosno svojeručni potpis i pečat u odnosu na podatke u papirnom obliku i

prihvatljiv je kao dokazni materijal u pravnim poslovima.

Dakle, da bi se ostvario kvalifikovani elektronski potpis neophodno je da potpisnik ima kvalifikovani elektronski certifikat koga izdaje certifikaciono telo koje ispunjava određene uslove definisane u Direktivi Evropske Unije o elektronskim potpisisma 1999/93/EC od 19.01.2000. godine. Drugim rečima, CA koje izdaje kvalifikovane elektronske certifikate treba da ispuni uslove za izdavanje kvalifikovanih certifikata u skladu sa Direktivom Evropske unije o elektronskim potpisima i domaćem Zakonom o elektronskom potpisu. Према Директиви, цертификационо тело које издаје квалификоване цертификате треба да испуни следеће захтеве (Annex II):

Da demonstrira neophodnu sposobnost za pružanje certifikacionih usluga,

Da garantuje pouzdan rad i da obezbedi pouzdane servise prikaza lista važećih i povučenih certifikata,

Da obezbedi neophodnu preciznost u vezi datuma i vremena izdavanja ili povlačenja certifikata,

Da pouzdano verifikuje identitet vlasnika certifikata i, ako je potrebno, bilo kog specifičnog atributa vlasnika,

Da zapošljava radnike koji poseduju ekspertska znanja, iskustvo i kvalifikacije neophodne za servise koji se obezbeđuju; posebno na upravnom nivou, ekspertizu u oblasti elektronskog potpisa i familijarnost sa propisanim bezbednosnim procedurama,

Da koristi proverene sisteme i proizvode koji obezbeđuju tehničku i kriptografsku bezbednost procesa koji se podržavaju primenom ovih sistema,

Da primenjuje mere protiv kompromitacije certifikata i garantuje tajnost procesa generisanja para ključeva za digitalno potpisivanje ukoliko se taj par generiše kod certifikacionog tela,

Da obezbedi odgovarajuća materijalna sredstva za siguran i bezbedan rad i da omogući određenu šemu osiguranja od lažiranja certifikata,

11

Da vrši zapisivanje svih relevantnih informacija koja se tiču certifikata u odgovarajućem periodu vremena (posebno za slučajeve 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 obezbeđuje servis generisanja para ključeva za digitalno potpisivanje,

Da precizno upozna osobu koja zahteva izdavanje certifikata sa svim uslovima korišćenja certifikata,

Da koristi proverene sisteme za čuvanje certifikata u formi koja se može verifikovati...

U skladu sa ovim kriterijuma, u članu 20. Zakona o elektronskom potpisu su definisani naši 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 sledeće uslove:

sposobnost za pouzdano obavljanje usluga izdavanja elektronskih certifikata,

bezbedno i ažurno vođenje registra korisnika kao i sprovođenje bezbednog i trenutnog opoziva elektronskog certifikata,

obezbeđivanje tačnog utvrđivanja datuma i vremena izdavanja ili opoziva elektronskog certifikata,

da izvršava proveru identiteta i, ako je potrebno, i drugih dodatnih obeležja osobe kojoj se izdaje certifikat, na pouzdan način i u skladu sa propisima,

da ima zaposleno osoblje sa specijalističkim znanjima, iskustvom i stručnim kvalifikacijama potrebnim za vršenje usluge izdavanja elektronskih certifikata, a naročito u odnosu na: sposobnosti na upravljačkom nivou, stručnost u primeni tehnologija elektronskog potpisa i odgovarajućih sigurnosnih procedura i bezbednu primenu odgovarajućih administrativnih i upravljačkih postupaka koji su usaglašeni sa priznatim standardima,

da koristi pouzdane sisteme i proizvode koji su zaštićeni od neovlašćenih izmena i koji obezbeđuju tehničku i kriptografsku sigurnost procesa.

23.Kvalifikovani sertifikatDa bi se ostvario kvalifikovani elektronski potpis neophodno je da potpisnik ima kvalifikovani elektronski certifikat koga izdaje certifikaciono telo koje ispunjava određene uslove definisane u Direktivi Evropske Unije o elektronskim potpisisma 1999/93/EC od 19.01.2000. godine.

Elektronski sertifikat predstavlja mehanizam za pouzdano pridruživanje između identiteta određenog korisnika i njegovog javnog ključa za primenu asimetričnog kriptografskog algoritma tj. implicira da je sertifikaciono telo (izdavalac elektronskog sertifikata), kao “treća strana od poverenja”, proverila da dati javni ključ pripada definisanom korisniku i da svojim potpisom sertifikuje da je to istinito.

Raspolaganje javnim ključem potpisnika je uslov za pouzdanu verifikaciju elektronskog potpisa. Naime strana koja vrši verifikaciju mora biti sigurna da dati javni ključ predstavlja kriptografski par sa tajnim ključem kojim je poruka elektronski potpisana. Javni i tajni ključ asimetričnog kriptografskog algoritma su dve velike brojne veličine i nemaju determinističku vezu sa identitetom bilo kog pravnog ili fizičkog lica.

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

Na taj način elektronski sertifikati predstavljaju elektronske ekvivalente nekoj vrsti “elektronske lične karte” ili “elektronskog pasoša”.

Kvalifikovani elektronski sertifikat je elektronski sertifikat izdat od strane kvalifikovanog sertifikacionog tela (akreditovanog od strane nadređenih državnih organa) prema procedurama i uslovima propisanim Zakonom o elektronskom potpisu i pratećim podzakonskim aktima.

Neke od mogućnosti korišćenja elektronskih sertifikata:

- transakcije elektronskog poslovanja pravnih lica- podnošenje elektronske pdv prijave- prijava, promena i odjava na obavezno zdravstveno osiguranje- transakcije elektronskog poslovanja građana

- elektronska pošta- elektronski ugovori- pristup bezbednim web sajtovima (ssl autentikacija)- elektronsko potpisivanje dokumenata- verifikaciju elektronskog potpisa- šifrovanje i dešifrovanje 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 domaćem Zakonom o elektronskom potpisu. Prema Direktivi, certifikaciono telo koje izdaje kvalifikovane certifikate treba da ispuni sledeće zahteve (Annex II):

Da demonstrira neophodnu sposobnost za pružanje certifikacionih usluga,

Da garantuje pouzdan rad i da obezbedi pouzdane servise prikaza lista važećih i povučenih certifikata,

Da obezbedi neophodnu preciznost u vezi datuma i vremena izdavanja ili povlačenja certifikata,

Da pouzdano verifikuje identitet vlasnika certifikata i, ako je potrebno, bilo kog specifičnog atributa vlasnika,

Da zapošljava radnike koji poseduju ekspertska znanja, iskustvo i kvalifikacije neophodne za servise koji se obezbeđuju; posebno na upravnom nivou, ekspertizu u oblasti elektronskog potpisa i familijarnost sa propisanim bezbednosnim procedurama.

24. Uspostava ISMSU cilju uspostave ISMS sistema organizacija treba da izvrši sledeće aktivnosti:

a) Definiše okvir i granice ISMS u skladu sa karakteristikama svog poslovanja, organizacije, lokacijom, imovinom i tehnologijama, uključujući i relevantne detalje;

b) Definiše ISMS politiku u skladu sa karakteristikama svog poslovanja, organizacije, lokacijom, imovinom i tehnologijama tako da:

1. Uključi okvir za postavljanje ciljeva i uspostavi opšte viđenje pravca i principa za aktivnosti povezane sa informatičkom bezbednošću;

2. Uzme u obzir poslovne i pravne ili regulatorne zahteve, kao i ugovorne bezbednosne obaveze;

3. Uskladi se sa kontekstom strateškog upravljanja rizikom u organizaciji u kome je uključena uspostava i održavanje ISMS;

4. Uspostave se kriterijumi u odnosu na koje će se rizici evaluirati,

5. Odobrena je od strane menadžmenta.

Napomena: U okviru ISO/IEC 27001, ISMS politika (ili Top Level Security Policy) predstavlja nadskup politika informatičke bezbednosti koje treba da se definišu u pojedinim oblastima koje standard pokriva.

c) Definiše pristup ocenjivanju rizika u organizaciji1. Identifikuje metodologiju ocenjivanja rizika koja

odgovara ISMS sistemu, kao i identifikovanim pravnim, regulatornim i poslovnim zahtevima za informatičku bezbednost,

2. Razvije kriterijume za prihvatanje rizika, kao i za identifikaciju prihvatljivog nivoa rizika.

Odabrana metodologija ocenjivanja rizika treba da osigura da ocena rizika proizvede uporedive i reproduktabilne rezultate.

d) Identifikuje rizike1. Identifikuje dobra u granicama okvira ISMS

sistema, kao i vlasnike pomenutih dobara. Termin vlasnik identifikuje pojedinca ili entitet koji ima od strane menadžmenta odobrenu odgovornost za kontrolu proizvodnje, razvoja, održavanje, korišćenja i obezbeđivanja dobra, Termin vlasnik ne znači da ta osoba poseduje bilo kakva vlasnička prava nad tim dobrom organizacije.

2. Identifikuje pretnje nad ovim dobrima.3. Identifikuje ranjivosti koje mogu biti iskorišćene od

strane navedenih pretnji. 4. Identifikuje uticaje koje gubici na tajnosti,

integritetu i raspoloživosti mogu imati nad dobrima organizacije.

12

e) Analizira i evaluira rizike1. Ocenjuje poslovne uticaje na organizaciju koji

mogu da rezultuju na bazi bezbednosnih ispada, uzimajući u obzir gubitke na tajnosti, integritet i raspoloživost dobara.

2. Ocenjuje realnu verovatnoću bezbednosnih ispada koji se dešavaju u svetlu preovlađujućih pretnji i ranjivosti, kao i uticaje koji su pridruženi tim dobrima, kao i trenutno implementirane kontrole.

3. Ocenjuje nivoe rizika.4. Određuje da li su rizici prihvatljivi ili se zahteva

odgovarajući tretman korišćenjem uspostavljenih kriterijuma za prihvatanje rizika.

f) Identifikuje i evaluira opcije tretmana rizikaMoguće aktivnosti uključuju:

1. Primena odgovarajućih kontrola.2. Svesno i objektivno prihvatanje rizika,

obezbeđujući da oni jasno zadovoljavaju politike i kriterijume organizacije za prihvatanje rizika.

3. Izbegavanje rizika.4. Prebacivanje pridruženih poslovnih rizika na druge

strane, kao na primer: dobavljače, osiguranje, itd.

g) Selektuje ciljeve kontrola, kao i same kontrole, za tretman rizikaCiljevi kontrola i same kontrole treba da budu izabrane i implementirane da zadovolje zahteve koji su identifikovani u procesima ocene i tretmana rizika. Ovaj izbor treba da uzme u obzir kriterijume za prihvatanje rizika, kao i eventualne pravne, regulatorne i ugovorne zahteve.

h) Dobije odobrenje od menadžmenta za predložene preostale (rezidualne) rizike

i) Dobije autorizaciju od strane menadžemnta da implementira i pusti u operativni rad ISMS sistem

j) Pripremi Izjavu o primenljivosti (Statement of Applicatbility)Izjava o primenljivosti treba da bude pripremljena tako da uključuje sledeće:

1. Izabrane ciljeve kontrola, kao i same kontrole, kao i razloge zašto su izabrani.

2. Ciljeve kontrola i same kontrole koje su trenutno implementirane.

3. Isključivanje bilo kojih ciljeva kontrola i samih kontrola koje su definisane ISO/IEC 27001 standardom, kao i obrazloženje za njihovo isključivanje.

Napomena: Izjava o primenljivosti obezbeđuje rezime o odlukama koje se tiču tretiranja rizika. Obrazloženi izuzeci obezbeđuju jednu dodatnu proveru da nijedna kontrola nije nehotično izostavljena.

25. Bezbednosna risk analizaProces sertifikovanja sprovodi sertifikaciono telo koje je akreditovano za sertifikaciju po standardu ISO/IEC 27001. Proces ocenjivanja i sertifikacije implementiranog ISMS sistema se sastoji od sledećih faza:

• Pred-sertifikacija i sertifikacija

o Korak 0 - Pred-ocenjivanje o Korak 1 – Audit dokumentacijeo Korak 2 – Audit implementacije

• Post-sertifikacija

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

sertifikacije

Procesu prethodi inicijalni zahtev sertifikacionog tela da organizacijia popuni i pošalje potpisanu aplikacionu formu koja uključuje opseg ISMS sistema koga treba sertifikovati, kao i izjavu da će sve informacije neophodne za evaluaciju ISMS sistema biti dostavljene. Ocenjivanje procesa ocene rizika u organizaciji se najčešće vrši kroz odgovarajuće intervjue sa menadžmentom i zaposlenima koji su odgovorni/uključeni u proces ocene rizika. Ocenjivanje Izjave o primenljivosti predstavlja ocenu rezultata analize rizika, izbora kontrola sa obrazloženjem, kao i ocenu same dokumentovane Izjave o primenljivosti. Korak 0 može trajati od jednog do dva dana na lokaciji organizacije. Audit program/plan koji se izrađuje se sastoji od odgovarajuće matrice sistema upravljanja sa aspekta ciljeva kontrola, odgovornih lica, odeljenja i procesa (ova matrica

pokriva čitav trogodišnji sertifikacioni period), kao i plana intervjua za korake 1 i 2 (izbor ciljeva kontrola, procesa i službi/odeljenja).

Korak 1 – predstavlja značajan deo procesa ocenjivanja po ISO/IEC 27001 standardu. Sertifikaciono telo treba da dobije dokumentaciju o dizajnu ISMS sistema, uključujući izveštaj o oceni rizika, Izjavu o primenljivosti, kao i ključne elemente ISMS sistema.

Ovaj korak audita uključuje, ali se ne ograničava samo na to, pregled dobijenih dokumenata. Audit dokumentacije se u opštem slučaju sprovodi u samoj organizaciji (on site) i sastoji se od sledećih aktivnosti:

• Ispitivanje saglasnosti ISMS okvira sa ISO/IEC 27001 standardom,• Pregleda se politika bezbednosti, opseg, ocena rizika (ako nije pregledana

u koraku 0), upravljanje rizikom, izbor kontrola i izjava o primenljivosti (takođe ako nije pregeldana u koraku 0).

• Politike, standardi, operativne procedure i radne instrukcije.• Odgovarajuće pokrivanje dokumentima izabranih bezbednosnih kontrola.• Upravljanje i dostupnost dokumenata.• Auditori verovatno neće detaljno pregledati specifične procedure ali

očekuju da postoji infrastruktura dokumenata koja, pored specifičnih politika, obuhvata standarde, procedure i radne instrukcije. Eventualno će biti pregledani uzorci pojedinih dokumenata.

Pregled dokumenata treba da bude završen pre početka koraka 2. Rezultati aktivnosti u koraku 1 se dokumentuju u pisanom izveštaju. Iako sve zavisi od procesa sertifikacije i izabranog sertifikacionog tela, korak 1 bi takođe mogao da traje od jednog do dva dana na lokaciji organizacije.

Korak 2 – Audit implementacije predstavlja verifikaciju implementacije i operativnog rada ISMS sistema. U ovom koraku, jedna ili više lokacija organizacije će biti posećena od strane jednog ili više auditora u skladu sa unapred definisnim planom audita, a na bazi rezultata iz Koraka 0 i 1. Cilj ove ili ovih poseta je da se potvrdi da je organizacija saglasna sa svim politikama, ciljevima i procedurama, kao i da je ISMS sistem u skladu sa svim identifikovanim bezbednosnim zahtevima. Prva aktivnost u ovom procesu je razmatranje ispravki detektovanih nesaglasnosti iz koraka 1 – Audita dokumentacije. Nakon toga se vrši ocenjivanje implementacije i efektivnosti upravljačkog sistema po PDCA modelu, kao i ocenjivanje implementacije i efektivnosti primenjenih bezbednosnih kontrola. Naime, cilj je da se oceni funkcionisanje ISMS sistema u realnom slučaju a na bazi rezultata internih audita, upravnog pregleda, praćenja korektivnih i preventivnih mera, identifikacije novih rizika i ponovnog ocenjivanja postojećih rizika, itd. Broj dana trajanja koraka 2 sertifikacije zavisi od veličine i kompleksnosti ISMS sistema i same organizacije. Nakon završenog procesa verifikacije tim lider ocenjivačkog tima daje predlog ali se ne donosi finalna odluka koja se potvrđuje od strane sertifikacionog tela. Nakon uspešno završenog procesa, izdaje se sertifikat po ISO/IEC 27001 standardu. Sertifikat je validan za period od tri godine, isključujući moguću suspenziju ili povlačenje sertifikacije. Sertifikat se izdaje sa sadržajem koji se odnosi na opseg ISMS sistema i referencira se na Izjavu o primenljivosti koja je raspoloživa u vreme ocenjivanja.

Sertifikaciono telo će sprovoditi nadzorne posete i nakon tri godine, ponovna sertifikacija je neophodna. Naime, kontinualni nadzor ISMS sistema (Surveillance Audit) sprovodi sertifikaciono telo u opštem slučaju dva puta godišnje. Cilj ovog audita je da se pokrije opseg sertifikacije tokom trogodišnjeg ciklusa. Moguće je da se sprovedu i vanredni dodatni auditi ukoliko je potrebno (specijalne posete sertifikacionog tela). Na kraju ovog perioda, sertifikaciono telo može produžiti validnost sertifikata za novi period od tri godine pod uslovom pozitivnog rezultata procesa ponovnog ocenjivanja. Vremenski zahtevi procesa ocenjivanja zavise od različitih faktora:

• Veličine opsega aktivnosti koje su pokrivene procesom ocenjivanja,• Brojem lokacija u organizaciji koje se posećuju u okviru ocenjivanja,• Poslovnih funkcija u okviru opsega ocenjivanja,• Eventualnih drugih sertifikacija koje se mogu uzeti u obzir.

Čitava ideja sertifikacije po ISO/IEC 27001 standardu je kontinualno upravljanje i poboljšanje vašeg sistema upravljanja informatičkom bezbednošću. PDCA model je jedan ciklični proces koji vam pomaže da ažurirate vaš sistem informatičke bezbednosti. Postoje nekoliko stvari koje možete činiti u cilju osiguranja da se održava željeni nivo bezbednosti prema ISO/IEC 27001 standardu, kao što su:

• Stalna provera da li bezbednosne kontrole rade i da li su efektivne,• Praćenje promena koje mogu imati uticaj na ISMS sistem, kao što su

izmene u rizicima po vašu organizaciju, izmene u poslovnim aktivnostima, itd., i poboljšavanje sistema gde god je to neophodno.

Svrha ovih provera nadzora i ponovnog ocenjivanja je da se verifikuje da je ISMS sistem i dalje u saglasnosti sa zahtevima ISO/IEC 27001 standarda, kao i da je ISMS sistem ispravno implementiran i održavan (Da li je opseg ISMS sistema i dalje validan? Da li su primenjeni bezbednosni mehanizmi i dalje efektivni? Da li postoji odgovarajući program nadzora i poboljšanja? itd.).

13

Neke promene će se verovatno desiti u vašoj organizaciji pre ili kasnije, kao na primer: promene u fokusu organizacije, promene IT sistema, promene u proizvodima ili promene koje se više odnose na informatičku bezbednost, kao što su nove pretnje i ranjivosti. Sve te promene mogu imati uticaj na rizike po vašu organizaciju, tako da kadgod se desi neka značajnija promena, vaša ocena rizika treba da bude preispitana i po potrebi ažurirana, a nove bezbednosne kontrole treba da budu identifikovane kada god je to neophodno. Sve nove bezbednosne kontrole koje su identifikovane tokom provere trenutnog statusa informatičke bezbednosti u organizaciji treba da budu implementirane, što uključuje:

• Implementaciju svih neophodnih promena, ažuriranja, novih bezbednosnih kontrola, modifikovanih procedura, itd.

• Ažuriranje dokumentacije i zapisa gde god se to zahteva.• Revidiranje ISMS sistema ukoliko je potrebno i osiguranje da revizije

dostižu željene ciljeve.• Kada se sva poboljšanja implementiraju, neophodno je informisati sve

zainteresovane jer to može imati implikacije na njihov posao.

14