SESAME

Secure European System for Aplications in a Multi-vendor Environment

Uvod

Razvoj SESAME projekta

Karakteristike SESAME-a

Arhitektura SESAME

Autentifikacijski sistem SESAME

GSS-API

Usporedba protokola SESAME i Kerberos

Prikaz autentifikacije u SESAME sustavu (PowerPoint)

Uvod

U većini današnjih sistema, zaštita podataka u višekorisničkim računalnim okruženjima postignuta je prijavljivanjem korisnika na računalo pomoću zaporke. Ako je korisnik fizički udaljen od računala njegova zaporka se mora prenjeti do računala putem mreže. Ta činjenica za sobom povlači određene poteškoće; kao prvo takav jednostavan sistem nije siguran, budući da svatko tko može "slušati" mrežu može saznati korisnikovu zaporku, te tako "oponašati" korisnika; ako bi se pak za svako novo prijavljivanje na računalo koristila nova zaporka, bilo bi vrlo nezgodno korisniku pamtiti toliko zaporki.

Da bi se izbjegli ti i slični problemi razvijaju se protokoli za sigurnu autentifikaciju, tj. protokoli za potvrdu identiteta korisnika ili procesa. Autentifikacija znači određivanje da li korisnik ili proces ima dozvolu izvoditi određenu operaciju.

Do danas je postignut veliki napredak u razvoju takovih protokola. Osmišljavani su i proučavani mnogi načini autentifikacije. Kerberos autentifikacijski protokol, razvijen na američkom univerzitetu MIT (Massachusetts Institute of Technology) 1987. godine, je jedan od najpoznatijih među njima i ako je njegova raširenost i primjenjivanost dobro mjerilo, vrlo uspješan. Pa usprkos njegovoj širokoj primjeni i on ima ograničenja, te se tako javlja potreba za stalnim unapređivanjem autentifikacijskih protokola.

U Europi u nedostatku protokola toga tipa mnoge se organizacije odlučuju da ne poduzmu ništa glede sigurnosti svojih podataka, ili da se pak osiguraju kod osiguravajućih društva od gotovo neimenovne katastrofe. U takvoj situaciji stvorena je dobra podloga za stvaranje novoga sigurnosnog protokola. SESAME (A Secure European System for Aplications in a Multi-vendor Environment) je jedan od takvih protkola.

Razvoj SESAME projekta

SESAME projekt svoje korijene vuče iz rada ECMA (European Computer Manufacturers Association). 1987. godine ECMA počinje raditi na sigurnosti u otvorenim sustavima. Tu su i postavljene prve ideje na kojemu se zasniva SESAME. U ožujku 1991. godine projekt ECMA arhitekture, teorijski vrlo razrađen, pokazuje se i kao praktički izvediv. Uspjeh rada ECMA na otvorenim sustavima potiče Europsku Zajednicu da financira rad ECMA pod imenom RACE program kojim se nastoji implementirati teorija u praktičnu realizaciju, tako nastaje Projekt SESAME. Konkretni ciljevi u ostvarenju SESAME projekta su definiranje i implementacija, kako sustava za autentifikaciju, tako i za upravljanje kontrolom pristupa. SESAME projekt preuzimaju Bull SA, ICL (International Computers Ltd) i Siemens Nixdorf Informationssysteme AG, vodeći europski proizvođači računala, uz djelomično financiranje od strane EZ. SESAME bi trebalo biti moguće prodavati na Europskom tržištu, te bi tako morao odgovarati zakonskim zahtjevima koje postavljaju različita nadležna tijela Europske Zajednice. Budući da je američko tržište vrlo veliko, sustav bi se trebao moći prodavati i na tome tržištu. Nažalost europski i američki propisi su vrlo različiti, te bi to bilo teško ostvariti. Zbog toga razloga u Kerberos sustav uključena je kompatibilnost sa Kerberos autzentifikacijskim protokolom, koji se koristi u SAD-u.

U srpnju 1994. godine izlazi beta verzija SESAME autentifikacijskog projekta pod oznakom V2. Ova verzija bila je stavljena na raspolaganje članovima SESAME End User Group (SEUG) u istarživačke svrhe. Prihvaćajući komentare ove gurupe korisnika i dodavanjem dodatne podrške ekripcije pomoću javnoga ključa, u lipnju 1995. godine izlazi verzija V3. Obje verzije ponuđene su besplatno u nekomercijalne istraživačke svrhe grupi SEUG. Podaci dobiveni tim ispitivanjima utjecali su na razvoj SESAME-a. Jedina prepreka javnoga korištenja SESAME-a bilo je dobivanje dozvole vlade SAD-a za korištenja Kerberos koda unutar protokola SESAME. Uskoro je bilo uočeno da se to neće dogoditi, tako da je donesena odluka da se u potpunosti ponovo napiše Kerberos dio protokola SESAME. što dovodi do konačne verzije SESAME-a V4, o kojoj će se ovdje govoriti.

