Reţele de Calculatoare -...

Reţele de Calculatoare Curs 12

1

Reţele de Calculatoare

Curs 12

Obiective:

1. Nivelul aplicație – sistemul numelor de domenii DNS (Domain Name System).

2. Poșta electronică.

3. World Wide Web (WWW).


2

1. Securitate reţelelor de calculatoare – Noţiuni introductive

Problemele securităţii reţelei pot fi împărţite, în mare, în patru domenii strâns interconectate:

confidenţialitate, autentificare, nerepudiere şi controlul integrităţii. Păstrarea secretului,

denumită de asemenea şi confidenţialitate, se referă la păstrarea informaţiei departe de

utilizatorii neautorizaţi. Autentificarea reprezintă determinarea identităţii persoanei cu care

vorbeşti înainte de a dezvălui informaţii importante sau de a intra într-o afacere. Nerepudierea

implică semnături: cum se poate dovedi că un client a făcut într-adevăr o comandă pentru o

anumită sumă, dacă, mai târziu, el pretinde că preţul era altul? Sau poate susţine că nu a făcut

nici o comandă. În fine, cum se poate dovedi faptul că un mesaj primit a fost cel trimis cu

adevărat şi nu unul pe care un adversar l-a modificat în tranzit?

Este important de subliniat faptul că, exceptând securitatea de la nivelul fizic, aproape toate

mecanismele de securitate a reţelelor de calculatoarese bazează pe principii criptografice.

2. Criptografia

Criptografie provine din cuvintele greceşti pentru „scriere secretă”. Profesioniştii fac o distincţie

între cifruri şi coduri. Un cifru este o transformare caracter-cu-caracter sau bit-cu-bit a

mesajului, fără a ţine cont de structura lingvistică a acestuia. Prin contrast, un cod înlocuieşte

un cuvânt cu un alt cuvânt sau cu un simbol.

2.1 Introducere în criptografie

Din punct de vedere istoric, patru grupuri de oameni au contribuit şi au folosit arta criptografiei:

armata, corpurile diplomatice, cei ce au ţinut jurnale şi îndrăgostiţii. Dintre acestea, armata a

avut rolul cel mai important şi a dat contur domeniului de-a lungul secolelor. În interiorul

organizaţiilor militare, mesajele ce trebuiau criptate erau de obicei date pentru criptare şi

transmitere unor funcţionari codori de nivel scăzut, prost plătiţi. Volumul de mesaje nu permitea

ca această muncă să fie făcută doar de câţiva specialişti de elită.

Până la apariţia calculatoarelor, una din marile constrângeri ale criptografiei a fost capacitatea

funcţionarilor codori de a realiza transformările necesare, adeseori pe câmpul de luptă, cu

echipament redus. O constrângere suplimentară a fost dificultatea de comutare rapidă de la o

metodă criptografică la alta, deoarece aceasta implica reantrenarea unui număr mare de

oameni. Totuşi, pericolul ca un funcţionar codor să fie capturat de către inamic a făcut să devină


3

esenţială posibilitatea de a schimba metoda criptografică instantaneu, în caz de necesitate.

Aceste cerinţe antagoniste au dat naştere modelului din Figura 12-1.

Mesajele ce trebuie criptate, cunoscute sub numele de text clar (plain text), sunt transformate

printr-o funcţie parametrizată de o cheie (key). Rezultatul procesului de criptare, cunoscut sub

numele de text cifrat (ciphertext), este apoi transmis, adeseori prin curier sau radio. Se

presupune că inamicul, sau intrusul, ascultă şi copiază cu acurateţe tot textul cifrat. Totuşi, spre

deosebire de destinatarul la care trebuie să ajungă, el nu ştie care este cheia de decriptare şi

astfel nu poate decripta prea uşor textul cifrat. Uneori intrusul poate nu numai să asculte canalul

de comunicaţie (intrus pasiv), ci şi să înregistreze mesajele şi să le retransmită mai târziu, să

injecteze propriile sale mesaje sau să modifice mesajele legitime înainte ca ele să fi fost

preluate de receptor (intrus activ). Arta de a sparge cifruri se numeşte criptanaliză

(cryptanalysis). Arta de a sparge cifruri, denumită criptanaliză şi arta de a le inventa

(criptografia) sunt cunoscute împreună sub numele de criptologie (cryptology).

Figura 12-1 – Modelul de criptare (pentru un cifru cu chei simetrice).

Adesea va fi util o notaţie pentru a pune în relaţie textul clar, textul cifrat şi cheile. Se va folosi

C=EK(P) pentru a simboliza faptul că prin criptarea textului clar P, folosind cheia K, rezultă

textul cifrat C. Similar, P=DK(C) reprezintă decriptarea lui C pentru a obţine din nou textul clar.

Rezultă că:

DK(EK(P))=P

Această notaţie sugerează că E şi D sunt doar nişte funcţii matematice, ceea ce sunt de altfel.

Singura parte mai delicată este aceea că ambele sunt funcţii cu doi parametrii iar noi am scris

unul dintre parametri (cheia) ca indice, nu ca argument, pentru a face distincţie între ea şi

mesaj.

O regulă fundamentală a criptografiei este aceea că trebuie presupusă cunoaşterea de către


4

orice criptanalist a metodelor utilizate pentru criptare şi decriptare. Cu alte cuvinte, criptanalistul

ştie cum lucrează în detaliu metoda de criptare E şi de decriptare D din Figura 12-1. Cantitatea

de efort necesară pentru a inventa, testa şi instala o metodă nouă, ori de câte ori vechea

metodă este compromisă (sau este presupus a fi compromisă), a făcut întotdeauna nepractică

păstrarea secretă a algoritmului de criptare. A crede că este secretă atunci când nu este face

mai mult rău decât bine.

Aici intră în scenă cheia. Cheia constă dintr-un şir (relativ) scurt care selectează una dintre mai

multe criptări posibile. În contrast cu metoda generală, care poate fi schimbată doar o dată la

câţiva ani, cheia poate fi schimbată oricât de des este nevoie. Astfel modelul de bază este stabil

şi metoda generală, cunoscută de toată lumea, este parametrizată cu o cheie secretă şi uşor de

schimbat. Ideea că algoritmii sunt cunoscuţi de criptanalist şi că secretul constă exclusiv în

cheie se numeşte principiul lui Kerckhoff, denumit astfel după criptograful militar flamand

Auguste Kerckhoff care l-a enunţat prima oară în 1883.

Principiul lui Kerckhoff: Toţi algoritmii trebuie să fie publici; numai cheile sunt secrete.

Caracterul nesecret al algoritmului nu poate fi subliniat suficient. Încercarea de a ţine secret

algoritmul, cunoscută în domeniu ca securitate prin obscuritate, nu funcţionează niciodată. De

asemenea, prin publicarea algoritmului, criptograful primeşte consultanţă gratuită de la un

număr mare de criptologi din mediul academic, nerăbdători să spargă sistemul pentru a putea

publica articole care să demonstreze cât de inteligenţi sunt ei. Dacă mulţi experţi au încercat să

spargă algoritmul timp de 5 ani după publicarea lui şi nici unul nu a reuşit, probabil că algoritmul

este destul de solid.

Din moment ce adevăratul secret este cheia, lungimea sa reprezintă un aspect foarte important

de proiectare. Se consideră o simplă combinaţie de seif. Principiul general este că se introduc

cifre în secvenţă. Oricine ştie aceasta, dar cheia este secretă. O lungime a cheii de două cifre

înseamnă că există 100 de posibilităţi. O lungime a cheii de trei cifre înseamnă 1000 de

posibilităţi şi o lungime a cheii de şase cifre înseamnă un milion. Cu cât cheia este mai lungă,

cu atât este mai mare volumul de muncă (work factor) pe care trebuie să-l depună

criptanalistul. Volumul de muncă pentru a sparge sistemul prin căutare exhaustivă în spaţiul

cheilor este exponenţial în raport cu lungimea cheii. Secretul provine din a avea un algoritm

puternic (dar public) şi o cheie lungă.

Din punctul de vedere al criptanalistului, problema criptanalizei are trei variaţiuni principale.

Când are la dispoziţie o cantitate de text cifrat şi nici un fel de text clar, el este confruntat cu

problema textului cifrat (ciphertext only problem). Criptogramele care apar la secţiunea de


5

enigme a ziarelor pun acest tip de problemă. Când criptanalistul are câtva text clar şi textul

criptat corespunzător, problema este cunoscută sub numele de problema textului clar cunoscut (known plaintext problem). În sfârşit, atunci când criptanalistul are abilitatea de a

cripta bucăţi de text clar la propria sa alegere, se ajunge la problema textului clar ales (chosen plaintext problem). Criptogramele din ziare ar putea fi sparte trivial dacă

criptanalistului i s-ar permite să pună întrebări de genul: Care este criptarea pentru

ABCDEFGHIJKL?

Novicii în domeniul criptografiei presupun adeseori că dacă un cifru poate rezista unui atac de tip text cifrat (ciphertext only attack), el este sigur. Această presupunere este foarte naivă. În

multe cazuri criptanalistul poate ghici corect unele părţi din textul clar. De exemplu, primul lucru

pe care multe sisteme îl afişează atunci când sunt accesate este login: . Echipat cu câteva

perechi de text clar text criptat potrivit, sarcina criptanalistului devine mult mai uşoară. Pentru a

obţine securitatea, criptograful trebuie să fie prudent şi să se asigure că sistemul este rezistent,

chiar dacă inamicul său poate cripta cantităţi arbitrare de text clar ales.

Metodele de criptare au fost istoric împărţite în două categorii: cifruri cu substituţie şi cifruri cu

transpoziţie.

2.2 Cifrurile cu substituţie

Într-un cifru cu substituţie fiecare literă sau grup de litere este înlocuit pentru a-l deghiza, cu altă

literă sau grup de litere. Unul dintre cele mai vechi cifruri cunoscute este Cifrul lui Caesar,

atribuit lui Julius Caesar. În această metodă, a devine D, b devine E, c devine F, ..., z devine C.

De exemplu, cuvântul attack devine DWWDFN. În exemple textul clar va fi scris cu litere mici,

iar textul cifrat va fi scris cu majuscule.

O uşoară generalizare a cifrului lui Caesar permite alfabetului textului cifrat să fie deplasat cu k

litere, în loc de a fi deplasat întotdeauna cu 3. În acest caz, k devine o cheie pentru metoda

generală a alfabetelor deplasate circular. Cifrul Caesar este posibil să îl fi păcălit pe Pompei,

dar de atunci el nu mai păcăleşte pe nimeni.

Următoarea îmbunătăţire este de a stabili o corespondenţă pentru fiecare simbol din textul

clar,pentru simplitate se denumesc cele 26 de litere, cu o altă literă. De exemplu:

textul clar: a b c d e f g h i j k l m n o p q r s y u v w x y z

textul cifrat: Q W E R T Y U I O P A S D F G H J K L Z X C V B N M

Sistemul general de substituire simbol-cu-simbol este denumit substituţie monoalfabetică (monoalphabetic substitution), cheia fiind şirul de 26 de litere corespunzând întregului


6

alfabet. Pen tru cheia anterioară, textul clar attack va fi transformat în texul cifrat QZZQEA.

La prima vedere, acesta ar putea fi considerat un sistem sigur deoarece, deşi criptanalistul

cunoaşte sistemul general (substituţie literă cu literă), el nu cunoaşte care dintre cele 26! ≈ 4 ×

1026 chei posibile este folosită. Spre deosebire de cifrul lui Caesar, încercarea tuturor cheilor

nu este o abordare prea promiţătoare. Chiar şi la 1 ns per soluţie, unui calculator i-ar trebui

1010 ani pentru a încerca toate cheile.

Un criptanalist care încearcă să spargă un cifru monoalfabetic va începe prin a număra

frecvenţele relative ale tuturor literelor din textul cifrat. După aceea el trebuie să încerce să

asocieze cea mai frecventă literă cu e, următoarea cu t. Apoi el va căuta trigramele, pentru a o

găsi pe cea mai frecventă cu forma tXe, care indică cu tărie că X este h. Similar, dacă apare

frecvent şablonul thYt, probabil că Y îl înlocuieşte pe a. Cu această informaţie, el poate căuta

apariţiile frecvente ale trigramelor de forma aZW, care sunt cel mai probabil, and. Prin astfel de

presupuneri făcute asupra celor mai comune litere, digrame, trigrame şi cu ceva cunoştinţe

despre şabloanele asemănătoare de vocale şi consoane, criptanalistul construieşte literă cu

literă o variantă de text clar.

2.3 Cifrurile cu transpoziţie

Cifrurile cu substituţie păstrează ordinea simbolurilor din textul clar, dar le deghizează. Spre

deosebire de acestea, cifrurile cu transpoziţie ( transposition ciphers) reordonează literele,

dar nu le deghizează. Figura 12-2 descrie un cifru cu transpoziţie simplu, transpoziţia pe

coloane.

Figura 12-2 – Un cifru cu transpoziţie


7

Cifrul are drept cheie un cuvânt sau o expresie ce nu conţine litere repetate. În acest exemplu

cheia este MEGABUCK. Scopul cheii este să numeroteze coloanele, coloana 1 fiind sub litera

din cheie cea mai apropiată de începutul alfabetului ş.a.m.d. Textul clar este scris orizontal, pe

rânduri. Textul cifrat este citit pe coloane, începând cu coloana al cărui număr de sub literă este

mai mic.

Pentru a sparge un cifru cu transpoziţie, criptanalistul trebuie mai întâi să fie sigur că are de-a

facecu un cifru cu transpoziţie. Analizând frecvenţa de apariţie pentru E, T, A, O, I, N etc., este

uşor de văzut dacă ele se încadrează în şablonul obişnuit pentru text clar. Dacă da, cifrul este

sigur un cifru cu transpoziţie, deoarece într-un astfel de cifru, fiecare literă este reprezentată de

ea însăşi, păstrând distribuţia frecvenţelor.

Următorul pas care trebuie făcut este să se emită o presupunere asupra numărului de coloane.

În multe cazuri un cuvânt sau o expresie probabilă poate fi ghicită din contextul mesajului. De

exemplu, se va presupune că un criptanalist bănuieşte că expresia în text clar milliondollars

apare pe undeva prin mesaj. Se observă că în urma împachetării acestei expresii, în textul cifrat

apar digramele MO, IL, LL, LA, IR şi OS. Litera O din textul cifrat urmează după litera M din

acelaşi text (adică sunt vertical adiacente în coloana 4) deoarece ele sunt separate în expresia

probabilă de o distanţă egală cu lungimea cheii. Dacă a fost folosită o cheie de lungime 7, în

locul acestora ar fi trebuit să apară digramele MD, IO, LL, LL, IA, OR şi NS. De fapt, pentru

fiecare lungime a cheii, în textul cifrat sunt produse seturi diferite de digrame. Prin urmărirea

diferitelor posibilităţi, criptanalistul poate determina cu uşurinţă lungimea cheii.

Pasul care mai rămâne este ordonarea coloanelor. Când numărul de coloane, k, este mic,

poate fi examinată fiecare dintre cele k(k-1) perechi de coloane pentru a vedea dacă diagrama

de frecvenţe se potriveşte diagramei pentru textul clar în engleză. Perechea cu cea mai bună

potrivire se presupune că este corect poziţionată. Acum fiecare coloană ce a rămas este

încercată a fi succesorul acestei perechi. Coloana pentru care frecvenţa digramelor şi

trigramelor se potriveşte cel mai bine se presupune a fi corectă. Coloana precedentă este

găsită în acelaşi mod. Se continuă întregul proces până când o ordine potenţială este

descoperită. Există şanse ca textul clar să devină recognoscibil din acest stadiu (de exemplu,

dacă apare milloin, este clar ce erori există în el).

Anumite cifruri cu transpoziţie acceptă un bloc de lungime fixă la intrare şi produc un bloc de

lungime fixă la ieşire. Aceste cifruri pot fi descrise complet dându-se doar o listă în care să se

precizeze ordinea în care caracterele vor fi trimise la ieşire. De exemplu, cifrul din Figura 12-2

poate fi văzut ca un cifru bloc pe 64 de caractere. Ieşirea sa este 4, 12, 20, 28, 36, 44, 52, 60,

5, 13, . . . , 62. Cu alte cuvinte, cel de-al patrulea caracter de la intrare, a, este primul ce va fi

trimis la ieşire, urmat de al doisprezecelea, f, ş.a.m.d.


8

2.4 Chei acoperitoare

Construirea unui cifru imposibil de spart este de fapt destul de simplă; tehnica este cunoscută

de decenii. În primul rând să se aleagă un şir aleatoriu de biţi pe post de cheie. Apoi să

seconvertească textul clar într-un şir de biţi, de exemplu folosind reprezentarea ASCII. În

final,să se calculeze XOR (SAU eXclusiv) între cele două şiruri, bit cu bit. Textul cifrat rezultat

nu poate fi spart, deoarece pentru un eşantion suficient de mare de text cifrat, fiecare literă va

apărea la fel de des, de asemenea şi orice digramă sau trigramă. Această metodă, cunoscută

sub numele de metoda cheilor acoperitoare (one-time pad) este imună la toate atacurile din

prezent şi din viitor, indiferent de puterea de calcul pe care o are la dispoziţie intrusul. Motivul

provine din teoria informaţiei: pur şi simplu nu există nici o informaţie în mesaj deoarece orice

text clar posibil cu o lungime dată este la fel de probabil.

Cheile acoperitoare sunt extraordinare în teorie, dar au numeroase dezavantaje în practică.

Unul dintre ele este faptul că nu poate fi memorată cheia, astfel încât atât transmiţătorul cât şi

receptorul trebuie să poarte cu ei o copie scrisă a acesteia. Dacă vreunul dintre ei este capturat,

evident că existenţa cheilor scrise nu este de dorit. În plus, cantitatea totală de date care poate

fi transmisă este limitată de dimensiunea cheii disponibile. Dacă spionul dă lovitura şi

descoperă o comoară de date, el nu va fi capabil să le transmită înapoi la cartierul general

deoarece cheia a fost epuizată. O altă problemă este sensibilitatea metodei la pierderea sau

inserarea de caractere. Dacă transmiţătorul şi receptorul pierd la un moment dat sincronizarea,

toate datele de aici încolo vor apărea ca fiind eronate.

Odată cu apariţia calculatoarelor, metoda cheilor acoperitoare poate deveni practică pentru

anumite aplicaţii. Sursa unei chei poate fi un DVD special care conţine câţiva gigabiţi de

informaţie şi care, transportat într-o cutie de DVD pentru filme, precedaţi de câteva minute de

imagini, nu ar fi nici măcar suspect. Desigur, la viteza reţelei de ordinul gigabiţilor, a trebui să

introduci un nou DVD la fiecare 5 secunde poate deveni obositor. Iar DVD-urile trebuie duse

personal de la transmiţător la receptor înainte de transmiterea oricărui mesaj, ceea ce reduce

mult valoarea lor practică.

Criptografia cuantică

Interesant este că ar putea exista o soluţie la problema transmiterii cheilor acoperitoare prin

reţea, şi ea provine dintr-o sursă neaşteptată: mecanica cuantică. Ideea este încă

experimentală, dar testele iniţiale sunt promiţătoare. Dacă poate fi perfecţionată şi eficientizată,

teoretic toată criptografia va fi făcută folosind chei acoperitoare dovedit fiind că acestea sunt

sigure

O utilizatoare, Alice, doreşte să stabilească o cheie acoperitoare cu un al doilea utilizator, Bob.

Alice şi Bob sunt denumiţi protagonişti, caracterele principale în povestea noastră. De exemplu,


9

Bob este un bancher cu care Alice ar dori să facă afaceri. Numele „Alice” şi „Bob” au fost

folosite pentru protagoniştii principali în aproape fiecare studiu şi lucrare despre criptografie în

ultima decadă.

Dacă Alice şi Bob ar putea stabili o cheie acoperitoare, ar putea să o folosească pentru a

comunica sigur. Întrebarea este: Cum pot ei să o stabilească fără să schimbe între ei DVD-uri?

Putem presupune că Alice şi Bob sunt la capetele opuse ale unei fibre optice prin care ei pot

trimite şi primi pulsuri de lumină. Cu toate acestea, o intrusă agitată, Trudy, poate tăia fibra

pentru a introduce un dispozitiv de ascultare activ. Trudy poate citi toţi biţii din ambele direcţii.

Ea poate de asemenea să trimită mesaje false în ambele direcţii. Situaţia ar părea fără

speranţă pentru Alice şi Bob, dar criptografia cuantică poate pune subiectul într-o nouă lumină.

Criptografia cuantică este bazată pe faptul că lumina circulă în mici pachete numite fotoni, care

au nişte proprietăţi specifice. În plus, lumina poate fi polarizată prin trecerea ei printr-un filtru

polarizator, un fapt bine cunoscut, atât de purtătorii de ochelari de soare cât şi de fotografi.

Dacă o rază de lumină (adică un flux de fotoni) trece printr-un filtru polarizator, toţi fotonii care

ies din el vor fi polarizaţi pe direcţia axului filtrului (adică pe verticală). Dacă raza va fi trecută

acum printr-un al doilea filtru polarizator, intensitatea luminii care iese din al doilea filtru va fi

proporţională cu rădăcina cosinusului unghiului dintre cele două axe. Dacă axele sunt

perpendiculare, nu va trece nici un foton. Nu contează orientarea absolută ale celor două filtre;

contează doar unghiul dintre axele lor.

Pentru a genera o cheie acoperitoare, Alice are nevoie de două seturi de filtre polarizatoare.

Primul set constă dintr-un filtru vertical şi un filtru orizontal. Această alegere se numeşte bază

rectiliniară. O bază este doar un sistem de coordonate. Al doilea set de filtre este similar, cu

excepţia faptului că sunt rotite cu 45 de grade, astfel că un filtru este de la stânga jos la dreapta

sus, iar celălalt filtru este de la stânga sus la dreapta jos. Această alegere se numeşte bază

diagonală. Deci Alice are două baze, pe care le poate introduce în raza de lumină oricând

doreşte. În realitate, Alice nu are patru filtre separate, ci un cristal a cărui polarizare poate fi

comutată electric cu o viteză foarte mare la oricare dintre cele patru direcţii permise. Bob are

acelaşi echipament ca şi Alice. Faptul că Alice şi Bob au fiecare câte două baze disponibile

este esenţial în criptografia cuantică.

Pentru fiecare bază, Alice desemnează o direcţie ca 0 şi cealaltă ca 1. În exemplul prezentat

mai jos, se va presupune că ea alege direcţia verticală ca 0 şi cea orizontală ca fiind 1.

Independent, ea alege de asemenea diagonala stânga-jos dreapta-sus ca 0 şi stânga-sus

dreapta-jos ca 1. Ea trimite aceste opţiuni lui Bob în text necriptat.

Acum Alice alege o cheie acoperitoare, bazată de exemplu pe un generator de numere

aleatoare (un subiect foarte complex în sine). Ea o transferă bit cu bit lui Bob, alegând aleator

una dintre cele două baze disponibile pentru fiecare bit. Pentru a trimite un bit, tunul de fotoni


10

emite un foton polarizat corespunzător pentru baza pe care o foloseşte pentru bitul respectiv.

De exemplu, ea ar putea să aleagă bazele diagonală, rectiliniară, rectiliniară, diagonală,

rectiliniară, etc. Pentru a trimite cheia sa acoperitoare 1001110010100110 cu aceste baze, ea

va trimite fotonii din Figura 12-3(a). Fiind date cheia acoperitoare şi secvenţa bazelor,

polarizarea folosită pentru fiecare bit este unic determinată. Biţii trimişi câte un foton la un

moment dat se numesc qubiţi.

Bob nu ştie ce baze să folosească, prin urmare pentru fiecare foton sosit, alege o bază

aleatoare şi o foloseşte, după cum se poate vedea în Figura 12-3(b). Dacă alege baza corectă,

el va obţine bitul corect. Dacă alege baza incorectă, el obţine un bit aleator deoarece dacă un

foton trece printr-un filtru polarizat la 45 de grade faţă de polarizarea proprie, sare aleator la

polarizarea filtrului sau sare cu o probabilitate egală, la o polarizare perpendiculară cu cea a

filtrului. Această proprietate a fotonilor este fundamentală pentru mecanica cuantică. Prin

urmare, câţiva dintre biţi vor fi corecţi iar câţiva vor fi aleatori, dar Bob nu ştie care sunt unii şi

care sunt ceilalţi. Rezultatele lui Bob sunt prezentate în Figura 12-3(c).

Figura 12-3 – Un exemplu de criptografie cuantică

Dar cum află Bob ce baze a ghicit corect şi pe care le-a greşit? Pur şi simplu, el îi va spune lui

Alice în text clar ce bază a folosit pentru fiecare bit, iar ea îi va spune care sunt corecte şi care


11

sunt greşite tot în clar, după cum este arătat în Figura 12-3(d). Din această informaţie, fiecare

dintre ei poate construi un şir de biţi din presupunerile corecte, după cum arată Figura 12-3(e).

În medie, acest şir va fi jumătate din lungimea şirului iniţial de biţi, dar deoarece ambele părţi îl

cunosc, îl pot folosi pe post de cheie acoperitoare. Alice trebuie să trimită un şir puţin mai mare

decât dublul lungimii dorite pentru ca ea şi Bob să obţină o cheie acoperitoare cu lungimea

dorită.

Se presupune că Trudy este curioasă să ştie ce are Alice de spus şi taie fibra, inserând propriul

ei detector şi transmiţător. Din nefericire pentru ea, nici ea nu ştie ce bază să folosească pentru

fiecare foton. Tot ce poate să facă este să aleagă aleatoriu o bază pentru fiecare foton, cum a

făcut şi Bob. Un exemplu cu alegerile ei este prezentat în Figura 12-3(f). Atunci când Bob

raportează mai târziu (în text clar) ce baze a folosit şi Alice îi spune (în text clar) care dintre ele

sunt corecte, Trudy va şti ce a înţeles bine şi ce nu a înţeles bine. În Figura 12-3 ea a nimerit

bine biţii 0, 1, 2, 3, 4, 6, 8, 12 şi 13. Dar ea ştie din replica lui Alice că doar biţii 1, 3, 7, 8, 10, 11,

12 şi 14 fac parte din cheia acoperitoare. Pentru patru dintre aceşti biţi (1, 3, 8, 12 ) ea a ghicit

corect şi a capturat bitul corect . Ea nu a ghicit ceilalţi patru (7, 10, 11 şi 14 ) biţi şi nu cunoaşte

bitul transmis. Prin urmare, Bob ştie că cheia acoperitoare începe cu 01011001, din Figura 12-

3(e) dar tot ce are Trudy este 01?1??0?, din fig.8-5(g).

Bineînţeles că Alice şi Bob sunt conştienţi că Trudy ar fi putut captura o parte din cheia lor

acoperitoare, astfel că ar dori să minimizeze informaţia deţinută de Trudy. Ei pot face acest

lucru prin efectuarea unei transformări asupra acestei chei. De exemplu, ei ar putea diviza cheia

acoperitoare în blocuri de câte 1024 biţi, ar putea ridica la pătrat fiecare bloc pentru a forma un

număr de 2048 de biţi şi ar putea folosi concatenarea acestor numere de 2048 de biţi ca cheie

acoperitoare. Având cunoştinţe parţiale despre şirul de biţi transmis, Trudy nu are nici un mod

de a genera pătratul lui şi deci nu dispune de nici o informaţie. Transformarea din cheia

acoperitoare originală într-una diferită care reduce cunoştinţele lui Trudy se numeşte

amplificarea confidenţialităţii. În practică, în locul ridicării la pătrat sunt folosite transformări

complexe în care fiecare bit de ieşire depinde de fiecare bit de intrare.

Trudy trebuie să redirecteze fiecare bit recepţionat de la Alice pentru Bob pentru a-l păcăli şi a-l

face să creadă că vorbeşte cu Alice. Problema este că tot ce poate ea să facă este să trimită

qubitul pe care l-a recepţionat, folosind polarizarea pe care a folosit-o pentru a-l recepţiona şi în

jumătate din cazuri ea va greşi, provocând multe erori în cheia acoperitoare a lui Bob.

Când în final Alice va începe să trimită datele, ea le va codifica folosind un puternic cod

preventiv corector de erori. Din punctul lui Bob de vedere, o eroare de 1 bit în cheia

acoperitoare este echivalentă cu o eroare de transmisie de 1 bit. În ambele cazuri, el va obţine

un bit eronat. Dacă există suficient cod preventiv corector de erori, el va putea recupera mesajul

original în pofida tuturor erorilor, dar va putea foarte uşor să numere câte erori au fost corectate.

Dacă acest număr este cu mult mai mare decât rata prevăzută de erori a echipamentului, el va


12

şti că Trudy a interceptat linia şi va putea să acţioneze în consecinţă (de ex., să-i spună lui Alice

să comute pe un canal radio, să cheme poliţia, etc.). Dacă Trudy ar dispune de o metodă de a

clona un foton pentru a avea un foton pe care să-l inspecteze şi un foton identic pe care să-l

trimită lui Bob, ea ar putea evita detecţia, dar în prezent nu este cunoscută nici o metodă de a

clona perfect un foton. Dar chiar dacă Trudy ar putea clona fotoni, asta nu ar reduce valoarea

criptografiei cuantice în stabilirea cheilor acoperitoare.

Deşi a fost demonstrat că criptografia cuantică poate opera pe distanţe de 60 km de fibră,

echipamentul este complex şi scump. Totuşi, ideea este promiţătoare.

2.5 Două principii criptografice fundamentale

Pentru sistemele criptografice există două principii de bază a căror înţelegere este importantă:

redundanța și prospețimea.

Redundanţa

Primul principiu este acela că toate mesajele criptate trebuie să conţină redundanţă, adică

informaţie ce nu este necesară pentru înţelegerea mesajului. Un exemplu poate clarifica de ce

este nevoie de aceasta. Se consideră o companie ce se ocupă cu comenzile prin poştă The

Couch Potato (TCP), cu 60000 de produse. Crezând că vor fi foarte eficienţi, programatorii de la

TCP au decis că mesajele de comandă trebuie să conţină un nume de client pe 16 octeţi, urmat

de un câmp de date pe 3 octeţi (1 octet pentru cantitate şi 2 octeţi pentru numărul produsului).

Ultimii 3 octeţi vor fi criptaţi folosind o cheie foarte lungă, cunoscută doar de client şi de TCP.

La prima vedere sistemul pare sigur şi, într-un anumit sens, chiar este, deoarece intruşii pasivi

nu pot decripta mesajele. Din nefericire, există o slăbiciune fatală a acestui sistem, care îl face

inutilizabil. Se presupune că o funcţionară recent concediată vrea să se răzbune pe TCP pentru

că a dat-o afară. Chiar înainte de a pleca, ea ia lista clienţilor cu ea. Ea lucrează în timpul nopţii

şi scrie un program care generează comenzi fictive folosind nume de clienţi reali. Deoarece nu

posedă lista cheilor, ea pune numere aleatorii în ultimii 3 octeţi şi trimite sute de comenzi la

TCP.

Când sosesc aceste mesaje, calculatorul TCP foloseşte numele clientului pentru a localiza

cheia şi a decripta mesajul. Din nefericire pentru TCP, aproape fiecare mesaj de 3 octeţi este

valid, iar calculatorul începe să tipărească instrucţiunile trimise. Deşi pare ciudat ca un client să

comande 837 de seturi de leagăne pentru copii sau 540 de cutii cu nisip, calculatorul poate

crede că acesta plănuieşte să deschidă o mulţime de locuri de joacă. În acest mod, un intrus

activ (ex-funcţionara) poate cauza probleme imense, chiar dacă ea nu poate înţelege mesajele

pe care le generează calculatorul ei.


13

