Tehnici criptograficeCrudu Victor, USM

În general, criptologia1 se referă la ştiinţa comunicării secretizate. Aceasta cuprinde atât criptografia cât şi criptanaliza.Funcţii de dispersie cu sens unicFuncţiile cu sens unic sunt foarte importante în criptologie. Pe înţelesul tuturor, funcţiile cu sens unic sunt uşor de calculat dar greu de inversat. Matematic, acest lucru se spune astfel:Funcţia f : A › B este o funcţie cu sens unic dacă f(x) se calculează uşor pentru toate valorile x A, dar este nefezabil din punct de vedere al timpului de calcul când se dă y f(A) = B să se găsească un x A astfel încât f(x) = y. Această definiţie nu este precisă în sensul matematic deoarece nu defineşte termenii „uşor” şi „nefezabil”. Este important de arătat că existenţa funcţiilor cu sens unic este o presupunere care nu a fost încă dovedită. Nu este în general necesar ca o funcţie cu sens unic să fie injectivă, valori distincte iniţiale putând să conducă la acelaşi rezultat. O funcţie cu sens unic f : A › B pentru care |B| << |A| se mai numeşte funcţie de dispersie cu sens unic. Dacă în plus faţă de aceste condiţii este greu să se obţină x1, x2 A distincte astfel încât f(x1) = f(x2), atunci f este o funcţie de dispersie cu sens unic rezistentă la coliziuni. Exemple de astfel de funcţii sunt MD4 (Rivest, 1992), MD5 (Rivest şi Dusse, 1992) şi SHS (Secure Hash Standard) propus de U.S. National Institute of Standards and Technology (NIST).Criptografia cu chei secreteÎn criptografia cu chei secrete, o cheie este aleasă între participanţi şi este folosită pentru criptarea şi decriptarea mesajelor. De aceea, criptografia cu chei secrete se mai numeşte criptografie simetrică. Criptografia cu chei secrete se folosesc de mii de ani într-o varietate de forme. Implementările moderne iau de obicei forma unui algoritm care se execută în hardware, firmware sau software. Majoritatea de astfel de criptosisteme se bazează pe operaţii simple cum ar fi permutări şi transpoziţii, dar este extrem de dificil să se creeze un system rezistent la atacuri, în ciuda faptului că istoria eşecurilor este lungă şi bogată. Exemple de sisteme de criptografie cu chei secrete utilizate pe scară largă în lume sunt: AES2, DES3, triple DES, IDEA4, RC2, RC4, RC55. Algoritmul FEAL6 nu se mai foloseşte datorită vulnerabilităţii la criptanaliză diferenţială.

Criptografia cu chei publiceIdeea funcţiilor cu sens unic a dus la inventarea criptografiei cu chei publice de către Diffie şi Hellman în 1976. Din punct de vedere practic, criptografia cu chei publice presupune existenţa unei perechi de chei legate matematic. Una dintre ele se numeşte cheie publică şi trebuie publicată – fără a afecta securitatea sistemului – iar cealaltă este cheia privată care nu trebuie să fie deconspirată în nici un fel. [DIFF88] Derivarea cheilor una dintr-alta este nefezabilă din punct de vedere computaţional. Cel mai folosit sistem cu chei publice este RSA, inventat în 1978 de Rivest, Shamir şi Adelman la Massachusetts Institute of Technology (MIT).AutentificareaÎn general, autentificarea se referă la procesul de verificare a identităţii unei părţi. Autentificarea rezultă în autenticitate, însemnând că partea care verifică (verificatorul) poate fi sigur că partea verificată (verificatul) este cel care spune că este. Uzual, aşa cum am expus în introducere, tehnicile de autentificare se împart în trei categorii fundamentale:1Autentificare prin cunoştinţe (ceva ce utilizatorul ştie: coduri PIN, coduri de tranzacţie, parole)1Autentificare prin posesie (ceva ce utilizatorul are: chei, carduri de identificare sau alt fel de dispozitive fizice)1Autentificare prin proprietăţi (identificarea biometrică a utilizatorului cum ar fi identificarea feţei, imagini ale retinei, şabloane vocale, amprente) În tehnica de calcul actuală autentificarea preponderentă este cea prin cunoştinţe.Autentificarea bazată pe parole

În cele mai multe sisteme distribuite şi reţele de calculatoare, protecţia resurselor se realizează prin login direct folosind parole, cu transmiterea în clar a acestora. Această autentificare are mai multe inconveniente, din care amintim doar câteva:2Utilizatorii tind să selecteze parole neuniform distribuite. Această problemă este binecunoscută şi nu este neapărat legată de reţele de calculatoare şi sisteme distribuite.2Nu este convenabil pentru un utilizator care are mai multe conturi pe hosturi diferite să îşi amintească parola pentru fiecare, şi de asemenea să o introducă la fiecare schimbare a host-ului. În schimb, utilizatorul va allege să fie recunoscut de reţea ca întreg şi nu de host-urile individuale.2Transmisia parolei este expusă la captură pasivă.