SESAME sam po sebi nije komercijalni projekt, već je predviđen kao jezgra sigurnosti na kojoj se mogu izgraditi različiti stvarni projekti. SESAME je zamišljen tako da se u njegovim implemetacijama može nekim njegovim komponentama pristupiti kroz Kerberos V5 protokol, te da koristiti strukture podataka Kerberos protokola, kao i svoje nove strukture podataka proistekle iz teorijskog razvoja ECMA. Ova kompatibilnost omogućava da korisnici SESAME-a mogu komunicirati na siguran načina sa korisnicima Kerberos sustava i obratno.

Karakteristike SESAME-a

Glavna funkcija SESAME protokola je da osigura potokole i za autentifikaciju i za uparavljanje kontorlom pristupa u smislu interakcije klijent – poslužitelj. SESAME omogućava sljedeće prednosti:

• Uzajamna ili jednostruka autentifikacija korištenjem Kreberosautentifikacije ili autentifikacije koja se temlji na korištenju javnoga ključa
• Tajnost i integritet informacije koja se prenosi
• Kontrola pristupa koja se temelji na ulogama Role Based Access Control (RBAC)
• Ovlaštenje prava korisnika
• Usluga vođenja podataka o radnjama u sustavu (audit)
• Podrška za više domena

Ove mogućnosti su dizajnirane za funkcioniranje unutar jedne domene, ali i preko više domena. Ostalie arhitekture, od kojih je većina baziranih na Kerberosu, su dizajnirane za jednu domenu i imaju problema sa primjenjivanjem na veliki broj domena.

Programima koje se koriste SESAME tehnologijom moguće je pristupiti korištenjem "single point of login", tako da se korisnik autentificira samo jedanputa. Značenje "single point of login" je u tome da se korisnik samo jednom autentificira, iako kasnije može pristupiti i drugim raznim uslugama na raznim poslužiteljima koji se protežu na više računalnih sustava. Taj način prijavljivanja na sustav stvara određene probleme, jer mjesto pristupa više nije u istoj točki gdje i mjesto autentifikacije. Da bi korisnik dokazao svoj identitet, njegova se autentifikacija mora prenijeti na siguran načina do mjesta gdje će ona biti potvrđena, i to preko potencijalno nesigurnih komunikacijskih veza. SESAME koristi kriptografske mehanizme da bi pomogao u tome zadatku, i to na dva načina: autentifikacijom sa zaporkom (kao Kerberos) i autentifikacijom u kojoj se koristi asimetrična kriptografija (npr. metoda javnoga ključa).

SESAME ne kontrolira samo osobu kao korisnika, već on može kontorlirati i neku aplikaciju koja djeluje samostalno. Prema tome kada se govori o korisniku, tj. "inicijatoru" ne misli se samo na osobu, već i na aplikaciju.

Arhitektura SESAME

Na prvi pogled arhitektura SESAME-a je vrlo kompleksna, ali moguće je razlučiti četiri osnovna dijela: Klijent (Client), Domena sigurnosnog poslužitelja (Domain Security Server), Poslužitelj (Server), Komponente za podršku (Support Components). Ovdje se u smislu Klijent-Poslužitelj aplikacije klijenta ponašaju kao inicijatori koji komuniciraju sa aplikacijama poslužitelja koje su ciljevi klijentovi aplikacija.

SESAME arhitektura

Klijent

Klijentom su obuhvaćeni User Sponsor (US), Authentication Privilege Attribute (APA), Client, Secure Association Contex Manager (SACM) i Client applicaion. US daje korisniku sučelje prema SESAME sistemu, dozvoljavajući korisniku da se prijavi na sistem. APA koristi US za komunikaciju sa domenom sigurnosnog poslužitelja i to tako da skriva detalje dijaloga kojima se pristupa AS-u i PAS-u. U SESAME je APA ugrađen kao library rutina.

SACAM osigurava servise zaštite podataka (autentifikaciju podataka, pouzdanost podataka) za interakciju Klijent-Poslužitelj.

Domena sigurnosnog poslužitelja

Domena sigurnosnog poslužitelja je jezgra SESAME-a i vrlo je slična onoj kod Kerberosa. Sastoji se od tri aktivna upravljačka dijela i baze podataka. Upravljački djelovi su poslužitelji Authentication Server (AS), Key Distribution Server (KDS) i Privilege Attribute Server (PAS), a baza podataka se naziva Security Management Information Base (SMIB).