Problema poate fi rezolvată prin adăugarea unor informaţii redundante tuturor mesajelor. De

exemplu, dacă mesajele de comandă sunt extinse la 12 octeţi, dintre care primii 9 trebuie să fie

zerouri, atunci acest atac nu ar mai fi funcţional, deoarece ex-funcţionara nu mai poate genera

un şir mare de mesaje valide.

Totuşi, adăugarea informaţiei redundante facilitează spargerea mesajelor de către criptanalişti.

Se presupune că afacerea de comenzi prin poştă este foarte competitivă şi competitorul

principal al companiei The Coach Potato, The Sofa Tuber, ar vrea tare mult să ştie câte cutii de

nisip vinde TCP. În consecinţă, ei ascultă linia telefonică a TCP. În schema originală, cu mesaje

de 3 octeţi, criptanaliza era aproape imposibilă, deoarece după ghicirea unei chei, criptanalistul

nu avea cum să-şi dea seama dacă a ghicit corect. În fond, aproape orice mesaj este tehnic

corect. Cu noua schemă de 12 octeţi, este uşor pentru criptanalist să distingă un mesaj valid de

unul invalid. Astfel :

Principiul criptografic 1: Mesajele trebuie să conţină redundanţă.

Cu alte cuvinte, după decriptarea unui mesaj, receptorul trebuie să poată distinge dacă este

valid printr-o simplă inspectarea a acestuia şi prin execuţia unui calcul simplu. Această

redundanţă este necesară pentru a împiedica intruşii activi să înşele receptorul trimiţându-i

un mesaj fals şi determinându-l să acţioneze în numele mesajului decriptat. Cu toate acestea,

aceeaşi redundanţă facilitează intruşilor pasivi spargerea sistemului, deci aici apar unele

probleme. Mai mult decât atât, redundanţa nu trebuie niciodată să fie folosită sub forma a n

zerouri la începutul sau sfârşitul unui mesaj, deoarece trecerea unor astfel de mesaje prin

anumiţi algoritmi criptografici dă rezultate predictibile, simplificând criptanaliza. Un cod CRC

polinomial ar fi o alegere mult mai bună decât un şir de 0 deoarece receptorul îl poate verifica

uşor, dar pentru criptanalist el reprezintă o muncă în plus. Şi mai bună ar fi folosirea unei

dispersii criptografice (cryptographic hash).

Privitor la criptografia cuantică, rolul redundanţei este următorul. Datorită interceptării fotonilor

de către Trudy, câţiva dintre biţii cheii acoperitoare a lui Bob vor fi eronaţi. Bob are nevoie de

redundanţă în mesajele primite pentru a determina faptul că există erori. O formă foarte

primitivă de redundanţă este transmiterea mesajului de două ori. Dacă cele două copii nu sunt

identice, Bob ştie că fie fibra optică are foarte multe zgomote, fie cineva interferează cu

transmisia. Bineînţeles că trimiterea de două ori a fiecărui lucru este extrem de ineficient: o

metodă mult mai eficientă de a detecta şi corecta erorile este folosirea unui cod Hamming sau

Reed-Solomon. Dar trebuie să fie clar că o anumită redundanţă este necesară pentru a putea

distinge între un mesaj valid şi unul invalid, mai ales în prezenţa unui intrus activ.

Prospeţimea

Cel de-al doilea principiu criptografic este acela că trebuie luate anumite măsuri pentru ne


14

asigura că fiecare mesaj primit poate fi verificat că este proaspăt, adică a fost trimis foarte

recent. Această măsură este necesară pentru a împiedica intruşii activi să retransmită mesaje

mai vechi. Dacă nu se iau nici un fel de astfel de măsuri, exfuncţionara noastră ar putea asculta

linia telefonică a TCP şi ar putea retransmite mesajele valide trimise anterior. Reformulând

această idee se obţine:

Principiul criptografic 2: Este necesară o metodă pentru a dejuca atacurile prin replicarea

mesajelor

O astfel de măsură este de a include în fiecare mesaj o amprentă de timp validă doar pentru, 10

secunde. Receptorul trebuie doar să păstreze mesajele primite în ultimele 10 secunde, pentru a

compara mesajele nou sosite cu anterioarele şi pentru a filtra duplicatele. Mesajele mai vechi

decât 10 secunde pot fi aruncate, deoarece orice replică a lor trimisă mai târziu de 10 secunde

va fi refuzată ca fiind prea veche. Alte măsuri în afara amprentelor de timp vor fi discutate mai

târziu.

3. Algoritmi cu cheie secretă

Criptografia modernă utilizează aceleaşi idei de bază ca şi criptografia tradiţională (transpoziţia

şi substituţia) dar accentul este diferit. Tradiţional, criptografii foloseau algoritmi simpli. În zilele

noastre este adevărat contrariul: obiectivul este de a face algoritmii de criptare atât de

complecşi şi ireversibili, încât, chiar dacă un criptanalist achiziţionează cantităţi imense de text

cifrat la alegerea sa, el nu poate face nimic cu el fără a avea cheia.

Prima clasă de algoritmi de criptare studiați se numesc algoritmi cu cheie secretă (symmetric-key algorithms) pentru că folosesc aceeaşi cheie pentru criptare şi decriptare. Figura 12-1

ilustrează folosirea unui algoritm cu cheie secretă. În particular, ne se va concentra asupra

cifrurilor bloc, care primesc la intrare un bloc de n biţi de text clar şi îl transformă folosind cheia

într-un bloc de text cifrat de n biţi.

Algoritmii criptografici pot fi implementaţi fie în hardware (pentru viteză) sau în software (pentru

flexibilitate). Deşi cea mai mare parte a acestei lucrări tratează algoritmii şi protocoalele, care

sunt independente de implementarea efectivă, ar putea fi interesante câteva cuvinte despre

construirea de hardware pentru criptare. Transpoziţiile şi substituţiile pot fi implementate cu

circuite simple. Figura 12-4(a) prezintă un dispozitiv, cunoscut sub numele de cutie P (P vine de

la permutare), folosit pentru a efectua o transpoziţie asupra unei intrări de 8 biţi. Dacă cei 8 biţi

sunt selectaţi să fie notaţi de sus în jos cu 01234567, ieşirea acestei cutii P particulare este

36071245. Printr-o cablare internă corespunzătoare, o cutie P poate fi construită să efectueze

orice transpoziţie şi să o facă practic cu viteza luminii.


15

Figura 12-4 –Elemente de bază ale cifrurilor produs. (a) Cutie P. (b) Cutie S. (c) Produs

Substituţiile sunt realizate de cutiile S, după cum este arătat în Figura 12-4(b). În acest exemplu

este introdus un text clar de 3 biţi, iar la ieşire este furnizat un text cifrat pe 3 biţi. Intrarea de 3

biţi selectează una dintre cele opt linii ce ies din primul nivel şi o poziţionează pe 1; toate

celelalte linii sunt 0. Cel de-al doilea nivel este o cutie P. Ce de-al treilea nivel codifică din nou

în binar linia selectată la intrare. Cu cablajul arătat, dacă opt numere scrise în octal 01234567

ar fi fost introduse unul după celălalt, secvenţa de ieşire ar fi 24506713. Cu alte cuvinte, 0 a fost

înlocuit cu 2, 1 a fost înlocuit cu 4 etc. Din nou, prin cablarea corespunzătoare a cutiei P în

interiorul cutiei S, poate fi realizată orice substituţie. De altfel, un astfel de dispozitiv poate fi

construit în hardware şi poate atinge viteze foarte mari deoarece codificatorul şi decodificatorul

au doar una sau două întârzieri de porţi logice (sub o nanosecundă) iar timpul de propagare

prin cutia P poate fi mult mai mic decât o picosecundă.

Puterea efectivă a acestor elemente de bază devine vizibilă doar atunci când se conectează în

cascadă o serie întreagă de cutii pentru a forma un cifru produs, după cum este arătat în Figura

12-4(c). În acest exemplu, 12 linii de intrare au fost transpuse (adică permutate) de primul nivel.

Teoretic, ar fi posibil să fie la doilea nivel o cutie S care să pună în corespondenţă un număr de

12 biţi cu alt număr de 12 biţi.Totuşi, un astfel de dispozitiv ar necesita 212=4096 cabluri

încrucişate la nivelul său din mijloc. În schimb, intrarea este împărţită în patru grupuri de 3 biţi,

fiecare fiind substituit independent de celelalte. Cu toate că această metodă este mai puţin

generală, ea este încă puternică. Prin includerea unui număr suficient de mare de niveluri în

cifrul produs, ieşirea poate deveni o funcţie extrem de complicată depinzând de intrare.

Cifrurile produs care operează asupra intrărilor de k biţi pentru a produce ieşiri de k biţi sunt

destul de obişnuite. O valoare tipică pentru k este de la 64 la 256. O implementare hardware

are de obicei cel puţin 18 niveluri fizice, nu doar şapte ca în Figura 12-4(c). O implementare

software este programată ca o buclă cu cel puţin 8 iteraţii, fiecare dintre ele executând

substituţii ca cele ale cutiilor S pe subblocuri din blocurile de date cu dimensiuni de la 64 la 256

de biţi, urmate o permutare care combină ieşirile cutiilor S. De obicei există o permutare iniţială


16

specială şi, de asemenea, una la început. În literatură, iteraţiile se numesc runde.

3.1 DES – Data Encryption Standard

În ianuarie 1977, guvernul SUA a adoptat ca standard oficial pentru informaţiile nesecrete un

cifru produs şi dezvoltat de IBM. Acest cifru, DES (Data Encryption Standard – Standard

pentru Criptarea Datelor), a fost adoptat extensiv în industrie pentru a fi utilizat în produsele de

securitate. El nu mai este de mult sigur în forma sa originală, dar într-o formă modificată el este

încă util.

O prezentare generală a DES este făcută în Figura 12-5(a). Textul clar este criptat în blocuri de

câte 64 de biţi, rezultând blocuri de 64 de biţi de text cifrat. Algoritmul, care este parametrizat

cu o cheie de 56 de biţi, are 19 runde distincte. Prima rundă este o transpoziţie independentă

de cheie, aplicată asupra textului clar de 64 de biţi. Ultima rundă este exact inversa acestei

transpoziţii. Penultima rundă schimbă cei mai din stânga 32 de biţi cu cei mai din dreapta 32 de

biţi. Cele 16 runde rămase sunt funcţional identice dar sunt parametrizate de funcţii de cheie

diferite. Algoritmul a fost proiectat pentru a permite ca decriptarea să se facă cu aceeaşi cheie

ca şi criptarea, o proprietate necesară în orice algoritm cu cheie secretă. Paşii sunt parcurşi în

ordine inversă.

Funcţionarea unuia dintre paşii intermediari este ilustrată în Figura 12-5(b). Fiecare rundă ia

două intrări de 32 de biţi şi produce două ieşiri de 32 de biţi. Ieşirea din stânga este o simplă

copie a intrării din dreapta. Ieşirea din dreapta rezultă în urma unui SAU exclusiv (XOR) bit cu

bit între intrarea din stânga şi o funcţie depinzând de intrarea din dreapta şi de o cheie pentru

această rundă, Ki. Toată complexitatea rezidă în această funcţie.

Funcţia constă din patru paşi, parcurşi în secvenţă. În primul rând, este construit un număr de

48 de biţi, E, prin expandarea celor 32 de biţi ai lui Ri-1 în concordanţă cu o regulă de

transpoziţie fixă şi de duplicare. În al doilea rând, E şi Ki sunt combinate prin XOR. Ieşirea este

apoi împărţită în opt grupuri de câte 6 biţi şi fiecare dintre acestea este introdus într-o cutie S

diferită. Fiecare dintre cele 64 de intrări posibile într-o cutie S este pusă în corespondenţă cu o

ieşire de 4 biţi. În final, aceşti 8 × 4 biţi sunt trecuţi printr-o cutie P.

În fiecare din cele 16 iteraţii este folosită o cheie diferită. Înainte de începerea algoritmului este

aplicată o transpoziţie de 56 de biţi asupra cheii. Chiar înainte de începerea fiecărei iteraţii,

cheia este partiţionată în două unităţi de câte 28 de biţi, fiecare dintre ele este rotită la stânga

cu un număr de biţi depinzând de numărul iteraţiei. Ki este derivat din această cheie rotită prin

aplicarea unei transpoziţii pe 56 de biţi asupra ei. La fiecare rundă este extrasă şi permutată o

altă submulţime de 48 de biţi din cei 56 de biţi.


17

Figura 12-5 – Cifrul DES. (a) Schemă generală. (b) Detalierea unei iteraţii. Semnul + înconjurat

de un cerc înseamnă SAU exclusiv

O tehnică folosită uneori pentru a face DES mai puternic se numeşte albire (whitening). Ea

consistă în efectuarea operaţiei SAU exclusiv între o cheie aleatoare de 64 de biţi cu fiecare

bloc de text clar înainte de a-l introduce în DES şi apoi efectuarea încă a unui SAU exclusiv cu

o a doua cheie de 64 de biţi a textului cifrat înainte de a-l transmite. Albirea poate fi eliminată

simplu prin efectuare operaţiilor inverse (dacă receptorul are cele 2 chei de albire). Din moment

ce această tehnică adaugă mai mulţi biţi la lungimea cheii, face căutarea exhaustivă a spaţiului

cheii mult mai mare consumatoare de timp. Se poate observa că aceeaşi cheie de albire este

folosită pentru fiecare bloc (adică există o singură cheie de albire).

Triplu DES

Încă din 1979, IBM a realizat că lungimea cheii DES era prea mică şi a conceput un mod de a o

creşte efectiv, folosind tripla criptare (Tuchman, 1979). Metoda aleasă, care de atunci a fost

încorporată în Standardul Internaţional 8732, este ilustrată în Figura 12-6..Aici sunt folosite

două chei şi trei runde. În prima rundă textul clar este în mod obişnuit criptat cu K1. În a doua

rundă, este rulat DES în mod de decriptare, folosind cheia K2. În final, este efectuată o altă


18

criptare cu K1.

Figura 12-6 – (a)Tripla criptare folosind DES. (b) Decriptarea.

Această proiectarea dă naştere imediat la două întrebări. Prima, de ce sunt folosite doar două

chei în loc de trei? A doua, de ce este folosită succesiunea de transformări EDE (Encrypt Decrypt Encrypt, Criptare Decriptare Criptare), în loc de EEE (Encrypt Encrypt Encrypt, Criptare Criptare Criptare)? Motivul pentru care sunt utilizate două chei este acela că chiar şi

cei mai paranoici criptografi admit că 112 biţi sunt suficienţi pentru aplicaţiile comerciale de

rutină, la momentul actual. A extinde la 168 de biţi înseamnă a adăuga o supraîncărcare inutilă

pentru gestiunea şi transportul unei alte chei cu un câştig real redus.

Motivul pentru criptare, decriptare şi apoi iar criptare este compatibilitatea cu produsele

existente ce folosesc sisteme DES cu o singură cheie. Atât funcţia de criptare cât şi cea de

decriptare sunt corespondenţe între mulţimi de numere pe 64 de biţi. Din punct de vedere

criptografic, cele două corespondenţe sunt la fel de puternice. Totuşi, folosind EDE în locul

EEE, un calculator ce utilizează tripla criptare poate comunica cu unul ce foloseşte criptarea

simplă, folosind K1=K2.

3.2 AES – Advanced Encryption Standard

Deoarece DES a început să se apropie de sfârşitul utilei sale vieţi , chiar şi cu DES triplu, NIST

(National Institute of Standards and Technology, Institutul Naţional de Standarde şi

Tehnologie), agenţia Departamentului de Comerţ al Statelor Unite însărcinată cu aprobarea

standardelor pentru Guvernul Federal al S.U.A., a decis că guvernul are nevoie de un nou

standard criptografic pentru folosinţă publică. NIST avea cunoştinţă de controversa din jurul

DES şi ştia bine că dacă ar fi anunţat un nou standard orice persoană care ştia câte ceva

despre criptografie ar fi presupus în mod automat că NSA a construit o uşă secretă prin care

NSA să poată citi orice criptat cu DES. În aceste condiţii, probabil nimeni n-ar fi folosit

standardul şi acesta ar fi murit probabil singur.

De aceea NIST a avut o abordare surprinzător de diferită pentru o birocraţie guvernamentală: a

sponsorizat un concurs de criptografie. În ianuarie 1997, cercetători din toată lumea au fost


19

invitaţi să depună propuneri pentru un nou standard, care urma să se numească AES

(Advanced Encryption Standard – Standard de Criptare Avansat). Regulile concursului erau:

1. Algoritmul trebuie să fie un cifru bloc simetric.

2. Tot proiectul trebuie sa fie public

3. Trebuie să fie suportate chei de 128, 192, şi de 256 biţi

4. Trebuie să fie posibile atât implementări hardware cât şi software

5. Algoritmul trebuie să fie public sau oferit cu licenţă nediscriminatorie.

Au fost făcute cincisprezece propuneri serioase şi au fost organizate conferinţe publice în care

propunerile au fost prezentate, iar publicul a fost încurajat să găsească punctele slabe în fiecare

dintre ele. În august 1998, NIST a selectat cinci finalişti, în principal pe criterii de securitate,

eficienţă, flexibilitate şi cerinţe de memorie (importante pentru sistemele integrate). Au avut loc

mai multe conferinţe şi s-au mai eliminat din variante. La ultima conferinţă s-a organizat un vot

liber. Finaliştii şi scorurile lor au fost următoarele:

1. Rijndael (din partea lui Joan Daemen şi Vincent Rijmen, 86 voturi)

2. Serpent (din partea lui Ross Anderson, Eli Biham şi Lars Knudsen, 59 voturi)

3. Twofish (din partea unei echipe condusă de Bruce Schneier, 31 voturi)

4. RC6 (din partea RSA Laboratories, 23 voturi)

5. MARS (din partea IBM, 13 voturi)

În octombrie 2000, NIST a anunţat că votează şi el pentru Rijndael, iar în noiembrie 2001

Rijndael a devenit standard guvernamental al S.U.A. publicat ca Standard Federal de

Procesare a Informaţiilor nr.197 (Federal Information Processing Standard FIPS 197).

Rijndael permite lungimi de chei şi mărimi de blocuri de la 128 de biţi la 256 de biţi în paşi de

câte 32 biţi. Lungimea cheii şi lungimea blocului pot fi alese în mod independent. Cu toate

acestea, AES specifică faptul că mărimea blocului trebuie să fie de 128 de biţi şi lungimea cheii

trebuie să fie de 128, 192, sau 256 de biţi. E îndoielnic că cineva va folosi vreodată cheile de

192 de biţi, astfel că de fapt, AES are două variante: bloc de 128 de biţi cu cheie de 128 de biţi

şi bloc de 128 de biţi cu cheie de 256 de biţi.

În prezentarea algoritmului, se va examina doar cazul 128/128. O cheie de 128 de biţi permite

un spaţiu al cheilor de 2128 ≈ 2 × 1038 chei. Chiar dacă NSA reuşeşte să construiască o

maşină cu un miliard de procesoare, fiecare fiind capabil să evalueze o cheie în fiecare

picosecundă, ar trebui pentru o astfel de maşină aproximativ 1010 ani pentru a căuta în spaţiul

de chei.


20

Rijndael

Dintr-o perspectivă matematică, Rijndael se bazează pe Teoria Câmpului Galois, care îi conferă

o serie de proprietăţi de securitate demonstrabile.

Ca şi DES, Rijndael foloseşte substituţie şi permutări, ca şi runde multiple. Numărul de runde

depinde de mărimea cheii şi de mărimea blocului, fiind 10 pentru o cheie de 128 de biţi cu

blocuri de 128 biţi şi mărindu-se până la 14 pentru cheia cu cea mai mare dimensiune şi blocul

cu cea mai mare dimensiune. Totuşi, spre deosebire de DES, toate operaţiile sunt la nivel de

octet, pentru a permite implementări eficiente hardware şi software. Codul este dat în Figura 12-

7.

#define LENGTH 16 /* # octeţi în blocul de date sau în cheie */

#define NROWS 4 /* număr de linii din stare */

#define NCOLS 4 /* număr de coloane din stare */

#define ROUNDS 10 /* număr de iteraţii */

typedef unsigned char byte; /* întreg fără semn pe 8 biţi */

rijndael(byte plaintext[LENGTH], byte ciphertext[LENGTH], byte key[LENGTH])

{ int r; /* index pentru iterare */

byte state[NROWS][NCOLS]; /* starea curentă */

struct {byte k[NROWS][NCOLS];} rk[ROUNDS + 1]; /* cheile pentru runde */

expand_key(key, rk); /* construieşte cheile pentru runde */

copy_plaintext_to_state(state, plaintext); /* iniţializează starea curentă */

xor_roundkey_into_state(state, rk[0]); /* face XOR între cheie şi stare */

for (r = 1; r <= ROUNDS; r++) {

substitute(stare); /* aplică substituţia fiecărui octet */

rotate_rows(state); /* roteşte rândul i cu i octeţi */

if (r < ROUNDS) mix_columns(state); /* funcţie de amestecare */

xor_roundkey_into_state(state, rk[r]); /* face XOR între cheie şi stare */

}

copy_state_to_ciphertext(ciphertext, state); /* întoarce rezultatul */

}

Figura 12-7 – Rijndael în linii generale


21

Funcţia rijndael are trei parametri. Aceştia sunt: plaintext, un vector de 16 octeţi conţinând

datele de intrare, ciphertext, un vector de 16 octeţi în care va fi introdus rezultatul cifrat, şi key,

cheia de 16 octeţi. Pe durata calculelor, starea curentă a datelor e păstrată într-un vector de

octeţi, state, a cărui mărime este NROWS × NCOLS. Pentru blocuri de 128 de octeţi, acest

vector este de 4 × 4 octeţi. Întregul bloc de date de 128 de biţi poate fi stocat în 16 octeţi.

Vectorul state este iniţializat cu textul clar şi este modificat la fiecare pas al calculului. În anumiţi

paşi, este realizată substituţia octet-cu-octet. În alţii, octeţii sunt permutaţi în interiorul vectorului.

Sunt folosite şi alte transformări. La sfârşit, conţinutul lui state reprezintă textul cifrat.

Codul începe prin expandarea cheii în 11 vectori de aceeaşi lungime cu starea. Aceştia sunt

memoraţi în rk, care este un vector de structuri, fiecare structură conţinând un vector stare.

Unul dintre aceştia va fi folosit la începutul calculului şi ceilalţi 10 vor fi folosiţi în timpul celor 10

runde, câte unul în fiecare rundă. Calculul cheilor de runde din cheia de criptare este prea

complicat pentru a fi prezentat aici. Este de ajuns că cheile de runde sunt produse prin rotiri

repetate şi aplicarea de operaţii XOR asupra unor grupuri de biţi din cheie.

Următorul pas este acela de a copia textul clar în vectorul state astfel încât să poată fi procesat

pe perioada rundelor. Acesta este copiat în ordinea coloanelor, cu primii patru octeţi în coloana

0, următorii patru octeţi în coloana 1 şi aşa mai departe. Atât coloanele cât şi liniile sunt

numerotate pornind de la 0, deşi rundele sunt numerotate pornind de la 1. Setarea iniţială a

celor 12 vectori de octeţi de dimensiuni 4 × 4 este ilustrată în Figura 12-8.

Mai este un pas înainte de a începe calculul principal: rk[0] este combinat prin XOR în state,

octet cu octet. Cu alte cuvinte fiecare octet din cei 16 aflaţi în state este înlocuit cu rezultatul

aplicării operaţiei XOR asupra sa şi asupra octetului corespunzător din rk[0].

Figura 12-8 – Crearea vectorilor state şi rk

Bucla execută 10 iteraţii, câte una pe rundă, transformând state la fiecare iteraţie. Fiecare rundă

constă în patru paşi. Pasul 1 realizează o substituţie octet-cu-octet asupra lui state. Pe rând,


22

fiecare octet este folosit ca index într-o cutie S pentru a-i înlocui valoarea prin conţinutul

corespunzător din acea cutie S. Acest pas este un cifru de substituţie monoalfabetică directă.

Spre deosebire de DES, care are mai multe cutii S, Rijndael are doar o cutie S.

Pasul 2 roteşte la stânga fiecare din cele 4 rânduri. Rândul 0 este rotit cu 0 octeţi (nu e

schimbat), rândul 1 este rotit cu 1 octet, rândul 2 este rotit cu 2 octeţi şi rândul 3 este rotit cu 3

octeţi. Acest pas difuzează conţinutul datelor curente în jurul blocului, analog cu permutările din

Figura 12-4.

Pasul 3 amestecă fiecare coloană independent de celelalte. Această amestecare este realizată

prin înmulţire de matrice, în care noua coloană este produsul dintre vechea coloană şi o matrice

constantă, multiplicarea fiind realizată folosind câmpul finit Galois, GF(28). Deşi acest lucru

poate părea complicat, există un algoritm care permite fiecărui element al noii coloane să fie

calculat folosind două căutări în tabele şi trei operaţii XOR (Daemen şi Rijmen, 2002, Anexa E).

În fine, pasul 4 aplică operaţia XOR pentru cheia din runda curentă şi vectorul stare.

Deoarece fiecare pas e reversibil, decriptarea poate fi realizată prin rularea algoritmului de la

coadă la cap. Oricum, este posibilă şi o schemă prin care decriptarea poate fi realizată prin

rularea algoritmului de criptare nemodificat, dar folosind tabele diferite.

Algoritmul a fost proiectat nu doar pentru o securitate foarte solidă, dar şi pentru o viteză foarte

mare. O bună implementare software pe o maşină la 2 GHz ar trebui să atingă o rată de

criptare de 700 Mbps, ceea ce este suficient de rapid pentru a criptarea peste 100 de fişiere

video MPEG-2 în timp real. Implementările hardware sunt chiar mai rapide.

4. Algoritmi cu cheie publică

Istoric, distribuţia cheilor a fost întotdeauna punctul slab al multor criptosisteme. Indiferent de

cât de puternic era un criptosistem, dacă un intrus putea fura cheia, sistemul îşi pierdea

valoarea. Criptologii au considerat întotdeauna ca de la sine înţeles faptul că atât pentru

criptare cât şi pentru decriptare se foloseşte aceeaşi cheie (sau una uşor derivabilă din

cealaltă). Dar cheia trebuia distribuită tuturor utilizatorilor sistemului. Astfel, părea a exista

întotdeauna următoarea problemă inerentă: cheile trebuia protejate contra furtului dar, în

acelaşi timp, ele trebuiau distribuite, astfel încât ele nu puteau fi sechestrate într-un seif de

bancă.În 1976, doi cercetători de la Universitatea Stanford, Diffie şi Hellman (1976), au propus

un tip radical nou de criptosistem în care cheile de criptare şi decriptare sunt diferite, iar cheia

de decriptare nu poate fi dedusă din cheia de criptare. În propunerea lor, algoritmul (cheia) de

criptare, E, şi algoritmul (cheia) de decriptare, D, trebuiau să satisfacă trei cerinţe. Aceste

cerinţe pot fi exprimate simplificat după cum urmează:


23

1. D(E(P))=P

2. Este mai mult decât dificil să se deducă D din E.

3. E nu poate fi spart printr-un atac cu text clar ales.

Prima cerinţă spune că, dacă se aplică D unui mesaj criptat, E(P), se obţine textul clar original,

P. Fără această proprietate, receptorul legitim nu ar putea decripta textul cifrat. Cea de-a treia

cerinţă este necesară deoarece, intruşii pot experimenta şi testa algoritmul după pofta inimii. În

aceste condiţii, nu există nici un motiv pentru ca E, cheia de criptare, să nu poată fi făcută

publică.

Metoda lucrează astfel: o persoană, Alice, dorind să primească mesaje secrete, concepe mai

întâi doi algoritmi ce satisfac cerinţele de mai sus. Algoritmul de criptare şi cheia lui Alice sunt

făcuţi apoi publici, de unde şi numele de criptografie cu cheie publică. Alice poate de exemplu

să îşi pună cheia publică pe pagina ei personală de pe Web. Se va folosi notaţia EA pentru

algoritmul de criptare parametrizat de cheia publică a lui Alice. În mod similar, algoritmul

(secret) de decriptare parametrizat de cheia privată a lui Alice este DA. Bob face acelaşi lucru,

publicând EB, dar ţinând DB secret.

Să se rezolve acum problema stabilirii unui canal sigur între Alice şi Bob, care nu au mai avut

niciodată vreun contact anterior. Atât cheia de criptare a Alicei, EA, cât şi cea a lui Bob, EB,

sunt presupuse a se găsi într-un fişier ce poate fi citit de oricine. Acum Alice ia primul ei mesaj,

P, calculează EB(P) şi îl trimite lui Bob. Bob îl decriptează aplicându-i cheia sa secretă DB

[adică, el calculează DB(EB (P))=P]. Nimeni altcineva nu poate citi mesajul criptat, EB(P),

deoarece sistemul de criptare este presupus puternic şi deoarece este prea greu să se deducă

DB(P) din EB(P) public cunoscut. Pentru a trimite un răspuns R, Bob transmite EA(R). Alice şi

Bob pot comunica acum într-o manieră sigură.

4.1 RSA

Singura problemă este aceea că este nevoie de algoritmi care să satisfacă complet toate cele

trei cerinţe. Datorită posibilelor avantaje ale criptografiei cu chei publice, mulţi cercetători au

lucrat din greu la acest subiect şi au fost deja publicaţi câţiva algoritmi. O metodă bună a fost

descoperită de un grup de la MIT (Rivest, 1978). Ea este cunoscută prin iniţialele numelor celor

trei descoperitori (Rivest, Shamir, Adelman): RSA. Metoda a supravieţuit tuturor încercărilor de

a o sparge timp de mai mult de un sfert de secol şi este considerată foarte puternică. Multe

aplicaţii de securitate se bazează pe ea. Dezavantajul major al acesteia este că necesită chei

de cel puţin 1024 de biţi pentru o securitate bună (spre deosebire de 128 biţi pentru algoritmii cu

cheie simetrică), ceea ce o face destul de lentă. Metoda RSA este bazată pe câteva principii din

teoria numerelor.


24

1. Se aleg două numere prime, p şi q, (de obicei de 1024 biţi).

2. Se calculează n = p × q şi z = (p 1)×(q-1).

3. Se alege un număr relativ prim cu z şi este notat cu d.

4. Se găseşte e astfel încât e × d = 1 mod z.

Cu aceşti parametri calculaţi în avans, se poate începe criptarea. Împărţim textul clar (privit ca

şir de biţi) în blocuri, astfel încât fiecare mesaj de text clar, P, să intre în intervalul 0 ≤ P < n.

Aceasta poate fi făcută grupând textul clar în blocuri de câte k biţi, unde k este cel mai mare

număr întreg pentru care inegalitatea 2k < n este adevărată.

Pentru a cripta mesajul P, se calculează C = Pe (mod n). Pentru a decripta C, se calculează P =

Cd (mod n). Se poate demonstra că pentru toţi P din intervalul specificat, criptarea şi

decriptarea sunt funcţii inverse una alteia. Pentru a realiza criptarea este nevoie de e şi n.

Pentru a realiza decriptarea este nevoie de d şi n. De aceea, cheia publică constă din perechea

(e, n) iar cheia privată din perechea (d, n).

Securitatea metodei este bazată pe dificultatea factorizării numerelor mari. Dacă un criptanalist

ar putea factoriza numărul n (public cunoscut), el ar putea găsi p şi q, iar din acestea pe z. Cu z

şi e cunoscuţi, criptanalistul îl poate calcula pe d folosind algoritmul lui Euclid. Din fericire,

matematicienii au încercat să factorizeze numere mari de cel puţin 300 de ani şi experienţa

acumulată sugerează că aceasta este o problemă mai mult decât dificilă.