În principal datorită acestui ultim punct, autentificarea bazată pe parolă nu este potrivită în reţele de calculatoare şi sisteme distribuite. Parolele trimise prin reţea sunt foarte uşor compromise şi folosite ulterior pentru impersonarea utilizatorului.În unele situaţii este chiar supărător că se foloseşte autentificarea prin parolă. Spre exemplu, în Statele Unite ale Americii telefoanele mobile folosesc ca parolă internă la efectuarea unui apel chiar numărul telefonului respectiv pentru ca centrala să poată factura fiecare apel în mod corect. Este evidentă că un atacator poate impersona uşor apelul şi poate efectua convorbiri în contul altei persoane.Autentificarea bazată pe adresăO alternativă – nu neapărat mai sigură – la autentificarea prin parolă este autentificarea prin adresă. Aceasta presupune că identitatea unei surse se poate deduce din adresa acesteia conţinută în pachete. Ideea de bază este că fiecare host memorează identitatea celorlalte host-uri care au acces la resursele sale. În UNIX, fiecare host are un fişier numit /etc/hosts.equiv. Utilizatorii cu acelaşi cont pe ambele sisteme pot folosi utilitarele „r” fără a specifica vreo parolă. Ideea de host-uri credibile nu este o soluţie la problema autentificării în reţele de calculatoare. De fapt, acest tip de autentificare chiar pune probleme mai mari din punct de vedere al securităţii. Dacă un atacator reuşeşte să intre pe contul unui utilizator dintr-un sistem, securitatea este compromisă pe toate sistemele care au încredere în acel sistem. În plus, administratorul de sistem nu poate da drepturi preferenţiale unor utilizatori. În funcţie de mediul concret, autentificarea prin adresă este chiar mai puţin sigură decât cea bazată pe parolă. Avantajul îl constituie însă comoditatea în folosire şi de aceea multe sisteme au ales să o implementeze.Autentificarea criptograficăIdeea din spatele autentificării criptografice este că un A îşi dovedeşte identitatea către B prin efectuarea unei operaţii criptografice asupra unei entităţi cunoscute de ambii participanţi sau oferită de B. Operaţia criptografică efectuată de A se bazează pe o cheie criptografică. Aceasta poate fi fie o cheie secretă sau o cheie privată dintr-un sistem cu chei asimetrice. În general, autentificarea criptografică este mai sigură decât autentificarea bazată pe parolă sau pe adresă. În schimb, noile tehnici bazate pe dovezi zero-knowledge pot oferi mecanisme de autentificare chiar mai puternice. Aceste tehnici necesită calcule matematice destul de complexe dar prezintă mai multe facilităţi attractive pentru autentificare. În primul rând, permit părţii ce se autentifică să dovedească că ştie secretul fără a transfera efectiv informaţia către verificator. În al doilea rând, multe dintre schemele propuse până acum folosesc aceleaşi informaţii publice, evitându-se astfelproblema distribuţiei cheilor care apare în cazul mecanismelor ce folosesc DES şi RSA. În ciuda aparentei simplităţi, proiectarea sistemelor reale este foarte dificilă. O serie de protocoale publicate au prezentat erori de securitate substanţiale sau subtile. În timpul ultimei decade, eforturile de cercetare s-au concentrat în crearea de utilitare pentru dezvoltarea protocoalelor de autentificare şi distribuţie a cheilor cu o anumită asigurare formală a securităţii. Realizările cele mai notabile sunt logica BAN şi logica GNY. În loc de a produce protocoale specifice, aceste metodologii se utilizează pentru a verifica un set de afirmaţii presupus adevărate.

Distribuţia cheilorCele mai multe dintre serviciile de securitate enumerate de arhitectura OSI a securităţii se bazează pe mecanisme criptografice, iar folosirea acestora necesită un management al cheilor corespunzător. Conform OSI, managementul cheilor se ocupă cu „generarea, stocarea, distribuţia, ştergerea, arhivarea

şi aplicarea cheilor în conformitate cu politica de securitate” (ISO/IEC, 1989). Managementul cheilor se efectuează cu protocoale şi multe dintre proprietăţile importante ale acestora nu au nici o legătură cu protocoalele criptografice folosite ci mai degrabă cu structura mesajelor schimbate. Drept urmare, scurgerile de securitate şi vulnerabilităţile nu provin de la algoritmii criptografici slabi ci mai degrabă de la greşeli în proiectarea protocoalelor de la nivelurile mai înalte. Grupul de lucru 802.10 a Institute of Electrical and Electronic Engineers (IEEE) a fost format în mai 1988 pentru a discuta nevoile de securitate a reţelelor locale şi metropolitane. Grupul este sponsorizat de IEEE Technical Committee on Computer Communications şi de IEEE Technical Committee on Security and Privacy. Lucrul a început în mai 1989 iar rezultatul este standardul IEEE 802.10 care suportă trei clase de tehnici de distribuţie a cheilor şi anume distribuţia manuală, distribuţia bazată pe centru şi distribuţia bazată pe certificate. În această lucrare vom adopta aceeaşi clasificare.Distribuţia manuală a cheilorDistribuţia manuală a cheilor foloseşte metode de distribuţie off-line pentru a distribui cheile între perechi sau la mai mulţi participanţi. Distribuţia manuală în general este dificilă şi are probleme de scalabilitate, în plus nu oferă o autentificare alta decât cea oferită în mod implicit. De aceea, siguranţa metodelor de distribuţie off-line este extrem de importantă. În multe cazuri, distribuţia manuală a cheilor este necesară doar o singură dată pentru un utilizator anume. Distribuţia materialelor adiţionale se face folosind cheia distribuită manual ca o cheie de cifrare a cheilor (KEK – Key Encryption Key). Materialele astfel cifrate se distribuie apoi prin orice canal convenabil. Distribuţia manuală este adesea cea mai eficientă metodă pentru distribuţia cheilor de grup, în special în cazul grupurilor mari.Distribuţia bazată pe centruTehnicile de distribuţie bazate pe centru se folosesc pentru a distribui chei între două sau mai multe părţi prin intermediul unui terţ credibil. Partea terţă poate fi:3Un centru de distribuţie a cheilor (KDC – Key Distribution Center)3Un centru de translaţie a cheilor (KTC – Key Translation Center)Distribuţia bazată pe centru acoperă atât KDC-urile cât şi KTC-urile. Acestea depind de KEK pentru a furniza confidenţialitatea şi protecţia integrităţii cheilor distribuite.

