UNIVERSITATEA PETRU MAIOR DIN TRGU-MURE

FACULTATEA DE INGINERIE
SPECIALIZAREA: CALCULATOARE

LUCRARE DE DIPLOM

Autentificarea, autorizarea i controlul accesului n

sisteme distribuite

Coordonator:

Student:

Asist. Ing. Genge Bla

Magyari Istvn Attila

2009

UNIVERSITATEA "PETRU MAIOR" TRGU-MURE

FACULTATEA DE INGINERIE
Specializarea CALCULATOARE

Viza

facultii

TEM PROIECT DE DIPLOM

Conductorul temei:
Candidat (a): Magyari Attila
Asist. ing. Genge Bela
Anul absolvirii: 2009
a) Tema proiectului de diplom: Autentificarea, autorizarea i controlul accesului n
sisteme distribuite
b) Problemele principale care vor fi tratate n proiect:

Introducere n domeniul sistemelor distribuite i a securitii;

Stabilirea problemelor de securitate cu care se confrunt sistemele distribuite existente;

Proiectarea componentelor sistemului prin formularea cerinelor de securitate i
evidenierea modulelor principale pentru satisfacerea acestor cerine;

Proiectarea protocoalelor de securitate implicate n stabilirea unei comunicri sigure ntre
componentele sistemului i verificarea independenei acestora;

Proiectarea unei interfee API pentru implementarea sistemului

Implementarea sistemului propus prin utilizarea arhitecturilor Mozilla.
c) Desene obligatorii:
- Arhitectura sistemului propus;
- Diagrame de secven pentru autentificarea aplicaiilor client;
- Protocoale de securitate proiectate.
d) Softuri obligatorii Visual C++, NSPR, Qt.
Bibliografie recomandat:
1.
2.
3.
4.
5.
6.
7.
8.

Butler Lampson, Martn Abadi, Michael Burrows, Edward Wobber, Authentication in Distributed Systems:
Theory and Practice, ACM Trans. Computer Systems 10, 1992.
Joshua D. Guttman, F. Javier Thayer Fabrega, Authentication tests and the structure of bundles, Theoretical
Computer Science, Vol. 283, No. 2, pag.333-380, iunie 2002.
W. Stallings, Cryptography and Network Security, 4th edition, Prentice Hall, 2005.
A. Menezes, P. van Oorschot, S. Vanstone, Handbook of Applied Cryptography, CRC Press, 1996.
J. D. Guttman, Security Protocol Design via Authentication Tests, 2002.
J. D. Guttman, Security goals: Packet trajectories and strand spaces, In R. Gorrieri and R. Focardi, editors,
Foundations of Security Analysis and Design, volume 2171 of LNCS, Springer Verlag, 2001.
E. Gerck, Overview of Certification Systems: X.509, PKIX, CA, PGP & SKIP, 2000.
C. Szyperski, Component Software Beyond Object Oriented Programming, 2nd edition, Addison Wesley,
pag. 3 47, 2002.

Termene obligatorii de consultaii: - sptmnal

Locul practicii: laboratoarele specifice din facultate
Primit la data de: 15. 03. 2008
Termen de predare: 15. 06. 2009

Semntura efului de catedr

Semntura conductorului
Semntura candidatului

Cuprins
Capitolul 1 Introducere......................................................................................................... 6
1.1 Structura documentului .................................................................................................... 7
Capitolul 2 Aspecte teoretice ................................................................................................ 8
2.1 Criptografia....................................................................................................................... 8
2.1.1 Criptografia simetric ................................................................................................ 8
2.1.2 Criptografia asimetric .............................................................................................. 9
2.1.3 Funcii hash ............................................................................................................. 11
2.2 Protocoale de securitate .................................................................................................. 12
2.2.1 Principii de proiectare.............................................................................................. 13
2.2.2 Proiectare via teste de autentificare ......................................................................... 16
2.2.3 Independena protocoalelor de securitate ................................................................ 17
2.3 Infrastructura Cheilor Publice (PKI) .............................................................................. 18
2.3.1 Certificatele X.509................................................................................................... 19
2.4 Mecanismul Single Sign-On (SSO)................................................................................ 20
2.5 Ingineria programrii bazat pe componente (CBSE).................................................... 21
2.5.1 Application Programming Interface (API) .............................................................. 22
2.6 Platforma Mozilla........................................................................................................... 22
2.6.1 Arhitectura Mozilla.................................................................................................. 23
2.6.2 XPCOM ................................................................................................................... 24
Capitolul 3 Proiectarea sistemului ..................................................................................... 26
3.1 Cerine ............................................................................................................................ 26
3.2 Arhitectura sistemului .................................................................................................... 27
3.2.1 Proiectarea mecanismului Single Sign-on............................................................... 27
3.2.2 Componentele sistemului ........................................................................................ 30
3.2.3 Proiectarea componentei XServer ........................................................................... 31
3.2.3.1 Iniializarea componentei XServer ................................................................... 33

3.2.3.2 Autentificarea unui client ................................................................................. 34

3.2.3.3 Serviciul de resurse........................................................................................... 35
3.2.4 Proiectarea componentei XClient............................................................................ 36
3.2.5 Proiectarea bazei de date ......................................................................................... 38
3.3 Proiectarea interfeei de programare (API) .................................................................... 39
3.4 Proiectarea protocoalelor de securitate........................................................................... 42
3.4.1 Protocolul de autentificare la home server .............................................................. 43
3.4.2 Protocolul de autentificare la serverul de resurse.................................................... 44
3.4.3 Protocolul de solicitare certificat............................................................................. 46
Capitolul 4 Implementarea sistemului............................................................................... 47
4.1 Arhitectura intern a claselor.......................................................................................... 47
4.1.1 Clasele de baz ........................................................................................................ 47
4.1.2 Clasele de securitate ................................................................................................ 50
4.1.3 Canalele de comunicaie.......................................................................................... 52
4.1.4 Servicii..................................................................................................................... 54
4.2 XServer........................................................................................................................... 57
4.2.1 Serviciul de autentificare ......................................................................................... 59
4.2.2 Serviciul de resurse.................................................................................................. 61
4.3 XClient ........................................................................................................................... 63
4.4 Implementarea API-ului ................................................................................................. 65
Rezultate experimentale......................................................................................................... 69
Concluzii .................................................................................................................................. 75
Bibliografie.............................................................................................................................. 76

Capitolul 1 Introducere

Importana aspectelor de securitate in reele de calculatoare a crescut odat cu

extinderea prelucrrilor electronice de date i a transmiterii acestora prin intermediul reelelor.
n cele mai multe sisteme distribuite i reele de calculatoare, protecia resurselor se realizeaz
prin login direct folosind parole, cu transmiterea n clar a acestora. Aceasta autentificare are
mai multe inconveniene, din care cea mai problematic ar fi expunerea parolei la captur
pasiv [1]. n zilele noastre vizitam zeci de website-uri, pe fiecare trebuie s ne cream un cont
de utilizator, completnd cu atenie formulare de nregistrare, s reinem parole, i s le
introducem de fiecare dat cnd vrem s accesm coninutul. Acest lucru devine plictisitor i
repulsiv, i n acelai timp informaiile noastre confideniale sunt expuse la poteniale atacuri
de fiecare dat. Muli dintre noi refolosim acelai parole n mai multe locuri, crescnd astfel
riscul unui compromis neplcut. n aceast lucrare propun un mecanism Single Sign-On,
bazat pe certificate generate la solicitarea de ctre aplicaia client. Sistemele Single Sign-On
(SSO) permit ca utilizatorii s-i introduc datele personale doar o singur dat, i s
primeasc acces la multiple resurse n sistem [2].
Dezvoltarea rapid a internetului i faptul c acesta este accesibil unui numr foarte
mare de utilizatori a determinat un volum mare de date private aflat n circulaie punndu-se
astfel problema securitii datelor i a limitrii accesului la date. Securitatea informaiei
nseamn protejarea informaiilor i a sistemelor informatice mpotriva aciunilor neautorizate
n ceea ce privete accesul, folosirea, copierea, modificarea sau distrugerea datelor.
Transmisia de date dintre client i server se va realiza folosind canale de comunicaii
securizate, cu ajutorul protocoalelor de securitate i a criptografiei. Pentru a permite o
conectare rapid la multiple resurse, nu am folosit protocoalele complexe existente, ca SSL
[3], sau versiunea mai nou, TLS [4], ci am construit un set de protocoale noi, pe baza testelor
de autentificare descrise de Guttman [5], [6]. Aceste protocoale au fost implementate folosind
librriile de securitate OpenSSL [7], oferind performan i confidenialitate.
Pentru a pune n practic modelul propus, am dezvoltat un middleware care
implementeaz aceste protocoale de securitate i mecanismul single sign-on. Majoritatea
mecanismelor SSO existente pe care le-am analizat au un dezavantaj major: sunt
implementate s funcioneze doar pe o singur platform, cum ar fi Active Directory [8]
pentru Microsoft Windows, sau eDirectory [9] pentru sistemele Unix. Un alt dezavantaj
frecvent ntlnit este arhitectura centralizat, de exemplu LDAP [10], adic serverele de
6

autentificare trebuie s fie conectai la un server central pentru a autentifica utilizatorii.

Noutatea modelului propus de mine const n folosirea componentelor XPCOM [11], oferit de
platforma Mozilla pentru a ncapsula nivelul de transport. Astfel middleware-ul nu va fi
restricionat pe o singur platform i mecanismul single sign-on va fi disponibil pe orice
platform care suport Mozilla. Pentru a nu depinde de un server central la autentificare, vom
implementa componenta n fiecare server din reea, adugarea crora se va putea face cu
uurin n caz de nevoie. Clienii se vor putea deplasa liber la aceste servere, distribuind
sarcina produs de procesul de autentificare pe toate nodurile din reea.

1.1 Structura documentului

Primul capitol prezint cteva noiuni introductive referitoare la problema dat,

scopul lucrrii i setul de cerine.
Capitolul 2 prezint cteva noiuni despre criptografie, tipurile acestei, diferenele
dintre cea simetric i asimetric, i folosirea acestora. Se continu cu descrierea
protocoalelor de securitate, principii de proiectare, testele de autentificare i independena
protocoalelor. Urmeaz o prezentare a infrastructurii cheilor publice, i descrierea
certificatelor X.509. Capitolul continu cu un subcapitol despre mecanismul Single Sign-On,
i principiile ingineriei programrii bazate pe componente. n ncheierea acestui capitol este o
prezentare general a platformei Mozilla, arhitectura acestei platforme i cteva noiuni
despre tehnologiile folosite i cum pot fi acestea utilizate n dezvoltarea de aplicaii.
Capitolul 3 este dedicat proiectrii sistemului i ncepe cu formularea cerinelor i
prezentarea arhitecturii generale a sistemului. Se identific componentele sistemului i se
prezint rolul acestora. Urmeaz proiectarea fiecrei componente cu ajutorul i sunt
prezentate interfeele acestora. Urmeaz proiectarea i verificarea protocoalelor de securitate.
Capitolul 4 conine implementarea sistemului i descriere fiecare component cu
ajutorul diagramelor de clase corespunztoare i a diagramelor de stare ale principalelor clase.
n final sunt prezentate i explicate msurri a performanei sistemului, i concluziile
referitoare la sistemul prezentat.

Capitolul 2 Aspecte teoretice

2.1 Criptografia

Criptografia reprezint o ramur a matematicii care se ocup cu securizarea

informaiei precum i cu autentificarea i restricionarea accesului ntr-un sistem informatic.
n realizarea acestora se utilizeaz att metode matematice (profitnd, de exemplu, de
dificultatea factorizrii numerelor foarte mari), ct i metode de criptarea cuantic.
Criptologia este considerat ca fiind cu adevrat o tiin de foarte puin timp. Aceasta
cuprinde att criptografia - scrierea secretizat - ct i criptanaliza. Criptarea se mparte n
doua mari categorii: criptarea simetric si cea asimetric.
nainte de epoca modern, criptografia se ocupa doar cu asigurarea confidenialitii
mesajelor (criptare) - conversia de mesaje dintr-o form comprehensibil ntr-una
incomprehensibil, i inversul acestui proces, pentru a face mesajul imposibil de neles
pentru cei care intercepteaz mesajul i nu au cunotine secrete adiionale (anume cheia
necesar pentru decriptarea mesajului). n ultimele decenii, domeniul s-a extins dincolo de
problemele de confidenialitate i include, printre altele, i tehnici de verificare a integritii
mesajului, autentificare a emitorului i receptorului, semntur electronic, calcule
securizate.
Criptografia, folosit intr-un protocol de securitate, dorete s asigure urmtoarele
deziderate fundamentale pentru securitatea informaiei: confidenialitate, integritatea datelor,
autenticitatea i ne-repudierea.

2.1.1 Criptografia simetric

Criptografia cu chei simetrice se refer la metode de criptare n care att

trimitorul ct i receptorul folosesc aceeai cheie (sau, mai rar, n care cheile sunt diferite,
dar ntr-o relaie ce la face uor calculabile una din cealalt). Acest tip de criptare a fost
singurul cunoscut publicului larg pn n 1976. Problema fundamental a utilizrii
criptografiei n reele este aceea a gsirii unor modaliti de distribuie sigur i periodic a
cheilor criptografice, fiind necesar ca acestea s fie schimbate ct mai des. Uzual, se folosete
un protocol de schimbare de chei ntre participani, sau criptografia cu chei publice. Fiindc
8

securitatea criptrii simetrice depinde mult de protecia cheii criptografice, administrarea

acestora este un factor esenial i se refer la:

generarea cheilor, adic mijloacele (pseudo)aleatoare de creare a succesiunii de

octei (bii) ai cheii

distribuia cheilor, adic modul n care se transmit i se fac cunoscute cheile

tuturor utilizatorilor cu drept de acces la informaiile criptate

memorarea cheilor, adic stocarea lor sigur pe un suport magnetic sau pe un

card, de obicei criptate sub o alt cheie de cifrare a cheilor, numit i cheie master.

Algoritmii de criptare cu chei simetrice (cele mai populare includ: Twofish, Serpent,
AES (Rijndael), Blowfish, CAST5, RC4, TDES, IDEA) se pot mpri n dou categorii: cifru
pe blocuri i cifru pe flux. Cel mai celebru cifru simetric pe blocuri, DES (Data Encryption
Standard) are deja peste 20 de ani. El este primul standard dedicat proteciei criptografice a
datelor de calculator. Progresele tehnologice au impus nlocuirea DES-ului care a devenit
vulnerabil. S-a demonstrat de curnd c, folosind o main paralel complex, se poate gsi,
ntr-un timp de aproximativ 60 de ore, o cheie de 56 de bii cu care a fost criptat un bloc de
text clar. Din acest motiv, n 2000, organizaia guvernamental american NIST (National
Institute of Standards and Technology) a selectat algoritmul Rijndael (AES) [12], dezvoltat de
doi criptografi belgieni, Joan Daemen i Vincent Rijmen, s fie noul standard n criptografie
simetric.

2.1.2 Criptografia asimetric

Criptografia asimetric, sau criptografie cu chei publice, este un tip de criptografie n

care utilizatorul are o pereche de chei, una public i una privat, dependente una de cealalt,
dar aproape imposibil de calculat una din ele dac se cunotea cealalt. Astfel, una dintre chei
se poate face public i stocat n domeniul public iar cealalt va fi cheia privat, cunoscut
numai de ctre posesor. Folosind cheia public se poate cripta un mesaj care nu va putea fi
decriptat dect cu cheia pereche, cea privat. O analogie foarte potrivit pentru proces este
folosirea cutiei potale. Oricine poate pune n cutia potal a cuiva un plic, dar la plic nu are
acces dect posesorul cheii de la cutia potal. Dac mesajul a fost criptat cu cheia privat, se
poate decripta de oricine cu cheia public. Acesta se numete semntur digital, pentru c se
cunoate destinatarul mesajului (avnd n posesie cheia secret pentru a genera mesajul), i se
poate dovedi c mesajul este nemodificat, precum arat i Fig. 1. O analogie pentru
9

semnturile digitale ar fi sigilarea unui plic folosind un sigiliu personal. Plicul poate fi deschis
de oricine, dar sigiliul personal este cel care verific autenticitatea plicului. Matematic, cele
dou chei sunt legate, ns practic nu se pot deriva una din cealalt. Avantajul evident const
n faptul c cheia secret este cunoscut doar de o singur entitate, i nu trebuie trimis
niciodat, fiind astfel aproape imposibil de atacat cu succes, n cazul n care este folosit
corect.