După Rivest şi colegii săi, factorizarea unui număr de 500 de cifre necesită un timp de calcul de

1025 ani folosind forţa brută. În ambele cazuri ei presupun că se foloseşte cel mai bun algoritm

de factorizare şi un calculator cu timp de execuţie a unei instrucţiuni de 1 µsec. Chiar dacă

viteza calculatoarelor va continua să sporească cu un ordin de mărime pe deceniu, vor mai

trece secole până când factorizarea unui număr de 500 de cifre va deveni realizabilă, moment

în care descendenţii noştri vor alege pur şi simplu p şi q mai mari.

Un exemplu didactic banal pentru algoritmul RSA este dat în Figura 12-9. Pentru acest exemplu

s-a ales p = 3 şi q = 11, rezultând n = 33 şi z = 20. O valoare potrivită pentru d este d = 7,

deoarece 7 şi 20 nu au factori comuni. Cu aceste alegeri, e poate fi găsit prin rezolvarea

ecuaţiei 7e = 1 (mod 20), care dă e = 3. Textul cifrat, C, pentru textul clar al mesajului, P, este

dat de C = P3 (mod 33). Textul cifrat este decriptat de către receptor după regula P = C7 (mod

33). Fig. prezintă ca exemplu criptarea şi decriptarea textului clar „SUZANNE”.

Deoarece numerele prime alese pentru acest exemplu sunt prea mici, P trebuie să fie mai mic

decât 33, deci fiecare bloc de text clar poate conţine doar un singur caracter. Rezultatul este un

cifru cu substituţie monoalfabetică, nu foarte impresionant. Dacă în locul acestora am fi ales p şi

q = 2512, am fi avut n = 21024, astfel încât fiecare bloc poate fi de până la 1024 de biţi sau 128


25

de caractere de 8 biţi, faţă de 8 caractere pentru DES şi 16 caractere pentru AES.

Figura 12-9 – Un exemplu de algoritm RSA.

Trebuie subliniat că folosirea RSA în modul descris este similară folosirii unui algoritm simetric

în modul ECB blocuri de intrare identice conduc la blocuri de ieşire identice. De aceea este

necesară o anumită formă de înlănţuire pentru criptarea datelor. Totuşi, în practică, cele mai

multe sisteme bazate pe RSA folosesc criptografia cu cheie publică în principal pentru

distribuirea cheilor de sesiune de unică folosinţă utilizate pentru un algoritm simetric ca AES

sau triplu DES. RSA este prea lent pentru a cripta eficient volume mari de date, dar este folosit

mult la distribuţia de chei.

5. Semnături digitale

Autenticitatea multor documente legale, financiare şi de alt gen este determinată de prezenţa

sau absenţa unor semnături autorizate scrise de mână. Iar fotocopiile nu sunt valabile. Pentru

ca sistemele de mesaje computerizate să înlocuiască transportul fizic al documentelor scrise cu

cerneală pe hârtie trebuie găsită o metodă ca documentele să fie semnate într-un mod

nefalsificabil. Problema de a concepe un înlocuitor pentru semnăturile scrise de mână este

destul de dificilă. De fapt, este necesar un sistem prin care una din părţi poate trimite mesaje

„semnate” celeilalte părţi astfel încât:

1. Receptorul poate verifica identitatea pe care pretinde a o avea transmiţătorul;

2. Transmiţătorul nu poate să nege mai târziu că e autorul mesajului;

3. Receptorul nu poate să fi pregătit el însuşi mesajul.

Prima cerinţă este necesară, de exemplu, în sistemele financiare. Atunci când calculatorul unui

client ordonă calculatorului unei bănci să cumpere o tonă de aur, calculatorul băncii trebuie să

poată să se asigure că acel calculator care dă ordinul aparţine într-adevăr companiei al cărei


26

cont va fi debitat. Cu alte cuvinte, banca trebuie să autentifice clientul (şi clientul trebuie să

autentifice banca).

A doua cerinţă este necesară pentru a proteja banca împotriva fraudei. Se presupune că banca

cumpără o tonă de aur şi imediat după aceea preţul aurului scade brusc. Un client necinstit

poate să acuze banca, pretinzând că el nu a emis niciodată vreun ordin de cumpărare de aur.

Când banca prezintă mesajul în faţa curţii, clientul neagă faptul că l-ar fi trimis. Proprietatea că

nici o parte a unui contract nu poate nega mai târziu faptul că l-a semnat se numeşte

nerepudiere (nonrepudiation). Schemele cu semnătură digitală oferă această proprietate.

Cea de-a treia cerinţă este necesară pentru a proteja clientul în eventualitatea că preţul aurului

explodează şi banca încearcă să construiască un mesaj în care clientul cere cumpărarea unui

lingou de aur în locul unei tone.

5.1 Semnături cu cheie simetrică

Un mod de abordare pentru semnăturile digitale este acela de a avea o autoritate centrală care

ştie totul şi în care oricine are încredere, numind Big Brother (BB, fratele cel mare). Fiecare

utilizator alege o cheie secretă şi o duce personal la biroul BB. Astfel, doar Alice şi BB vor

cunoaşte cheia secretă a lui Alice, KA, ş.a.m.d.

Atunci când Alice doreşte să trimită un mesaj în clar semnat, P, bancherului său, Bob, ea

generează KA(B, RA, t, P), unde B este identitatea lui Bob, RA este un număr aleator ales de

Alice, t este o amprentă de timp pentru a asigura prospeţimea şi KA(B, RA, t, P) este mesajul

criptat cu cheia ei KA. Apoi îl trimite, după cum este se arată şi în Figura 12-10. BB vede că

mesajul este de la Alice, îl decriptează şi îi trimite lui Bob mesajul ca în figură. Mesajul trimis

spre Bob conţine textul clar din mesajul lui Alice şi, de asemenea, mesajul semnat KBB(A, t, P),

unde t este amprenta de timp. Acum Bob rezolvă cererea lui Alice.

Figura 12-10 – Semnături digitale cu Big Brother.

Ce se întâmplă dacă Alice neagă mai târziu trimiterea mesajului? Primul pas este că toată

lumea dă în judecată pe toată lumea. În final, când cazul ajunge în faţa curţii şi Alice neagă cu


27

înverşunare că a trimis lui Bob mesajul în dispută, judecătorul îl va întreba pe Bob cum poate fi

sigur că mesajul disputat vine de la Alice şi nu de la Trudy. Bob va arăta mai întâi că BB nu

acceptă un mesaj de la Alice decât dacă este criptat cu KA, aşa că nu există nici o posibilitate

ca Trudy să-i trimită lui BB un mesaj fals ca provenind de la Alice fără ca BB să îl detecteze

imediat.

Apoi Bob va aduce în mod incontestabila Probă A, KBB(A, t, P). Bob spune că acesta este un

mesaj semnat de BB care demonstrează că Alice i-a trimis P lui Bob. Judecătorul îi va cere apoi

lui BB (în care toată lumea are încredere) să decripteze Proba A. Când BB va depune mărturie

că Bob spune adevărul, judecătorul va de verdictul în favoarea lui Bob. Cazul va fi închis.

O problemă posibilă cu protocolul de semnare din Figura 12-10 apare atunci când Trudy replică

oricare din mesaje. Pentru a minimiza această problemă, sunt folosite peste tot amprente de

timp. Mai mult, Bob poate verifica toate mesajele recente să vadă dacă RA a fost folosit în

vreunul dintre ele. Dacă da, mesajul respectiv este ignorat deoarece este o replică. De remarcat

că Bob va refuza toate mesajele foarte vechi din punct de vedere al amprentei de timp. Pentru a

se păzi împotriva atacurilor cu replică instantanee, Bob verifică doar RA al oricărui mesaj venit,

ca să vadă dacă s-a mai primit în ultima oră un astfel de mesaj de la Alice. Dacă nu, Bob poate

presupune fără nici un risc că mesajul reprezintă o nouă cerere.

5.2 Semnături cu cheie publică

Se presupune că algoritmii de criptare şi decriptare cu cheie publică au proprietatea că

E(D(P))=P în plus faţă de proprietatea uzuală D(E(P))=P (RSA are această proprietate, deci

presupunerea nu este nerezonabilă). Presupunând acest lucru, Alice poate trimite un text clar

semnat, P, lui Bob transmiţând EB(DA(P)). O observaţie importantă aici este aceea că Alice

cunoaşte atât propria sa cheie secretă, DA, cât şi cheia publică a lui Bob, EB, astfel încât

construcţia acestui mesaj este pentru Alice un lucru realizabil.

Figura 12-11 – Semnături digitale folosind criptografia cu cheie publică


28

Când Bob primeşte mesajul, el îl transformă, folosindu-şi cheia privată, ca de obicei, rezultând

DA(P), după cum este arătat şi în Figura 12-11. El memorează acest text într-un loc sigur şi

apoi aplică EA pentru a obţine textul clar original.

Pentru a vedea cum lucrează proprietatea de semnătură, se presupune că Alice neagă ulterior

trimiterea mesajului P lui Bob. Atunci când cazul ajunge în faţa curţii, Bob poate aduce ca probe

atât P cât şi DA(P). Judecătorul poate verifica uşor că Bob are un mesaj valid criptat cu DA,

doar aplicând EA asupra lui. Deoarece Bob nu ştie care este cheia privată a lui Alice, singurul

mod prin care Bob poate să fi primit mesajul criptat cu această cheie privată este ca Alice în

persoană să-l fi trimis.

Cu toate că folosirea criptografiei cu cheie publică pentru semnături digitale este o schemă

elegantă, există probleme legate mai degrabă de mediul în care acestea operează decât de

algoritmul de la bază. De exemplu, Bob poate dovedi că mesajul a fost trimis de către Alice

doar atâta vreme cât DA rămâne secret. Dacă Alice dezvăluie cheia sa secretă acest argument

nu va mai fi valabil, deoarece oricine poate să fi trimis mesajul, chiar şi Bob.

Problema poate apărea, de exemplu, dacă Bob este agentul de vânzări al lui Alice. Alice îi

spune lui Bob să cumpere nişte acţiuni. Imediat după aceea, preţul scade vertiginos. Pentru a

repudia mesajul său către Bob, Alice face o plângere la poliţie, pretinzând că i-a fost spartă

casa şi furată cheia secretă. În funcţie de legislaţia din ţara sau ţinutul său, ea poate fi sau nu

răspunzătoare legal, în special dacă pretinde că a descoperit spargerea când s-a întors acasă

de la muncă, la câteva ore mai târziu.

O altă problemă cu schema de semnătură este ce se întâmplă dacă Alice decide să-şi schimbe

cheia. A face acest lucru este evident legal şi este probabil o idee bună să o facă periodic. Dacă

în justiţie apare mai târziu un caz, aşa cum s-a povestit mai sus, judecătorul va aplica actualul

EA la DA(P) şi va descoperi că nu se obţine P. Bob va fi atunci într-o situaţie delicată.

În principiu, orice algoritm cu cheie publică poate fi folosit pentru semnături digitale. Standardul

de facto în industrie este algoritmul RSA. Multe produse pentru securitate îl folosesc. Totuşi, în

1991, NIST (National Institute of Standards and Technology) a propus o variantă a

algoritmului cu cheie publică El Gamal pentru noul lor standard DSS (Digital Signature Standard – Standard pentru Semnătură Digitală). El Gamal îşi bazează securitatea pe

dificultatea calculului logaritmilor discreţi şi nu pe dificultatea factorizării numerelor mari.

Ca de obicei, când guvernul încearcă să impună standarde criptografice, s-a iscat o reacţie

antagonistă de masă. DSS a fost criticat pentru a fi:

1. Prea secret (NSA a proiectat protocolul pentru folosirea El Gamal).

2. Prea lent (de 10 până la 40 de ori mai lent decât RSA în verificarea semnăturilor).

3. Prea nou (El Gamal nu a fost încă suficient analizat).


29

4. Prea nesigur (chei fixe de 512 biţi).

După o revizuire ulterioară, cel de-al patrulea motiv a fost eliminat fiindcă s-au permis chei de

până la 1024 biţi. Cu toate acestea, primele două puncte rămân valide.

5.3 Rezumate de mesaje

O critică adusă schemelor de semnătură este aceea că adeseori cuplează două funcţii distincte:

autentificare şi confidenţialitate. Adesea, autentificarea este necesară, dar confidenţialitatea nu.

În continuare se descrie o schemă de autentificare care nu necesită criptarea întregului mesaj.

Schema este bazată pe ideea unei funcţii de dispersie neinversabile care preia o bucată de text

clar de lungime arbitrară din care calculează un şir de biţi de lungime fixă. Funcţia de dispersie,

MD (Message Digest), adeseori numită rezumat (digest) al mesajului, are patru proprietăţi

importante:

1. Dat fiind P, este uşor de calculat MD(P).

2. Dat fiind MD(P), este efectiv imposibil de calculat P.

3. Dat fiind P nimeni nu poate găsi P’ astfel încât MD(P’)=MD(P).

4. O schimbare la intrare chiar şi de 1 bit produce o ieşire foarte diferită.

Pentru a satisface criteriul 3, dispersia trebuie să aibă cel puţin 128 de biţi lungime, de preferat

chiar mai mult. Pentru a satisface criteriul 4, dispersia trebuie să amestece biţii foarte bine.

Calculul rezumatului unui mesaj dintr-o bucată de text clar este mult mai rapidă decât criptarea

acelui text clar cu un algoritm cu cheie publică, deci rezumatele de mesaje pot fi folosite pentru

a oferi viteză algoritmilor cu semnătură digitală. Pentru a vedea cum lucrează, se ia din nou

protocolul de semnătură din Figura 12-10. În loc de a semna P cu KBB(A, t, P), BB calculează

acum rezumatul mesajului aplicând MD lui P, rezultând MD(P). BB include apoi KBB(A, t,

MD(P)) ca al cincilea element în lista criptată cu KB care este trimisă lui Bob, în loc de KBB(A, t,

P).

Figura 12-12 - Semnături digitale folosind rezumatul mesajului


30

Calculul rezumatelor mesajelor funcţionează şi în criptosistemele cu chei publice, după cum

este arătat şi în Figura 12-12. Aici, Alice calculează mai întâi rezumatul de mesaj pentru textul

său clar. Apoi ea semnează rezumatul şi trimite atât rezumatul semnat cât şi textul clar lui Bob.

Dacă Trudy îl înlocuieşte pe P în timpul transferului, Bob va vedea aceasta atunci când va

calcula el însuşi MD(P).

Au fost propuse diverse de funcţii pentru calculul rezumatului mesajelor. Cele mai folosite sunt

MD5 (Rivest, 1992) şi SHA-1 (NIST, 1993). MD5 este a cincea dintr-o serie de funcţii de

dispersie proiectate de Ronald Rivest. Operează prin amestecarea biţilor într-un mod suficient

de complicat, astfel încât fiecare bit de ieşire să fie afectat de fiecare bit de intrare. Foarte pe

scurt, algoritmul începe prin a umple mesajul până la o lungime de 448 de biţi (modulo 512).

Apoi lungimea originală a mesajului este adăugată ca un întreg pe 64 de biţi, dând o intrare

totală a cărei lungime este un multiplu de 512 de biţi. Ultimul pas dinaintea începerii calculului

este iniţializarea unui tampon de 128 de biţi la o valoare fixă.

Apoi începe calculul. Fiecare rundă ia un bloc de intrare de 512 de biţi şi îl amestecă complet cu

tamponul de 128 de biţi. Ca o măsură suplimentară, este folosită şi o tabelă construită folosind

funcţia sinus. Utilizarea unei funcţii cunoscute cum este sinus nu se datorează faptului că este

mai aleatoare decât un generator de numere aleatoare, ci pentru a evita orice suspiciune că

proiectantul a inclus o trapă inteligent ascunsă prin care doar el poate intra. Refuzul IBM-ului de

a dezvălui principiile aflate la baza proiectării cutiilor S din DES a dus la destul de multe

speculaţii privind existenţa trapelor ascunse. Rivest a vrut să evite această suspiciune. Pentru

fiecare bloc de intrare sunt efectuate patru runde. Acest proces continuă până când sunt

consumate toate blocurile de intrare. Conţinutul tamponului de 128 de biţi formează rezumatul

mesajului.

MD5 este activ deja de peste o decadă şi a fost atacat de mulţi. S-au găsit câteva vulnerabilităţi,

dar anumiţi paşi interni previn spargerea lui. Totuşi, dacă barierele care rămân în MD5 cad,

poate că într-un final va cădea şi el. Cu toate acestea, la momentul scrierii acestei cărţi el stătea

încă în picioare.

SHA-1

Altă funcţie majoră pentru calculul rezumatului este SHA (Secure Hash Algorithm – Algoritm

de Dispersie Sigur), dezvoltată de NSA şi acceptată de către NIST ca FIPS 180-1. Ca şi MD5,

SHA-1 prelucrează datele de intrare în blocuri de câte 512 de biţi, dar, spre deosebire de MD5,

generează un rezumat de mesaj de 160 de biţi. Un mod tipic pentru Alice de a trimite un mesaj

nesecret dar semnat lui Bob este ilustrat în Figura 12-13. Aici mesajul ei de text clar este

introdus în algoritmul SHA-1 pentru a obţine o dispersie SHA-1 de 160 biţi. Apoi Alice


31

semnează dispersia cu cheia sa privată RSA şi trimite atât mesajul în text clar cât şi dispersia

semnată lui Bob.

Figura 12-13 – Folosirea lui SHA-1 şi RSA pentru a semna mesaje nesecrete

După ce primeşte mesajul, Bob calculează el însuşi dispersia SHA-1 şi aplică de asemenea

cheia publică a lui Alice asupra dispersiei semnate pentru a obţine dispersia originală H. Dacă

cele două se potrivesc, mesajul este considerat valid. Deoarece nu există nici o cale pentru

Trudy de a modifica mesajul (în text clar) în timp ce se trimite şi de a produce unul nou care dă

ca dispersie H, Bob poate să detecteze uşor orice modificări pe care le-a adus Trudy mesajului.

Pentru mesajele a căror integritate este importantă dar al căror conţinut nu este secret, se

foloseşte pe larg schema din Figura 12-13. În schimbul unui cost de calcul relativ mic, ea

garantează că orice modificări făcute asupra mesajului în text clar în tranzit pot fi detectate cu o

probabilitate foarte mare.

SHA-1 începe prin a completa mesajul, adăugând la sfârşit un bit 1, urmat de atâţi biţi 0 câţi

sunt necesari pentru a obţine o lungime multiplu de 512 de biţi. Apoi se introduce prin OR în cei

64 de biţi mai puţin semnificativi un număr de 64 biţi conţinând lungimea mesajului înaintea

completării. În Figura 12-14, este arătat mesajul cu completare la dreapta deoarece textul şi

cifrele englezeşti merg de la stânga la dreapta (adică dreapta jos este perceput în general ca

sfârşit de cifră). La calculatoare, această orientare corespunde la maşini de tip big-endian ca

SPARC, dar SHA-1 completează întotdeauna sfârşitul mesajului, indiferent de ce tip de endian

este maşina.

În timpul calculului, SHA-1 păstrează cinci variabile de 32 de biţi, H0 până la H4, în care se

acumulează dispersia. Acestea sunt arătate în Figura 12-14(b). Ele sunt iniţializate la constante

specificate în standard.

Fiecare din blocurile M0 până la Mn-1 este prelucrat pe rând. Pentru blocul curent, primele 16

cuvinte sunt copiate mai întâi la începutul unui vector auxiliar de 80 de cuvinte, W, ca în Figura

12-14(c). Apoi celelalte 64 de cuvinte din W sunt umplute folosind formula:

Wi=Si(Wi-3 XOR Wi-8 XOR Wi-14 XOR Wi-16) (16≤ i ≤ 79)


32

unde Sb(W) reprezintă rotaţia circulară la stânga, cu b biţi a cuvântului de 32 de biţi W. Cinci

variabile auxiliare, de la A până la E, sunt apoi iniţializate din H0 – H4 respectiv.

Figura 12-14 – (a) Un mesaj completat până la un multiplu de 512 biţi. (b) Variabilele de ieşire.

(c) Vectorul de cuvinte

6. Gestionarea cheilor publice

Criptografia cu chei publice face posibilă comunicaţia sigură între persoane care nu împart o

cheie comună. De asemenea face posibilă semnarea mesajelor fără prezenţa unei a treia părţi

de încredere. În fine, rezumatul mesajului semnat face posibilă verificarea uşoară a integrităţii

mesajelor primite. Există totuși o problemă: dacă Alice şi Bob nu se cunosc unul pe altul, cum

îşi pot afla cheile publice pentru a porni procesul de comunicaţie? Soluţia evidentă – să fie pusă

cheia publică pe web – nu merge datorită următorului motiv. Se presupune că Alice vrea să

caute cheia publică a lui Bob pe site-ul lui de web. Cum face ea acest lucru? Începe prin a tasta

adresa de web a lui Bob. Browserul ei va căuta adresa DNS a paginii principale a lui Bob şi va

trimite o cerere de tip GET, aşa cum se indică în Figura 12-15.

Figura 12-15 – O modalitate prin care Trudy sparge infrastructura cu chei publice

Din păcate, Trudy interceptează cererea şi răspunde cu o falsă pagină principală, probabil o


33

copie a paginii principale a lui Bob în care s-a înlocuit cheia publică a lui Bob cu cheia publică a

lui Trudy. Când Alice va cripta primul ei mesaj cu ET, Trudy îl va decripta, îl va citi, îl va recripta

cu cheia publică a lui Bob şi îl va trimite apoi lui Bob, care nu este capabil să-şi dea seama că

Trudy i-a citit mesajele primite. Şi mai grav, Trudy poate modifica mesajele înainte de a le

recripta pentru Bob. În mod evident, este nevoie de un mecanism care să asigure un schimb

sigur de chei publice.

6.1 Certificate

Ca o primă încercare de distribuire sigură a cheilor publice, se poate imagina un centru de

distribuţie a cheilor disponibil 24 de ore pe zi pentru a oferi chei publice la cerere. Una dintre

multele probleme ale acestei soluţii este lipsa de scalabilitate şi faptul că centrul de distribuţie

de chei va deveni rapid un punct de gâtuire a procesului de distribuţie de chei. De asemenea,

dacă centrul se va opri vreodată, securitatea Internetului se va pierde in mod subit.

Din cauza acestor motive, s-a dezvoltat o soluţie diferită, care nu presupune un centru de

distribuţie de chei care să fie disponibil tot timpul. De fapt, acesta nu trebuie să fie disponibil

deloc. În schimb, soluţia aleasă certifică faptul că o cheie publică aparţine unei anume

persoane, companii sau altei organizaţii. O organizaţie care certifică chei publice este numită

CA (Certification Authority –Autoritate de Certificare).

Figura 12-16 – Un certificat posibil şi rezumatul său semnat

De exemplu, se presupune că Bob vrea să-i permită lui Alice şi altor persoane să comunice în

mod sigur cu el. El poate să meargă la un CA cu cheia sa publică însoţită de paşaport sau

permisul de conducere şi să ceară să fie certificat. CA-ul va emite un certificat similar cu cel din

Figura 12-16 şi va semna rezumatul de tip SHA-1 al certificatului cu cheia sa secretă. Bob va

plăti preţul cerut de CA şi va obţine o dischetă conţinând certificatul şi rezumatul semnat.Scopul

principal al unui certificat este să facă legătura între o cheie publică şi o entitate (individ,


34

companie etc.). Certificatele în sine nu sunt secrete sau protejate. Bob poate, de exemplu, să

decidă să-şi pună noul certificat pe sit-ul său web, cu o legătură către pagina sa principală în

care sa afirme: "Apasă aici pentru certificatul chei mele publice". Ca rezultat se vor returna atât

certificatul cât şi semnătura sa (codul de dispersie semnat SHA-1 al certificatului).

Când Trudy interceptează cererea lui Alice pentru pagina principală a lui Bob, ce poate face ea

acum? Îşi poate pune propriul ei certificat şi semnătura pe pagina falsă, dar când Alice va citi

certificatul îşi va da seama imediat că nu vorbeşte cu Bob deoarece numele lui Bob nu se

găseşte în certificat. Trudy poate modifica pagina lui Bob din mers, înlocuind cheia publică a lui

Bob cu propria ei cheie. Oricum, când Alice va rula algoritmul SHA-1 pe certificat, va obţine un

rezumat care va fi diferit de cel obţinut prin aplicarea cheii publice a CA-ului asupra semnăturii

certificatului. Cum Trudy nu deţine cheia privată a CA-ului, ea nu are nici o modalitate de a

genera un bloc de semnătură care să conţină codul de dispersie modificat de ea, prin înlocuirea

propriei sale chei publice în pagina de web. În acest fel Alice poate fi sigură ca are cheia publică

a lui Bob şi nu pe cea a lui Trudy sau a altcuiva. Cum am promis, această schemă nu

presupune un CA disponibil mereu pentru verificare, eliminându-se astfel o posibilă gâtuire.

În timp ce funcţia standard a unui certificat este de a face legătura între o cheie publică şi o

entitate, un certificat poate face legătura între o cheie publică şi un atribut. De exemplu un

certificat poate afirma: "Această cheie publică aparţine cuiva care are vârsta de peste 18 ani.

Ea poate fi folosită pentru a dovedi că posesorul cheii private nu este minor şi că are acces la

materiale interzise copiilor şi aşa mai departe" , fără a dezvălui identitatea posesorului

certificatului. În mod obişnuit, persoana care deţine un certificat, îl va trimite unui sit Web,

persoană sau proces de administrare, în care se ţine cont de vârstă. Acel sit (persoana sau

procesul de administrare) va genera un număr aleator şi îl va cripta cu cheia publică prezentă în

certificat. Dacă posesorul certificatului este capabil să decripteze mesajul şi să-l trimită înapoi,

acest lucru va fi o dovada că posesorul deţine într-adevăr atributul din certificat. Ca alternativă,

numărul aleator poate fi folosit pentru a genera o cheie de sesiune pentru a garanta

comunicaţia.

Un alt exemplu în care certificatul poate conţine un atribut este cazul sistemelor distribuite

orientate pe obiecte. Fiecare obiect are în mod normal mai multe metode. Proprietarul unui

obiect poate oferi fiecărui client un certificat care să conţină o hartă de biţi cu metode ce sunt

permise clientului respectiv şi poate face legătura între cheia publică şi harta de biţi prin

folosirea unui certificat semnat. Şi în acest caz, dacă posesorul certificatului poate dovedi că

este în posesia cheii secrete corespunzătoare, el va avea dreptul să execute metodele

identificate de harta de biţi. Certificatul are proprietatea că identitatea posesorului nu trebuie să

fie cunoscută, proprietate utilă în situaţii în care confidenţialitatea este importantă.


35

6.2 X.509

Dacă fiecare persoană care doreşte ceva semnat ar merge la CA pentru diverse tipuri de

certificate, gestionarea tuturor tipurilor de formate ar deveni curând o problemă. Pentru a

rezolva această problemă, s-a proiectat şi aprobat de către ITU un standard pentru certificate.

Standardul se numeşte X.509 şi este folosit pe scara largă în Internet.

X.509 a fost foarte mult influenţat de lumea OSI, împrumutând unele din cele mai proaste

trăsături (ex. politica de nume şi codificarea ). În mod surprinzător, IETF a fost de acord cu

X.509, chiar dacă în alte domenii, de la adresele maşinilor la protocoalele de transport şi

formatul poştei electronice, IETF ignoră OSI şi încearcă să facă lucrurile corect. Versiunea IETF

pentru X.509 este descrisă în RFC 3280.

În principal, X.509 este o modalitate de a descrie certificate. Câmpurile principale dintr-un

certificat sunt listate in Figura 12-17. Descrierea dată aici ar trebui să ofere o idee generală a

ceea ce fac câmpurile respective.

Figura 12-17 – Câmpurile principale dintr-un certificat X.509

De exemplu, daca Bob lucrează în departamentul de împrumuturi al Băncii Bani, adresa sa

X.500 poate să fie:

/c=US/O=MoneyBanc/OU=Loan/CN=Bob/

unde C indică ţara, O indica organizaţia, OU reprezintă o unitate din organizaţie, şi CN este

folosit drept numele comun (common name). CA-urile şi alte entităţi sunt denumite similar. O

problemă mare cu numele X.500 este că, dacă Alice vrea să-l contacteze pe

[email protected] şi are un certificat conţinând un nume X.500, nu este evident că acel

certificat se referă la acel Bob pe care vrea ea să-l contacteze. Din fericire, începând cu

versiunea 3, sunt permise numele DNS în loc de numele X.500, deci această problemă ar putea

să dispară.

mailto:[email protected]


36

Certificatele sunt codificate folosind OSI ASN.1 (Abstract Syntax Notation 1, Notaţia sintactică

abstractă 1), care poate fi văzută ca o structură C, cu excepţia unei notaţii foarte specifice şi

detaliate.

6.3 Infrastructuri cu chei publice

Existenţa unei singure Autorităţi de certificare care să emită toate certificatele din lume nu este

evident o bună soluţie. Ea ar ceda datorită încărcării mari şi va fi în acelaşi timp şi un punct

central de defectare. O soluţie posibilă este existenţa mai multor CA-uri, toate rulând în cadrul

aceleaşi organizaţii şi folosind aceeaşi cheie privată pentru semnarea certificatelor. Cu toate că

se rezolvă problema încărcării şi a defectării, această soluţie introduce o problemă nouă:

dezvăluirea cheilor. Dacă ar exista o zeci de servere împrăştiate prin lume, toate deţinând cheia

privată a CA-ului, posibilitatea furtului cheii private sau a dezvăluirii ei va creşte foarte mult.

Cum compromiterea acestei chei va ruina securitatea infrastructurii electronice mondiale,

existenţa unei singure CA centrale este un risc foarte mare.

În plus, ce organizaţii vor juca rolul de CA? Este foarte greu de imaginat că orice autoritate este

acceptată la nivel mondial ca legitimă şi de încredere. În unele ţări oamenii vor insista să fie

guvernamentală, în timp ce în altele vor insista să nu fie o organizaţie guvernamentală.

Din cauza acestor motive, a fost dezvoltată o altă variantă de certificare a cheilor publice.

Denumirea generală este de PKI (Public Key Infrastructure – Infrastructură cu chei publice).

O PKI are mai multe componente, incluzând utilizatorii, CA-urile, certificatele şi directoarele.

Scopul unei PKI este să ofere o structurare a acestor componente şi să definească standarde

pentru diferite documente şi protocoale. O formă particulară de PKI este o ierarhie de CA-uri,

aşa cum se arată în Figura 12-18. În acest exemplu se prezintă trei niveluri, dar în practică pot fi

mai multe sau mai puţine. CA-ul din vârf, rădăcina, certifică a doua CA, pe care o se va denumi

RA (Regional Authority – Autoritate Regională) deoarece va răspunde de anumite regiuni

geografice, precum o ţară sau un continent. Acest termen nu este standard; de fapt nici un

termen referitor la diferite nivele din arbore nu este standardizat. Aceste RA-uri certifică de fapt

adevăratele CA-uri, care vor emite certificate X.509 pentru organizaţii şi indivizi. Când rădăcina

autorizează o nouă RA, ea va genera un nou certificat X.509 care atestă că a aprobat RA-ul,

incluzând în el noua cheie publică a RA-ului, îl va semna şi îl va trimite RA-ului. Similar, RA-ul

aprobă noi CA-uri, generează şi semnează certificate care atestă aprobarea şi conţin cheia

publică a CA-ului.

Exemplu de PKI funcţionează în modul următor. Se presupune că Alice are nevoie de cheia

publică a lui Bob pentru a comunica cu acesta, deci ea va căuta şi va găsi un certificat semnat

de CA 5 care să conţină cheia publică respectivă. Dar Alice nu a auzit niciodată de CA 5. Din