PAS služi za upavljanje mehanizmom kontrole pristupa, i u upravo ovome dijelu je najveća razlika između Kerberos i SESAME protokola. Kada se korisnik prijavi na sustav on tada daje autentifikacijsku i privilegijsku potvrdu. Autentifikacijska potvrda se koristi za potvrdu identiteta korisnika, dok se privilegijska potvrda služi za utvrđivanje privilegija korisnika. PAS sdrži odgovarajuće Privilege Attribute Certificates (PACs), privilegijske certifikate korisnika, koji su digitalno potpisana obilježja od strane PAS-a i sadrže informacije o korisnicima na temelju koje se donosi odluka o kontroli pristupa, tj. što je korisniku dozvoljeno u sustavu i što nije. Uz pomoć privilegijskih certifikata korisnik može pristupiti računalu koje ne zna ništa onjemu, ali može provjeriti korisnikove privilegije iz certifikata. Na zahtjev PAS vraća odgovarajućiprivilegijski certifikat PAC korisnikovu SACM-u.

KDS i AS poslužitelji imaju funkciju kao i njihove inačice u Kerberos sustavu koje upravljaju kriptiranim ključevima. AS služi za autentifikaciju korisnika. Ekvivalent KDS-a u Kerberosu se naziva “Ticket granting server”. KDS u se koristi za generiranje ključeva za komunikaciju aplikacija unutar domene i također njihovo prevođenje za ciljeve komunikacije unutar domene. KDS, zahvaljujući postojećoj kompatibilnosti, prihvaća ulaznice od Kerberos klijenata i automatski detektira da li je pozivatelj Kerberos ili SESAME klijent. U slučaju autentifikacijske metode sa asimetričnim kriptiranjem, KDS poslužitelj nije potreban. Jedna od velikih razlika između Kerberosa i SESAME-a je u tome da SESAME podržava javne ključeve (asimetrično kriptiranje), dok Kerberos ne. Javni ključevi su asimetrični kriptografski mehanizmi i baziraju se na X.509 autentifikacijskom mehanizmu.

SMIB pohranjuje sve dugoročne sigurnosne podatke koji su potrebni AS, PAS i KDS poslužiteljima koji na temelju njih grade sigurnosne konstrukcije. Ta baza je skup lokalnih datoteka, koja nije direktno vidljiva budući da je SMIB baza podataka uvijek administrirana koristeći Control Program (SESADMIN). SESADMIN dozvoljava administatoru sigurnosne domene da specificira autentifikacijski mehanizam (tajni ili javan), te ostale informacije o korisnicima (privilegijske atribute za PAS, kao i sve ostale atribute).

Aplikacijski poslužitelj

Aplikacijski poslužitelj se sastoji od usluge provjeravanja privilegija PAC Validation Facility (PVF), poslužiteljskog SACM i Application Server, aplikacijskog poslužitelja.

SACM ima istu ulogu kao i kod klijenta, da osigurava servise zaštite podataka za interakciju klijent-poslužitelj. Svaka ciljna aplikacija u krajnjem računalnom sustavu povezana je sa jednim PVF-om kroz SACM toga računala, pri čemu više od jedne aplikacije može biti povezano sa dobivenim PVF-om. PVF je smješten uz aplikaciju koju podržava, iako će u kasnijim verzijama SESAME-a biti podržan PVF koji će biti udaljen od aplikacija, npr. predviđen je jedan PVF poslužitelj visoke sigurnosti koji će podržavati cijelo područje neke lokalne mreže. PVF pokreće vlastite zaštićene procese i dostupan je pomoću međuprocesorskih poziva. Kada aplikacijski poslužitelj primi poruku od aplikacijskog klijenta, dajući do znanja da želi uspostaviti vezu, on prosljedi poruku prema PVF-u. PVF provjerava da li klijent ima pristup aplikaciji. Ako je provjera uspješna, SACM aplikacijski poslužitelj autentificira klijenta i osigurava komunikaciju sa klijentom.

Komponente za podršku

Komponente za podršku čine Audit, upravljanje javnim ključevima Public Key Management (PKM), usluga za podršku kriptografije Cryptographic Support Facility (CSF). Audit komponenta bilježi sve radnje vezane uz sigurnost. Događaji se bilježe uz pomoć audit demona kojemu informacije dolaze preko cjevovoda koji je podešen samo za pisanje. Za svaki događaj postoji jedan zapis, tako da se sva događanja u sistemu mogu kasnije podrobno analizirati.

