1

Curs 5-8

Autentificarea mesajelor

Autentificarea mesajelor este un mecanism prin care destinatarul unui mesaj poate

verifica faptul că autorul mesajului este o anumită entitate și că mesajul nu a fost modificat de

altcineva. Pentru autentificarea unui mesaj se aplică asupra mesajului primit un test de

autenticitate. Un asemenea test trebuie să asigure faptul că orice mesaj autentic va trece testul

respectiv și că probabilitatea ca un mesaj neautentic, produs cu un efort computațional

rezonabil, să treacă testul este foarte mică.

Există două nivele distincte de "spargere" a unui test de autenticitate:

fals existent (engl. existential forgery) - posibilitatea ca un adversar să genereze un mesaj neautentic care să treacă testul de autenticitate;

fals ales (engl. choosen forgery) - în plus față de falsul existent, conținutul mesajului neautentic este (total sau în mare parte) la alegerea adversarului.

În studiul metodelor de autentificare a mesajelor se presupune că mesajul de transmis nu

este secret deoarece în practică apare frecvent necesitatea ca un mesaj public să poată fi testat

de oricine în privintă autenticității (de exemplu, în cazul unui anunț public, un cetățean ar

trebui să poată verifica dacă textul respectiv este textul autentic emis de autoritatea abilitată).

Metodele de asigurare a confidențialității se separă de obicei de metodele de control a

autenticității, deoarece doar informațiile pentru asigurarea confidențialității nu asigură o

garanție privind autenticitatea mesajului (de exemplu, pentru unele metode de criptare un

adversar poate opera modificări asupra textului cifrat cu efecte previzibile asupra textului clar,

chiar dacă nu cunoaște efectiv textul clar). Așadar, pentru autentificare sunt necesare unele

informații suplimentare care de obicei se transmit pe canale sigure (ca exemplu practic, un

canalul nesigur este Internet-ul, iar un canalul sigur dar cu capacitate foarte redusă este un

bilet scris sau o convorbire telefonică). În asigurarea autenticității, un rol foarte important este

jucat de funcțiile de dispersie criptografică (engl. hash function). În sens matematic, funcțiile

hash sunt funcții definite pe o mulțime cu multe elemente (posibil infinită) cu valori într-o

mulțime cu un număr fix și mai redus de elemente. Funcțiile hash nu sunt inversabile. Pe

lângă aplicațiile în domeniul criptografiei, aceste funcții mai sunt folosite pentru a accelera

căutările în tabele cu multe date sau pentru comparări de date. În cazul nostru, o funcție de

dispersie va asocia unui șir de biți de lungime oricât de mare, o valoare întreagă într-un

interval dat de forma (sau echivalent, un șir de biți de lungime ), satisfăcând condiția că, pentru șirurile care apar în problema unde se folosește funcția de dispersie, două șiruri

distincte să nu aibă aceeași valoare a funcției de dispersie cu probabilitate semnificativ mai

mare de . O funcție hash poate lega două sau mai multe chei de la aceeași valoare hash. În multe aplicații, este de dorit minimalizarea șansei apariției unor astfel de coliziuni, ceea ce

înseamnă că funcția hash trebuie să lege cheile de valorile hash cât mai uniform posibil. De

asemenea, în funcție de aplicație, alte proprietăți pot fi necesare. Deși ideea a fost concepută

în anii 1950, proiectarea optimă a funcțiilor hash este încă un subiect activ de cercetare și

http://ro.wikipedia.org/wiki/Matematic%C4%83

2

discuție. Funcțiile hash sunt utilizate și ca sume de control sau funcții hash criptografice, dar

nu trebuie confundate cu caracterele de verificare, amprentele numerice, funcțiile de

randomizare, codurile de corectare a erorilor. Deși aceste concepte se suprapun într-o oarecare

măsură, fiecare are propriile sale utilizări și cerințele și este proiectat și optimizat în mod

diferit.

Față de o funcție de dispersie, o funcție de dispersie criptografică are anumite

proprietăți suplimentare, și anume:

rezistentă la preimagine (preimage resistence) - dacă se cunoaște , să fie dificil de regăsit (dificultatea să se păstreze chiar în cazul cunoașterii unei părți din );

rezistentă la a doua preimagine (second preimage resistence) - dacă se cunoaște un șir

, să fie dificil de găsit un alt șir , cu ; rezistentă la coliziuni (collision resistence) - să fie dificil de găsit două șiruri și

cu . Pentru ca o funcție să satisfacă aceste condiții (pentru a rezista atacurilor prin forță brută)

trebuie ca numărul de biți ai dispersiei să fie suficient de mare (minim 128).

Principalele funcții de dispersie sunt:

MD5 - creată de Ronald Rivest în 1991, este una dintre cele mai raspandite. Lucrează cu

șiruri de biți de lungime 128. Recent au fost descoperite o serie de slăbiciuni ale acesteia.

SHA1 - a fost dezvoltată de NSA (National Security Agency, SUA). Lucrează cu șiruri

de biți de lungime 160. Până în acest moment s-a dovedit a fi mai sigură decât MD5.

RIPEMD-160 - dezvoltată la Katholieke Universiteit Leuven în 1996. Lucrează cu șiruri

de biți de lungime 160.

Ca și mod de lucru, emițătorul unui mesaj calculează , transmite prin canalul principal și transmite prin canalul sigur. La destinație se va verifica de către receptor dacă . În baza proprietăților funcției este greu (daca nu chiar imposibil) ca un adversar să modifice în , cu pentru a păcăli receptorul.

Pentru sporirea securității se utilizează și funcții de dispersie cu cheie (keyed hash

function), numită și MAC (message authentication code), o asemenea funcție fiind o funcție

de dispersie parametrizată cu o cheie , având proprietatea că, pentru cineva care nu cunoaște dinainte cheia , este nefezabil computațional să obțină o (nouă) pereche în care , chiar dacă cunoaște un număr de perechi cu . Pentru a utiliza o funcție de dispersie cu cheie, mai întâi, emițătorul și receptorul se înțeleg asupra unei

chei secrete , apoi, la trimiterea unui mesaj , emițătorul calculează și trimite perechea . Receptorul testează dacă .

Ca și cale de atac pentru autentificările prin dispersie cu cheie putem aminti atacul prin

reflexie, eficient când se utilizează aceeași cheie pentru autentificarea ambelor sensuri de

comunicație. Dacă spre exemplu Alice dorește să comunice cu Bob și ei stabilesc cheia de

dispersie , un adversar activ poate intercepta un mesaj trimis de Alice către Bob și să-l trimită înapoi lui Alice. Dacă aceeași cheie este utilizată pentru autentificarea ambelor sensuri de comunicație și dacă mesajele au același format, atunci Alice acceptă mesajul ca

venind de la Bob. Pentru prevenirea unui asemenea atac, există două soluții:

utilizarea de chei distincte pentru cele două sensuri;

trecerea numelui entității emițătoare în mesaj.

http://ro.wikipedia.org/w/index.php?title=Sum%C4%83_de_control&action=edit&redlink=1http://ro.wikipedia.org/wiki/Coduri_corectoare_de_erori

3

Pentru a rezista atacurilor prin forță brută, se impune ca atât dimensiunea cheii cât și cea

a dispersiei să fie de minim 64 de biți, preferabil 80 de biți.

Exemplu de construcție a unei funcții de dispersie cu cheie pornind de la funcții de

dispersie rezistente la coliziuni și rezistente la preimagine (conform [RFC 2104, 1997]):

( )

unde:

- reprezintă concatenarea;

- este operația sau exclusiv;

hash - este funcția de dispersie criptografică (de exemplu sau );

- este cheia completată la o lungime aleasă în funcție de anumite particularități ale funcției de dispersie de la bază (pentru și , se ia de 64 de octeți);

, - sunt șiruri obținute prin repetarea de ori a octetului cu valoarea (hexa) 36, respectiv 5C.

Pentru micșorarea cantității de informație pusă la dispoziția adversarului, rezultatul unei

funcții hash se poate trunchia la lungime mai mică (o funcție de dispersie hash dă 128-160

biți, iar pentru o dispersie cu cheie sunt suficienți 64-80 de biți).

O construcție similară dispersiei cu cheie este semnătura digitală, aceasta din urmă

utilizând chei diferite pentru crearea respectiv verificarea dispersiei(numită, în acest caz,

semnătură). Fiind o construcție asimetrică, relația dintre semnătura digitală și dispersia cu

cheie este similară cu cea dintre criptografia asimetrică și criptografia simetrică.

Ca și mod de lucru, autorul de mesaje semnate generează cu un algoritm specific o

pereche de chei ( -cheia secretă sau cheia de semnătură, -cheia publică sau cheia de verificare) și transmite cheia publică receptorului, prin utilizarea unui canal sigur, astfel încât cheia să nu poată fi modificată în timpul transmisiei. Apoi, folosind funcția de semnare

se crează semnătura și transmite perechea . Utilizând funcția de

verificare , receptorul verifică dacă =true.

Întrucât semnătura depinde și de mesajul de semnat și de semnatarul acestuia (prin cheia ), o semnătură nu poate fi tăiată de pe un mesaj și plasată pe alt mesaj. Pentru a crea mai multe semnături valide pentru un același mesaj se poate folosi pentru funcția de

semnătură un număr aleator ca al treilea argument.

Exemplu de construcție a unei semnături în care criptarea este bijectivă (pe baza RSA):

,

.

Deși calcularea lui fără cunoașterea lui este aproape imposibilă,

construcția anterioară permite totuși adversarului să producă un fals prinalegerea unui în mod aleator și prin calcularea valorii . Pentru eliminarea acestui inconvenient,

nu se va aplica direct asupra lui ci asupra unei dispersii rezistente la preimagine și la coliziuni a lui . Metoda aceasta are două avantaje, pe de o parte că algoritmul de criptare asimetric, lent, se aplică asupra dispersiei și nu asupra întregului mesaj (dispersia se

calculează mai repede decât criptarea asimetrică), iar pe de altă parte se împiedică falsul

4

existent deoarece chiar dacă adversarul calculează nu poate găsi un mesaj cu

dispersia astfel fixată.

Prin intermediul semnăturii digitale este asigură atât autentificarea mesajelor cât și

nonrepudiabilitatea acestora deoarece cheia de semnătură este cunoscută doar de către

emițător, ceea ce face ca prezența unei semnături verificabile să garanteze că mesajul a fost