Cele mai multe metode de distribuţie a cheilor au fost proiectate având în vedere scenarii şi aplicaţii specifice. Spre exemplu, orice schemă care se bazează pe amprente de timp favorizează mediul local, unde toţi utilizatorii au acces la un server de timp credibil. Cerinţa de a avea ceasuri sincronizate în reţele mari nu este absurdă, dar este cu siguranţă dificil de asigurat. Mai important este că schemele existente fac presupuneri despre configuraţia reţelei şi modelele de conectivitate. Spre exemplu, acestea pot cere o anumită paradigmă în contactarea unui server credibil sau KDC. Când A necesită o cheie pentru a comunica cu B, Kerberos – spre exemplu – cere ca A să obţină o cheie de la KDC înainte de a comunica cu B. Această paradigmă se mai numeşte modelul „trage”, ilustrat în figura 6.În contrast, în aceeaşi situaţie, standardul american pentru managementul cheilor instituţiilor financiare (ANSI X9.17), cere ca A să contacteze mai întâi pe B, apoi B obţine cheia necesară de la KDC. Această paradigmă se numeşte modelul „împinge”, ilustrat în figura 7.

Este important de remarcat că nici unul dintre aceste modele nu este superior faţă de celălalt, fiecare fiind potrivit în mediul său. În reţele locale, pentru care Kerberos a fost proiectat, cerinţa ca clienţii să obţină cheile are sens deoarece distribuie efortul care altfel ar fi preluat de doar câteva servere. Într-o reţea mare, se adoptă metoda opusă deoarece tipic sunt mult mai mulţi clienţi decât servere şi KDC-urile se află mai apropiate de acestea. În aceste condiţii, costul conectivităţii între clienţi şi KDC necesitată de Kerberos devine prohibitiv.

Există şi posibilitatea de a combina cele două metode, ca în figura 8.

Distribuţia bazată pe certificatTehnicile de distribuţie bazate pe certificat se pot utiliza pentru stabilirea perechilor de chei criptografice. Distingem două tipuri de astfel de tehnici:4Criptosistem cu chei publice folosit pentru a cripta o cheie generată local pentru a o proteja în timpul transferului către o entitate de management a cheilor. Această metodă se numeşte transferul cheilor.4O cheie criptografică este generată în mod cooperativ atât la entitatea locală cât şi la cea îndepărtată. Această metodă se numeşte schimb de chei sau convenire asupra cheilor.În general, distribuţia bazată pe certificat nu se poate utiliza pentru stabilirea cheilor într-un mediu multicast. Odată stabilite cheile perechi, acestea se pot folosi totuşi pentru distribuirea cheilor multicast. Recomandarea X.509 a ITU-T descrie schema distribuţiei bazată pe certificat, unde o autoritate de certificare (CA) autentifică cheile principale. CA-uri diferite se pot autentifica reciproc, rezultând un graf conectat de CA-uri. Punctul iniţial de credibilitate pentru un utilizator este CA-ul care l-a înregistrat. 2.Protocolul Kerberos V4Protocolul 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:

5Utilizarea amprentelor de timp, aşa cum au propus Denning şi Sacco5Adăugarea unui serviciu de oferire a biletelor pentru a permite autentificarea suplimentară fără a fi necesar ca utilizatorul să-şi reintroducă parola5O abordare diferită a autentificării inter-domeniiAvând în vedere figura nr. 9, paşii protocolului Kerberos V4 se poate formaliza după cum urmează:1. C AS : U, TGS, T, L2. AS C : {K, N, Tc,tgs} Ku3. C TGS : S, N, Tc,tgs, Ac,tgs4. TGS C : {Tc,s, K’} K5. C S : Tc,s, Ac,s6. 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 bilet 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:5Schimbul AS între client şi AS (paşii 1 şi 2)5Schimbul TGS între client şi TGS (paşii 3 şi 4)5Schimbul AP între client şi serverul de aplicaţii (paşii 5 şi 6)În cele ce urmează vom discuta aceste schimburi.Schimbul ASSchimbul AS al protocolului Kerberos V4 este ilustrat în figura 10. Pe scurt, 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.Schimbul TGSSchimbul TGS al protocolului Kerberos V4 este ilustrat în figura 11. 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. Prima dată se încearcă a se obţine un TGT pentru domeniul destinaţie de la un server Kerberos local, prin trimiterea mesajului KRB_TGS_REQ. Acesta poate returna un TGT pentru domeniul în cauză, caz în care C îl poate folosi. Alternativ, serverul Kerberos poate returna un TGT pentru un domeniu mai apropiat de cel solicitat, caz în care procesul trebuie repetat pentru acest domeniu, specificat în TGT. În cazul în care nu se primeşte nici un răspuns, se încearcă obţinerea TGT-ului de la un domeniu mai sus în ierarhie. În pasul 3, C trimite mesajul KRB_TGS_REQ (Kerberos ticket granting server request) către TGS. Mesajul include S, N, Tc,tgs şi un autentificator Ac,tgs = {C, T} K, cu T amprentă de timp. De remarcat că Tc,tgs poate avea o viaţă relativ lungă şi poate fi capturat şi redat. Scopul autentificatorului este să arate că C ştie cheia secretă şi deci să contracareze un astfel de atac. Utilizarea autentificatorilor necesită o sincronizare relativ precisă a ceasurilor, diferenţa admisibilă fiind configurabilă la fiecare server. De regulă, aceasta este configurată la 5 minute, dar în practică aceasta s-a dovedit mult mai problematică. Odată cu introducerea protocoalelor de sincronizare temporală a fost posibilă sincronizarea mult mai precisă.

Mesajul KRB_TGS_REQ este procesat într-o manieră similară cu mesajul KRB_AS_REQ dar se fac o serie de verificări suplimentare. În pasul 4, TGS-ul returnează un mesaj KRB_TGS_REP (Kerberos ticket granting server reply) care are acelaşi format cu mesajul KRB_AS_REP. Acesta include un bilet