câte ştie ea, CA 5 poate fi şi fiica de 10 ani a lui Bob. S-ar putea duce la CA5 şi să-i pretindă să


37

îşi dovedească legitimitatea. CA 5 răspunde cu certificatul obţinut de la RA 2, care conţine

cheia publică a lui CA 5. Acum, deţinând cheia publică a lui CA 5, ea poate verifica dacă

certificatul lui Bob este într-adevăr semnat de CA 5 şi datorită acestui fapt este legal.

Figura 12-18. – (a) O PKI ierarhică (b) Un lanţ de certificate

Dar dacă RA 2 este copilul lui Bob? Deci pasul următor pentru ea este de a cere ca RA 2 să-şi

dovedească legitimitatea. Răspunsul la întrebarea ei este certificatul semnat de rădăcină şi care

conţine cheia publică a lui RA 2. Acum Alice este sigură ca ea deţine cheia publică a lui Bob.

Dar cum ştie Alice sa găsească cheia publică a rădăcinii? Magie. Se presupune că toată lumea

cunoaşte cheia publică a rădăcinii. De exemplu, programul său de navigare ar fi putut fi vândut

cu cheia publică a rădăcinii înglobată în el.

Bob nu vrea să-i provoace lui Alice multă bătaie de cap. El ştie că ea trebuie să verifice CA 5 şi

RA 2, deci pentru a-i economisi timp, el colectează certificatele necesare şi îi transmite încă

două certificate alături de al său. Acum ea îşi poate folosi propria ei informaţie cu privire la cheia

publică a rădăcinii pentru a verifica certificatul din vârful ierarhiei şi cheia publică conţinută în

acesta pentru a verifica al doilea certificat. În acest fel, Alice nu mai trebuie să contacteze pe

nimeni pentru a efectua verificarea. Pentru că toate certificatele sunt semnate, ea poate detecta

cu uşurinţa orice încercare de falsificare a conţinutului acestora. Un lanţ de certificate care duce

la rădăcină, ca în acest exemplu, este denumit câteodată lanţ de încredere sau cale de

certificare. Tehnica este larg răspândită în practică.

Desigur, mai rămâne problema cine va juca rolul de rădăcină. Soluţia este să nu fie o singură

rădăcină, ci mai multe, fiecare cu propriile sale RA-uri şi CA-uri. De fapt, programele de

navigare moderne vin preîncărcate cu cheile publice a peste 100 de rădăcini, denumite


38

câteodată puncte de încredere. În acest fel, poate fi evitată existenţa la nivel mondial a unei

singure autorităţi de încredere.

Dar apare acum problema cum poate decide producătorul programului de navigare care dintre

punctele sugerate sunt de încredere şi care nu. Totul se reduce la încrederea utilizatorului în

faptul că producătorul programului de navigare este capabil să facă alegeri înţelepte şi nu doar

să aprobe toate punctele de încredere care au plătit o taxă pentru includere. Majoritatea

programelor de navigare permit utilizatorilor să inspecteze cheile rădăcinilor (în mod obişnuit

sub formă de certificate semnate de rădăcină) şi să le şteargă pe cele care par dubioase.

Directoare

O altă problemă pentru orice PKI este locul în care se stochează certificatele (şi lanţurile care

duc către un punct de încredere cunoscut). O posibilitate este ca fiecare utilizator să-şi

stocheze propriile certificate. Cu toate că acest lucru este sigur (de ex. nu există nici o

posibilitate ca un utilizator să falsifice certificatele semnate fără a fi detectat), nu este prea

convenabil. O alternativă care a fost propusă este folosirea DNS ca director pentru certificate.

Înainte de a-l contacta pe Bob, Alice probabil îi va căuta adresa IP folosind DNS, deci de ce să

nu întoarcă DNS-ul întregul lanţ de certificate odată cu adresa IP?

Unele persoane consideră că aceasta este soluţia corectă, dar alţii preferă servere de

directoare specializate a căror îndatorire este doar gestionarea de certificate X.509.

Directoarele de acest fel pot oferi servicii de căutare bazate pe proprietăţile numelor X.500. De

exemplu, în teorie un astfel de director poate răspunde la o întrebare de tipul: "Dă-mi o listă a

persoanelor numite Alice care lucrează în departamentul de vânzări oriunde în Canada sau

S.U.A.". LDAP poate fi un candidat care să stocheze acest tip de informaţii.

Revocarea

Lumea reală este plină de certificate, la fel ca în cazul paşapoartelor şi al carnetelor de

conducere. Câteodată aceste certificate pot fi revocate, de exemplu, carnetul de conducere

poate fi suspendat pentru conducere sub influenţa alcoolului sau pentru o altă greşeală de

conducere. Aceeaşi problemă apare şi în lumea digitală: emitentul unui certificat poate decide

dacă să-l revoce problemă apare şi în lumea digitală: emitentul unui certificat poate decide dacă

să-l revoce în cazul în care persoana sau organizaţia care îl deţine a abuzat de el într-un

anume mod. El poate fi de asemenea revocat dacă cheia privată a subiectului a fost

compromisă (demascată), sau mai rău, dacă cheia privată a CA-ului a fost compromisă. Atunci,

o PKI trebuie să fie capabilă să trateze problema revocării.

Primul pas în această direcţie este ca fiecare CA să emită periodic o CRL (Certificate


39

Revocation List – Listă de Certificate Revocate) conţinând numerele seriale ale tuturor

certificatelor revocate de aceasta. Cum certificatele conţin data de expirare, CRL-ul trebuie să

conţină doar numerele seriale ale certificatelor care încă nu au expirat. Odată ce perioada de

validitate a expirat, un certificat este automat invalidat, deci nu mai este necesară nici o

distincţie între acelea care tocmai au expirat şi cele are au fost de fapt revocate. În ambele

cazuri, certificatele nu mai pot fi folosite în continuare.

Din păcate, introducerea CRL-ului înseamnă că un utilizator care doreşte să folosească un

certificat trebuie acum să consulte CRL-ul pentru a vedea dacă certificatul a fost revocat. Dacă

a fost revocat, nu mai trebuie folosit. Oricum, chiar dacă certificatul nu este în listă, el poate să fi

fost revocat chiar după ce lista a fost publicată. Atunci, singura modalitate rămâne întrebarea

către CA. La o nouă folosire a aceluiaşi certificat, CA-ul trebuie întrebat din nou, pentru este

posibil ca certificatul să fi fost revocat cu câteva secunde în urmă.

O altă complicaţie este că un certificat revocat poate în principiu să fie restabilit, de exemplu,

dacă a fost revocat datorită neplăţii unei taxe care acum s-a plătit. Având de a face cu

revocarea (şi posibil cu restabilirea) se elimină una dintre cele mai bune proprietăţi ale

certificatelor, adică faptul că ele pot fi folosite fără a fi necesar sa se contacteze o RA.

Unde trebuie stocate CRL-urile? Un loc bun ar putea fi acela în care se stochează certificatele

însele. O strategie este ca CA-ul să publice periodic CRL-uri şi să permită directoarelor să

înlăture certificatele revocate. Dacă nu sunt folosite directoare pentru stocarea de certificate,

CRL-urile pot fi ţinute în diverse locuri convenabile din reţea. Cum o CRL este ea însăşi un

document, dacă este falsificată, falsul se poate detecta uşor.

7. Securitatea comunicaţiei

Securitatea comunicaţiei se referă la felul în care se transferă biţii în mod confidenţial şi fără a fi

modificaţi, de la sursă la destinaţie. Fără discuţie că acestea nu sunt singurele idei despre

securitatea în reţele, dar cu siguranţă sunt printre cele mai importante.

7.1 IPsec

IETF a ştiut de ani de zile că securitatea lipsea din Internet. Adăugarea ei nu a fost uşoară

deoarece a izbucnit un război cu privire la locul de plasare al acesteia. Majoritatea experţilor în

securitate credeau că pentru a fi într-adevăr sigure, criptarea şi verificarea integrităţii trebuie să

fie capăt la capăt (de ex. nivelul aplicaţie). Adică, procesul sursă criptează şi/sau protejează

datele din punct de vedere al integrităţii şi le trimite către procesul de destinaţie, unde sunt

decriptate şi/sau verificate. Orice falsificare între aceste două procese, incluzând sistemele lor


40

de operare, poate fi detectată. Problema cu această abordare este că presupune schimbarea

tuturor aplicaţiilor pentru a le securiza. În această idee, următoarea abordare posibilă este

plasarea criptării pe nivelul transport sau într-un nou nivel între nivelul aplicaţie şi nivelul

transport, păstrând mecanismul tot capăt la capăt, dar fără a mai fi necesare schimbări ale

aplicaţiilor.

Ideea opusă este că utilizatorii nu înţeleg securitatea şi că nu vor fi capabili să o folosească în

mod corect şi nimeni nu doreşte să modifice programele existente în nici un fel, deci nivelul

reţea trebuie să autentifice şi/sau cripteze pachetele fără nici o implicare din partea utilizatorilor.

După ani de controverse, această idee a câştigat suficient suport astfel încât a fost definit un

standard de securitate pentru nivelul reţea. În parte, argumentul a fost că având criptarea la

nivelul reţea nu împiedică utilizatorii conştienţi de problema securităţii să o folosească corect şi

îi ajută într-un anumit grad pe utilizatorii neavizaţi.

Rezultatul acestui “război” a fost un proiect numit IPsec (IP securizat), care este descris în

RFCurile 2401, 2402 şi 2406, printre altele. Nu toţi utilizatorii doresc criptarea (pentru că este

costisitoare din punct de vedere al puterii de calcul). În loc să fie opţională, s-a decis să se

impună criptarea permanent, dar cu posibilitatea de folosire unui algoritm nul. Algoritmul nul

este descris şi lăudat pentru simplitatea sa, uşurinţa de implementare şi viteza mare în RFC

2410.

Proiectul complet IPsec este o cadru de lucru pentru mai multe servicii, algoritmi şi granularităţi.

Motivul pentru servicii multiple este că nu toată lumea doreşte să plătească preţul necesar

tuturor serviciilor, deci serviciile sunt disponibile la cerere. Serviciile principale sunt

confidenţialitatea, integritatea datelor, şi protejarea lor de atacul prin replicare (un intrus poate

replica un dialog). Toate acestea se bazează pe criptografia cu chei simetrice pentru că înalta

performanţă este un lucru crucial.

Motivul pentru care există mai mulţi algoritmi este că un algoritm care acum pare sigur poate fi

spart in viitor. Făcând IPsec-ul independent de algoritmi, cadrul de lucru poate supravieţui chiar

dacă mai târziu un algoritm este spart.

Motivul pentru care există mai multe granularităţi se datorează posibilităţii de a se proteja o

singură conexiune TCP, tot traficul dintre două gazde, sau tot traficul dintre o pereche de rutere

securizate, printre alte posibilităţi.

Un aspect destul de surprinzător al IPsec-ului este că deşi se găseşte pe nivel IP, el este

orientat pe conexiune. De fapt, nu este chiar aşa de surprinzător deoarece pentru a exista

securitate, o cheie trebuie să fie stabilită şi folosită pentru o anume perioadă de timp, în esenţă,

un fel de conexiune. De asemenea conexiunile amortizează costurile de iniţializare pentru mai

multe pachete. În contextul IPsec o "conexiune" este denumită SA (Security Association –

Asociere securizată). O SA este o conexiune simplă între două capete şi are asociat un


41

identificator de securitate. Dacă este nevoie de un trafic securizat în ambele direcţii, sunt

necesare două asocieri securizate. Identificatorii de securitate sunt transportaţi în pachetele

care se transmit pe aceste conexiuni securizate şi sunt folosiţi la căutarea cheilor sau a altor

informaţii relevante atunci când soseşte un pachet securizat.

Din punct de vedere tehnic, IPsec conţine două părţi principale. Prima parte descrie două noi

antete care pot fi adăugate pachetelor pentru a transporta identificatorul de securitate, datele de

control al integrităţii şi alte informaţii. Cealaltă parte, ISAKMP (Internet Security Association and Key Managment Protocol – Asociaţia Securităţii Internet şi Protocolul de Gestiune al

Cheilor) se ocupă cu stabilirea cheilor.

IPsec poate fi folosit în două moduri. În modul transport, antetul IPsec este inserat chiar după

antetul IP. Câmpul de Protocol din antetul IP este schimbat pentru a indica faptul că un antet

IPsec urmează după antetul normal de IP (înainte de antetul TCP). Antetul IPsec conţine

informaţii de securitate, în principal identificatorul SA, un nou număr de secvenţă şi, posibil, o

verificare a integrităţii încărcăturii utile.

În modul tunel, întregul pachet IP, antet şi restul, este încapsulat în corpul unui nou pachet IP

cu un antet IP complet nou. Modul tunel este folositor când capetele tunelului se termină la o

locaţie diferită de destinaţia finală. În unele cazuri, capătul tunelului este o maşină poartă de

aplicaţie (gateway) securizată, de exemplu, de zidul de protecţie (firewall) al unei companii. În

acest mod, zidul de protecţie încapsulează şi decapsulează pachete la trecerea prin el.

Terminând tunelul prin această maşină securizată, maşinile din LAN-ul companiei nu trebuie să

fie conştiente de IPsec. Doar zidul de protecţie trebuie să ştie de el.

Modul tunel este de asemenea util când o legătura a unei conexiuni TCP este agregată şi se

comportă ca un flux criptat, deoarece împiedică un intrus să vadă câte pachete trimite cineva

către altcineva. Câteodată doar cunoscând cât de mult trafic este dirijat undeva reprezintă o

informaţie de valoare. Dezavantajul modului tunel este că adaugă un antet IP în plus, crescând

astfel în mod substanţial dimensiunea unui pachet. Prin contrast, modul transport nu afectează

atât de mult dimensiunea pachetului.

Primul antet nou este AH (Authentication Header – Antetul de Autentificare). El permite

controlul integrităţii şi securitate anti-replică, dar nu şi confidenţialitate (de ex. nu criptează

datele). Folosirea AH în modul tunel este ilustrată în Figura 12-19. În IPv4, el este interpus între

antetul IP (incluzând orice opţiuni) şi antetul TCP. În IPv6 este doar o altă extensie a antetului şi

este tratată ca atare. De fapt, formatul este apropiat de cel al standardului IPv6 de extensie a

antetului. Este posibil ca încărcătura utilă să trebuiască a fie completată până la o anumită

lungime pentru algoritmul de autentificare după cum este prezentat în figură.


42

Figura 12-19 –Antetul de autentificare IPsec în modul transport pentru IPv4

Se examinează în continuare antetul AH. Câmpul Antetul următor este folosit pentru a păstra

valoarea anterioară pe care a avut-o câmpul Protocol IP înainte de a fi înlocuit cu 51 pentru a

indica faptul că urmează un antet AH. În majoritatea cazurilor, aici va fi plasat codul pentru TCP

(6). Lungimea încărcării utile o reprezintă numărul de cuvinte de 32 de biţi din antetul AH minus

2.

Indexul parametrilor de securitate reprezintă identificatorul de conexiune. Acesta este inserat

de către emiţător pentru a indica o anumită înregistrare în baza de date a receptorului. Această

înregistrare conţine cheia partajată folosită în această sesiune şi alte informaţii despre

conexiune. Dacă acest protocol ar fi fost inventat de către ITU şi nu de către IETF, acest câmp

ar fi fost denumit Număr de circuit virtual.

Câmpul Număr de secvenţă este folosit pentru a număra toate pachetele trimise pe un SA.

Fiecare pachet primeşte câte un identificator unic, chiar şi retransmisiile, cu alte cuvinte copia

unui pachet primeşte un număr diferit de cel original (chiar dacă numărul său de secvenţă TCP

este acelaşi). Scopul acestui câmp este de a detecta atacurile prin replică. Aceste numere de

secvenţă nu se pot repeta. Dacă toate cele 232 de numere au fost epuizate, trebuie stabilit un

nou SA pentru a continua comunicaţia.

În sfârşit, câmpul Date de autentificare este un câmp de lungime variabilă care conţine

semnătura digitală. Când este stabilit un SA, cele două părţi negociază algoritmul de semnare

pe care îl vor folosi. În mod normal, nu este folosită criptografia cu chei publice pentru că

pachetele trebuie procesate rapid, iar toţi algoritmii cu chei publice sunt prea lenţi. Deoarece

IPsec este bazat pe criptografia cu chei simetrice iar emiţătorul şi receptorul negociază o cheie

partajată înaintea stabilirii unui SA, cheia partajată este folosită în procesul de semnare. O

modalitate simplă este de a calcula rezumatul pentru un pachet şi cu cheia partajată. Desigur,

cheia partajată nu este transmisă. O schemă ca aceasta este denumită HMAC (Hashed Message Authentication Code – Cod de Autentificare bazat pe un rezumat de mesaj). Este

mult mai rapid să calculezi un rezumat decât să rulezi întâi SHA-1 şi apoi să rulezi RSA asupra


43

rezultatului.

Antetul AH nu permite criptarea datelor, deci este cel mai folosit atunci când este necesară

verificarea integrităţii dar nu este necesară confidenţialitatea. O proprietate demnă de notat a

antetului AH este aceea că verificarea integrităţii foloseşte o parte din câmpurile antetului IP, şi

anume, acelea care nu se schimbă când pachetul trece de la un ruter la altul. De exemplu,

câmpul Durata de viaţă se schimbă la fiecare ruter şi nu poate fi inclus în verificarea integrităţii.

În orice caz adresa sursa IP este inclusă în această verificare, un intrus neputând să falsifice

originea pachetului. O altă variantă de antet IPsec este ESP (Encapsulating Security Payload

– Încapsularea încărcăturii utile de securitate). Folosirea acestuia, atât pentru modul transport,

cât şi pentru modul tunel, este prezentată în Figura 12-20.

Figura 12-20 – (a) ESP în mod transport (b) ESP în mod tunel

Antetul ESP conţine două cuvinte de 32 de biţi. Acestea sunt câmpurile Indexul Parametrilor de

Securitate şi, respectiv, Numărul de Secvenţă pe care le-am întâlnit la AH. Un al treilea cuvânt

care, în general, le urmează (dar care din punct de vedere tehnic nu este parte a antetului) este

câmpul Vector de Iniţializare, folosit pentru criptarea datelor; dacă nu se foloseşte criptarea

acest câmp este omis.

De asemenea, ESP oferă verificarea integrităţii pentru HMAC, aşa cum o face şi AH, dar în loc

să fie inclus în antet, urmează după încărcătura utilă, aşa cum se arată în Figura 12-20.

Includerea HMAC la sfârşit are un avantaj în implementarea hardware. HMAC poate fi calculat

pe măsură ce biţii ies dintr-o interfaţă de reţea ataşarea sa la sfârşit fiind foarte simplă. Din

această cauză Ethernet şi alte LAN-uri au propriile CRC la sfârşitul pachetelor în loc să le aibă

la începutul acestora. Cu AH, pachetul trebuie să fie păstrat într-o zonă tampon şi semnătura să

fie calculată înainte ca pachetul să fie trimis, reducând astfel numărul de pachete care pot fi

transmise pe secundă.

Deoarece ESP poate face tot ceea ce poate face AH şi chiar mai mult şi faptul că este mai

eficient la iniţializare decât acesta, se ridică întrebarea: De trebuie complicat cu AH? Răspunsul

este mai mult istoric. La început, AH se ocupa numai de integritate iar ESP numai de


44

confidenţialitate. Mai târziu, integritatea a fost adăugată şi la ESP, dar cei care au proiectat AH

nu au vrut ca acesta să dispară după ce au muncit atât de mult la el. În orice caz, singurul lor

argument real este faptul că AH verifică o parte a antetului IP, ceea ce ESP nu face; dar acesta

este un argument nesemnificativ. Un alt argument nesemnificativ este acela că un produs care

suportă AH, dar nu suportă ESP, poate avea mai puţine probleme în a obţine licenţa de export,

datorită faptului că nu foloseşte criptarea. Este posibil ca în viitor AH să nu mai fie folosit.

7.2 Ziduri de protecţie

Posibilitatea de a conecta orice calculator, de oriunde, cu orice alt calculator, de oriunde, este o

sabie cu două tăişuri. Pentru persoanele aflate acasă, colindatul prin Internet aduce multe

bucurii. Pentru administratorii pe probleme de securitate ai firmelor, este un coşmar. Multe

companii au mari cantităţi de informaţie confidenţială sub formă electronică secrete de afaceri,

planuri de dezvoltare produse, strategii de marketing, analize financiare etc. Dezvăluirea

acestor informaţii către un competitor poate avea consecinţe cumplite. În afara pericolului

scurgerii de informaţii, există şi un pericol al infiltrării de informaţii. În particular, viruşii, viermii şi

alţi dăunători digitali pot încălca securitatea, distruge informaţii de valoare şi irosi o mare

cantitate din timpul administratorilor care încearcă să cureţe dezordinea pe care o lasă.

În consecinţă, sunt necesare mecanisme pentru a păstra biţii „buni” în interior şi biţii „răi” afară.

O metodă este folosirea IPsec. Această abordare protejează datele în tranzit între situri sigure.

Cu toate acestea, IPsec nu face nimic pentru a ţine dăunătorii digitali şi spărgătorii în afara

LAN-ului companiei. Pentru a realiza acest obiectiv, este nevoie studierea zidurilor de protecţie

(firewalls).

O companie poate avea multe LAN-uri conectate în moduri arbitrare, dar tot traficul către sau de

la companie este forţat printr-un pod mobil electronic (zidul de protecţie), aşa cum este

prezentat în Figura 12-21.

În această configuraţie zidul de protecţie are două componente: două rutere care fac filtrare de

pachete şi o poartă de aplicaţii. Există, de asemenea, configuraţii şi mai simple, dar avantajul

acestui proiect este că fiecare pachet trebuie să tranziteze două filtre şi o poartă de aplicaţie

pentru a intra sau ieşi. Nu există altă rută.

Fiecare filtru de pachete este un ruter standard echipat cu unele funcţii suplimentare. Acestea

permit inspectarea fiecărui pachet care intră sau iese. Pachetele care îndeplinesc anumite

criterii sunt transmise normal. Cele care nu trec testul sunt eliminate.


45

Figura 12-21 – Un zid de protecţie format din două filtre de pachete şi o poartă de aplicaţii.

În Figura 12-21, este foarte probabil ca filtrul de pachete din interiorul LAN-ului să verifice

pachetele care ies, iar cel din exteriorul LAN-ului să verifice pachetele care intră. Pachetele

care trec de prima barieră merg la poarta de aplicaţii pentru o examinare ulterioară. Motivul

introducerii a două filtre de pachete în reţele diferite este de a asigura că nici un pachet nu intră

sau iese fără a fi obligat să treacă prin poarta de aplicaţii: nu există nici o cale pe care să o

ocolească.

Filtrele de pachete sunt, în mod tipic, dirijate de tabele configurate de administratorul de sistem.

Aceste tabele enumeră sursele şi destinaţiile acceptabile, sursele şi destinaţiile care sunt

blocate şi reguli implicite despre ce se face cu pachetele care vin sau se duc la alte maşini.

Blocarea pachetelor care ies este mai complicată, deoarece, deşi cele mai multe situri aderă la

convenţiile standard de numire a porturilor, nu sunt obligate să o facă. Mai mult, pentru servicii

importante, cum ar fi FTP (File Transfer Protocol – Protocol de transfer fişiere), numerele de

port sunt atribuite dinamic. În plus, deşi blocarea conexiunilor TCP este dificilă, blocarea

pachetelor UDP este şi mai grea datorită faptului că se ştie foarte puţin a priori despre ce vor

face. Multe filtre de pachete pur şi simplu interzic în totalitate traficul UDP.

A doua jumătate a mecanismului de zid de protecţie este poarta de aplicaţie. În loc să trateze

pachete brute, o poartă operează la nivelul aplicaţie. O poartă de poştă electronică, de

exemplu, poate fi configurată să examineze fiecare mesaj care intră sau iese. Pentru fiecare

mesaj, ea ia decizia de a-l transmite sau elimina pe baza câmpurilor din antet, a dimensiunii

mesajului sau chiar a conţinutului

Proiectele de instalare au libertatea de a configura una sau mai multe porţi de aplicaţie pentru

aplicaţii specifice, dar nu este ieşit din comun ca organizaţii suspicioase să permită intrarea şi


46

ieşirea poştei electronice şi, probabil, folosirea World Wide Web, dar să interzică orice altceva

ca fiind prea riscant. Combinat cu criptarea şi cu filtrarea de pachete, acest aranjament oferă o

cantitate limitată de securitate cu costul unor inconveniente.

Chiar dacă zidul de protecţie este configurat perfect, există încă o groază de probleme de

securitate. De exemplu, dacă un zid de protecţie este configurat să accepte pachete doar de la

anumite reţele (de ex. alte sedii ale companiei), un intrus din exteriorul zidului de protecţie poate

să-şi pună o adresă falsă pentru a evita această verificare. Dacă un individ din interior doreşte

să vândă documentele secrete, el le poate cripta sau chiar fotografia şi apoi să sustragă pozele

ca fişiere JPEG, care evită orice filtru de texte.

În plus, există o întreagă altă clasă de atacuri cărora zidurile de protecţie nu le pot face faţă.

Ideea de bază a unui zid de protecţie este de a împiedica intruşii să pătrundă în reţeaua

protejată şi de a împiedica datele secrete să iasă din acea reţea. Din păcate, există oameni

care nu au altceva mai bun de făcut, decât să încerce să scoată din funcţiune anumite situri. Ei

realizează acest lucru prin trimiterea unui număr foarte mare de pachete legitime către o ţintă,

până când aceasta va fi scoasă din funcţiune datorită încărcării mari. De exemplu, pentru a

distruge un sit de web, un intrus poate trimite un pachet TCP SYN pentru a stabili o conexiune.

Ca urmare, situl va aloca, într-o tabelă, o intrare pentru acea conexiune şi va trimite ca răspuns

un pachet SYN +ACK. Dacă intrusul nu răspunde intrarea din tabelă va fi ocupată pentru un

interval de timp de până la câteva secunde, până când se va produce un timeout. Dacă intrusul

va trimite mii de cereri de conexiune, toate intrările din tabelă vor fi ocupate astfel încât nu vor

mai putea fi stabilite noi conexiuni legitime. Atacurile în care scopul intrusului este de a opri

funcţionarea ţintei, în locul sustragerii de informaţii, sunt denumite atacuri DoS (Denial of Service – Refuzul Serviciilor). În mod obişnuit, pachetele de cereri au o adresă sursă falsă

pentru ca intrusul să nu poată fi detectat uşor.

O variantă şi mai pesimistă este aceea în care intrusul a pătruns deja în sute de calculatoare

aflate în alte zone ale lumii, pe care apoi le comandă să atace aceeaşi ţintă în acelaşi timp. Nu

numai că această abordare creşte forţa de atac a intrusului, dar ea reduce şansele ca ea să fie

detectată, deoarece pachetele provin de la un mare număr de maşini aparţinând unor utilizatori

ce nu sunt suspecţi. Un astfel de atac este denumit atac DDoS (Distributed Denial of Service

– Refuzul serviciilor realizat în mod distribuit). Împotriva acestui atac este greu de găsit o

apărare. Chiar dacă maşina atacată poate recunoaşte rapid o cerere falsă, trece un anumit timp

pentru procesarea şi ignorarea acestei cereri, iar dacă sosesc destul de multe cereri pe

secundă procesorul va fi ocupat tot timpul cu tratarea acestora.

7.3 Reţele private virtuale

Multe companii au birouri răspândite în mai multe oraşe şi uneori în mai multe ţări. În trecut,


47

înaintea apariţiei reţelelor de date publice, era obişnuită închirierea de către aceste companii a

unor linii telefonice, aparţinând companiilor de telefonie, între unele sau între toate perechile de

locaţii ale birourilor. Unele companii încă mai fac acest lucru. O reţea alcătuită din

calculatoarele unei companii şi liniile telefonice închiriate este denumită reţea privată. Un

exemplu de reţea privată conectând trei birouri este arătată în Figura 12-22(a).

Figura 12-22 – (a) O reţea privată folosind linii închiriate (b) O reţea privată virtuală

Reţelele private funcţionează bine şi sunt foarte sigure. Dacă singurele linii disponibile sunt linii

închiriate, atunci nu există trafic care să se scurgă în afara companiei, iar intruşii trebuie să se

conecteze fizic la liniile respective pentru a pătrunde în reţea, ceea ce nu este un lucru uşor de

realizat. Problema care apare cu reţelele private este acea că închirierea unei singure linii de

capacitate mare poate fi costisitoare și multe companii au vrut să-şi transmită traficul de date (şi

posibil cel de voce) prin reţelele publice, dar fără a renunţa la securitatea unei reţele private.

Această necesitate a condus în curând la inventarea reţelelor private virtuale VPN (Virtual Private Networks – Reţele private virtuale), care sunt reţele construite deasupra unor reţele

publice, dar care beneficiază de proprietăţile unei reţele private. Aceste reţele sunt denumite

virtuale pentru că ele constituie o iluzie, aşa cum circuitele virtuale nu sunt circuite reale şi cum

memoria virtuală nu este o memorie reală.

Deşi VPN-urile pot fi implementate peste ATM (sau frame relay), o tendinţă populară aflată în

creştere este de a construi VPN-uri direct peste Internet. O modalitate de proiectare obişnuită

este de a echipa fiecare birou cu un zid de protecţie şi de a crea tuneluri prin Internet între toate

perechile de birouri, după cum este ilustrat în Figura 12-22(b). Dacă pentru tunelare este folosit

IPsec, atunci este posibilă agregarea întregului trafic dintre oricare două perechi de birouri într-

un singur SA autentificat şi criptat, oferindu-se astfel controlul integrităţii, confidenţialitate şi

chiar o imunitate considerabilă asigurată analizei de trafic.

Când un sistem este pornit, fiecare pereche de ziduri de protecţie trebuie să negocieze

parametrii SA-ului ei, incluzând serviciile, modurile, algoritmii şi cheile. Multe ziduri de protecţie


48

au înglobate capabilităţi de VPN, deşi chiar şi unele rutere obişnuite beneficiază de acestea.

Dar, deoarece zidurile de protecţie au prioritate în problema securităţii, este natural a avea

tuneluri care încep şi se termină în ziduri de protecţie, furnizând o separare clară între

companie şi Internet. Astfel, zidurile de protecţie, VPN-urile şi IPsec folosit cu ESP în mod tunel

formează o combinaţie naturală şi larg folosită în practică.

Odată ce a fost stabilit un SA, transferul datelor poate începe. Pentru un ruter din Internet, un

pachet care traversează un tunel VPN este un pachet obişnuit. Singurul lucru neobişnuit la

acesta este prezenţa antetului IPsec după antetul IP, dar deoarece aceste extra-antete nu au

efect în procesul de rutare, ruterele nu le iau în considerare.

Un avantaj cheie al organizării VPN în acest fel este transparenţa completă pentru programele

utilizatorilor. Zidurile de protecţie iniţializează şi gestionează SA-urile. Singura persoană care

are cunoştinţă de acest proces este administratorul de sistem care configurează şi gestionează

zidul de protecţie. Pentru oricine altcineva lucrurile arată ca şi cum ar fi o reţea privată bazată

pe linie închiriată.

7.4 Securitatea în comunicaţiile fără fir

Este surprinzător de uşor de proiectat un sistem care din punct de vedere logic, este complet

securizat folosind VPN şi ziduri de protecţie, dar prin care, în practică, informaţia se scurge ca

prin sită. Această situaţie poate fi întâlnită dacă o parte dintre maşini sunt fără fir şi folosesc

comunicaţia radio, care trece prin zidul de protecţie în ambele sensuri. Aria de acoperire a

reţelelor 802.11 este foarte adesea de câteva sute de metri, astfel că oricine doreşte să