Fig. 1 Modul de funcionare a semnturii digitale

O problem pentru criptografia asimetric este dovedirea autenticitii cheii publice,

trebuie dovedit c nu a fost nlocuit de o a treia persoan maliioas. O abordare comun este
folosirea unei infrastructuri pentru chei publice ( PKI Public Key Infrastructure ), n
interiorul creia, una sau multe third-parties, cunoscute sub numele de autoriti de
certificare (CA Certification Autority), certific posesorul perechii de chei. O alt abordare,
folosit de PGP (Prety Good Privacy), un program care garanteaz securitate criptografic i
autentificare, este metoda web of trust pentru a asigura autenticitatea perechii de chei, o
metod descentralizat prin care orice utilizator, prin intermediul unui certificat de identitate,
poate garanta autenticitatea.

10

Criptosistemul RSA [13] este unul dintre cei mai cunoscui algoritmi criptografici cu
chei publice, i este de asemenea primul algoritm utilizat att pentru criptare, ct i pentru
semntura electronic. Algoritmul a fost dezvoltat n 1977 i publicat n 1978 de Ron Rivest,
Adi Shamir i Leonard Adleman la MIT i i trage numele de la iniialele numelor celor trei
autori. Algoritmul implic trei stri: generarea cheilor, criptarea i decriptarea [14]. n acest
moment, cea mai eficient metod de a realiza aceasta este descompunerea n factori primi a
lui n, iar acesta nseamn un nivel de dificultate similar cu problema factorizrii. Cel mai
mare numr factorizat vreodat avea 663 bii, iar cheile folosite de obicei au o lungime de
1024 sau 2048 bii, ceea ce demonstreaz sigurana acestui algoritm. Perechea de chei se
genereaz dup urmtorii pai:
1. Se genereaz dou numere prime, de preferat mari, p i q;
2. Se calculeaz

3. Se alege un ntreg aleator e, 1 < e < astfel nct cmmdc(e, ) = 1. Perechea

(n, e) este cheia public.
4. Folosind algoritmul lui Euclid extins, se calculeaz ntregul d, unicul cu
proprietatea c

constituie cheia secret.

n general, deoarece se bazeaz pe o operaie destul de costisitoare din punct de vedere

al timpului de calcul i al resurselor folosite, i anume exponenierea modulo n, viteza RSA
este mult mai mic dect a algoritmilor de criptare cu cheie secret [15]. De aceea, n
sistemele de comunicaie n timp real, n care viteza de criptare i decriptare este esenial
(cum ar fi, de exemplu, aplicaiile de streaming video sau audio securizate), se folosete un
sistem de criptare hibrid, adic RSA se folosete doar la nceputul comunicaiei, pentru a
transmite cheia secret de comunicaie, care ulterior este folosit ntr-un algoritm cu cheie
secret, cum ar fi 3DES sau AES.

2.1.3 Funcii hash

Se poate numi o funcie hash (message digest) orice procedur bine definit sau o
funcie matematic care convertete o cantitate mare de date (de dimensiuni variabile) ntr-un
alt set de date, de obicei mult mai redus ca dimensiune, i de lungime fix. Funcia este
ireversibil, iar aceleai date de intrare va avea ca rezultat aceleai date de ieire daca se
aplic aceeai funcie hash pe ele. Pentru hash-urile bune, coliziunile (dou texte clare diferite
11

care produc acelai hash) sunt extrem de dificil de gsit. Funciile hash sunt folosite n mai
multe domenii, de exemplu pentru a accelera cutrile n tabele, sau baze de date mari, ca
sume de control, coduri de corectoare de erori, sau n criptografie, componente n schemele de
semntur digital. Cele mai des folosite funcii hash in criptografie sunt MD5 (Message
Digest Algorithm 5) i SHA1 (Secure Hash Algorithm), cea din urm fiind mai sigur. Putei
vedea rezultatul celei dou funcii menionate aplicate pentru textul Hello World n Tabelul
1.
Tabel 1 Rezultatele funciilor hash MD5 i SHA1
MD5

2ef7bde608ce5404e97d5f042f95f89f1c232871

SHA1

ed076287532e86365e841e92bfc50d8c

2.2 Protocoale de securitate

Protocoalele de securitate sunt o secven de operaiuni ce folosesc transformri

criptografice i al cror principal scop este s asigure o serie de proprieti de securitate, cum
ar fi: autentificarea, integritatea, secretizarea, ne-repudierea. Proiectarea unui protocol corect
este dificil, pentru c nu se pot verifica cu uurin. Multe dintre protocoale de securitate
propuse s-au dovedit mai trziu a avea defecte, de exemplu protocolul cu cheie simetric
Needham-Schroeder a fost dovedit defect de ctre Burrows, Abadi i Needham, la 3 ani dup
publicare. n cazul descoperirii defectelor abia dup ce protocoalele au devenit utilizate pe
scar larg consecinele pot fi foarte grave, i acest fapt a determinat multe persoane s fie
sceptice referitor la protocoalele de securitate n general. Exist cteva tehnici de formale
pentru analiza i verificarea protocoalelor de securitate. Printre acestea se numr: BAN
Logic, NRL Analzyer, FDR, Spi calculus, metoda inductiv, teoria spaiilor Strand.
Corectitudinea protocoalelor poate fi verificat parial cu aceste metode.
O alt problem n ceea ce privete proiectarea i verificarea protocoalelor de
securitate este dificultatea de a specifica criteriile de corectitudine sau obiectivele
protocolului. Multe protocoale sunt proiectate greit pentru c proiectanii lor nu tiu exact ce
obiective vor s ating. Specificnd cerinele protocoalelor se clarific problema pe care
trebuie s o rezolve proiectanii i realizeaz o legtur ntre criteriile informale legate de
corectitudine i descrierea formal a protocolului. Totui nc nu exist o definire precis a
proprietilor necesare unui protocol, la fel cum nu exist o noiune exact a ceea ce nseamn
autentificarea.
12

Proiectarea protocoalelor de securitate este un proces repetat de proiectare i

verificare. Datorit anilor de cercetare n verificarea protocoalelor, analiza i verificarea a
devenit mult mai uoar, cu toate acestea procesul depinde de reguli i experiena
proiectantului. nc nu exist o metodologie de proiectare.

2.2.1 Principii de proiectare

Protocoalele de securitate, cum sunt cele folosite pentru autentificare, sunt predispuse
la greeli de proiectare de multe tipuri. De-a lungul timpului, au fost propuse multe
formalisme pentru a investiga i analiza protocoalele cu scopul de a vedea dac au defecte.
Dei uneori aceste formalisme s-au dovedit utile, acestea nu sugereaz reguli de proiectare, nu
sunt n mod direct utile pentru prevenirea defectelor.
n [16] sunt prezentate principiile proiectrii protocoalelor de securitate. Aceste
principii nu sunt necesare pentru a asigura corectitudinea, dar nu sunt nici suficiente. Ele sunt
utile pentru c folosirea lor simplific protocoalele i previne repetarea unor confuzii i greeli
deja descoperite i publicate. Principiile sunt formulate pentru a evita anumite aspecte ale
protocoalelor care sunt greu de analizat. Dac aceste aspecte sunt evitate, devine mai puin
necesar s se recurg la folosirea metodelor formale. Principiile sunt indicaii informale i
sunt utile independent de orice logic.
Un protocol este un set de reguli sau convenii care definesc un schimb de mesaje ntre
doi sau mai muli parteneri. Aceti parteneri sunt persoane, procese sau calculatoare, care vor
fi numii n continuare interlocutori. ntr-un protocol de securitate toate sau o parte din mesaje
sunt criptate n ntregime sau parial. n acest context criptarea i decriptarea sunt definite ca
fiind transformri dependente de cheie ale unor mesaje care pot fi inversate doar prin folosirea
unei chei stabilite. Aceste chei pentru criptare i decriptare sunt aceleai sau pot fi diferite n
funcie de algoritmul de criptare folosit.
n continuare sunt prezentate aceste principii pentru proiectarea protocoalelor de
securitate. Sunt prezentate dou principii de baz, primul fiind preocupat de coninutul
mesajului, iar al 2-lea este preocupat de circumstanele n care un mesaj se comport corect:
1. Fiecare mesaj ar trebui s specifice ce nseamn, ce conine, interpretarea lui ar
trebui s depind doar de coninutul su. Ar trebui s se poat scrie o propoziie care s
descrie coninutul mesajului.
2. Condiiile n care un mesaj se comport conform ateptrilor ar trebui specificate
clar pentru ca oricine modific un protocol s vad dac acestea sunt acceptabile sau nu.
13

Pentru o bun nelegere a primului principiu lum un exemplu: un server de

autentificare S trimite un mesaj a crui sens poate fi exprimat astfel: Dup recepionarea
unei secvene de bii P, S trimite lui A o cheie de sesiune K pentru a fi folosit n conversaia
cu B. Toate elementele trebuie reprezentate n mesaj pentru ca nelesul su s poat fi
refcut de destinatar fr a fi nevoie de informaii din context. Pentru exemplu dat, dac P, S,
A, B sau K sunt omise din mesaj i se dorete obinerea lor din context, exist posibilitatea ca
un mesaj s poat fi folosit n locul altui mesaj, cu scopul de a nela.
Principiul doi menioneaz c nu este suficient ca mesajul s fie neles pentru a se
comporta corect, trebuie s ndeplineasc o varietate de alte condiii. Aceste condiii de cele
mai multe ori constau n ce poate fi privit informal ca o declaraie de ncredere. Declaraiile de
ncredere nu pot fi greit concepute, doar pot fi luate n considerare nepotrivit. De exemplu,
dac cineva consider c alegerea cheilor de sesiune ar trebui fcut de un server de ncredere
i nu de un participant la sesiune, atunci el nu va dori s foloseasc un protocol cum este
Wide-mouthed-frog (protocol care distribuie o cheie de sesiune generata de unul din
interlocutori prin intermediul unui server ).
Pornind de la aceste doua principii au fost formulate alte principii mai specifice.
Principiul 3 este un caz particular al principiului 1: dac identitatea unui interlocutor
este eseniala pentru sensul mesajului, este prudent s se menioneze numele su explicit n
mesaj. Numele relevante pentru un mesaj pot fi uneori deduse din alte date i din ce cheie de
criptare s-a folosit. Cnd aceast informaie nu poate fi dedus, omiterea ei din mesaj poate
avea consecine grave.
n continuare sunt prezentate notaiile folosite n exprimarea celorlalte protocoale:
K cheia de criptare public n criptarea asimetric, i cheia de criptare/decriptare n criptarea
simetric
K 1 - cheia privat n criptarea asimetric
A, B, C, S interlocutori ( S fiind serverul )

{X }K

- mesajul X este criptat cu cheia K i oricine cunoate inversa lui K (este K n criptarea

simetric i K 1 n cea asimetric) poate decripta mesajul, iar dac K este secret putem vedea

{X }K

ca un mesaj semnat digital.

Criptarea poate fi folosit pentru diferite scopuri:

pentru asigurarea confidenialitii. n acest caz cnd un interlocutor cunoate K 1

i vede {X }K tie c acest mesaj este pentru cineva care cunoate K 1 ; i poate va
deduce c i este adresat cu ajutorul informaiilor adiionale din mesaj.
14

este uneori folosit pentru garantarea autenticitii. n acest caz este de presupus c
doar emitorul corect cunoate cheia secret pentru a cripta mesajul. Criptarea
contribuie clar la sensul general al mesajului.

contribuie la unirea prilor de mesaje: recepionarea {X , Y }K nu este ntotdeauna

acelai lucru cu recepionarea {X }K i {Y }K . Dac criptarea este folosit doar
pentru unirea prilor de mesaje este suficient semntura digitala. Modul de unire
a mesajelor este dependent de protocol i este de multe ori subtil.

generarea de numere aleatoare cu ajutorul funciilor one-way.

Principiul 4 este legat de folosirea criptrii: trebuie s se specifice clar de ce se

folosete criptarea. Criptarea nu este sinonim cu securitatea, i folosirea ei improprie poate
conduce la erori. Criptarea nu este ieftin, i dac nu se tie de ce este folosit poate conduce
la redundan.
Principiul 5 este legat de semnarea datelor criptate: cnd un interlocutor semneaz un
material care a fost deja criptat nu trebuie presupus c acesta cunoate coninutul mesajului.
Pe de alt parte, este corect s presupui c interlocutorul care semneaz un mesaj i apoi l
cripteaz pentru secretizare cunoate coninutul mesajului.
O parte important n sensul mesajului este format din informaiile temporale. O
precondiie comun pentru a prelucra un mesaj este c exist un motiv care te face s crezi c
mesajul este recent, i nu un rspuns al unui mesaj mai vechi. Aceast noutate a mesajului
trebuie s fie indus de o component a mesajului. Aceast component trebuie s fie legat
de restul mesajului pentru a nu putea fi ataat unui mesaj mai vechi.
Principiul 6: Scopul folosirii nonce-urilor (numr generat aleatoriu) trebuie bine
precizat, fie pentru asociere, fie pentru succesiunea temporal. Ceea ce poate asigura
succesiunea temporal poate afecta asigurarea asocierii, i poate asocierea este mai bine
stabilit prin alte mijloace.
Principiul 7: valorile (nonce-urile) predictibile (cum este valoarea unui contor) pot fi
folosite pentru garantarea noutii n cadrul unui protocol ntrebare-rspuns (challengeresponse), dar pentru ca aceast cantitate predictibil s fie eficient trebuie protejat pentru
ca un intrus s nu poat simula o ntrebare i mai trziu s trimit un rspuns.
Principiul 8: Dac timestamps (marca de timp) sunt folosite pentru a garanta noutatea
prin referire la timpul absolut, atunci diferena dintre ora local a diferitelor maini trebuie s
fie mult mai mic dect durata de via permis a unui mesaj pentru a fi considerat valid.

15

Principiul 9: o cheie se poate s fi fost folosit recent, pentru criptarea unui nonce de
exemplu, i totui s fie destul de veche i posibil compromis. Folosirea recent nu face ca
cheia s par mai sigur dect nefolosirea ei recent.
Principiul 10: dac o codare este folosit pentru a prezenta sensul unui mesaj, atunci ar
trebui s fie posibil s spui ce codare este folosit. n cazurile comune unde codarea este
dependent de protocol, ar trebui s fie posibil s se deduc c mesajul aparine acelui
protocol, i mai exact aparine unei rulri particulare a protocolului, i s se afle numrul
mesajului n acest protocol.
Principiul 11: proiectantul protocolului ar trebui s tie care sunt relaiile de ncredere
de care depinde protocolul su i de ce sunt necesare aceste dependene. Motivele pentru care
o relaie particular de ncredere s fie acceptabil ar trebui explicit bazate pe judecat i
politici dect pe logic.

2.2.2 Proiectare via teste de autentificare

Proiectarea protocoalelor de securitate, descris n [17] urmrete urmtoarele

obiective, ntre doi participani P i Q:
Confidenialitate: se definete ca fiind protecia datelor trimise n fata persoanelor
neautorizate
Autenticitatea I: dou entiti aflate ntr-un schimb de mesaje s se poat identifica
una pe cealalt. n prima faz, la iniierea conexiunii, acest serviciu asigur ca cele dou
entiti sunt autentice. n al doilea rnd, autenticitatea presupune ca transferul de date ntre
cele dou entiti s nu fie interferat astfel nct o a treia entitate s se legitimeze ca fiind una
din ele. Fiecare participant P trebuie s aib garanie c fiecare partener Q a primit i a
acceptat datele lui P.
Non-repudierea: previne situaia n care o entitate refuza s recunoasc aciuni
anterioare. Cnd un mesaj este trimis, destinatarul poate demonstra ca mesajul primit este cel
trimis de emitor. Fiecare participant P trebuie s-i dovedeasc autenticitatea I, garantat de o
ter parte.
Autenticitatea II: Fiecare participant Q trebuie s aib garanie ca un mesaj avnd ca
expeditor P, a fost creat ntr-adevr de partenerul P, ntr-o rulare recent a acestui protocol.

S presupunem o entitate ntr-un protocol criptografic ca fiind creatorul i

transmitorul unui mesaj care conine o valoare nou v, iar mai trziu primind un mesaj
16