Tc,s pentru serverul cerut S şi o nouă cheie de sesiune K’, ambele codificate cu K. Când mesajul KRB_TGS_REP este recepţionat de C, este procesat în aceeaşi manieră cu KRB_AS_REP, aşa cum s-a descries mai înainte. Principala diferenţă este că partea cifrată a răspunsului trebuie decodificată cu cheia de sesiune cunoscută de TGS şi nu cu cheia utilizatorului.Schimbul APSchimbul AP din protocolul Kerberos V4 este ilustrat în figura 12. Acesta este utilizat de aplicaţii de reţea fie pentru a autentifica un client faţă de un server sau să se autentifice reciproc. Clientul trebuie să aibă deja credenţiale pentru server prin utilizarea schimburilor AS şi TGS. În pasul 5, C trimite mesajul KRB_AP_REQ (Kerberos Application Request) către serverul S. Mesajul include Tc,s, Ac,s = {C, T’} K’ şi unele informaţii de management. Autentificarea se bazează pe timpul curent al serverului, biletul Tc,s şi autentificatorul Ac,s. Pentru a ne se asigura că mesajul KRB_AP_REQ nu este o redare a unui mesaj recent, este îndeajuns ca S să memoreze toate amprentele de timp într-o fereastră dată şi să se asigure că mesajul nu are o amprentă de timp identică cu cele anterior recepţionate. Orice autentificator mai vechi decât fereastra de timp permisă ar fi respins oricum, deci nu ar fi folositor a se memora amprente mai vechi decât această fereastră. Kerberos V4 însă nu se complică să memoreze amprente de timp, aceasta deoarece dacă S este un serviciu replicat în care toate instanţele împart aceeaşi cheie master, ar fi relativ uşor pentru un atacator să trimită un mesaj de la o instanţă S1 către o altă instanţă S2. Rezolvarea simplă a acestei probleme ar fi ca autentificatorul să conţină şi identificatorul nivelului de reţea a instanţei S în cauză. Dacă nu apare nici o eroare şi dacă este necesară autentificarea reciprocă, S trebuie să returneze lui C mesajul KRB_AS_REP (Kerberos application reply) în pasul 6. Din nou, acest mesaj este codificat cu cheia de sesiune K’, cunoscută de C şi S. Din moment ce această cheie a fost în biletul codificat cu cheia secretă a serverului, posesia acesteia este dovada că S este partenerul dorit. Mai precis, S trebuie să incrementeze amprenta de timp inclusă în autentificatorul mesajului KRB_AP_REQ şi să-l recodifice cu K’.

Confidenţialitatea datelor şi servicii de integritateAşa cum a fost descris anterior, Kerberos furnizează servicii de autentificare. Totuşi, un „produs” auxiliar al protocolului este schimbul unei chei de sesiune K’, cunoscută de client şi de server. Această cheie poate fi utilizată de aplicaţie pentru a proteja confidenţialitatea şi integritatea comunicaţiilor. De fapt, sistemul Kerberos oferă două tipuri de mesaje, şi anume:7Mesajul KRB_PRIV pentru a proteja confidenţialitatea comunicaţiilor.7Mesajul KRB_SAFE pentru a proteja integritatea comunicaţiilor. În ciuda acestor tipuri de mesaje oferite de sistem, o aplicaţie este liberă să utilizeze orice metodă potrivită pentru tipul particular de date care se transmite. Formatul acestor mesaje nu va fi detaliat mai mult aici.

3.Protocolul Kerberos V5În această secţiune ne vom concentra asupra Kerberos V5 în general şi a diferenţelor importante faţă de Kerberos V4. În Kerberos V5 au fost operate următoarele modificări:

8Identificatorii 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âtecomponente 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.8Utilizarea 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 de asemenea au sarcina de a oferi siguranţa integrităţii, prin folosirea unor metode adecvate, cum ar fi suma de control.8Adrese 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.8Codificarea 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.8Formatul 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.8Suport 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.În plus faţă de acestea, Kerberos V5 mai aduce o serie de îmbunătăţiri. Spre exemplu, câmpurile indicatoare menţionate anterior permit o flexibilitate mai mare în utilizarea biletelor decât în versiunea V4. Fiecare bilet emis de AS în schimbul iniţial este marcat ca atare. Aceasta permite serverelor să ceară clientului să prezinte un bilet obţinut prin folosirea directă a cheii secrete a clientului în locul cheii obţinute folosind un TGT. O astfel de cerinţă împiedică un atacator să schimbe parola unui utilizator de la o staţie neutilizată dar loginată.În Kerberos V5, biletele pot fi eliberate cu două date de înnoire. Biletul expiră ca de obicei la primul timp, dar dacă TGS primeşte o cerere de înnoire înainte de expirarea acestuia, biletul emis ca înlocuitor este valabil pentru încă o perioadă de timp. Totuşi, TGS-ul nu va reînnoi un bilet după expirarea celui de al doilea timp. Acest mecanism prezintă avantajul că deşi credenţialele se pot utiliza o perioadă lungă de timp, TGS-ul ar putea refuza să reînnoiască bilete raportate ca furate şi astfel să împiedice folosirea lor în continuare.Kerberos se ocupă în principal cu autentificarea şi nu este în mod direct preocupat de servicii de securitate înrudite cum ar fi autorizarea şi contabilitatea. Pentru a sprijini implementarea acestor servicii de securitate, Kerberos V5 oferă un mecanism de transmisie sigură a informaţiilor de autorizare şi contabilitate ca parte a unui bilet. Acestea pot restricţiona utilizarea unui bilet. Când se solicită un bilet, restricţiile sunt specificate şi trimise unui TGS unde sunt incluse în bilet, codificate şi protejate de modificare. În forma cea mai generală a protocolului, un client cere ca KDC să includă sau adauge astfel de informaţii la bilet. TGS-ul la rândul lui nu îndepărtează informaţia de autorizare din TGT, ci o copiază în fiecare bilet nou şi adaugă informaţii adiţionale. La decodificarea biletului, informaţiile de autorizare sunt disponibile la serverul de aplicaţii. Kerberos nu face nici o interpretare a acestor informaţii, în schimb serverul de aplicaţii trebuie să le folosească pentru a restricţiona accesul clienţilor la resursele prezentate în bilet. Având în vedere figura 9, paşii protocolului Kerberos V5 se pot formaliza după cum urmează:1. C AS : U, TGS, L1, N12. AS C : U, Tc,tgs, {TGS, K, Tstart, Texpire, N1} KU3. C TGS : S, L2, N2, Tc,tgs, Ac,tgs4. TGS C : U, Tc,s, {S, K’, T’start, T’expire, N2} K5. C S : Tc,s, Ac,s6. S C : {T’} K’