spioneze o companie, poate să vină dimineaţa în parcarea pentru angajaţi, să lase un calculator

portabil care este configurat pentru o reţea 802.11 să înregistreze tot ce aude şi să dispară

pentru restul zilei.

O mare parte a problemei de securitate poate fi urmărită până la producătorii de staţii de bază

care comunică fără fir (puncte de acces), care încearcă să-şi facă produsele prietenoase pentru

utilizatori. De obicei, dacă utilizatorul scoate dispozitivul din cutie şi îl introduce în priză, acesta

începe să funcţioneze imediat – aproape fără nici un fel de securitate, împrăştiind secrete către

oricine se află în aria de acoperire radio. Dacă apoi este şi legat la o reţea Ethernet, tot traficul

Ethernet va apărea dintr-o dată şi în locul de parcare. Reţelele fără fir sunt visul oricărui agent

ascuns: date gratuite, fără să trebuiască să lucrezi pentru ele. Prin urmare, nici nu mai trebuie

spus că securitatea este şi mai importantă pentru reţelele fără fir decât pentru cele cu fir.

Securitatea 802.11

Standardul 802.11 recomandă un protocol de securitate la nivelul legătură de date care se


49

numeşte WEP (Wired Equivalent Privacy – Confidenţialitate Echivalentă cu cea Cablată), care

este proiectat pentru a face securitatea unui LAN cu comunicaţie fără fir la fel de bună ca cea a

unui LAN cablat. Cum LAN-urile cu cabluri nu au de obicei nici un fel de securitate, acest

obiectiv este uşor de îndeplinit şi WEP îl îndeplineşte.

Când securitatea 802.11 este activată, fiecare staţie are o cheie secretă comună cu staţia de

bază.

Standardul nu specifică cum sunt distribuite cheile. Pot fi încărcate înainte de către producător.

Pot fi interschimbate înainte prin reţeaua cu fire. În fine, fie staţia de bază, fie maşina

utilizatorului poate alege o cheie aleatoare şi o poate trimite prin aer criptată cu cheia publică a

celeilalte staţii. Odată stabilită, cheia rămâne neschimbată în general pentru luni sau ani.

Criptarea WEP foloseşte un cifru flux bazat pe algoritmul RC4. RC4 a fost proiectat de Ronald

Rivest şi a fost ţinut secret până în 1994 când s-au scurs nişte informaţii şi a fost publicat pe

Internet. După cum am mai subliniat înainte, este aproape imposibil ca algoritmii să fie păstraţi

secreţi, chiar dacă scopul este protejarea proprietăţii intelectuale (cum a fost în acest caz), mai

degrabă decât securitatea prin obscuritate (care nu a fost scopul cu RC4). În WEP, RC4

generează un şir-cheie (keystream) care este combinat prin XOR cu textul clar pentru a forma

textul cifrat.

Figura 12-23 –Criptarea pachetelor folosind WEP

Încărcătura utilă a fiecărui pachet este criptată folosind metoda din Figura 12-23. Mai întâi,

încărcătura este verificată folosind polinomul CRC-32, iar suma de control este adăugată

încărcăturii pentru a forma textul clar pentru algoritmul de criptare. Acest text clar este combinat

XOR cu o bucată din şirul cheie de aceeaşi lungime. Rezultatul este textul cifrat. IV-ul utilizat

pentru pornirea RC4 este trimis împreună cu textul cifrat. Când receptorul primeşte pachetul,

extrage din acesta încărcătura utilă criptată, generează şirul cheie din cheia secretă şi din IV pe

care tocmai l-a primit şi apoi efectuează operaţia XOR între şirul cheie şi încărcătura utilă a


50

pachetului pentru a obţine textul în clar. Apoi poate verifica suma de control pentru a se asigura

că pachetul a ajuns intact.

Deşi această abordare arată bine la prima vedere, a fost deja publicată o metodă de a o sparge

În primul rând, surprinzător de multe instalaţii folosesc aceeaşi cheie comună pentru toţi

utilizatorii, caz în care fiecare utilizator poate citi traficul tuturor celorlalţi utilizatori. Acest lucru

este desigur echivalent cu Ethernet-ul, dar nu este foarte sigur.

WEP poate fi atacat chiar dacă fiecare utilizator are o cheie distinctă. Din moment ce cheile

sunt în general stabile pentru perioade lungi de timp, standardul WEP recomandă (dar nu

impune) ca IV-ul să fie schimbat la fiecare pachet pentru a evita atacul de tip reutilizare asupra

şirului cheie, atac discutat în secţiunea 8.2.3. Din nefericire, multe plăci 802.11 pentru

calculatoarele portabile resetează IV la 0 când placa este introdusă în calculator şi apoi îl

incrementează cu 1 la fiecare pachet trimis. Cum utilizatorii scot şi apoi reinserează frecvent

aceste plăci, pachetele cu valori mici pentru IV sunt destul de obişnuite. Dacă Trudy poate să

colecteze mai multe pachete trimise de acelaşi utilizator, care au aceeaşi valoare pentru IV

(care este trimis în clar cu fiecare pachet), atunci ea poate să calculeze XOR între două valori

de textul clar şi poate astfel să spargă cifrul. Dar, chiar dacă placa 802.11 alege o valoare

aleatoare pentru fiecare pachet, IV are doar 24 de biţi, astfel încât după ce au fost trimise 224

pachete, va trebui ca valorile să fie refolosite. Mai rău, folosind valori aleatoare pentru IV,

numărul probabil de pachete care trebuie trimise înainte ca acelaşi număr să fie folosit de două

ori este în jur de 5000, datorită atacului de tip „ziua de naştere”. Ca urmare, dacă Trudy ascultă

pentru câteva minute, ea este aproape sigură că va captura două pachete cu acelaşi IV şi

aceeaşi cheie. Efectuând operaţia XOR între cele două texte cifrate, ea este capabilă să obţină

combinaţia XOR dintre textele în clar. Această secvenţă de biţi poate fi atacată în diferite

moduri pentru a descoperi textele în clar. Cu mai multă muncă, şirul cheie pentru acel IV poate

fi obţinut de asemenea. Trudy poate continua să lucreze în acest mod pentru a realiza un

dicţionar de şiruri cheie pentru diferite IV. Odată spart un IV, toate pachetele trimise cu acesta

în viitor (dar şi în trecut) pot fi complet decriptate.

Mai mult, deoarece IV-urile sunt folosite aleator, odată ce Trudy a determinat o pereche (IV,

şircheie) validă, ea o poate folosi pentru a genera toate pachetele pe care le doreşte şi astfel,

să intervină activ în comunicaţie. Teoretic, un receptor ar putea observa că dintr-o dată un

număr mare de pachete au toate acelaşi IV, dar (1) WEP permite acest lucru şi (2) oricum

nimeni nu verifică acest lucru.

În sfârşit, CRC-ul nu valorează prea mult, deoarece este posibil ca Trudy să modifice

încărcătura utilă şi apoi să facă schimbările corespunzătoare în CRC, fără a trebui măcar să

elimine criptarea.

În august 2001 a fost publicat un atac devastator asupra WEP (Fluhrer, 2001). Acesta a găsit


51

slăbiciuni criptografice chiar în RC4. Fluhrer a descoperit că multe dintre chei au proprietatea că

este posibilă deducerea câtorva dintre biţii cheii din şirul-cheie. Dacă acest atac este pus în

aplicare repetat, este posibilă deducerea întregii chei cu un efort modest.

8. Protocoale de autentificare

Autentificarea (authentication) este tehnica prin care un proces verifică dacă partenerul său de

comunicaţie este cel presupus a fi şi nu un impostor. Verificarea identităţii unui proces de la

distanţă, în cazul unui intrus activ şi răuvoitor, este surprinzător de dificilă şi necesită protocoale

complexe bazate pe criptografie. În această secţiune, vor fi studiate câteva dintre numeroasele

protocoale de autentificare folosite în reţelele nesigure de calculatoare.

Autentificarea se ocupă cu problema de a şti dacă într-adevăr comunici cu un anumit proces.

Autorizarea se ocupă cu ceea ce îi este permis unui proces să facă. De exemplu, un proces

client contactează un server de fişiere şi spune: „Eu sunt procesul lui Scott şi vreau să şterg

fişierul cookbook.old”. Din punctul de vedere al serverului de fişiere, trebuie găsite răspunsurile

la două întrebări:

1. Chiar este procesul lui Scott? (autentificare)

2. Are Scott permisiunea de a şterge cookbook.old? (autorizare)

Doar după ce s-a răspuns afirmativ, fără ambiguităţi, la ambele întrebări poate avea loc

acţiunea cerută. De fapt prima dintre cele două este cu adevărat întrebarea cheie. Odată ce

serverul de fişiere ştie cu cine vorbeşte, verificarea autorizării este doar o problemă de căutare

în intrările tabelelor şi bazelor de date locale. Din acest motiv, în această secţiune se va

concentra asupra autentificării. Modelul general pe care îl folosesc toate protocoalele de

autentificare este următorul. Alice începe prin a trimite un mesaj fie lui Bob, fie unui centru

autorizat de distribuire a cheilor KDC (Key Distribution Center), care este presupus a fi

credibil. Urmează alte câteva schimburi de mesaje în diferite direcţii. În timp ce aceste mesaje

sunt transmise, Trudy, le poate intercepta, modifica sau retrimite în scopul de a-i înşela pe Alice

şi Bob sau doar pentru a încurca lucrurile. Cu toate acestea, la încheierea protocolului de

comunicare, Alice este sigură că a vorbit cu Bob, iar acesta este sigur că a vorbit cu Alice. Mai

mult decât atât, în cele mai multe protocoale, cei doi vor fi stabilit şi o cheie secretă de sesiune,

pentru folosirea în conversaţiile viitoare. În practică, din motive de performanţă, tot traficul de

date este criptat folosind criptografia cu cheie secretă (de obicei AES sau DES triplu), în timp ce

criptografia cu cheie publică este larg folosită în protocoale de autentificare şi pentru stabilirea

unei chei de sesiune.

Motivul pentru utilizarea unei chei de sesiune noi, alese aleator, pentru fiecare conexiune, este


52

minimizarea mărimii traficului care este transmis cu cheile secrete sau publice ale utilizatorilor,

pentru a reduce cantitatea de text cifrat pe care intrusul o poate obţine şi pentru a reduce

pagubele care se pot produce dacă un proces eşuează, iar vidajul său de memorie (core dump) cade în mâini rele. Din fericire, singura cheie prezentă va fi cheia de sesiune. Toate

cheile permanente trebuie să fie anulate cu grijă după stabilirea sesiunii.

8.1 Autentificare bazată pe cheie secretă partajată

Pentru primul protocol de autentificare prezentat, se presupune că Alice şi Bob partajează deja

o cheie secretă, KAB. Această cheie partajată poate să fi fost stabilită anterior fie prin telefon,

fie direct, dar în nici un caz nu prin intermediul unei reţele (nesigure).

Protocolul este bazat pe un principiu ce poate fi întâlnit în multe protocoale de autentificare: o

parte trimite un număr aleatoriu celeilalte, care îl transformă apoi într-un anumit mod şi

returnează rezultatul. Astfel de protocoale se numesc protocoale provocare-răspuns

(challenge-response). În acest protocol şi în cele ce urmează va fi folosită următoarea notaţie:

A, B reprezintă identităţile lui Alice şi Bob.

Ri reprezintă provocările, unde indicele identifică pe cel ce trimite provocarea.

Ki sunt cheile, unde i indică proprietarul.

KS este cheia de sesiune.

Secvenţa de mesaje pentru primul nostru protocol de autentificare cu cheie partajată este

ilustrată în Figura 12-24. În mesajul 1 Alice îi trimite lui Bob identitatea sa, A, într-un mod pe

care Bob îl înţelege. Bineînţeles că Bob nu are posibilitatea de a şti dacă acest mesaj vine de la

Alice sau de la Trudy, astfel încât el alege o provocare, un număr aleator mare, RB, şi îl trimite

înapoi spre „Alice” sub forma mesajului 2, ca text clar. Alice criptează atunci mesajul cu cheia

pe care ea o partajează cu Bob şi trimite textul cifrat KAB(RB) înapoi, ca mesajul 3. Când Bob

vede acest mesaj el ştie imediat că vine de la Alice, deoarece Trudy nu cunoaşte KAB şi astfel

nu putea să genereze mesajul respectiv. Mai mult decât atât, deoarece RB a fost ales aleator

dintr-un spaţiu mare (să spunem, de exemplu, numere aleatoare pe 128 de biţi), este destul de

puţin probabil ca Trudy să fi văzut RB şi răspunsul asociat lui într-o sesiune anterioară. Este la

fel de puţin probabil ca ea să fi putut ghici răspunsul corect la orice provocare.

În acest moment, Bob este sigur că vorbeşte cu Alice, dar Alice nu este sigură de nimic. Din

punctul ei de vedere, s-ar putea ca Trudy să fi interceptat mesajul 1 şi să fi trimis înapoi replica

RB. Poate că Bob a murit azi-noapte. Pentru a descoperi cu cine vorbeşte, Alice alege un

număr aleator RA şi îl trimite lui Bob ca text clar, în mesajul 4. Când Bob răspunde cu KAB(RA),

Alice ştie că vorbeşte cu Bob. Dacă ei vor să stabilească acum o cheie de sesiune, Alice poate


53

alege una, KS, şi o poate trimite lui Bob criptată cu KAB.

Figura 12-24 –Autentificare în doi paşi folosind un protocol de tipul provocare-răspuns.

Protocolul din Figura 12-24 conţine cinci mesaje. Trebuie încercat să se elimine o parte din ele.

O variantă este ilustrată în Figura 12-25. Aici Alice iniţiază protocolul provocare-răspuns, în loc

de a-l aştepta pe Bob să o facă. Similar, în timp ce răspunde la provocarea lui Alice, Bob o

trimite pe a sa. Întregul protocol poate fi redus la trei mesaje în loc de cinci.

Figura 12-25 –Un protocol mai scurt de autentificare în doi paşi.

Este acest nou protocol o îmbunătăţire a celui original? Într-un anumit sens da: este mai scurt.

Din nefericire, este şi greşit. În anumite situaţii, Trudy poate învinge acest protocol folosind ceea

ce se numeşte atacul prin reflexie. În particular, Trudy îl poate sparge dacă este posibil să

deschidă sesiuni multiple cu Bob simultan. Această situaţie ar fi adevărată, de exemplu, dacă

Bob este o bancă şi este pregătit să accepte simultan mai multe conexiuni cu maşini de

efectuat plăţi.

Atacul prin reflexie al lui Trudy este prezentat în Figura 12-26. Pentru început, Trudy pretinde că

este Alice şi trimite RT. Bob răspunde, ca de obicei, cu propria sa provocare, RB. Acum Trudy

este în impas. Ce poate să facă? Nu cunoaşte KAB(RB).


54

Ea poate deschide o a doua sesiune cu mesajul 3, furnizând RB luat din mesajul 2 ca

provocare a ei. Bob îl criptează calm şi trimite înapoi KAB(RB) în mesajul 4. Am colorat

mesajele din sesiunea a doua pentru a le evidenţia. Acum Trudy are informaţia care îi lipsea,

aşa că poate să finalizeze prima sesiune şi să o abandoneze pe cea de-a doua. Bob este acum

convins că Trudy este Alice, aşa că atunci când ea întreabă de balanţa contului său bancar, el i-

o dă fără nici o problemă. Apoi când ea îi cere să transfere toţi banii la o bancă secretă din

Elveţia, el face asta fără nici un moment de ezitare.

Următoarele patru reguli generale sunt adeseori utile:

1.Iniţiatorul să dovedească cine este înaintea celui care răspunde. În acest caz, Bob

transmite informaţii importante înainte ca Trudy să-i fi dat vreo dovadă că este cine

pretinde a fi.

2.Iniţiatorul şi cel ce răspunde să folosească chei diferite pentru dovadă, chiar dacă

aceasta presupune existenţa a două chei partajate KAB şi K’AB.

3.Iniţiatorul şi cel ce răspunde să-şi extragă provocările din mulţimi diferite. De exemplu,

iniţiatorul trebuie să folosească numere pare, iar cel ce răspunde să folosească numere

impare.

4.Protocolul să fie rezistent la atacuri ce implică o a doua sesiune paralelă, în care

informaţia obţinută într-o sesiune este folosită într-o alta.

Figura 12-26 – Atacul prin reflexie.

Dacă fie şi una singură din aceste patru reguli este nerespectată, deseori protocolul poate fi

spart. În acest caz, patru reguli au fost încălcate cu consecinţe dezastroase.

Acum să se discute protocolul din Figura 12-24. Sigur acel protocol nu poate fi ţinta unui atac

prin reflexie? Depinde. Este destul de subtil. Trudy a reuşit să învingă protocolul nostru folosind


55

un atac prin reflexie pentru că a fost posibil să deschidă o a doua sesiune cu Bob şi să îl

păcălească, făcându-l să răspundă la propriile întrebări. Ce s-ar întâmpla dacă Alice ar fi un

calculator de uz general care ar accepta şi el sesiuni multiple, şi nu o persoană în faţa unui

calculator?

Pentru a vedea cum funcţionează atacul lui Trudy, a se vedea Figura 12-27. Alice începe prin a-

şi anunţa identitatea în mesajul 1. Trudy interceptează acest mesaj şi îşi începe propria sesiune

cu mesajul 2, pretinzând că este Bob. Am colorat din nou mesajele din sesiunea a doua. Alice

răspunde la mesajul 2 spunând: Pretinzi că eşti Bob? Demonstrează. în mesajul 3. În acest

moment Trudy e în impas pentru că nu poate demonstra că este Bob.

Ce face Trudy acum? Se întoarce la prima sesiune, în care e rândul ei să trimită o provocare,

şi trimite RA pe care a primit-o în mesajul 3. Alice îi răspunde politicos în mesajul 5, furnizându-i

lui Trudy informaţia de care are nevoie pentru a trimite mesajul 6 din sesiunea 2. În acest

moment Trudy este practic liberă pentru că a răspuns cu succes la provocarea lui Alice în

sesiunea 2. Acum poate să abandoneze sesiunea 1, să trimită un număr oarecare pentru restul

sesiunii 2 şi va avea o sesiune autentificată cu Alice în sesiunea 2.

Figura 12-27 – Atac prin reflexie asupra protocolului din Figura 12-24.

În loc să trimită un număr oarecare pentru a completa sesiunea 2, Trudy aşteaptă ca Alice să

trimită mesajul 7, provocarea lui Alice pentru sesiunea 1. Bineînţeles, Trudy nu ştie cum să

răspundă, aşa că foloseşte din nou atacul prin reflexie, trimiţând RA2 ca mesajul 8. Alice

criptează RA2 în mesajul 9. Acum Trudy se întoarce la sesiunea 1 şi îi trimite lui Alice numărul


56

dorit în mesajul 10, copiat din ceea ce trimisese Alice în mesajul 9. Acum Trudy are două

sesiuni complet autentificate cu Alice.

De această dată, Trudy are două sesiuni autentificate cu Alice. În exemplul anterior, ea avea o

singură sesiune autentificată cu Bob. Şi aici, dacă am fi aplicat toate regulile generale pentru

protocoale de autentificare discutate mai sus, acest atac ar fi putut fi oprit. Ei arată şi cum este

posibilă construirea sistematică de protocoale pentru care să se poată demonstra că sunt

corecte. Cel mai simplu protocol de acest fel este totuşi cam complicat, aşa că acum se

prezintă o altă clasă de protocoale care funcţionează de asemenea corect.

Noul protocol de autentificare este reprezentat în Figura 12-28. Acesta foloseşte un HMAC de

tipul pe care l-am văzut când am studiat IPsec. Alice începe prin a-i trimite lui Bob un număr ad-

hoc, RA, ca mesajul 1. Bob răspunde alegând propriul număr ad-hoc, RB, şi trimiţându-l înapoi

împreună cu un HMAC. HMAC-ul este format prin construirea unei structuri de date alcătuită din

numărul ad-hoc al lui Alice, numărul ad-hoc al lui Bob, identităţile lor şi cheia secretă partajată,

KAB. Această structură de date este codificată prin dispersie în HMAC, de exemplu folosind

SHA-1. Când Alice primeşte mesajul 2, ea are RA (pe care a ales-o ea însăşi), RB, care ajunge

ca text clar, cele două identităţi, şi cheia secretă, KAB, pe care a ştiut-o tot timpul, aşa că poate

să calculeze singură HMAC-ul. Dacă acesta coincide cu cel din mesaj, ea ştie că vorbeşte cu

Bob deoarece Trudy nu cunoaşte KAB, deci nu-şi poate da seama ce HMAC să trimită. Alice îi

răspunde lui Bob cu un HMAC ce conţine doar cele două numere ad-hoc.

Figura 12-28 – Autentificarea folosind HMAC.

Poate Trudy să spargă în vreun fel acest protocol? Nu, pentru că nu poate forţa nici una din

părţi să cripteze sau să rezume o valoare aleasă de ea, cum se întâmpla în Figura 12-26 şi în

Figura 12-27. Ambele HMAC-uri includ valori alese de partea care le trimite, ceea ce Trudy nu

poate controla.

Utilizarea HMAC-urilor nu este singurul mod de a folosi această idee. O schemă alternativă

deseori utilizată în locul calculării HMAC pentru o serie de elemente este criptarea acestor

elemente secvenţial, folosind înlănţuirea blocurilor cifrate.


57

8.2 Stabilirea unei chei secrete: schimbul de chei Diffie-Hellman

Până acum am presupus că Bob şi Alice partajează o cheie secretă. Se presupune că nu este

aşa (pentru că deocamdată nu există o PKI universal acceptată pentru semnarea şi distribuirea

certificatelor). Cum pot ei să stabilească una? O modalitate ar fi ca Alice să-l sune pe Bob şi să-

i dea cheia ei prin telefon, dar el probabil va începe întrebând: Cum ştiu eu că eşti Alice şi nu

Trudy? Ei ar putea încerca să aranjeze o întâlnire la care fiecare din ei să aducă un paşaport,

un permis de conducere şi trei cărţi de credit semnificative, dar fiind oameni ocupaţi, e posibil să

nu poată găsi, vreme de luni de zile, o dată acceptabilă pentru amândoi. Din fericire, oricât de

incredibil ar părea, există un mod ca cei ce sunt total străini să stabilească, chiar la lumina zilei,

o cheie secretă partajată, cu Trudy înregistrând grijulie fiecare mesaj.

Protocolul care permite străinilor să stabilească o cheie secretă partajată se numeşte

interschimbul de chei Diffie-Hellman (Diffie şi Hellman, 1976) şi funcţionează după cum

urmează. Alice şi Bob trebuie să se pună de acord asupra a două numere mari, n şi g, unde n

este prim, (n-1)/2 este de asemenea prim şi g îndeplineşte anumite condiţii. Aceste numere pot

fi publice, astfel că oricare din ei poate pur şi simplu să aleagă n şi g şi să o spună celuilalt, în

mod deschis. Acum Alice alege un număr mare (se spune pe 512 biţi), x, şi îl păstrează secret.

Similar, Bob alege un număr mare, secret, y.

Alice iniţiază protocolul de schimb al cheii trimiţându-i lui Bob un mesaj ce conţine (n, g, gx mod

n), după cum se arată în Figura 12-29. Bob răspunde trimiţându-i lui Alice un mesaj ce conţine

gy mod n. Acum Alice are numărul pe care i l-a trimis Bob şi îl ridică la puterea x modulo n

pentru a obţine (gy mod n)x mod n. Bob efectuează o operaţie similară pentru a obţine (gx mod

n)y mod n. Conform legilor aritmeticii modulare, ambele calcule duc la gxy mod n. Iată cum

Alice şi Bob partajează acum o cheie secretă gxy mod n.

Figura 12-29 – Schimbul de cheie Diffie-Hellman.

Este evident că Trudy vede ambele mesaje. Ea cunoaşte pe g şi pe n din mesajul 1. Dacă ea ar


58

putea calcula x şi y ar putea să descopere cheia secretă. Necazul este că, dat fiind doar gx mod

n, ea nu poate afla pe x. Nu este cunoscut nici un algoritm practic pentru calculul logaritmilor

discreţi modulo un număr prim foarte mare.

Pentru a face exemplul anterior mai concret, se va folosi (complet nerealist) valorile n = 47 şi g

= 3. Alice alege x = 8 şi Bob alege y = 10. Ambele chei sunt păstrate secrete. Mesajul lui Alice

către Bob este (47, 3, 28) deoarece 38 mod 47 este 28. Mesajul lui Bob către Alice este (17).

Alice calculează 178 mod 47, care este 4. Bob calculează 2810 mod 47, care este 4. Alice şi

Bob au determinat independent cheia secretă care este 4. Trudy are de rezolvat ecuaţia 3x mod

47 = 28, ceea ce poate fi făcut prin căutare exhaustivă în cazul unor numere mici ca acestea,

dar nu şi atunci când toate numerele sunt lungi de sute de biţi. Toţi algoritmii cunoscuţi la ora

actuală iau prea mult timp, chiar şi atunci când sunt rulaţi folosind un supercalculator masiv

paralel.

În ciuda eleganţei algoritmului Diffie-Hellman, există o problemă: când Bob ia tripletul (47, 3,

28), cum ştie el că este de la Alice şi nu de la Trudy? Nu există nici o modalitate pentru

aceasta. Din nefericire Trudy poate exploata acest fapt pentru a-i înşela atât pe Alice cât şi pe

Bob, după cum este ilustrat în Figura 12-30. Aici, când Alice şi Bob îl aleg pe x, respectiv pe y,

Trudy alege propriul său număr aleator, z. Alice trimite mesajul 1, destinat lui Bob. Trudy îl

interceptează şi trimite mesajul 2 lui Bob, folosind g şi n corecţi (care sunt disponibili public), dar

cu al său z în loc de x. De asemenea ea trimite mesajul 3 lui Alice. Mai târziu Bob îi trimite lui

Alice mesajul 4, pe care Trudy îl interceptează din nou şi îl păstrează.

Figura 12-30 – Atacul de tip găleata brigăzii sau omul-din-mijloc.

Acum fiecare efectuează aritmetica modulară. Alice calculează cheia secretă ca fiind gxz mod n

şi la fel face şi Trudy (pentru mesajele lui Alice). Bob calculează gyz mod n şi la fel face şi

Trudy (pentru mesajele lui Bob). Alice crede că vorbeşte cu Bob, aşa că ea stabileşte o sesiune

de cheie (cu Trudy). La fel face şi Bob. Fiecare mesaj pe care Alice îl trimite în sesiunea criptată


59

este capturat de Trudy, memorat, modificat la dorinţă şi apoi (opţional) transmis lui Bob. Similar

în cealaltă direcţie. Trudy vede orice şi poate modifica toate mesajele la dorinţă, în timp ce atât

Alice cât şi Bob trăiesc cu iluzia că au un canal de comunicaţie sigur de la unul la celălalt. Acest

atac este cunoscut sub numele de atacul găleata brigăzii de pompieri (bucket brigade attack),

deoarece el seamănă vag cu un departament de pompieri de pe vremuri trecând din mână în

mână găleţile de-a lungul drumului de la maşina de pompieri la foc. El se mai numeşte şi atacul

omul-din-mijloc (man-in-themiddle attack).

8.3 Autentificarea folosind un Centru de Distribuţia Cheilor

Stabilirea unui secret partajat cu un străin a mers destul de bine, dar nu în întregime. Pe de altă

parte, probabil că nici nu merită să fie făcut (atacul strugurilor acri). Pentru a vorbi cu n oameni

în acest mod ar fi necesare n chei. Pentru persoanele foarte cunoscute, gestiunea cheilor ar

deveni o adevărată pacoste, în special dacă fiecare cheie trebuie stocată separat pe câte o

cartelă de plastic.

O abordare diferită o reprezintă introducerea unui centru autorizat de distribuţie a cheilor (KDC

Key Distribution Center). În acest model, fiecare utilizator are o singură cheie partajată cu

KDC. Autentificarea şi gestiunea cheilor de sesiune merg acum prin intermediul KDC. Cel mai

simplu protocol cunoscut pentru autentificarea KDC, implicând două părţi şi un centru autorizat,

este ilustrat în Figura 12-31.

Ideea din spatele protocolului este simplă: Alice alege o cheie de sesiune , KS, şi anunţă KDC

că vrea să vorbească cu Bob folosind KS. Acest mesaj este criptat cu cheia secretă pe care

Alice o împarte (numai) cu KDC, KA. KDC decriptează acest mesaj, extrage identitatea lui Bob

şi cheia de sesiune. Apoi el construieşte un nou mesaj ce conţine identitatea lui Alice şi cheia

de sesiune şi trimite acest mesaj lui Bob. Criptarea este făcută cu KB, cheia secretă pe care

Bob o împarte cu KDC. Când Bob decriptează mesajul, el află că Alice vrea să vorbească cu el

şi cheia pe care aceasta vrea să o utilizeze.

Figura 12-31 – O primă încercare de protocol de autentificare folosind un KDC .

Autentificarea are loc gratuit. KDC ştie că mesajul 1 trebuie să fi venit de la Alice, deoarece


60

nimeni altcineva nu poate să-l cripteze cu cheia secretă a Alicei. Similar, Bob ştie sigur că

mesajul 2 vine de la KDC, în care el are încredere, deoarece nimeni altcineva nu mai cunoaşte

cheia lui secretă.

Din nefericire, acest protocol prezintă un defect grav. Trudy are nevoie de ceva bani, aşa că ea

imaginează un serviciu pe care îl poate executa pentru Alice, face o ofertă atractivă şi obţine

postul. După ce îşi face treaba, Trudy cere politicos lui Alice să-i plătească transferându-i banii

prin bancă. Aşa că Alice stabileşte o cheie de sesiune cu bancherul ei, Bob. Apoi ea îi trimite lui

Bob un mesaj prin care cere ca banii respectivi să fie transferaţi în contul lui Trudy.

Între timp, Trudy se întoarce la vechile ei obiceiuri, furturile prin reţea. Ea copiază atât mesajul 2

din Figura 12-31, cât şi cererea de transferare a banilor care îl urmează. Mai târziu ea le trimite

lui Bob. Bob le ia şi gândeşte: „Alice probabil că a angajat-o din nou pe Trudy. Cu siguranţă că

ea lucrează bine.” Bob transferă din nou o cantitate de bani egală cu prima din contul lui Alice în

al lui Trudy. La câtva timp după cea de-a 50-a pereche de mesaje pe care o primeşte, Bob

aleargă afară din biroul său pentru a o găsi pe Trudy şi a-i oferi un împrumut mare astfel ca ea

să-şi poată extinde afacerea ce se dovedeşte a fi atât de plină de succes. Problema se

numeşte atacul prin reluare.

Sunt câteva soluţii posibile la atacul prin reluare. Prima este de a include în fiecare mesaj o

amprentă de timp. Astfel, dacă cineva primeşte un mesaj expirat, îl ignoră. Necazul cu această

abordare este că într-o reţea ceasurile nu sunt niciodată perfect sincronizate, astfel încât va

exista un întreg interval de timp în care o amprentă de timp este validă. Trudy poate retrimite

mesajul în acest interval de timp fără să fie prinsă.

Cea de-a doua soluţie este să se pună, în fiecare mesaj, un număr ad-hoc. Fiecare parte

trebuie să-şi rememoreze toate numerele ad-hoc folosite anterior şi să respingă orice mesaj ce

conţine un număr ad-hoc folosit deja. Dar numerele ad-hoc trebuie rememorate la nesfârşit,

chiar şi atunci când Trudy încearcă să retrimită un mesaj vechi de 5 ani. De asemenea, dacă o

maşină cade şi îşi pierde lista de numere ad-hoc, ea va fi din nou vulnerabilă la un atac prin