coninnd valoarea v, dar ntr-un alt context criptografic. De aici poate conclude c o alt
entitate, avnd n posesie cheia relevant K a recepionat i a transformat mesajul care
coninea valoarea v. Dac cheia K este secret, aceast entitate nu poate fi penetratorul, deci
trebuie s fie un participant reglementar. Testele de autentificare [19] ofer suficiente condiii
ca s putem dovedi c aceste schimbri a formei criptografice sunt aciunile unui participant
regular. Putem deosebi dou tipuri de teste de autentificare:
Teste de ieire: o valoare unic a poate fi transmis numai n form criptat
{|a|}K , unde cheia K-1 este secret. Dac mai trziu un mesaj primit
conine valoarea a n afara contextului {|a|}K , nseamn c un participant
regular a fost responsabil de transformarea {|a|}K  a . Este un test
de ieire pentru c elementul criptat ias.
Teste de intrare: dac, n schimb, a este primit ntr-o form criptat {|a|}K
dar nu a fost trimis n acest context, i cheia K este secret, atunci putem
afirma din nou c transformarea nu a fost efectuat de un penetrator. Testul
care conine transformarea a  {|a|}K este o un test de intrare pentru
c elementul criptat intr.
Dac o valoare unic a este transmisa intr-o form criptat {|h|}K, i primit
napoi ntr-o alt form criptat {|h|}K , iar cheile K-1 i K sunt secrete,
atunci este un test i de intrare, i i de ieire.

2.2.3 Independena protocoalelor de securitate

Dac este de ateptat ca dou sau mai multe protocoale de securitate s ruleze n
paralel trebuie s se determine dac un protocol afecteaz securitatea celorlalte protocoale.
Acest lucru se realizeaz analiznd independena protocoalelor implicate. Cnd mai multe
protocoale de securitate ruleaz combinate pentru intruii apar noi oportuniti pentru a obine
mesajele. Aceast combinare de protocoale s-a dovedit o cauz semnificativ a eurii
protocoalelor i face mult mai dificil analiza protocoalelor. A fost dovedit o problem n
aplicarea metodelor formale protocoalelor de securitate.
Un protocol, numit protocol primar, este independent de alte protocoale, numite
protocoale secundare, dac protocolul primar i ndeplinete scopul de securitate fr a
depinde dac un protocol secundar ruleaz n acelai timp (1). Pentru dovedirea independenei
protocoalelor au fost folosite spaiile strand. Un strand este o secven de mesaje transmise i
17

recepionate. Protocoalele de securitate sunt modelate cu ajutorul acestor spaii strand. n [20]
este propus reprezentarea protocoalelor de securitate folosind un model canonic care
permite realizarea unei analize sintactice pentru determinarea independenei protocoalelor.
Construirea mesajelor dup modelul propus este realizat prin nlocuirea fiecrei componente
a mesajului din specificarea obinuit cu un tip. n modelul canonic propus, mesajele
schimbate de participani sunt reprezentate sub forma unor construcii sintactice, evideniind
structura mesajelor care influeneaz direct independena protocoalelor. Bazndu-se pe
cunotinele fiecrui participant se modeleaz viziunea fiecrui participant asupra aceluiai
mesaj. Primul pas este mbuntirea specificaiilor obinuite folosind cunotinele
participanilor pentru a se observa clar care sunt componentele mesajului care pot fi validate
de participani. Pornind de la aceast reprezentare este construit un model canonic, numit
model de tipuri, care nlocuiete componentele mesajelor cu tipul lor corespunztor,
reprezentndu-se astfel explicit structura mesajului. Aceast reprezentare permite realizarea
analizei sintactice pentru determinarea independenei protocoalelor.
Tipurile componentelor mesajelor sunt:

Kt : cheie

r: rol

n: nonce

i: index, de exemplu o secven de numere sau o marc de timp

u: tip necunoscut

mt : numele protocolului de securitate

2.3 Infrastructura Cheilor Publice (PKI)

Infrastructurile cu chei publice (Public Key Infrastructure / PKI) nu este o tehnologie

relativ nou, ea se bazeaz pe criptografia asimetric i ofer diverse servicii n ncercarea de
a rezolva diverse probleme de securitate. PKI este o combinaie de produse hardware i
software, politici i proceduri care asigur securitatea de baz necesar astfel nct doi
utilizatori, care nu se cunosc sau se afl n puncte diferite de pe glob, s poat comunica n
siguran. La baza PKI se afl certificatele digitale, un fel de paapoarte electronice ce
mapeaz semntura digital a utilizatorului la cheia public a acestuia. O infrastructur cu
chei publice reprezint cadrul i serviciile ce pun la dispoziia utilizatorului metode pentru a
genera, distribui, controla, contoriza i revoca certificate cu chei publice. O structur PKI se
18

constituie, de obicei, din una sau mai multe autoriti de certificare (CA), un container cu
certificate, i documentaia ce include politica de certificare. ntr-un sens mai larg, se poate
spune c PKI integreaz certificatele digitale, criptografia cu cheie public i noiunea de
autoritate de certificare ntr-o arhitectur de securitate a reelei.

2.3.1 Certificatele X.509

Certificatele identific persoana specificat n certificat i asociaz acelei persoane o

anumit pereche de chei public/privat. Certificatul X.509 [21] a fost folosit prima dat n
1988, i este un standard ITU-T (International Telecommunication Union) pentru
Infrastructura Cheilor Publice (Public Key Infrastructure / PKI). Certificatele de obicei sunt
emise de autoriti de certificate (certificate authorities / CA), i conin urmtoarele
informaii: versiunea certificatului, un numr de serie, identificator de algoritm, numele
emitentului, perioada de valabilitate a certificatului, numele posesorului, algoritmul cheii
publice, cheia public i cteva cmpuri opionale. n afar de aceste informaii predefinite,
certificatele X.509 v3 suport i date personalizate, unde voi stoca drepturile de acces pentru
fiecare utilizator separat. Certificatele sunt relativ uor de generat, iar datorit dimensiunii
mici, i fiind stocate in format .PEM (Privacy Enhanced Mail), codificat BASE64, transmisia
lor se realizeaz fr probleme. Un dezavantaj constituie faptul c suport un singur algoritm
de criptare la un moment dat.
Un exemplu de certificat X.509 v3, emis de ctre Thawte, pentru Google Mail se poate
vedea n Fig. 2.

19

Fig. 2 Certificat X.509

2.4 Mecanismul Single Sign-On (SSO)

Utilizatorii de reea folosesc un set de informaii pentru identificare, de obicei numele

de utilizator i parola, pentru fiecare furnizor de servicii (Service Provider / SP) la care sunt
nregistrai. n cadrul acestei lucrri, un furnizor de servicii este o entitate care ofer anumite
resurse sau informaii utilizatorilor, de exemplu servicii de web, servicii de mesaje, site-uri
web/FTP sau orice fel de format de flux. Numrul acestor furnizori de servicii a crescut
enorm, i a ajuns la un punct unde utilizatorii rein cu greu informaiile necesare pentru
identificare. Cea mai simpl i rspndit soluie este de a folosi aceeai parol la fiecare
furnizor la care sunt nregistrai un compromis ntre securitate i uurina de folosire. O
soluie la aceast problem de securitate ar fi implementarea unui mecanism Single Sign-On
(SSO). SSO este o proprietate de control de acces a sistemelor software multiple, legate, dar
independente. Cu aceast proprietate, utilizatorul se autentific doar o singur dat, iar
identificarea se face de ctre sistem, de cte ori va fi nevoie, la fiecare furnizor din reea.
Aceast autentificare este automat, nu necesit intervenia utilizatorului [22]. Beneficiile
unui sistem SSO includ:

Scade numrul parolelor folosite, mbuntind semnificativ securitatea sistemelor

Se reduce din timpul folosit reintroducnd parole pentru aceeai identitate

Securitate la toate nivelele de intrare/ieire/accesare a sistemelor

20

Exist mai multe modaliti de a crea un sistem SSO, de exemplu: protocolul de

autentificare Kerberos interogheaz utilizatorul pentru datele de identificare, i emite un tichet
(Ticket granting gicket / TGT), care va fi folosit pentru autentificare n continuare. Cteva
dezavantaje a acestui sistem includ arhitectura centralizat, care const in serverul principal
care trebuie s fie funcional pentru a permite autentificarea utilizatorilor. Acest server central
stocheaz datele tuturor utilizatorilor, fiind astfel inta eventualelor atacuri la adresa
sistemului. Kerberos necesit sincronizarea ceasurilor pe diferite servere, tichetele emise de
server au o perioad de valabilitate, de obicei 10 minute, iar dac ceasul furnizorului nu este
sincronizat cu cel al serverului care a emis tichetul, autentificarea eueaz. Un alt sistem SSO
folosete smart-carduri pentru a stoca informaii despre posesor, i pentru autentificarea
utilizatorilor. Acest card, fabricat de obicei din plastic, conine un circuit integrat, capabil de a
prelucra anumite date. Smart cardurile sunt rspndite, i foarte utile n anumite domenii, dar
necesitatea acestui hardware l face greu de utilizat n cazul nostru. nc cteva sisteme SSO
de menionat ar fi cel bazat pe parole de unic folosin (One-time passwords / OTP) sau
Integrated Windows Authentication (IWA), introdus cu Windows 2000. Pentru modelul meu
am ales s folosesc autentificarea pe baza certificatelor client X.509, descris n seciunea
2.3.1.

2.5 Ingineria programrii bazat pe componente (CBSE)

Componentele software sunt uniti binare produse, dezvoltate i achiziionate

independent care interacioneaz pentru a forma un sistem funcional [23]. Este esenial s fie
dezvoltate independent i sub form binar pentru a permite integrarea lor ntr-un produs
indiferent de identitatea productorilor i pentru a putea fi integrate robust n sistem.
Construirea unor aplicaii noi prin combinarea componentelor achiziionate din exterior i a
celor dezvoltate n interior mbuntete calitatea produsului i scurteaz perioada de
dezvoltare, produsul ajungnd pe pia mult mai repede. n acelai timp adaptarea aplicaiei la
noi cerine poate fi fcut doar asupra componentelor care necesit acest lucru fr a fi nevoie
s se lanseze o noua versiune a aplicaiei.

21

2.5.1 Application Programming Interface (API)

O interfa API este un set de funcii, structuri de date, clase de obiecte i/sau
protocoale accesibile din librrii, sau oferite de serviciile sistemului de operare, pentru a
suporta crearea aplicaiilor. Un program care ofer funcionalitatea descris de interfaa API
este implementarea interfeei API. Interfaa API n sine este abstract, n sensul c specific
instana dar nu se implic n detalii de implementare. Un API poate fi dependent de un limbaj,
dar i independent, adic poate fi folosit din mai multe limbaje de programare. Standardul
POSIX (Portable Operating System Interface for Unix) definete un API care permite scrierea
unor game mari de funcii de baz n aa fel nct s fie compatibile cu mai multe sisteme de
operare. Cteva API-uri populare includ: ASPI pentru interfaa SCSI, DirectX pentru
Microsoft Windows, OpenGL cross-platform 3D, Carbon i Cocoa pentru Macintosh, etc.
Cteva principii de baz n proiectarea unui API: [24] s fac un singur lucru, dar s-l
fac bine funcionalitatea s fie uor de explicat. S fie ct se poate de mic, dar s-i
satisfac cerinele poi s adugi mai trziu, dar e mai greu s scoi. Implementarea nu ar
trebui s influeneze API-ul. Un aspect important, i un scop important al fiecrui API este s
ascund informaiile irelevante, clasele i membrii ar trebui s fie privai, ct posibil. Numele
membrilor publici s fie sugestive, dar API-ul s aib o documentaie detaliat. n general s
fie uor de nvat, uor de folosit chiar i fr documentaie, greu de folosit incorect.

2.6 Platforma Mozilla

Mozilla este o platform portabil, gratuit, open-source creat n totalitate cu ajutorul

componentelor software. Mozilla a luat natere n 1998 prin decizia companiei Netscape de a
publica sursele browserului Netscape i declararea lor ca open-source permind contribuia
programatorilor din toat lumea pentru a mbuntii browserul. Cu timpul platforma Mozilla
a devenit dintr-o aplicaie browser foarte mare, o platform mare portabil pe care un set de
aplicaii mai mici sunt construite i ruleaz. Ea ofer fundaia pe care programatorii pot s
dezvolte uor aplicaii de nivel nalt fr a mai irosi timp preios implementnd funcionaliti
de baz, oferite acum de platform.
Cel mai important avantaj al aplicaiilor dezvoltate pe platforma Mozilla este
portabilitatea pe majoritatea sistemelor de operare, programele vor avea aceeai structur
indiferent dac vor rula pe Windows, Unix sau Mac. Acest lucru e posibil pentru c Mozilla
se comport ca un nivel de interpretare ntre aplicaie si sistem de operare. Portabilitatea este
22

realizat cu ajutorul XPFE (Extreme Portability Front End ), o tehnologie dezvoltat pentru a
economisi timp datorit dezvoltrii open-source i care s-a dovedit o inovaie.
XPFE folosete o serie de standarde web existente cum ar fi Cascading Style Sheets
(CSS) (un limbaj cu ajutorul cruia se creeaz aspectul grafic al aplicaiei), XUL (un dialect al
limbajului XML utilizat pentru descrierea interfeelor grafice), JavaScript (un limbaj pentru
script-uri cu o sintax asemntoare cu cea a limbajului C), RDF (un dialect al XML utilizat
pentru salvarea datelor) i XPCOM (un sistem pentru descoperirea i administrarea obiectelor
care permite JavaScript sau oricrui limbaj pentru script-uri s acceseze librriile C i C++ ).
Dezvoltarea de aplicaii se realizeaz folosind aceste tehnologii combinate cu limbaje de
programare cum ar fi C, C++, Python i Interface Definition Language ( IDL ).

2.6.1 Arhitectura Mozilla

n Fig. 3 este prezentat arhitectura simplificat a platformei Mozilla. Se observ o

aezare pe nivele semi-independente. Legtura dintre sistemul de operare i platform se
realizeaz la nivelurile inferioare prin intermediul unei interfee, accesul la serviciile oferite
de acesta fcndu-se n trei moduri: printr-un API (Application Programming Interface)
portabil numit NSPR (Netscape Portable Runtime), prin cod Java interpretat de JVM (Java
Virtual Machine) sau prin implementarea unor plugin-uri. Pentru o flexibilitate i o deschidere
mai mare a sistemului funcionalitatea nivelelor inferioare este nglobat n mai multe
componente independente, administrarea lor fiind realizat de un sistem de mediere portabil
numit XPCOM (Cross Platform Component Object Model). Componente XPCOM pot fi
dezvoltate n C, C++, JavaScript, Python sau alte limbaje pentru care exista legturi speciale
create. Portabilitatea tehnologiilor folosite n aceste nivele inferioare conduce la o
portabilitate crescut a ntregii platforme i implicit a tuturor aplicaiilor dezvoltate pe ea. n
momentul de fa Mozilla este disponibil pe principalele trei sisteme de operare existente pe
pia: Microsoft Windows, Linux i Mac OS.
Aplicaiile care vor sa obin acces la componentele XPCOM folosesc tehnologia
XPConnect care asigur accesul limbajelor pentru script-uri (cum este JavaScript) la
interfeele componentelor de la nivelele inferioare. Legtura funcioneaz i n sens invers
permind interaciunea unor obiecte implementate n JavaScript cu alte obiecte implementate
de obicei n limbaje de programare clasice cum ar fi C sau C++.
Platforma Mozilla, pentru a oferii portabilitate, descrie interfeele componentelor
utiliznd un limbaj independent de platform numit XPIDL (Cross Platform Interface
23

Definition Language, o variant a limbajului IDL utilizat de sistemul de administrare a

obiectelor CORBA). Deasemenea se pot accesa servicii cum este NSS ( Netscape Secure
Services ) un serviciu de securitate care printre alte facilitai ofer posibilatea de utilizare a
certificatelor digitale.
Pentru a obine acces la interfaa componentelor se folosete JavaScript care utilizeaz
tehnologia XPConnect, menionat anterior. Interfaa cu utilizatorul este implementat sub
forma unor documente scrise n XUL (limbajul derivat din XML specific platformei) sau mult
mai cunoscutul limbaj HTML, acestea se pot combina cu CSS ( Cascade Sheet Style),
eXtensible Binding Language (XBL), DTD ( Document Type Definition ) pentru a oferi un
caracter internaional.
Platforma pune la dispoziia programatorilor un format portabil pentru salvarea datelor
numit RDF ( Resource Description Framework ) care este o particularizare a limbajului XML.

