-
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.