reluare. Amprentele de timp şi numerele ad-hoc pot fi combinate pentru a limita timpul în care

acestea din urmă nu trebuie şterse, dar este evident că protocolul devine mult mai complicat.

O abordare şi mai sofisticată a autentificării este folosirea unui protocol provocare-răspuns

multicăi. Un exemplu binecunoscut de astfel de protocol este protocolul de autentificare

NeedhamSchroeder (Needham şi Schroeder, 1978). O variantă a acestuia este prezentată în

Figura 12-32.

În acest protocol, Alice începe prin a anunţa KDC că ea doreşte să vorbească cu Bob. Acest

mesaj conţine un număr aleator mare, RA, pe post de număr ad-hoc. KDC trimite înapoi

mesajul 2 conţinând numărul aleator al lui Alice împreună cu un tichet pe care ea îl poate trimite

lui Bob. Scopul numărului aleator este acela de a o asigura pe Alice că mesajul 2 este proaspăt


61

şi nu unul reluat. Identitatea lui Bob este de asemenea inclusă pentru cazul în care lui Trudy îi

vine amuzanta idee să înlocuiască B-ul din mesajul 1 cu propria sa identitate, astfel încât KDC

să cripteze tichetul de la sfârşitul mesajului 2 cu KT în loc de KB. Tichetul criptat cu KB este

inclus în interiorul mesajului criptat, pentru a o împiedica pe Trudy să-l înlocuiască cu altceva pe

drumul lui înapoi spre Alice.

Figura 12-32 – Protocolul de autentificare Needham-Schroeder.

Acum Alice îi trimite tichetul lui Bob, împreună cu un nou număr aleator, RA2, criptat cu cheia

de sesiune, KS. În mesajul 4, Bob trimite înapoi KS(RA2 -1) pentru a-i dovedi lui Alice că

vorbeşte cu adevăratul Bob. Trimiterea înapoi a lui KS(RA2) nu ar fi mers, deoarece ar fi fost

posibil ca Trudy tocmai să-l fi furat din mesajul 3.

După primirea mesajului 4, Alice este convinsă că vorbeşte cu Bob şi că până în acest moment

nu s-au folosit mesaje reluate. Doar ea tocmai generase RA2 cu câteva milisecunde înainte.

Scopul mesajului 5 este de a-l convinge pe Bob că cea cu care vorbeşte este chiar Alice şi că

nu s-au folosit nici aici mesaje reluate. Posibilitatea oricărui tip de atac prin replicare este

eliminată, deoarece fiecare parte nu numai că generează o provocare, dar şi răspunde la una.

Cu toate că protocolul pare a fi destul de solid, el are o mică scăpare. Dacă Trudy reuşeşte să

obţină o cheie de sesiune veche în text clar, ea poate să iniţieze o nouă sesiune cu Bob reluând

mesajul 3 corespunzător cheii compromise şi convingându-l pe acesta că ea este Alice. De

această dată ea poate prăda contul din bancă al lui Alice fără să trebuiască să se legitimeze

nici măcar o dată.

Needham şi Schroeder au publicat mai târziu un protocol care corectează această problemă

(Needham şi Schroeder, 1987). În acelaşi număr al aceluiaşi jurnal, Otway şi Rees (1987) au

publicat de asemenea un protocol care rezolvă problema pe o cale mai scurtă. Figura 12-33

ilustrează un protocol Otway-Rees uşor modificat.

În protocolul Otway-Rees, Alice începe prin a genera o pereche de numere aleatoare, R, care

va fi utilizată ca identificator comun, şi RA, pe care Alice îl va folosi pentru a-l provoca pe Bob.


62

Când Bob preia acest mesaj, el construieşte un mesaj nou din partea criptată a mesajului lui

Alice şi unul analog din partea sa. Ambele părţi criptate cu KA şi KB, identificând pe Alice şi pe

Bob, conţin identificatorul comun şi o provocare.

Figura 12-33 – Protocolul de autentificare Otway-Rees (puţin simplificat).

KDC verifică dacă R din ambele părţi este acelaşi. S-ar putea să nu fie, deoarece Trudy a

intervenit cu R în mesajul 1 sau a înlocuit partea din mesajul 2. Dacă cele două RS se

potrivesc, KDC crede că mesajul de cerere de la Bob este valid. El generează atunci o cheie de

sesiune şi o criptează de două ori, o dată pentru Alice şi o dată pentru Bob. Fiecare mesaj

conţine numărul aleator al receptorului, ca dovadă că mesajul a fost generat de KDC şi nu de

Trudy. În acest moment atât Alice cât şi Bob sunt în posesia aceleiaşi chei de sesiune şi pot

începe comunicarea. Prima dată când ei vor schimba mesaje de date, fiecare va putea vedea

că celălalt are o copie identică a lui KS, astfel autentificarea fiind completă.

8.4 Autentificarea folosind Kerberos

Un protocol de autentificare folosit în multe sisteme reale este Kerberos, care se bazează pe o

variantă a protocolului Needham-Schroeder. Numele său vine de la un câine cu mai multe

capete din mitologia greacă, ce era folosit pentru a păzi intrarea în Hades (probabil pentru a-i

ţine pe cei nedoriţi afară). Kerberos a fost proiectat la M.I.T. pentru a permite utilizatorilor de la

staţiile de lucru să acceseze resursele reţelei într-un mod sigur. Cea mai mare diferenţă dintre

el şi Needham-Schroeder este presupunerea lui că toate ceasurile sunt destul de bine

sincronizate. Protocolul a trecut prin câteva iteraţii. V4 este versiunea cea mai larg utilizată în

industrie. Kerberos implică trei servere în afară de Alice (staţia de lucru a clientului):

• Serverul de autentificare (AS – Authentication Server): verifică utilizatorii în timpul

conectării.

• Serverul de acordare a Tichetelor (TGS – Ticket-Granting Server): emite

„demonstrarea identităţii tichetelor”.

• Serverul Bob: realizează efectiv acţiunea pe care o doreşte Alice.


63

AS este similar unui KDC prin aceea că el partajează o parolă secretă cu orice utilizator.

Sarcina TGS este de a emite tichete care pot convinge serverele reale că acela care deţine un

tichet TGS este într-adevăr cel ce pretinde a fi.

Pentru a porni o sesiune, Alice stă aşezată la o staţie de lucru publică oarecare şi-şi tastează

numele. Staţia de lucru transmite numele ei la AS ca text clar, după cum este arătat în Figura

12-34. Ceea ce vine înapoi este o cheie de sesiune împreună cu un tichet KTGS(A, KS),

destinate TGS-ului. Aceste elemente sunt împachetate împreună şi criptate folosind cheia

secretă a lui Alice, astfel încât doar Alice să le poată decripta. Doar când soseşte mesajul 2,

staţia de lucru îi va cere lui Alice parola. Parola este folosită pentru a genera KA, în scopul

decriptării mesajului 2 şi obţinerii cheii de sesiune şi tichetului TGS din interiorul acestui mesaj.

În acest moment, staţia de lucru înlocuieşte parola lui Alice pentru a se asigura că ea se

găseşte în interiorul staţiei de lucru pentru cel mult câteva milisecunde. Dacă Trudy încearcă să

se conecteze ca Alice, parola pe care o introduce va fi greşită şi staţia de lucru va detecta acest

lucru deoarece partea standard a mesajului 2 va fi incorectă.

După conectare Alice trebuie să anunţe staţia de lucru că doreşte să-l contacteze pe Bob,

serverul de fişiere. Atunci staţia de lucru trimite spre TGS mesajul 3 cerând un tichet pentru a-l

folosi cu Bob. Elementul cheie în această cerere este KTGS(A, KS), care este criptat cu cheia

secretă a TGS şi este folosit ca dovadă că transmiţătorul este chiar Alice. TGS răspunde prin

crearea unei chei de sesiune KAB, pe care Alice să o folosească cu Bob. Se trimit înapoi două

versiuni ale acesteia. Prima este criptată doar cu KS, astfel încât Alice să poată să o citească. A

doua este criptată cu cheia lui Bob, KB, astfel încât Bob să o poată citi.

Figura 12-34 – Modul de operare la Kerberos V4.

Trudy poate copia mesajul 3 şi poate încerca să-l utilizeze din nou, dar ea va fi împiedicată de

amprenta de timp criptată, t, trimisă împreună cu el. Trudy nu poate înlocui amprenta de timp cu

una mai recentă, deoarece ea nu cunoaşte KS, cheia de sesiune pe care o foloseşte Alice


64

pentru a vorbi cu TGS. Chiar dacă Trudy retrimite mesajul 3 repede, tot ceea ce va obţine este

o altă copie a mesajului 4, pe care nu a putut să-l decripteze prima dată şi nu va putea nici a

doua oară.

Acum Alice îi poate trimite lui Bob KAB pentru a stabili o sesiune cu el. Acest schimb este de

asemenea cu amprente de timp. Răspunsul este pentru Alice dovada că ea vorbeşte chiar cu

Bob, nu cu Trudy.

După această serie de schimburi, Alice poate comunica cu Bob sub acoperirea cheii KAB. Dacă

mai târziu se decide că are nevoie să comunice cu alt server, Carol, ea va repeta doar mesajul

3 spre TGS, specificând de această dată C în loc de B. TGS va răspunde cu promptitudine cu

un tichet criptat cu KC, pe care Alice îl poate transmite lui Carol şi pe care Carol îl va accepta

ca dovadă că el vine de la Alice.

Scopul întregii acţiuni este că acum Alice poate accesa serverele din toată reţeaua într-un mod

sigur şi că parola sa nu va fi niciodată transmisă prin reţea. De fapt parola trebuie să existe pe

staţia de lucru doar pentru câteva milisecunde. Cu toate acestea, trebuie remarcat că fiecare

server face propria sa autorizare. Atunci când Alice îi prezintă tichetul său lui Bob, acest tichet

doar îi demonstrează lui Bob cine l-a trimis. Ceea ce îi este permis lui Alice să facă, depinde

doar de Bob.

Deoarece proiectanţii Kerberos-ului nu s-au aşteptat ca întreaga lume să aibă încredere într-un

singur server de autentificare, ei au prevăzut posibilitatea de a avea domenii multiple, fiecare cu

propriul său AS şi TGS. Pentru a obţine un tichet de la un server dintr-un domeniu de la

distanţă, Alice ar trebui să ceară propriului său TGS un tichet acceptat de TGS-ul din domeniul

de la distanţă. Dacă TGS-ul de la distanţă este înregistrat la TGS-ul local (în acelaşi mod în

care sunt serverele locale), TGS-ul local îi va da lui Alice un tichet valid pentru TGS-ul de la

distanţă. Astfel ea poate să lucreze acolo, de exemplu să ia tichete pentru serverele din acest

domeniu. De notat totuşi că, pentru ca părţi din două domenii diferite să conlucreze, fiecare

trebuie să se încreadă în TGS-ul celuilalt.

Kerberos V5 este mai sofisticat decât V4 şi are o supraîncărcare mai mare. Pentru a descrie

tipurile de date el foloseşte OSI ASN.1 (Abstract Syntax Notation 1) şi prezintă mici modificări

în protocoale. Mai mult decât atât, are timpi de viaţă mai mari pentru tichete, permite reînnoirea

tichetelor şi va elibera tichete postdatate. În plus, cel puţin în teorie, nu este dependent de DES,

cum este V4, şi suportă domenii multiple delegând servere de tichete multiple pentru generarea

de tichete.

8.5 Autentificarea folosind criptografia cu cheie publică

Autentificarea mutuală poate fi realizată şi cu ajutorul criptografiei cu cheie publică. Pentru


65

început, Alice are nevoie de cheia publică a lui Bob. Dacă există o PKI cu un server de

directoare care emite certificate pentru chei publice, Alice o poate cere pe a lui Bob, după cum

se vede din Figura 12-35, ca mesajul 1. Răspunsul, în mesajul 2, este un certificat X.509

conţinând cheia publică a lui Bob. Când Alice verifică faptul că semnătura e corectă, îi trimite lui

Bob un mesaj conţinând identitatea ei şi un număr ad-hoc.

Când Bob primeşte acest mesaj, nu are idee dacă a venit de la Alice sau de la Trudy, dar

continuă şi cere serverului de directoare cheia publică a lui Alice (mesajul 4), pe care o obţine

imediat (mesajul 5). Apoi îi trimite lui Alice un mesaj conţinând RA a lui Alice, propriul număr ad-

hoc, RB, şi o cheie de sesiune propusă, KS, ca mesajul 6.

Când Alice primeşte mesajul 6, ea îl decriptează folosind propria cheie privată. Ea vede RA în

mesaj, ceea ce îi dă o senzaţie plăcută. Mesajul trebuie să fi venit de la Bob, pentru că Trudy

nu are nici un mijloc de a determina RA. Mai mult, trebuie să fie un mesaj proaspăt, şi nu unul

reluat, din moment ce ea tocmai i-a trimis RA lui Bob. Alice acceptă cheia de sesiune trimiţând

înapoi mesajul 7. Când Bob vede RB criptat cu cheia de sesiune pe care a generat-o el, ştie că

Alice a primit mesajul 6 şi a verificat RA.

Figura 12-35 – Autentificarea mutuală folosind criptografia cu cheie publică.

Cum poate încerca Trudy să compromită acest protocol? Ea poate fabrica mesajul 3 şi-l poate

păcăli pe Bob să o testeze pe Alice, dar Alice va vedea un RA pe care nu l-a trimis ea şi nu va

merge niciodată mai departe. Trudy nu poate falsifica mesajul 7 pentru Bob, deoarece nu ştie

RB sau KS şi nu le poate determina fără cheia privată a lui Alice. De data aceasta ea nu are

noroc.


66

9. Confidenţialitatea poștei electronice

Când un mesaj de poştă electronică este trimis între două locaţii situate la distanţă, acesta va

trece în drumul său pe la un număr mare de maşini. Oricare dintre acestea poate să citească şi

să înregistreze mesajul pentru utilizare ulterioară. În secţiunile următoare se va studia un sistem

de e-mail sigur larg utilizat, PGP, şi apoi se vor menţiona pe scurt altele două, PEM şi S/MIME.

9.1 PGP-Pretty Good Privacy (Confidenţialitate Destul de Bună)

PGP (Pretty Good Privacy) este în cea mai mare parte rodul gândirii unei singure persoane,

Phil Zimmermann. Lansat în 1991, PGP este un pachet complet de securitate a e-mail-ului,

care oferă confidenţialitate, autentificare, semnături digitale şi compresie, toate într-o formă uşor

de utilizat. Pe deasupra, pachetul complet, incluzând tot codul sursă, este distribuit gratuit prin

Internet. Datorită calităţii sale, preţului (zero) şi disponibilităţii pe platformele UNIX, Linux,

Windows şi Mac OS, acesta este larg utilizat astăzi.

PGP criptează datele folosind un cifru bloc numit IDEA (International Data Encryption Algorithm – Algoritm Internaţional de Criptare a Datelor), care foloseşte chei de 128 de biţi.

Acesta a fost proiectat în Elveţia într-un moment in care DES era considerat compromis şi AES

încă nu fusese inventat. Conceptual, IDEA este similar cu DES şi AES: permută biţii într-un şir

de runde, dar detaliile funcţiilor de permutare sunt diferite de DES şi AES. Gestiunea cheilor

foloseşte RSA şi integritatea datelor foloseşte MD5.

O problemă cu care s-a confruntat PGP a fost una de încălcare a patentului. Compania ce

deţine patentul RSA, RSA Security, Inc., a susţinut că folosirea de către PGP a algoritmului

RSA îi încalcă patentul, dar această problemă a fost rezolvată în versiunile începând de la 2.6.

Mai mult, PGP foloseşte şi alt algoritm de criptare patentat, IDEA, ceea ce a provocat nişte

probleme la început.

În mod intenţionat PGP utilizează algoritmi de criptare existenţi, în loc să inventeze unii noi. Se

bazează în principal pe algoritmi care au fost supuşi unor numeroase analize amănunţite şi nu

au fost proiectaţi sau influenţaţi de vreo agenţie guvernamentală care să încerce să le

micşoreze puterea. Pentru cei ce au tendinţa să nu aibă încredere în guvern, această

proprietate este un mare avantaj.

PGP permite compresia de text, asigurarea secretului mesajelor şi semnături digitale şi

furnizează de asemenea facilităţi de management extensiv al cheilor, dar, destul de ciudat, nu

şi facilităţi pentru e-mail. Este mai mult un preprocesor care preia text clar de la intrare şi

produce text semnat, cifrat, în bază 64, ca rezultat. Acest rezultat poate fi apoi trimis prin e-mail,

bineînţeles. Unele implementări ale PGP apelează, ca pas final, un agent utilizator care să


67

trimită efectiv mesajul.

Pentru a vedea cum funcţionează PGP, se consideră exemplul din Figura 12-36. Aici, Alice vrea

să-i trimită lui Bob, într-o manieră sigură, un mesaj text simplu, semnat, P. Alice şi Bob au

cheile private (DX) şi cheile RSA publice (EX). Se presupune că fiecare ştie cheia publică a

celuilalt.

Alice începe prin a invoca programul PGP pe calculatorul său. Mai întâi PGP rezumă prin

dispersare (hash) mesajul P utilizând MD5, apoi criptează codul de dispersie rezultat utilizând

cheia sa RSA privată, DA. Când, în cele din urmă, Bob primeşte mesajul, el poate decripta

rezumatul cu cheia publică cunoscută a lui Alice şi poate testa corectitudinea acestuia. Chiar

dacă altcineva (de ex. Trudy) poate obţine codul în această etapă şi îl poate decripta cu cheia

publică a lui Alice, puterea lui MD5 garantează că este nerealizabilă computaţional producerea

unui alt mesaj care să aibă acelaşi cod MD5.

Figura 12-36 – PGP în acţiunea de trimitere a unui mesaj.

Rezumatul criptat şi mesajul original sunt acum concatenate într-un singur mesaj P1 şi

comprimate apoi cu programul ZIP, care utilizează algoritmul Ziv-Lempel (Ziv şi Lempel, 1977).

Se denumește ieşirea obţinută la acest pas P1.Z.

Apoi, PGP îi cere lui Alice introducerea unui şir de caractere oarecare. Atât conţinutul acestuia

cât şi viteza de tastare sunt utilizate pentru a genera o cheie de mesaj de tip IDEA, de 128 de

biţi, KM (numită cheie de sesiune în literatura PGP, dar numele este nepotrivit atâta timp cât nu

există nici o sesiune). KM este acum utilizat pentru a cripta P1.Z cu IDEA, prin metoda de tip

reacţie cifrată. În plus, KM este criptată cu cheia publică a lui Bob, EB. Aceste două

componente sunt apoi concatenate şi convertite în bază 64, aşa cum s-a discutat în secţiunea


68

despre MIME din Cap. 7. Mesajul rezultat conţine numai litere, cifre şi simbolurile +, / şi =, ceea

ce înseamnă că poate fi pus într-un corp de RFC 822 şi că ne putem aştepta să ajungă

nemodificat la destinaţie.

Când Bob primeşte mesajul, îl reconverteşte din bază 64 şi decriptează cheia IDEA utilizând

cheia sa RSA privată. Utilizând această cheie, decriptează mesajul pentru a obţine P1.Z. După

de compresia acestuia, Bob separă textul simplu de codul cifrat şi decriptează codul de

dispersie utilizând cheia publică a lui Alice. Dacă codul textului clar coincide cu ceea ce a

calculat el utilizând MD5, el ştie că P este mesajul corect şi că provine de la Alice.

Merită observat că RSA este utilizat doar în două locuri aici: pentru a cifra codul de dispersie de

128 de biţi generat de MD5 şi pentru a cifra cheia IDEA de 128 de biţi. Deşi RSA este lent, are

de criptat doar 256 de biţi şi nu un volum mare de date. Mai mult, toţi cei 256 de biţi de text

simplu sunt generaţi extrem de aleator, astfel încât numai pentru a determina dacă o cheie

ghicită este corectă, Trudy ar trebui să depună o cantitate însemnată de muncă. Criptarea de

mare putere este realizată de IDEA, care este cu câteva ordine de mărime mai rapidă decât

RSA

PGP acceptă trei lungimi de chei RSA. Rămâne la latitudinea utilizatorului să o aleagă pe cea

mai potrivită. Lungimile disponibile sunt:

1. Obişnuită (384 biţi): poate fi spartă uşor în ziua de azi.

2. Comercială (512 biţi): ar putea fi spartă de organizaţii cu nume din trei litere (care se

ocupă

cu securitatea statului).

3. Militară (1024 biţi): Nu poate fi spartă de nici un pământean.

4. Extraterestră (2048 biţi): Nu poate fi spartă nici de cineva de pe altă planetă.

Cum RSA este folosită doar pentru două calcule uşoare, toată lumea ar trebui să folosească

mereu chei de lungime extraterestră.

Formatul unui mesaj PGP este prezentat în Figura 12-37. Mesajul are trei părţi, conţinând cheia

IDEA, semnătura şi respectiv mesajul. Partea care conţine cheia mai include, de asemenea, un

identificator de cheie, deoarece utilizatorilor li se permite să aibă mai multe chei publice.

Partea cu semnătura conţine un antet. Antetul este urmat de: o amprentă de timp,

identificatorul pentru cheia publică a emiţătorului, care poate fi folosit pentru a decripta codul

semnăturii, unele informaţii care identifică algoritmul folosit, precum şi codul de dispersie criptat.


69

Figura 12-37 – Un mesaj PGP

Partea de mesaj conţine de asemenea un antet, numele implicit care va fi folosit pentru fişier în

cazul în care utilizatorul doreşte să-l salveze pe disc, o amprentă de timp pusă la crearea

mesajului şi, în sfârşit, mesajul în sine. Administrarea cheilor a fost tratată cu atenţie foarte

mare în PGP, deoarece acesta este călcâiul lui Ahile pentru sistemele de securitate.

Administrarea cheilor funcţionează după cum urmează. Fiecare utilizator menţine două structuri

de date locale: un inel cu chei private şi unul cu chei publice. Inelul cheilor private conţine una

sau mai multe perechi de chei personale (privată-publică). Motivul pentru care se acceptă mai

multe chei pentru un utilizator este pentru a permite acestora să-şi schimbe cheile publice

periodic sau când se consideră că acestea au fost compromise, fără a invalida mesajele aflate

în pregătire sau în tranzit. Fiecare pereche are un identificator asociat, astfel încât un emiţător

de mesaj poate spune destinatarului ce cheie publică a fost folosită pentru criptarea acestuia.

Identificatorii de mesaj constau din ultimii 64 de biţi ai cheii publice. Utilizatorii sunt responsabili

pentru evitarea conflictelor între identificatorii cheilor lor publice. Cheile private de pe disc sunt

criptate folosind o parolă specială (arbitrar de lungă) pentru a le proteja împotriva unor atacuri.

Inelul cheilor publice conţine cheile publice ale corespondenţilor utilizatorului. Acestea sunt

necesare pentru criptarea cheilor de mesaj asociate cu fiecare mesaj. Fiecare intrare în inelul

cheilor publice conţine nu doar cheia publică, ci şi identificatorul său pe 64 de biţi şi o indicaţie

asupra încrederii pe care o are utilizatorul în cheie.

Problema care trebuie rezolvată aici este următoarea. Să presupunem că cheile publice sunt

menţinute în grupurile de ştiri. O metodă pentru Trudy de a citi e-mail-ul secret al lui Bob este

de a ataca grupul de ştiri şi de a înlocui cheia publică a lui Bob cu una la alegerea sa. Când

Alice va lua mai târziu aşa-zisa cheie a lui Bob, Trudy poate lansa un atac găleata-brigăzii la

adresa lui Bob.

Pentru a preveni astfel de atacuri, sau cel puţin pentru a minimiza consecinţele lor, Alice trebuie

să ştie cât de mult se poate încrede în obiectul numit „cheia lui Bob” din inelul său de chei


70

publice. Dacă ea ştie că Bob personal i-a dat o dischetă conţinând cheia, atunci poate acorda

valoarea maximă de încredere. Această abordare descentralizată, bazată pe controlul

utilizatorului, asupra administrării cheilor publice este ceea ce face PGP să se deosebească de

schemele centralizate PKI.

Totuşi, în practică, oamenii primesc cheile publice întrebând un server de chei sigur. Din acest

motiv, după ce X.509 a fost standardizat, PGP a început să suporte aceste certificate, pe lângă

tradiţionalul mecanism al inelelor cu chei publice. Toate versiunile curente de PGP suportă

X.509.

9.2 PEM-Privacy Enhanced Mail (Poştă cu Confidenţialitate Sporită)

Spre deosebire de PGP, care a fost iniţial opera unui singur om, cel de-al doilea exemplu al

nostru, PEM (Privacy Enhanced Mail), dezvoltat la sfârşitul anilor ’80, este un standard oficial

Internet şi este descris în patru RFC-uri: RFC 1421 până la RFC 1424. Foarte pe scurt, PEM

acoperă acelaşi teritoriu ca şi PGP: confidenţialitatea şi autentificarea sistemelor de e-mail

bazate pe RFC 822. Cu toate acestea, el prezintă şi unele diferenţe faţă de abordarea şi

tehnologia PGP.

Mesajele trimise folosind PEM sunt mai întâi convertite într-o formă canonică, astfel încât ele au

aceleaşi convenţii referitoare la spaţii albe (de ex. tab-uri, spaţiile de la sfârşit de text). Apoi este

calculat un cod de dispersie al mesajului, folosind MD2 sau MD5. După aceasta, concatenarea

codului de dispersie şi a mesajului este criptată folosind DES. În lumina cunoscutei slăbiciuni a

unei chei de 56 de biţi, această alegere este în mod sigur suspectă. Mesajul criptat poate fi apoi

codificat utilizând o codificare în baza 64 şi transmis destinatarului.

Ca şi în PGP, fiecare mesaj este criptat cu o cheie unică, inclusă şi ea în mesaj. Cheia poate fi

protejată fie cu RSA, fie cu DES triplu folosind EDE.

În PEM administrarea cheilor este mult mai structurată decât în PGP. Cheile sunt certificate prin

certificate X.509 emise de CA-uri, care sunt organizate într-o ierarhie rigidă pornind de la o

singură rădăcină (bază). Avantajul acestei scheme este că revocarea certificatului este posibilă

dacă autoritatea corespunzătoare rădăcinii emite periodic CRL-uri.

9.3 S/MIME

Ca şi PEM, S/MIME (Secure/MIME – MIME Sigur) oferă autentificare, integritatea datelor,

confidenţialitate şi non-repudiere. Este de asemenea destul de flexibil, suportând o varietate de

algoritmi criptografici. În mod previzibil, având în vedere numele, S/MIME se integrează bine cu

MIME, permiţând tuturor tipurilor de mesaje să fie protejate. Sunt definite o varietate de antete

noi MIME, de exemplu pentru a conţine semnături digitale.


71

S/MIME nu are o ierarhie rigidă pentru certificate, pornind de la o singură bază. În schimb,

utilizatorii pot avea mai multe puncte de încredere (trust anchors). Atâta timp cât un certificat

poate fi urmărit înapoi până la un punct în care utilizatorul are încredere, este considerat valid.

S/MIME foloseşte algoritmii şi protocoalele standard pe care le-am examinat până acum.

10. Securitatea Web-ului

În linii mari, securitatea Web-ului poate fi împărţită în trei subiecte. În primul rând, cum pot fi

sigur denumite obiectele şi resursele? În al doilea rând, cum se pot stabili conexiuni sigure,

autentificate? În al treilea rând, ce se întâmplă când un sit Web trimite unui client un fragment

de cod executabil?

10.1 Pericole

În ziare se poate citi despre problemele de securitate a siturilor Web aproape în fiecare

săptămână. Situaţia e într-adevăr destul de proastă. În primul rând, paginile principale ale

multor organizaţii au fost atacate şi înlocuite cu alte pagini alese de spărgători (crackers).

Printre siturile care au fost sparte se numără şi Yahoo, Armata S.U.A., CIA, NASA, New York

Times. În cele mai multe cazuri, spărgătorii au pus acolo doar un text amuzant şi siturile au fost

reparate în câteva ore.

Multe situri au căzut din cauza atacurilor de refuz al serviciilor (denial-of-service attacks), în

care spărgătorul „inundă” situl cu trafic, făcându-l incapabil de a răspunde la cererile legitime.

De multe ori atacul e lansat de pe un număr mare de maşini în care spărgătorul tocmai a intrat

(atacuri distribuite de negare a serviciilor – DDoS attacks). Aceste atacuri au devenit atât de

obişnuite încât acum nici nu mai ajung la ştiri, dar pot costa situl atacat mii de dolari în afaceri

pierdute.

10.2 Siguranţa numelor

Se consideră exemplul: Alice vrea să viziteze situl Web al lui Bob. Ea tastează URL-ul lui Bob în

browser şi după câteva secunde, apare o pagină Web. Dar este pagina lui Bob? Pate că da,

poate că nu. Poate că Trudy s-a întors din nou la farsele ei. De exemplu, ar putea să

intercepteze toate pachetele ce vin de la Alice şi să le examineze. Când găseşte o cerere HTTP

de tip GET pentru situl lui Bob, ar putea să se ducă ea însăşi la situl lui Bob ca să ia pagina, să

o modifice după cum doreşte şi să îi trimită lui Alice pagina falsă. Alice nu ar fi deloc mai

înţeleaptă. Mai rău, Trudy ar putea să micşoreze preţurile din magazinul virtual al lui Bob pentru


72

a face produsele să pară foarte atractive, păcălind-o astfel pe Alice să trimită numărul cărţii ei

de credit lui „Bob” ca să cumpere ceva.

.

Figura 12-38. (a) Situaţie normală. (b) Atac bazat pe spargerea DNS-ului şi modificarea

înregistrării lui Bob

Un dezavantaj al acestui atac clasic de tip omul-din-mijloc este acela că Trudy trebuie să poată

intercepta traficul ce pleacă de la Alice şi să îl poată falsifica pe cel ce vine. Practic, ea trebuie

să intercepteze linia de telefon a lui Alice sau a lui Bob, pentru că interceptarea fibrei optice

este foarte dificilă. Deşi interceptarea activă a cablurilor este cu siguranţă posibilă, ea

presupune o anumită cantitate de muncă. În plus, există moduri mai uşoare de a o păcăli pe

Alice.

Păcălirea DNS-ului (DNS Spoofing)

De exemplu, se presupune că Trudy poate să spargă sistemul DNS, sau poate memoria

ascunsă a DNS de la ISP-ul lui Alice, şi să înlocuiască adresa IP a lui Bob (de exemplu,

36.1.2.3) cu adresa ei (a lui Trudy, de exemplu, 42.9.9.9). Aceasta duce la următorul atac.

Modul în care ar trebui să funcţioneze este ilustrat în Figura 12-38(a). Aici (1) Alice cere DNS-

ului adresa IP a lui Bob, (2) o obţine, (3) îi cere lui Bob pagina sa principală şi (4) o obţine şi pe

aceasta. După ce Trudy a modificat înregistrarea DNS corespunzătoare lui Bob astfel încât

aceasta să conţină adresa ei IP în loc de cea a lui Bob, ajungem la situaţia din Figura 12-38(b).

Aici, când Alice caută adresa IP a lui Bob, o obţine pe a lui Trudy, aşa că tot traficul ei destinat

lui Bob ajunge la Trudy. Trudy poate organiza acum un atac omul-din-mijloc fără să mai fie


73

necesar să facă efortul de a intercepta vreo linie telefonică. În schimb, ea trebuie să pătrundă

într-un server DNS şi să schimbe o înregistrare, ceea ce este mult mai uşor.

Cum ar putea Trudy să înşele DNS-ul? Acest lucru se dovedeşte a fi relativ uşor. Pe scurt,