Fig. 3 Arhitectura simplificat a platformei Mozilla

2.6.2 XPCOM

XPCOM (Cross Platform Component Object Model) reprezint principala inovaie

oferit de platforma Mozilla. Aceasta este principalul motiv pentru care Mozilla este cu
adevrat o platforma de dezvoltare. XPCOM este tehnologia prin care platforma Mozilla i
24

administreaz propriile componente sau pe cele implementate de alte aplicaii, deasemenea se

ocupa de regsirea i instanierea n timpul rulrii a diverselor componente.
Flexibilitatea ridicat a platformei a fost obinut prin organizarea codului sub forma
componentelor XPCOM independente accesibile printr-un set de interfee pe care le
implementeaz. Aceast abordare faciliteaz adugarea de funcionaliti noi la momente
ulterioare cu eforturi i costuri minime cu condiia ca toate componentele s implementeze un
set de interfee standard care s poat face posibil comunicarea dintre ele.
Att componentele ct i interfeele sunt identificate printr-un UUID (Universally
Unique Identifier, un numr pe 128 de bii) sau printr-un identificator specific platformei
numit

ContractID, o secven de caractere ntr-o form uor de reinut de utilizatori.

Majoritatea componentelor XPCOM sunt scrise n C sau C++ cu NSPR la baz, dar dac
interfeele lor utilizeaz exclusiv tipuri de date definite de XPIDL ele pot fi accesate uor de
limbaje ca JavaScript prin intermediul tehnologiei XPConnect. JavaScript este de obicei
limbajul care asigur legtura dintre interfaa cu utilizatorul i componentele de la baza
platformei.

25

Capitolul 3 Proiectarea sistemului

3.1 Cerine

Se consider un sistem format din servere (Service Provider / SP) care gzduiesc
diferite servicii n mod request-response (cerere-rspuns). Pentru a avea acces la resursele
disponibile pe aceste servere, clienii trebuie s se autentifice. n Fig. 4 este prezentat
arhitectura unui astfel de sistem. Fiecare dintre servere gzduiete un serviciu de autentificare,
nu se bazeaz pe un punct central fix de autentificare.

Fig. 4 Arhitectura sistemului

Autentificarea clienilor va fi asigurat de un mecanism Single Sign-On, care se va

ocupa de identificarea clienilor fr a-i interoga la fiecare conectare pentru informaiile
personale. Pentru acesta se va folosi de certificatele generate la comand de oricare dintre
serverele din reea. Reeaua poate fi public, deci informaiile trebuie protejate. Pentru acesta
toate comunicaiile i datele vor fi criptate, i coordonate de protocoale de securitate sigure.
Componentele trebuie s fie compatibile cu mai multe platforme, i aceste
componente vor fi distribuite intr-un API. Acesta pune la dispoziie o interfa simpl care
permite crearea unui astfel de sistem propus cu uurin, permind dezvoltatorului s se
concentreze pe celelalte aspecte ale proiectului.
26

3.2 Arhitectura sistemului

3.2.1 Proiectarea mecanismului Single Sign-on

Single Sign-on este o proprietate de control de acces a sistemelor software multiple,

legate, dar independente. Cu aceast proprietate, utilizatorul se autentific doar o singur dat,
iar identificarea se face de ctre sistem, de cte ori va fi nevoie, la fiecare furnizor din reea.
Aa cum s-a mai menionat, sistemul propus va fi alctuit din noduri, independente unul de
altul, dar fiecare tie de cellalt. Aceste noduri care n cazul nostru vor fi servere, i mai
concret modulul XServer, vor gzdui dou tipuri de servicii: unul pentru autentificarea ,
controlul accesului i autorizarea clienilor, i unul pentru distribuirea resurselor. Fiecare
server are capabilitatea de a efectua aceste procese, nu depind de un alt nod central, astfel
adugarea nodurilor noi se face fr probleme.
Clienii sunt nregistrai la unul dintre aceste servere, fiecare client are un home server.
Acest home server se difereniaz de celelalte, doar din punctul de vedere al acelui client, care
este nregistrat la el, i doar din punctul de vedere al autentificrii, restul facilitilor sunt
disponibile n aceeai msur. Altfel spus, fiecare server este un home server pentru toi
clienii nregistrai la el. nregistrarea se poate face n orice mod, fie prin e-mail, o pagin
web, manual de ctre administratorul serverului, important e ca dup nregistrare clientul s
aib acreditri, de orice tip (de obicei numele de utilizator i parola) stocate i protejate de
server. Aceste informaii personale vor fi pstrate secrete, oricine poate lua rolul unui client
dac are n posesie aceste date.
Un server poate s furnizeze resurse clienilor, fie acestea fiiere locale, de orice tip,
fie date de flux. n cadrul lucrrii o s numim aceste servere, servere de resurse, resource
server, sau service provider (SP). Toate datele trimise ctre i de serviciul de resurse vor fi
criptate, cu chei generate la autentificare, explicat n urmtoarele paragrafe. Dac un server nu
ruleaz serviciul de resurse, atunci va avea rolul doar de a autentifica utilizatori, i de a trimite
lista cu celelalte servere la cererea acestora. Serverele nu sunt limitate doar la aceste dou
servicii, ci se pot implementa numeroase i diferite tipuri de servicii, de exemplu serviciu de
nume, webmail, FTP, etc. Un model al unui sistem descris se poate vedea n Fig. 4, unde 3
clieni sunt conectai la mai multe servere de resurse ale reelei.
Pentru a se folosi de serviciile serverelor de resurse, un utilizator trebuie s fie
autentificat i s aib drepturi de acces suficiente pentru aceast aciune. Autentificarea este
27

un proces prin care o entitate verific dac o alt entitate este cine sau ce pretinde a fi. Aceast
entitate poate fi un utilizator, un cod executabil sau un calculator. Verificarea identitii unui
proces de la distan este dificil i necesit protocoale complexe de securitate bazate pe
criptografie. Autentificarea n modelul meu se face pe baza numelui de utilizator i parol.
Clientul se va conecta la home serverul lui, adic unde a fost nregistrat, iar serverul verific
dac este salvat vreun utilizator cu acel nume la el. Dac numele clientului se regsete n
baza de date la server, se ncepe protocolul de autentificare care va asigura transmiterea
datelor clientului n siguran. (pasul 1 din Fig. 5) Protocolul se folosete de infrastructura
cheilor publice, i va cripta mesajul clientului cu cheia public a serverului. Dac vreun client
nu are cheia public a unui server la care vrea s se conecteze, sau certificatul nu este valid,
nainte de conectare va cere certificatul clientului de la serverul respectiv, care conine cheia
public.

Fig. 5 Paii de execuie pentru mecanismul Single Sign-on

Dup recepionarea datelor personale de la client, home serverul va verifica dac

numele de utilizator i parola furnizat se potrivesc cu cele din baza de date, ceea ce se poate
28

vedea n Fig. 5, pasul 2. Aceste informaii secrete a clientului vor fi trimise doar o singur
dat , asta fiind important nu numai din punctul de vedere al confortului, ci i al securitii.
Dup autentificare, serverul va genera perechea de chei RSA i certificatul clientului. Aceste
certificate vor fi folosite de acum ncolo pentru autorizare n sistem, deci trebuie s fie create
i folosite n aa fel nct s asigure un nivel securitate ridicat. Acest certificat va conine
cteva informaii despre utilizator (numele, locaia, organizaia, adresa e-mail, etc), despre
certificat (algoritmul de criptare, rezultate hash, data expirrii), dar i date despre emitent,
pentru verificarea autenticitii. Certificatul este semnat digital cu cheia secret a serverului,
protejnd-ul astfel de orice modificare a coninutului acestuia. Certificatele folosite de mine,
X.509v3, permit adugarea unor extensii la setul de cmpuri predefinite, unde se pot nscrie
comentarii sau date alese de utilizator. Aceste cmpuri vor conine permisiunile clienilor care
vor servi la controlul accesului n reea, dup un model bazat pe roluri (role-based access
control / RBAC). Controlul accesului se refer la acordarea sau refuzul de privilegii la o
entitate dup autentificare. Un privilegiu este un drept pe care l are un utilizator. Unele
operaii sunt considerate privilegiate i trebuie atribuite doar persoanelor de ncredere.
Utilizatorilor nu se vor atribui direct permisiunile, ci acetia le vor dobndi prin rolurile pe
care le iau n cadrul reelei. Astfel gestionarea permisiunilor utilizatorilor, sau adugarea
permisiunilor utilizatorilor noi se face uor. Rolurile sunt salvate n aceeai baz de date ca i
numele de utilizator i parola. n pasul 3, Certificatul i cheia secret vor fi trimise clientului
via canale securizate. Clientul are n posesie un certificat valid, care poate fi folosit ca un
paaport pentru a se mica liber i a primi acces la oricare dintre servere din reea unde are
permisiune. Certificatul i cheia secret vor fi salvate pentru alte di, avnd o valabilitate
ndelungat, atta timp ct acesta nu a expirat, poate fi folosit pentru a se conecta la alte
servere. Dac a expirat, se contacteaz home serverul, i se repet paii 1-3.
Pasul 4 din Fig. 5 reprezint conectarea la unul dintre serverele de resurse, folosind
certificatul generat anterior. Serverul verific certificatul, adic numele s fie identic cu cel al
clientului, s nu fie expirat, s fie emis de un server cunoscut din reea i semntura digital a
emitentului. Pentru verificarea semnturii se folosete cheia public a serverului care a
generat certificatul. De regul fiecare server are o copie dup certificatele ale celorlalte
servere din reea, dar n caz contrar se poate face rost de el cu uurin, cunoscnd adresa
serverului (pasul 5). Dac verificarea a fost efectuat cu succes, i clientul are drepturi de
acces la acel server, se va genera o cheie secret. Aceast cheie se va folosi pentru criptarea
datelor att de la client la server ct i vice-versa. Cheia va fi folosit de algoritmul de criptare
simetric, AES, i este valid doar pentru sesiunea curent. Dac cheia a expirat, clientul va
29

trimite nc odat certificatul pentru a solicita o alt cheie. Durata de via scurt a cheilor
asigur o protecie ridicat mpotriva atentatelor asupra reelei. Cererile ctre serviciul de
resurse i datele trimise ca rspuns de ctre server vor fi criptate cu aceast cheie.

3.2.2 Componentele sistemului

n Fig. 6 este prezentat arhitectura propusa a sistemului pentru care s-au formulat
cerinele. Sunt prezentate componentele din care este format i legturile dintre acestea.

Fig. 6 Componentele sistemului

Sistemul este format din urmtoarele componente:

XServer: gzduiete diferite servicii, cu diverse funcionaliti. Numrul

acestor servicii nu este limitat, dar n modelul meu folosesc doar un serviciu de
autentificare i unul de resurse. Serviciul de autentificare este responsabil de
identificarea clienilor, prin conectarea la baza de date, generarea certificatelor
i a cheilor pentru acetia, i trimiterea listei cu serveri. Serviciul de resurse
30

ncarc fiierele cerute, i cripteaz i transmite datele napoi la client,

bineneles doar dup autentificare.

XClient: componenta ofer o interfa pentru conectare la servere,

autentificare, cerere lista de serveri, lista de fiiere, cerere de fiiere i scrierea
acestora pe o unitate fizic. Conectarea se face automat, fr intervenia
utilizatorului, aa cum i decriptarea fiierelor primite.

Baza de date: fiecare server se poate conecta la o baz de date pentru a stoca
utilizatorii nregistrai. Aceste date se acceseaz de ctre serviciul de
autentificare doar o singur dat pentru fiecare client. Baza de date mai conine
o list cu fiecare server disponibil din reea.

3.2.3 Proiectarea componentei XServer

Componenta este responsabil de rularea serviciilor, care la rndul lor sunt i ei

componente, permind crearea, nlocuirea sau adugarea acestora la fiecare server. Dup cum
s-a menionat anterior, n modelul meu voi folosi dou servicii: unul pentru autentificare i
unul pentru gestionarea resurselor.
Serviciul de autentificare este cea mai complex component din model. Ea se ocup
n primul rnd de actualizarea listei cu serveri, i informarea clienilor de aceast list, la
comand. Clienii nregistrai la un server sunt gestionate de acest serviciu, identificarea lor se
face pe baza numelui de utilizator i a parolei, i pe baza acestor informaii serviciul
genereaz certificatul i cheile RSA pentru fiecare client. Autentificarea cu certificat este
procesat tot de aceast component, astfel toate protocoalele de securitate sunt rulate de acest
serviciu. La sfritul autentificrii se genereaz o cheie secret pentru sesiunea curent, i se
comunic aceast cheie cu serviciul de resurse. Componentele majore al serviciului de
autentificare i a relaiile dintre ele se pot vedea n Fig. 7.

31

Fig. 7 Structura intern al serviciului de autentificare

Principalele module interne ale componentei de autentificare sunt:

XAuthService: reprezint modulul principal care se ocup de acceptarea conexiunilor

clienilor.

La

conexiune

acesta

creeaz

instan

modulului

XAuthConnectionHandler. Totodat se ocup de eliberarea memoriei, distrugerea

modulelor inactive, notificarea serviciului de resurse de utilizatorilor noi i preluarea
mesajelor de la ali participani.


Listen Thread: firul de execuie genereaz evenimente care vor rula anumite
funcii ale modulului. Aici se creeaz canalele de comunicaie, se verific
starea fiecrui modul activ i preluarea mesajelor.

TCP Server Channel: implementeaz soclurile (socket) care accept conexiuni

i date. Se ocup de distribuirea mesajelor ntre componente.

Service Handler: gestioneaz serviciile create pentru fiecare conexiune.

Creeaz i distruge canalele de comunicaie folosite pentru toate transmisiunile
de date.

XAuthConnectionHandler: modulul este creat de ctre XAuthService la fiecare

conexiune nou. Aceast component se ocup de tot procesul de autentificare i
generare de certificate i chei.


Service Controller: iniializeaz i controleaz unele funcionaliti al

modulului, comunic cu XAuthService.

32

Final State Machine: automatul finit controleaz cursul protocoalelor de

securitate, setnd strile potrivite pentru o bun funcionare a acestora.

Security Protocol Runner: aici sunt implementate majoritatea protocoalele de

securitate.

Acceseaz

baza

de

date,

controleaz

componenta

OpenSSLWrapper, genereaz rspunsurile pentru clieni i verific datele din

mesaje la fiecare pas.


OpenSSLWrapper: ncapsuleaz toate funciile OpenSSL folosite n proiect i

iniializeaz librriile OpenSSL. Conine mai multe clase care pot fi folosite
separat pentru diferite procese. Modulul XAuthConnectionHandler folosete
majoritatea acestor clase: wrapperul pentru criptare simetric i asimetric,
diferite funcii legate de crearea, folosirea, ncrcarea, scrierea i verificarea
certificatelor; clase pentru crearea i verificarea semnturilor digitale,
generatoare de randomuri.

Performance Counter: msoar timpul de execuie a anumitelor procese n

timpul rulrii. Unele informaii sunt salvate ntr-un fiier jurnal.

3.2.3.1 Iniializarea componentei XServer

Componenta XServer este pornit automat cu apelarea funciei StartServices() la

nivelul cel mai de sus, din API-ul public. nainte de pornire se pot seta anumite proprieti al
serverului, de exemplu directorul care conine resursele. n Fig. 8 se poate vedea secvena de
iniializare mult simplificat a modulului XServer.

33

Fig. 8 Iniializarea modulului XServer

Dup pornirea serviciilor, modulul XServer creeaz cele dou servicii, care la rndul
lor sunt iniiate, i se trec n stare de ateptare de conexiuni noi de la clieni.

3.2.3.2 Autentificarea unui client

n Fig. 9 este prezentat diagrama de secven a autentificrii unui client nou la