PKM usluga koristise od strane klijenta, PAS-a, PVF-a u ciljnim sustavima, KDS-a kada obrađuje distribuciju ključeva među domenama. PKM osigurava relativno jednostavnu funkcionalnost, ali je ujedno i tako dizajniran da gaje moguće vrlo lagano proširiti. Uopće PKM se koristi za upravljanje ključevima, od javnih do tajnih (PAS; KDS, PVF i inicijator mogu imati tajne ključeve). To upravljanje PKM obavlja zajedno sa CSF-om.

CSF je zadužen za osiguravanje svih algoritamskih kriptografskih usluga potrebnih drugim SESAME komponentama i aplikacijama koje SESAME podržava. Nek od usluga koje pruža sustav su: simetrična i asimetrična enkripcija i dekripcija, nepovratnu enkripciju, generiranje slučajnih brojeva i ključeva, generiranje para asimetričnih ključeva i druge.

Privilegijski sistem SESAME – kontrola pristupa

Privilegijski sustav dizajniran je u radu ECMA i jedno je od glavnih obilježja SESAME-a. Cilj je je bio razviti privilegije koje nisu specifične za niti jedan krajnji korisnički sustav. Na temelju privilegija kontrolirao bi se pristup korisnika do određenih sredstva. Korisnik bi dobio privilegije koje bi se mogle koristiti za autorizaciju direktno od strane aplikacije ili bi bile mapirane od strane aplikacije zavisno od stanja lokalnog operativnog sustava. Prednost toga da aplikacija direktno donosi autorizacijske odluke je u tome, što je na taj način aplikacija prenosiva preko različitih operacijskih sustava (sa stajališta autorizacije).

Ideja je da postoji središnja baza podataka (PAS) o informaciji o kontroli pristupa definiranoj za svakoga korisnika posebno koju bi održavao administrator. Informacija o kontroli pristupa se prenesi do aplikacijskog poslužitelja u obliku privilegijskog certifikata (PACs).

Privilegijski sustav dizajniran je na temelju “uloga”. Korisniku je dodjeljena uloga kada se korisnik kreira u SESAME sistemu, a kada se korisnik prijavi u sustav PAC sadrži ulogu koju korisnik koristi. U jednoj sesiji korisniku se pridružuje jedna i samo jedna uloga. Uloge su numerirani i određeni identifikatori. Za svakoga korisnika postoji lista uloga koje on može imati. Sredstva kojim korisnik pristupa donose odluku koja se temelji na informaciji o ulozi u PAC-u, tj. korisnikovom privilegijskom certifikatu. Postoje dvije vrste certifikata:

1. certifikati bez ovlasti (non-delegatable PACs) – vezani su za određeni identitet i prenose sigurnu informaciju u određenoj sesiji (mogu se razlikovati od sesije do sesije).
2. certifikati sa ovlastima (delegatable PACs) – djeluju kao sposobnosti, mogu se koristiti da privremeno prenesu neka od prava pristupa korisnika do poslužitelja, koji ne bi treba predstavljati korisnika. Uz pomoć ovlaštenih certifikata prava korisnika koja se prenose su maksimalno ograničena.

Oba certifikata su vremenski ograničena (u trajanu od nekoliko sati) da bi se ograničila kompromizacija ključa. Certifikati sa ovlastma omogućuju tajnost klijenta, budući da ne sadrže identite korisnika, krajnji cilj kojemu klijent želi pristupiti nemaju informaciju o njemu. Tragovi zapisani u audit logovima sadrže dovoljno informacija da omoguće administratoru zaduženom za sigurnost uvid u identite kolijenta ako je to potrebno.

Format privilegijskih certifikata je nezavisan o sigurnosnoj politici domene. Detalji o sigurnosnoj politici su sadržani u sistemskim komponentama koje stvaraju ili interpretiraju privilegijske certifikate; PAS i kontrolna logika svakoga aplikacijskog poslužitelja. Ovaj način djelovanja autorizacijskog sistema je nezavisan od svojstva operativnog sustava, te je iz toga razloga bolji od tradicionalnih lista za kontrolu pristupa. Sam sadržaj PAC-a definiran je ECMA-inim standardom. Uobičajeni sadrži privilegijskog certifikata:

SESAME također pruža mogućnost usluge mapiranja privilegija koje nadvladava probleme različitih privilegija širom velikih sistema. Dužnost PVF je da prevede dobiven privilegijski atribut u ulogu koja je relevantna za ciljnu domenu. Na slici je prikazan postupak provjere privilegijskog certifikata, koji je naveden u poglavlju sa autentifikacijskim protokolom

SESAME sistem za provjeru privilegija