produs de emițător.

O altă problemă importantă în privința securității datelor este verificarea prospețimii

mesajelor primite, adică necesitatea de a distinge un mesaj (autentic) "nou" de o copie a unui

mesaj mai vechi (ex. în cazul transferului unei sume de bani dintr-un cont în altul, este

necesar ca destinatarul să accepte mesajul doar o singură dată). Dificultatea în privința

verificării prospețimii constă în faptul că o copie a unui mesaj "vechi" este identică cu

originalul din momentul când acesta era "nou", ceea ce face ca un test de autenticitate să nu

detecteze vechimea mesajului. Ca soluíe a problemei, se introduce în mesajul autentificat un

"identificator de mesaj" care va fi diferit de la un mesaj la altul și asupra căruia să se execute

testul de prospețime. Un astfel de element se numește număr unic. Ca și număr unic se poate

folosi un număr de ordine, ora curentă sau un număr aleator ales de receptor. În cazul

numărului de ordine, atât emițătorul cât și receptorul țin evidența numărului de ordine pentru

fiecare mesaj, un mesaj fiind acceptat de receptor doar daca numărul trecut în mesaj (de

emițător) coincide cu numărul curent de ordine. Metoda aceasta are două neajunsuri: necesită

menținerea pe termen lung a numerelor de ordine curente și necesită un contor separat de

număr de ordine pentru fiecare partener de comunicație. Dacă se folosește ca număr unic ora

curentă, emițătorul scrie în mesaj ora curentă, receptorul considerând mesajul proaspăt dacă

ora din mesaj coincide cu ora curentă a receptorului. În cazul acesta receptorul trebuie să

accepte un decalaj de cel puțin câteva zecimi de secundă deoarece ceasurile nu sunt

întotdeauna perfect sincronizate iar transportul mesajului nu se poate realiza instantaneu.

Acest aspect este principala problemă a utilizării orei curente ca număr unic, deoarece în

interiorul acestui decalaj admis, adversarul poate trimite copii ale mesajului, copii ce vor fi

acceptate ca proaspete de destinatar. Această problemă poate fi corectată dacă emițătorul va

asigura ca două mesaje distincte să aibă numărul unic distinct (fie rezoluția marcajului de

timp se face mai fină decât timpul necesar emiterii unui mesaj, fie emițătorul mai ține un

contor care se incrementează la fiecare mesaj trimis și făcut astfel încât să nu se reseteze

înainte ca marcajul de timp să treacă la următoarea valoare). Utilizarea orei la verificarea

prospețimii necesită și un mecanism sigur care să mențină sincronizate ceasurilor

dispozitivelor care comunică. Utilizarea unui număr aleator ca număr unic se realizează prin