componenta de autentificare. Pentru a porni procesul de autentificare, clientul emite o cerere
de conectare. Dac clientul nu are nc un certificat valid, atunci se va conecta prima dat la
serverul gazd (home server), unde va fi verificat n baza de date dac este nregistrat sau nu.
Dac informaiile de identificare au fost corecte, home serverul va genera un certificat cu
datele personale i permisiunile clientului, ct i perechea de chei RSA i va transmite aceste
date clientului. Dac clientul are deja n posesie un certificat valid, poate s sar peste paii de
la serverul gazd, i va iniia o conexiune la serverul de resurse. Acest server poate s fie chiar
i home serverul. La conectare la serverul de resurse, clientul va trimite certificatul, iar
serverul va verifica validitatea acestui folosind cheia public a serverului care a emis acest
certificat. Dac nu are n posesie aceast cheie, va emite o cerere ctre acest server, i va
solicita certificatul acestuia. Se verific mai multe informaii din certificat: validitatea
semnturii, data expirrii, numele nscris n certificat trebuie s coincid cu numele clientului,
emitentul certificatului trebuie s aib proprietatea de Certificate Authority (CA), etc. Dac
toate testele sunt trecute cu succes, serverul genereaz o cheie privat, valabil doar pentru
sesiunea curent, i o va comunica clientului.
34

Fig. 9 Diagrama de secven a autentificrii unui client

3.2.3.3 Serviciul de resurse

Serviciul de resurse pune la dispoziia utilizatorului fiiere gzduite pe serverul

respectiv. La fiecare conectare cu succes la modulul de autentificare, numele utilizatorului i
cheia acestuia vor fi nscrie ntr-o list, care poate fi accesat de serviciul de resurse. La
conectarea clienilor la acest serviciu, se va cuta numele n acea list. Dac numele nu a fost
gsit, fie nc nu s-a autentificat, fie a expirat cheia. Dac numele a fost gsit n list, se
decodeaz cheia, i se folosete pentru decriptarea cererii clientului. Dac decriptarea eueaz,
35

nseamn c cheia nu a fost corect. n acest caz, clientul este deconectat. n caz contrar, se
proceseaz mesajul clientului, si n funcie de natura acestuia se va genera rspunsul.
Momentan acest serviciu poate procesa dou tipuri de cereri: s trimit lista cu fiiere
disponibile, i s trimit unul dintre aceste fiiere napoi la client. n primul caz se parcurge
recursiv lista directoarelor care au fost adugate ca resurse, i se construiete o list cu toate
fiierele, calea acestora i mrimea fiierului. Serviciul, i API-ul suport filtrarea tipurilor de
fiiere, pentru rezultate mai precise. Aceast list cu fiiere va fi criptat cu cheia secret,
folosind algoritmul de criptare simetric AES, i trimis clientului. La recepionare se
decripteaz mesajul, se verific integritatea listei, i se copiaz in locaie de memorie
specificat de utilizator. n cazul celuilalt tip de mesaj, clientul solicit un fiier de la serviciu.
Se decripteaz cererea, se verific dac fiierul exist i dac se afl n directorul de resurse.
n caz afirmativ, se ncarc fiierul ntr-un buffer, i se cripteaz cu aceeai algoritm. La
recepionarea fiierului de ctre client, ca i n cazul anterior, se decripteaz i se copiaz ntrun buffer specificat de utilizator.

3.2.4 Proiectarea componentei XClient

Modulul XClient ncapsuleaz toate procedurile pe partea de client necesare pentru a

implementa mecanismul SSO descris n seciunea 3.2.1. Interfaa componentei ascunde marea
parte a autentificrii, totul se face automat, uurnd munca utilizatorului. Pentru a se conecta
la orice server, se creeaz o instan a componentei, i se apeleaz funcia pentru conectare.
Se verific dac clientul posed un certificat valid pentru a primi acces n sistem. Dac acesta
nu exist, se iniiaz primul protocol pentru a solicita i primi un certificat i cheile respective.
Aceste protocoale includ cteva subprotocoale care vor fi descrise n seciunea urmtoare.
Clientul se ocup de salvarea i ncrcarea acestor certificate i chei pentru fiecare utilizator n
parte. Dup ce certificatul a fost verificat pentru autenticitate, se va trimite serverului care a
fost selectat de utilizator iniial. Acest server va verifica certificatul nc odat, de data asta va
fi verificat i semntura digital cu cheia public a emitentului. De obicei aceste certificate
care conin cheile publice a serverilor sunt salvate la fiecare participant, fiindc se schimb
destul de rar, iar n caz contrar, fiecare server suport un protocol simple pentru a trimite
certificatul propriu solicitanilor. Dac certificatul clientului a fost gsit autentic, se trimite
cheia de sesiune via al doilea protocol de securitate. Clientul va folosi aceast cheia pn la
deconectare de la acest nod, sau pn expir pe partea serverului. Generarea unei chei noi i
protocolul de transport se vor efectua la fiecare conectare, acesta avnd nevoie, n condiii
36

optime, de 100 de milisecunde timp de rulare, ceea ce practic nu este detectabil de utilizator.
Dup conectare, sunt disponibile dou funcii pentru a interaciona cu server: unul pentru a
cere lista de fiiere gzduite aici, i altul pentru a solicita un fiier din aceast list. Filtrarea
listei n funcie de extensia fiierelor se poate face pe partea de client, pentru a gsi obiectul
cutat mai uor. Momentan nu exist un indicator de progres pentru transferul fiierului, dar
se poate aduga mai trziu. Interfaa mai ofer cteva funcii, ca de exemplu: interogarea
componentei despre erori, solicitarea listei cu serveri din reea, simularea unui pachet ping,
pentru a msura timpul de rspuns al unui server, scrierea fiierelor pe un dispozitiv de
stocare fizic, schimbarea utilizatorului, etc. Toate aceste procese se fac automat i ascuns, dar
totui tot traficul ntre participani este confidenial, datorit protocoalelor de securitate i
criptografiei performante.
Componentele majore i relaiile ntre ele sunt prezentate n Fig. 10.

Fig. 10 Structura intern a componentei XClient

37

Principalele module interne ale componentei XClient sunt:

XClient: reprezint modulul principal care leag componentele interioare ntre ele, i
face legtura cu API-ul.


TCP Client Channel: implementeaz soclurile (socket) care comunic cu

servere, prin protocoale TCP/IP. Se ocup de distribuirea mesajelor ntre
componente.

Service Handler: gestioneaz serviciile create pentru fiecare conexiune.

Creeaz i distruge canalele de comunicaie folosite pentru toate transmisiunile
de date.

Component Wrapper: Reprezint interfaa dintre utilizator i componentele

interne.

Final State Machine: automatul finit controleaz cursul protocoalelor de

securitate, setnd strile potrivite pentru o bun funcionare a acestora.

Security Protocol Runner: aici sunt implementate majoritatea protocoalele de

securitate.

Acceseaz

baza

de

date,

controleaz

componenta

OpenSSLWrapper, genereaz rspunsurile pentru clieni i verific datele din

mesaje la fiecare pas.


OpenSSLWrapper: ncapsuleaz toate funciile OpenSSL folosite n proiect i

iniializeaz librriile OpenSSL. Conine mai multe clase care pot fi folosite
separat pentru diferite procese. Modulul XAuthConnectionHandler folosete
majoritatea acestor clase: wrapperul pentru criptare simetric i asimetric,
diferite funcii legate de crearea, folosirea, ncrcarea, scrierea i verificarea
certificatelor; clase pentru crearea i verificarea semnturilor digitale,
generatoare de randomuri.

FileSystem IO: reprezint setul de funcii care acceseaz fiierele necesare

pentru funcionare.

3.2.5 Proiectarea bazei de date

Baza de date conine date legate de localizarea serviciilor n cadrul reelei, ct i

informaii despre utilizatorii nregistrai la un server. n mod normal, fiecare server are o baz
de date cu aceeai structur. n Fig. 11 este prezentat structura bazei de date.
Tabelul servers conine informaii despre fiecare server n reea. Aceste date sunt
folosite pentru a forma lista serverilor la solicitarea clienilor. Datele se citesc de fiecare
38

cerere. Fiecare server are asociat un nume, o adres i o opional o descriere a serverului sau a
resurselor gzduite. Tabelul users stocheaz datele despre utilizatorii nregistrai la serverul
respectiv. Fiecare utilizator nregistrat are asociat un nume de utilizator, o parol i un rol n
cadrul reelei. Aceste date se verific la autentificare, i se genereaz certificatul pe baza lor.

Fig. 11 Structura bazei de date

3.3 Proiectarea interfeei de programare (API)

Componenta XClient asigur o interfa minimal, dar suficient pentru implementare.

Majoritatea funciilor sunt cu blocare, i au nume sugestive. Componenta ofer rapoarte
detaliate n caz de eroare.

Constructorul: ia ca parametru numele de utilizator i parola, care vor fi folosite

pe toat durata instanei. Aceste date se pot schimba mai trziu.
XClient( const std::string UserName, const std::string Password
);

Connect: conectare la un server din reea, adresa acestui server fiind precizat prin
parametru. Clientul se conecteaz la home server i va solicita un certificat, n
cazul n care nu are deja unul valid, iar dup aceea la serverul precizat. Conectarea
la cele dou servere se face automat i cu blocare pn terminare. Un al doilea
parametru va returna numrul de milisecunde scurse pn la obinerea
certificatului respectiv a cheii pentru aceast sesiune. Funcia returneaz o expresie
boolean, semnificnd reuita operaiei.
bool Connect( std::string ResourceServerAddress, double
&TimeElapsed );

getLastErrorMessage: n caz de eroare, se apeleaz aceast funcie pentru a afla

mai multe detalii legate de problem, n form de text.
39

std::string getLastErrorMessage();

getServerList: cere lista de serveri disponibili n reea de la home server. Lista

include adresa fiecrui server, ct i descrierea acestora. Funcia se poate apela
oricnd, nu necesit autentificare. Lista va fi stocat intr-un vector dat ca
parametru. Funcia blocheaz firul de execuie n care se ruleaz pn primete un
rspuns de la server, sau expir time-out-ul. Funcia returneaz o expresie
boolean, semnificnd reuita operaiei.
bool getServerList( std::vector< ServerInfo* > &SList );

getFileList: se solicit lista de fiiere disponibile pe serverul curent. Funcia se

apeleaz doar dup o conectare cu succes la unul dintre serverele din reea. Datele
trimise i recepionate vor fi criptate cu o cheie secret prestabilit la conectare.
Lista va fi stocat intr-un vector dat ca parametru. Lista va include numele, calea i
mrimea n octei pentru fiecare fiier. Funcia blocheaz firul de execuie n care
se ruleaz pn primete un rspuns de la server, sau expir time-out-ul. Funcia
returneaz o expresie boolean, semnificnd reuita operaiei.
bool getFileList( std::vector< FileInfo* > &FList, std::string
Mask );

RequestFile: se solicit un fiier de la serverul curent. Funcia se apeleaz doar

dup conectare cu succes la unul dintre serverele din reea. Datele trimise i
recepionate vor fi criptate cu o cheie secret prestabilit la conectare. Calea ctre
fiierul dorit, ct i un buffer pentru stocarea acestuia vor fi date ca parametru.
Funcia blocheaz firul de execuie n care se ruleaz pn primete un rspuns de
la server, sau expir time-out-ul. Funcia returneaz o expresie boolean,
semnificnd reuita operaiei.
bool RequestFile( std::string FileName, std::vector< char >
&FileBuffer );

PingServer: simuleaz un ping ctre un server din reea. Singurul parametru este
adresa serverului ales. Funcia este cu blocare i returneaz timpul trecut n
milisecunde pn la recepionarea rspunsului de la server.
int PingServer( std::string HostName );

40

WriteFile: scrie un fiier pe o unitate fizic pentru stocare. Primul parametru

specific calea ctre noul fiier, iar al doilea va fi bufferul care conine fiierul
primit de la server. Funcia returneaz o expresie boolean, semnificnd reuita
operaiei.
bool

WriteFile(

std::string

FileName,

std::vector<

char

>

FileBuffer );

getCertificate: funcia returneaz un certificat ntr-un format decriptat, doar pentru

afiare. Singurul parametru precizeaz certificatul ales, 1 pentru a returna
certificatul clientului, 2 al home serverului i 3 al serverului de resurse.
std::string getCertificate(int Select);

SwitchUser: permite schimbarea utilizatorului, fr a crea o instan nou XClient.

Noul utilizator va trebui s se reconecteze la unul dintre serverele disponibile.
Parametrii vor conine numele de utilizator, adresa home serverului, i parola
utilizatorului. Funcia nu returneaz o valoare.
void SwitchUser( std::string UserName, std::string Password );

Componenta XServer pune la dispoziie cteva funcii care permit crearea unui server
de autentificare i de resurse funcional.

Constructorul: are ca parametru numele serverului

XAuthServer( const tstring ServerName );

setResourceDir: permite selectarea dosarelor care vor conine fiiere resurse. Se

pot preciza mai multe surse, separndu-le cu virgul. Aceste dosare vor fi parcurse
recursiv de la fiecare cerere de list de fiiere. Dac serverul nu va gzdui resurse,
se poate ignora aceast funcie. Funcia se apeleaz doar nainte de pornirea
serverului.
void setResourceDir( tstring Directories );

startServices: pornete serverele de autentificare i de resurse n mod de ascultare.

Conexiunile vor fi procesate automat. Ca parametru se pot specifica porturile de
ascultare pentru cele dou servere, sau 0 pentru a folosi porturile predefinite.
Funcia blocheaz curentul fir de execuie pn la oprirea serverului.
void

startServices

const

int

AuthServicePort,

const

int

ResourceServicePort );

41

stopServices: oprete cele dou servicii, clienii vor fi deconectai.

void stopServices();

3.4 Proiectarea protocoalelor de securitate

Comunicarea ntre componentele sistemului de autentificare se realizeaz prin schimb

de mesaje pe soclu. Mesajele sunt parte a unor protocoale de securitate care au rolul de a
pstra confidenialitatea datelor, identificarea i autentificarea participanilor. Protocoalele
difer n funcie de componentele ntre care se desfoar, dar i n funcie de scopul fiecrui
protocol. Proiectarea protocoalelor s-a realizat pe baza principiilor prezentate n capitolul
2.2.1. Protocoalele de securitate existente ca SSL (Secure Socket Layers) sau TLS (Transport
Layer Security) sunt complexe, i conin multe informaii care nu ne folosesc n modelul meu.
Fiindc noi vrem s navigm cu uurin i rapiditate ntre serverele din reea nu ne putem
permite s avem date inutile n mesaje, de aceea am proiectat un set nou de protocoale, care
conin datele strict necesare pentru a atinge scopurile propuse. Protocolul complet este descris
n Fig. 12, descrierea lui n seciunea urmtoare.
Componentele mesajelor i ce anume semnific acestea:
A Home server (serverul unde este nregistrat clientul B), respectiv n mesaj nume server
B Client, respectiv n mesaj nume client
C Serverul de resurse ales pentru conectare, respectiv n mesaj nume server
N Nonce, un numr aleator
(X)h O funcie hash aplicat pe X
M Cuvinte cheie folosite pentru identificarea tipul mesajului
KXY Cheie simetric cunoscut doar de X i Y
skX Cheie secret asimetric a lui X, se decripteaz cu pkX, folosit pentru semnturi digitale
pkX Cheie public asimetric a lui X, se decripteaz cu skX
{|X|}Y X criptat cu cheia Y
CertX Certificatul lui X, care conine i cheia public
Sig Semntur digital

42

Fig. 12 Protocolul complet de autentificare

3.4.1 Protocolul de autentificare la home server

Pentru a primi acces la serviciul de resurse, un utilizator trebuie s aib un certificat

valid. Serverul genereaz aceste certificate la cerere, pe baza numelui de utilizator si a parolei.
Aceste informaii sunt stocate ntr-o baz de date sigur, pe partea serverului, dar transmiterea
lor nu se poate face direct, pentru c oricine poate asculta comunicaia n reea. Acest protocol
de securitate va garanta transmisia lor n secret. Protocolul se efectueaz ori de cte ori este
nevoie de un nou certificat, dar pentru c certificatul este salvat, asta se ntmpl n mod
normal doar dup expirarea certificatului. Paii protocolului de autentificare:

1.
2.
3.
4.

43