Analog cu Kerberos V4, Tc,tgs şi Tc,s se referă la un TGT respectiv un bilet, 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:9Dacă pre-autentificarea trebuie realizată9Dacă biletul solicitat se poate re-înnoi sau re-trimite.9Dacă biletele derivate ar trebui să fie postdatate sau să permită postdatarea.9Dacă 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, 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 autentificareconstau î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. Din nou, 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 biletului. 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. 4. Protocoale criptografice KKÎn această secţiune vom face o prezentare generală a protocoalelor KK. În particular, ne vom îndrepta atenţia în autentificarea a două părţi şi distribuţia cheilor, distribuţia cheilor a trei părţi, distribuţia cheilor inter-domeniu şi protocoalele single signon.Autentificarea a două părţiProtocolul de autentificare a două părţi (2PAP1) este la baza protocoalelor KK. Acesta specifică protocolul provocare – răspuns care permite ca doi participanţi A şi B să se autentifice reciproc. 2PAP poate fi formalizat după cum urmează:1. A B : Na2. B A : Nb, (Na, Nb, B) Kba3. A B : (Na, Nb) KabÎn această descriere a protocolului, originea şi receptorul mesajului sunt omise în corpul mesajelor deoarece pot fi deduse din informaţia de adresare din reţea. Na şi Nb sunt valori alese aleator de către A respectiv B. Notaţia (m) K înseamnă un MAC calculat din mesajul m şi codificat cu cheia K. Similar, (Na, Nb, B) Kba se referă la un MAC calculat prin concatenarea componentelor Na, Nb şi B şi codificarea acestora cu cheia secretă Kba. Dacă atât (Na, Nb, B) Kba cât şi (Na, Nb) Kab sunt implementate cu un sistem de chei private, Kba şi Kab sunt acelaşi lucru. Dacă in schimb se utilizează

DES în modul CBC pentru autentificare, atunci termenul (Na, Nb, B) Kba abreviază de fapt {{{Na}Kba Nb} Kba B} Kba, iar (Na, Nb) Kab abreviază {{Na} Kab Nb} Kab. În loc de a utiliza un criptosistem pentru a calcula şi verifica MAC-urile, se poate utiliza o funcţie de dispersie cu sens unic cu cheie în loc, aşa cum s-a menţionat anterior. În acest caz, (Na, Nb, B) Kba se referă la h(Kba, Na, Nb, B) pentru metoda prefixului secret, h(Na, Nb, B, Kba) pentru metoda sufixului secret şi h(Kba, Na, Nb, B, Kba) pentru metoda plicului. Întorcându-ne la 2PAP, A oferă lui B o valoare Na în pasul 1 şi B răspunde cu o altă valoare Nb împreună cu (Na, Nb, B) Kba în pasul 2. A poate utiliza acum Kba pentru a verifica MAC-ul şi pentru a-l autentifica pe B. Dacă B se consideră a fii autentic, A îi oferă lui B cantitatea (Na, Nb) Kab care este un alt MAC calculat din concatenarea lui Na şi Nb cu cheia secretă Kab în pasul 3. B poate folosi acum Kab pentru a verifica MAC-ul şi pentru a-l autentifica pe A. Dezvoltatorii protocolului 2PAP original au arătat că acesta este într-adevăr rezistent la atacuri prin întreţesere şi toate protocoalele KK moştenesc această proprietate. Cu alte cuvinte, dacă se poate dovedi că un protocol este echivalent cu 2PAP, putem spune că moşteneşte proprietăţile acestuia, inclusiv rezistenţa la atacuri de întreţesere.Distribuţia cheilor între două părţiObiectivul protocolului de distribuţie a cheilor între două părţi (2PKDP) este să permită unei părţi A care o cheie Ka cunoscută de un centru de distribuţie a cheilor (KDC) să obţină o nouă cheie Ka new. Presupunerile care au condus la proiectul protocoalelor KK de distribuţie a cheilor sunt după cum urmează:10O cheie este întotdeauna generată de o singură parte10O cheie care se distribuie trebuie să fie o cantitate aleatoare şi imprevizibilă. Dacă A şi B se angajează într-un protocol de distribuţie a cheilor şi A generează o cheie, atunci nici B şi nici altă parte nu trebuie să fie capabilă de a deduce cheia.10Cheile nu se reutilizează niciodată.1 Two-party Authentication Protocol

Aceste presupuneri au dus la observaţia importantă că o cheie este conceptual similară cu o valoare unică. De fapt, singura diferenţă între o cheie nouă distribuită în 2PKDP şi o valoare folosită in 2PAP este că valoarea se comunică în clar în timp ce cheia trebuie comunicată secretizat. Familia de protocoale KK cuprinde astfel două 2PKDP-uri: primul oferă confidenţialitatea cheilor şi altul oferă integritatea şi autenticitatea cheilor.Protocolul de distribuţie a cheilor între două părţi (2PKDP1)Având în vedere cele expuse anterior, protocolul 2PKDP se poate deriva uşor din 2PAP prin simpla înlocuire a lui B cu KDC. Protocolul rezultat se poate formaliza după cum urmează:1. A KDC : Na2. KDC A : Nk, (Na, Nk, KDC) Ka Kanew3. A KDC : (Na, Nk) KaSimilar cu protocolul 2 PAP, A oferă KDC o valoare Na în pasul 1. KDC selectează aleator o altă valoare Nk şi o nouă cheie secretă Ka new pentru A, calculând apoiun MAC din ambele valori şi identificatorul propriu, rezultatul adunându-se modulo 2 la noua cheie secretă Ka new. În pasul 2, KDC trimite lui A atât Nk cât şi (Na, Nk, KDC) Ka Ka new. De remarcat că în acest punct că un atacator care e capabil să captureze mesajul nu poate să extragă nici o informaţie dacă nu cunoaşte cheia secretă a lui A, Ka. A poate utiliza acum Ka şi Nk pentru a calcula (Na, Nk, KDC) Ka şi foloseşte acest MAC pentru a extrage Ka new din (Na, Nk, KDC) Ka Ka new. În pasul 3, A poate trimite lui KDC un alt MAC calculat din ambele valori Na şi Nk cu Ka. De remarcat că spre deosebire de 2PAP, pasul 3 nu este neapărat necesar în 2PKDK.Protocolul de distribuţie a cheilor între două părţi autentificate(2PAKDP2)Protocolul 2PKDP descris anterior este sigur în sensul confidenţialităţii cheilor, aceasta însemnând că nimeni în afară de KDC şi A nu poate obţine Ka new