Trudy poate să păcălească serverul DNS de la ISP-ul lui Alice, făcându-l să trimită o cerere

pentru a afla adresa lui Bob. Din nefericire, deoarece DNS-ul foloseşte UDP, serverul DNS

practic nu poate verifica cine a dat cu adevărat răspunsul. Trudy poate profita de această

proprietate pentru a falsifica răspunsul aşteptat, introducând astfel o adresă IP falsă în memoria

ascunsă a serverului DNS. Pentru simplitate, se presupune că iniţial ISP-ul lui Alice nu are o

intrare pentru situl Web al lui Bob, bob.com. Dacă are, Trudy poate să aştepte până când

aceasta expiră şi să încerce mai târziu (sau să folosească alte manevre).

Trudy începe atacul prin a trimite o cerere de căutare ISP-ului lui Alice, solicitând adresa IP a

sitului bob.com. Cum nu are nici o intrare pentru acest nume, serverul local interoghează

serverul de nivel superior pentru domeniul com pentru a obţine una. Totuşi, Trudy o ia înaintea

serverului com şi trimite înapoi un răspuns fals spunând: „bob.com este 42.9.9.9” , unde acea

adresă IP este a ei. Dacă răspunsul ei fals ajunge primul la ISP-ul lui Alice, va fi memorat în

memoria ascunsă şi răspunsul adevărat va fi respins ca răspuns nesolicitat la o cerere care nu

mai e valabilă. A face un server DNS să instaleze o adresă IP falsă se numeşte păcălirea DNS-

ului (DNS spoofing). O memorie ascunsă care conţine o adresă IP intenţionat falsă, ca aceasta,

se numeşte memorie ascunsă otăvită (poisoned cache).

De fapt, lucrurile nu sunt chiar aşa de simple. În primul rând, ISP-ul lui Alice verifică dacă

răspunsul are adresa IP sursă corectă a serverului de nivel superior. Dar cum Trudy poate să

pună orice doreşte în acel câmp al mesajului, poate trece uşor de acest test, pentru că adresele

IP ale serverelor de nivel superior trebuie să fie publice.

În al doilea rând, pentru ca serverele DNS să poată spune care răspuns corespunde cărei

cereri, toate cererile poartă un număr de secvenţă. Pentru a păcăli ISP-ul lui Alice, Trudy

trebuie să îi cunoască numărul de secvenţă curent. Cea mai uşoară metodă de a afla numărul

de secvenţă este ca Trudy să–şi înregistreze ea însăşi un domeniu, să spunem trudy-the-

intruder.com. Să presupunem că adresa IP a acestuia este tot 42.9.9.9. Ea creează şi un server

DNS pentru noul ei domeniu, să spunem dns.trudy-the-intruder.com. Şi acesta foloseşte adresa

IP a lui Trudy, 42.9.9.9, din moment ce Trudy are un singur calculator. Acum ea trebuie să-l

facă pe ISP-ul lui Alice să înregistreze serverul ei DNS. Asta e uşor de făcut. Tot ceea ce are de

făcut este să întrebe ISP-ul lui Alice de foobar.trudythe-intruder.com, şi ISP-ul lui Alice va afla

cine se ocupă de noul domeniu al lui Trudy întrebând serverul com de nivel superior.

Cu dns.trudy-the-intruder.com aflat în siguranţă în memoria ascunsă a ISP-ului lui Alice,

adevăratul atac poate începe. Acum Trudy întreabă ISP-ul lui Alice de www.trudy-the-

intruder.com. Bineînţeles, ISP-ul trimite serverului DNS al lui Trudy o cerere referitoare la acest

http://www.trudy-the-intruder.com/

http://www.trudy-the-intruder.com/


74

domeniu. Această cerere poartă numărul de secvenţă pe care îl caută Trudy. Sprintenă ca un

iepuraş, Trudy îi cere ISP-ului lui Alice să îl caute pe Bob. Apoi răspunde imediat la propria

întrebare trimiţând ISP-ului un răspuns falsificat, ca din partea serverului com de nivel superior,

spunând: „bob.com este 42.9.9.9 ”. Acest răspuns falsificat poartă un număr de secvenţă cu 1

mai mare decât cel pe care tocmai l-a primit ea. Dacă tot a ajuns aici, poate să mai trimită şi un

al doilea fals cu un număr de secvenţă cu 2 mai mare şi poate încă o duzină de răspunsuri false

cu numere de secvenţă consecutive. Unul dintre ele va trebui să se potrivească. Restul pur şi

simplu vor fi respinse. Când răspunsul fals ajunge la Alice, este stocat în memoria ascunsă; mai

târziu, când va ajunge răspunsul adevărat, va fi respins pentru că nu va mai exista pentru el o

cerere valabilă.

Acum, când Alice caută bob.com, i se spune să folosească 42.9.9.9, adresa lui Trudy. Trudy a

organizat cu succes un atac omul-din-mijloc din confortabila ei cameră de zi. Diverşii paşi ai

acestui atac sunt ilustraţi în Figura 12-39. Pentru ca situaţia să fie şi mai complicată, acesta nu

e singurul mod de a păcăli DNS-ul.

Figura 12-39 – Cum păcăleşte Trudy ISP-ul lui Alice

DNS sigur

Acest atac, în particular, poate fi împiedicat făcând serverele DNS să folosească identificatori

aleatorii în cererile lor în loc să numere pur şi simplu, dar se pare că de fiecare dată când o

gaură e astupată, se iveşte una nouă. Adevărata problemă este că DNS-ul a fost proiectat într-o

vreme în care Internetul era o facilitate pentru cercetare pentru câteva sute de universităţi şi nici

Alice, nici Bob, nici Trudy nu intraseră încă în joc. Pe atunci securitatea nu era o problemă;

problema era de a face Internetul să funcţioneze. Situaţia s-a schimbat radical cu trecerea

anilor, aşa că în 1994 IETF a înfiinţat un grup de lucru care să facă DNS-ul fundamental sigur.

Acest proiect este cunoscut sub numele de DNSsec (DNS security – securitatea DNS-ului).


75

Rezultatele lui sunt prezentate în RFC 2535. Din nefericire, DNSsec nu a fost încă distribuit

peste tot, aşa că multe servere DNS sunt încă vulnerabile la atacuri de păcălire.

Conceptual, DNSsec este extrem de simplu. Este bazat pe criptografia cu chei publice. Fiecare

zonă DNS are o pereche de chei formată dintr-una publică şi una privată. Toate informaţiile

trimise de un server DNS sunt semnate cu cheia privată a zonei de origine, deci destinatarul

poate să le verifice autenticitatea.

DNSsec oferă trei servicii fundamentale:

1. Dovada originii datelor.

2. Distribuţia cheilor publice.

3. Autentificarea tranzacţiilor şi a cererilor.

Principalul serviciu este primul dintre ele, care verifică faptul că datele returnate au fost

aprobate de către deţinătorul zonei. Al doilea este util pentru stocarea şi refacerea, în siguranţă,

a cheilor publice. Al treilea este necesar pentru a proteja împotriva atacurilor prin reluare şi a

celor de păcălire. Se observă că păstrarea secretului nu face parte dintre serviciile oferite

deoarece toate informaţiile din DNS sunt considerate publice. Cum etapele dezvoltării DNSsec

se estimează că vor dura mai mulţi ani, capacitatea serverelor ce pot asigura securitatea de a

colabora cu cele ce nu o asigură este esenţială, ceea ce implică faptul că protocolul nu poate fi

schimbat. Să vedem acum nişte detalii.

Înregistrările DNS sunt grupate în mulţimi numite RRSets (Resource Record Sets – Mulţimi de

Înregistrări de Resurse), toate înregistrările cu acelaşi nume, clasă şi tip fiind incluse într-o

mulţime. O mulţime poate conţine mai multe înregistrări A, de exemplu, dacă un nume DNS

corespunde unei adrese IP primare şi unei adrese IP secundare. Mulţimile sunt extinse cu

câteva tipuri noi de înregistrări (discutate mai jos). Pentru fiecare mulţime se face un cod de

dispersie criptografic (de exemplu utilizând MD5 sau SHA-1). Rezumatul e semnat de către

zona privată a RRSet. La primirea unei mulţimi semnate, clientul poate verifica dacă a fost

semnată cu cheia privată a zonei de origine. Dacă semnătura coincide, datele sunt acceptate.

Cum fiecare mulţime are propria semnătură, RRSet poate fi memorat oriunde, chiar pe un

server neautorizat, fără să pună în pericol securitatea.

DNSsec introduce câteva tipuri noi de înregistrări. Primul din ele este înregistrarea KEY.

Această înregistrare conţine cheia publică a unei zone, utilizatorul, gazda, sau alt principal,

algoritmul criptografic folosit pentru semnături, protocolul folosit pentru transmisie şi încă biţi în

plus. Cheia publică este stocată ca atare. Certificatele X.509 nu sunt utilizate, din cauza

dimensiunii lor. Câmpul corespunzător algoritmului este 1 pentru semnături MD5/RSA (varianta

preferată), sau are alte valori pentru alte combinaţii. Câmpul corespunzător protocolului poate

indica folosirea IPsec sau a altor protocoale de securitate, dacă s-a utilizat vreunul.


76

Al doilea tip nou de înregistrare este SIG. Acesta conţine codul de dispersie semnat conform

algoritmului specificat în înregistrarea KEY. Semnătura se aplică tuturor resurselor din set,

inclusiv celor de tip KEY, dar nu şi lui însuşi. Înregistrarea mai conţine şi momentele când

începe perioada de valabilitate a semnăturii şi când aceasta expiră, precum şi numele celui

care semnează şi alte câteva informaţii.

DNSsec este proiectat astfel încât cheia privată a unei zone să poată fi păstrată pe un

calculator neconectat la reţea. O dată sau de două ori pe zi, conţinutul bazei de date a unei

zone poate fi transportat manual (de exemplu, pe CD-ROM) la o maşină neconectată unde se

găseşte cheia privată. Toate mulţimile de înregistrări pot fi semnate acolo şi înregistrările SIG

create astfel pot fi duse înapoi, pe CD-ROM, la serverul primar al zonei. Astfel, cheia privată

poate fi memorată pe un CDROM încuiat într-un seif, mai puţin în momentele în care este

introdus în calculatorul neconectat pentru a semna înregistrările noi. Când semnarea s-a

terminat, toate copiile cheii sunt şterse din memorie şi CD-ROM-ul este pus înapoi în seif.

Această procedură reduce securitatea electronică la securitatea fizică.

Această metodă de a pre-semna mulţimile de înregistrări accelerează foarte mult procesul de

răspuns la cereri, deoarece nu mai trebuie făcute pe loc operaţii de criptografie. Dezavantajul

este că e necesară o cantitate mare de spaţiu pe disc pentru a stoca toate cheile şi semnăturile

în bazele de date DNS. Unele înregistrări îşi vor mări dimensiunea de zece ori din cauza

semnăturii.

Când un proces client obţine o mulţime de înregistrări semnată, trebuie să aplice cheia publică

a zonei de origine pentru a decripta rezumatul, să calculeze el însuşi rezumatul, şi să compare

cele două valori. Dacă sunt identice, datele sunt considerate valide. Totuşi, această procedură

ridică întrebarea cum va afla clientul cheia publică a zonei. Un mod este de a o cere unui server

autorizat, folosind o conexiune sigură (de ex., folosind IPsec).

Totuşi, în practică, e de aşteptat ca clienţii să fie reconfiguraţi cu cheile publice ale tuturor

domeniilor de nivel superior. Dacă acum Alice vrea să viziteze situl Web al lui Bob, poate cere

DNSului mulţimea de înregistrări pentru bob.com, care va conţine adresa IP a acestuia şi o

înregistrare de tip KEY cu cheia publică a lui Bob. Această mulţime de înregistrări va fi semnată

de către nivelul superior com, deci Alice îi poate verifica uşor validitatea. Un exemplu de ce ar

putea conţine această mulţime de înregistrări se află în Figura 12-40.

Înarmată acum cu o copie verificată a cheii publice a lui Bob, Alice poate întreba serverul DNS

al lui Bob (rulat de Bob) de adresa IP pentru www.bob.com. Această mulţime de înregistrări va

fi semnată cu cheia privată a lui Bob, deci Alice poate verifica semnătura mulţimii de înregistrări

pe care o returnează Bob. Dacă Trudy reuşeşte în vreun fel să introducă o mulţime de

înregistrări falsă în una din memoriile ascunse, Alice poate detecta cu uşurinţă lipsa ei de

autenticitate pentru că înregistrarea SIG va fi incorectă.

http://www.bob.com/


77

Figura 12-40 – Un exemplu de mulţime de înregistrări (RRSet) pentru bob.com. Înregistrarea

KEY este cheia publică a lui Bob. Înregistrarea SIG este rezumatul serverului com de nivel

superior pentru înregistrările A şi KEY , pentru a le verifica autenticitatea.

Totuşi, DNSsec oferă şi un mecanism criptografic de a lega un răspuns de o anumită cerere,

pentru a preveni înşelătoria pe care Trudy a reuşit să o facă în Figura 12-39. Această măsură

(opţională) de prevenire a înşelătoriilor adaugă la răspuns un cod de dispersie al mesajului de

interogare semnat cu cheia privată a celui care răspunde. Cum Trudy nu ştie cheia privată a

serverului com de nivel superior, nu poate falsifica un răspuns la o cerere pe care ISP-ul lui

Alice a trimis-o acolo. Desigur, ea poate să trimită prima răspunsul, dar acesta va fi respins din

cauza semnăturii invalide a rezumatului cererii.

Nume cu auto-certificare DNS sigur nu este singura posibilitate de a proteja numele. O abordare complet diferită este

întâlnită în Sistemul Sigur de Fişiere (Secure File System). În acest proiect, autorii au conceput

un sistem de fişiere sigur, scalabil, de întindere foarte largă, fără a modifica DNS-ul (standard)

şi fără a folosi certificate sau a presupune existenţa unei PKI. În această secţiune se arată cum

au putut fi aplicate ideile lor în cazul Web-ului. Prin urmare, în descrierea de mai jos se va folosi

terminologia Web în loc de cea a sistemelor de fişiere, utilizată în lucrarea respectivă. Dar,

pentru a evita orice confuzie, deşi această schemă ar putea să fie aplicată Web-ului pentru a

obţine o securitate înaltă, ea nu este folosită în prezent şi ar avea nevoie de modificări

substanţiale ale software-ului pentru a fi introdusă.

Se începe prin a presupune că fiecare server Web are o pereche de chei formată dintr-o cheie

publică şi una privată. Esenţa ideii este că fiecare URL conţine un cod de dispersie criptografic

pentru numele serverului şi cheia publică a acestuia, ca parte a URL-ului. De exemplu, în

Figura 12-41 arată URL-ul pentru fotografia lui Bob. Începe cu obişnuita schemă http, urmată de

numele DNS al serverului (www.bob.com). Apoi urmează două puncte şi un rezumat de 32 de

caractere. La sfârşit este numele fişierului, din nou în modul obişnuit. Cu excepţia codului de

dispersie, acesta este un URL standard. Împreună cu codul, este un URL cu auto-certificare

(self-certifying URL).


78

Figura 12-41 Un URL cu auto-certificare conţinând un rezumat al numelui serverului şi al cheii

publice.

Întrebarea evidentă este: la ce foloseşte codul de dispersie? Codul e calculat concatenând

numele DNS al serverului cu cheia publică a acestuia şi aplicând rezultatului funcţia SHA-1

pentru a obţine un cod pe 160 de biţi. În această schemă, rezumatul e reprezentat ca o

secvenţă de 32 de cifre şi litere mici, cu excepţia literelor „l” şi „o” şi a cifrelor „1” şi „0”, pentru a

evita confuziile. Deci au mai rămas 32 de cifre şi de litere posibile. Fiecare dintre cele 32 de

caractere disponibile poate codifica un şir de 5 biţi. Un şir de 32 de caractere poate reprezenta

rezumatul SHA-1 de 160 de biţi. De fapt, nu e necesară folosirea unui rezumat; ar putea fi

folosită cheia însăşi. Avantajul rezumatului este că reduce lungimea numelui.

Cel mai simplu (dar cel mai puţin convenabil) mod de a vedea fotografia lui Bob este ca Alice să

trimită pur şi simplu şirul din Figura 12-41 programului de navigare. Programul de navigare

trimite un mesaj la situl lui Bob, cerându-i cheia publică. Când cheia publică a lui Bob ajunge,

programul de navigare concatenează numele serverului şi cheia publică şi execută algoritmul

de calcul al rezumatului. Dacă rezultatul coincide cu rezumatul de 32 de caractere din URL-ul

securizat, programul de navigare este sigur că are cheia publică a lui Bob. Până la urmă,

datorită proprietăţilor algoritmului SHA-1, chiar dacă Trudy interceptează cererea şi falsifică

răspunsul, nu are cum să găsească o cheie publică prin care să se obţină rezumatul aşteptat.

Orice interferenţă din partea ei va fi astfel detectată. Cheia publică a lui Bob poate fi stocată în

memoria ascunsă pentru utilizări viitoare.

Acum Alice trebuie să verifice că Bob are cheia privată corespunzătoare. Ea construieşte un

mesaj conţinând o cheie de sesiune AES propusă, un număr ad-hoc şi o amprentă de timp. Pe

urmă criptează mesajul cu cheia publică a lui Bob şi i-l trimite. Cum doar Bob are cheia privată

corespunzătoare, numai el poate să decripteze mesajul şi să trimită înapoi numărul ad-hoc

criptat cu cheia AES. Când primeşte numărul corect criptat AES, Alice ştie că vorbeşte cu Bob.

De asemenea, Alice şi Bob au acum o cheie de sesiune AES pentru următoarele cereri şi

răspunsuri GET.

Odată ce Alice are fotografia lui Bob (sau orice altă pagină Web), ea poate să o marcheze

(bookmark), ca să nu mai trebuiască să scrie încă o dată întregul URL. Mai mult, URL-urile

incluse în paginile Web pot fi de asemenea cu auto-certificare, ca să poată fi folosite doar

făcându-se un clic pe ele, dar având în plus şi siguranţa că pagina returnată este cea corectă.


79

Alte moduri de a evita scrierea iniţială a URL-urilor cu auto-certificare sunt obţinerea lor printr-o

conexiune sigură de la un server autorizat sau prezenţa lor în certificate X.509 semnate de

autorităţi de certificare.

Altă metodă de a obţine URL-uri cu auto-certificare ar fi conectarea la un motor de căutare

autorizat, introducând (prima dată) URL-ul cu auto-certificare al acestuia, şi trecerea prin

acelaşi protocol cu cel descris mai sus, ceea ce va duce la o conexiune sigură, autentificată, cu

motorul de căutare. Apoi motorul de căutare poate fi interogat, iar rezultatele vor apărea pe o

pagină semnată, plină cu URL-uri auto-certificate ce pot fi accesate printr-un clic, fără a mai fi

necesară scrierea unor şiruri lungi.

Dacă Trudy reuşeşte otrăvirea memoriei ascunse de la ISP-ul lui Alice, cererea lui Alice ar

putea fi în mod greşit livrată lui Trudy în loc de Bob. Dar acum protocolul cere ca cel ce

primeşte un mesaj iniţial (adică Trudy) să returneze o cheie care să producă rezumatul corect.

Dacă Trudy îşi trimite propria cheie publică, Alice o va detecta imediat pentru că rezumatul

SHA-1 nu se va potrivi cu URL-ul auto-certificat. Dacă Trudy trimite cheia publică a lui Bob,

Alice nu va detecta atacul, dar va cripta mesajul următor folosind cheia lui Bob. Trudy va primi

mesajul, dar nu va putea să-l decripteze pentru a extrage cheia AES şi numărul ad-hoc. În

ambele cazuri, tot ceea ce poate face această păcălire a DNS-ului este să provoace un atac de

refuz al serviciului.

10.3 SSL – Nivelul soclurilor sigure (Secure Sockets Layer)

Atunci când Web-ul a intrat în atenţia publicului, el era folosit pentru distribuţia de pagini statice.

Oricum, nu după mult timp, câteva companii au avut ideea de a-l folosi pentru tranzacţii

financiare, cum ar fi de exemplu cumpărarea de bunuri cu ajutorul cărţii de credit, operaţiuni

bancare online şi schimburi electronice de acţiuni. Aceste aplicaţii au creat o cerere pentru

conexiuni sigure. În 1995, compania Netscape Communications, furnizorul dominant de

navigatoare de web din acel moment, a răspuns acestei cereri prin introducerea unui pachet de

securitate denumit SSL (Secure Sockets Layer –Nivelul soclurilor sigure).

SSL-ul realizează o conexiune sigură între două socluri, precum şi

1. Negocierea parametrilor între client şi server.

2. Autentificare mutuală a clientului şi serverului.

3. Comunicare secretă.

4. Protecţia integrităţii datelor.

Poziţia SSL-ului în cadrul stivei de protocoale este ilustrată în Figura 12-42. De fapt, este un

nou nivel interpus între nivelul aplicaţie şi cel de transport, acceptând cereri din partea unui


80

program de navigare şi trimiţându-le mai jos către TCP pentru transmisia către server. Din

momentul în care s-a realizat conexiunea sigură, principala sarcină a SSL-ului constă în

asigurarea compresiei şi a criptării. Când HTTP este folosit deasupra SSL-ului, este denumit

HTTPS (Secure HTTP – HTTP securizat), deşi este vorba de protocolul standard HTTP.

Câteodată este disponibil la un nou port (443) în loc de portul standard (80). Ca o

particularitate, folosirea SSL nu este restricţionată numai cu programe de navigare Web, deşi

aceasta este aplicaţia cea mai des întâlnită.

Figura 12-42. Niveluri (şi protocoale) pentru un utilizator obişnuit ce navighează cu SSL.

Protocolul SSL a cunoscut mai multe versiuni. În cele ce urmează, se va discuta numai despre

versiunea 3, care este cea mai folosită. SSL suportă o diversitate de algoritmi şi opţiuni diferite.

Aceste opţiuni includ prezenţa sau absenţa compresiei, algoritmii de criptare ce vor fi folosiţi şi

câteva chestiuni legate de restricţiile de export impuse criptografiei

SSL constă din două subprotocoale, unul pentru stabilirea unei conexiuni sigure şi unul pentru

folosirea acesteia.

Subprotocolul de stabilire a conexiunii este arătat în Figura 12-43. El începe cu mesajul 1 când

Alice trimite o cerere către Bob pentru stabilirea unei legături. Cererea specifică versiunea de

SSL pe care o are Alice şi preferinţele sale cu privire la algoritmii de compresie şi de criptare.

De asemenea, conţine un număr ad-hoc (nonce), RA.

Acum este rândul lui Bob. În cel de al doilea mesaj, Bob face o alegere între diverşii algoritmi pe

care Alice îi poate suporta şi îşi trimite numărul lui ad-hoc, RB. Apoi, în mesajul 3, el trimite un

certificat ce conţine cheia lui publică. Dacă acest certificat nu este semnat de o autoritate

recunoscută, el trimite de asemenea şi un lanţ de certificate ce pot fi urmate în sens invers până

la ultimul. Toate programele de navigare, inclusiv cel al lui Alice, au predefinite aproximativ 100

de chei publice, aşa că dacă Bob poate stabili un lanţ care ajunge la una din acestea, Alice va

putea să verifice cheia publică a lui Bob. În acest moment, Bob poate trimite şi alte mesaje

(cum ar fi o cerere pentru certificatul cheii publice al lui Alice). Când Bob a terminat, el trimite


81

mesajul numărul 4 pentru a-i spune lui Alice că este rândul ei. Alice răspunde prin alegerea unei

chei primare (premaster key) aleatoare de 384 de biţi şi prin trimiterea acesteia lui Bob,

criptată cu cheia lui publică (mesajul numărul 5). Cheia sesiunii folosită de fapt pentru criptarea

datelor este derivată din cheia primară combinată cu ambele numere ad-hoc într-o manieră

complexă. După ce mesajul 5 a ajuns, atât Alice cât şi Bob sunt în stare să calculeze cheia

sesiunii. Datorită acestui fapt, Alice îi spune lui Bob să folosească noul cifru (mesajul 6) şi de

asemenea că a terminat subprotocolul de stabilire (mesajul 7). Bob îi răspunde afirmativ la

aceste mesaje (mesajele cu numerele 8 şi 9).

Figura 12-43 – O versiune simplificată a subprotocolului de stabilire unei conexiuni SSL

Totuşi, deşi Alice ştie cine este Bob, Bob nu ştie cine este Alice (în afara cazului în care Alice

are o cheie publică şi un certificat corespunzător pentru ea, o situaţie puţin probabilă în cazul

unui individ). De aceea, primul mesaj al lui Bob poate foarte bine să fie o cerere pentru ca Alice

să se autentifice folosind un nume de login şi o parolă ce au fost stabilite anterior. Protocolul de

autentificare este în afara domeniului de acoperire al SSL-ului. De îndată ce a fost îndeplinit,

prin orice mijloace, transportul de date poate începe.

Aşa cum este menţionat şi mai sus, SSL suportă mai mulţi algoritmi de criptare. Cel mai

puternic dintre aceştia foloseşte triplu DES cu trei chei separate pentru criptare şi SHA-1 pentru

integritatea mesajului. Această combinaţie este relativ lentă, aşa că este folosită de cele mai

multe ori de operaţiile bancare şi alte aplicaţii în care este necesar cel mai mare nivel de

securitate. Pentru aplicaţii obişnuite de comerţ electronic este folosit RC4 cu o cheie de 128 de


82

biţi pentru criptare şi MD5 pentru autentificarea mesajului. RC4 foloseşte cheia de 128 de biţi ca

un punct de plecare şi o extinde la un număr mult mai mare pentru uzul intern. Apoi foloseşte

acest număr intern pentru a genera un şir cheie. Acesta este supus unei operaţii SAU

EXCLUSIV cu textul pentru a genera un flux de cifru clasic. Versiunile de export folosesc de

asemenea RC4 cu chei de 128 de biţi, dar 88 de biţi dintre aceştia sunt făcuţi public pentru a

face cifrul mai uşor de spart.

Figura 12-44 – Transmisie de date folosind SSL

Pentru transportul efectiv, este folosit un al doilea subprotocol, aşa cum este arătat în Figura

12-44. Mesajele de la navigator sunt mai întâi sparte în bucăţi de până la 16 KB. Dacă

compresia este activată, atunci fiecare unitate este apoi compresată. După aceea, o cheie

secretă derivată din cele două numere ad-hoc şi cheia primară este concatenată cu textul

compresat şi rezultatul este rezumat cu algoritmul de dispersie agreat (de obicei MD5). Acest

cod de dispersie este adăugat fiecărui fragment ca MAC (Message authentication code – Cod

pentru autentificarea mesajului). Fragmentul compresat împreună cu MAC este apoi criptat cu

algoritmul de criptare simetrică agreat (de obicei prin aplicarea operaţiei SAU EXCLUSIV cu

şirul-cheie RC4). În final, este ataşat un antet de fragment şi fragmentul este transmis prin

intermediul conexiunii TCP.

Prudenţa este totuşi importantă. Deoarece a fost demonstrat că RC4 are câteva chei slabe ce

pot fi analizate criptologic, securitatea SSL folosind RC4 este pe un teren şubred. Programele

de navigare ce permit utilizatorului să aleagă suita de cifruri ar trebui configurate să folosească

mereu DES triplu cu chei de 168 de biţi şi SHA-1, chiar dacă această combinaţie este mai lentă


83

decât RC4 şi MD5.

O altă problemă cu SSL o reprezintă faptul că principalii pot să nu aibă certificate şi chiar dacă

au, ei nu verifică întotdeauna dacă cheile folosite se potrivesc cu certificatele.

În 1996, compania Netscape Communications a trimis SSL către IETF pentru standardizare.

Rezultatul a fost TLS (Transport Layer Security – Securitate la nivelul de transport). Acesta

este descris în RFC 2246.

Schimbările aduse SSL au fost relativ mici, dar suficiente pentru ca versiunea 3 de SSL şi TLS

să nu poată coopera. De exemplu, modul în care cheia de sesiune este derivată din cheia

primară (premaster key) şi numerele ad-hoc a fost schimbat pentru a face cheia mult mai

puternică (adică mai greu de criptanalizat). Versiunea de TLS este cunoscută ca versiunea 3.1

SSL.

10.4 Securitatea codului mobil

Denumirile şi conexiunile sunt două zone de interes pentru securitatea pe Web. La început,

când paginile Web erau doar fişiere statice HTML, ele nu conţineau cod executabil. Acum, ele

conţin adesea mici programe, inclusiv applet-uri Java, programe ActiveX şi fragmente

JavaScript. Descărcarea şi execuţia de cod mobil (mobile code) prezintă un risc de securitate

mare; de aceea au fost elaborate diverse metode pentru micşorarea acestui risc.

Securitatea applet-urilor Java

Applet-urile Java sunt mici programe Java care se traduc în limbajul unei maşini cu stivă

denumit JVM (Java Virtual Machine – Maşină virtuală Java). Ele pot fi puse intr-o pagină Web

fiind descărcate împreună cu pagina. După ce pagina a fost descărcată, applet-urile sunt date

unui interpretor JVM din programul de navigare, aşa cum este ilustrat în Figura 12-45.

Figura 12-45 – Applet-urile pot fi interpretate de către un navigator Web


84

Avantajul execuţiei codului interpretat faţă de codul compilat este că fiecare instrucţiune este

examinată de către interpretor înaintea execuţiei. Astfel este dată o şansă interpretorului de a

verifica dacă adresa instrucţiunii este validă. În plus, apelurile de sistem sunt, de asemenea,

captate şi interpretate. Felul în care aceste apeluri sunt manipulate este conform politicii locale

de securitate. De exemplu, dacă un applet este de încredere (de exemplu, provine de pe discul

local), apelurile de sistem pot fi executate fără probleme. Totuşi, dacă un applet este nesigur

(de exemplu, a venit din Internet), el poate fi încapsulat în ceea ce se numeşte un mediu

protejat (sandbox) pentru a restricţiona comportamentul său şi a controla încercările sale de a

folosi resursele sistemului.

Când un applet încearcă să folosesc resursele sistemului, apelul său este trimis pentru

aprobare către un monitor de securitate. Acest monitor examinează apelul din punctul de

vedere al politici locale de securitate şi apoi decide dacă îl va permite sau îl va respinge. Astfel,

este posibil să dea unor applet-uri acces la resurse, dar nu tuturor. Din nefericire, realitatea este

că modelul de securitate lucrează prost şi că defectele de programare apar mai tot timpul.

ActiveX

Controalele ActiveX sunt programe binare ce pot fi incluse în pagini Web. Când este întâlnit

unul dintre ele, se efectuează o verificare pentru a vedea dacă ar trebui să fie executat sau nu,

şi este executat dacă trece testul. El nu este interpretat şi nici nu este executat într-un mediu

protejat, astfel încât codul are aceeaşi putere ca orice alt program şi poate face mult rău. Astfel,

întreaga securitate constă în a decide dacă controlul ActiveX va fi sau nu rulat.

Metoda aleasă de Microsoft pentru stabilirea acestei deciziei este bazată pe ideea de semnare

a codului (code signing). Fiecare program ActiveX vine împreună cu o semnătură digitală – un

rezumat al codului ce este semnat de cel ce a creat codul folosind criptografia cu cheie publică.

Când un program ActiveX îşi face apariţia, programul de navigare verifică semnătura pentru a

se asigura că nu a suferit modificări în timpul transferului. Dacă semnătura este corectă,

programul de navigare verifică tabelele sale interne pentru a vedea dacă cel ce a creat

programul este de încredere sau există un lanţ ce se termină la un creator de încredere. Dacă

creatorul este de încredere, programul este executat; altfel, nu este executat. Sistemul

Microsoft care verifică programele ActiveX este numit Autenticod (Authenticode).