Primul pas reprezint iniierea conexiunii de ctre client (B). Mesajul conine tipul
mesajului, acesta fiind solicitare de autentificare pe baza parolei, i numele clientului.
Serverul (B) decide dac poate accepta o nou conexiune, i verific dac numele clientului se
gsete la el n baza de date. n caz afirmativ, se genereaz un nonce, se aplic funcia hash, i
se trimite napoi clientului. Mesajul serverului va conine fie acceptarea conexiunii, fie un
mesaj de eroare cu motivul eurii. Dac conexiunea este acceptat, clientul va aplica aceeai
funcie hash pe hashul primit de la server, i va genera o cheie simetric care va fi folosit
pentru criptarea cheii secrete din certificat. Clientul n acest moment are n posesie certificatul
serverului, fie avndu-l salvat, fie cerndu-l nainte de iniierea conexiunii. Acest certificat
conine cheia public a serverului (pkA), i va fi folosit pentru criptarea prilor secrete a
mesajului, adic nonce-ul, numele de utilizator, parola i cheia generat. Datele binare sunt
codate cu Base64 nainte de trimitere. Acest text cifra poate fi decriptat doar cu cheia secret a
serverului (skA), iar dup decriptare, se verific prima dat nonce-ul. Acesta se face prin
aplicarea funciei hash pe hash-ul salvat n pasul anterior, i compararea rezultatului cu cel din
mesajul trimis de client. Dac cele dou iruri nu coincid, se trimite un mesaj de eroare, i se
termin conexiunea. Acesta este un Dac verificarea a fost efectuat cu succes, semnificnd
c mesajul este recent, se caut numele clientului n baza de date i se compar parola trimis
de client cu cea stocat n baza de date. Dup acesta se genereaz certificatul pentru client,
care va conine numele i permisiunile solicitantului, numele emitentului, perioada de
validitate, cheia public generat i alte informaii necesare pentru verificarea certificatului.
Certificatul este semnat digital cu cheia secret a serverului. Perechea cheii din certificat este
criptat cu cheia generat de client. Hash-ul nonce-ului este procesat similar ca n pasul
precedent, i mpreun cu cheia criptat i certificatul generat vor fi criptate cu cheia secret a
serverului, adic semnat digital. Acesta este un test de autentificare de intrare, pentru c
nonce-ul trimis va fi reprimit de ctre client ntr-o form criptat cu o cheie care este
cunoscut numai de ctre server. Mesajul este autentic, dar pentru a se asigura c este i
recent, se verific nonce-ul. Cheia secret este decriptat cu cheia generat anterior, i va fi
salvat mpreun cu certificatul generat.

3.4.2 Protocolul de autentificare la serverul de resurse

Dup ce clientul are un certificat valid, se poate folosi de el pentru a primi acces la
anumite servere din reea, n funcie de permisiunile fiecruia. Acest certificat ar fi de ajuns
pentru a se autentifica i pentru a transmite date criptate, dar algoritmul de criptare RSA este
44

mai ncet dect algoritmii de criptare cu chei simetrice. De aceea, cu ajutorul cheilor din
certificat se negociaz o cheie secret simetric, care va fi folosit pentru criptarea datelor ntre
client i serverul de resurse ales. Pentru c cheile simetrice pot fi descoperite mai uor dect
cele asimetrice, o cheie nou se va genera la fiecare conectare, i va fi valabil doar pe durata
sesiunii curente. Aceast cheie trebuie s rmn secret, dar fiindc este generat de ctre
server, transmisia ei necesit protecie, oferit de acest protocol de securitate. Protocolul
este iniiat de client la fiecare conectare la orice server de resurse, i are urmtorii pai:

1.
2.
3.
4.

n primul pas clientul (B) iniiaz conexiunea, trimind numele i tipul mesajului:
autentificare cu certificat. Serverul rspunde fie cu acceptare, fie cu un mesaj de eroare i
motivul acestuia. Mesajul va conine i un nonce generat de acest server. Clientul aplic
funcia hash asupra nonce-ului, i l semneaz cu cheia lui secret. Aceast semntur i
certificatul va fi trimis napoi serverului. Nonce-ul semnat poate fi verificat cu cheia public
din certificat, dar nainte de acesta, trebuie verificat i autenticitatea certificatului. Se verific
hash-urile din certificat, perioada de valabilitate, anumite flaguri care specific dac emitentul
este sau nu un Certificate Authority (CA), i bineneles semntura din certificat. Aceast
semntur a fost fcut cu cheia secret a emitentului, deci se verific cu cheia public
pereche. Dac acest server nu are certificatul serverului emitent, l solicit i extrage cheia
public pentru a verifica semntura din certificat. Dac certificatul nu poate fi validat,
autentificarea va eua. n caz contrar, se extrage cheia public din certificat i se verific
semntura clientului. i aici ntlnim un test de autentificare de intrare, pentru c elementul
criptat intr: N  {|N|}. Acest test asigur c mesajul este recent i c este trimis de
posesorul certificatului. Opional, se verific permisiunile nscrise n certificat, i n funcie de
regulile serverului anumite clase de utilizatori sunt filtrate. Se genereaz o cheie privat, i
mpreun cu nonce-ul hash-uit, este criptat cu cheia public a clientului, extras din certificat.
Tot mesajul este semnat digital de ctre server i transmis clientului. La recepionare se
decripteaz mesajul, i se verific nonce-ul, comparndu-l cu cel salvat anterior. Se verific i
semntura digital a serverului, i se salveaz cheia de sesiune. Aceast cheie va fi folosit
doar o singur sesiune, i doar cu acest server. Toate cererile de resurse i rspunsurile sunt
45

criptate cu aceast cheie. La reconectare se ruleaz acest protocol nc odat pentru a genera o
cheie nou.

3.4.3 Protocolul de solicitare certificat

Sistemul Single Sign-on este construit pe o infrastructur cu chei publice, unde

certificatele sunt elementele de baz. De aceea fiecare protocol de autentificare are nevoie de
certificatele serverelor participani. Pentru asta am creat un alt protocol simplu care solicit
certificatul serverului precizat i l salveaz local. Pentru c n cazul meu cel mai important
aspect dup securitate este simplitatea, acest protocol conine doar doi pai:

1.
2.

Primul pas specific tipul mesajului i numele solicitantului, iar al doilea pas conine
rezultatul cererii, i certificatul solicitat. Fiindc certificatul conine toate elementele de
securitate pentru a verifica autenticitatea lui, nu este nevoie de un protocol complex pentru a
asigura transmisia acestuia.

46

Capitolul 4 Implementarea sistemului

4.1 Arhitectura intern a claselor

La baza sistemului stau clasele construite cu librriile NSPR, i care ofer

funcionaliti simple, de exemplu: fire de execuie, socluri, parsere, containere i elemente de
legtura cu clasele la nivele mai nalte.
O alt grup de clase este cea de securitate, asta include clasele care se conin
funcionaliti pentru crearea, ncrcarea, verificarea certificatelor, criptografie, funcii hash,
semnturi digitale, generatoare de nonce-uri, etc. Aceste clase au fost construite folosind
librriile OpenSSL.
Canalele de comunicaie sunt motenesc soclurile i firele de execuie, pentru a oferi
un control mai avansat al fluxului de mesaje. Acesta se realizeaz apelnd funcii callback.
Gestionarea canalelor se face cu ajutorul clasei XChannelHandler, care creeaz i terge
canalele.
Peste aceste canale sunt construite serviciile, care deja au
funcionaliti complexe. Sunt dou tipuri de servicii, client i
server, fiecare are canale de comunicaie, care vor transmite
mesajele.

Gestionarea

serviciilor

se

face

de

clasa

XServiceHandler, cu ajutorul creia se pot crea i terge serviciile.

4.1.1 Clasele de baz

n aceast seciune sunt prezentate clasele mai importante

care sunt folosite pentru a construi componentele principale,
amintite anterior.
Clasa XThread (Fig. 13) implementeaz datele necesare i
funcionalitatea unui fir de execuie aa cum este el definit de
NSPR. Printre datele membru se regsete m_Thread, descriptorul
firului de execuie i dou variabile de tip boolean m_bRunning i
m_bExited utilizate pentru a semnala starea firului. Funciile
membru start(), stop() sunt folosite pentru a porni, respectiv a opri

Fig. 13 Clasa XThread

47

firul de execuie. Pentru a lansa un fir de execuie trebuie derivat o clas din XThread i
suprascris metoda Run(), instaniat clasa, apoi se va apela metoda start(). Firul de execuie
va rula pn cnd metoda Run() i va ncheia execuia sau este apelat metoda stop().
Metodele isRunning() i isExited() returneaz starea firului de execuie.
Clasa XTwinThread ncapsuleaz dou fire de
execuie, unul prin motenirea clasei XThread, iar al doilea
printr-un membru de tipul clasei XThreadRunner care
motenete la rndul ei clasa XThread. Membrul m_thread
este un pointer ctre instana clasei XThreadRunner iar
metodele tstart(), tstop(), tisRunning() i tisExited() se
folosesc pentru a porni, opri, respectiv interoga starea celui
de-al doilea fir de execuie.
Clasa

XTCPSocket

(Fig.

14)

ncapsuleaz

funcionalitatea unui soclu utilizat pentru a stabili conexiuni

TCP/IP. Printre datele membru este m_Socket, descriptorul
obiectului soclu. Funciile getData(char* buffer,int bufSize)
i sendData(char* buffer,int bufSize) sunt folosite pentru a
receptiona date pe soclu, respectiv pentru a trimite date.
Clasa XTCPServerSocket motenete n mod direct
clasa XSocket i implementeaz metode pentru a pune un
soclu n starea de ascultare i pentru a accepta cereri de
conexiune. Aceasta ofer n plus faa de clasa XSocket dou
metode: Listen() i Accept() folosite pentru a pune soclul n
starea de ascultare, respectiv pentru a accepta o conexiune.
Mai conine i un membru m_port folosit pentru a specifica
pe ce port s se porneasc ascultarea.

Fig. 14 Clasa XTCPSocket

Clasa XTCPClientSocket motenete n mod direct clasa XSocket i implementeaz

metode pentru a realiza o conexiune cu un server. Aceasta ofer n plus fa de clasa XSocket
cteva metode: Connect() pentru a iniia o cerere de conexiune i isConnected() prin care se
poate interoga starea soclului (dac este sau nu conectat). Printre membri acestei clase se pot
aminti urmtorii: pAddr i m_iPort prin care se specific adresa i portul pe care s se fac
conectarea i m_bConnected utilizat pentru stabilirea strii soclului, valoarea sa putnd fi
setat prin intermediul metodei setConnectionStatus() i obinut prin intermediul metodei
isConnected().
48

Clasa TCPServer ncapsuleaz clasa XServerSocket, i XTwinThread, i ofer

funcionalitatea unui server, adic ascult pentru conexiuni noi, att timp ct membrul privat
m_bShouldRun este true. Tot aici se vor apela funciile callback care vor fi suprascrise n
clasele care vor moteni clasa TCPServer. Ofer trei funcii pentru a interaciona cu serverul:
createServer(), runServer() i stopServer(), rolul crora sunt evidente.
Clasa TCPTransport ncapsuleaz clasa XClientSocket, dar este folosit att pe partea
clientului ct i pe partea serverului, ocupndu-se de transportul datelor. Apeleaz funciile
callback, la orice eveniment de receive sau send, att timp ct membrul privat m_bShouldRun
este true.
Un obiect care st la baza transportului de date este clasa XMessage (Fig. 15), care
conine toate setrile necesare ca datele s ajung la destinaie, ct i datele n sine. Clasa
ofer stocarea datelor att n format raw, neformatat, ct i ntr-un format delimitat, avnd
funcionalitatea unui parser.
Clasa XSimpleParser (Fig. 15) este folosit foarte des, deoarece se ocup de prelucrarea
mesajelor, i a datelor n general. Prelucrarea n cazul acestui parser nseamn desprirea
ntregului ir n mai multe pri (tokenuri), iar delimitatorul este specificat de utilizator la
instanierea obiectului. Metodele publice includ funcii pentru a returna numrul acestor
tokenuri, verificarea dac conine un anumit subir, returnarea fiecrui token separat, etc.
Clasa XSimpleList (Fig. 15) ncapsuleaz lista din librriile standard [25], adugnd
cteva funcii pentru compatibilitate cu celelalte clase din proiect.
Clasa XBase64Coder (Fig. 15) ofer codare i decodare n popularul format
standardizat Base64 [26]. Acest format permite trimiterea datelor binare ntre participani fr
a pierde integritatea datelor. Clasa stocheaz rezultatul i mrimea acestuia n membrii privai
m_pResult respectiv m_nResultSz. Funciile publice encode() i decode() sunt folosite pentru
codarea i decodarea datelor, iar rezultatul i mrimea rezultatului sunt returnate de funciile
getResult() respectiv getResultSize().

49

Fig. 15 Diagrama de clase pentru clasele: XMessage, XSimpleParser, XSimpleList i XBase64Coder

4.1.2 Clasele de securitate

Clasele OpenSSL sunt construite pe librriile OpenSSL, i se folosesc pentru a

implementa facilitile de securitate. Diagrama de clase este prezentat n Fig. 16.
Majoritatea claselor au un membru privat care conine datele procesate, i funcii de
tip getter / setter pentru accesarea lor.
Clasa DigitalSignatureCreator creaz semnturi digitale pe baza datelor de intrare i a
unei chei transmise ca parametrii n funcia signData(). Semntura i hash-ul acesteia pot fi
accesate prin funciile respective. Aceast clas ofer si verificare prin funcia
verifySignature(), care ia ca parametru datele semnate digital i o cheie.
Clasa HashCreator, cum spune i numele, aplic o funcie hash pe datele introduse.
Funcia hashData() ia ca parametru datele de intrare i tipul algoritmului hash. Algoritmii
suportai sunt MD5 i SHA1. Rezultatul se returneaz cu funciile getHash() i getHashSize().
Clasele CertificateCreator, CertificateChecker i CertificateLoader conin proceduri
pentru gestionarea certificatelor. Cum spune i numele, CertificateCreator genereaz
50

certificatele pe baza datelor trimise ca argumente funciei CreateCertificate(). Informaiile

necesare pentru generarea certificatului sunt prezentate n seciunea 2.4. Tot aici se genereaz
i perechea de chei RSA. Clasa CertificateChecker verific certificatele, dup anumite criterii
specificate ca parametru pentru funcia VerifyCertificate(). Funcia getPermission() citete
permisiunile clienilor pentru controlul accesului n reea. Clasa CertificateLoader are rolul de
a ncrca certificatele stocate pe un dispozitiv fizic. Funciile getPrivateKey() i
getPublicKey() extrag cheile specificate din certificat, care a fost ncrcat folosind funcia
loadCertificate() respectiv din fiierul cu cheia privat, folosind funcia loadPrivateKey().
Clasa RandomCreator genereaz numere aleatorii, care sunt folosite n orice protocol
de securitate. Un numr 100% aleatoriu este imposibil de generat folosind numai calculatorul,
de aceea aceste numere sunt doar pseudorandom-uri. Totui se ncearc s fie influenat de ct
mai multe surse ntmpltoare posibil. Acesta folosete timpul calculatorului combinat cu
valori din stiv. Funcia generateRandom() creeaz un numr de mrime specificat ca
parametru. Rezultatul este returnat de funcia getRandData().
Clasa AszmmEncCreator ncapsuleaz funciile de criptografie simetric din librriile
OpenSSL. Suport toate algoritmele disponibile n aceste librrii. Pentru selectarea
algoritmului i specificarea cheii folosite se apeleaz funcia initEncryptionCtx(). Dup
iniializare se pot apela funciile encryptData() i decryptData() pentru criptarea respectiv
decriptarea datelor. Rezultatul se obine apelnd funcia getData() iar mrimea rezultatului
prin funcia getDataSize().

51

Fig. 16 Diagrama de clase OpenSSL

4.1.3 Canalele de comunicaie

Prin folosirea funciilor callback a claselor TCPServer i TCPTransport se creeaz o

list care va conine obiecte de tip XMessage, cu ajutorul crora se va efectua transmisia
datelor. Canalele sunt reprezentate de clasa XIChannel, care gestioneaz aceast list cu
mesaje, m_msgList. Identificatorul canalului este stocat n membrul m_nChannelID, iar de
funciile callback se ocup m_pchCallback. Aceste variabile sunt accesabile prin metodele
getter i setter: getChannelID(), setChannelID(), addMessage(), getChMessage().
Clasa XHandlerImplementation motenete clasele XIChannelCallback i XThread, i
se ocup de gestionarea canalelor i redirecionarea mesajelor la destinaia potrivit. Firul de
execuie, pornit cu run(), citete datele recepionate, i decide canalul pentru care este
destinat acesta. Canalele sunt create i distruse de acest obiect, prin funciile createChannel()
i destroyChannel(). Membrul m_channelMap stocheaz toate canalele create. Mesajele sunt
trimise canalelor prin funciile sendToChannel() i getMessage(), iar mesajele interne sunt
52