generarea de către receptor a unui număr aleator ce trebuie să aibă cel puțin 64{80 biți (pentru

a nu se repeta) și să nu poată fi prezis de către adversar, număr care se adaugă de emițător la

mesajul trimis. Mesajul va fi acceptat ca "nou" de către receptor doar dacă numărul aleator din

mesaj coincide cu numărul aleator trimis anterior. Nu este necesar ca acest număr să fie inclus

efectiv ăn mesaj, fiind suficientă participarea acestuia la calculul semnăturii mesajului.

Principalul inconvenient al acestei metode este acela că este necesar transferul numărului

aleator dinspre receptor spre emițător ( implică și faptul că receptorul trebuie să știe că

urmează să primească un mesaj). Acest lucru necesită adesea încă un mesaj, lucru care face

aplicarea metodei costisitoare, și în anumite cazuri imposibilă (de exemplu, metoda nu este

aplicabilă pentru securizarea poștei electronice sau pentru protocoale de difuziune-broadcast).

În cazul unui schimb de mai multe mesaje, de exemplu o sesiune ssh, se poate combina

numărul aleator cu un număr de ordine. La deschiderea conexiunii, receptorul trimite numărul

aleator, emițătorul include în fiecare pachet al conexiunii numărul aleator primit la

deschiderea conexiunii și numărul de ordine al pachetului.

5

În practică, criptarea, autentificarea și verificarea prospețimii nu sunt activități care se

execută separat, de cele mai multe ori acestea fiind combinate.

Verificarea prospețimii unui mesaj se face pe baza unui număr unic inclus în mesaj,

număr unic pe care receptorul îl verifică la primirea mesajului. Dacă numărul unic are o

singură valoare validă, se poate conveni că numărul nu se transmite efectiv, însă dispersia sau

semnătura se calculează ca și când numărul ar fi parte a mesajului. Combinarea criptării cu

autentificarea se poate face în mai multe moduri. O modalitate ar fi aceea în care se calculează

întâi semnătura sau dispersia, iar apoi se criptează rezultatul concatenării datelor utile cu

dispersia sau semnătura. O altă metodă constă în criptarea mai întâi a mesajului urmată de

calculul dispersiei sau semnăturii mesajului criptat. Pentru această metodă, este necesar ca

pentru semnătură sau dispersie să nu se utilizeze decât o singură cheie de criptare, în caz

contrar apărând vulnerabilități de tip fals existent. Ultima metodă de combinare a criptării cu

autentificarea constă în criptarea doar a textului clar, iar apoi la textul cifrat rezultat se adaugă

semnătura sau dispersia textului clar. Dacă autentificarea se face prin dispersie cu cheie,

metoda nu prezintă vulnerabilități (în caz contrar, se poate arăta că funcția de dispersie este

vulnerabilă la fals existent). Acest mod de combinare a criptării cu dispersia cu cheie este

utilizat de protocolul ssh versiunea 2. Dacă autentificarea se face prin semnătură digitală,

metoda nu este corectă deoarece permite unui adversar care bănuiește textul clar să verifice

dacă textul clar este cel bănuit de el.

Intrebări de verificare

Cum se face autentificarea mesajelor?

Ce este o funcţie de dispersie criptografică?

Ce este semnatura digitală?

Cum se poate verifica prospeţimea unui mesaj?

Stabilirea cheilor

În cursurile anterioare s-a vorbit despre alegerea cheilor de către partenerii de

comunicație fără a preciza modul în care se realizează acest lucru. Cerințele de generare a

cheilor diferă în cazul criptografiei simetrice de cel al criptografiei asimetrice.

În primul caz, cheile se numesc chei simetrice, iar un protocol de stabilire pentru acestea

trebuie să îndeplinească următoarele cerințe:

autentificarea cheilor - cheia să nu poată fi cunoscută de altcineva decât de entitățile ce doresc să comunice;

cheia să fie nouă (chei mai vechi ar putea fi cunoscute de eventuali adversari);

confirmarea cheii - fiecare entitate ce comunică să aibă confirmarea că partenerul de comunicație a primit efectiv cheia .

Există posibilitatea ca să nu se prevadă confirmarea cheii ca parte a protocolului de

stabilire a cheii, dacă spre exemplu a doua entitate fie nu are nevoie să o autentifice pe prima

(de exemplu, a doua entitate este un server public), fie utilizează un mecanism de autentificare

al utilizatorilor.

6

În cazul criptografiei asimetrice avem chei publice. În cazul acestora, spre deosebire de

cazul cheilor simetrice, unde transmisia unei chei între partenerii de comunicație se face doar

pentru o cheie proaspăt generată, se întâmplă frecvent ca o aceeași cheie să fie transmisă de

mai multe ori către o aceeași entitate. Certificarea unei chei publice necesită următoarele:

receptorul trebuie să poată verifica dacă cheia primită este autentică (dacă este cheia partenerului de comunicație);

receptorul trebuie să poată verifica dacă cheia mai este validă (o cheie publică trebuie să poată fi invalidată dacă se suspectează că a fost compromisă cheia secretă

corespunzătoare).

Pentru stabilirea cheilor (simetrice sau publice) sunt necesare mecanisme de securizare a

comunicației (criptare și autentificare) deoarece prezența unui adversar este posibilă chiar în

această etapă a comunicării, principala problemă fiind aceea că între cele două entități nu

există încă un canal sigur de comunicare. În această situație o comunicație securizată se poate

realiza prin intermediul unui terț de încredere (care să poată deja comunica securizat cu

fiecare din primele două și care să prezinte încredere acestora) sau prin intermediul unui

utilizator uman. Cheile odată generate pot fi:

chei efemere (ephemeral key) sau chei de sesiune, utilizate pentru o perioadă scurtă, de exemplu pe durata unei conexiuni sau pentru a cripta un singur mesaj, fiind

distruse imediat după aceea. Cheile efemere sunt chei simetrice;

chei de lungă durată (long-term key), utilizate în cadrul mecanismelor de stabilire sau certificare a cheilor. Cheile de lungă durată pot fi chei simetrice sau chei asimetrice.

Stabilirea cheilor în lipsa unei chei deja existente și în prezența unui adversar pasiv se

poate face prin utilizarea criptografiei asimetrice sau prin alte metode, dintre care cea mai

cunoscută este metoda Difie-Hellman.

Pentru stabilirea unei chei de sesiune între două entități, și , prin criptografie asimetrică, protocolul este următorul:

generează o pereche de chei pentru criptografie asimetrică (cheia secretă este cheia sa de lungă durată);

trimite lui cheia publică a lui ; generează aleator o cheie de sesiune ; trimite lui cheia de sesiune criptată cu cheia publică primită de la ; decriptează cheia transmisă de . Varianta aceasta se poate îmbunătăţi dacă, spre exemplu, pe lângă cheia de lungă durată,

se ia o a doua pereche de chei care să fie regenerată periodic. transmite lui ambele chei publice (cheia de lungă durată și cheia publică proaspătă), iar criptează cheia de sesiune cu cheia proaspătă iar rezultatul îl criptează cu cheia de lungă durată. Avantajul obținut este că

dacă un adversar obține cheia secretă de lungă durată a lui , dar între timp cheia proaspătă a expirat și a fost distrusă, adversarul nu mai poate decripta comunicațiile vechi.

Pentru stabilirea unei chei de sesiune prin metoda Difie-Hellman, protocolul este

următorul:

Se genenerează un număr prim mare și un număr ; alege un număr aleator , calculează și-i transmite lui numărul

; alege un număr aleator , calculează și-i transmite lui numărul

; și calculează cheia de sesiune astfel:

7

(pentru )

(pentru )

Deoarece , cheia de sesiune calculată de cei doi este aceeași. Cunoscând doar , calcularea valorii este foarte dificilă. Avantajul metodei constă în faptul că nu este necesară o cheie de lungă durată, totodată fiind mai rapidă decât regenerarea la fiecare mesaj a unei perechi de

chei pentru un cifru asimetric. Dezavantajul este acela că metoda necesită o comunicație

interactivă, astfel, nefiind aplicabil transmiterii mesajelor prin poștă electronică.

Metodele de mai sus nu sunt eficiente în prezența unui adversar activ deoarece există

pericolul atacului omului din mijloc, descris în continuare. Un asemenea atac constă în

interpunerea unui adversar activ între și , aceștia din urmă crezând că comunică fiecare cu celălalt când de fapt ei comunică cu . În general, comunică cu jucând rolul lui pentru a stabili o cheie de sesiune , comunică cu jucând rolul lui pentru a stabili o cheie de sesiune , apoi decriptează mesajele trimise de lui (acestea fiind criptate cu ), le citește, eventual le modifică, după care le criptează (și eventual le autentifică) utilizând cheia

. Pentru lupta împotriva unor asemenea atacuri, informația se transmite în fragmente, lucru ce împiedică forma pură a atacului man-in-the-middle, însă, pentru ca să-l distingă pe de un adversar este necesar ca să aibă o caracteristică distinctivă inimitabilă. O astfel de caracteristică este cunoașterea unei chei secrete, ceea ce face necesară, pentru o comunicație

sigură, existența unui pas de inițializare în care să se transfere o cheie între cele două entități.

O cale sigură pentru stabilirea cheilor între două entități care încă nu au stabilite chei se poate

face cu ajutorul unui terț de încredere(trusted third party), , în ale cărui servicii au încredere și care partajează chei pentru criptare și autentificare atât cu cât și cu se mai numește server de distribuire a cheilor (Key Distribuțion Center sau KDC).

Dacă presupunem că protocolul de stabilire a cheii este inițiat de către , serverul generează aleator o cheie de sesiune, pe care o transmite lui și lui . Transmisia către este criptată și autentificată cu cheia partajată între și , iar transmisia către este criptată și autentificată cu cheia partajată între și . Deoarece este de presupus că face acest serviciu pentru mai multe entități, pachetele transmise către și trebuie să conțină și numele lor, astfel încât, la primirea pachetului, și să știe cine este partenerul cu care comunică.

Modul descris anterior oferă doar autentificarea cheii și nu verifică și prospețimea

acesteia, ceea ce impune introducerea în mesaje a unor elemente de control al prospețimii. O

primă posibilitate, exploatată de protocolul Kerberos, este adăugarea unei perioade de

valabilitate. O a doua posibilitate, exploatată de protocolul Otway-Rees, se bazează pe numere

aleatoare. Acesta prevede că și transmit către câte un număr aleator, acestea fiind incluse în mesajele corespunzătoare fiecărei entități. și verifică dacă numerele aleatoare incluse în mesajul autentificat de la sunt într-adevăr numerele trimise de ele.

Practic, stabilirea cheilor cu ajutorul unui terț de încredere se face construind un server care crează chei de sesiune, la cerere, pentru toate entitățile din rețea. În rețele mari, nu se

poate lucra cu un singur server, deoarece aceasta ar cere tuturor să aibă încredere în

administratorul serverului. Pentru stabilirea de chei între orice două entități în aceste condiții,

se construiește un sistem astfel:

se configurează mai multe servere de distribuire a cheilor, fiecare entitate având o cheie partajată cu unul dintre aceste servere;

8

se configurează chei partajate între serverele de distribuire a cheilor ce formează legături securizate între servere (graful format de serverele de distribuire a cheilor și

de legăturile securizate trebuie să fie conex).

În acest sistem, în loc să aibă toată lumea încredere într-un singur server, fiecare pereche

de entități care doresc să comunice trebuie să aibă încredere în lanțul de servere ce participă la

stabilirea cheii.

Pentru stabilirea sau certificarea cheilor trebuie să se mai țină seama de:

numărul de chei pe care trebuie să le posede o entitate pentru a putea comunica trebuie să fie cât mai mic;

intervenția manuală în stabilirea cheilor trebuie să fie minimă (cu excepția primului transport al unei chei);

cheile trebuie să poată fi schimbate periodic deoarece cheile de lungă durată pot fi atacate de adversari.

Orice protocol sigur de stabilire a cheilor are nevoie cel puțin o dată de un canal sigur

bazat pe alte mijloace decât cele criptografice. Acest canal este necesar pentru transportul

unei prime chei criptografice, utilizabilă pentru transportul sigur al altor chei. Acest canal

sigur implică întotdeauna intervenția omului, și poate fi reprezentat de: transportul pe un

suport amovibil (dischetă, CD, DVD, memorie flash) sau printr-o legătură ad-hoc securizată

(cablu direct); citirea unei informații de pe sistemul sursă și introducecea acesteia pe sistemul

destinație; inventarea unei parole și introducerea acesteia pe ambele sisteme.

Metoda citirii unei informații de pe sistemul sursă permite transportul unei cantități mici

de informație, totodată fiind greu de aplicat pentru informații secrete, deoarece informația este

afișată pe ecranul sistemului sursă și ca urmare este vizibilă persoanelor din apropiere. Pentru

scrierea informației într-o formă ușor de reținut se poate face apel la diverse "artificii" cum ar

fi împărțirea textului pe grupuri de 4 sau 8 caractere sau, transformarea, în cazul șirului de

biți, într-un șir de cuvinte dintr-un dicționar standard sau într-un șir de silabe ce alcătuiesc

cuvinte, probabil fără sens, dar pronuntăbile.

Pentru metoda introducerii unei parole pe ambele sisteme trebuie avut în vedere ca

parola să fie trecută printr-un "concentrator de entropie" (ex. o funcție de dispersie) înainte de

a fi utilizată ca și cheie și să fie suficient de lungă (și de aleator aleasă) ca să furnizeze efectiv

biții de entropie necesari. O frază în limbaj natural, utilizată pentru derivarea unei chei de 128

biți, trebuie să aibă cam 85 litere (în jur de 20 de cuvinte). Pentru parole, trebuie acordată

atenție tentativelor de spargere, o metodă de protecție fiind blocarea accesului în cazul

încercărilor eșuate în perioade scurte de timp. Ca terminologie, distingem tentative de

spargere off-line, în care adversarul poate verifica dacă o parolă este corectă utilizând doar

echipamentele proprii, și tentative de spargere on-line, în care adversarul contactează serverul

atacat, încercând să deschidă o conexiune cu parola supusă verificării.

Odată stabilite, cheile trebuie autentificate (certificate). Autentificarea este asigurată dacă

cheile au fost stabilite printr-un terț de încredere, însă acest lucru se poate realiza pentru un

număr mic de chei. Ca soluție aplicabilă în rețele mari s-a găsit utilizarea certificatelor. Un

certificat este un ansamblu cuprinzând o cheie publică, un nume de entitate și o semnătură a

9

unui terț pe ansamblul celor două. Terțul semnatar se numește autoritate de certificare. Prin

semnătură, autoritatea de certificare atestă că cheia publică din certificat aparține entității al

cărei nume figurează în certificat. Utilizarea certificatelor se face astfel. Dacă nu are cheia publică a lui , dar are cheia publică a lui dintr-o sursă sigură sau are un certificat pentru semnat de , dintr-o sursă nesigură dsau are încredere în că a verificat corect identitatea lui B înainte de a-i semna certificatul, atunci poate verifica semnătura lui pe certificatul lui și, dacă este corectă, poate prelua cheia lui de pe certificat.

Certificatele au durata de valabilitate limitată, data creerii și data expirării fiind înscrise în

certificat și semnate de autoritatea de certificare. O entitate a cărui certificat se apropie de

expirare va crea o nouă pereche de chei și va solicita autorității de certificare eliberarea unui

nou certificat pentru noua cheie publică. După expirare, un certificat nu mai este recunoscut

de nimeni ca valid și nu mai este folosit. Pe lângă expirare, un certificat mai poate fi eliminat

datorită revocării. Pe servere accesibile public, se pot ține certificate de revocare ale

certificatelor ale căror chei secrete se consideră compromise. Un certificat de revocare al unui

certificat este un ansamblu cuprinzând datele de identificare ale certificatului revocat și

semnătura autorității de certificare a certificatului revocat asupra acelor date de identificare.

Publicarea unui certificat de revocare pentru un certificat anunță invalidării certificatului

original. O entitate care utilizează un certificat va verifica înainte, de fiecare utilizare, dacă nu

există un certificat de revocare al certificatului respectiv. Un certificat de revocare poate fi

produs doar de către autoritatea de certificare emitentă sau de posesorul certificatului.

Un rol important în protecția împotriva atacurilor criptografice îl are autentificarea

utilizatorilor. Pentru autentificare o importanță deosebită o are păstrarea parolelor. Pentru

păstrarea parolelor o soluție este ținerea unei baze de date cu corespondentă nume, parolă.

Această soluție (stocarea parolelor în clar) are un dezavantaj: un adversar care reușește să

spargă sistemul sau un administrator indiscret poate obține direct parolele tuturor utilizatorilor

ceea ce poate fi periculos dacă utilizatorii folosesc aceleași parole și în alte locuri. O metodă

de protecție o constituie criptarea parolelor, mai exact transformarea parolei printr-o dispersie

criptografică rezistentă la preimagine, în baza de date fiind stocată valoarea transformata a parolei . La conectarea unui utilizator, sistemul cere parola utilizatorului și verifică, pentru parola introdusă , dacă . Deoarece este rezistentă la preimagine, probabilitatea ca un adversar, care nu cunoaște parola , să găsească o parolă satisfăcând este neglijabil de mică. Pentru împiedicarea creării unui dicționar de dispersii (memorarea dispersiilor pentru o mulțme de parole), la inițializarea parolei, sistemul

generează un număr aleator și scrie în fișierul de parole perechea unde . Verificarea parolei dată de utilizator se face testând dacă . Pentru crearea unui dicționar ar fi nevoie de un număr de dispersii egal cu produsul dintre numărul de parole

de încercat și numărul de valori posibile pentru , ceea ce îngreunează foarte mult munca unui adversar.

Indiferent de mecanismul folosit la stocarea parolelor, un adversar ce a spart un sistem,

sau un administrator indiscret, va putea întotdeauna să obțină parola cu care se conectează un

utilizator la acel sistem (ex.: adversarul poate înlocui programul obișnuit de login cu un

program care scrie undeva parola în clar).

Autentificarea se poate face și cu parole de unică folosință (One Time Password), o

asemenea parolă fiind acceptată de sistem ca fiind parolă validă cel mult o dată. Una din

aplicațiile parolelor de unică folosință este conectarea la un sistem, în prezentă unui adversar

pasiv, fără a recurge la criptare. Aplicabilitatea acestora este foarte limitată, deoarece

10

comunicația nu este criptată (nu se poate aplica dacă datele transmise trebuie să rămână

secrete).

Intrebări de verificare

Cum pot fi clasificate cheile folosite de partenerii de comunicaţie?

Ce reprezintă „atacul omului din mijloc”?

Cum se realizează „autentificarea utilizatorilor”?

Protocoale de securitate

Un concept de bază, care apare în mecanismele IP pentru autentificare și

confidențialitate, este asociația de securitate (SA - Security Association). SA este o relație

unidirecțională între o sursă și o destinație care asigură servicii de securitate traficului efectuat

pe baza ei, putând fi privită ca un ansamblu de date de tip nume de algoritm - cheie, care

reprezintă capabilitățile criptografice comune entităților participante la asociere, adică grupuri

de utilizatori autorizați să folosească o anumită rețea, denumită rețea virtuală privată (VPN -

Virtual Private Network). Protocoalele de securitate pentru rețelele de comunicații sunt

definite pentru a stabili modul în care sunt oferite serviciile de securitate. Aceste protocoale

de securizare a comunicațiilor pot lucra pe diferite nivele ale modelului OSI, între acestea

regăsind:

pe nivelul legăturii de date: protocoale de tunelare, precum L2TP (Layer2 Tunnelling Protocol) care, deși definit pe acest nivel, operează de fapt pe nivelul OSI 5, de

sesiune;

pe nivelul de rețea: IPsec (IP Security) oferă servicii de autentificare, de control al accesului, de confidențialitate și integritate a datelor;

pe nivelul de transport: TLS (Transport Layer Security), SSL (Secure Socket Layer), protocolul Handshake de autentificare mutuală a clienților și serverelor și negocierea

algoritmilor de criptare înaintea desfăsurării propriu-zise a transmisiei datelor;

pe nivelul de aplicație: SSH (Secure Shell), PGP (Pretty Good Privacy), S/MIME (Secure Multipurpose Internet Mail Extension).

De cele mai multe ori, se definesc suite de protocoale de securitate cum ar fi: IPSec,

KERBEROS, SESAME și altele. Implementarea suitelor de protocoale de securitate în

rețelele de comunicații se face cu mai multe servere de rețea dedicate diferitelor servicii, cum

ar fi: servere de autentificare, servere de certificare, servere de distribuție a cheilor de criptare,

servere de gestiune a cheilor de criptare etc.

Protocolul IPSec (Internet Protocol Security)

IPSec este o suită de protocoale pentru securizarea comunicațiilor peste stiva TCP/IP.

Această suită se bazează pe folosirea funcțiilor matematice și a algoritmilor de criptare și

autentificare pentru a asigura confidențialitatea, integritatea și non-repudierea informațiilor

din fiecare pachet IP transmis pe rețea. IPSec este la ora actuală una dintre cele mai folosite

11

metode de securizare a transmisiei pe Internet, alături de SSL (Secure Sockets Layer) și TLS

(Transport Layer Security). Spre deosebire de acestea, protocoalele IPSec se regăsesc la

nivelul 3 al stivei TCP/IP și la nivelul 3 al stivei ISO-OSI, ceea ce face posibilă securizarea

tuturor aplicațiilor care folosesc stiva TCP/IP. IPSec are o arhitectură de tip end-to-end,

compatibilă atât cu stiva IPv4, cât și cu IPv6, unde integrarea funcțiilor de securizare este

nativă, încă de la proiectarea stivei pe 128 de octeți. Un router sau un server pe care sunt

activate protocoalele de securitate IPsec se numește poartă de securitate (securițy gateway)

sau "zid" de protecție (firewall). În general, asigurarea securității unei transmisii se realizează

la ambele capete ale căii de comunicație, cu două echipamente care folosesc IPSec lucrând în

pereche (IPsec peers). Prin suita IPSec pot fi securizate comunicațiile între două sau mai

multe calculatoare independente, între două sau mai multe subrețele aflate fiecare în spatele

unui gateway care se ocupă de folosirea funcțiilor criptografice pentru fiecare subrețea aflată

în administrarea sa, precum și între un calculator independent și o subrețea aflată în spatele

unui gateway. IPSec se bazează pe proprietățile criptografice ale unor modele precum Diffie-

Hellman, RSA sau DSA și a algoritmilor de criptare și autentificare, cum sunt DES, 3 DES,

AES, MD5, SHA1.

IPsec oferă următoarele servicii de securitate pe nivelul IP al rețelelor TCP/IP:

integritatea conexiunii - asigură faptul că în procesul de comunicație nu intervin entități neautorizate care să modifice datele sau să genereze mesaje false în rețea;

autentificarea sursei de date - permite identificarea sursei și asigurarea autenticității mesajelor;

criptarea datelor - asigură confidențialitatea mesajelor transmise și imposibilitatea preluării neautorizate a informațiilor;

protecția la atacuri în rețea - detectează pachetele repetitive, replici ale aceluiași pachet, care se transmit la infinit în rețea și pot produce blocaje sau saturarea rețelei

(flooding).

În cadrul IPsec autentificarea sursei se face pe baza protocolului AH (Authentication

Header) din suita IPsec (RFC 2401, RFC 2402). Acest protocol asigură autenticitatea

mesajelor și a tuturor informațiilor adiționale incluse în pachet precum și integritatea

pachetului de date, prin aplicarea funcților hash. AH împiedică modificarea ilegală a

pachetelor, multiplicarea sau întârzierea datelor (antireplay security). Pe lângă protocolul AH,

există și protocolul ESP (Encapsulating Security Payload) care asigură autenticitatea,

integritatea și confidențialitatea pachetelor de date. Spre deosebire de protocolul AH, antetul

pachetului IP nu este protejat de ESP, acesta oferind servicii de securitate numai protocoalelor

de pe nivelele superioare Confidențialitatea datelor este asigurată prin criptare. Protocoalele

AH și ESP pot fi implementate prin diverși algoritmi software și se pot aplica fie individual,

fie ambele simultan, în funcție de gradul de securitate impus pachetelor IP (RFC 2403, RFC

2404). Stabilirea protocoalelor poate avea loc static sau dinamic. Denumirea oficială a

stabilirii statice este manual keying. Metoda dinamică de stabilire a asocierilor de algoritmi și

chei este numită ISAKMP (Internet Security Association and Key Management Protocol),

descrisă în RFC 2408. Pe baza mecanismului ISAKMP/TKE se generează și se transmit între

părți cheile de criptare utilizate de SA în diferite sesiuni, memorate într-o bază de date proprie

ISAKMP ca atribute ale SA. În rețelele TCP/IP, se utilizeazează diverși algoritmi de criptare,

uzuali fiind cei cu cheie publică (RSA, Diffie-Hellman, DES, 3DES etc). Există două versiuni

ale ISAKMP, IKEv1 și IKEv2 - Internet Key Exchange.

În funcție de tipul de încapsulare al traficului supus IPSec, suita poate realiza securizarea

prin încapsulare de tip tunel sau de tip transport.

http://tools.ietf.org/html/rfc2408

12

Încapsularea de tip tunel (IP tunneling) apare în momentul în care entitățile participante la IPSec sunt de tip gateway; ele au în administrare una sau mai multe

subrețele pentru traficul cărora realizează operații criptografice. Pachetul încapsulat

IPSec va avea un set de adrese IP exterioare - adresele IP ale entităților gateway și un

set de adrese IP interioare sau protejate - adresele IP, publice sau private, ale

subrețelelor din spatele acestor gateway-uri. Antetul extern specifică perechea de

entități între care se creează tunelul IP și se aplică măsurile de securitate pe baza

IPsec. Antetul intern precizează destinația finală a pachetului pentru realizarea rutării.

ESP protejează numai pachetul transmis prin tunelul IP, în timp ce AH asigură și

securitatea antetului exterior atașat. De regulă acest mod de operare se utilizează între

porți de securitate care execută împachetarea și despachetarea mesajelor (gateway-to-

gateway).

Încapsularea de tip transport(transport mode) apare în momentul în care entitățile participante la IPSec sunt calculatoare independente, care au instalat un soft

specializat IPSec, realizînd operații criptografice pentru propriul trafic. Pachetul

încapsulat va avea un singur set de adrese IP, publice, ale acestor calculatoare.

Protocolul de securitate intervine în pachetul IP și adaugă un antet de securitate

imediat după antetul IP (cu sau fără opțiuni exprimate) dar antetul IP inițial (header-

ul) nu se modifică, doar datele transmise sunt securizate (criptate și/sau autentificate).

Prin folosirea protocolului AH, adresele IP ale sursei, respectiv destinației, nu pot fi

modificate pe parcurs deoarece acest lucru ar duce la modificarea valorii hash. ESP

oferă protecție minimă protocoalelor de nivel superior, în timp ce AH securizează

total pachetul, inclusiv antetul IP. Acest mod de operare se utilizează pentru schimbul

de pachete între calculatoarele-gazdă (host-to-host).

Dacă la unul din capetele canalului de comunicație definit de SA, se găseste un

echipament de securitate (security gateway; firewall), atunci este obligatoriu ca acel SA să

lucreze în modul de tunelare pentru a evita problemele create de existența căilor multiple de

rutare precum și pe cele datorate fragmentării pachetelor.

Configurarea echipamentelor dintr-o rețea în vederea aplicării IPsec se realizează de către

o persoană cu drepturi depline de stabilire a securității rețelei (security officer), în trei etape:

1. crearea grupurilor de securitate (SA) și stabilirea drepturilor și atribuțiilor acestora;

2. configurarea legăturilor dintre SA-uri și stabilirea ierarhiilor de priorități, folosind ISAKMP/IKE (RFC 2408, RFC 2409);

3. stabilirea modalităților de clasificare a pachetelor IP și de acțiune asupra lor (permite sau interzice accesul în rețea, aplică procedurile de securitate conform

IPsec).

Aceste configurații referitoare la IPsec sunt stocate în bazele de date pentru securitatea

rețelei (SPD - Security Policy Database), la care are acces doar administratorul de rețea.

Regulile de securitate aplicate într-o rețea folosind IPsec stabilesc trei moduri posibile de

acțiune asupr pachetelor IP:

1. se aplică pachetului, serviciile de securitate conform IPsec;

2. se interzice accesul pachetului în rețea (deny);

13

3. se acordă permisiunea de acces în rețea, fără aplicarea măsurilor de securitate IP (bypass IPsec).

Modul de acțiune asupra unui pachet IP se stabilește pe baza antetelor conținute de

acesta, prin operația de clasificare a pachetelor, în funcție de diverși factori de selecție, cum ar

fi: adresa IP a sursei, adresa IP a destinației, portul-sursă, portul-destinație, protocolul de

transport, numele utilizatorului sau al sistemului, gradul de prioritate a informațiilor conținute

în pachet.

IPsec oferă posibilitatea unei comunicări sigure în rețelele de arie largă (WAN), în

aplicații precum:

Definirea rețelelor virtuale private (VPN – Virtual Private Network), în care uzual IPsec este configurat să folosească protocolul ESP în modul tunel pentru furnizarea

confidențialității. Pentru o organizație cu mai multe rețele locale, aflate în diferite

locații, traficul intern rețelelor locale nu este securizat în timp ce traficul între acestea

utilizează IPsec pentru securizare. IPsec este activat în echipamentele de acces la

rețeaua de arie largă, de exemplu în gateway, router sau firewall. Operațiile de

criptare/decriptare și de autentificare executate de IPsec sunt transparente pentru

stațiile de lucru și serverele din rețelele locale.

Accesul securizat de la distanță prin rețeua publică de Internet la un sistem în care este implementat protocolul IPsec. Se poate apela la un furnizor de Internet (ISP -

Internet Service Provider) pentru a obține accesul securizat la o rețea privată.

Îmbunătățirea securității aplicațiilor distribuite care au o serie de mecanisme de securitate incluse. Principala caracteristică a IPsec care îi permite să securizeze o

gamă atât de largă de aplicații distribuite (e-mail, transfer de fișiere, acces Web etc.),

este faptul că pentru întregul trafic IP se pot utiliza mecanismele de criptare si/sau

autentificare.

Pentru o asociație de securitate, ca și identificatori, avem un număr aleator denumit

identificator de securitate (SPI - Security Parameter Index), o adresă IP de destinație și un

protocol de securitate (AH sau ESP).

Identificatorul de securitate constă într-un sir de biți cu semnificație locală, inclus în antetele AH și ESP pentru a permite destinației să selecteze SA-ul pentru procesarea

pachetului recepționat;

Adresa IP de destinație este adresa nodului de destinație al asociației de securitate, care poate fi un calculator-gazdă (host) sau un echipament de comunicație al rețelei

(router, firewall, access point);

Identificatorul protocolului de securitate indică pentru care protocol, AH sau ESP, lucrează SA. Dacă este necesară utilizarea ambelor protocoale de securitate în

Internet (AH si ESP), atunci se creează și se configurează legăturile dintre două sau

mai multe asociații de securitate.

Pentru ca în momentul securizării traficului fiecare entitate să cunoască parametrii de

securizare pentru fiecare tip de trafic este folosit identificatorul SPI - Security Parameter

Index, un index pe baza de date SAD. Folosind acest index și valoarea adresei IP din

destinația pachetului ce urmează a fi supus procesului de criptare sau autentificare, fiecare

entitate IPSec știe exact ce transformare trebuie realizată pe fiecare pachet IP pentru ca acesta

să poată fi decriptat la receptor și corect interpretat.

14

Procesul de decriptare este asemănător în momentul recepției unui pachet astfel securizat.

În cazul în care sunt mai mult de doi participanți la asocierea de securitate, în cazul traficului

de tip multicast, asocierea de securitate este furnizată pentru întregul grup și este prezentă pe

fiecare sistem participant. Pot exista, deasemenea, mai multe asocieri de securitate pentru un

același grup de entități, fiecare cu diverse nivele de securitate în interiorul grupului.

În funcție de al tipului entității participante la IPSec putem avea modelul de trafic:

Site-to-Site sau LAN-to-LAN, în cazul în care entitățile sunt două gateway-uri de securitate care realizează operații criptografice pentru subrețele protejate aflate în

administrarea lor.

Remote-Access sau Dial-Up VPN, în cazul în care entitățile sunt un gateway de securitate care are în administrare o subrețea și un calculator independent care dorește

să comunice cu acea subrețea.

Această manieră de clasificare se pretează în exclusivitate tipului de încapsulare tunel,

neavând sens pentru tipul transport, în principal datorită faptului că un pachet trimis pe rețea

are două seturi de adrese IP: un set "extern", reprezentat de adresele IP are calculatorului și al

gateway-ului căruia se adresează, și un set de adrese IP "intern", reprezentat de adresa IP a

unei mașini din interiorul rețelei și a unei adrese IP noi a calculatorului, obținută de la acel

gateway pentru a avea adresabilitate de nivel IP în interiorul rețelei la care acest calculator se

conectează. Procedeul prin care un calculator obține, în momentul negocierii IPSec, o adresă

de la gateway pentru a avea acces într-o rețea internă este numit mode-config în scenariile de

tip IKEv1 sau configurare remote în cele de IKEv2.

În momentul negocierii de IKE a parametrilor asocierii de securitate se realizează și faza

de autentificare mutuală sau unilaterală a entităților, existând mai multe modalități de a realiza

această autentificare:

PSK - Pre-Shared Key : pentru autentificare, fiecare entitate are pre-configurată o cheie secretă, o parolă. În momentul realizării negocierii IKE, entitățile trimit această

cheie pe rețea, spre a fi verificată de entitățile omoloage și verifică, la rândul lor, că o

anumită entitate-pereche are o anumită cheie secretă.

PKI - Public Key Infrastructure: pentru autentificare este folosit un sistem de tip PKI. Fiecare entitate are un certificat digital semnat de o autoritate de certificare publică

sau internă companiei, dar de încredere pentru toate entitățile participante în IPSec. În

faza de autentificare din IKE, fiecare entitate își trimite certificatul digital către

omologi spre a fi verificat și verifică la rândul ei validitatea acelui certificat digital.

EAP - Extensible Authentication Protocol: la rândul său un framework, de data aceasta de autentificare, EAP nu realizează autentificare per se, ci oferă o schemă de

mesaje de autentificare ce folosește metode specifice, cum sunt MD5, GTC, TLS,

SIM, AKA. În faza de autentificare, EAP este folosit ca extensie a protocolului

IKEv2, acest framework nefiind suportat în IKEv1.

Cele mai multe implementări de IPSec încearcă să realizeze pe cât posibil optimizarea

utilizării resurselor computaționale disponibile. Un exemplu în acest sens este închiderea

tunelului IPSec în cazul în care nu se mai trimit date pentru o anumită durată de timp, sau

dacă lărgimea de bandă ocupată pentru o anumită conexiune este nulă. Dacă aceasta este

configurația implicită, pentru anumite conexiuni se poate dori suprascrierea ei și menținerea

acelei conexiuni. Una dintre posibilitățile puse la dispoziție de standard se numește DPD -

15

Dead Peer Detection. Acesta este un mecanism de timp keepalive care presupune trimiterea

unui pachet între capetele conexiunii, la un interval stabilit.

Cu toate "măsurile de siguranță" luate în cazul IPSec, au fost raportate și unele

vulnerabilităţi în anumite configuraţii ale acestuia, acestea putând fi exploatate de atacatori

pentru a sustrage informaţii confidenţiale. Aceste atacuri sunt posibile când IPSec foloseşte

ESP (Encapsulating Security Payload) în modul de funcţionare tunnel cu opţiunea

confidentiality only, sau opţiunea integrity protection oferită de modulul AH sau de un

protocol de nivel mai ridicat. Dacă un atacator poate intercepta şi modifica comunicaţiile

IPSec și ICMP între două servere de tip security gateway, exploatând această vulnerabilitate

poate lansa atacuri de tip Destination Address Rewriting, IP Options modification şi Protocol

Field modification, astfel făcând posibilă sustragerea de informaţii din datele transferate

folosind IPsec. Ca și soluţie este recomandat să se configureze ESP astfel încât să folosească

atât opţiunea confidentiality, cât şi integrity protection și să se folosească protocolul AH

alături de ESP pentru a oferi protecţia integrităţii.

Protocolul Kerberos

Protocolul Kerberos1 a fost proiectat la Massachusetts Institute of Technology (MIT), în

jurul anului 1984 pentru a proteja serviciile de reţea oferite de proiectul Athena. Scopul

protocolului Kerberos era să extindă noţiunea de autentificare, autorizare şi contabilizare a

mediului MIT.

Kerberos a fost proiectat pe baza modelului client-server și asigură autentificarea

mutuală, adică atât utilizatorul cât și serverul se autentifică unul față de celălalt. În

terminologia Kerberos, un domeniu administrativ se numeşte realm. Se presupune că orice

companie sau organizaţie care doreşte să ruleze Kerberos poate crea un realm identificat unic

printr-un nume. Teoretic, Kerberos poate suporta mai bine de 100.000 de utilizatori. Kerberos

se bazează pe modelul client / server. Protocolul în sine constă dintr-un schimb de mesaje

între un client şi o serie de servere, fiecare cu o altă misiune.

Utilizatorii, clienţii şi serviciile de reţea instanţiate pe un host în particular se consideră în

mod tipic parteneri. Fiecare partener este identificat în mod unic de un identificator de

partener. Un identificator de partener are în componenţă trei câmpuri, fiecare fiind un şir

terminat cu null de până la 40 de caractere. Aceste trei câmpuri sunt:

Numele partenerului, NAME

Numele instanţei, INSTANCE

Numele realm-ului, REALM

Mesajele protocolului Kerberos sunt protejate împotriva atacurilor de ascultare

(eavesdropping) și de reluare a mesajelor (replay), scopul sistemului Kerberos fiind acela de a

permite unui client ce rulează în numele unui utilizator anume să se identifice unui serviciu

sau unui server de aplicaţii corespunzător, fără a se necesita trimiterea unor date secrete care

1 În mitologia greacă, cerberul (Kerberos) este numele unui câine de pază cu trei capete al lui Hades, a cărui misiune era să păzească intrarea în lumea de dedesubt.

16

ulterior să poată fi folosite de un atacator la impersonarea utilizatorului. Pentru a realiza acest

lucru, modelul Kerberos necesită existenţa unui terţ de încredere care serveşte ca centru de

distribuţie a cheilor (KDC) în realm-ul Kerberos. Kerberos utilizează tehnici simetrice de

criptare și oferă un sistem de mesaje criptate numite tichete, care asigură în mod securizat

încrederea reciprocă dintre două entități din rețea. Utilizând Kerberos, parolele nu mai sunt

transmise prin rețea, nici măcar criptate. În cazul în care un tichet Kerberos este interceptat

acesta rămâne protejat deoarece este criptat cu algoritmi robusti de criptare. Odată ce o

entitate-client obține un tichet către un anume server, tichetul este păstrat pe calculatorul local

până la expirare, făcând astfel din Kerberos un sistem de autentificare foarte eficient. Depinde

de implementare, dar în mod uzual un tichet Kerberos expiră după opt ore. Fiecare entitate din

rețea, fie client, fie server, deține o cheie secretă, cunoscută doar de ea și de KDC. Această

cheie constituie dovada identității unei entități. Pentru o comunicare sigură între două entități

din rețeaua publică, KDC generează o cheie a sesiunii. Pentru implementarea protocolului

Kerberos trebuie acordată o atenție deosebită stocării parolelor fiecărui client, motiv pentru

care serverul central trebuie să fie o maşină foarte sigură. KDC menţine o bază de date cu

informaţii despre fiecare partener din cadrul sistemului. Deoarece securitatea este foarte

importantă, această informaţie este redusă la un minim posibil pentru a efectua cu succes

autentificarea. Astfel, deşi baza de date Kerberos este la nivel de utilizator, aceasta nu conţine

informaţii cum ar fi numere de telefon sau adrese, neutilizate în mod curent la autentificare, ci

următoarele:

Identificatorul partenerului

Cheia master Kp (sau parola dacă este utilizator)

Data expirării identităţii

Data ultimei modificări a înregistrării

Identitatea partenerului care a operat modificarea

Timpul maxim de viaţă a biletelor emise partenerului

Unele atribute

Unele date interne de implementare invizibile la exterior cum ar fi versiunea cheilor, versiunea cheii master sau indicatori către valori vechi ale înregistrării.

Cheia master (Kp) a fiecărui partener trebuie ţinută secretă, de aceea toate aceste chei se

codifică cu o cheie master a KDC. Pe lângă o protecţie sporită, această metodă permite

distribuirea bazei de date între servere fără riscul de a fi capturată de un potenţial atacator.

Cheia master KDC nu se păstrează în aceeaşi bază de date, ci se operează separat.

Un centru de distribuție a cheilor are două părți:

un server de autentificare (Authentication Server - AS);

un server de alocare a tichetelor (Ticket Granting Server - TGS).

AS şi TGS sunt componente separate logic dar pot fi procese care rulează pe aceeaşi

maşină. Aceasta trebuie să fie protejată cu grijă şi securizată fizic, deoarece un intrus ar putea

compromite uşor întreg sistemul de la acest nivel. Un tichet este un certificat emis de KDC şi

criptat cu cheia master a serverului. Printre altele, un tichet conţine:

Cheia de sesiune care va fi utilizată pentru autentificarea între client şi server

Numele partenerului către care cheia de sesiune a fost emisă

Un timp de expirare după care cheia de sesiune nu mai este validă

17

Pentru înțelegerea principiul de funcționare a protocolului, explicăm noțiunile:

Serverul TGS (Ticket Granting Server) oferă tichete de tip sesiune pentru accesarea altor resurse. De obicei, TGS rulează în KDC;

Tichetul TGT (Ticket Granting Ticket) reprezintă un jeton de validare a unui tichet Kerberos care atestă faptul că o entitate a fost deja autentificată și ne asigură că

utilizatorii nu mai trebuie să reintroducă parola după un login inițial, până la expirarea

tichetului;

Tichetul de sesiune ST (Session Ticket) reprezintă un jeton de sesiune care permite accesul la resurse protejate. Pentru accesarea oricărei aplicații care utilizează

Kerberos este necesar un tichet de sesiune valid.

Pașii protocolului Kerberos sunt (a se vedea figura de mai sus):

pasul 1

Utilizatorul unui sistem client, utilizând un username și o parolă sau un smart card, se

autentifică față de server-ul de autentificare (AS din KDC). Clientul de login furnizează AS

numele, iar AS caută intrarea corespunzătoare utilizatorului în baza de date KDC.

pasul 2

Cu parola cerută de client utilizatorului se va cripta TGT. Dacă cheia derivată din parola

utilizatorului poate decripta cu succes TGT, acestuia i se permite accesul. Pe partea de client,

TGT-ul este memorat pentru folosire ulterioară şi anume pentru a obţine bilete pentru

autentificarea în servicii de reţea particulare. Scopul principal al TGT este deci să faciliteze o

singură autentificare pentru utilizatori. Parola este astfel cerută o singură dată, şi nu de fiecare

dată când se cere accesul la un serviciu.

pasul 3

Biletele sunt eliberate de TGS-ul specificat în TGT-ul primit de utilizator. Pentru a obţine

un bilet, clientul trimite o cerere către TGS.

pasul 4

Dacă T

GS consideră atât biletul cât şi autentificatorul valid, biletul este returnat.

1 2 3 4

5

6

18

Mesajul include numele serviciului cerut, TGT-ul şi autentificatorul. Acesta din urmă

este o informaţie ce poate proba că a fost generată recent utilizând cheia de sesiune de către

client şi server împreună. În particular, autentificatorul conţine numele utilizatorului, adresa

de reţea a clientului şi timpul curent, fiind criptat cu cheia de sesiune returnată în TGT.

Autentificatorul descurajează atacurile replay.

pasul 5

Clientul creează un alt autentificator şi îl trimite împreună cu biletul de serviciu

serverului.

pasul 6

Dacă se cere autentificare reciprocă, serverul returnează un autentificator.

Aşa cum a fost descris până acum, modelul Kerberos nu oferă decât serviciul de

autentificare. În sine, el nu oferă informaţii despre autorizarea clientului în a folosi anumite

servicii de reţea. În general, sunt trei posibilităţi pentru atingerea problemei autorizării, şi

anume:

baza de date Kerberos ar putea conţine informaţii de autorizare pentru fiecare serviciu şi să emită bilete doar utilizatorilor autorizaţi.

un serviciu dedicat poate menţine informaţiile de autorizare prin liste de acces pentru fiecare serviciu şi permiterea clientului să obţină certificate sigilate de apartenenţă la

listă. În acest caz clientul ar prezenta serviciului certificarea în locul biletului

Kerberos.

fiecare serviciu poate menţine propria informaţie de autorizare cu ajutorul opţional al unui serviciu care stochează aceste liste de acces şi oferă certificări de apartenenţă la

listă.

Modelul Kerberos se bazează pe faptul că fiecare serviciu cunoaşte cu exactitate cine sunt

utilizatorii săi şi ce formă de autorizare este potrivită pentru aceştia. În consecinţă Kerberos

foloseşte cea de-a treia metodă. Pentru simplificarea implementării celei de a treia metode,

Kerberos foloseşte modelul de autorizare bazat pe liste de control al accesului. Orice serviciu

care consideră că i se potriveşte acest tip de autorizare poate încorpora o bibliotecă cu funcţii

adecvate. Utilizarea acestui model presupune că serviciul verifică dacă o identitate verificată

aparţine unei liste de acces.

Primele trei versiuni ale Kerberos au fost folosite doar în cadrul MIT, în prezent

nemaifiind folosite. Prima versiune făcută publica a fost Kerberos V4, versiune ce a cunoscut

o răspândire importantă în afara MIT. Deoarece unele medii necesitau funcţionalităţi

neacoperite de Kerberos V4, iar altele aveau o structură diferită de modelul MIT, în 1989 a

început lucrul la Kerberos V5. În septembrie 1993, Kerberos V5 a fost specificat ca standard

Internet în RFC 1510 [KOHL93]. MIT a dezvoltat şi testat Kerberos V5 pe Ultrix, SunOS,

Solaris şi Linux, fiind portat şi pe alte sisteme de către terţi. Deşi similare ca şi concept,

Kerberos V4 şi V5 sunt substanţial diferite şi chiar sunt în competiţie pentru dominaţia pe

piaţă. Pe scurt, Kerberos V4 are o bază de instalare mai mare, este mai simplu şi are o

performanţă mai mare decât V5, însă lucrează doar cu adrese IP. Kerberos V5 pe de altă parte,

are o bază de instalare mai redusă, este mai complicat şi implicit mai puţin eficient, dar

prezintă mai multă funcţionalitate decât V4.

19

În ciuda faptului că este disponibil codul sursă pentru Kerberos V4 şi V5, MIT nu-l

susţine oficial şi nu oferă suport. Unele companii însă oferă contra cost versiuni comerciale de

implementări Kerberos. Informaţii despre versiunile freeware şi comerciale se găsesc în

Kerberos FAQ publicat periodic în grupul de ştiri comp.protocols.kerberos.

Protocoalele criptografice implementate de Kerberos

Protocolul Needham-Schroeder

Kerberos se bazează pe protocoalele de autentificare şi distribuţie a cheilor propuse de

Needham şi Schroeder [NEED78, NEED87]. Protocolul presupune existenţa unui terţ de

încredere care reprezintă un server de autentificare (AS). Daca AS are cheile fiecărui

partener, doi parteneri arbitrari A şi B pot folosi AS pentru a se autentifica reciproc şi să

primească o cheie de sesiune Kab. Protocolul Needham-Schroeder se poate formaliza după

cum urmează:

pas1

A AS : A, B, N

Începe comunicaţia în clar de la A la AS transmițându-se identitatea pretinsă, identitatea

corespondentului dorit B, precum şi o valoare curentă N. La recepţionarea mesajului, AS

caută cheile secrete ale A şi B (Ka şi Kb) şi alege aleator o cheie de sesiune Kab.

pas 2

AS A : {N, B, Kab, {Kab, A} Kb} Ka

AS returnează lui A {N, B, Kab, {Kab, A} Kb} Ka, mesaj codificat cu cheia lui A (numai A

poate decodifica mesajul). A poate verifica prezenţa valorii N pentru a determina dacă

mesajul provine într-adevăr de la AS.

pas 3

A B : {Kab, A} Kb

A memorează valoarea Kab şi trimite lui B valoarea {Kab, A} Kb. Această valoare este

codificată cu cheia lui B (numai acesta poate decodifica mesajul şi extrage componentele, în

speţă cheia Kab). Prin această modalitate B poate afla identitatea corespondentului A,

autentificat de AS. În acest moment, A ştie că orice comunicare codificată cu Kab provine de

la B şi orice trimite A codificat cu Kab poate fi înţeles numai de B.

pas 4

B A : {Nb} Kab

B alege un număr Nb aleator și il codifică cu cheia Kab (pentru protecţia împotriva

atacurilor replay)

pas 5

A B : {Nb – 1} Kab

B cere lui A să răspundă cu numărul decrementat şi recodificat cu cheia Kab. Dacă

răspunsul primit de B este satisfăcător, schimbul ulterior de mesaje poate continua.

20

Numărul pașilor se poate reduce la 3 prin menţinerea de către A în cazul partenerilor

obişnuiţi de comunicare a perechilor de forma B : Kab, {Kab, A} Kb , astfel eliminându-se paşii

1 şi 2.

O vulnerabilitate majoră a ambelor versiuni ale protocolului Needham-Schroeder constă

în posibilitatea ca un terţ C care este capabil de a urmări dialogul să lanseze un atac off-line

asupra Kab. Daca C poate determina o cheie de sesiune K’ab folosită în trecut, C poate

impersona pe A. De fapt, C poate folosi biletul corespunzător împreună cu valoarea codificată

cu K’ab in pasul 3. B provoacă pe A în pasul 4 şi deoarece C cunoaşte pe K’ab, poate răspunde

corect în pasul 5. Slăbiciunea subtilă din spatele acestui protocol este că mesajul din pasul 3

nu conţine nici o informaţie pentru B pentru a-i verifica prospeţimea. De fapt acest lucru este

cunoscut doar de AS şi A. Ca măsură reparatorie, se poate înlocui valoarea cu amprente de

timp.

Protocolul Kerberos V4

Protocolul utilizat în Kerberos V4 se bazează în parte pe protocolul Needham-Schroeder

cu unele modificări menite să-l adapteze la mediul de reţea pentru care a fost proiectat iniţial.

Printre aceste schimbări, amintim:

utilizarea amprentelor de timp

adăugarea unui serviciu de oferire a tichetelor pentru a permite autentificarea suplimentară fără a fi necesar ca utilizatorul să-şi reintroducă parola

o abordare diferită a autentificării inter-domenii

Paşii protocolului Kerberos V4 se pot formaliza după cum urmează:

C AS : U, TGS, T, L

AS C : {K, N, Tc,tgs} Ku

C TGS : S, N, Tc,tgs, Ac,tgs

TGS C : {Tc,s, K’} K

C S : Tc,s, Ac,s

S C : {T + 1} K’

În această descriere, termenul Tc,tgs = {U, C, TGS, T, L, K} KTGS se utilizează pentru a ne

referi la un TGT care a emis de AS pentru a fi folosit de un client C pentru a se autentifica cu

un TGS şi a cere un bilet corespunzător. În mod similar, termenul Tc,s ={U, C, S, T’, L’, K’}

Ks desemnează un bilet emis de TGS şi utilizat de C pentru a se autentifica cu un server S. În

ambele expresii, T şi T’ se referă la amprente de timp, iar L şi L’ desemnează timpul de viaţă

al acestora. O amprentă de timp reprezintă numărul de secunde de la ora 00:00:00 GMT, 1

ianuarie 1970 şi se codifică pe 4 octeţi. Aceasta este o reprezentare comună a timpului într-un

sistem UNIX. În mod similar, timpul de viaţă al unui tichet se specifică în unităţi de cinci

minute şi se codifică într-un singur octet, drept urmare timpul maxim de viaţă care se poate

exprima în Kerberos V4 este de puţin peste 21 de ore. În plus faţă de acestea, termenii Ac,tgs =

{C, T} K şi Ac,s = {C, T’}K’ desemnează autentificatorii pentru Tc,tgs şi Tc,s.

Cei şase paşi ai protocolului se pot grupa în trei schimburi:

schimbul AS între client şi AS (paşii 1 şi 2)

21

schimbul TGS între client şi TGS (paşii 3 şi 4)

schimbul AP între client şi serverul de aplicaţii (paşii 5 şi 6)

Schimbul AS, prezentat pe scurt, decurge astfel:

Un client C utilizează un serviciu de nume (name service) pentru a localiza în termeni de

topologie a reţelei cel mai apropiat TGS disponibil. C trimite apoi un mesaj KRB_AS_REQ

(Kerberos authentication server request) către AS în pasul 1. Mesajul include identificatorul

de utilizator U, identificatorul TGS-ului selectat, o amprentă de timp T şi durata de viaţă

dorită pentru TGT. După primirea mesajului KRB_AS_REQ, AS caută şi extrage cheile

secrete asociate cu U şi TGS. AS selectează apoi o cheie de sesiune aleatoare K şi-i răspunde

lui C cu mesajul KRB_AS_REP (Kerberos authentication server reply) în pasul 2. Mesajul

include K, N şi Tc,tgs. În plus, mesajul este codificat cu Ku. După recepţionarea mesajului

KRB_AS_REP, C trebuie să ceară utilizatorului U parola sa. De fapt, protocolul Kerberos V4

adoptă o regulă general valabilă în securitate, aceea de a ştii parola utilizatorului un timp

minim posibil. Totuşi, aşteptarea pentru câteva secunde a mesajului KRB_AS_REP nu creşte

siguranţa în mod semnificativ, de aceea Kerberos V5 cere parola înainte ca C să trimită

mesajul KRB_AS_REP. Un alt motiv pentru care această parolă se cere înainte este că C

trebuie să dovedească faptul că ştie parola utilizatorului pentru ca AS să trimită mesajul

KRB_AS_REP, lucru care îngreunează atacul prin ghicire a parolelor. În Kerberos V4, dacă

U introduce corect parola pwdU, C poate folosi o funcţie h de dispersie cu sens unic cunoscută

pentru a calcula cheia secretă a lui U, adică KU =h(pwdU). Echipat cu această cheie, C poate

decodifica {K, N, Tc,tgs} KU şi extrage K, N, şi Tc,tgs. Dacă C are succes, acesta este în

posesia unui TGT care poate fi utilizată pentru a cere bilete de la TGS. De remarcat că într-un

TGT, timpul de viaţă se foloseşte ca o parolă de expirare a timpului. Limitarea timpului de

viaţă al TGT limitează astfel avariile produse în sistem în cazul compromiterii TGT. În

Kerberos, în general nu este posibil să se revoce un TGT odată ce a fost emis.

În schimbul TGS al protocolului Kerberos V4 formatul mesajului este aproape identic cu

cel din schimbul AS. Diferenţa constă în faptul că mesajul este codificat cu cheia de sesiune K

(cunoscută de C şi TGS) în loc de cheia utilizatorului KU. Înainte de a iniţia un schimb TGS,

C trebuie să determine în care domeniu a fost înregistrat serverul de aplicaţii pentru care se

cere un bilet. Dacă C nu are deja un TGT pentru acel domeniu, trebuie să obţină unul.

Schimbul AP este utilizat de aplicaţii de reţea pentru a autentifica un client faţă de un

server sau pentru a se autentifica reciproc. Clientul trebuie să aibă deja credenţiale pentru

server prin utilizarea schimburilor AS şi TGS.

Faţă de Kerberos V4, în Kerberos V5 au fost operate modificările:

Identificatorii părţilor: În Kerberos V5, identificatorii părţilor constau în două repere: numele domeniului (realm) şi un rest. Numele domeniului este separat pentru a

facilita implementarea uşoară a rutinelor de traversare şi a verificărilor de acces la

domeniu. Restul este o secvenţă de câte componente sunt necesare pentru numele

părţii. De remarcat că identificatorul din Kerberos V4 este similar cu un rest cu două

componente în Kerberos V5.

Utilizarea criptării: Pentru a îmbunătăţi modularitatea lui Kerberos, criptarea a fost separată în module software care pot fi schimbate sau îndepărtate la nevoie. Când se

foloseşte criptarea, textul respectiv este marcat în aşa fel încât receptorul să poată

identifica modulul de care are nevoie pentru a înţelege mesajul. Algoritmii de criptare

22

de asemenea au sarcina de a oferi siguranţa integrităţii, prin folosirea unor metode

adecvate, cum ar fi suma de control.

Adrese de reţea: În Kerberos V5, adresele sunt etichetate cu un tip şi lungime, astfel că dacă un host suportă mai multe protocoale de reţea să le poată oferi bilete.

Codificarea mesajelor: Mesajele sunt descrise utilizând notaţia de sintaxă abstractă 1 (ASN 1) şi codificate după regulile fundamentale de codificare (BER). Astfel, se evită

specificarea codificării pentru cantităţi compuse din mai mulţi octeţi, aşa cum era

cazul în Kerberos V4.

Formatul biletului: Biletul are un format extins pentru noile opţiuni. Acesta este împărţit în două părţi, una codificată iar alta nu. Numele serverului este necodificat

pentru a permite unui server cu identităţi multiple să selecteze cheia potrivită. În plus

faţă de această schimbare, timpul de viaţă al biletului este reprezentat ca timp de start

şi timp de expirare, permiţând timp de viaţă aproape nelimitat.

Suport inter-domeniu: În Kerberos V5, domeniile pot coopera printr-o ierarhie bazată pe numele realm-ului. Un domeniu sursă este interoperabil cu domeniul destinaţie

dacă cele două cunosc o cheie pentru domeniul destinaţie.

Paşii protocolului Kerberos V5 se pot formaliza astfel cum urmează:

C AS : U, TGS, L1, N1

AS C : U, Tc,tgs, {TGS, K, Tstart, Texpire, N1} KU

C TGS : S, L2, N2, Tc,tgs, Ac,tgs

TGS C : U, Tc,s, {S, K’, T’start, T’expire, N2} K

C S : Tc,s, Ac,s

S C : {T’} K’

Analog cu Kerberos V4, Tc,tgs şi Tc,s se referă la un TGT respectiv un tichet, iar Ac,tgs şi

Ac,s se referă la autentificatorii respectivi. În pasul 1, C selectează un TGS şi trimite un mesaj

KRB_AS_REQ la AS. Mesajul include identificatorul utilizatorului (U), identificatorul TGS-

ului selectat, durata de viaţă solicitată L1 pentru TGT şi o valoare N1. În plus faţă de acestea,

un mesaj poate specifica un număr de opţiuni, cum ar fi:

Dacă pre-autentificarea trebuie realizată

Dacă biletul solicitat se poate re-înnoi sau re-trimite.

Dacă biletele derivate ar trebui să fie postdatate sau să permită postdatarea.

Dacă un bilet re-înnoibil va fi acceptat în locul unuia ne-înnoibil (dacă timpul de expirare nu poate fi satisfăcut)

După recepţionarea mesajului KRB_AS_REQ, AS caută şi extrage cheile secrete pentru

U şi TGS. Dacă este necesar, AS pre-autentifică cererea iar dacă aceasta eşuează, un mesaj de

eroare corespunzător este returnat lui C. Altfel, AS selectează aleator o nouă cheie de sesiune

K’ şi returnează un mesaj KRB_AS_REP lui C în pasul 2. Mesajul include U, un Tc,tgs = {U,

C, TGS, K, Tstart, Texpire} Ktgs şi {TGS, K, Tstart, Texpire, N1} KU. Timpii de start şi de expirare

Tstart respectiv Texpire ale TGT-ului sunt setaţi în concordanţă cu politica de securitate a

domeniului în aşa fel încât se încadrează în timpul de viaţă L1 specificat în mesajul

KRB_AS_REQ. După recepţionarea mesajului KRB_AS_REP, C aplică o funcţie cu sens

unic h la parola utilizatorului pwdU pentru a calcula cheia master a acestuia. KU = h(pwdU).

Echipat cu această cheie, C poate decodifica {TGS, K, Tstart, Texpire} KU, şi extrage TGS, K,

23

Tstart, Texpire. Acum poate folosi acest TGT pentru a solicita un bilet de la TGS. Schimbul TGS

este iniţiat ori de câte ori C doreşte să obţină un bilet pentru server, re-înnoiască său valideze

un bilet existent sau chiar să obţină un bilet proxy. Cel puţin în primul caz, clientul trebuie să

fi obţinut deja un TGT prin schimbul AS. În pasul 3, C trimite mesajul KRB_TGS_REQ către

TGS. Din nou, mesajul include informaţii pentru autentificarea clientului plus cereri pentru

credenţiale. Informaţiile de autentificare constau în Tc,tgs şi un autentificator corespunzător

Ac,tgs = {C, T} K generat de C cu amprenta de timp T şi cheia de sesiune K. În pasul 4, TGS

returnează un mesaj KRB_TGS_REP care include un bilet Tc,s = {U, C, S, K’, T’start, T’expire}

Ks pentru serverul S, precum şi {S, K’, T’start, T’expire} K. Schimbul AS se utilizează fie pentru

a autentifica un client unui server, fie pentru a se autentifica reciproc un client şi un server. În

pasul 5, C trimite un mesaj KRB_AP_REQ către serverul S. Mesajul conţine biletul Tc,s şi un

autentificator corespunzător Ac,s = {C, T’} K’, împreună cu unele informaţii de management.

Autentificarea se bazează pe timpul curent al serverului, a autentificatorului şi a tichetului.

Dacă nu apare nici o eroare şi dacă se cere autentificare reciprocă, S returnează un mesaj

KRB_AP_REP în pasul 6. Acest mesaj include amprenta de timp T’, codificată cu cheia de

sesiune K’ pe care S o cunoaşte împreună cu C.

În general, un mediu de reţea constă din mai multe organizaţii, cum ar fi companii în

competiţie, agenţii guvernamentale, instituţii financiare său universităţi. Într-un astfel de

mediu, ar fi dificil de găsit o entitate credibilă pentru toată lumea care să ruleze un Kerberos

KDC. Problema este că oricine are acces la KDC cunoaşte cheia master a utilizatorului şi are

acces la orice are acces şi utilizatorul. Chiar şi dacă o astfel de entitate s-ar găsi, replicile

KDC-ului ar trebui să fie de asemenea credibile. O entitate poate fi foarte ocupată cu

utilizatorii şi serviciile care intră şi iasă din reţea. Din acest motiv, reţeaua este împărţită în

domenii, fiecare dintre acestea având propriul KDC. Kerberos a fost proiectat să funcţioneze

şi în afara graniţelor domeniului, fiind posibil ca în principiu, un client într-un domeniu să se

autentifice unui server din alt domeniu. În Kerberos, o autentificare peste graniţele

domeniului se numeşte autentificare inter-domeniu. O cheie inter-domeniu este o cheie

secretă cunoscută de KDC-urile a două domenii Kerberos. Prin stabilirea acestor chei,

administratorul domeniilor permite ca un utilizator autentifica într-un domeniu să se

autentifice şi la distanţă. Se spune că un domeniu comunică cu altul dacă cele două cunosc

aceeaşi cheie inter-domeniu sau dacă domeniul local cunoaşte cheia unui domeniu intermediar

care la rândul său comunică cu domeniul îndepărtat. În terminologia Kerberos, o cale de

autentificare se referă la o secvenţă de domenii tranzitate în proces. Kerberos V4 necesita ca

AS-ul să comunice cu fiecare domeniu unde era necesară autentificarea inter-domeniu iar, în

contrast, Kerberos V5 suportă autentificarea inter-domenii cu treceri, cheile fiind distribuite

ierarhic.

Slăbiciunile lui Kerberos

Utilizarea sistemului Kerberos îmbunătăţeşte securitatea aplicaţiilor în reţea dar, prezintă

și unele deficiențe:

Dependenţa de criptosistem: implementarea de referinţă de la MIT pentru Kerberos V4 utilizează DES pentru a codifica mesajele. Înainte ca restricţiile de export ale

sistemelor criptografice să fie ridicate, răspândirea utilizării lui Kerberos a fost destul

de dificilă.

24

Dependenţa faţă de protocolul Internet: Kerberos V4 necesită utilizarea adreselor de tip IP, ceea ce îl face nepotrivit în anumite medii.

Ordinea octeţilor în mesaj: în Kerberos V4, host-ul care trimite mesajul ordonă octeţii în conformitate cu ordinea sa naturală. Receptorul este responsabil de a re-

ordona octeţii pentru a se potrivi modului său nativ. În timp ce acest lucru va uşura

comunicarea între host-uri cu aceeaşi ordine a octeţilor, comunicarea cu un tip diferit

de host poate afecta interoperabilitatea.

Timpul de viaţă al tichetului: limita de viață de aproximativ 21 de ore a unui tichet este un neajuns major în Kerberos V4, deoarece împiedică acordarea de tichete unor

sarcini care rulează multă vreme.

Înaintarea autentificării: Kerberos V4 nu permite ca un tichet emis unui client de pe un host să fie trimis altui host sau utilizat de alt client.

Numirea utilizatorilor: în Kerberos V4, numele sunt compuse din trei componente: nume, instanţă şi domeniu, fiecare având maxim 40 de caractere, aceste dimensiuni

dovedindu-se prea mici pentru unele aplicaţii.

Necesitatea autentificării inter-domenii

Dubla criptare: TGT-ul emis de AS este codificat de două ori când este returnat la client şi numai o dată când este trimis la TGS.

Autentificarea mesajului: algoritmul de sumă de control din Kerberos V4 nu este documentat sau publicat, de aceea nu există dovezi despre slăbiciunea sau tăria sa.

Totuşi, faptul că un algoritm nu a fost spart până în prezent nu înseamnă că algoritmul

este sigur.

În Kerberos V5, multe dintre probleme prezentate anterior au fost luate în seamă la

proiectarea acestuia. Una din marile probleme este aceea că sistemul Kerberos se bazează în

continuare pe parole bine alese şi pe faptul că acestea sunt ţinute secrete. Dacă un atacator

poate primi acces la parola unui utilizator, Kerberos nu poate distinge între cei doi. O

problemă oarecum înrudită a Kerberos V5 este și faptul că nu e rezistent la atacuri reply.

Protocolul SESAME

Protocolul SESAME (Secure European System for Applicxations in a Multivendor

Environment) este rezultatul unui proiect al Asociației Fabricanților Europeni de Calculatoare

(ECMA – European Computer Manufacturer Asociation) propus pentru optimizarea și

extinderea protocolului Kerberos pentru controlul distribuit al accesului în rețea. SESAME

foloseste o tehnică de autorizare și control al accesului similară celei aplicate de protocolul

Kerberos, cu autentificare a clientului de către AS. Suplimentar, este necesară și autentificarea

de către un server de privilegii (PAS – Privilege Attribute Server) care eliberează un certificat

de privilegii (PAC – Privilege Attribute Certificate) după prezentarea unei dovezi de

autenticitate. Certificatul este semnat cu cheia privată a serverului emitent. În certificat se

specifică identitatea și rolul utilizatorului, grupul organizațional căruia îi aparține, permisiuni

și restricții impuse, condiții de utilizare a certificatului. După obținerea certificatului, clientul

se adresează serverului KDS (Key Distribution Center Server), conform RFC 3634, pentru

obținerea tichetului de serviciu.

25

SESAME a adoptat terminologia introdusă de cadrele de securitate ISO/IEC. În particular, se foloseşte termenul de partener pentru a referi o persoană sau entitate înregistrată

şi autentificabilă. Când joacă un rol activ (spre exemplu când solicită acces), partenerul se

numeşte iniţiator. Când joacă un rol pasiv (spre exemplu este accesat), partenerul se numeşte

ţintă. Un serviciu este un set abstract de funcţionalităţi care poate fi implementat de un număr

de servere separate. Referindu-ne la modelul client / server, componentele aplicaţiei client

joacă rolul de iniţiatori comunicând cu componentele aplicaţiei server care joacă rolul de

ţintă.

Obiectivul primar al proiectului SESAME este producerea de tehnologie pentru controlul

accesului în sisteme distribuite, adică să ofere servicii de autentificare, control al accesului,

confidenţialitate şi integritate a datelor.

Arhitectura sistemului SESAME folosește o ierarhie de chei cu două niveluri:

o cheie simplă - stabilită și utilizată între un SACM inițiator și PVF-ul SACM-ului țintă, pentru a proteja PAC-urile corespunzătoare precum si informațiile de stabilire a

cheilor.