Kada klijent u SESAME sustavu želi pristupiti poslužitelju, klijent šalje svoj PAC poslužitelju. Da bi potvrdio privilegijske certifikate, poslužitelj certifikate šalje u PVF lokalne domene. PVF provjeruje da PAS signatura na PAC-u odgovara jednom od PAS-ova koji se nalaze u PVF-ovoj listi povjerenja (Trusted List). PAS lista nije ograničena i može sadržati PAS lokalne domene, kao i PAS-ove stranih domena.

SESAME sistem povjerenja nema problema sa skalabilnošću. Kad administrator jedne domene odluči “vjerovati” drugoj domeni, potrebno je da administrator samo dobavi X.509 certifikat od PAS-a te domene iz X.500 direktorija.

Autentifikacijski sistem SESAME

Pojednostavljeni autentifikacijski protokol

SESAME autentifikacija

1. Korak

Klijant šalje autentifikacijskom poslužitelju svoja autentifikator koji sadrži identifikator klijenta, te daje do znanju da se želi autentificirati u SESAME sustav.

2. Korak

Autentifikacijski poslužitelj autentificira poslužitelja, generira sesijski ključ za potrebu komunikacije korisnika i ostalih komponenti domene sigurnosnog poslužitelja, ulaznicu za dodjelu ulaznica i autentifikator. Sve to šalje natrag klijentu.

3. Korak

Klijent se u ovom koraku obraća poslužitelju privilegijskih atributa i poslužitelju za distribuciju ključeva. Od PAS-a klijent traži svoje privilegijske atribute, a KDS-u šalje ulaznicu za dodjelu ulaznica koju je dobio od autentifikacijskog poslužitelja i autentifikator.

4. Korak

Poslužitelj privilegijskih atributa vraća klijentu njegov privilegijski certifikat PAC. Poslužitelj za distribuciju ključeva klijentu vraća ulaznicu i novi sesijski ključ.

5. Korak

Klijent poslužitelju šalje svoj privilegijski certifikat i ulaznicu dobivenu od KDS-a. Unutar ulaznice nalazi se kriptirani i sesijski ključ koji je generirao klijent, a služiti će za komunikaciju između poslužitelja i klijenta. Uovome koraku se i odvija provjera privilegijskog certifikata unutar računala poslužitelj.

6. Korak

Ako je poslužitelj prihvatio klijentov certifikat, on se autentificira klijentu, nakon čega je moguća sigurna komunikacija između klijenta i poslužitelja.

Protokol

Protokol koji će biti opisan je dobiven od International Standards Organization, 1993. Grafički je protokol prikazan u obliku PowerPoint dokumenta.

Napomena: Ovaj protokol nije potpun, iz njega su izostavljene neki manje važni dijelovi poruka kojima komuniciraju komponente u SESAME sustavu.

U opisu kriptografskih operacija biti će korištena sljedeća notacija:

• PE{m, KAB} – poruka m digitalno zapečačena simetričnim ključem KAB

• E{m, KAB} – poruka m kriptirana simetričnim ključem KAB

• PO{m, SA} – poruka m digitalno potpisana tajnim ključem SA

• E{m, PA} – poruka m kriptirana javnim ključem PA

Pod digitalno zapečačena poruka PE{m, KAB} podrazumjeva se tekst poruke m u običnom text formatu, koju slijedi poruka o informaciji dobivena računski pmoću KAB poruke m. SESAME se oslanja na pretpostavku da se sadržaj zapečačene poruke može pročitati bez znanja ključa koji je korišten za proračun pečata.

Poruka m kriptirana simetričnim ključem KAB, E{m, KAB}, treba imati zaštitu integriteta i tajnosti. SESAME to postiže enkripcijom povezanog sažetka (hash) poruke m i poruke m same.

Za digitalno potpisanu poruku PO{m, SA} podrazumjeva se da je to poruka m koju prati sažetak (hash) poruke m potpisna digitalno pomoću javnoga ključa.

Tijela koja sudjeluju u protokolu

• A: Autentifikacijski poslužitelj
• P: Privilege Attribute Server
• G: Poslužitelj za distribucijuključeva
• U: User Sponsor
• R: Korisnik
• X: Aplikacijski klijent
• Y: Aplikacijski poslužitelj
• V: PVF poslužitelja Y

Kriptografski ključevi

Prije početka rada protokola pretpostavlja se da su sljedeći ključevi na svome mjestu:

• LKAPG : dugotrajniključ između A, P, G
• PX : javni kljč od X-a, poznat drugima
• SX : tajni ključ od X-a, poznat samo X-u
• DCX : Direktorijski certifikat javnoga ključa od X-a

Tijekom rada protokola generiraju se sljedeći ključevi:

• BKUPG : ključ generiran od strane A za korišćenje između U i P ili G
• BKXV : ključ generiran za komunikaciju između X i V (Y-ov PVF)
• IKXY : ključ integriteta izveden od BKXV, za uporabu između X i Y
• CKXY : ključ tajnosti dobiven iz BKXV, za uporabu između X i Y