trimise funciei handleInternalChMessage() pentru procesare local. Clasa XChannelHandler

este un wrapper pentru clasa XHandlerImplementation.
Clasele XTCPServerChannel

XTCPClientChannel

motenesc

unele clase

menionate anterior, i adaug anumite funcionaliti specifice canalelor server / client, i se

ocup de crearea i verificarea header-urilor mesajelor.
Diagrama de clase a canalelor de comunicaie este prezentat n Fig. 17.

Fig. 17 Diagrama de clase a canalelor de comunicaie

53

4.1.4 Servicii

Serviciile ncapsuleaz canalele de comunicaii i au o structur similar cu acestea:

funciile callback genereaz evenimentele cnd se recepioneaz un mesaj. Aceste mesaje sunt
trimise canalelor, iar de la canale la servicii. Gestionarea serviciilor se face de ctre un obiect
global, ca i XChannelHandler-ul. La crearea serviciilor, se seteaz proprietile fiecruia n
parte. Acest lucru se face cu ajutorul structurii service_info, care conine tipul noului serviciu,
portul de ascultare, i configurri opionale.
Elementul de baz este XIService care la rndul lui motenete clasa XThread.
Aceast clas este abstract, i definete structura clasei care o va ncapsula. Acesta va fi
XBaseService care are deja funcionalitile unui serviciu. Membrii privai stocheaz ultimele
mesaje (m_lstMessages), o instan a XChannelHandler-ului, prin care se va face transmisia
datelor (m_pChannelHandler), proprietile serviciului (m_svInfo), i identificatorului
canalului principal (m_nMainChannelID). Majoritatea funciilor membri a clasei sunt virtuale,
i folosite ca funcii callback pentru clasa care va moteni acest obiect. Aceste funcii sunt
apelate la evenimentele generate de mesaje primite, care sunt verificate n funcia run a firului
de execuie. Funciile includ notificri pentru crearea, distrugerea, configurearea canalelor,
furnizeaz informaii despre starea canalelor, i trimit notificri n cazul n care s-au
recepionat mesaje pe canal.
Clasa XServiceDeployment gestioneaz serviciile, se ocup de crearea acestora i
expedierea mesajelor. Toate serviciile active sunt stocate n variabila m_serviceMap.
Distrugerea i configurarea serviciilor, ct i rutarea mesajelor se face la nivele mai joase.
Clasa XServiceHandler este un wrapper pentru clasa XServiceDeployment. Diagrama
acestor clase este prezentat n Fig. 18.

54

Fig. 18 Diagrama de clase a serviciilor

Diagrama claselor de comunicaie i relaiile ntre ele sunt prezentate n Fig. 19.

55

Fig. 19 Clasele de comunicaie i relaiile ntre ele

56

4.2 XServer

Funcionarea componentei este descris n seciunea 3.2.3. Componenta este o

ncapsulare a clasei XServiceHandler, cu ajutorul creia sunt create serviciile de autentificare
i de resurse. Dup configurarea componentei, fluxul mesajelor i generarea notificrilor se
face automat de ctre clasele de comunicaie descrie mai sus.
Un serviciu se creeaz prin motenirea clasei XBaseService. Aceast clas conine n
mare parte funcii virtuale, care trebuie suprascrie de ctre noul serviciu creat. Un fir de
execuie se ocup de citirea mesajelor i generarea notificrilor necesare. Funciile oferite de
clasa XBaseService sunt vizibile n Fig. 18. Funcia onCreateChannel() este apelat de fiecare
dat cnd o nou conexiune este creat, i odat cu acesta un nou obiect XChannelHandler,
pentru a gestiona fluxul mesajelor. La conectarea unui client se creeaz un obiect de tip
XAuthSvConnHandler pentru serviciul de autentificare, respectiv XResSvConnHandler
pentru serviciul de resurse. Aceste dou clase motenesc clasa abstract XISvConnHandler,
care recepioneaz mesajele pentru acest canal, i le proceseaz n funcie de tipul serviciului.
Membrul privat m_lstConnections este o list care conine aceste obiecte de tip
XISvConnHandler, i are rolul de a gsi destinatarii mesajelor la recepionare. De acesta se
ocup funcia onChannelDataMessage() care este apelat la fiecare mesaj recepionat. n
acest moment lista cu conexiuni este parcurs i se caut canalul care are identificatorul la fel
ca i mesajul primit. Dac se gsete canalul, se apeleaz funcia processMessage(), n caz
contrar se genereaz o eroare i se distruge canalul. Acest lucru declaneaz o notificare care
apeleaz funcia onDestroyChannel(). n aceast funcie se terge obiectul care stoca
conexiunea respectiv, i se elibereaz memoria. O alt notificare se declaneaz cnd un
canal este inactiv pentru un timp mai lung. n funcie de implementarea serviciului, aici se pot
lua unele msuri n legtur cu acest canal. n sistemul meu, conexiunile sunt eliberate cnd
sunt inactive. Diagrama de stare a clasei este prezentat n Fig. 20.
Clasele XISvConnHandler suprascriu funcia onMessage() care va fi apelat de fiecare
dat cnd este recepionat un mesaj care are ca destinaie acest canal. n aceast funcie se
proceseaz mesajul, n cazul acesta se verific header-ul mesajelor,se extrage informaia util
din acestea, i se trimite funciei processRequest(). Aici procesarea datelor este dependent de
tipul serviciului. Diagrama de stare se poate vedea n Fig. 21.

57

Fig. 20 Diagrama de stare a sistemului de servicii

Fig. 21 Diagrama de stare a sistemului de conexiuni

58

4.2.1 Serviciul de autentificare

Serviciul de autentificare are urmtoarele roluri:

o Autentific utilizatorii pe baza numelui de utilizator i a parolei
o Autentific utilizatorii pe baza certificatului
o Trimite certificatul propriu la cerere
o Trimite lista de serveri disponibili din reea la cerere
o Msurarea performanei de autentificare a clienilor
Fiecare server care ruleaz acest serviciu are aceste funcionaliti, iar selectarea lor se
face de ctre maina de stare a sistemului. Strile sunt setate n funcie de coninutul mesajelor
sau de pasul curent n procesul de autentificare. La acceptarea unei noi conexiuni n funcia
onCreateChannel() se creeaz o nou instan a obiectului XAuthSvConnHandler, i se
adaug n lista m_lstConnections. Periodic se verific activitatea acestor conexiuni, i dac
sunt inactive, sau i-au terminat activitatea, sunt eliberate din memorie i terse din list.
Mesajele sunt recepionate prin funcia onChannelDataMessage() i trimise ca parametru
instanei XAuthSvConnHandler prin funcia processMessage(). n cazul n care nu este gsit
proprietarul mesajului, se terge canalul de comunicaie. La distrugerea conexiunilor se citete
membrul m_Time a instanei XAuthSvConnHandler, prin funcia getTime(), care conine
timpul de rulare n cazul autentificrii. Aceste informaii sunt salvate ntr-un fiier local.
La crearea unui obiect XAuthSvConnHandler sistemul este iniiat i trece n stare de
ateptare mesaje. La recepionarea unui mesaj se verific integritatea acestuia, i se
proceseaz. La procesare se seteaz starea sistemului n funcie de solicitarea clientului.
Protocolul de autentificare are nevoie de mai muli pai pentru terminare, aa c sistemul este
configurat pentru a recepiona alte mesaje i ai continua autentificarea. Celelalte mesaje, i
ultimul pas din fiecare protocol, dup generarea i trimiterea datelor pun sistemul n starea
final, unde se elibereaz memoria alocat n timpul rulrii, i se seteaz variabila m_bAllive,
care indic starea conexiunii, false. Clasa XAuthService verific aceast valoare periodic, i la
terminare, dac e cazul citete performana autentificrii, distruge i elibereaz conexiunea. n
Fig. 22 se vede diagrama de stare simplificat.

59

Fig. 22 Diagrama de stare a execuiei serviciului de autentificare

Funcionarea serviciului de autentificare mai detaliat, cu strile sistemului, sunt

explicate n continuare. Sistemul iniial este n starea 0, unde se fac iniializrile, i se trece n
starea 1. Aici se ateapt ntr-o bucl infinit pn la recepionarea unui mesaj. Mesajul
poate fi unul pentru configurarea sistemului, sau unul de la client, solicitnd servicii.
La solicitarea listei cu serveri, se acceseaz baza de date pentru citirea datelor.
Informaiile legate de server sunt formatate pentru trimitere, n form de token-uri. Aceeai
lucru se ntmpl i n cazul solicitrii a certificatului. La cerere se ncarc certificatul n
memorie, i se trimite clientului aa cum este, fiind deja codat cu Base64, permite transportul
fr pierderea integritii. n acest timp, serverul este n starea 2. n ambele cazuri, dup
terminarea procesrii, sistemul trece n starea final unde conexiunea este terminat iar
obiectul XAuthSvConnHandler este distrus i eliberat din memorie.
n cazul autentificrii, clientul n primul pas trimite un mesaj exprimndu-i inteniile
de autentificare. Serviciul verific numele clientului, i folosind RandomGenerator-ul, se
genereaz un nonce. Acesta va fi salvat pentru pasul urmtor. Sistemul se trece iar n starea 1,
ateptnd mesaje, dar se salveaz progresul autentificrii. La recepionarea unui mesaj valid
60

se trece n starea 4. Aici practic se desfoar protocolul de autentificare, paii detaliai

includ: se decodeaz mesajul, folosind o clas XBase64Coder, declarat global. Se decripteaz
mesajul cu cheia privat a serverului, i se verific dac sunt prezente toate token-urile
necesare pentru acest pas. Se verific nonce-ul trimis de client dac coincide cu cel salvat n
pasul anterior. Informaiile de identificare a clientului sunt verificate n baza de date, i se
ncepe generarea certificatului. Funcia CertificateCreator::CreateCertificate() ia toate
informaiile necesare pentru a completa cmpurile din certificat. Cheia public se afl n
certificat, iar perechea este criptat cu cheia trimis de client, tot n acest mesaj. La orice
euare a verificrii unui element se termin procesul, i se genereaz o eroare pentru client.
Datele binare sunt codate cu Base64, i mpreun cu alte informaii i delimitatori, sunt
stocate n variabile de tip std::string. Se adaug o semntur digital, i se trimit datele.
Sistemul trece n starea final, elibernd memoria.
Dac se solicit o autentificare cu certificat, sistemul trece din starea 1 n starea 5. Se
genereaz un nonce, i se trimite clientului ntr-un mesaj de acceptare a conexiunii. Sistemul
intr iar n starea 1, pn la recepionarea unui alt mesaj, care l pune n starea 6. Se decodeaz
certificatul primit, datele binare sunt stocate n obiecte XByteSequence. Clientul a re-trimis
nonce-ul semnat digital, iar pentru verificare se folosete cheia public a clientului extras din
certificat. Verificarea se face utiliznd funcia DigitalSignatureCreator::veritfySignature().
Ca i n pasul anterior, la orice eroare de orice fel, se termin procesul. Pentru verificarea
certificatului primit se folosete certificatul emitentului. Aici se citesc i permisiunile
clientului, i n cazul n care acesta nu are privilegii pentru a accesa resursele serverului, se
genereaz un mesaj de eroare, i se termin conexiunea. Dac nonce-ul se potrivete cu cel
salvat anterior, se genereaz cheia de sesiune, se cripteaz cu cheia secret a clientului i este
codificat cu Base64. Semntura serverului este adugat n mesaj, i este trimis clientului. Un
alt mesaj cu numele utilizatorului i cheia generat se trimite serviciului de resurse. n acest
pas, performana de autentificare este citit i nscris n variabila m_Time, pentru a fi citit la
distrugerea obiectului. Sistemul trece n starea final, i se distruge obiectul.

4.2.2 Serviciul de resurse

Structura i funcionarea acestui serviciu este foarte asemntoare cu cel al serviciului

de autentificare. Clasa XResService motenete clasa XBaseService, iar la acceptarea unei noi
conexiuni, se creeaz o instan a clasei XResSvConnHandler, care motenete clasa

61

XISvConnHandler. Notificrile sunt aceeai, singurul lucru care difer este procesarea
mesajelor.
Serviciul se ocup de distribuirea fiierelor n directoarele partajate. Aceste directoare
pot fi setate prin intermediul funciei setResourceDir() la cel mai nalt nivel, din API. Acesta
va seta membrul m_resDir, care va fi citit de fiecare solicitare a listei. Clientul poate cere lista
cu fiiere, care va conine numele i calea fiierelor, ct i mrimea acestora.
Fiindc aceste informaii sunt trimise criptate, utilizatorii trebuie s se nregistreze
nainte de a solicita orice date. Serviciul de autentificare trimite un mesaj intern, cu serviciul
de resurse ca destinatar. Acest mesaj este trimis cnd un client se autentific cu un certificat,
i se genereaz o cheie secret de sesiune. Mesajul va conine numele utilizatorului, i cheia
generat, care odat recepionat de serviciul de resurse va fi stocat ntr-o structur de tip
std::map. Orice cerere de informaii va conine numele utilizatorului, astfel serviciul ncarc
cheia i o va folosi pentru sesiunea curent. Dac numele utilizatorului este incorect, sau cheia
nu se potrivete, mesajul nu va putea fi decriptat, i se va rspunde cu un mesaj de eroare.
Cnd se primete un mesaj care solicit lista de fiiere, serviciul va parcurge
directoarele recursiv, formnd rspunsul cu toate datele necesare. Dac se cere un fiier, se
verific dac se afl n aceste directoare, i n caz afirmativ, se ncarc n memorie, ntr-un
format std::vector<char>. n ambele cazuri datele sunt criptate i trimise clientului.

Fig. 23 Diagrama de stare a execuiei serviciului de resurse

62

4.3 XClient

Partea de client a unui serviciu se creeaz

motenind clasa XBaseService, care ofer funciile
callback necesare pentru a primi i trimite mesaje.
Funcionarea i structura sunt descrie n seciunea
anterioar. n Fig. 24 este prezentat diagrama de stare a
clasei XClient.
Constructorul

componentei

XClient

are

parametrii, acestea fiind numele de utilizator i parola.

Aceste date se vor folosi numai pentru identificarea
utilizatorului de ctre client, pentru a ncrca certificatul
potrivit, iar n cazul n care aceste nu se gsete,
informaiile vor fi folosite pentru a solicita un certificat. Fig. 24 Diagram de stare: XClient
Datele private se pot schimba pe parcurs. XClient este controlat prin funciile din API-ul
global. Majoritatea funciilor urmresc strile prezentate n Fig. 25, adic se trimite
solicitarea, se ateapt un rspuns, i se genereaz rezultatul funciei, fie datele cerute, fie un
mesaj de eroare. Unele proceduri se pot efectua fr conectarea la un server. Acestea sunt:

getServerList(): Se genereaz i se trimite un mesaj ctre serviciul de autentificare

a home serverului, care cere lista serverilor din reea. Dup trimitere se ateapt un
rspuns de la server. Ateptarea rspunsului are un timeout de cteva secunde,
dac nu se primete se genereaz o eroare. Ultima eroare se salveaz n variabila
global m_errMsg. La recepionarea unui mesaj, se creeaz un std::vector care
conine structuri cu informaiile serverilor.

switchUser(): Se folosete n cazul n care se dorete schimbarea utilizatorului.

Dac clientul a fost conectat la un server, acesta va fi deconectat. Practic se reiniializeaz toate datele.

writeFile(): Funcia scrie un buffer din memorie pe un dispozitiv de stocare fizic

folosind funcia std::ofstream::write().

pingServer(): Simuleaz un ping, adic trimite un mesaj scurt serverului i

msoar timpul ntre trimitere i primire rspuns. Rezultatul va fi diferena ntre
cele dou timpuri.

getLastErrorMessage(): Returneaz coninutul variabilei m_errMsg, care conine

un mesaj care descrie ultima eroare raportat.
63

Connect(): Funcia ia ca parametru adresa serverului la care se dorete conexiunea,