Se face o comparaţie între modurile de abordare pentru Java şi ActiveX. Cu Java, nu este

important cine a scris applet-ul. În schimb, un interpretor asigură că nu face lucruri interzise de

proprietarul maşinii. Prin contrast, cu semnarea codului, nu există nici o încercare de

monitorizare a comportamentului codului mobil la execuţie. Dacă el vine de la o sursă de

încredere şi nu a fost modificat pe parcurs, el este executat. Nu este făcută nici o încercare de a

vedea dacă codul este răuvoitor sau nu. Dacă programatorul original a dorit să formateze discul


85

dur şi să şteargă memoria ROM flash, astfel încât calculatorul să nu mai poată fi pornit, şi dacă

programatorul a fost recunoscut ca fiind de încredere, codul va rula şi va distruge calculatorul

(excepţie făcând cazul în care controalele ActiveX au fost dezactivate în programul de

navigare).

JavaScript

JavaScript nu are nici un model formal de securitate, dar are o lungă istorie de implementări

vulnerabile. Fiecare furnizor tratează problema securităţii într-o manieră diferită. De exemplu,

versiunea 2 de Netscape Navigator a folosit ceva apropiat de modelul Java, dar la versiunea 4

a fost abandonată această manieră în favoarea modelului de cod semnat.

Problema fundamentală este că permiţând execuţia de cod străin pe calculator pot apare multe

necazuri. Din punct de vedere al securităţii, este ca şi cum s-ar invita un hoţ în casa

dumneavoastră şi apoi s-ar urmări cu atenţie pentru a nu putea ieşi din bucătărie şi intra în

sufragerie. Dacă se întâmplă ceva neaşteptat din neatenţie de o clipă, se pot întâmpla lucruri

rele. Problema este că codul mobil permite o grafică atractivă şi o interacţiune rapidă şi foarte

mulţi proiectanţi Web cred că acestea sunt mult mai importante decât securitatea, în special

când este vorba de riscul altcuiva.

Viruşi

Viruşii sunt o altă formă de cod mobil. Diferenţa între un virus şi un cod mobil obişnuit este

aceea că viruşii sunt scrişi pentru a se reproduce. Când un virus ajunge într-un calculator, prin

intermediul unei pagini Web, al unui document ataşat sau printr-o altă cale, el începe prin

infectarea programelor executabile de pe disc. Când unul dintre aceste programe este executat,

controlul este transferat virusului, care de obicei încearcă să se întindă pe alte maşini, de

exemplu, prin trimiterea de mesaje cu propriile sale copii către toate persoanele din agenda

victimei. Unii viruşi infectează sectorul de start al discului dur, astfel că atunci când maşina

porneşte, virusul este activat. Viruşii au devenit o problemă uriaşă pe Internet şi au provocat

pagube de miliarde de dolari. Nu există o soluţie foarte clară. Probabil că soluţia ar fi cea a unei

noi generaţii de sisteme de operare bazate pe micronuclee şi o separare puternică a

utilizatorilor, proceselor şi resurselor.


86

11. Modelul SNMP (Simple Network Management Protocol)

Modelul SNMP de administrare a reţelei e format din patru componente (Figura 12-46):

1. Noduri administrate.

2. Staţii de administrare.

3. Informaţii de administrare.

4. Un protocol de administrare.

Nodurile administrate pot fi sisteme gazdă, rutere, punţi, imprimante sau alte dispozitive

capabile să comunice informaţii de stare către lumea exterioară. Ca să poată fi administrat

direct de SNMP, un nod trebuie să poată executa un proces de administrare numit agent

SNMP. Toate calculatoarele îndeplinesc această cerinţă, aşa cum o fac şi multe punţi, rutere şi

dispozitive periferice proiectate pentru utilizare în reţea. Fiecare agent îşi menţine o bază de

date locală de variabile, care descrie şi istoria sa şi care îi influenţează funcţionarea.

Figura 12-46 –Componentele modelului de administrare SNMP.

Administrarea reţelei se face de la staţii de administrare (management stations), care sunt de

fapt calculatoare de uz general care execută programe speciale de administrare. Staţiile de

administrare conţin unul sau mai multe procese care comunică cu agenţii prin reţea, trimiţând

comenzi şi primind răspunsuri. În această structură, toată ‘‘inteligenţa’’ se găseşte în staţiile de

administrare. Multe staţii de administrare au o interfaţă grafică ce permite administratorului de

reţea să inspecteze starea reţelei şi să ia măsuri atunci când este necesar.


87

11.1 Modelul de funcţionare SNMP

Cele mai multe reţele sunt eterogene, cu sisteme gazdă de la unul sau mai mulţi producători,

punţi şi rutere de la alte companii şi imprimante de la cu totul altele. Pentru a permite unei staţii

de administrare, care poate fi şi ea furnizată de la un alt producător, să comunice cu toate

aceste componente diferite, natura informaţiei păstrate de toate dispozitivele trebuie să fie bine

specificată. Nu are nici un rost ca staţia de administrare să întrebe un ruter care este rata de

pachete pierdute dacă ruterul nu ţine evidenţa acesteia. De aceea SNMP descrie informaţia

exactă pe care fiecare agent trebuie să o păstreze şi formatul în care trebuie furnizată. Cea mai

mare parte a modelului SNMP o reprezintă definirea celor care trebuie să păstreze anumite

informaţii, precum şi modul în care sunt comunicate aceste informaţii.

Foarte pe scurt fiecare dispozitiv actualizează una sau mai multe variabile care descriu starea

sa. În literatura SNMP aceste variabile se numesc obiecte, dar termenul e oarecum înşelător ,

căci este vorba de obiecte în sensul sistemelor orientate pe obiecte, deoarece acestea au

numai stări , nu şi metode, în afară de citirea şi scrierea valorilor. Colecţia tuturor posibilelor

obiecte dintr-o reţea este dată într-o structură de date numita MIB – Management Information Base – Bază de informaţii de administrare.

Staţiile de administrare interacţionează cu agenţii folosind protocolul SNMP. Acest protocol

permite staţiei de administrare să întrebe un agent despre starea obiectelor locale şi să le

modifice dacă este necesar. Cea mai mare parte din SNMP este reprezentată de acest tip de

comunicaţie întrebare-răspuns.

Totuşi uneori au loc evenimente neaşteptate. Nodurile administrate pot să se blocheze sau să

se reseteze, liniile de comunicaţie pot cădea pentru a reveni apoi la starea de funcţionare, pot

apărea congestii. Fiecare eveniment important este definit într-un modul MIB. Atunci când un

agent observă că s-a produs un eveniment important, raportează imediat evenimentul către

toate staţiile de administrare din lista sa de configuraţie. Acest raport se numeşte capcană

(trap) SNMP. Raportul afirmă doar că s-a întâmplat un anumit eveniment. Este de datoria

staţiei de administrare să lanseze întrebări pentru a afla detaliile evenimentului. Deoarece

comunicaţia de la nodurile administrate către staţia de administrare nu este sigură (adică nu

este confirmată), este bine ca staţia de administrare să interogheze din când în când fiecare

nod administrat pentru a verifica dacă nu cumva au apărut evenimente neobişnuite. Modelul de

interogare la intervale mari, cu accelerare la recepţia unei capcane se numeşte interogare

directă a capcanelor (trap directed polling).

Acest model presupune că fiecare nod administrat este capabil să ruleze intern un agent

SNMP. Este posibil ca dispozitivele mai vechi sau care nu au fost proiectate pentru utilizarea în

reţea să nu aibă această capacitate. Pentru a le putea folosi şi pe acestea , SNMP defineşte

ceea ce numim un agent intermediar (proxy agent), adică un agent care veghează asupra


88

unuia sau mai multor dispozitive non SNMP şi comunică în locul lor cu staţia de administrare şi,

eventual, chiar cu dispozitivele respective prin intermediul unor protocoale care nu sunt

standard.

Securitatea şi autentificarea joacă un rol important în cadrul SNMP-ului. O staţie de

administrare are capacitatea de a afla foarte multe despre fiecare dintre nodurile pe care le

controlează şi de asemenea are posibilitatea de a le opri pe toate. De aceea este foarte

important ca agenţii să fie siguri că cererile presupunându-se a fi de la staţia de administrare

provin într-adevăr de la ea. În SNMPv1, staţia de administrare se identifică prin intermediul unei

parole (text normal) aflată în fiecare mesaj. În SNMPv2 securitatea s-a îmbunătăţit considerabil

prin folosirea unor tehnici criptografice moderne. Această modificare a mai îngreunat acest

protocol care era deja încărcat şi a fost eliminată ulterior.

11.2 ASN.1 – Notaţia sintactică abstractă 1 (Abstract Syntax Notation One)

Nucleul modelului SNMP este mulţimea de obiecte administrate de către agenţi şi citite şi scrise

de către staţia de administrare. Pentru a face posibilă comunicaţia între produse de producţie

diferită este esenţial ca aceste obiecte să fie definite într-un mod standard, independent de

producător. Mai mult este necesară o metodă standard de codificare a acestora pentru

transferul în cadrul reţelei. Definiţiile din C++ ar satisface prima cerinţă dar acestea nu definesc

o codificare a bitului pe fir astfel încât o staţie de administrare folosind codificarea little

endian(cel mai puţin semnificativ primul) pe 32 de biţi în complement faţă de doi, să poată

schimba informaţie neambiguu cu un agent care foloseşte codificarea big endian(cel mai

semnificativ primul) pe 16 biţi, în complement faţă de unu.

Din această cauză este necesar un limbaj standard de definire a obiectelor, împreună cu reguli

de codificare. Cel folosit de SNMP este preluat de la OSI şi se numeşte ASN.1(Abstract Syntax Notation One – Notaţia sintactica abstractă unu). La fel ca OSI, este mare, complex şi

nu prea eficient. Aşa-zisa putere a ASN.1 (existenţa regulilor de codificare neambigue) este de

fapt o slăbiciune a sa, deoarece regulile de codificare sunt optimizate astfel încât să minimizeze

numărul de biţi transmişi cu preţul unei ocupări mai mari a unităţii centrale la ambele capete ale

transmisiei: codificare, decodificare.

Sintaxa abstractă ASN.1 este în esenţă un limbaj de declarare a datelor primitive. El îi permite

utilizatorului să îşi definească obiecte primitive şi apoi să le combine în cadrul unora mai

complexe. O serie de declaraţii din ASN.1 sunt asemănătoare din punct de vedere funcţional cu

declaraţiile pe care le întâlnim în cadrul fişierelor antet (header) asociate multor programe C++.

SNMP are o serie de convenţii sintactice dar care nu sunt totuşi în totalitate cele folosite de

ASN.1. Tipurile de date predefinite sunt scrise cu majuscule(de exemplu INTEGER). Tipurile

definite de utilizator încep cu majusculă, dar trebuie să conţină cel puţin un caracter diferit de


89

majusculă. Identificatorii pot conţine litere mici şi mari, cifre, liniuţă, dar care trebuie să înceapă

cu o literă mică(de exemplu counter). Caracterele de spaţiere (tab, carriage return) nu sunt

semnificative. Comentariile încep cu – şi continuă până la următoarea apariţie a secvenţei --.

Tipuri primitive Semnificaţie

INTEGER Întreg de lungime arbitrară

BIT STRING Şir de 0 sau mai mulţi biţi

OCTET STRING Şir de 0 sau mai mulţi biţi fără semn

NULL Rezervat

OBJECT IDENTIFIER Un tip de date definit oficial

Figura 12-47 –Tipurile de date primitive din ASN.1 permise în SNMP

O variabilă de tipul INTEGER poate, din punct de vedere teoretic, să ia orice valoare întreagă,

dar alte reguli SNMP limitează intervalul. Pentru a exemplifica folosirea tipurilor, este declarată

şi iniţializată cu 100 variabila count de tip INTEGER în ASN.1:

count INTEGER ::=100

Deseori este necesar un subtip ale cărui variabile sunt limitate la o anumită valoare sau la un

interval. Acestea pot fi declarate după cum urmează:

Status ::=INTEGER{up(1),down(2),unknown(3)}

PacketSize ::=INTEGER(0..1023)

Variabilele de tipul BIT STRING şi OCTET STRING conţin zero sau mai mulţi biţi şi, respectiv,

octeţi. Un bit este 0 sau 1. Un octet este cuprins între 0 şi 255 inclusiv. Pentru ambele tipuri pot

fi specificate lungimea şirului şi o valoare iniţială. Tipul OBJECT IDENTIFIER furnizează o

metodă de identificare a obiectelor. În principiu fiecare obiect definit în fiecare standard oficial

poate fi identificat în mod unic. Mecanismul folosit este de a defini un arbore de standardizări şi

de a plasa fiecare obiect şi fiecare standard într-un loc unic în arbore.

Primul nivel din arbore conţine toate organizaţiile importante de standardizare din lume (în

viziunea ISO) şi anume ISO şi CCITT (acum ITU) precum şi combinaţia celor două. Din nodul

ISO sunt definite patru arce din care unul este pentru identified-organization, ceea ce

reprezintă concesia ISO că pot exista şi alte organizaţii implicate în standarde. Ministerului

Apărării al Statelor Unite(DoD) i-a fost atribuit un loc în acest subarbore, iar ministerul a atribuit

numărul 1 din ierarhia sa Internetului. În ierarhia Internet, SNMP MIB are codul 1.


90

Fiecare arc din Figura 12-48 are atât o etichetă cât şi un număr, astfel încât nodurile pot fi

identificate prin intermediul unei liste de arce, folosind etichetă(număr) sau numere. În

consecinţă, toate obiectele MIB din SNMP sunt identificate prin etichete de forma:

{iso identified-organization(3) dod(6) internet(1) mgmt(2) mib-2(1)…}

sau, echivalent, {1 3 6 1 2 1 …}. De asemenea sunt permise şi forme mixte. De exemplu,

identificarea anterioară poate fi scrisă şi sub forma:

{internet(1) 2 1 …}

În acest mod fiecare obiect al fiecărui standard poate fi reprezentat ca un OBJECT

IDENTIFIER.

Figura 12-48 – O parte a arborelui de nume de obiect ASN.1


91

ASN.1 defineşte cinci căi de construire a noilor tipuri derivate din cele de bază. SEQUENCE

este o listă ordonată de tipuri, similară unei structuri din C++ sau unei înregistrări din Pascal.

SEQUENCE OF este un vector uni-dimensional de un anumit tip. SET şi SET OF sunt analoage

celor de mai sus dar nu sunt ordonate. CHOICE creează o uniune (union) dintr-o listă de tipuri.

Cei doi constructori SET nu sunt folosiţi în nici un document SNMP.

O altă cale de a crea noi tipuri este de a redeclara tipuri vechi. Redeclararea unui tip este

oarecum similară cu definirea unor tipuri noi în C++, de exemplu time_t şi size_t, amândouă de

tip long, dar care sunt folosite în contexte diferite. Redeclarările sunt împărţite în 4 categorii:

universale, în cadrul unei aplicaţii, specifice contextului şi private. Fiecare marcaj(tag) este

format dintr-o etichetă şi un întreg identificând marcajul. De exemplu:

Counter32 ::=[APPLICATION 1] INTEGER (0..4294967295)

G32::=[APPLICATION 2]INTEGER (0..4294967295 )

definesc două tipuri diferite în cadrul unei aplicaţii, amândouă fiind întregi fără semn pe 32 biţi,

dar fiind din punct de vedere conceptual diferite. Primul dintre ele ar putea, de exemplu, ca

odată ajuns la valoarea maximă să continue cu valoarea 0, în timp ce cel de-al doilea ar

continua să întoarcă valoarea maximă până când va fi decrementat sau iniţializat.

Un tip redeclarat poate avea cuvântul cheie IMPLICIT după paranteza dreaptă închisă atunci

când tipul a ceea ce urmează reiese din context(ceea ce de exemplu, nu este adevărat în

cadrul unui CHOICE). Procedând astfel permitem o mai eficientă codificare a biţilor, din moment

ce marcajul nu mai trebuie transmis. Într-un tip care implică o alegere(CHOICE) între două tipuri

diferite, trebuie transmis un marcaj care să spună receptorului ce tip este prezent.

ASN.1 defineşte un mecanism complex de macrodefinire, care este folosit din plin în SNMP.O

macrodefiniţie poate fi folosită ca un fel de prototip pentru a genera o mulţime de tipuri şi valori

noi, fiecare cu sintaxa proprie. Fiecare macrodefiniţie defineşte câteva cuvinte cheie, care sunt

folosite în apel pentru a identifica parametrii(adică parametrii macrodefiniţiilor sunt identificaţi

prin cuvinte cheie, nu prin poziţie). O macrodefiniţie este apelată menţionând numele său,

urmat de (o parte din) cuvintele cheie şi valorile lor pentru respectivul apel.

11.3 SMI – Structura informaţiei de administrare

(Structure of Management Information)

RFC 1442 spune că ASN.1 va fi folosit pentru a descrie structurile de date ale SNMP apoi,

elimină unele definiţii şi defineşte patru macrodefiniţii importante şi opt noi tipuri de date care

sunt intens folosite în cadrul SNMP. Acesta este sub-super-setul ASN.1, care se numeşte

SMI(Structure of Management Information- structura informaţiei de administrare) care este

folosit pentru definirea structurilor de date din SNMP.


92

La ce mai de jos nivel, variabilele SNMP sunt definite ca obiecte individuale. Obiectele înrudite

sunt reunite în grupuri, iar grupurile sunt asamblate în module. De exemplu, există grupuri

pentru obiecte IP şi obiecte TCP. Un ruter poate suporta grupul IP dacă administratorul său

vrea să ţină evidenţa pachetelor pierdute. Pe de altă parte, un ruter ieftin poate să nu suporte

grupul TCP, din moment ce nu are nevoie să utilizeze TCP ca să realizeze funcţiile de dirijare.

Ideea este că toţi producătorii care suportă un grup să suporte toate obiectele din grupul

respectiv. Totuşi, un producător care suportă un modul nu trebuie să suporte toate grupurile

acestuia, deoarece este posibil ca unele să nu fie aplicabile echipamentului.

Toate modulele MIB încep cu un apel al macrodefiniţiei MODULE-IDENTITY. Parametrii săi

furnizează numele şi adresa celui care l-a implementat, istoricul reviziilor şi alte informaţii

administrative. De obicei acest apel este urmat de apelul macrodefiniţiei OBJECT-IDENTITY

care precizează unde este amplasat modulul în cadrul arborelui din Figura 12-48.

Urmează apoi unul sau mai multe apeluri ale macrodefiniţiei OBJECT-TYPE, care indică

variabilele administrate şi le specifică proprietăţile. Gruparea variabilelor în grupuri este făcută

prin convenţie; în ASN.1 sau SMI nu există instrucţiuni BEGIN-GROUP şi END-GROUP.

Macrodefiniţia OBJECT-TYPE are patru parametrii obligatorii şi patru parametrii opţionali.

Primul parametru obligatoriu este SYNTAX şi defineşte tipul variabilei, dintre cele listate în

Figura 12-49. În cea mai mare parte aceste tipuri sunt autoexplicate, cu comentariile următoare.

Sufixul 32 este folosit atunci când se doreşte un număr pe 32 de biţi, chiar dacă toate maşinile

considerate au unităţi centrale pe 64 de biţi. Tipurile Gauges diferă de counter prin aceea că

atunci când îşi ating limita superioară nu revin la valoarea minimă, ci rămân nemodificate. Dacă

un ruter a pierdut exact 232 pachete, este mult mai bine ca el să raporteze 232 –1 decât 0.

În afară de specificarea tipului de date folosit de variabila declarată, macrodefiniţia OBJECT

TYPE solicită încă trei parametrii. MAX-ACCESS conţine informaţii despre accesul la variabile.

Cele mai obişnuite valori sunt citire – scriere(read - write) şi doar-citire(read-only). Dacă o

variabilă are acces citire-scriere, atunci staţia de administrare o poate modifica. Dacă accesul

este doar-citire atunci staţia o poate citi dar nu o poate modifica.

STATUS poate avea trei valori. O variabilă current (actuală) respectă specificarea SNMP

curentă. O variabil obsolete(învechită) nu este în conformitate cu versiunea curentă ci cu una

mai veche. O variabilă deprecated(depăşită) are un statut între primele două.

Ultimul parametru obligatoriu este DESCRIPTION, care este un şir ASCII ce descrie rolul

variabilei. Dacă un administrator cumpără un echipament nou, îl interoghează de la staţia de

administrare şi află că acesta ţine evidenţa pktCnt (packet Count – număr de pachete ),

câmpul DESCRIPION ar trebui să-i dea o indicaţie despre tipul pachetelor numărate. Acest

câmp este destinat numai factorului uman, nicidecum calculatorului.


93

Nume Tip Octeţi Semnificaţie

INTEGER Numeric 4 Întreg (pe 32 de biţi în implementările obişnuite)

Counter32 Numeric 4 Contor fără semn pe 32 de biţi circular

Gauge32 Numeric 4 Întreg fără semn pe 32 de biţi, cu limitare

Uinteger Numeric 4 Întreg pe 32 de biţi chiar pe maşini pe 64 de biţi

Integer32 Numeric 4 Întreg ca şi Integer32,fără semn

Counter64 Numeric 8 Contor pe 64 de biţi

TimeTicks Numeric 4 Sutimi de secundă de la un anumit moment

BIT STRING String 4 De la 1 la 32 de biţi

OCTET STRING String >=0 Şir de octeţi de lungime variabilă

Opaque String >=0 Învechit; doar pentru compatibilitate

OBJECT

IDENTIFIER

String >0 O listă de întregi

IpAddress String 4 Adresă de Internet în notaţia zecimală cu

puncte

NsapAddress String <22 Adresă OSI NSAP

Figura 12-49 –Tipuri de date utilizate pentru variabilele monitorizate de SNMP

LostPackets OBJECT TYPE

SYNTAX Counter32 --foloseşte un contor pe 32 de biţi

MAX-ACCESS read-only –staţia de administrare nu o poate modifica

STATUS current --variabila nu este învechită

DESCRIPTION

‘‘Numărul de pachete pierdute de la ultima pornire’’

::={experimental 20}

Figura 12-50 – Un exemplu de variabilă SNMP


94

Variabila din exemplul 12-50 se numeşte lostPackets şi poate fi folosită de către un ruter sau

orice alt echipament care administrează pachete. Valoarea de după semnul ::= o plasează în

arbore.

11.4 MIB – Baza de informaţii de administrare (Management Information Base)

Colecţia de obiecte administrate de SNMP este definită în MIB. Pentru uşurinţă, aceste obiecte

sunt grupate (în mod obişnuit) în zece categorii, care corespund celor zece noduri de sub mib-2

din Figura 12-51 Cele zece categorii au menirea să ofere baza pentru ceea ce ar trebui să

înţeleagă o staţie de administrare. Cu certitudine în viitor vor fi adăugate noi categorii şi obiecte,

iar producătorii sunt liberi să definească obiecte în plus pentru produsele lor. Cele zece

categorii sunt prezentate în tabelul următor.

Grup

Număr

obiecte Descriere

sistem 7 Numele, amplasarea şi descrierea echipamentului

Interfeţe 23 Interfeţe de reţea şi traficul lor

AT 3 Traducerea adresei

IP 42 Statistici pentru pachete IP

ICMP 26 Statistici despre mesajele ICMP primite

TCP 19 Algoritmi, parametri şi statistici TCP

UDP 6 Statistici de trafic UDP

EGP 20 Statistici de trafic pentru protocoalede poartă exterioară

Transmisie 0 Rezervat pentru MIB-uri specifice mediului de transmisie

SNMP 29 Statistici de trafic SNMP

Figura 12-51 – Categorii MIB

Grupul sistem permite administratorului să afle denumirea echipamentului, cine l-a produs, ce

hardware şi software conţine, unde se află şi ce ar trebui să facă. De asemenea sunt furnizate

timpul ultimei porniri şi numele şi adresa persoanei de contact. Această informaţie permite ca o

companie să se poată angaja să administreze sistemul unei alte companii, care se află într-un

alt oraş şi îi permite celei din urmă să afle ce configuraţie are sistemul şi cu cine poate lua

legătura în cazul în care apar probleme cu diferite echipamente.


95

Grupul interfeţe se ocupă de adaptoarele de reţea. Memorează numărul de pachete şi de biţi

trimişi şi primiţi de pe reţea, numărul de pachete respise, numărul de transmisii şi dimensiunea

cozii de ieşire.

Grupul AT a fost prezent şi în MIB-I şi furniza informaţii despre corespondenţa dintre adrese(de

exemplu de la Ethernet la IP). În SNMPv2 această informaţie a fost mutată în MIB-uri specifice

protocoalelor.

Grupul IP se ocupă de traficul IP din şi spre nod. Este bogat în contoare care memorează

numărul de pachete respinse pentru o diversitate de motive(de exemplu traseu către destinaţie

necunoscut sau penurie de resurse). De asemenea sunt disponibile statici despre fragmentarea

şi reasamblarea datagramelor. Toate aceste elemente sunt deosebit de importante pentru

administrarea ruterelor.

Grupul ICMP se referă la mesajele de eroare IP. De fapt, are un contor pentru fiecare mesaj

ICMP, contor care înregistrează câte mesaje de acel tip au fost întâlnite.

Grupul TCP monitorizează umărul curent şi cumulat de conexiuni deschise, segmente trimise şi

primite, precum şi diferite statici referitoare la erori.

Grupul UDP ţine evidenţa numărului de datagrame UDP trimise şi primite şi către din ultima

categorie nu au fost livrate datorită unui port necunoscut sau din alt motiv.

Grupul EGP este folosit de ruterele care suportă protocolul de poartă exterioară. Ţine evidenţa

numărului de pachete de un anumit tip care au plecat, au venit şi au fost corect retransmise sau

au venit şi au fost eliminate.

Grupul transmisie este rezervat pentru MIB-uri specifice mediului de transmisie. De exemplu,

statisticile specifice Ethernet pot fi păstrate aici. Scopul includerii unui grup vid în cadrul MIB-II

este acela de a rezerva identificatorul{internet 2 1 9 } pentru astfel de scopuri.

Ultimul grup este cel care colectează statisticile despre funcţionarea SNMP-ului: câte mesaje au

fost transmise, de ce tip sunt acestea.

MIB-II este definit formal în cadrul RFC 1213. RFC 1213 constă din 175 de apeluri de

macrodefiniţii similare celor din figura 7.5, cu comentarii care delimitează cele zece grupuri.

Pentru fiecare dintre cele 175 de obiecte definite este furnizat tipul de date împreună cu un text

în limba engleză care descrie la ce este folosită variabila.

11.5 Protocolul SNMP

Protocolul pe care îl folosesc staţiile de administrare şi agenţii din modelul SNMP este denumit,

după numele modelului, protocolul SNMP. Acesta este definit în RFC 1448.


96

Mesaj Descriere

Get-request Solicită valoarea uneia sau a mai multor variabile

Get-next-request Solicită variabila care urmează după aceasta

Get-bulk-request Aduce o tabelă mare

Set+request Actualizează una sau mai multe variabile

Inform-request Mesaj de la administrator la administrator descriind MIB-ul local

SNMPv2-trap Raport agent-către-administrator referitor la capcană

Figura 12-52 - Tipurile de mesaje SNMP

Modul normal este acela în care staţia de administrare trimite către un agent o cerere prin care

solicită informaţii sau îi comandă să-şi actualizeze starea într-un anumit mod. În mod ideal

agentul întoarce informaţia cerută sau confirmă actualizarea stării. Datele sunt trimise folosind

sintaxa de transfer ASN.1. Totuşi pot fi raportate şi diferite erori, cum ar fi ‘‘nu există o

asemenea variabilă (No Such Variable)’’.

SNMP defineşte şapte mesaje care pot fi trimise. Cele şase mesaje provenite de la un iniţiator

sunt listate în Figura 12-52 (cel de-al şaptelea mesaj este mesajul răspuns). Primele trei solicită

să fie trimise valori de variabile. Prima formă numeşte explicit variabilele pe care le doreşte.

Cea de-a doua cere următoarea variabilă, permiţându-i administratorului să parcurgă MIB-ul în

ordine alfabetică(implicit este vorba de prima variabilă). Cea de-a treia formă este pentru

transferuri mari, ca de exemplu tabele.

Urmează un mesaj care permite administratorului să actualizeze variabilele unui agent,

bineînţeles în măsura în care specificaţia obiectului permite acest lucru. Următoarea este o

cerere de informaţie care îi permite unui administrator să îi comunice altuia ce variabile

administrează. Ultimul este mesajul trimis de către un agent unui administrator, atunci când

apare o capcană.


97

Termeni esențiali:

• Criptografia – criptanaliză, criptologie, principiul lui Kerckhoff, problema textului cifrat (ciphertext only problem), textului clar cunoscut (known plaintext problem), problema textului clar ales (chosen plaintext problem).

• Cifruri cu substituție – substituţie monoalfabetică (monoalphabetic substitution).

• Cifruri cu transpoziţie.

• Chei acoperitoare. Criptografia cuantică.

• Algoritmi cu cheie secretă – DES (Data Encryption Standard – Standard pentru Criptarea Datelor), Triplu DES, AES (Advanced Encryption Standard – Standard de Criptare Avansat), Rijndael.

• Algoritmi cu cheie publică – RSA (Rivest-Shamir-Adleman).

• Semnături digitale – semnături cu cheie simetrică, semnături cu cheie publică, DSS (Digital Signature Standard – Standard pentru Semnătură Digitală).

• Rezumate de mesaje – MD5 (Message Digest 5), SHA-1 (Secure Hash Algorithm 1).

• Gestionarea cheilor publice – certificate digitale, standardul X.509, PKI (Public Key Infrastructure – Infrastructură cu chei publice).

• Securitatea comunicației – IPsec, ziduri de protecție (firewall), VPN (Virtual Private Networks – Reţele private virtuale), securitatea în comunicațiile fără fir (securitatea 802.11, WEP (Wired Equivalent Privacy – Confidenţialitate Echivalentă cu cea Cablată)).

• Protocoale de autentificare – autentificare bazată pe cheie secretă partajată, schimbul de chei Diffie-Hellman, autentificarea folosind un Centru de Distribuţia Cheilor, autentificarea Kerberos, autentificarea folosind criptografia cu cheie publică.

• Confidențialitatea poștei electronice – PGP (Pretty Good Privacy – Confidenţialitate Destul de Bună), S/MIME (Secure/MIME – MIME Sigur), PEM (Privacy Enhanced Mail – Poştă cu Confidenţialitate Sporită).

• Securitatea Web-ului – DNS Spoofing – Păcălirea DNS, DNSsec – DNS sigur, nume cu aotu-certificare, SSL (Secure Sockets Layer – Nivelul soclurilor sigure), TLS (Transport Layer Security – Securitatea la nivelul transport).

• Securitatea codului mobil – securitatea applet-urilor Java, ActiveX, JavaScript, viruși.

• Modelul SNMP (Simple Network Management Protocol – Protocolul simplu de management al rețelei) – SMI (Structure of Management Information – Structura informaţiei de administrare), MIB (Management Information Base – Baza de informaţii de administrare), protocolul SNMP.


98

Bibliografie

1. Tanenbaum, A. , Wetherall D., Computer Networks (5rd Edition), Prentice Hall Software

Series, 2010.

2. Crainicu B., Reţele de calculatoare: pentru uzul studenţilor, Universitatea Petru Maior, 2005.

3. Peterson, L, Davie, B., Computer networks: A systems approach, Elsevier Publishing

Company; Morgan Kaufmann Publishers, Inc, 2007.

4. Kurose, J., Ross, K., Computer Networking: A Top-Down Approach (5th Edition), Addison-

Wesley, 2009

Reţele de Calculatoare -...

Documents

Transcript of Reţele de Calculatoare -...