Ostali dijelovi protokola

• RA : zatraženi atributi
• PA : privilegijski atributi
• RLX : zatraženo vrijeme života ključa BKX
• LX : vrijeme života klljuča BKX
• t : vremenska marka
• r : neponavljajući broj
• n : redni broj poruke

Primjer rada SESAME protokola unutar domene

Korak 1.

Korisnik U šalje autentifikator autentifikacijskom poslužitelju A. Autentifikator sadrži:

• identitet klijenta, U
• DCR koji predstavlja X.509 certifikat za javni ključ PR,
• zatraženo virijeme života ključa BKUPG,
• potpisanu poruku m = (A, r, t) u kojoj se nalazi neki slučajni broj r ili vremenska marka t kriptirani privatnim ključem korisnika SR.

Korak 2.

Na dobitak poruke autentifikacijski server A na temelju dobivenoga certifikata DCR vadi javni ključ korisnika PR. Uz pomoć ključa PR, autentifikacijski poslužitelj provjerava digitalni potpis poruke m. Nakon provjera potpisa provjerava i vremensku marku, tj. da li je vrijeme trenutno. Ako je sve u redu, korisnik A je autentificiran u sistem.

Autentifikacijski poslužitelj sada generira sesijski ključ BKUPG koji će se koristiti samo za ovu sesiju. Poslužitelj ključ kriptira svojim privatnim ključem. On ga šalje zajedno sa ulaznicom za dodjelu ulaznica koja ima identičnu ulogu kao i ona kod Kerberosa. U ulaznici se nalazi Primary Principal Id (PPID) što je broj od DCR certifikata, koji se koristi kao jedinstvani identifikator. Ulaznica je kriptirana dugoročnim ključem koji je poznat samo poslužiteljima u sigurnosnoj domeni (AS, KDS, PAS). Osim ključa i ulaznice poslužitelj šalje i svoj autentifikator, koji sadrži identifikator poslužitelja A, njegov direktorijski certifikat, i vraćenu poruku m’ = (U, r, r’, t’) u kojoj poslužitelj vraća dobiveni broj r, da bi potvrdio svoj idetitet korisniku U.

Korak 3.

Treći korak je identičan Kerberosovom KBR-TGS-REQ koraku u kojemu korisnik zahtjeva ulaznicu od KDS-a (TGS-a u Kerberos sustavu), koristeći ulaznicu za dodjelu ulaznica. Korisnik U provjerava autentifikator aplikacijskog poslužitelja sa javnim ključem PA, koji je dobio uz pomoć DCA. Ako je provjera uspješna ostvarena je uzajamna autentifikacija korisnika i autentifikacijskog poslužitelja.

Korisnik će uz pomoć svoga privatnoga ključa dekriptirati poruku koja sadrži sesijski ključ. Uz pomoć njega će korisnik u nastavku komunicirati sa sustavom.

Nakon uzajamne autentifikacije autentifikacijskog poslužitelja i korisnika, korisnik šalje poruku poslužitelju za distribuciju ključeva KDS. U ovome koraku koriste se standardne Kerberos ekstenzije zajednosa SESAME ekstenzijama. Kerberos ekstenzije sadrže ulaznicu za dodjelu ulaznice plus autentifikator. Ulaznica za dodjelu ulaznica je ista ona ulaznica koju je korisnik dobio od autentifikacijskog poslužitelja u koraku 2. Autentifikator sadrži sažetak tijela poruke (hash) da bi se osigurala originalnost podataka. SESAME dio ove poruke je onaj u kojemu korisnik traži svoje privilegije. Zahtjev sadrži vremensku marku i zahtjev za privilegijske atribute, zapečačene sesijskim ključem BKUPG.

Korak 4.

Ovaj korak je identičan Kerberosovom koraku KRB-TGS-REP. KDS dekriptira ulaznicu za dodjelu ulaznica dugoročnim ključem LKAGP. U toj ulaznici nalazi se sesijski ključ BKUPG koji KDS koristi za potvrdu autentifikatora dobivenog od korisnika. Ako je potvrda uspjela on korisniku vraća ulaznicu u kojoj se nalazi novi sesijski ključ BKXG, generiran od strane KDS-a. Novi ključ se koristi za autentifikaciju zahtjeva za ulaznicu koji se temelji na novoj ulaznici za dodjelu ulaznica, što znači da sljedeći puta kada će korisnik htjeti pristupiti KDS-u koristiti će ključ BKXG, a ne BKUPG. Vraćena ulaznica je nova ulaznica za dodjelu ulaznica. U ovom koraku vraća se odgovor na klijentov zahtjev za privilegijama. PAS na temelju dobivenog zahtjeva, identiteta korisnika i podataka u SMIB bazi podataka, kreira privilegijski certifikat PAC. Vraćeni certifikat se sastoji od vremenske marke i dobivenih privilegijskih atributa korisnika, digitalno zapečačenih ključem BKUPG. Certifikat sadrži i PPID, na taj način se privilegijski atributi PA vežu uz ključ BKXG.