Totuşi, protocolul nu este nu este sigur în sensul integrităţii cheilor şi al autenticităţii. Cu alte cuvinte, un intrus ar putea modifica mesajul returnat de KDC către A în pasul 2 şi să provoace extragerea unei chei false din mesaj. Problema rezidă în faptul că A nu are nici o metodă să afle dacă mesajul recepţionat este întreg şi autentic, sau mai mult, KDC-ul ar putea să nici nu fie disponibil şi întreg mesajul să fi fost produs de un intrus.În acest moment trebuie remarcat că această vulnerabilitate nu este un eşec al protocolului, deoarece un intrus nu poate schimba cheia la o valoare cunoscută. Tot ce poate face intrusul este să modifice cheia cu o cantitate aleasă aleator, dar această vulnerabilitate este rezolvată în protocolul 2PAKDP:1. A KDC : Na2. KDC A : MAC(A), {MAC(A)} Ka Nk3. A KDC : (Na, Nk) KaProtocolul 2PAKDP este foarte similar cu 2PKDP. Notaţia MAC(A) abreviază (Na, Nk, KDC) Ka.Distribuţia cheilor între trei părţiObiectivul general al protocolului de distribuţie a cheilor între trei părţi (3PKDP) este distribuirea unei chei de sesiune de la un KDC către A şi B. Un protocol 3PKDP sigur trebuie să satisfacă aceleaşi condiţii ca şi protocolul 2PKDP cu condiţia suplimentară ca nici una dintre părţi să nu fie capabilă să altereze cheia distribuită. Din moment ce iniţial A şi B nu au în comun nici o cheie secretă care ar putea fi folosită ca o cheie de sesiune, aceştia trebuie să contacteze KDC, cu care fiecare are o cheie secretă. KDC-ul oferă părţilor A şi B bilete. În NetSP, un bilet se referă la un mesaj trimis de un KDC într-un mesaj al 3PKDP. Această terminologie diferă uşor de cea folosită de Kerberos. În legătură cu distribuţia cheilor celor trei părţi, în general nu este necesar ca ambele părţi să contacteze KDC-ul. În funcţie de cine contactează primul KDC-ul şi în funcţie de modelul folosit (împinge sau trage), au fost proiectate mai multe protocoale de tip 3PKDP, pe care le vom prezenta în continuare.

Scenariul A-B-KDCÎn scenariul A-B-KDC se presupune că A este fie incapabil, neautorizat său nu vrea să contacteze KDC, şi că B trebuie să îl înlocuiască pe A. Acest scenariu se poate realiza prin combinarea a două execuţii 2PAKDP (una între A şi KDC, una între B şi KDC) şi o execuţie a 2PAP (între A şi B). Protocolul 3PKDP este formalizat după cum urmează:1. A B : Na2. B KDC : Na, Nb, A3. KDC B : MAC(A), {MAC(A)}Ka Kab : MAC(B), {MAC(B)}Kb Kab4. B A : MAC(A), {MAC(A)}Ka Kab : Nb, (Na, Nb, B) Kab5. A B : (Na, Nb) Kab, [(Na, Kab) Ka]6. B KDC : [(Na, Kab) Ka, (Nb, Kab) Kb]Scenariul KDC-A-BÎn scenariul KDC-A-B, A îl contactează pe B înainte de a solicita bilete de la KDC. Acest scenariu se poate formaliza după cum urmează:1. A B : Na2. B A : Nb, (Na, Nb, B) Kb3. A KDC : Na, Nb, B, (Na, b, B) Ka, A unde b = (Na, Nb, B) Kb4. KDC A : MAC(A), {MAC(A)} Ka Kab, MAC(B), {MAC(B)} Kn Kab5. A B : MAC(B), {MAC(B)}Kb Kab, [(Na, Nb, B) Kab]Distribuţia cheilor inter-domeniiÎn principiu, toate protocoalele 3PKDP se pot extinde pentru a suporta distribuţia cheilor inter-domenii. Dacă ne amintim de modelul Kerberos, este sarcina clientului să solicite toate biletele necesare pentru a contacta un server într-un domeniu îndepărtat. Acest lucru presupune relativ multă muncă din partea clienţilor, ceea ce face Kerberos potrivit pentru medii locale. Totuşi, există unele medii unde această abordare se dovedeşte