i o variabil care va stoca timpul de conectare. Conectare n acest caz nseamn
autentificare, fie prin parol, fie prin certificat. Se ncepe cu crearea directorului cu
certificate i chei, dac acesta nu exist. Se verific dac exist vreun certificat i
cheie pe acest nume de utilizator. Dac exist, se ncepe verificarea validitii cu
ajutorul clasei CertificateChecker::VerifyCertificate(). n cazul n care certificatul
sau cheia secret nu sunt valide, se verific certificatul home serverului. Dac
acesta nu este salvat local, se solicit de la server, i se ateapt un rspuns. Dac
nu s-a primit nici un rspuns, se genereaz o eroare. Diagrama de stare este
prezentat n Fig. 25. Odat avnd certificatul serverului n posesie, ncepe
protocolul de autentificare. La sfritul cu succes al acestui protocol, clientul va
avea un certificat valid. Acesta va fi stocat n variabila global cert_X509, iar cheia
secret n variabila cert_sk. Aceste dou obiecte vor fi scris n fiiere folosind
funciile

oferite

de

API-ul

OpenSSL:

PEM_write_PrivateKey

PEM_write_PrivateKey. Avnd certificatul se contacteaz serviciul de resurse, i

se primete o cheie de sesiune, conform protocolului descris anterior. Cheia este
verificat la fiecare solicitare de resurse, iar dac nu este valid, se genereaz o
eroare, notificnd utilizatorul c o reconectare este necesar.

Urmtoarele funcii se pot apela dup autentificare la serverul de resurse:

getFileList(): Prima dat se verific dac utilizatorul este autentificat, i dac are o
cheie valid. Se solicit lista de fiiere dup modelul prezentat n Fig. 25. Datele
recepionate sunt decriptate, se parcurge lista, i se adaug fiierele unul cte unul
n vectorul specificat de client.

requestFile(): Dup verificarea cheii de sesiune, se creeaz un serviciu pe partea

clientului, care se va conecta la server. Se solicit fiierul i se trece n stare de
ateptare. Dac se primete rspuns, se decripteaz i se copiaz coninutul
fiierului n bufferul specificat de utilizator de tip std::vector<char>.

getCertificate(): La conectare la unul dintre serverele din reea, certificatele sunt

stocate n memorie i n fiiere. Aceste certificate sunt folosite automat, dar pentru
le a afia, se poate apela aceast funcie, care returneaz unul dintre trei certificate
ntr-o form decodat. Se folosete o funcie OpenSSL X509_print() pentru a copia
coninutul ntr-un ir de caractere care va fi returnat.

64

Fig. 25 Diagrama de stare a execuiei cererilor de tip request-response

4.4 Implementarea API-ului

Interfaa de programare ofer proiectarea unui sistem descris n aceast lucrare cu

uurin, prin interfaa descris n seciunea 3.3. Interfaa grafic a clientului a fost creat cu
ajutorul framework-ului Qt [27], implementnd funciile din interfa pentru a crea serviciile
i a interaciona cu serverul. n Fig. 26 se poate vedea o captur de ecran a interfeei de
utilizator a clientului, dup pornire, afind lista cu servere, controale pentru remprosptare
list, verificare disponibilitate server i conectare.

65

Fig. 26 GUI client: Lista cu servere

Dup conectare se afieaz lista cu fiiere disponibile i detalii despre acestea. Clientul
permite salvarea fiierelor unul cte unul, salvarea tuturor fiierelor, sau doar deschiderea
fiierelor suportate. Qt suport mai multe tipuri de imagini, iar modulul Phonon suport i
clipuri video. Pentru a afia certificatele folosite pentru aceast sesiune se navigheaz pe
pagina Certificates, unde se pot solicita toate trei certificate. Pagina Activity Log ine o
eviden cu toate evenimentele din sesiunea curent, iar navignd pe pagina Switch User, se
poate schimba utilizatorul curent. Interfaa grafic, cu lista de fiierele i o imagine deschis
se poate vedea n Fig. 27.

66

Fig. 27 GUI client: lista cu fiiere

Serverul are doar interfa consol, i afieaz evenimentele importante, care includ:
conectarea unui client, solicitrile de ctre ali participani, deconectarea clienilor, etc.
Serverul ine o eviden a tuturor clienilor conectai i timpul de conectare a acestora ntr-un
fiier local. Interfaa serverului se poate vedea n Fig. 28.

67

Fig. 28 Interfaa consol a serverului

68

Rezultate experimentale

Testele au fost efectuate pe un calculator rulnd sistemul de operare Windows XP

SP3, procesor dual core cu frecvena 2800 MHz.
n Fig. 29 se vd timpii de autentificare pentru mai muli clieni simultan. Timpul
msurat a fost intervalul dintre trimiterea cererii de autentificare pn la recepionarea cheii de
sesiune de la serverul de resurse. Se observ diferena ntre cele dou autentificri, care este
produs de generarea certificatului i paii adiionali pentru trimiterea acestuia. Dac
conectarea se face la un server liber, performanele sunt bune, ajungnd la 130 ms pentru
autentificare fr certificat i 270 ms cu certificat. Performana scade dac mai muli clieni se
autentific n acelai timp, ajungnd la 607 / 1266 ms la 10 clieni simultan. Pentru a
mbuntii performana unui server populat, se poate aduga un alt server pentru a distribui
autentificarea clienilor.

69

Fig. 29 Timp de autentificare cu i fr generare de certificat

n Fig. 30 se vede timpul de generare a cheilor RSA. Aceast operaie necesit cele mai
multe resurse ale procesorului. Generarea unei chei dureaz aproximativ 80 ms, ajungnd la
aproape 600 ms la 10 generri de chei n paralel. Fiindc acest proces se bazeaz mai mult pe
puterea de procesare a procesorului, cea mai evident metod de a mbuntii timpul de
generare este de a folosi un procesor mai puternic. O alta metod ar fi folosirea unui procesor
dedicat doar pentru generare de chei, proiectat n special pentru aceast operaie.

70

Fig. 30 Timp de generare a cheilor RSA

Timpul de autentificare este afectat i de starea serverului, adic dac este inactiv, doar
ateptnd conexiuni, sau dac se afl in cursul procesrii datelor. n Fig. 31 se vede diferena
dintre aceste dou stri. Serverul la care s-a msurat autentificarea, cripteaz i transmite date
la ali doi clieni deja conectai. Timpul de autentificarea n acest caz crete cu 10% n cazul
autentificrii fr generare certificat, i cu aproximativ 25% dac se genereaz i certificat
pentru client.

71

Fig. 31 Timpul de autentificare la un server activ

Pentru a analiza performana autentificrii, am msurat fiecare pas al protocolului

separat. Pe partea serverului, cum era de ateptat, generarea certificatului necesit cel mai
mult timp de procesare, 45 ms. Cum s-a mai menionat acesta s-ar putea mbuntii daca am
folosi un dispozitiv dedicat pentru generarea cheilor. Generarea nonce-ului dureaz
aproximativ 4 ms, ceea ce e acceptabil. Totui pentru a genera numere aleatorii ct mai sigure,
se poate nlocui si acesta cu un dispozitiv dedicat care genereaz nonce-uri. n Fig. 32 se pot
vedea durata de execuie a fiecrui pas din protocol.

72

Fig. 32 Timpul de execuie a protocoalelor pe partea serverului

Pe partea clientului, protocoalele au un pas n plus, adic ncrcarea certificatelor i a

cheilor, ceea ce intr la categoria iniializare. Acesta necesit cel mai lung timp de completare,
aproximativ 35 ms. Restul protocolului se desfoar relativ ntr-un timp scurt. Aceste
msurtori nu includ transportul de date, doar procesarea datelor. Protocolul descompus i
durata de execuie a fiecrei pas se poate vedea n Fig. 33.

Fig. 33 Timpul de execuie a protocoalelor pe partea clientului

73

n Tabelul 2 sunt msurate autentificarea cu i fr certificat, i descrcarea datelor de

la servere amplasate n diferite locaii externe. Rezultatele, evident, nu arat performana
sistemului, fiindc cel mai mare factor aici a avut limea de band i distana dintre client i
server. Totui au avut un rol important pentru a testa sistemul ntr-un mediu real, unde s-a
comportat conform ateptrilor. Cel mai important lucru, care depinde mai puin de viteza de
transfer, i este efectuat mai des, este autentificarea. La autentificare fr certificat deja se
observ influena distanei, dar la cel cu certificat se efectueaz ntr-un timp acceptabil,
permind navigarea ntre servere chiar i la distane de mii de kilometrii.
Tabel 2 Performana sistemului
Autentificare

Autentificare

Descrcare

Descrcare

Descrcare

fr certificat

cu certificat

date (50KB)

date (500KB)

date (6MB)

Local

270 ms

127 ms

61 ms

406 ms

11646 ms

LAN

392 ms

131 ms

73 ms

443 ms

11947 ms

Cluj Napoca,

478 ms

158 ms

85 ms

475 ms

12005 ms

Ljubljana, Slovenia

914 ms

359 ms

415 ms

3901 ms

39123 ms

Aarhus, Danemarca

678 ms

310 ms

414 ms

1178 ms

13102 ms

Islamabad, Pakistan

3916 ms

1681 ms

8818 ms

87167 ms

Wichita, Kansas,

1968 ms

814 ms

492 ms

4416 ms

36926 ms

Timp
Locaie server

Romnia

SUA

74

Concluzii

Sistemul prezentat ofer dezvoltatorilor o interfa cu ajutorul crei implementarea

unei aplicaii distribuite pe reea se face cu uurin. Sistemul a fost proiectat pentru a oferi
sigurana necesar pentru transportul datelor confideniale ntr-un mediu nesecurizat,
suportnd pierderea mesajelor, generarea cheilor i a certificatelor. Canalele securizate sunt
create pe linii de transmisiune normale, cu ajutorul celei mai avansate tehnici de criptografie,
i prin folosirea protocoalelor de securitate re-proiectate. Protocoalele necesit mult putere
de procesare, dar arhitectura distribuit a serviciilor garanteaz acesta.
Arhitectura sistemului elimin serverul central de autentificare, nlocuindu-l cu
serviciul de autentificare, care ruleaz pe fiecare server, distribuind astfel ncrcarea.
nregistrarea utilizatorilor poate lua orice form, oferind flexibilitate i mai mult securitate.
Permisiunile utilizatorilor sunt disponibile fiecrui server la care se conecteaz, acesta avnd
controlul asupra accesului la diferite resurse. Navigarea ntre serverele reelei se face cu
uurin, acesta fiind meritul mecanismului Single Sign-On, care elimin necesitatea reautentificrii la fiecare furnizor de servicii, i a protocoalelor de securitate proiectate astfel
nct aceste autentificri s se efectueze n cel mai scurt timp posibil, ajungnd chiar i la
timpuri de 100 ms. Distribuirea serviciilor de autentificare i de resurse permite scalarea
sistemului cu uurin, adaptndu-se nevoilor utilizatorilor.
Platforma fiind dezvoltat dup principiile ingineriei programrii bazate pe
componente este robust, adaptabil i uor de actualizat. Orice component poate fi foarte
uor nlocuit cu o alta cu condiia ca interfaa s nu se modifice sau dac trebuie aduse
75

modificri n funcionalitatea unei componente acestea se pot face cu un minim de efort. n

plus componentele pot fi refolosite i la dezvoltarea altor sisteme. Componentele fiind
ncapsulate, adic structura intern este ascuns i serviciile sunt oferite printr-o interfa bine
definit, face ca programatorul s le poat integra mai uor fr s tie cum funcioneaz
acestea.
Noutatea platformei mele const n folosirea componentelor XPCOM, care permite
dezvoltarea aplicaiilor portabile. Folosind platforma Mozilla i API-ul NSPR pentru
implementare, aplicaiile pot rula pe cele trei sisteme mari de operare existente: Microsoft
Windows, Linux i Mac OS, dar i pe cele mobile, sau oricare unde Mozilla este disponibil.
Soluia propus pentru sistemul de autentificare este distribuit, dar totui s-ar putea
ivi probleme n cazul n care un numr mare de utilizatori vor s se conecteze n acelai
timp. Pentru distribuirea autentificrii se poate implementa n viitor un serviciu de balansare
care s comunice cu fiecare server i s repartizeze clienii la serverele mai puin ncrcate,
sporind astfel performana sistemului. Alte mbuntiri ar fi implementarea unui serviciu de
nume mai performant.

Bibliografie

[1] Marian Nica, Tehnici de autentificare, http://itsecure.wordpress.com [Interactiv], 2007

[2] Butler Lampson, Martn Abadi, Michael Burrows, Edward Wobber. Authentication in
Distributed Systems: Theory and Practice. s.l. : ACM Trans. Computer Systems 10, 1992
[3] Freier, A., O., Karlton, P., Kocher, P., C. The SSL Protocol, Version 3.0, draft-ietf-tlssslversion3-00.txt, Internet-Draft. s.l., Transport Layer Security Working Group,
noiembrie 1996
[4] Dierks T., Allen C., The TLS Protocol, Version 1.0, Request for Comments: 2246. s.l. :
Network Working Group, ianuarie 1999
[5] Joshua D. Guttman, F. Javier Thayer Fabrega, Authentication tests and the structure of
bundles, Theoretical Computer Science, Vol. 283, No. 2, pages 333-380., iunie 2002
[6] Guttman, Joshua D., Security Protocol Design Via Authentication Tests. s.l. : In
Proceedings of the 15th IEEE Computer Security Foundations Workshop, IEEE CS
Press, iunie 2002
76

[7] Project, OpenSSL., available at http://www.openssl.org/ [Interactiv], 2008

[8] L. Hunter, Active Directory User Guide, Springer-Verlag, 2005
[9] R. Killpack, eDirectory Field Guide, Springer-Verlag, 2006
[10] OpenLDAP, versiunea 2.4.15., http://www.openldap.org/ [Interactiv], 2008
[11]

Corporation,

Mozilla.,

XPCOM,

Cross

Platform

Component

Model,

http://www.mozilla.org/projects/xpcom, 2008
[12]

AES

Algorithm

(Rijndael)

Information,

http://csrc.nist.gov/archive/aes/rijndael

[Interactiv], 28 februarie, 2001

[13] Ronald L. Rivest, Adi Shamir, Leonard M. Adleman, Communications of the ACM,
21(2):120-126., februarie 1978
[14] W. Stallings, Cryptography and Network Security, 4th edition, Prentice Hall. ISBN 0-13187319-3., 2005
[15] A. Menezes, P. van Oorschot, S. Vanstone, Handbook of Applied Cryptography, CRC
Press, ISBN: 0-8493-8523-7, octombrie 1996
[16] M. Abadi, R. Needham, Prudent Engineering Practice for Cryptographic Protocols,
DEC SRC Research Report 125, pag 1 22., 1994
[17] J. D. Guttman, Security Protocol Design via Authentication Tests. 11 aprilie, 2002
[18] J. D. Guttman, Security goals: Packet trajectories and strand spaces. In R. Gorrieri and
R. Focardi, editors, Foundations of Security Analysis and Design, volume 2171 of LNCS.
. s.l. : Springer Verlag, 2001
[19] J.D. Guttman, F.J. Thayer Fabrega, Protocol independence through disjoint encryption,
Proceedings of the 13th IEEE Computer Security, pag. 24-34. s.l. : Foundations
Workshop, Cambridge, 2000
[20] B. Genge, I. Ignat, Verifying the independence of security protocols, pag 155-163. s.l. : ,
IEEE International Conference on Intelligent Computer Comumunication and
Processings, 2007
[21] E. Gerck, Overview of Certification Systems: X.509, PKIX, CA, PGP & SKIP. s.l. : ISSN
1530-048X, 2000
[22] A. Pashalidis, C. J. Mitchell, A Taxonomy of Single Sign-On Systems, Volume 2727/2003.
s.l. : Springer Berlin / Heidelberg, 2003
[23] C. Szyperski, Component Software Beyond Object Oriented Programming, 2nd edition,
Addison Wesley, pag. 3 47., 2002
[24] J. Bloch, How to Design a Good API and Why it Matters, noiembrie 2006

77

[25]

Joint

Technical

Standardization;

Committee

and

ISO/IEC

International

JTCI;

International

Electrotechnical

Organization

Commission.

for

Programming

Languages C++. s.l. : Geneva, Switzerland: ISO/IEC, 1998

[26] S. Josefsson, The Base16, Base32, and Base64 Data Encodings, octombrie 2006
[27] Qt, versiunea 4.5, http://www.qtsoftware.com/products [Interactiv], 2009

78