Daljna komunikacija se odvija između korisnika i ciljnog poslužitelja. Komunikacija je ostvarena njihovim SACM-ima. U klasičnom Kerberos protokolu bila bi potrebna još dva koraka da bi se dobio sesijski ključ BKXV. U ovom slučaju ciljani PVF (V) od strane klijenta određen je svojim javnim ključem PV, tako da X može sam generirati BKXV i proslijediti ga PVF-u. Javni ključ KV može biti dobiven iz X.500 direktorija. Rezultat toga je smanjenje koraka u protokolu u odnosu na Kerberos (KRB-AP-REQ i KRB-AP-REP) .

Korak 5. SES-INIT-CTXT

Poruka koju korisnik šalje poslužitelju prenosi se preko SACM komponenti. Poruka se sastoji od privilegijskog certifikata, ulaznice koju je kreirao korisnik, dva generirana slučajna broja i identifikatora ciljanog poslužitelja. Poruka je zapečačena sa integracijskim ključem IKXY da bi se osigurao integritet podataka i da bi se mogao autentificirati X. Poruka sadrži informaciju koja će PVF-u poslužitelja Y, tj. V-u, trebati da bi dobio ključ IKXY. Neka je poruka M:

Rezultirajuća poruka koju korisnik šalje poslužitelju je sljedeća:

Ključevi integriteta i tajnosti poruke, IKXY i CKXY, su dobiveni izračunavanjem iz ključa BKXV, koristeći jednosmjernu funkciju i slučajan pomak (rs1 i rs2) dobiven od X.

IKXY = H1(BKXV, rs1)

CKXY = H2(BKXV, rs2)

Korak 5a. SACMtoPVF

Poslužitelj Y šalje dobivenu informaciju od X-a PVF-u na obradu. Ovaj prijenos informacija odvija se unutar jednoga računala, pa SESAME pretpostavlja da je informacija unutar računala sigurana i tajna.

PE{M, BKXV}

Korak 5b. PVFtoSACM

PVF dekriptira ulaznicu dobivenu od X-a sa privatnim ključem SV da bi dobio ključ BKXV. PVF nakon toga mora izvršiti sljedeće provjere:

• Treba potvrditi valjanost pečata na cijeloj poruci sa ključem BKXV
• Treba provjeriti da li indetifikator ciljanog poslužitelja Y unutar poruke odgovara identitetu poslužitelja za kojega PVF radi
• Treba provjeriti digitalni potpis privilegijskog certifikata sa javnim ključem PP
• Treba provjeriti da li PPID unutar privilegijskog certifikata odgovara PPID-u unutar ulaznice
• Treba primjeniti sve potrebne provjere kontrole pristupa, temeljene na atributima koji se nalaze unutar privilegijskog certifikata, identiteta X-a i identiteta Y.

Nakon ovih radnji PVF prosljeđuje poslužitelju Y ključeve IKXY i CKXY. Ponovo pretpostavljajući da je sigurnost unutar jednoga računala osigurana.

Korak 6. SES-INIT-CTCX-COMPLETE

Poslužitelj Y se autentificira X-u porukom koja je zapežažena ključem IKXY.

PE{(t’’’, n’), IKXY}

Korak 7. SES-DATA

Klijent i poslužitelj mogu sada razmjenjivati podatke. Koju zaštitu i njezin stupanj će se pri tome koristiti zavisi od aplikacija koje koriste SESAME. Zaštita poruka može biti u oba smjera. Mogu biti samo zapečačene ili samo kriptirane, ili jedno i drugo, pri čemu se u ovome slučaju enkripcija izvodi prije pečačenja.

SESAME koristi vlastiti format poruka:

Impmentacijske bilješke

Za trenutačnu implementaciju SESAME koristi sljedeće algoritme za enkripciju:

• PE{m, KAB}: DES-MAC enkripcija
• E{m, KAB}: DES u CBC modu zajedno sa MD5
• PO{m, SA}: RSA (512 bita) zajedno s MD5
• E{m, KA}: RSA (512 bita)
• H( ): MD5 hash funkcija za izračunavanje sažetka poruke