greoaie sau nu se poate aplica deloc. Obiectivul fixat iniţial, acela de maximă flexibilitate a condus la proiectarea protocolului KK de distribuţie inter-domeniu a cheilor. Asemănător cu modelul Kerberos, se presupune că există deja cheile interdomeniu. O cheie inter-domeniu se referă la o cheie cunoscută de KDC-uri şi de domeniile administrative şi de autentificare. Dacă centrele de distribuţie ale cheilor se numesc KDC1 şi KDC2, termenul K12 se referă la cheia inter-domeniu folosită de cele două în autentificarea şi distribuţia cheilor. Deşi folosirea literelor majuscule implicăfolosirea criptografiei cu chei secrete, nu este nici un motiv pentru care criptografia cu chei publice să nu poată fi folosită. De fapt, utilizarea criptografiei cu chei publice poate fi transparentă pentru părţi şi doar KDC-ul să fie implicat. Pe lângă multele avantaje, cel mai clar dezavantaj este mărirea lungimii mesajelor şi a dimensiunii pachetelor.Comunicarea fără / cu KDCÎn cazul cel mai simplu, se presupune că KDC-urile nu participă la comunicaţia inter-domeniu. De remarcat că în ciuda simplităţii, această presupunere este realistă deoarece în mod normal KDC-ul este un server bine protejat şi comunicarea cu lumea exterioară ar fi doar un risc asumat gratuit. În plus, comunicarea inter-domenii este mai apare de mai puţine ori şi este mai nesigură decât comunicaţia principală. Astfel, încărcarea asupra KDC-ului poate fi redusă mult prin interzicerea comunicaţiei interdomenii. Dacă comunicarea directă între KDC-uri nu este posibilă, soluţia evidentă este ca unul dintre ele să emită ambele bilete, iar celălalt să le translateze în bilete valabile în propriul domeniu. Sunt situaţii în care comunicaţia între KDC-uri este necesară. Spre exemplu, una dintre părţi ar putea să nu aibă o conexiune directă cu KDC-ul său sau altul străin. Comunicaţia între KDC-uri este mai avantajoasă dacă legătura este mai rapidă, mai ieftină sau chiar mai securizată, astfel că ele pot comunica mai bine decât cu părţile. Modificările aduse protocolului 3PKDP pentru a suporta comunicarea prin KDCuri sunt două mesaje adiţionale între KDC-urile implicate. Paşii suplimentari sunt transparenţi pentru părţi iar acestea nu trebuie să diferenţieze între KDC-ul propriu sau cel din alt domeniu. Spre exemplu, protocolul 3PKDP se modifică astfel pentru a suporta comunicarea inter-domenii:1. A B : Na2. B KDC2 : Na, Nb, A3. KDC2 KDC1 : Na, Nb, A, B4. KDC1 KDC2 : MAC(A), {MAC(A)} Ka Kab, MAC(12), {MAC(12)} K12 Kab5. KDC2 B : MAC(A), {MAC(A)} Ka Kab, MAC(B), {MAC(B)} Kb Kab6. B A : MAC(A), {MAC(A)} Ka Kab, (Na, Nb, B) Kab, Na, Nb, A7. A B : (Na, Nb) KabAbrevierile MAC(A), MAC(B), MAC(12) sunt aceleaşi cu cele din protocolul 3PKDP anterior.

5.Protocoale criptografice SPXÎn următoarele secţiuni ne oprim în detaliu asupra iniţializării credenţialelor, schimbul de autentificare şi protocolul de înscriere. Iniţializarea credenţialelorDacă un utilizator doreşte să se delege la staţia sa, el trebuie să posede cheia sa privată pentru a instala credenţialele pretinzătorului. În general nu este realist să cerem utilizatorilor să îşi reamintească cheile private şi nici să poate smart card-uri sau discuri flexibile cu fişiere. S-a menţionat deja că SPX are un LEAF care permite utilizatorilor să-şi obţină cheia privată în formă codificată. Rolul LEAF se diminuează pe măsură ce smart card-urile sau alte dispozitive cu funcţionalitate similară devin disponibile. LEAF nu expune în mod direct cheile private ci doar le expune atacurilor de tip ghicire, deoarece acesta nu cunoaşte în mod direct aceste chei ci le memorează codificate cu DES şi derivate din cheia utilizatorului (KEK – key encryption key) cu ajutorul unei funcţii cu sens unic. Pentru a ajunge să aibă acces la cheia privată, un client trebuie să se preautentifice, această însemnând că trebuie să arate dovada cunoaşterii parolei. Pentru a permite o astfel de preautentificare, LEAF păstrează cheia privată împreună cu semnătura de dispersie a acesteia, utilizând o altă funcţie decât cea utilizată pentru a forma KEK care criptează cheia privată. Ideea este ca dezvăluirea cheii private să se facă doar dacă valoarea de dispersie prezentată de client coincide cu cea memorată.