U duhu nedavnih razvoja predlaže se da se povećanjedužine u bitovima RSA enkripcije sa 512 na 1024 bita, zamjena DES-a sa trostrukim DES-om ili bilo kojim drugom algoritmom sa ključem duljim od 80 bita, zamjena hash funkcije MD5 sa funkcijom RIPE-MD 160 duljine 160 bita. Budući da je SESAME kod pisan u modularnom obliku te izmjene vrlo je lako ostvariti.

Problemi sa SESAME V4

Čak i Europi može biti nekih problema oko korištenja jake kriptografije. Zbog toga Senior Officials Group on Information Security (SOGIS) savjetuje da se DES ne uvrsti u distribuciju SESAME-a. DES je zamjenjen jednostavnim XOR algoritmom. Korisnici SESAME-a mogu ga zamjeniti vlastitom implementacijom DES algoritma (više javnih verzija može se naći na Internetu).

Tajni ključ korisnika, korištena da bi se generirao njegov digitalni potpis, je zaštićen jedino UNIX-ovom kontrolom pristupa. Da bi se to riješlo mogu se koristit zaštitni načini sa passphrase kakvi se koriste u PGP-u.

Aplikacije koje žele u potpunosti biti prilagođene prednostima ove tehnologije, moraju biti SESAMISED, prilagođene SESAME-u. Nasreću SESAME je usvojio GSS-API koji minimizira napore oko programiranja.

GSS-API

Cilj Generic Security Services Application Program Interface (GSS_API) je osigurati aplikacijskom programeru jedinstvenu biblioteku funkcija koje implementiraju sigurnosne mjere u odnos klijent – poslužitelj. Time se omogućuje da programer ne mora znati kakoSESAME protokol funkcionira da bi ga ugradio u svoju aplikaciju. Za programera je potrebno da zna samo osnove o sigurnosnom komuniciranju da bi mogao upotrijebiti ispravne pozive svojih funkcija.

Više protokola za mrežnu sigurnost podržava GSS-API, ali sa različitim stupnjevima funkcionalnosti. Npr. Kerberos GSS-API daje programeru set sigurnosnih usluga koje se temelje na mogućnosti Kerberos arhitekture. U odnosu na SESAME GSS-API on je ograničen jer podržava samo uzajamnu autentifikaciju, integritet podataka i njihovu tajnost, dok SESAME GSS-API podržava i sve svoj ostale funkcije.

U osnovi, SESAME GSS-API klijent-poslužitelj aplikacije djeluju na sljedeći način. Oboje i klijent i poslužitelj će zahtjevati vjerdjanice jedan od drugoga, izvodeći autentifikaciju (gss_acquire_credential) sa sigurnosnim poslužiteljem. Klijent će tada predati svoj kontekst (koji sadrži ključne informacije i privilegijski certifikat) (gss_init_sec_context) poslužitelju. Poslužitelj tada može donijeti odluku o kontroli pristupa u zavisnosti od dobivrnih informacija, i u slučaju uspješne odluke uspostaviti sigurnu vezu između sebe i klijenta (gss_accept_sec_context). U slučaju da je potrebna uzajamna autentifikacija , poslužitelj bi vratio znak klijentu, koji bi trebao biti potvrđen od strane klijenta, prije nego što se uspostavi veza od strane poslužitelja. Klijent u petlji vrti zahtjev gss_init_sec_context dok ne dobije znak od poslužitelja. Od trnutka kada je uspostavljena veza klijent i poslužitelj mogu koristiti uslugu sigurnog prijenosa poruka koju omogućava GSS-API, kao što je enkripcija (gss_seal, gss_unseal) i digitalni potpis (gss_sign, gss_verify). Kada je veza između klijenta i poslužitelja prekinuta, sigurnosni kontekst se briše (gss_delete_sec_context).

Usporedba protokola SESAME i Kerberos

Ključna razlika između ova dva protokola je u tome što SESAME posjeduje mogućnost kontrole pristupa. Iz te činjenice proistječu sve njegove prednosti u odnosu na Kerberos protokol. Zahvaljujući kontroli pristupa, u SESAME-u su omogućene usluge kao "single point of login, višedomenski rad, uklanjananje nužnoga autentificiranja klijanta poslužitelju, te ostale usluge.

© 2000-2001 Zlatko Čekolj. Svaki dio ovih materijala SMIJE SE umnažati, fotokopirati, širiti Internet-om i Carnet-om, reproducirati na bilo koji način, bez pismene ili usmene dozvole autora. Ovo je seminar iz predmeta "Operacijski sustavi II" i kao takav služi za obrazovanje svih studenata koji slušaju ovaj predmet, svih studenata FER-a, članova njihovih užih i širih obitelji i svih ostalih žednih znanja.