Schema protocolului de iniţializare a credenţialelor este ilustrată în figura 15.Protocolul constă din şase paşi care se pot formaliza după cum urmează:1. C LEAF : C, {T, Nc, h1(pwd’)}kLEAF2. LEAF CDC : C3. CDC LEAF : {{kC-1}h2(pwd), h1(pwd)}K, {K}LEAF4. LEAF C : {{kC-1}h2(pwd)}Nc5. C CDC : C6. CDC C : C << (TAC) >>Protocolul începe cu presupunerea că utilizatorul care vrea se iniţializeze credenţialele pretinzătorului şi-a introdus deja identificarea sa C şi parola pwd’. C nu este folosit doar pentru a indica identitatea clientului ci este folosit şi în procesul de iniţializare. Acest proces se numeşte login. De remarcat apostroful de la pwd, care înseamnă că parola nu e neapărat corectă în acest moment.În pasul 1, C trimite lui LEAF identificatorul său şi un mesaj codificat cu cheia publică de lungă durată kLEAF. Această cheie se presupune că este instalată pe sistemul folosit de C, cum ar fi într-un fişier de configurare. Mesajul criptat conţine amprenta de timp T, o valoare Nc, şi h1(pwd’), o dispersie a parolei furnizată de C. În pasul 2, LEAF cere unui CDC să i se furnizeze informaţiile de autentificare pentru C. Această informaţie constă din {{kC-1}h2(pwd) şi h1(pwd).În pasul 3, CDC sigilează cu DES această informaţie cu o cheie K aleasă aleator şi furnizează lui LEAF cantităţile {{kC-1}h2(pwd), h1(pwd)}K şi {K}LEAF. Evident, LEAFul poate folosi această cheie privată pe termen lung kLEAF-1 pentru a decodifica {K}kLEAF şi a extrage cheia DES corespunzătoare. LEAF poate folosi K pentru decodificarea {{kC-1}h2(pwd), h1(pwd)}K şi extragerea componentelor {{kC-1}h2(pwd) şi h1(pwd). Dacă dispersia cu sens-unic a parolei din CDC (care este h1(pwd)) se potriveşte cu valoarea primită de la C (care este h1(pwd’)), LEAF ştie că C cunoaşte parola şi este autentic. Altfel se afişează un mesaj de eroare şi se înregistrează acest lucru într-un jurnal. De remarcat că atacul prin ghicire a parolelor necesită cunoaşterea cheii private kLEAF-1 sau contactarea LEAF-ului chiar şi pentru o singură încercare. În consecinţă, SPX se presupune că este mult mai rezistent la atacuri prin ghicire decât alte protocoale.În pasul 4, LEAF codifică {kC-1}h2(pwd) cu valoarea Nc primită în pasul 1 şi transmite rezultatul {{kC-1}h2(pwd)}Nc lui C. Acesta poate acum utiliza Nc şi h2(pwd’) pentru a decodifica cheia sa privată pe termen lung kC-1 şi să folosească această cheie pentru a instala credenţialele pretinzătorului. Pentru a face acest lucru, C selectează aleator o pereche de chei publice de delegare (kc, kc-1) şi generează un bilet de login corespunzător TicketC = {C, kc, L}kC-1. Acesta include identificatorul lui

C, cheia de delegare de scurtă durată şi durata de viaţă a biletului. În plus, biletul este semnat digital cu cheia privată de termen lung al lui C. De acum înainte, C nu-şi mai foloseşte cheia privată de termen lung ci cheia de delegare kc-1.Ultimul lucru pe care C trebuie să-l facă pentru instalarea credenţialelor este să instaleze certificate pentru autorităţile credibile. În pasul 5, C furnizează CDC-ului identificatorul său iar în pasul 6 CDC-ul returnează C << (TAC) >>, care este o listă de certificate pentru autorităţile credibile ale lui C. Certificatele sunt emise de către C şi semnate digital cheia privată a lui C, kC-1. După recepţionarea C << (TAC) >>, C are câte o cheie publică pentru fiecare dintre TA-urile sale. C poate utiliza aceste chei pentru a verifica semnăturile digitale de la TA-uri.Schimbul de autentificareSchimbul de autentificare SPX este ilustrat în figura 16. Protocolul este formalizat după cum urmează:1. C CDC : V2. CDC C : (TAC, V, LV, kV)kTAc-13. C V : C, TicketC, {K}kV, {kc-1}K | {K}kc-1, AuthK4. V CDC : C5. CDC V : (TAV, C, LC, kC)kTAv-16. V C : AuthK’

În pasul 1, pretinzătorul C furnizează CDC-ului identificatorul verificatorului V căruia doreşte să se autentifice iar în pasul 2, CDC furnizează lui C un certificat corespunzător (TAC, V, LV, kV)kTAc-1. De remarcat că TAC este o autoritate credibilă pentru C, iar C are cheia publică ce se foloseşte pentru verificarea semnăturii digitale care se adaugă la certificatul anterior. Dacă semnătura digitală este validă, C extrage cheia publică a lui V (kV) din certificat. În plus faţă de aceasta, C selectează aleator o cheie DES de sesiune K şi foloseşte această cheie pentru a genera un simbol de autentificare. Acest simbol consta din:14C14TicketC = {C, kc, L)kC-114{K}kV14{kc-1}K dacă se solicită delegarea, sau {K}kc-1 altfel14un autentificator AuthK care constă dintr-o amprentă, indicator de direcţie şi legături de canal opţionale, cum ar fi adrese de reţea sau informaţii de context ale aplicaţiei. AuthK este autentificat K.

În pasul 3, C îi furnizează lui V semnul de autentificare generat prin intermediul protocolului de aplicaţie, care în general este diferit de protocolul de reţea situat mai jos în ierarhie. V utilizează credenţialele sale pentru a decodifica simbolul şi pentru a decodifica şi recupera cheia K. În continuare, V foloseşte K şi timpul curent pentru verificarea validităţii autentificatorului. Dacă se solicită delegarea, V decodifică cheia privată de delegare K şi o verifică cu cheia publică din bilet. Altfel, V verifică semnătura cheii codificate folosind cheia publică din bilet.

În acest moment, V a verificat validitatea simbolului de autentificare dar încă trebuie să îi verifice autenticitatea. În pasul 4, V îi furnizează lui CDC identitatea pretinsă a lui C, iar în pasul 5, CDC-ul returnează (TAV, C, LC, kC)kTAv-1 . Remarcăm faptul că acest certificat este analog cu certificatul care a fost returnat lui C în pasul 2. În consecinţă, V poate folosi cheia publică a TAV pentru a verifica semnătura digitală ataşată certificatului şi pentru a extrage kC. Echipat cu această cheie, V poate verifica semnătura digitală care este asociată cu TicketC. Dacă semnătura este validă, V presupune că C este autentic. Dacă se solicită delegarea mai există un pas suplimentar pentru instalarea credenţialelor pretinzătorului folosind biletul şi cheia privată de delegare. Dacă este necesară autentificarea reciprocă, V returnează lui C un alt autentificator Auth’K in pasul 6. În orice caz, C şi V cunosc împreună cheia K ce poate fi utilizată pentru autentificarea originii datelor, a confidenţialităţii şi servicii de integritate a datelor. SPX detectează atacurile replay în schimbul de autentificare prin utilizarea amprentelor de timp în cadrul autentificatorilor cu rememorarea mesajelor anterioare acceptate până când acestea se învechesc. Unul dintre motivele pentru care s-a ales această abordare a fost compatibilitatea cu Kerberos.