Sec Flux Informational PDF

Capitolul 1
Infrastructur
a cu chei publice (P KI)
1.1
Prezentare general
a
Intr-un sistem de criptare cu cheie publica, cheia de criptare nu este secreta; deci este
necesara o autentificare a sa, pentru a-i garanta integritatea si a elimina o serie de atacuri,
cum ar fi man-in-the-middle.
Cheia publica a unui utilizator trebuie autentificata (semnata) de o autoritate de
certificare (CA). Rolul acesteia este de a garanta autenticitatea si integritatea unei chei
publice (unica) pentru fiecare utilizator. Dupa certificare, utilizatorul poate trimite cheia
sa publica oricarui alt utilizator, care i poate verifica autenticitatea.
Un certificat se poate elibera nu numai pentru autentificarea unei chei, ci n general
pentru orice bloc de identificare.
Definitia 1.1. Un bloc de identificare este o structur
a asociat
a unui utilizator.
Ea poate contine numarul serial al PC-ului, num
arul de telefon, num
arului retelei, num
arul
de certificare, data de expirare a certificatului, diverse autorizatii.
Certificatul este creat prin legarea cheii publice cu blocul de identificare. Atunci cand
doi utilizatori stabilesc ntre ei o comunicare, ei si trimit unul altuia certificatele, si fiecare
valideaza identitatea partenerului.
Ca mod de implementare. componentele cheii publice si blocul de identificare al unui
utilizator pot fi scrise pe un smartcard. Cu ajutorul acestuia, componentele pot fi transportate fizic (electronic) la o autoritate de certificare. Aceasta genereaza un certificat care
va fi ncarcat de asemenea pe smartcard.
Ulterior toate aceste componente sunt ncarcate pe calculator.
Obiectivele pe care trebuie sa le ndeplineasca un sistem atunci cand apeleaza la CA
sunt n mare:
Sa fie capabil sa estimeze scopul si valoarea certificatelor si a procesului de certificare;
1
CU CHEI PUBLICE (P KI)

CAPITOLUL 1. INFRASTRUCTURA
Sa nteleaga durata unui certificat si cum gestioneaza un P KI acest certificat pe

durata valabilitatii lui;
Sa fie capabil sa aleaga un serviciu de ncredere adecvat pentru eliberarea certificatului.
1.2
Formatul de certificat X.509
X.509 este cel raspandit format de certificat utilizat pentru o structura P KI. Poate fi
ntalnit n protocoale SSL, IP sec, S/M IM E, SET, P GP .
Standardul RF C 4325 listeaza urmatoarele zone cuprinse ntr-un certificat X.509 (Santesson & Housley, 2005):
Version: Versiunea certificatului.
Certificate serial number (maxim 20 octeti): ntreg pozitiv (unic) asignat de CA
fiecarui certificat.
Signature algorithm identifier: Identificatorul algoritmului folosit de CA pentru
semnatura digitala a certificatului. Algoritmul folosit este RSA sau DSA.
CA issuer name: Identifica autoritatea de certificare care a semnat si a eliberat
certificatul.
Validity period: Intervalul de timp n care CA asigura validitatea certificatului.
Campul respectiv este o seventa de doua date: data nceperii perioadei de validitate
si data expirarii validitatii certificatului.
Subject name: Identifica entitatea a carei cheie publica este autentificata.
Subject public-key information: Prezinta cheia publica mpreuna cu parametrii
publici asociati. Daca este necesar, este depus si identificatorul sistemului de criptare
utilizat (de exemplu: RSA, DSA, Dif f ie Hellman).
Issuer unique ID: Zona optionala alocata numelor CA aparute n CA Issuer
name (pentru o eventuala reutilizare).
Subject unique ID: Zona optionala care permite utilizarea ulterioara a numelor
din Subject name.
Extensions: Acest camp apare numai daca versiunea certificatelor este 3.
Extensiile pentru certificatele X.509 v3 ofera metode de asociere de atribute suplimentare referitoare la utilizatori si chei publice pentru gestionarea unei ierarhii de
certificare, cum ar fi CA Key Identifier si Subject Key Identifier.
1.3. VARIANTE DE CERTIFICARE
Informatia scrisa pe aceste campuri este semnata folosind cheia secreta a lui CA. Aceste
doua elemente (semnatura si continutul zonelor) sunt apoi
1. concatenate;
2. scrise cu ajutorul unui sistem de notatie sintactica numit Abstract Syntax One1 ;
3. transformate n date binare folosind sistemul de codificare DER (Distinguish Encoding Rules);
4. convertite n caractere ASCII folosind codificarea base64.
Observatia 1.1. DER este un sistem de codificare a c
arui sintax
a este specificat
a n
standardul X.690. Codificarea DER utilizat
a de X.509 este un standard international
rezultat din codificarea BER (Basic Encoding Rules). De fapt, DER difer
a de BER
doar prin faptul ca ignora optiunile expeditorului (care n cazul unor certificate nu sunt
necesare).
Scopul principal este oferirea unei codific
ari unice, asigur
and astfel CA c
a structura de
date pe care o semneaza va produce o reprezentare serial
a unic
a. Multe lucr
ari considera
DER ca o forma canonica pentru BER (numit
a de aceea si CAR Canonical Encoding
Rules).
De exemplu, n BER o valoare boolean
a de Adev
ar poate fi codificat
a n 255 moduri
diferite (n timp ce Fals este codificat prin valoarea 0), iar n DER exist
a un singur mod
de a codifica valoarea logica Adevar.
Pentru detalii privind ASN.1 si DER se poate folosi [5].
1.3
1.3.1
Variante de certificare
Certificare RSA
Pentru o astfel de certificare, autoritatea CA genereaza proprii sai parametri RSA:

pca , qca , P rivca (exponentul de criptare) si P ubca (exponentul de decriptare).
CA face publice valorile P ubca si Nca (unde Nca = pca qca ) pentru toti utilizatorii din
retea.
Daca notam l() lungimea secventei binare , va trebui ca pentru orice utilizator X
din retea,
l(Nca ) > l(IDX ) + l(P ubX )
CA autentifica cheia publica P ubA si identificatorul IDA ale lui Alice, generand certificatul public
1
Abstract Syntax Notation One (ASN.1) este un standard si o notatie definita prin reguli formale,
utilizata n retelele de calculatoare si n telecomunicatii. Descrie structuri de date utilizate pentru
reprezentarea, codificarea, transmiterea si n final decodificarea datelor.

CA = (IDA , P ubA , (IDA kP ubA )P rivca (mod Nca ))
(1)
La primirea certificatului, Alice l verifica calculand

IDA kP ubA = (IDA kP ubA )P ubca (mod Nca )
(2)
Cand Alice doreste sa stabileasca o comunicare securizata cu alt utilizator din retea,
ea i va trimite acestuia certificatul CA ; destinatarul Bob avand acces la P ubca si Nca
va determina IDA kP ubA calculand (2), dupa care va compara rezultatul cu primele doua
valori concatenate din CA .
Aceasta varianta asigura autenticitatea si integritatea cheii publice. Daca vrem sa
avem si confidentialitate, se renunta la primele doua componente ale certificatului. In
acest caz nsa trebuie sa existe o modalitate clara care sa separe IDA de P ubA din secventa
binara concatenata.
1.3.2
Certificare Cylink (SEEK)
Protocolul de certificare a fost prezentat n 1987 ([2]).

Fie a un numar aleator si p un numar prim tare (p = 2q + 1 cu q prim).
Autoritatea de certificare CA genereaza propriile sale chei P ubca , P rivca , n conformitate cu protocolul Diffie - Hellman:
P ubca = aP rivca (mod p)
CA autentifica cheia publica si ID lui Alice calculand certificatul dupa algoritmul:
A
1. Calculeaza MA = P ubID
(mod p)
A
2. Genereaza aleator RA si calculeaza CcaA = aRA (mod p)

3. Calculeaza VA din ecuatia MA = [P rivca CcaA + RA VA ] (mod (p 1))
4. Trimite lui Alice certificatul CA = (CcaA , VA ).
Alice verifica faptul ca certificatul a fost eliberat de autoritatea CA folosind algoritmul:
A
1. Calculeaza MA = P ubID
(mod p)
A

VA
caA
2. Calculeaza SA = P ubC
(mod p) CcaA
(mod p) (mod p)
ca
3. Daca SA = aMA , atunci certificatul CA este valid.
1.3. VARIANTE DE CERTIFICARE
Cand Alice doreste sa stabileasca o sesiune de comunicare cu Bob, i trimite quadruplul

(CcaA , P ubA , VA , MA )
Cum ambele parti dispun de a, p si P ubca , Bob poate autentifica certificatul lui Alice
calculand

VA
caA
SB = P ubC
mod
p
C
mod
p
(mod p)
caA
ca
si verificand congruenta aMA SB (mod p).
De remarcat ca prin acest protocol, Bob nu poate deduce identificatorul lui Alice.
1.3.3
Certificare CyLink bazat

a pe algoritmul ElGamal
Intr-o astfel de certificare, valorile a si p sunt comune tututor utilizatorilor si autoritatii

de certificare. a este un numar generat aleator, iar p este un numar prim tare.
CA genereaza perechea de chei (P ubca , P rivca ) care verifica relatia
P ubca = aP rivca (mod p)
La solicitarea lui Alice de a obtine un certificat pentru mesajul MA , unitatea de certificare:
1. Genereaza aleator un numar secret RcaA
2. Calculeaza valoarea publica VcaA = aRcaA (mod p);
3. Aplica o functie de dispersie criptografica: HcaA = h(MA , VcaA );
4. Calculeaza semnatura sa digitala
ScaA = (RcaA + HcaA P rivca ) (mod p)
5. Trimite lui Alice tripletul (ScaA , HcaA , VcaA ).
La primire, Alice verifica certificatul pe baza relatiei
caA
aScaA VcaA P ubH
(mod p)
A
Recapituland: daca Alice si Bob doresc sa stabileasca un contact bazat pe un certificat

eliberat de CA:
Informatiile detinute de
Alice : P rivA , P ubA , MA , ScaA , VcaA , P ubca , h
Bob : P rivB , P ubB , MB , ScaB , VcaB , P ubca , h

Amandoi schimba simultan ntre ei urmatoarele informatii:

Alice Bob : P ubA , MA , ScaA , VcaA
Bob Alice : P ubB , MB , ScaB , VcaB
Fiecare stabileste autenticitatea certificatului celuilalt calculand si verificand:
caB
Alice : HcaB = h(MB , VcaB ), aScaB VcaB P ubH
(mod p)
B
HcaA
ScaA
Bob : HcaA = h(MA , VcaA ), a
VcaA P ubA (mod p)
Daca congruentele sunt verificate de ambele parti, atunci Alice si Bob stiu ca certificatele
sunt eliberate de autoritatea de certificare CA, iar partenerii sunt autentificati.
1.3.4
Variant
a a protocolului de certificare ElGamal
Diferenta fata de varianta anterioara consta n modul de calcul al semnaturii S si n tipul

de verificare al semnaturii.
Fie p un numar prim cu proprietatea ca p 1 are cel putin un factor prim mare; fie g
un generator al lui Zp .
Autoritatea de certificare CA genereaza perechea de chei (P ubca , P rivca ) care verifica
relatia
P ubca = g P rivca (mod p)
Pentru a instala certificatul generat de CA pentru computerul lui Alice, se genereaza
ntai un identificator IDA (acesta poate consta din IP calculatorului, CN P lui Alice,
numarul ei de telefon etc).
La solicitarea lui Alice de a obtine un certificat, unitatea de certificare:
1. Genereaza aleator un numar secret RcaA ;
2. Calculeaza valoarea publica VcaA = g RcaA (mod p);
3. Aplica o functie de dispersie criptografica: HcaA = h(IDA , P ubA , VcaA );
4. Calculeaza semnatura sa digitala
ScaA = (RcaA HcaA + VcaA P rivca ) (mod (p 1))
5. Trimite lui Alice perechea (ScaA , VcaA ).
Deci, daca Alice si Bob doresc sa stabileasca un contact bazat pe un certificat eliberat
de CA:
Informatiile detinute de
1.4. MANAGEMENTUL UNUI P KI
Alice : P rivA , P ubA , IDA , ScaA , VcaA , P ubca , h

Bob : P rivB , P ubB , IDB , ScaB , VcaB , P ubca , h
Amandoi schimba simultan ntre ei urmatoarele informatii:
Alice Bob : IDA , P ubA , ScaA , VcaA
Bob Alice : IDB , P ubB , ScaB , VcaB
Fiecare stabileste autenticitatea certificatului celuilalt calculand si verificand:
Alice : HcaB = h(IDB , P ubB , VcaB ), g ScaB (VcaB )HcaB (P ubca )VcaB (mod p)
Bob : HcaA = h(IDA , P ubA , VcaA ), g ScaA (VcaA )HcaA (P ubca )HcaA (mod p)
Daca congruentele sunt verificate de ambele parti, atunci Alice si Bob stiu ca certificatele
sunt eliberate de autoritatea de certificare CA, iar partenerii sunt autentificati.
Observatia 1.2. Consistenta congruentei de verificare este bazat
a pe secventa de calcule
(efectuate modulo p) pentru un utilizator X:
g ScaX = g (RcaX HX +VcaX P rivca ) (mod (p1)) (mod p)
Deoarece g x mod (p1) g x (mod p), vom avea n continuare:

g ScaX = g RcaX HX g VcaX P rivca = g RcaX
HX
g P rivca
VcaX
= (VcaX )HX (P ubca )VcaX .
Aceasta varianta de certificare este mai robusta decat versiunea anterioara, deoarece:
Factorul VcaX este inclus atat la baza cat si ca exponent;
Cheia publica a autoritatii apare explicit n procedura de verificare.
1.4
Managementul unui P KI
In general, o infrastructura cu chei publice asigura urmatoarele servicii:

Urmareste perioada de valabilitate a cheii si certifica acest lucru;
Pentru o cheie certificata, asigura servicii de back-up si recovery;
Up-dateaza automat perechile de chei si certificatele lor;
Gestioneaza un istoric al cheilor certificate;
Este capabila sa efectueze certificari ncrucisate.
Conform standardului RF C 4210, sunt 4 entitati implicate n managementul unui
P KI:
1. Utilizatorul P KI, numit si end-entity sau end-user: entitatea nominalizata n campul
Subject name a unui certificat;

2. Autoritatea de certificare CA: entitatea nominalizata n campul Issuer name a

unui certificat;
3. O autoritate de nregistrare RA (componenta optionala a unui P KI);
4. Un site RS unde sunt depuse toate certificatele (repository site).
1.4.1
Utilizatorii P KI
Un utilizator P KI (End-Entity) este un beneficiar al unui certificat P KI. El poate fi o

persoana, un computer, o aplicatie (de exemplu pentru securitatea IP ).
Utilizatorul are nevoie de un acces local sigur la anumita informatie (cel putin la
propriul nume, la cheia sa privata, la numele unui CA n care are ncredere, precum si la
cheia publica a acestui CA).
Conform cu RF C 3647, un utilizator P KI are urmatoarele obligatii:
Sa asigure o reprezentare corecta a datelor sale n cadrul certificatului;
Sa asigure protectie cheii sale private;
Sa introduca restrictii de acces la cheia sa privata si la utilizarea certificatului;
Sa notifice orice compromitere a cheii sale private.
Procesul de nregistrare si autentificare are loc dupa schema urmatoare:
3
CA/RA
RS
2
?
Alice
5
Mesaj criptat 4
Semnatura digitala
6
?
Bob
7
1. Alice se nregistreaza la autoritatea de certificare CA si aplica pentru obtinerea unui

certificat;
2. CA verifica identitatea lui Alice si elibereaza un certificat;
3. CA publica certificatul pe un site dedicat RS (Repository Site);
4. Alice trimite lui Bob mesajul sau criptat mpreuna cu certificatul. Mesajul este
semnat cu cheia privata a lui Alice (se asigura astfel autenticitatea si integritatea
mesajului, precum si non-repudierea);
5. Dupa primirea mesajului, Bob acceseaza RS si verifica autenticitatea certificatului

lui Alice;
6. Site-ul da lui Bob starea actuala a certificatului lui Alice;
7. Bob verifica integritatea mesajului folosind cheia publica a lui Alice.
1.4.2
Autoritatea de certificare
Intr-un sistem cu cheie publica, secretul acestei chei nu este obligatoriu; este nsa necesara
o autentificare a cheii publice, pentru a garanta integritatea si autenticitatea ei.
Identitatea si cheia publica a unui utilizator P KI este autentificata (semnata) de o
autoritate de certificare.
Termenul CA se refera la entitatea scrisa n zona Issuer name a unui certificat. Un
CA poate emite diverse tipuri de certificate, cum ar fi: certificat pentru un utilizator,
pentru alt CA (CA - certificat), sau cross - certificat (un proces de autentificare trecand
prin diverse domenii de securitate).
Un domeniu de securitate este un domeniu logic n care un CA emite si gestioneaza
certificate.
In general, un utilizator P KI este certificat de un CA, iar un CA este certificat de
alt CA. Se construieste astfel o retea arborescenta de certificare, care are ca radacina un
root - CA.
Nu este obligatoriu ca o unitate de certificare sa fie a treia parte; frecvent, CA
apartine aceleiasi organizatii ca si utilizatorul pe care l certifica.
1.4.3
Contactele dintre utilizator si unitatea de certificare
Contactele dintre un utilizator si CA sunt legate exclusiv de operatia de certificare. Ele

apar n doua situatii: cand este solicitat un certificat (initializare) si la eliberarea unui
certificat.
Initializarea
Alice solicita un certificat de la CA sau RA. Rezultatul actiunii este eliberarea unui
certificat pentru o cheie publica a lui Alice, care este trmis lui Alice si/sau publicat pe
un repository site.
Componentele unei faze de initializare sunt:
1. Inregistrare: CA (sau RA) stabileste si verifica identitatea lui Alice ca solicitator
de certificat.
2. Generarea cheilor: Este generata perechea (cheie public
a, cheie privat
a). Generarea poate fi efectuata de Alice, CA, RA sau chiar o a treia parte de ncredere
10

(T T P ). Daca cheia generata este folosita la o actiune de non-repudiere, atunci ea

este generata obligatoriu de Alice.
3. Crearea certificatului: CA genereaza un certificat asociat cheii construite anterior. Numai CA poate construi un astfel de certificat.
4. Distributia certificatului si cheii publice: CA trimite lui Alice certificatul si
perechea de chei (daca acestea nu au fost generate de Alice).
5. Diseminarea certificatului: CA trimite certificatul lui Alice si la un RS.
6. P
astrarea cheii: Optional, CA poate trimite cheia (pentru backup) unui T T P .
Recuperarea si actualizarea cheii
Daca Alice pierde cheia sa privata, sau mediul n care aceasta este stocata a fost corupt,
este nevoie de o recuperare a cheii, deci de un nou contact ntre utilizator si unitatea de
certificare.
O cheie publica este folosita:
pentru criptare (chei de criptare);
pentru semnare de mesaje si verificarea de certificate (chei de semn
atur
a).
Procesul de recuperare a cheii este utilizat numai pentru cheile de criptare; aici, organismul abilitat va recalcula cheia privata.
Acest proces nu poate fi similar pentru cheile de semnatura, deoarece va ncalca proprietatea de non-repudiere a cheii (Alice este singura entitate care controleaza cheia privata).
Singurul remediu n acest caz este generarea unei noi perechi de chei.
Procesul de actualizare a cheii se refera la o updatare periodica a unei perechi de chei
cand aceasta este nlocuita cu o noua pereche de chei, nsotita de un nou certificat.
Rennoirea si actualizarea unui certificat
Un certificat este eliberat pentru o perioada strict determinata de timp. Dupa expirare,
el trebuie rennoit sau actualizat.
Rennoire nseamna eliberarea unui nou certificat, pentru aceeasi cheie si aceleasi date
de identificare ale utilizatorului.
Actualizare nseamna eliberarea unui certificat pentru o noua pereche de chei si/sau o
modificare de date de identificare ale lui Alice.
11
Cererea de revocare a unui certificat

Este un proces de invalidare a unui certificat nainte de expirarea sa. Aceasta actiune este
initiata de o persoana autorizata, care atentioneaza CA asupra unei situatii anormale,
care impune revocarea certificatului.
Deoarece prezenta unui certificat nu mentioneaza daca acesta este revocat sau nu,
apare necesitatea de a pastra ntr-o zona sigura, dar accesibila oricui o lista cu toate
certificatele revocate.
Contacte ntre unitatea de certificare si RS (repository site)
Sunt doua tipuri de contacte: cel legat de diseminarea certificatelor si cel referitor la
lista de revocare. Odata cu eliberarea sau revocarea unui certificat, CA este obligata sa
trans,ita aceasta informatie spre RS, pentru publicarea sa.
La crearea unui certificat, RS l publica conform unui protocol special LDAP (Light
Weight Directory Access Protocol) mentionat n standardul RF C 4510 19.
Cererea de revocare a unui certificat poate apare cand cheia privata a lui Alice este
compromisa sau cand Alice nu mai face parte din domeniul de securitate al CA (de
exemplu cand ea paraseste organizatia). Revocarea este inclusa de CA n CRL (Certificate
Revocation List) si diseminata cu ajutorul RS.
1.4.4
Contacte ntre unitatea de certificare si cea de nregistrare
RA poate avea diferite functii; doua sunt nsa obligatorii:

In prima faza RA este un tampon ntre utilizator si unitatea de certificare.
Astfel, Alice trimite spre RA cererea de nregistrare. RA verifica datele de identificare ale lui Alice, dupa care daca acestea sunt corecte trimite aceasta cerere
spre CA. CA raspunde cu rezultatele nregistrarii, rezultate pe care RA le retrimite
spre Alice. Pe baza acestor rezultate, Alice trimite ulterior spre CA o cerere de
certificare.
RA publica certificatele eliberate de CA (informatie primita de la CA).
1.4.5
Contacte ntre utilizator si RS
Intre cele doua entitati au loc doua tipuri de contacte:

G
asirea certificatului: Alice contacteaza RA pentru aflarea certificatului lui Bob,
care i este necesar pentru:
Gasirea cheii publice a lui Bob pentru a cripta un mesaj adresat acestuia.
Verificarea unei semnaturi digitale primite de la Bob.

12
Validarea certificatului: Dupa ce Alice a gasit certificatul lui Bob, ea trebuie sa

l valideze. Validarea unui certificat include urmatoarele verificari:
Certificatul a fost eliberat de un CA de ncredere (se verifica autenticitatea).
Certificatul nu a fost modificat (se verifica integritatea).
Certificatul nu a expirat.
Certificatul nu a fost revocat (se verifica CRL).
1.4.6
Contacte ntre dou

a autorit
ati de certificare
Este posibil ca cei doi utilizaotri care doresc sa intre n contact sa aiba certificatele eliberate de autoritati distincte. Astfel, Alice are certificatul eliberat de CA1 , iar certificatul
lui Bob este eliberat de CA2 . Fiecare din ei are ncredere numai n autoritatea care i-a
eliberat certificatul. In plus, chiar daca unul din ei doreste sa l certifice pe celalalt, acest
lucru nu ar fi posibil deoarece domeniile de certificare sunt diferite.
Mecanismul folosit pentru a rezolva acest impediment este numit certificare ncrucisat
a: CA1 l certifica pe CA2 , extinzand ncrederea lui Alice si asupra certificatelor emise
de CA2 (n particular, al lui Bob).
Procesul poate fi rafinat, n sensul ca domeniul lui CA1 se poate extinde asupra tuturor
certificatelor emise de CA2 sau doar pentru anumite certificate (care apartin unei singure
organizatii, care sunt ntr-un anumit grup etc).
1.5
Formatul unei liste de revocare
Standardul RF C 4325 (Internet X.509 Public Key Infrastructure Certificate and Revocation List (CRL) Profile) descrie detaliat formatul si semantica unei liste de revocare
pentru P KI.
In formatul X.509, un CA emite periodic o structura semnata numita CRL (Certificate
Revocation List). In esenta, un CRL este o lista cu stampila de timp, emisa si semnata
de un CA si facuta publica printr-un site RS.
Fiecare certificat revocat este identificat prin numarul sau serial. Cand se verifica un
certificat, nafara de semnatura si perioada sa de valabilitate, se acceseaza si CRL-ul
curent, verificand daca aici este mentionat numarul serial al certificatului.
De mentionat ca numai CA-ul care emite un certificat poate sa l revoce. Din acest
motiv, datele cu care lucreaza o unitate de certificare (algoritmul de semnatura, cheile
etc) trebuie securizate prin protocoale suplimentare (deoarece compromiterea unui CA
conduce automat la revocarea tuturor certificatelor emise de acesta).
Componentele unei liste de revocare sunt:
Versiune: X.509 admite n prezent doua versiuni. Pentru aceasta componenta este
rezervata locatie numai daca se lucreaza cu versiunea 2.
1.6. MODELE DE INCREDERE
13
Semn
atur
a: contine ID-ul algoritmului folosit de CA pentru a semna CRL-ul.
Nume emitent: Identifica CA-ul care emite si semneaza CRL-ul.
Actualizare: Indica data emiterii. Informatia se poate codifica n doua moduri:
U T CT ime2 sau Timp generalizat3 .
Urm
atoarea actualizare: Indica data emiterii urmatorului CRL. Acesta poate
apare nainte de data indicata, dar n nici un caz nu va apare ulterior datei.
Certificatele revocate: Listeaza numerele seriale ale certificatelor revocate n
intervalul dintre aparitia CRL-ului anterior si cel actual. Pentru fiecare certificat
trebuie mentionata si data revocarii.
Daca nu exista certificate revocate, aceasta locatie trebuie sa lipseasca.
In faza urmatoare, locatiile care contin aceste componente ale CRL-ului sunt:
1. concatenate;
2. scrise n format standard bazat pe Abstract Syntax One ([4]);
3. convertite n binar folosind sistemul de codificare DER (Distinguish Encoding Rules)
(pentru detalii a se vedea [6]);
4. transformate n caractere ASCII cu ajutorul codificarii base64.
1.6
Modele de ncredere
Autortatile de certificare actioneaza ca agenti de ncredere pentru validarea identitatii si

a cheilor publice a utilizatorilor. Acest concept este numit a treia parte de ncredere
(T T P thirst-third party): un utilizator are ncredere ntr-un certificat emis de un CA
cat timp el are ncredere n CA-ul respectiv.
Altfel spus, Alice are ncredere n Bob nseamna de fapt Alice are ncredere n CA-ul
care semneaza certificatul lui Bob.
Aici apar diverse dificultati, cum ar fi:
Alice si Bob vor sa intre n legatura, dar certificatele lor sunt emise de AC-uri cu
domenii de securitate distincte.
Pentru a-si legitima ncrederea, un CA trebuie sa fie certificat la randul sau de alt
CA.
2
Coordinated Universal Time: un compromis ntre timpul dat de meridianul 0 (numit Timp Universal)
si timpul fizic determinat cu cea mai mare precizie (Timpul Atomic International - T AI); a se vedea
http://ro.wikipedia.org/wiki/Ora universal
a coordonat
a.
3
Reprezentare sub forma standard Y Y Y Y M M DDHHM M SS.

14
Din aceste motive, apar diverse structuri formate din mai multe autoritati de certificare;
aceste structuri se numesc modele de ncredere. In prezent sunt utilizate mai multe
tipuri de modele de ncredere: ierarhice, mesh, Web, si centrate pe utilizator.
1.6.1
Model de ncredere ierarhic
Intr-un astfel de model exista o autoritate de certificare (Root CA) considerata apriori
sigura; celelalte CA-uri sunt organizate ntr-o structura arborescenta ale carei noduri
terminale sunt utilizatorii (entitati care nu sunt abilitate sa emita certificate).
Toate entitatile au ncredere n root CA. Inafara de el, fiecare entitate dispune de (cel
putin) un certificat eliberat de un CA situat pe drumul (unic) de la el spre root CA.
Avantajul acestui model este simplitatea sa si usurinta de implementare. Dezavantajul
este acela ca nu permite certificari ncrucisate ntre CA-uri diferite.
Un exemplu de model ierarhic este:
CA
Root
CA1
N ivel 1
CA2
N ivel 2
Utilizator A
Utilizator B
CA4
N ivel 1
CA3
N ivel 2
Utilizator C
Utilizator D
Utilizator F
Utilizator E
Certificatul lui A este emis de CA2 , iar al lui F este emis de CA4 . Daca cei doi vor
sa stabileasca o legatura, iar A (de exemplu) nu are ncredere n CA4 , el va trebui sa
gaseasca alt CA n care sa aiba ncredere. Singurul care poate fi folosit aici este Root CA.
Daca contactul trebuie facut ntre utilizatorii A si D, ei pot folosi ca autoritate de
certificare comuna pe CA1 .
1.6.2
Model de ncredere mesh
Este un model de ncredere bazat pe structura ierarhica, care faciliteaza certificarile

ncrucisate.
Daca sunt mai multe structuri ierarhice, toate autoritatile de certificare aflate pe
pozitia de radacina se autorizeaza reciproc prin certificare ncrucisata. Aceasta interautorizare are loc nainte de nceperea emiterii de certificate catre alte entitati.
1.7. ALGORITMI DE CRIPTARE ACCEPTAT

I IN P KI
1.6.3
15
Model de ncredere Web
Pentru un numar mare de utilizatori, modelul de ncredere cel mai utilizat este cel de tip
lista, numit si Web model.
Fiecare browser Internet actioneaza ca un Root CA virtual, deoarece utilizatorii au
ncredere n CA-ul instalat n softul browserului. Browserele sunt distribuite mpreuna cu
un set initial de certificate; la acestea utilizatorii pot adauga certificate noi sau pot elimina
certificate. Browserele pot utiliza certificatele pre-instalate pentru a semna, verifica, cripta
sau decripta mesajele de e-mail scrise n S/M IM E si de a stabili sesiuni T LS sau SSL.
De asemenea, ele sunt abilitate sa verifice semnaturile n cazul codurilor semnate.
Pentru un utilizator obisnuit, gestionarea numeroaselor certificate instalate n browserconstituie o problema extrem de dificila4 ; mai mult, nu exista nici o modalitate practica
de a preveni o modificare neautorizata (din partea utilizatorilor sau celor care au acces la
statiile de lucru) a listei de certificate.
In acest tip de model de ncredere nu exista o modalitate practica de a revoca certificate. Astfel, daca Firefox sau Microsoft (cei doi lideri actuali pe piata browserelor
Internet) instaleaza din greseala un CA care nu este de ncredere, nu exista nici o modalitate de a-i revoca certificatul din milioanele browsere aflate n uz.
1.6.4
Model de ncredere centrat pe utilizator
Protocolul de posta electronica P GP foloseste un model de ncredere centrat pe utilizator

(User Centric Model). Orice utilizator P GP poate actiona ca o autoritate de certificare
si sa valideze certificatul cheii publice a altui utilizator P GP .
Totusi, un certificat eliberat de Alice care actioneaza ca un CA poate sa nu fie
valid pentru alt utilizator, pentru ca acesta stie ca Alice nu este de ncredere ca autoritate
de certificare. Fiecare utilizator este direct responsabil n a decide ce certificate accepta
si ce certificate respinge.
1.7
Algoritmi de criptare acceptati n P KI
Standardul RF C 4210 stabileste algoritmii criptografici, functiile de dispersie si semnaturile

digitale care pot fi folosite pentru a semna certificatele si listele de revocare.
1. Algoritmii de semn
atur
a:
Certificatele si listele de revocare pot fi semnate teoretic cu orice protocol de semnatura cu cheie publica. Algoritmul folosit este totdeauna nsotit de o functie de
dispersie criptografica. Aceasta produce o amprenta a datelor care trebuie semnate.
4
De exemplu, browserele Firefox si Microsoft Explorer sunt distribuite mpreuna cu aproximativ 100
chei publice pre-instalate, fiecare cheie fiind nsotita de un certificat.

16
Amprenta este apoi formatata corespunzator algoritmului de semnatura care va fi

folosit.
Dupa generarea semnaturii, valoarea obtinuta este codificata cu ASN.1 sub forma
unui sir de biti si inclusa n certificat.
Algoritmi recomandati: DSA/SHA1.
Alti algoritmi: HM AC/SHA1, RSA/M D5, ECDSA/ECDH
2. Algoritmi de criptare:
(a) Algoritmi cu cheie public
a: Utilizati pentru criptarea cheilor privatre transportate de mesajele P KI.
Algoritm recomandat: Diffie - Hellman5 .
Alti algoritmi: RSA, ECDH.
(b) Algoritmi simetrici:
Pot fi utilizati daca cheia de criptare a fost transmisa prin canal securizat.
Algoritm recomandat: 3DES (n mod CBC)
Alti algoritmi: RC5, Cast 128.
Aloritmul de criptare Diffie - Hellman acceptat de X.509 este definit n ANSI X.9.42, publicat n
2003.
Bibliografie
[1] M. Mogollon - Cryptography and Security Services: Mechanisms and Applications,
Cybertech Publishing, 2007.
[2] D.B. Newman, J.K. Omura, R.L. Pickholtz - Public key management for network
security IEEE Network Magazine, 1(2), 1987, pp. 12-13
[3] Simmons, G. J. - Contemporary Cryptology, IEEE Press, 1992.
[4]
http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One
[5]
http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
[6] http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
17
Capitolul 2
Servicii terte de ncredere (T T P )
2.1
2.1.1
Cerinte ale serviciilor terte de ncredere

Notiuni introductive
Schimbul de informatie electronica ntre doua entitati implica prezenta unui element de
ncredere care sa asigure unele servicii, cum ar fi autenticitatea acelor entitati. Mai mult,
uneori nivelul de ncredere asteptat de entitati nu se poate obtine decat cu ajutorul unei
parti terte, care sa faciliteze schimbul de informatie.
Definitia 2.1. (X509) O entitate are ncredere n alta c
and are siguranta c
a partenerul
se va comporta exact conform astept
arilor sale.
Un tert de ncredere (T T P - Trusted Third Party) este o entitate specific
a care furnizeaz
a unul sau mai multe servicii electronice si este considerat
a de ncredere de c
atre
celelalte entitati.
Exemplul 2.1. Exemple de servicii furnizate prin intermediul tertilor de ncredere: servicii de marcare temporala, servicii de arhivare electronic
a, servicii de administrare a
cheilor si certificatelor de chei, servicii suport pentru identificare, autentificare si nonrepudiere, servicii de acordare de privilegii, servicii de notariat public electronic, servicii
de directoare etc.
Conform recomandarilor ISO 14516, un tert de ncredere trebuie:
sa ofere servicii clar definite;
sa respecte politici bine definite de utilizare si de securitate, care sunt facute public;
sa opereze ntr-un cadru perfect legal n ceea ce priveste serviciile pe care le ofera si
entitatile carora se adreseaza;
sa opereze n conformitate cu standardele nationale si internationale n vigoare;
1
CAPITOLUL 2. SERVICII TERT

E DE INCREDERE (T T P )
sa fie independent si impartial pe timpul functionarii;

sa urmareasca cel mai bun cod de practici si proceduri acceptat, pe care l face
public;
sa nregistreze si sa arhiveze toate elementele de evidenta relevante pentru tipul de
servicii oferite, astfel ncat ulterior sa se poata face auditarea;
sa permita arbitrarea independenta, fara a compromite securitatea serviciilor oferite
sau a entitatilor sale client;
sa-si asume responsabilitatea si raspunderea n niste limite definite pentru disponibilitatea si calitatea serviciilor sale.
Un T T P poate furniza unul sau mai multe servicii. El trebuie nsa sa asigure faptul ca
serviciile pe care le ofera sunt n concordanta cu politicile definite si publicate de acesta.
In functie de arhitectura furnizorului de servicii de ncredere, pot exista cerinte aditionale
si de securitate care trebuie avute n vedere la administrarea si operarea sa.
2.1.2
Cerinte asupra tertilor de ncredere
In general, cerintele formulate asupra unui tert de ncredere difera n functie de serviciile
furnizate.
Pentru a castiga ncrederea partilor interesate, un T T P trebuie sa demonstreze ca
(ISO 14516):
exista si aplica o politica de securitate potrivita;
problemele de securitate sunt rezolvate printr-o combinatie de mecanisme si proceduri de securitate corect implementate;
operatiile sunt realizate corect si n stransa legatura cu un set de roluri si responsabilitati clar definite;
procedurile si interfetele de comunicare cu entitatile sunt potrivite cu scopul lor si
sunt aplicate corect;
regulile si regulamentele sunt corect aplicate si sunt consistente cu nivelul de ncredere dorit;
calitatile operatiilor si practicilor de lucru au fost corect acreditate;
respecta obligatiile contractuale n raport cu utilizatorii sai;
exista o ntelegere si acceptare clara a responsabilitatilor;
2.1. CERINT
E ALE SERVICIILOR TERT
E DE INCREDERE
compatibilitatea cu legile si regulamentele este mentinuta si auditata;

amenintarile cunoscute si masurile de contracarare a acestora sunt clar identificate;
sunt ndeplinite cerintele organizationale si de personal;
credibilitatea sa poate fi verificata;
este monitorizat permanent de o autoritate administrativa care i supervizeaza activitatea.
Cerinte functionale
D. Lekkas s.a. au realizat ([11]) un studiu privind o serie de proiecte de securitate derulate
la nivel european, toate bazate pe utilizarea T T P -urilor. Aici s-au identificat o serie de
cerinte functionale care pot fi definite la nivelul unui T T P :
1. Autentificarea: Identificarea corecta a entitatilor implicate n tranzactiile electronice.
Se obtine n general utilizand mecanisme de criptografie cu chei publice si semnatura
electronica. Stocarea cheilor private de autentificare se face de obicei: pentru utilizatori pe smartcarduri dedicate, iar pentru serviciile furnizate de T T P -uri pe dispozitive speciale de tip HSM (Hardware Secure Module).
2. Integritatea datelor: Pastrarea lor nealterata pe timpul comunicarii ntre entitati.
Alterarea datelor poate fi accidentala sau intentionata. Integritatea se poate realiza
utilizand mecanisme de semnatura electronica sau functii de dispersie.
3. Confidentialitatea: Criptarea mesajelor schimbate ntre entitati n cadrul tranzactiilor electronice constituie o cerinta de baza. Se obtine utilizand n general algoritmi
de criptare cu chei simetrice, iar n unele situatii mecanisme de criptare asimetrica.
4. Non-repudierea: O entitate nu poate nega o actiune (cum ar fi expedierea sau
receptionarea unui mesaj) sau existenta unor informatii la un moment dat.
Aceasta cerinta poate fi asigurata cu tehnici de semnatura digitala (non-repudierea
originii mesajelor) sau de marcare temporala (existenta datelor la un anumit moment).
5. Disponibilitatea: Este de asemenea una din cerintele fundamentale ale unui T T P .
Ea este corelata cu politica T T P -ului si SLA-ului (Service Level Agreament) acceptat.
Disponibilitatea poate fi asigurata prin mecanisme specifice de HA (High - Availability) avand la baza redundanta echipamentelor si mecanisme de DR (Disaster Recovery).

6. Usurinta de utilizare: Interfata sistemului cu utilizatorii constituie o cerinta

importanta n conditiile n care interactioneaza n mod direct cu acestia. Unele
servicii oferite de T T P nu interactioneaza n mod direct cu utilizatorii, ci prin
intermediul unor aplicatii care implementeaza protocoale specifice.
7. Mobilitatea: Necesara n unele situatii pentru utilizatorii mobili. Acestia
trebuie sa poata contacta un anumit T T P indiferent de localizarea lor n raport cu
acesta.
8. Anonimitatea: O entitate poate fi nregistrata la un T T P , nsa (n functie de
optiunile sale) identitatea sa trebuie sa nu fie dezvaluita celorlaltor utilizatori.
9. Marcarea temporal
a: Marcile temporale sigure (de ncredere) atasate documentelor electronice sunt necesare n anumite tranzactii desfasurate ntre entitati.
In general serviciile de marcare temporala (T SP - Time Stamp Providers) sunt
vazute ca servicii auxiliare ale serviciilor de securitate. Implementarea lor necesita
nsa un nivel mare de atentie, datorita complexitatii si cerintelor speciale privind
echipamentele hardware de sincronizare a timpului.
10. Unicitatea: Unicitatea unor documente electronice/mesaje poate fi o cerinta functionala care trebuie ndeplinita de un T T P .
11. Inter-operabilitatea: Schimbul mesajelor nu poate fi restrictionat la domeniul
deservit de un singur T T P . In unele situatii, mesajele electronice trebuie procesate
nsa de utilizatori din domenii deservite de T T P -uri diferite.
Cerinta poate fi asigurata prin actiuni suplimentare executate ntre T T P -uri si sunt
specifice fiecarui tip de T T P . De exemplu, cross - certificarea a doua CA - uri din
domenii P KI diferite poate fi o conditie necesara si suficienta pentru asigurarea
inter-operabilitatii utilizatorilor acelor domenii.
Tot inter-operabilitatea presupune si respectarea standardelor care guverneaza domeniul de aplicabilitate.
12. Acreditarea: Procedurile de auditare si acreditare pentru T T P -uri sunt esentiale
n special pentru asigurarea unui nivel de ncredere cerut n relatiile cu utilizatorii.
Acreditarea se poate face la nivel local, national sau international iar nivelul ei
depinde de legile si standardele existente n domeniul respectiv.
13. Politica de securitate: Fiecare T T P trebuie sa ofere utilizatorilor sai o politica de
securitate bine definita, n concordanta cu legislatia si restrictiile nationale precum
si cu cerintele de securitate definite.
Disputele dintre entitati vor fi arbitrate n concordanta si cu politicile de securitate
definite la nivelul T T P -urilor implicate (direct sau indirect) n tranzactiile electronice.
2.1. CERINT
E ALE SERVICIILOR TERT
E DE INCREDERE
14. Managementul cheilor: Utilizatorii pot cere unui T T P diverse servicii de gestiune
privind cheile lor de semnatura si criptare. Generarea cheilor, distributia acestor
chei, mecanisme de recuperare de chei (key - recovery), backup pentru chei, key
- escrow, rennoirea automata sau la cerere a cheilor (la expirare sau n caz de
compromitere) pot fi cerinte functionale la nivelul unui T T P .
15. Publicarea datelor: Serviciile de publicare din T T P -uri sunt necesare pentru
pu-blicarea unor informatii folosite de utilizatorii sistemelor. Distribuirea cheilor
publice sau a certificatelor digitale pentru utilizatori, distribuirea listelor de certificate revocate sunt informatii esentiale proceselor de certificare si validare.
Serviciile de publicare pot fi implementate prin intermediul unor protocoale cum ar
fi LDAP, HT T P, X.500, DN S etc.
16. Scalabilitatea si modularitatea: Serviciile furnizate de T T P -uri trebuie sa fie
scalabile si usor gestionabile n implementari pe scara larga. Structura modularizata
permite adaugarea sau scoaterea cu usurinta a unor componente de functionalitate
la nivelul T T P -ului.
17. Compatibilitatea si portabilitatea: Presupune compatibilitatea implementarilor T T P -urilor cu standardele, tehnologiile si platformele software/hardware cerute.
Cerinte privind politica de securitate
Politica de securitate a unui T T P trebuie sa acopere toate aspectele de securitate privind
administrarea T T P ului si operarea serviciilor sale, fiind un instrument vital pentru generarea ncrederii catre entitatile client.
O politica de securitate nglobeaza toate elementele principale de functionare ale
tertului de ncredere. Orice politica de securitate ar trebui sa contina:
1. O componenta privind politica de securitate generala, n care care sunt stabilite
toate aspectele non-tehnice privind securitatea si ncrederea n serviciile tertului;
2. O componenta privind politica de securitate tehnica, n care sunt stabilite aspectele
tehnice privind securitatea si functionalitatea tertului. Aici sunt descrise rutinele,
procedurile si aspectele tehnice ale sistemului.
Continutul efectiv al politicii depinde de serviciile oferite de T T P . In orice politica de
securitate sunt incluse urmatoarele elemente:
conceptele generale privind serviciile furnizate;
definirea entitatilor participante;
cerintele de securitate (confidentialitatea, integritatea, disponibilitatea, autenticitatea, responsabilitatea);

infrastructura organizationala si asignarea responsabilitatilor n cadrul T T P -ului;

obligatiile si raspunderile T T P -ului si a celorlaltor entitati implicate;
ciclul de viata al cheilor criptografice necesare (mecanismul de generare a cheilor,
protejarea cheilor, timpul lor de viata, rennoirea cheilor, distrugerea cheilor etc.);
mecanismele de asigurare a securitatii n cadrul sistemului;
procedurile de operare si scenariile lor de aplicare;
definirea rolurilor necesare n cadrul operarii serviciilor furnizate;
definirea claselor pentru clasificarea informatiilor;
aspectele legate de personal, n special pentru personalul din functii - cheie;
strategiile de gestiune a riscurilor;
tratarea incidentelor.
2.2
Configuratii cu terti de ncredere
Din punct de vedere al pozitionarii tertului de ncredere n cadrul comunicatiei dintre entitatile client, precum si al implicarii sale directe sau indirecte la protocolul de comunicatie,
se pot realiza trei configuratii diferite:
1. Configuratie cu T T P in-line:
Un tert de ncredere in-line poate exista atunci cand doua entitati apartinand la
doua domenii de securitate diferite doresc sa schimbe ntre ele mesaje securizate.
In aceasta situatie, tertul este pozitionat ntre cele doua entitati, actionand ca un
intermediar n toate interactiunile dintre ele si facilitand schimburile lor securizate
de informatii.
Entitate Alice
TTP
in line
Entitate Bob
Configuratiile cu T T P -uri in-line pot include servicii cum ar fi autentificarea sau

controlul privilegiilor (tertii de ncredere jucand un rol n furnizarea de servicii de
non-repudiere), controlul accesului, recuperarea de chei, confidentialitate si integritate pentru datele transmise.
2.3. INTER-OPERAREA SERVICIILOR T T P
2. Configuratie cu T T P on-line: Un T T P on-line se poate utiliza n situatia cand

cel putin una din entitati cere tertului respectiv furnizarea sau nregistrarea unor
informatii de securitate, iar tertul este implicat doar n cateva din schimburile securizate dintre ele (de obicei n prima faza a comunicatiei).
Ulterior T T P nu mai participa la tranzactiile dintre entitati si nu este pozitionat
pe calea lor de comunicatie.
TTP
on line
Entitate Alice
Entitate Bob
Astfel de configuratii pot include servicii de autentificare, certificare, controlul privilegiilor etc.
Tertul de ncredere poate juca de asemenea un rol n furnizarea de servicii de nonrepudiere, controlul accesului, managementul cheilor, marcare temporala, confidentialitate si integritate pentru datele transmise.
3. Configuratie cu T T P off-line: Tertul de ncredere off-line nu interactioneaza direct cu entitatile n timpul schimburilor de mesaje securizate. In schimb, entitatile
comunica ntre ele folosind date generate anterior de catre T T P .
TTP
on line
Entitate Alice
?

Entitate Bob
T T P -urile off-line pot include servicii de autentificare, certificare, controlul privilegiilor, non-repudiere, distribuirea cheilor, recuperarea cheilor etc.
2.3
Inter-operarea serviciilor T T P
Un T T P poate avea acorduri de ncredere stabilite cu alte T T P -uri pentru a forma o retea
care sa permita entitatilor sale sa comunice securizat cu entitatile acestea. In situatiile
n care T T P -ul nu poate oferi anumite servicii solicitate, se pot stabili protocoale de

ncredere care sa permita altor T T P -uri sa subcontracteze si sa asigure aceste servicii

suplimentare.
La analizarea cerintelor de interconectare trebuie avut n vedere daca relatia legala
dintre un T T P si abonatii sai este diferita de cea dintre acel T T P si alte entitati interesate
(de exemplu utilizatori care verifica semnaturi digitale bazate pe certificatele digitale emise
de o Autoritate de Certificare).
Fiecare tert de ncredere furnizeaza servicii catre entitatile din domeniul sau conform cu
politica de securitate proprie.
Exista urmatoarele posibilitati de interconectare:
1. Interconectare T T P - Utilizator: presupune mecanisme si mijloace prin care un utilizator interactioneaza cu un T T P pentru a cere/primi un serviciu. Fiecare utilizator
poate interactiona cu un T T P n mod diferit, n functie de serviciul solicitat.
2. Interconectare Utilizator - Utilizator: dupa ce un T T P si-a terminat joburile n
relatia cu entitatile sale, toate comunicatiile dintre entitati se pot face fara a mai fi
nevoie de asistenta T T P -ului.
Relatia ntre entitati, precum si formalizarea contractuala a acestei relatii, se bazeaza
pe ncrederea acestora n T T P si pe mecanismele de interconectare dintre T T P -uri.
3. Interconectare T T P - T T P :
Figura de mai jos prezinta un exemplu de astfel de interfata (ISO 14516):
(1)
(2)
TTP A
TTP B
6
-
(3)
(3)
(1)
?
Alice
(4)

Domeniu Alice
Bob
Domeniu Bob
(a) Alice cere de la T T P -ul A o cheie secreta pentru a comunica cu Bob (1).
(b) T T P -ul A transfera cheia secreta catre Alice (3) si catre T T P -ul B (2).
(c) T T P -ul B transmite apoi cheia catre Bob (3).
(d) Avand stabilita o cheie comuna, cele doua entitati pot comunica securizat (4).
2.4. SERVICII DE NON-REPUDIERE
O varianta a acestui protocol, care utilizeaza tehnologia cu chei publice:

(a) Alice cere T T P -ului A un certificat pentru a comunica securizat cu Bob (1).
(b) T T P -ul A emite un certificat lui Alice (3).
(c) Analog, Bob cere catre T T P -ul B emiterea unui certificat (1) si-l obtine (3).
(d) De asemenea, cele doua T T P -uri si emit una catre cealalta cate un certificat
(2).
(e) Acum, cele doua entitati pot comunica securizat avand stabilita ntre ele infrastructura de chei de ncredere publice (4).
2.4
Servicii de Non-Repudiere
Repudierea este una dintre problemele de securitate fundamentale existente n tranzactiile

efectuate prin documente. Necesitatea serviciilor de non-repudiere nu provine numai din
faptul ca partile pot ncerca sa se nsele una pe cealalta. Este o realitate bine cunoscuta
faptul ca diverse circumstante neasteptate pot conduce la situatia n care doua entitati
implicate ntr-o tranzactie ajung n timp sa aiba puncte diferite de vedere cu privire la
ce s-a ntamplat n cadrul relatiei dintre ele. O eroare de comunicatie pe retea n timpul
derularii unui protocol este un exemplu reprezentativ.
Putem defini o tranzactie de baza ca fiind transferarea unui mesaj M de la Alice
(Emitent) la Bob (Receptor):
A B : M
Chiar si ntr-o astfel de tranzactie simpla, ar putea apare urmatoarele cazuri de disputa:
Alice sustine ca a trimis mesajul M lui Bob, iar Bob acuza faptul ca nu l-a primit;
Bob sustine ca a primit mesajul M de la Alice, iar Alice acuza faptul ca nu l-a
trimis;
Alice sustine ca a trimis mesajul M nainte de un moment de timp T , n timp ce
Bob declara ca ca nu a primit mesajul nainte de momentul T .
Serviciile de non-repudiere ajuta entitatile implicate ntr-o astfel de tranzactie sa rezolve
posibilele dispute care pot apare cu privire la anumite evenimente sau actiuni care s-au
ntamplat (sau nu s-au ntamplat) n cadrul tranzactiei.
Definitia 2.2. Un protocol de non-repudiere este un flux de tranzactii n care entit
atile
implicate schimba dovezi electronice, capabile s
a ofere apoi servicii de non-repudiere.
Principalele dovezi de non-repudiere prezente n toate protocoalele propuse sunt:
10

Non-Repudierea Originii: un protocol de non-repudiere ofera non-repudierea originii

(N RO), daca si numai daca poate genera o dovada privind originea mesajului
destinata receptorului mesajului si care prezentata unui judecator, acesta poate
stabili fara dubiu ca initiatorul a trimis acel mesaj.
Non-Repudierea Receptiei: un protocol de non-repudiere ofera non-repudierea receptiei (N RR), daca si numai daca poate genera o dovada privind primirea mesajului
destinata initiatorului mesajului si care prezentata unui judecator, acesta poate
stabili fara dubiu ca destinatarul a primit acel mesaj.
Un protocol de non-repudiere este corect (fair) daca la finalizarea sa:
Alice detine o dovada de tip N RR, iar Bob detine o dovada de tip N RO; sau
nici unul dintre ei nu detine o informatie de acest tip.
Protocoalele de non-repudiere corecte au constituit o tema importanta de cercetare n
literatura de specialitate. Studiul [15] mparte protocoalele de non-repudiere n:
1. protocoale cu corectitudine tare;
2. protocoale cu corectitudine adevarata;
3. protocoale cu corectitudine probabilistica.
Cele mai multe protocoale de non-repudiere propuse iau n considerare cazul n care sunt
implicate doar doua entitati, care trebuie sa obtina dovezile de non-repudiere a originii,
respectiv a receptiei unui mesaj. Exista si scheme de protocoale care asigura dovezile
necesare de non-repudiere pentru scenarii cu mai mult de doua entitati care doresc sa
schimbe mesaje ntre ele. Un studiu asupra acestui tip de protocoale este realizat n [25].
Intr-o tranzactie electronica, un transfer de mesaj poate fi transferat de la un emitent
E (Alice) catre un receptor R (Bob) n doua feluri:
1. E trimite mesajul direct catre R (comunicare directa); sau
2. E trimite mesajul catre un Agent de Expediere intermediar AE, care apoi trimite
mesajul catre R (comunicare indirecta).
#
AE
>"!
Comunicare indirecta
#
#
~
Comunicare direct
a
-
"!
"!
11
In varianta de comunicare directa, daca Emitentul si Receptorul nu au ncredere unul

n celalalt, pentru a se putea contoriza corect actiunile lor, sunt necesare urmatoarele
servicii de non-repudiere (ISO 13888 3):
Non-Repudierea Originii (N RO): asigura protectia mpotriva refuzului Emitentului de a recunoaste transmiterea mesajului. Dovada transmiterii mesajului va fi
generata de Emitent sau un T T P si va fi pastrata de Receptor.
Non-repudierea Receptiei (N RR): asigura protectia mpotriva refuzului Receptorului
de a recunoaste primirea mesajului. Dovada primirii mesajului este generata de
Receptor sau de un T T P si va fi pastrata de Receptor.
In varianta de comunicare intermediata de un Agent de Expediere (AE), pentru a se
putea rezolva eventualele dispute ntre Emitent si Agentul de Expediere, respectiv ntre
Agentul de Expediere si Receptor, sunt necesare urmatoarele servicii de non-repudiere
ISO 13888 3):
Non-repudierea depunerii (N RS): asigura dovada ca Emitentul a depus mesajul
pentru expediere. Dovada depunerii mesajului este generata de Agentul de Expediere
si va fi pastrata de Receptor.
Non-repudierea expedierii (N RD): asigura dovada ca mesajul a fost expediat de
Receptor. Dovada de expediere este generata de Agentul de Expediere si va fi pastrata
de Emitent.
In general, protocoalele care stau la baza unui serviciu de non-repudiere trebuie sa
ndeplineasca urmatoarele cerinte:
Corectitudine: Nici una din cele doua entitati implicate nu trebuie sa poata detine
vreun avantaj fata de cealalta privind obtinerea dovezilor de non-repudiere.
Repudierea poate fi prevenita numai daca fiecare entitate obtine n egala masura
informatia de care are nevoie: Bob trebuie sa obtina mesajul util si dovada de
non-repudiere a originii acestui mesaj, iar Alice trebuie sa obtina dovada de nonrepudiere a receptiei mesajului transmis.
In caz contrar, cei doi utilizatori nu trebuie sa aiba acces la nici una din aceste
informatii.
Eficienta: Non-repudierea se obtine n general prin folosirea unor servicii de tip
T T P . Gradul de implicare al acestora este esential n determinarea eficientei unui
protocol de non-repudiere.
Oportunitate: Din diverse motive, o tranzactie din protocolul de non-repudiere poate
fi ntarziata sau chiar stopata intentionat de una dintre partile implicate. Acest lucru
nu trebuie sa dezavantajeze cealalta parte.

12
Politica: Toate regulile si toti parametrii necesari n cadrul serviciului de nonrepudiere trebuie definite corect si complet.
Transparenta T T P -ului: In anumite situatii este de dorit ca implicarea T T P -ului
n cadrul protocolului (sau a rezolvarii disputelor) sa fie invizibila. Astfel, dovezile
obtinute prin implicarea T T P -ului vor fi similare celor obtinute fara ajutorul acestuia.
Verificabilitatea T T P -ului: Proprietate necesara n situatia cand T T P -ul nu este
considerat de ncredere de ambele entitati.
2.4.1
Protocoale de non-repudiere bazate pe T T P -uri
Exista mai multe abordari si propuneri privind protocoale care sa asigure cerintele definite
mai sus pentru un serviciu de non-repudiere. Unele presupun obtinerea dovezilor de nonrepudiere fara a implica terte parti n comunicarea dintre Alice si Bob; cele mai multe
protocoale se bazeaza nsa pe conectarea la un T T P .
Rolul T T P -urilor n protocoalele de non-repudiere
In functie de mecanismele de non-repudiere folosite si de politica aplicata, T T P -urile pot
participa sub diverse roluri la generarea, verificarea, validarea sau transferarea dovezilor
de non-repudiere si la arbitrarea disputelor.
Din punct de vedere al implicarii T T P -ului n cadrul derularii unui protocol de nonrepudiere, pot fi identificate trei situatii (ISO 10181 4):
1. Protocoale de non-repudiere bazate pe T T P -uri in-line. Acest tip de terti de ncredere actioneaza ca intermediari n toate tranzactiile efectuate ntre entitati. Toate
mesajele schimbate n cadrul protocolului trec pe la T T P .
2. Protocoale de non-repudiere bazate pe T T P -uri on-line. T T P -urile participa activ
la generarea si verificarea dovezilor de non-repudiere.
3. Protocoale de non-repudiere bazate pe T T P -uri off-line. In aceasta situatie, tertii
de ncredere nu participa activ n cadrul serviciului de non-repudiere (vor fi invocati
doar n anumite situatii de exceptie).
Un T T P implicat n gestionarea dovezilor de non-repudiere se poate afla n una din
situatiile de mai jos ([30]):
Ca Autoritate de Certificare. Un CA genereaza certificate digitale pentru cheile
utilizatorilor, autentificandu-le astfel pentru a fi folosite n protocoalele de nonrepudiere. CA-ul furnizeaza de asemenea listele de certificate revocate, pentru a
putea fi determinata validitatea cheilor folosite.
13
Autoritatile de Certificare sunt folosite ntotdeauna n situatiile cand pentru generarea dovezilor de non-repudiere sunt utilizate semnaturile digitale. In general,
T T P -urile cu rol de CA sunt utilizate off-line n protocoalele de non-repudiere. Ele
pot fi folosite si ca T T P -uri on-line, daca semnaturile electronice folosesc formate
avansate de semnatura electronica si contin informatii bazate pe servicii on-line de
validare a certificatelor.
Ca Notar Electronic. Similar cazului non-electronic, un T T P cu rol de notar electronic poate fi utilizat pentru asigurarea unor servicii de non-repudiere.
Daca pentru generarea dovezilor de non-repudiere sunt folosite mecanisme bazate pe
criptografia simetrica, T T P -ul implicat n protocol poate fi activat pentru a genera
dovezile de non-repudiere n numele participantilor. Daca dovezile de non-repudiere
se obtin pe baza de semnaturi digitale, notarul ar trebui sa furnizeze marci temporale
privind momentul generarii dovezilor.
In general T T P -urile cu rol de Notar Electronic sunt utilizate n protocoalele de
non-repudiere ntr-o arhitectura on-line.
Ca Autoritatea de Expediere. O astfel de Autoritate constituie un tert de ncredere
n ceea ce priveste expedierea mesajelor.
Acest tip de T T P -uri este utilizat n cadrul protocoalelor de non-repudiere ntr-o
arhitectura in-line.
Ca Autoritatea de Arbitrare. Un T T P cu acest rol nu va fi implicat n protocoale decat n situatiile n care apar dispute, principalul sau scop fiind judecarea
si rezolvarea acestora. Judecarea disputelor presupune evaluarea dovezilor puse la
dispozitie de participanti si luarea n consideratie a unei politici de non-repudiere.
Protocoale de non-repudiere f
ar
a T T P -uri
Protocoalele de acest tip pot asigura doar probabilistic cerintele de non-repudiere.
Chiar daca n implementare se aleg corect parametrii protocolului, gradul de risc este
foarte mic iar probabilitatea de nesolutionare a disputelor este neglijabila, totusi aceste
protocoale sunt ineficiente, fiind greu de aplicat.
Exemplul 2.2. Primele protocoale f
ar
a T T P apar la jum
atatea anilor 80, dezvoltate
initial pentru schimbul de secrete (de exemplu chei criptografice) ntre entit
ati. Ideea de
baz
a era ca fiecare entitate sa transmit
a pe r
and biti succesivi din informatia secret
a care
trebuia furnizata celeilalte entitati, p
an
a la epuizarea informatiei. Dac
a o entitate stopa
procesul, cealalta proceda similar; n acest mod, efortul de calcul pentru aflarea restului de
cadrul acestor protocoale de
informatie era sensibil echivalent pentru ambele entit
ati. In
schimb de date pot fi identificate mecanisme clare de non-repudiere.
14

Primele protocoale pure de non-repudiere propuse au fost cele bazate pe T T P -uri.

Abia mai tarziu au aparut si protocoale de non-repudiere care nu necesitau existenta unui
TTP.
Pentru exemplificare prezentam protocolul probabilist de non-repudiere propus de
Markowitch si Roggeman ([18]). Protocoale similare care asigura non-repudierea si nu
folosesc T T P -uri au mai fost realizate n [13], [26], [22].
Scopul protocolului Markowitch - Roggeman este de a obtine dovezile de non-repudiere
N RO si N RR fara a utiliza un tert de ncredere. Protocolul si propune sa asigure
transmiterea unui mesaj M de la Alice catre Bob si sa asigure dovezile de non-repudiere
a originii si receptiei mesajului.
Protocolul este descris de urmatoarele tranzactii:
1. In prima runda, Alice:
(a) Cripteaza mesajul M folosind cheia simetrica k si obtine c = Ek (M );
(b) Genereaza dovada originii lui c:
EOOc = SigAlice (Bob, l, c)
unde l = Hash(M, k);
(c) Trimite lui Bob (EOOC , l, c).
2. Bob raspunde cu dovada receptiei mesajului criptat c:
EORC = SigBob (Alice, l, c)
3. In rundele i = 2, . . . , n 1
(a) Alice trimite lui Bob cuplul (EOOri1 , ri1 ) unde ri1 este o valoare aleatoare
de runda, iar
EOOri1 = SigAlice (Bob, i, ri1 )
(b) Bob raspunde cu dovada receptiei valorii ri1 :
EORri = SigBob (Alice, i, ri )
4. In ultima runda, Alice trimite cheia simetrica k si dovada EOOrn1 a originii acesteia:
EOOrn1 = SigAlice (Bob, n, k)
5. Bob raspunde cu dovada receptiei cheii k:
EORrn1 = SigBob (Alice, n, k)
15
Dupa epuizarea rundei n si primirea lui EORrn1 , Alice anunta terminarea protocolului,
dezvaluind practic numarul de runde ales si faptul ca n aceasta ultima runda a trimis cheia
simetrica k prin care Bob poate obtine mesajul M = Dk ((c). Dovada de non-repudiere a
originii va fi:
N RO = (EOOc , EOOrn1 ),
iar dovada de non-repudiere a receptiei va fi N RR = (EORc , EORrn1 ).
In cazul unei dispute:
Bob poate dovedi non-repudierea originii:
EOOc : dovedeste ca Alice i-a trimis mesajul criptat cu o cheie simetrica;
EOOrn1 : dovedeste ca Alice i-a trimis si cheia simetrica de decriptare.
Alice poate dovedi non-repudierea receptiei:
EORc : dovedeste ca Bob i-a confirmat primirea mesajului criptat cu o cheie
simetrica;
EORrn1 : dovedeste ca Bob i-a confirmat si primirea cheii simetrice de decriptare, adica obtinerea mesajului M .
Protocolul se bazeaza pe pastrarea secretului privind numarul de runde si cheia secreta k,
alese de Alice pana la epuizarea ntregului set de runde. Bob, nestiind dinainte numarul
de runde fixat de Alice, n ultima runda nu va sti ca a primit cheia simetrica decat dupa
ce va fi anuntat de Alice, furnizand la randul lui informatia necesara de non-repudiere.
Observatia 2.1.
La fiecare din ultimele n 1 runde, nainte de a trimite dovada non-repudierii
receptiei corespunzatoare, Bob ar putea ncerca decriptarea mesajului primit n prima
rund
a; daca reuseste, poate alege s
a nu mai trimit
a aceast
a dovad
a, ceea ce l-ar pune
n avantaj fata de Alice. Aceast
a problem
a se poate rezolva printr-o implementare
care sa contorizeze timpii de raspuns ai lui Bob. Astfel, dac
a apare o nt
arziere mai
mare n cadrul unui raspuns de la Bob, protocolul esueaz
a. Pentru asta, trebuie ales
un algoritm de criptare n care operatia de decriptare s
a dureze un timp suficient ca
s
a poata fi detectat de Alice. Solutia este ineficient
a practic din mai multe motive
(stadiul actual face ca timpii de calcul s
a fie insezizabili; sau, dac
a entit
atile utilizeaz
a o retea de comunicatie instabil
a unde pot apare nt
arzieri nepredictibile, f
ara
ca ele sa fie induse de Bob).
Pentru ca protocolul sa fie functional, valorile aleatoare r1 , . . . , rn1 trebuie s
a fie
independente, egal distribuite, de lungimi aproximativ echivalente cu lungimea lui k.
16

Alice trebuie sa aleaga un algoritm de criptare simetric si/sau un mod de utilizare
al acestui algoritm care sa nu permit

a decriptarea doar a unei p
arti a mesajului. In
[18] sunt propuse astfel de moduri si mecanisme de prevenire.
Oricare dintre entitati poate ntrerupe protocolul n rundele intermediare; n aceasta
situatie, nici Alice si nici Bob nu detine un avantaj, deoarece nu va avea dovada
privind trimiterea/receptia cheii simetrice de decriptare.
Exist
a nsa o probabilitate ca Bob s
a intuiasc
a corect num
arul de ordine al rundei
finale si sa ntrerupa protocolul nainte de epuizarea corect
a a acestei runde finale,
aceast
ceea ce i confera un avantaj. In
a situatie Bob va avea dovada complet
a a
non-repudierii originii n timp ce lui Alice i lipseste dovada receptiei de c
atre Bob
a cheii de decriptare, deci nu poate dovedi c
a Bob a avut acces la mesaj.
Protocoale de non-repudiere bazate pe T T P -uri in-line
In 1996 Coffey si Saidha au propus un protocol de non-repudiere ([9]) bazat pe un T T P
in-line utilizat pe post de Server de Non-Repudiere (N RS - Non-Repudiation Server).
Acest tert colecteaza dovezile de non-repudiere si le transmite apoi entitatilor care si
disputa tranzactia. Practic tertul de ncredere functioneaza ca un Agent de Expediere
(AE) pentru mesajele schimbate ntre entitatile participante.
Protocolul utilizeaza semnaturile digitale (ca mecanism criptografic pentru generarea
dovezii de non-repudiabilitate) si criptografia cu chei publice (pentru schimbul de mesaje).
Pentru ca protocolul sa fie functional, Serverul de Non-Repudiere trebuie sa aiba
urmatoarele caracteristici:
este independent de cele doua entitati, fiind nsa de ncredere pentru acestea;
nu distribuie nici o informatie legata de dovezi catre vreo entitate participanta pana
cand nu detine si dovada corespunzatoare pentru a putea fi distribuita catre cealalta
entitate;
primeste dovada de non-repudiere a originii direct de la Alice si coopereaza cu Bob
pentru a genera dovada de non-repudiere a receptiei;
odata ce detine toata informatia necesara de non-repudiere pentru ambele entitati,
nu se va opune procesului de distributie a acestei informatii catre cele doua entitati.
Protocolul Coffrey - Saidha se desfasoara n doua faze:
1. (Faza 1) Generarea dovezilor de non-repudiabilitate; are loc la T T P .
2. (Faza 2) Distribuirea dovezilor de non-repudiabilitate.
17
Faza 1
?
?
TTP
Emitent Alice
? ?-
Faza 2
Receptor Bob
Dupa ce se consuma Faza 1 si Serverul de Non-Repudiere este n posesia celor doua

dovezi, el va distribui n Faza 2 aceste dovezi catre partile comunicante.
Toata comunicarea dintre Alice si Bob are avea loc prin intermediul Serverului de NonRepudiere, iar mesajele schimbate sunt semnate digital si nsotite de o informatie privind
momentul semnarii. De aceea pe langa Serverul de Non-Repudiere protocolul necesita
si prezenta unei Autoritati de Marcare Temporal
a care sa marcheze momentul semnarii si
sa poata astfel demonstra ca semnarea mesajelor s-a facut n perioada de valabilitate a
certificatelor digitale corespunzatoare cheilor de semnatura.
Protocolul Coffey-Saitha cu T T P in-line este descris formal de urmatoarele tranzactii:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Alice T SA :
T SA Alice :
Alice N RS :
N RS Alice :
Alice N RS :
N RS Bob :
Bob T SA :
T SA Bob :
Bob N RS :
N RS Bob :
N RS Alice :
P KT SA (N ROp)
P KAlice (N RO)
N R req
P KAlice (n1 )
P KN RS (SigAlice (n1 , N RO, N RRp))
P KBob (SigN RS (n2 , N RRp))
P KT SA (N RRps)
P KBob (N RR)
P KN RS (SigBob (n2 , N RR))
P KBob ((N RO))
P KAlice (N RR)
Descrierea si analiza protocolului:

Toate mesajele intermediare Mi sunt criptate cu cheia publica a entitatii destinatie:
P KBob (Mi ). Astfel numai Bob n calitate de destinatar poate accesa mesajul
transmis, utilizand pentru decriptare, cheia sa privata.
In pasii 1 si 2, Alice ca entitate initiatoare genereaza prin intermediul tertului de
ncredere dat de Autoritatea de Marca Temporala (T SA Timestamp Authority)
dovada de non-repudiere a originii (N RO).
Alice trimite catre T SA dovada partiala a originii:
N ROp = SigAlice (Alice, Bob, M )
18

si primeste de la T SA marca temporala peste aceasta semnatura:

N RO = SigT SA ((N ROp, T SA, ts1 )
unde T SA si ts1 reprezinta identificatorul T SA-ului si respectiv timpul aplicat.
La pasul 3 Alice initiaza o sesiune de lucru cu Serverul de Non-Repudiere (N RS),
transmitandu-i o cerere de non-repudiere N R req.
In pasii 4 si 5 Alice transmite catre N RS dovada de non-repudiere a originii (N RO)
obtinuta la primii doi pasi, precum si o dovada partiala de non-repudiere a receptiei:
N RRp = (Bob, Alice, h(N RO))
unde h este o functie de dispersie criptografica. Pentru a evita atacuri de tip replay,
se foloseste o secventa de tip provocare - raspuns bazata pe un nonce n1 , generat
de serverul N RS la pasul 4.
Fiind criptat de N RS cu cheia publica a lui Alice, nonce-ul transmis nu poate fi
accesat decat de Alice.
In pasul 6, serverul N RS initiaza generarea dovezii de non-repudiere a receptiei
transmitandu-i lui Bob un nonce n2 (necesar mai tarziu) si dovada partiala de nonrepudiere N RRp primita de la Alice.
In pasii 7 si 8, Bob genereaza prin intermediul tertului de ncredere dat de T SA
dovada de non-repudiere a receptiei (N RR). Bob trimite spre T SA o dovada
partiala de non-repudiere a receptiei, semnata de el:
N RRps = SigBob (N RRp) = SigBob (Bob, Alice, h(N RO))
si primeste de la T SA marca temporala peste aceasta semnatura:
N RR = SigT SA (N RRps, T SA, ts2 ) = SigT SA (SigBob (Bob, Alice, h(N RO))).
La pasul 9 Bob trimite catre Serverul de Non-Repudiere (N RS), dovada de nonrepudiere a receptiei N RR, nsotita de nonce-ul n2 (pentru a evita atacurile de tip
replay).
In acest moment, Faza 1 s-a ncheiat si N RS avand ambele dovezi de non-repudiere
este n masura sa treaca la Faza 2 a protocolului: transmiterea acestor dovezi catre
Alice si Bob.
Astfel, n pasii 10 si 11, Bob va primi dovada de non-repudiere a originii mesajului
(N RO) si mpreuna cu acesta si mesajul propriu zis M ; similar, Alice primeste
dovada de non-repudiere a receptiei mesajului (N RR).
19
Observatia 2.2.
1. Ideea principala a protocolului Coffey - Saidha este aceea c
a dovezile de non-repudiere a originii si respectiv a receptiei nu sunt trimise celor dou
a entit
ati p
an
a ce acestea
nu depun aceste dovezi semnate la Serverul de Non-Repudiere.
2. Dovezile de non-repudiere detinute de Alice si Bob nu contin semn
atura N RS-ului.
Acestea sunt:
N RO = SigT SA (SigAlice (Alice, Bob, M ), T SA, ts1 );
N RR = SigT SA (SigBob (Bob, Alice, h(N RO)), T SA, ts2 ).
3. Cele doua entitati nu comunic
a niciodat
a direct; schimbul de mesaje (mesajul M
si dovezile de non-repudiere) se face numai prin intermediul Serverului de NonRepudiere.
4. Mesajul M ajunge la Bob odat
a cu dovada de non-repudiere a originii N RO si nu
nainte ca N RS sa detina dovada de non-repudiere a receptiei N RR.
cazul solutionarii unei dispute n care Alice sustine c
5. In
a Bob a primit mesajul
M , arbitrul cere N RS-ului dovada de non-repudiere a receptiei (N RR) precum si
dovada de non-repudiere a originii (N RO).
Dac
a aceste dovezi nu pot fi oferite, afirmatia lui Alice este respins
a. Altfel, arbitrul verifica semnatura lui Alice si marca temporal
a aplicat
a de T SA pe aceast
a semnatura. De asemenea verific
a valoarea h(N RO) din cadrul dovezii N RR,
semn
a-tura lui Bob si marca temporal
a aplicat
a peste aceasta.
In caz de succes, arbitrul aprob

a afirmatia lui Alice.
cazul solutionarii unei dispute n care Bob sustine c
6. In
a Alice a trimis mesajul M ,
arbitrul cere N RS-ului sau lui Bob dovada N RO. Dac
a aceasta nu poate fi oferita,
afirmatia lui Bob este respinsa.
Altfel, arbitrul verifica daca mesajul din N RO satisface informatia oferit
a de Bob.
De asemenea, verifica semnatura lui Alice si marca temporal
a aplicat
a de T SA pe
caz de success, arbitrul aprob
aceasta semnatura. In
a afirmatia lui B.
7. T SA-ul participa activ la generarea dovezilor de non-repudiere; cei doi participanti
precum si Serverul de Non-Repudiere, trebuie s
a aib
a ncredere n acesta si s
a verifice
semn
aturile digitale ale T SA-ului aplicate la marcarea temporal
a a mesajelor (pentru
a se asigura ca dovezile generate sunt valabile la solutionarea disputelor ulterioare).
8. Alice si Bob nu trebuie sa aib
a ncredere unul n cel
alalt, dar trebuie s
a aiba
ncredere n cele doua T T P -uri.
20

9. Atacurile de tip replay n relatia N RS - Entitate sunt ocolite prin utilizarea unor
secvente de tip provocare -raspuns, bazate pe informatii de tip nonce transmise de
N RS.
Concluzie: Utilizarea de T T P -uri in-line (pentru asigurarea dovezilor necesare n
serviciile de non-repudiere) poate fi o solutie viabila. Exista nsa cateva dezavantaje
majore care descurajeaza punerea n practica a acestui tip de arhitectura:
1. T T P -ul trebuie sa gestioneze baze de date destul de mari n care sa stocheze mesajele
pe care le primeste pentru a le retransmite.
2. La nivelul T T P -ului, gatuirea tranzactiilor este maxima.
3. Gestiunea centralizata de informatii sensibile n cantitati mari poate constitui o
problema, necesitand un nivel suplimentar de confidentialitate la nivelul tertului.
Protocoale de non-repudiere bazate pe T T P -uri on-line
In cazul protocoalelor de non-repudiere bazate pe T T P -uri on-line, T T P -ul nu actioneaza
ca Agent de Expediere (intermediar pentru fiecare tranzactie ntre entitati). El intervine
totusi n cadrul fiecarei sesiuni a protocolului.
Dintre protocoalele de acest tip vom detalia pe cel propus de Zhou si Gollmann ([32]) n
1996. Aici T T P -ul functioneaza ca un director de publicare read-only, de unde entitatile
participante si obtin informatii necesare pentru dovezile de non-repudiere.
Protocolul este descris de urmatoarele tranzactii:
1. Alice (ca entitate emitenta):
(a) cripteaza mesajul M folosind cheia simetrica k : c = Ek (M );
(b) genereaza dovada originii lui c:
EOOc = SigAlice (Bob, l, t, c)
unde l = Hash(M, k)
(c) trimite lui Bob perechea (c, EOOc ).

2. Bob (ca entitate receptoare) raspunde cu dovada receptiei mesajului criptat c:
EORc = SigBob (Alice, l, t, c).
3. Alice trimite unui tert de ncredere T T P cheia simetrica k si dovada depunerii cheii
la T T P :
Sub = SigAlice (Bob, l, t, k)
21
4. T T P :
(a) trimite spre ambele entitati confirmarea faptului ca detine cheia k:
Con = SigT T P (Alice, Bob, l, t, k)
(b) trimite lui Bob cheia simetrica k.
(c) Bob poate recompune mesajul M = Dk (c).
Dovada de non-repudiere a originii va fi:
N RO = (EOOc , Con)
Dovada de non-repudiere a receptiei va fi:
N RR = (EORc , Con)
In cazul unei dispute:
Bob poate dovedi non-repudierea originii:
EOOc dovedeste ca Alice i-a trimis mesajul criptat cu o cheie simetrica;
Con dovedeste ca Bob a putut obtine de la T T P cheia simetrica de decriptare,
deci a putut obtine si mesajul.
Alice poate dovedi non-repudierea receptiei:
EORc dovedeste ca Bob i-a confirmat primirea mesajului (criptat cu o cheie
simetrica);
Con dovedeste ca T T P -ul a publicat cheia simetrica, deci Bob a avut acces
la aceasta cheie, pentru decriptarea si obtinerea lui M .
T T P -ul poate dovedi ca Alice i-a trimis cheia simetrica, prezentand Sub.
Observatia 2.3.
Dup
a epuizarea primului pas, dac
a Bob nu r
aspunde cu dovada primirii mesajului
criptat EORc sau comunicatia se ntrerupe, Alice va opri protocolul f
ar
a a transmite
cheia simetrica de decriptare c
atre T T P .
Astfel Bob nu va avea acces la aceast
a cheie si implicit nici la mesaj.
Toate mesajele din cadrul protocolului sunt legate ntre ele prin intermediul etichetei
l.

22
Dup
a primirea dovezii de confirmare a mesajului criptat, Alice trebuie s
a compare
eticheta din confirmare cu cea trimis
a odat
a cu mesajul criptat. Altfel va pierde o
eventuala viitoare disputa.
Dac
a Alice nu trimite catre T T P cheia simetric
a k, protocolul se ncheie si niciunul
din parteneri nu este n avantaj.
Bob nu are mesajul si nici dovada complet
a a originii lui (i lipseste Con), iar lui
Alice i lipseste Con, deci nu are dovada c
a T T P -ul a publicat cheia simetric
a de
decriptare si nu poate dovedi non-repudierea receptiei.
Dup
a primirea cheii k si a lui Sub, T T P -ul va publica tuplul (Alice, Bob, l, k, Con)
ntr-o intrare specifica lui Alice, de unde Bob poate obtine cheia de decriptare.
Protocolul este protejat la atacuri de tip denial-of-service. Entit
atile r
au intentionate
nu pot trimite chei false n numele lui Alice, deoarece acestea trebuie semnate de
ea.
Ca o concluzie, n obtinerea de servicii de non-repudiere, T T P -urile on-line pot constitui o solutie mai buna decat cele in-line. Motive:
1. T T P -ul nu actioneaza ca Agent de Expediere ci ca un Agent de Certificare pentru
cheile de decriptare.
2. Entitatile nu schimba mesajele prin intermediul T T P -ului, nsa acesta participa
activ n cadrul fiecarei instante a protocolului.
3. In cadrul schimbului de mesajelor exista si un parametru (optional) de timp t.
Pentru a evita o ncarcare prea mare a T T P -ului, parametrul t agreat de Alice
si Bob nca din primele doua mesaje specifica o perioada de timp cat T T P -ul va
pastra disponibila informatia de cheie si dovada publicarii ei.
Protocoale de non-repudiere bazate pe T T P -uri off-line
Un T T P este off-line ntr-un protocol de non-repudiere daca nu intervine decat n situatii
n care apar probleme n cadrul protocolului.
T T P -urile de acest tip au fost introduse n protocoale unde n general nu apar probleme. Din acest motiv protocoalele cu T T P off-line se numesc si protocoale optimiste.
Primele protocoale care folosesc T T P -uri off-line sunt descrise de Asokan ([2],[3]).
De asemenea, Micalli propune ([21]) un protocol de certificat e-mail cu cerinte de nonrepudiabilitate bazat pe T T P -uri off-line transparente (invizibile)1 .
1
Un T T P off-line are proprietatea de a fi transparent daca la sfarsitul protocolului, analizand numai

dovezile produse, va fi imposibil de afirmat ca T T P -ul a intervenit sau nu n cadrul derularii acestuia.
23
Totusi, primele protocoale dedicate clar ideii de non-repudiere cu T T P -uri off-line sunt
descrise de Kremer, Markowitch ([14]) si de Jhou ([31]).
In general toate protocoalele de non-repudiere cu T T P -uri off-line contin cel putin
doua sub-protocoale diferite:
Un protocol principal (main) utilizat n cazurile normale n care entitatile se
comporta corect una fata de cealalta.
T T P -ul nu intervine n acest protocol.
Un protocol de recuperare (recovery) pentru situatiile cu probleme.
In acest caz este necesara interventia T T P -ului pentru furnizarea dovezilor de nonrepudiere.
In plus, unele protocoale contin si:
un protocolul aditional de iesire fortata (abort), care poate fi declansat de una
din entitati n anumite situatii; n urma acestuia se va apela ulterior protocolul de
recuperare (recovery) pentru rezolvarea disputelor.
Vom prezenta ca studiu de caz protocolul de non-repudiere cu T T P off-line propus de
Kremer-Merkowitch ([14])).
El se desfasoara ntre Alice (ca entitate emitenta) si Bob (ca entitate receptoare), iar
daca apar probleme de non-repudiere este implicat si T T P -ul.
Dovezile de non-repudiere sunt obtinute pe baza mecanismului de semnatura digitala.
In cadrul protocolului sunt generate urmatoarele dovezi:
dovada originii mesajului criptat:
EOO = SigAlice (Bob, T T P, h(c))
dovada expedierii cheii k de criptare a mesajului (criptata cu cheia publica a T T P ului): Sub = SigAlice (Bob, P KT T P (k)).
dovada de non-repudiere a receptiei mesajului criptat si a cheii de criptare a mesajului (criptata cu cheia publica a T T P -ului):
N RR = SigBob (Alice, T T P, h(c), P KT T P (k))
dovada originii cheii k de criptare a mesajului: EOOk = SigAlice (Bob, k).
dovada cererii de recuperare:
Rec = SigBob (Y )

24
dovada de confirmare a cheii de criptare:

Conk = SigT T P (Alice, Bob, k)
Schema protocolului Kremer-Merkowitch este:
1. Alice:
(a) Genereaza o cheie de sesiune k si cripteaza mesajul M : c = Ek (M ).
(b) Calculeaza P KT T P (k) folosind cheia publica a T T P -ului;
(c) Construieste dovezile EOO (privind originea mesajului criptat) si Sub (privind
expedierea cheii de sesiune criptata).
(d) Trimite lui Bob aceste informatii: (c, P KT T P (k), EOO, Sub).
2. Bob trimite catre Alice dovada N RR de non-repudiere a receptiei informatiilor.
3. Alice trimite lui Bob cheia de sesiune k (necesara decriptarii mesajului M ) si dovada
EOOk privind originea acestei chei.
Daca Bob nu primeste informatiile din pasul 3 al protocolului (din cauza lui Alice
sau a canalului de comunicatie), el apeleaza la protocolul de recuperare (recovery)
a mesajului; lucru necesar deoarece Bob nu are nca acces la M .
4. Bob trimite spre T T P o cerere de recuperare Y :
(Y, h(c), P KT T P (k), Rec, Sub, N RR, EOO)
5. T T P -ul:
(a) Decripteaza cheia de sesiune k:
(b) Trimite lui Alice: cheia k si dovada N RR (semnata de Bob) care atesta faptul
ca Bob are mesajul criptat si poate primi acum si cheia de decriptare.
(c) Trimite lui Bob cheia de sesiune k decriptata si confirmarea dovezii Conk pentru
aceasta cheie.
Observatia 2.4.
primul pas Alice trimite mesajul criptat si cheia simetric
In
a k criptat
a cu cheia
publica a T T P -ului. Acest lucru va permite T T P -ului n faza de recuperare sa
extraga cheia k si sa o furnizeze lui Bob.
Dup
a acest mesaj, nici Alice si nici Bob nu posed
a dovezi complete de non-repudiere.
25
La terminarea pasului 2, desi Bob nu poate accesa nc

a mesajul, trimite lui Alice
dovada completa de non-repudiere a receptiei.
Dac
a Bob nu primeste ulterior cheia de decriptare (adic
a pasul 3 nu mai are loc),
el o poate obtine de la T T P prin protocolul de recuperare.
De asemenea, daca cheia simetric
a criptat
a primit
a de la Alice la pasul 1 este
eronata (de exemplu a primit P KT T P (k1 ) cu k1 6= k), atunci Bob poate demonstra
c
a a primit un P KT T P (k1 ), iar dovada trimis
a de el lui Alice devine invalid
a.
Dovada completa de non-repudiere a expedierii este compus
a din tripletul {EOO,
Sub, EOOk } si este obtinuta de Bob abia dup
a completarea pasului 3 din protocol.
Dac
a pasul 3 nu are loc (din diverse motive), dovada de non-repudiere a expedierii va fi completata prin protocolul de recuperare si este format
a din tripletul
{EOO, Sub, Conk }.
acest caz, Bob primeste si cheia simetric
In
a de decriptare.
Bob poate ncerca sa triseze si s
a lanseze protocolul de recuperare mai devreme.
Imediat dupa pasul 1 el poate ntrerupe protocolul principal f
ar
a s
a mai trimit
a lui
Alice dovada N RR. Pentru a furniza corect dovezile de non-repudiere, T T P -ul
ofer
a totdeauna ambelor entitati dovezile necesare.
De asemenea este necesar ca T T P -ul s
a valideze N RR-ul primit de la Bob n pasul
4 (primul pas al protocolului de recuperare). Validarea presupune de fapt verificarea
semn
aturii lui Bob din acest N RR.
Acest lucru este necesar pentru a putea fi sigur c
a nainte ca Bob s
a primeasca
cheia de decriptare si dovada expedierii acestei chei, Alice a primit dovada corecta
de non-repudiere a receptiei.
Din aceste observatii rezulta ca niciuna dintre cele doua entitati implicate nu este
avantajata n ceea ce priveste expedierea si receptia informatiei utile si a dovezilor corespunzatoare necesare.
Exista nsa un dezavantaj pentru Alice; acesta apare n situatia n care Bob refuza sa
completeze pasul 2, caz n care Alice nu va primi dovada receptiei.
In aceasta situatie:
Bob poate lansa imediat protocolul de recuperare. Nici o problema, deoarece ambele
entitati primesc toate informatiile pentru a ncheia corect sesiunea protocolului.
Bob poate astepta o perioada de timp (mai mica sau mai mare) si abia dupa aceea
va lansa protocolul de recuperare.
In acest caz Alice trebuie sa pastreze deschisa sesiunea de protocol, pana cand Bob
se hotaraste sa lanseze protocolul de recuperare.

26
Acest lucru l plaseaza pe Bob pe o pozitie avantajata fata de Alice, deoarece Bob
nu poate fi niciodata n situatia de a depinde de Alice. Se spune despre un astfel
de protocol ca nu este oportun.
Concluzie:
Arhitectura bazata pe T T P -uri off-line constituie cea mai buna solutie pentru asigurarea dovezilor necesare de non-repudiere deoarece:
Implicarea T T P -ului poate fi doar ocazionala. In majoritatea timpului, tranzactiile
se desfasoara doar ntre entitatile emitator si receptor.
T T P -ul nu trebuie sa stocheze informatiile primite de la entitati decat n anumite
situatii ceea ce diminueaza necesarul de resurse.
Caracterul off-line al protocoalelor elimina dezavantajele cu care se confrunta serviciile on-line (redundanta serviciului si a conectivitatii, amenintari cu diverse atacuri
cum ar fi cele de tip Denial-of-Service, intruziune etc.).
2.5
Servicii de Marc
a Temporal
a
Definitia 2.3. Marcarea temporala a documentelor este un mecanism prin care se poate
determina daca un document electronic a fost creat nainte de un moment de timp dat.
Exemplul 2.3. Fara un astfel de mecanism nu putem avea ncredere n documente semnate electronic cu primitive criptografice de semn
atur
a care au fost dep
asite tehnologic.
F
ar
a cunoasterea momentului la care a fost creat
a semn
atura, aceasta poate fi oric
and
repudiat
a.
Dup
a semnarea documentului, certificatul semnatarului poate fi revocat pe motiv de
compromitere a cheii private, ceea ce permite acestuia s
a afirme c
a nu el a fost cel care a
semnat documentul.
Validarea unei semnaturi trebuie s
a se poat
a realiza si dup
a revocarea sau expirarea
certificatului de semnare.
Multe din serviciile si tehnicile de securitate existente (semnaturile electronice, autentificarea, arhivarea electronica a documentelor, protocoale de non-repudiere etc.) sunt
bazate pe posibilitatea de a putea stabili cu exactitate momentul de timp cand anumite
date au fost supuse unor operatii.
Atunci cand exista termene de predare/primire, exista necesitatea de a dovedi ca un
document a fost predat la termen, acesta constituind un alt caz de utilizare a marcilor de
timp.
Orice forma de notariere electronica include si o marca temporala. Cu toate ca marcile
temporale constituie o solutie pentru diverse aplicatii, n multe cazuri adevarata problema
o constituie obtinerea lor ntr-o maniera sigura si eficienta ([19]).
TEMPORALA
2.5. SERVICII DE MARCA
27
Marcarea temporala a unui document se face prin adaugarea unei amprente (stampile)
de timp la documentul respectiv.
In general, majoritatea schemelor de marcare temporala folosesc:
1. un rezumat al documentului care trebuie marcat (marca temporala se calculeaza pe
rezumatul documentului)
2. un tert de ncredere de tip on-line numit Autoritate de Marc
a Temporal
a (T SA
Time Stamping Authority).
T SA - ul genereaza marcile temporale pentru documente si garanteaza ca parametrul de
timp inclus este corect. Entitatile care verifica marca temporala trebuie sa aiba ncredere
n T SA.
2.5.1
Clasificarea schemelor de marc

a temporal
a
Schemele difera ntre ele prin doua aspecte de baza:

mecanismul prin care se genereaza marca temporala (pornind de la document).
modalitatea prin care se asigura ncrederea n T SA.
Conform clasificarii prezentate n [6], schemele de marcare temporala pot fi clasificate n:
1. scheme simple;
2. scheme cu nlantuire (legaturi);
3. scheme distribuite.
Indiferent de schema folosita, obtinerea unei marci temporale se realizeaza dupa modelul
urmator:
-
Entitate
T SA

Scheme simple
Definesc doar un mecanism prin care se pot obtine marcile temporale; ele genereaza marci
temporale independente (nu includ informatii din alte marci generate anterior).
Exemple de utilizare al acestui tip de schema sunt cele propuse de standardele elaborate
de IETF n T SP Time-Stamping Protocol (RF C 3161) si de ISO n ISO 18014 2.
Solutia cea mai utilizata de generare a amprentelor de timp se bazeaza pe criptografie,
folosind semnaturile digitale.
Astfel, pentru obtinerea unei marci temporale pentru un document X:

28
1. O entitate finala Alice calculeaza o amprenta h(X), pe care o trimite la T SA.

2. T SA-ul genereaza o marca temporala, atasand timpul curent T la h(X) si semneaza
marca de timp cu cheia sa privata: SigT SA (T, h(X)).
3. T SA-ul trimite lui Alice aceasta marca generata SigT SA (T, h(X)).
Avantaje:
Simplitate
Clientul poate verifica singur marca de timp: orice entitate care verifica marca
temporala trebuie de fapt sa verifice semnatura generata de T SA.
Dezavantaje:
Necesita ncredere absoluta n Autoritatea de Marcare Temporala; este motivul
principal pentru care schemele simple prezinta un nivel scazut de securitate. Haber
si Stornetta au aratat ([12]) ca, daca T SA modifica n mod fraudulos parametrul T
pentru a antedata un document, nimeni nu poate detecta acest lucru.
Posibilitatea de compromitere a cheii private de semnatura; n acest caz toate
marcile temporale generate cu cheia respectiva devin invalide.
Pentru generarea marcilor de timp independente (cu scheme simple), ISO 18014 2
ofera alte doua solutii: utilizarea codurilor de autentificare (M AC) si utilizarea obiectelor
arhivate.
Aceste metode se bazeaza pe realizarea unor blocuri M AC (n care T SA-ul foloseste o
cheie simetrica pentru autentificare) sau pe stocarea unor obiecte ce reprezinta o legatura
ntre documentul care trebuie marcat si timpul marcarii.
Ambele metode au dezavantajul ca la verificarea marcilor trebuie implicata si Autoritatea de Marcare Temporala.
Schemele cu nl
antuire
Aceste scheme ncearca sa micsoreze necesarul de ncredere acordat T SA-ului si problemele de compromitere a cheii private a acestuia prin legarea ntre ele a amprentelor de
timp generate.
Schemele includ n marca temporala generata anumite informatii referitoare la marcile
temporale generate anterior. In acest fel se poate crea un lant de marci temporale care
depind una de cealalta si stopeaza posibilitatea T SA-ului de a antedata documente.
Securitatea sistemului creste, dar procesul de verificare a marcilor necesita participarea T SA-ului, ceea ce complica implementarea Autoritatii de Marcare si modelul de
functionare al schemelor.
Exista mai multe abordari de implementare pentru schemele nlantuite:
TEMPORALA
29
scheme cu nlatuire liniara;

scheme cu nlantuire bazate pe arbori de autentificare Merkle;
scheme cu nlantuire bazate pe arbori binari: ISO 18014 3, schemele HaberStornetta ([12]), schema Bayer ([4]), schema Benaloh - De Mare ([5]), schema Buldas
([8]) etc.
Schemele cu legaturi functioneaza n general n trei pasi:
1. Agregarea: toate documentele primite de T SA ntr-un interval scurt de timp sunt
considerate simultane si vor fi colectate de T SA pentru a fi prelucrate mpreuna.
Prin agregare se obtine un sir binar (marca temporala) calculat pe baza documentelor simultane.
Scopul pasului de agregare este de a scadea ncarcarea T SA-ului.
antuirea: urmareste obtinerea unui lant ordonat ntr-un singur sens (one way)
2. Inl
ntre valorile obtinute la pasul de agregare.
Rezultatul pasului de agregare curent este folosit pentru a fi legat de rezultatul
pasului de agregare anterior.
Prin acest mecanism se obtine o autentificare temporala relativa: rezultatele rundelor de agregare pot fi comparate ntre ele n ceea ce priveste ordinea.
Operatia de nlantuire (de legare) se poate face de exemplu folosind functii de dispersie. Daca se doreste doar garantarea ordinii documentelor, valoarea efectiva de
timp nu este neaparat necesara n schemele cu nlantuire.
3. Publicarea: pentru a-i putea audita activitatea si a creste astfel securitatea, T SA-ul
publica periodic (de exemplu lunar) ultima legatura obtinuta la pasul de nlantuire.
In acest fel T SA-ul nu mai poate interveni n lantul creat pana la ultima legatura
publicata, pentru a antedata de exemplu un document.
Schema propusa de Haber-Stornetta este una din cele mai simple si folosite scheme
cu legaturi. Ea se bazeaza pe utilizarea unei functii de dispersie criptografica (pentru
nlantuirea amprentelor de timp generate) si pe semnatura digitala (pentru autentificarea
marcilor).
Astfel, pentru cel de-al n-lea document, Hn = h(X) primit de T SA pentru marcare,
amprenta de timp generata va fi
SigT SA (n, Tn , IDn , Hn , Ln )
unde Tn este timpul curent, IDn este identificatorul clientului, iar Ln este informatia de
legatura cu marcile generate anterior, fiind definit recursiv de formula:
Ln = (Tn1 , IDn1 , Hn1 , h(Ln1 ))

30
In opinia autorilor singura solutie de a ataca schema este aceea de a falsifica un lant
suficient de lung de legaturi.
Pentru a prentampina acest lucru, pasul de publicare devine obligatoriu .
Publicarea nu este eficienta daca se face pentru fiecare marca generata.
De aceea schemele cu legaturi sunt totusi vulnerabile n intervalul petrecut de la ultima
publicare pana la urmatoarea publicare. In acest interval, un T SA compromis poate
antedata orice document si poate reface lantul de legaturi.
O solutie de auditare ar putea fi realizata doar cu colaborarea tuturor clientilor din
acest interval, ceea ce nu este deloc practic.
Schemele distribuite
Sunt obtinute prin utilizarea mai multor T SA-uri pentru generarea amprentelor de timp.
In acest mod ncrederea ntr-un singur T SA poate fi redusa.
Pentru falsificarea unei amprente de timp a unui document trebuie sa colaboreze mai
multe T SA-uri.
Schemele distribuite pot fi obtinute prin combinarea schemelor simple si a schemelor
nlantuite. De exemplu, o schema distribuita se poate obtine prin serializarea unei scheme
simple cu o schema nlantuita care ruleaza la doua T SA-uri diferite.
Schemele distribuite prezinta cel mai mare grad de securitate, dar au o complexitatea
ridicata. In consecinta fiabilitatea sistemului scade, deoarece toate componentele sale
trebuie sa fie functionale.
Exemple de scheme distribuite putem gasi n [1], [7].
2.5.2
Problemele schemelor de marc

a temporal
a
Nici una din schemele de marca temporala prezentate nu este perfecta, fiecare din ele
avand avantajele dar si dezavantaje sale. In [20] sunt indicate o serie de probleme cu care
se confrunta schemele actuale de marca temporala:
Schemele simple nu prezinta control asupra parametrului de timp. Din aceasta
cauza nu exista posibilitatea de a contracara un comportament fraudulos al T SAului, acesta putand antedata documentele.
Caracterul on-line caracteristic T SA-urilor face ca acestea sa devina vulnerabile la
problemele specifice acestui tip de serviciu: atacuri de intruziune, disponibilitatea
serviciilor, resurse de retea redundante etc.
In cazul schemelor cu nlantuire, T SA-ul poate antedata documente n intervalul
dintre pasii de publicare. Singura solutie de verificare a procesului ar fi prin identificarea si colaborarea tuturor utilizatorilor sistemului din acest interval, ceea ce face
schema nepractica.
TEMPORALA
31
Metoda cea mai folosita pentru generarea marcilor de timp se bazeaza pe semnaturi
digitale. In cazul schemelor simple, compromiterea cheii private invalideaza toate
marcile generate. Pentru schemele cu nlantuire, sunt invalidate toate marcile care
nu au fost nca incluse n legatura publicata.
La schemele cu legaturi, pentru verificarea lanturilor de amprente, acestea trebuie
arhivate pe o perioada suficient de mare, iar operatia de verificare necesita implicarea
T SA-ului.
Datorita faptului ca n general procesul de marcare temporala se bazeaza pe un
singur serviciu T SA, schemele devin vulnerabile la atacuri de tip Denial-of-Service.
Este foarte greu de implementat solutii de balansare a cererilor bazate pe servicii
T SA redundante, deoarece marcile de timp trebuiesc corelate.
Pasul de publicare necesar schemelor de nlantuire nu este ntotdeauna usor de
realizat. In general pentru procesul de publicare sunt preferate diverse mijloace
cum ar fi reviste sau ziare cu circulatie publica, iar n acest caz publicarea nu poate
fi automatizata.
Nu toate schemele sunt echivalente ca nivel de securitate. Anumite scheme sunt
succeptibile la diverse atacuri.
Tehnic, schemele de marcare sunt bazate pe primitive criptografice cum ar fi functiile
de dispersie criptografica sau criptografia cu chei publice.
Compromiterea acestora implica automat si compromiterea schemelor de marcare.
Inter-operabilitatea constituie o alta problema a schemelor. Pentru foarte multe
scheme, formatul cererilor, al marcilor de timp si al legaturilor nu sunt bine specificate.
Standardul T SP (RF C 3161) trateaza doar schemele simple, propunand un format
ASN.1 pentru cereri si marcile temporale. In [29] este o propunere mai generala
bazata pe formate XM L (care acopera si mecanisme de nlantuire), nsa nu exista
nca un standard n acest sens.
In acest moment majoritaea aplicatiilor sunt bazate pe standardul T SP , iar unele
autoritati de marcare temporala folosesc si elemente de nlantuire.
Schemele distribuite prezinta cel mai bun grad de securitate, nsa acestea sunt greu
si scump de implementat practic. Verificarea marcilor presupune implicarea tuturor
T SA-urilor din cadrul sistemului de marcare.
Cerintele actuale privind realizarea semnaturilor digitale obliga folosirea marcilor
temporale pentru a garanta validitatea semnaturilor electronice pe termen lung

32
(ETSI 101 733). Infrastructurile P KI sunt afectate de necesitatea unui serviciu

T SA de tip on-line deoarece scade din scalabilitatea si usurinta de folosire.
2.5.3
Standardizarea serviciilor de marc

a temporal
a
ISO (International Organization for Standardization) a abordat problematica serviciilor

de marcare temporala n suita de standarde ISO 18014.
Conform acestora, entitatile implicate ntr-un serviciu de marcare temporala sunt:
1. o Autoritate de Marcare Temporala (T SA), definita ca tert de ncredere care ofera
dovezi ca anumite date au existat la un moment de timp dat si garanteaza corectitudinea parametrului de timp.
2. un client: entitatea care este n posesia datelor si doreste ca acestea sa fie marcate
temporal.
3. un verificator: entitatea care confirma validitatea unei marci temporale.
Conform standardului ISO 18014 1 exista doua protocoale de marca temporala:
Protocolul de emitere:
1. Clientul trimite o cerere de marcare temporala.
2. T SA verifica formatul cererii si genereaza marca temporala.
3. T SA returneaza spre client marca generata.
Marca temporala contine cel putin un parametru de timp si o amprenta a datelor
pentru care se genereaza marca, legate ntre ele printr-o tehnica criptografica.
Protocolul de verificare:
1. Verificatorul lanseaza procedura de verificare a unei marci temporale.
2. Daca si de cate ori este necesar, el solicita Clientului si T SA-ului informatii
suplimentare.
3. Pe baza tuturor informatiilor primite, Verificatorul controleaza marca temporala.
Celelalte doua parti ale standardului ISO prezinta cateva modalitati de legare a amprentei
datelor cu parametrul de timp, folosind diferite tehnici criptografice.
ISO 18014 2 defineste trei mecanisme de generare a amprentelor de timp independente, specifice schemelor simple:
TEMPORALA
33
1. folosind semnaturile electronice pentru asigurarea autenticitatii si integritatii

marcilor emise model preluat din PKIX TSP (RF C 3161);
2. pe baza de M AC-uri si cu chei simetrice: asigura garantarea integritatii si
autenticitatii marcilor;
3. pe baza de obiecte arhivate; n acest caz, T SA-ul ntoarce clientului ca marca
temporala numai o referinta cu un identificator al datelor marcate.
Ultimele doua solutii necesita ca verificatorul sa obtina de la T SA anumite informatii
pentru verificare:
- In cazul bazat pe M AC-uri, verificatorul trimite T SA-ului marca iar T SA-ul
ntoarce raspunsul cu privire la integritatea si autenticitatea acesteia.
- La utilizarea de obiecte arhivate, verificatorul cere T SA-ului direct parametrul de
timp asociat cu identificatorul primit.
In toate situatiile, verificatorul trebuie sa aiba ncredere deplina n T SA.
ISO 18014 3 defineste mecanisme de generare a amprentelor de timp cu legatura.
Aici sunt construiti cei trei pasi specifici schemelor nlantuite: agregarea, nlantuirea
si publicarea.
Niciuna din cele trei componente ale standardului ISO nu face referire la schemele distribuite.
P KIX Time-Stamp Protocol (T SP )
T SP -ul propus de IET F P KIX n standardul Internet RF C 3161 este cel mai raspandit
protocol utilizat n aplicatiile si serviciile de marcare temporala existente. El foloseste
schema simpla de generare a amprentelor de timp si se bazeaza pe mecanismul de semnatura digitala pentru garantarea autenticitatii si integritatii marcilor de timp emise de
T SA.
Standardul defineste T SA-ul ca fiind un T T P care creeaz
a m
arci temporale pentru a
indica faptul ca anumite date au existat la un moment particular de timp.
Modelul tranzactional propus este de tip client - server. Clientul face o cerere catre
T SA, n care transmite amprenta h(X) corespunzatoare documentului care trebuie marcat
si obtine marca temporala SigT SA (h(X), T ).
Pe langa detaliile legate de formatul cererilor si raspunsurilor, standardul defineste si
conceptul de politica de marcare temporala.
Aceasta reprezinta un set de reguli de functionare a T SA, elementele care tin de securitatea serviciului, mecanismele de gestiune a cheii private a T SA, algoritmii de dispersie
criptografica acceptati, algoritmul de semnatura folosit, acuratetea parametrului de timp
etc.
34

Un T SA poate functiona dupa una sau mai multe politici care trebuie sa fie clar definite, publicate si unic identificabile prin intermediul unui ObjectIdentifier (OID). Clientul
poate alege n cerere una din politicile T SA-ului sau l poate lasa pe acesta sa foloseasca
una din politicile sale.
Standardul stabileste si cateva cerinte de securitate asupra T SA-ului:
foloseste o sursa de timp exacta si de ncredere;
include informatia de timp de ncredere n fiecare marca de timp emisa;
accepta din partea clientului numai cereri de marcare bazate pe una dintre politicile
sale de functionare;
verifica si accepta din partea clientului numai functii de dispersie considerate de
ncredere la momentul cererii;
nu asociaza parametrul de timp niciodata cu datele ci doar cu amprenta acestora;
semneaza fiecare token de timp emis ca raspuns si foloseste o cheie dedicata n acest
sens;
identifica n mod unic fiecare marca de timp emisa, folosind numere ntregi;
pastreaza caracterul anonim al clientului; marca de timp generata nu trebuie sa
identifice n nici un fel clientul.
Standardul propune mai multe mecanisme posibile de transport bazate pe protocoalele
HT T P, F T P, eM ail sau T CP/IP . In practica, standardele de securitate care folosesc
protocolul T SP pentru obtinerea marcilor temporale necesare aleg de obicei varianta
HT T P .
Protocolul descris n RF C3161 prezinta cateva slabiciuni care se pot transforma n
falii de securitate ([27]):
1. Nu se precizeaza nici un mecanim de protectie mpotriva unui comportament fraudulos al T SA-ului. Este folosita schema simpla de generare a marcilor, schema care
este cea mai putin sigura din acest punct de vedere. Verificatorii trebuie sa accepte
T SA-ul ca fiind de ncredere n totalitate.
Implementarile T SA pot fi mbunatatite prin adaugarea unor mecanisme specifice
schemelor nlantuite, nsa standardul nu contine nici un astfel de element pentru a
asigura un nivel de interoperabilitate n acest sens.
2. Standardul nu prevede alte metode mai rapide comparativ cu semnatura pentru
obtinerea marcilor temporale. Operatia de semnare este mare consumatoare de timp
ceea ce face sistemul vulnerabil la atacuri de tip Denial-of-Service.
TEMPORALA
35
O solutie ar putea fi utilizarea unor acceleratoare criptografice specializate, care sa

sporeasca viteza de rezolvare a cererilor din partea T SA.
3. Compromiterea cheii private invalideaza toate token-urile de timp generate cu ea.
Siguranta sistemului depinde practic de securitatea acestei chei. De aceea, implementarile T SA trebuie sa aiba n vedere masuri speciale de protectie a cheii, bazate
pe dispozitive speciale de tip HSM (Hardware Secure Module) si pe mecanisme de
acces dual de tip K-din-N cu roluri atent definite si controlate, ceea ce presupune
costuri ridicate de implementare si operare pentru T SA.
4. Daca nu este folosit corect, protocolul poate fi vulnerabil la atacuri de tip replay.
Pot fi mai multe scenarii n care poate fi executat atacul: un document trebuie
datat de mai multe ori, sau datarea unui document nu s-a putut face dintr-un
anumit motiv si trebuie retransmis etc.
Un atacator poate ntoarce n aceste situatii un raspuns cu un parametru de timp
nvechit. Protocolul contine suport pentru mecanismul clasic de protectie la acest
atac, bazat pe informatia de tip nonce, nsa utilizarea sa este optionala.
Cealalta solutie (sugerata n standard) care foloseste o fereastra glisanta de timp
este nepractica deoarece se bazeaza pe o sursa locala de timp, care poate fi total
dereglata si n plus complica destul de mult implementarile clientilor.
5. Standardul nu reglementeaza suficient de bine componenta de politica a T SA.
Aceasta este doar amintita, nefiind detaliate aspecte utile cum ar fi: ce elemente
minime trebuie sa contina o politica, numarul de politici pe care trebuie sa le accepte
un server, cum poate afla un client politicile oferite de un T SA etc.
Forul de standardizare European ET SI reglementeaza o parte din aceste aspecte
prin specificatia ETSI 102 023.
6. Standardul nu prevede mecanisme proprii de autentificare a clientilor.
De exemplu, pot exista cerinte ca un serviciu T SA sa fie disponibil numai unor clienti
care platesc un abonament. In astfel de scenarii trebuie implementate mecanisme
proprietare de gestiune a clientilor respectivi.
O solutie poate fi bazata pe un serviciu de tip proxy care sa intermedieze relatia
clientilor cu T SA-ul si care va implementa mecanismele de identificare, autentificare
si contorizare a cererilor sosite. Autentificarea se va face prin mecanisme externe
protocolului T SP de exemplu folosind protocolul T LS (RF C 5246).
7. Raspunsurile de eroare sunt vulnerabile la atacuri de tip Man-in-the-Middle deoarece
nu sunt semnate de T SA. Un atacator poate intercepta astfel de atacuri si poate
modifica informatiile din raspuns (poate schimba, de exemplu motivul erorii).

36
Aceasta vulnerabilitate a protocolului poate fi exploatata si sub forma unui atac

de tip Denial-of-Service, caz n care toate raspunsurile corecte ale T SA-ului vor fi
convertite n raspunsuri de eroare.
2.6
Servicii de Arhivare Digital

a
Definitia 2.4. Un serviciu de arhivare digital

a are ca obiectiv principal salvarea documentelor digitale si pastrarea lor n sigurant
a pentru o anumit
a perioad
a de timp.
Exemplul 2.4. Perioada de utilizare a unor informatii semnate electronic poate fi mai
lung
a dec
at perioada de valabilitate a certificatelor de chei publice utilizate la verificarea
semn
aturii sau n raport cu perioada de criptanaliz
a a algoritmilor criptografici folositi la
generarea semnaturii.
Orice mecanism de arhivare electronica trebuie sa ia n considerare: durata de viata a
mediilor de stocare, mecanisme de disaster-recovery, cresterea capacitatii de criptanalizare
a algoritmilor dar si a puterii de calcul, modificarile care apar la nivel de tehnologie
hardware sau software.
Sistemele de arhivare de ncredere detin mecanisme de stocare a datelor ntr-un mod
care sa asigure si dovezile necesare privind integritatea lor. Dovezile de integritate sunt
generate/obtinute periodic pentru a forma un lant continuu care sa garanteze integritatea
datelor de la momentul arhivarii acestora pana la data verificarii lor.
Exista mai multe scheme care trateaza problema arhivarii pe termen lung. In general
acestea urmaresc disponibilitatea datelor pe termen lung, nsa pierd din vedere alte aspecte
importante cum ar fi migrarea formatelor datelor n timp, astfel ncat acestea sa poata fi
compatibile cu noile implementari hardware si software.
2.6.1
Cerintele unui serviciu de arhivare pe termen lung
Cerintele de functionare formulate asupra unui serviciu de arhivare pot sa difere n raport
cu utilizatorii care folosesc serviciul respectiv si cu necesitatile acestora.
Cateva cerinte generale specifice unui serviciu de arhivare pe termen lung (RF C4810):
1. Un serviciu de arhivare trebuie sa permita clientilor sai realizarea operatiilor de baza
privind:
(a) depunerea datelor pentru a fi arhivate;
(b) obtinerea datelor din arhiva;
(c) stergerea datelor din arhiva (optional).
Datele pot fi transmise n diverse forme (date brute, date semnate si/sau criptate
etc.) si folosind diverse formate de prezentare (documente PDF, XML, Microsoft
Office Word, PPT etc.).

2.6. SERVICII DE ARHIVARE DIGITALA
37
La receptionarea datelor care urmeaza sa fie arhivate, serviciul furnizeaza clientului

un identificator unic asociat cu datele respective.
Acesta va fi apoi folosit pentru identificarea, obtinerea sau stergerea datelor din
arhiva. Autentificarea clientilor n vederea realizarii acestor operatii poate fi o
cerinta suplimentara la nivelul serviciului. In acest sens, anumite operatii pot fi
de uz general (de exemplu, obtinerea datelor), sau pot fi permise numai entitatilor
autorizate (stergerea datelor).
2. Garantarea integritatii datelor arhivate.
Integritatea trebuie asigurata pe toata perioada de arhivare, iar serviciul este responsabil de asigurarea dovezilor care pot demonstra aceasta proprietate.
Dovezile pot fi generate intern de serviciul de arhivare sau pot fi obtinute de la un
serviciu de ncredere extern.
3. Functionarea n concordanta cu o politica de arhivare.
Aceasta defineste caracteristicile de implementare pentru serviciul respectiv si are
mai multe componente: politica de mentenanta a obiectelor arhivate, politica de
autorizare a clientilor serviciului, politica de securitate a serviciului de arhivare etc.
Un serviciu de arhivare poate avea n uz mai multe politici.
4. Pe langa operatiile principale (depunerea, obtinerea sau stergerea datelor din arhiva),
serviciul trebuie sa permita clientilor sai specificarea altor elemente care privesc
datele arhivate: informatiile de tip meta-data asociate cu datele arhivate, politica de arhivare folosita, perioada de arhivare a datelor, posibilitatea de extindere a
acestei perioade etc.
5. Asigurarea confidentialitatii datelor arhivate.
Un client poate cere ca datele respective sa ramana confidentiale chiar si fata de
serviciul de arhivare. Aceasta cerinta este destul de dificil de ndeplinit, deoarece serviciul trebuie sa asigure n timp operatiile de conservare a datelor originale (necriptate), fara a avea acces la ele.
6. Metode de transfer a datelor arhivate si a dovezilor asociate catre un alt serviciu de
arhivare.
Acest lucru este necesar de exemplu la ncetarea activitatii serviciului nainte de
terminarea perioadei de arhivare a datelor si prin cedarea serviciilor sale catre un
alt serviciu.
Un alt caz de acest gen poate fi n situatia cand un client doreste sa-si mute datele
arhivate de la un serviciu de arhivare la altul.
7. In unele situatii obiectele de date arhivate nu pot fi independente ci fac parte dintrun grup.

38
Ca exemple: o semnatura digitala mpreuna cu documentul semnat, sau un document mpreuna cu o serie de traduceri ale sale. In aceste cazuri operatiile de arhivare
trebuie realizate nu pentru un singur obiect, ci pentru un grup de obiecte arhivate.
8. Eficienta serviciului.
Serviciile de arhivare pot avea cantitati mari de date arhivate pe care trebuie sa le
gestioneze ntr-un mod eficient. Operatiile de conservare a datelor si de (re)generare
a dovezilor de integritate pot fi costisitoare ca timp, putere de calcul si resurse de
stocare. O solutie eficienta n acest sens este furnizata n RF C 4998.
9. Asigurarea non-repudierii originii datelor poate fi de asemenea un obiectiv al unui
serviciu de arhivare.
Pot fi folosite mecanisme specifice protocoalelor de non-repudiere, cu sau fara implicarea altor T T P -uri.
2.6.2
Tehnici pentru asigurarea integrit

atii datelor
Anumite tehnici criptografice (functiile de dispersie criptografica, semnaturile digitale)

pot asigura integritatea datelor, dar securitatea lor depinde de rezistenta la procedeele de
criptanaliza care evolueaza si se perfectioneaza n timp.
Cheile de semnatura, lungimile amprentelor (prin aplicarea functiilor de dispersie)
devin la un moment dat ineficiente n raport cu puterea de calcul.
Cand discutam de arhivare pe termen lung trebuie sa avem n vedere perioade de la
cativa ani la cateva decenii. In acest timp, cu siguranta mecanismele criptografice amintite
si pot pierde proprietatile de securitate necesare pentru garantarea integritatii datelor.
Tehnici de baz
a folosite de sistemele de arhivare
Una din primele metode folosite pentru asigurarea integritatii datelor a fost replicarea.
Metoda presupune generarea mai multor replici (clone) ale datelor iar integritatea
acestora este validata prin compararea replicilor si luarea unei decizii pe baza de vot
majoritar. Daca nu exista erori n faza initiala de replicare, orice modificare survenita
la nivelul datelor poate fi detectata (daca nu a fost realizata pe un numar majoritar de
replici).
Sistemele de arhivare PASIS ([28]) si SafeStore ([16]) folosesc aceasta idee a descentralizarii datelor. Un atacator trebuie sa compromita un numar suficient de replici pentru
a deveni o amenintare reala.
Metodele bazate pe descentralizare si replicare asigura foarte bine existenta datelor
arhivate si accesul la ele, nsa nu ofera mecanisme de protectie fata de nvechirea algoritmilor criptografici. De exemplu, daca arhiva contine documente semnate acestea nu pot fi
protejate pe termen lung. In plus, implementarile pot deveni scumpe iar verificarile sunt
consumatoare de timp (daca sistemul arhiveaza cantitati mari de date).

39
Functiile de dispersie criptografica pot constitui o solutie privind integritatea datelor.

La introducerea unui document n arhiva este generata si salvata si amprenta acestuia. Verificarea integritatii documentului presupune recalcularea acestei amprente si
confruntarea ei cu informatia salvata initial.
Solutiile Plutus ([17]) si SN AD ([23]) folosesc acest mecanism.
Tehnicile mentionate nu pot rezolva problemele privind integritatea documentelor pe
termen lung. Ele pot fi nsa folosite pentru a construi alte mecanisme mai sigure n acest
sens.
O abordare posibila foloseste o combinare a mecanismelor de replicare cu cele de
dispersie.
Fiecare obiect de date arhivat este replicat pe mai multe arhive. Verificarea integritatii
unui obiect se poate face prin calcularea amprentelor tuturor replicilor obiectului si trimiterea lor catre un auditor. Acesta va lua o decizie folosind o schema simpla de vot
majoritar.
Proiectul LOCKSS ([24]) foloseste un astfel de mecanism.
Desi sunt mult mai costisitoare ca timp de calcul, semnaturile electronice constituie
un mecanism puternic care poate fi folosit pentru garantarea integritatii datelor.
Fiecare obiect arhivat poate fi semnat pe baza unei chei private a sistemului de arhivare.
Verificarea integritatii presupune validarea semnaturii respective pe baza certificatului
digital asociat.
Problema principala este legata atat de rezistenta n timp a algoritmilor de semnatura
folositi, dar si de valabilitatea certificatului folosit la verificare. In plus, compromiterea
cheii private a sistemului de arhivare va compromite ntreaga arhiva.
Formatele de semnatura electronica avansate propuse de ET SI (European Telecommunications Standards Institutei) iau n calcul aspectul rezistentei semnaturilor electronice n
timp. Formele de semnatura CAdES A (ETSI 101 733) si XAdES A (ETSI 101 903)
contin campuri speciale pentru arhivarea pe termen lung bazata pe marcarea temporala
periodica.
In vederea micsorarii complexitatii operatiilor de generare/verificare a informatiei de
control (dovezilor), semnaturile electronice pot fi nlocuite cu mecanisme de tip M AC,
dar riscul privind compromiterea cheii secrete ramane la fel de mare.
Trusted Archive Protocol (T AP )
T AP Trusted Archive Protocol ([10]) este o propunere dezvoltata de grupul de lucru
IT EF P KIX care foloseste marci temporale pentru asigurarea integritatii datelor arhivate.
T AP introduce conceptul de Autoritate de Arhivare de Incredere

(T AA Trust Archive
Authority) ca fiind componenta centrala a unui sistem de arhivare de ncredere. T AA
accepta date (de orice tip) pentru arhivare si asigura dovezile necesare pentru garantarea
integritatii acestora.

40
Modelul arhitectural propus de Trusted Archive Protocol este:

(1)Client
(2)
TTP
T AA - T SA
(3)Client
(4)
unde:
1. Clientul trimite o cerere de arhivare a datelor (inclusiv datele care trbuie arhivate).
2. T AA raspunde la cererea de arhivare, trimitand printre altele si un token de
arhivare.
3. Clientul face o cerere de obtinere a datelor (incluzand tokenul de arhivare).
4. T AA raspunde la cerere, incluzand tokenul de arhivare, nregistrarea de arhivare si
datele solicitate din arhiva.
Modelul foloseste schema T T P (RF C 3161) pentru obtinerea marcilor temporale necesare
n vederea garantarii integritatii datelor. Protocolul este de tip client - server sincron, iar
tranzactiile din cadrul protocolului sunt bazate pe mesaje CM S (RF C 3852). Toate
raspunsurile primite din partea T AA sunt semnate electronic, fiind ncapsulate ntr-o
structura de tip SignedData.
Toate datele pentru structurile definite n T AP sunt descrise folosind notatia ASN.1
(ISO 8824).
Datele arhivate sunt pastrate mpreuna cu dovezile de arhivare ntr-un Pachet de
Arhivare. Acesta contine:
Datele primite de la client.
Un token de arhivare, generat de T AA la momentul arhivarii datelor. El este
furnizat clientului ca raspuns la depunerea datelor, pentru a putea identifica si
realiza operatii ulterioare asupra datelor arhivate (obtinerea, stergerea datelor din
arhiva etc.).
Inregistrarea de arhivare, cu informatia criptografica actualizata de T AA prin care se
asigura integritatea datelor. Aceasta este o structura de marci temporale imbricate.
Initial structura contine marca temporala calculata pentru datele transmise pentru
arhivare. La fiecare actualizare, nregistrarea de arhivare cea mai recenta devine
subiectul unei noi marcari temporale.

41
Protocolul T AP nu trateaza decat cateva aspecte legate de arhivele pe termen lung. O

serie de alte elemente cum ar fi formatul datelor sau migrarea acestuia n timp nu
sunt acoperite de protocol. La nivelul protocolului nu pot fi definite roluri, atributii sau
alte elemente care sa permita implementarea unor operatii de autentificare, autorizare,
taxare a serviciului etc.
De asemenea propunerea de protocol nu contine nici un suport pentru informatii de tip
meta-data (cuvinte cheie, categoria datelor, formatul datelor etc.). Acestea sunt esentiale
pentru gestiunea datelor n cadrul unui sistem de arhivare.
Schema folosita pentru gestiunea dovezilor de arhivare (nregistrarile de arhivare)
prezinta si ea cateva probleme:
Numarul de marci temporale necesar este destul de mare.
Pentru fiecare obiect de date, T AA trebuie sa obtina cel putin o marca temporala
initiala (asociata cu datele arhivate), dupa care aceasta trebuie rennoita ori de cate
ori este nevoie. Astfel, dimensiunile structurilor cu nregistrarile de arhivare pot
creste foarte mult.
Folosirea schemei de marcare descrisa de RF C 3161 implica un nivel de ncredere
deplin n Autoritatea de Marcare Temporal
a (T SA) folosita.
Ar trebui avute n vedere si alte mecanisme de marcare temporala, mai sigure din
acest punct de vedere, cum ar fi de exemplu cele bazate pe schemele nlantuite.
Garantarea integritatii unui document semnat digital se bazeaza tot pe validarea
unei semnaturi (cea din marca temporala).
Evidence Record Syntax
Standardul Internet ERS Evidence Record Syntax (RF C 4998) prezinta o propunere
eficienta de generare a dovezilor necesare pentru garantarea integritatii datelor ntr-un
sistem de arhivare pe termen lung.
ERS se bazeaza pe conceptul de marca temporala mbunatatita. Aceasta este o
combinatie realizata ntre arbori de dispersie si o marca temporala obisnuita. Fiecare arbore este construit pentru un grup de date arhivate. Frunzele arborilor contin amprentele
obiectelor de date arhivate, iar celelalte noduri contin amprente ale informatiei obtinute
prin concatenarea dispersiilor descendentilor. Dupa construirea fiecarui arbore, marca
temporala este aplicata numai nodului radacina.
In acest fel marca de timp nu protejeaza un singur obiect, ci un grup ntreg de obiecte
arhivate.
Pentru formatul marcilor temporale se poate folosi sintaxa propusa n RF C 3161.
Structurile de date astfel obtinute poarta numele de m
arci temporale mbun
at
atite.
Modelul este exemplificat n figura de mai jos.

42
Verificarea unei marci temporale mbunatatite pentru un obiect de date Di presupune

urmarirea drumului de la amprenta documentului verificat pana la nodul radacina din
arbore si validarea marcii temporale aplicate acestuia.
Marca temporala
T SP

SigT SA (h(a5 ka6 ), T )
Arbore de
amprente
T SA
a5 = h(a1 ka2 )
a6 = h(a3 ka4 )
> I
I
a1 = h(D1 )
6
Document
D1
a2 = h(D2 )
a3 = h(D3 )
Document
D2
Document
D3
a4 = h(D4 )
6
Document
D1
Astfel, pentru verificarea integritatii documentului D1 se va testa h(h(a1 ka2 ), a6 )

T SA.
Arborele de amprente marcat temporal constituie punctul de pornire pentru generarea
dovezilor.
Pentru fiecare document din arhiva nu se salveaza ntreg arborele, ci numai o forma redusa.
Arborele redus pentru un document este de fapt o lista de liste cu amprente selectate din
arborele initial, suficiente pentru a putea reface lantul pana la marca temporala.
De exemplu, pentru documentul D1 , arborele redus este
a1 = h(D1 )
a2 = h(D2 )
a6 = h(a3 , a4 )
Periodic marcile temporale si arborii de dispersie trebuie regenerati (re-nnoiti). Motivul este deprecierea n timp a proprietatilor de securitate ai algoritmilor si parametrilor
folositi la generarea marcilor de timp si a nodurilor arborelului (functii de dispersie, algoritmi de semnatura, lungimi de chei).
Regenerarea se face doar pentru marcile temporale aplicate nodurilor radacina sau
pentru tot arborele de dispersie.
Rennoirea marcilor temporale se face n situatia cand algoritmul de semnatura sau
cheia privata folosite de T SA devin slabe. Avand n vedere ca marca temporala veche
2.7. SERVICII DE DIRECTOARE
43
include deja toate amprentele documentelor din arbore, procesul de rennoire este foarte
eficient, iar documentele referite nu mai trebuie ncarcate de pe mediile de stocare pentru
a li se recalcula amprentele.
Sistemul de arhivare va calcula doar amprenta marcii temporale vechi si o va insera ntr-un
arbore nou, pentru care va obtine o marca temporala actualizata.
Rennoirea unui arbore de amprente se face n situatia cand algoritmul de dispersie
utilizat devine nesigur. Operatia de nlocuire a functiei de dispersie este costisitoare,
deoarece necesita refacerea amprentelor tuturor documentelor implicate.
Sistemul de arhivare trebuie sa pastreze lantul complet de dovezi generate pentru fiecare
document de la momentul initial al depunerii sale n arhiva. Din acest motiv regenerarea
fiecarui arbore va tine cont atat de amprenta documentului cat si de amprenta ultimului
arbore redus calculat.
Pentru siguranta sistemului de arhivare este recomandat sa se genereze doua structuri
arborescente paralele, folosind functii de dispersie diferite (de exemplu SHA 256 si
RIP EM D 160). Daca una din ele va fi compromisa, cealalta ofera ragazul necesar
pentru rennoire.
Stergerea unui document din arhiva nu influenteaza restul arhivei. Toate celelalte
documente pot fi verificate folosind pentru fiecare, arborele sau redus.
Relativ la formatul datelor pentru structurile definite n ERS (RF C 4998), acestea
sunt descrise folosind notatia ASN.1 (ISO 8824).
2.7
Servicii de Directoare
Exista multe situatii n care serviciile de securitate se bazeaza pe informatii cum ar fi

certificate de chei publice, liste de certificate revocate, certificate de atribute sau copii de
registre electronice furnizate prin intermediul unor servicii de directoare.
Pentru accesarea acestor informatii pot fi folosite metode de identificare unica si clara a
obiectelor din cadrul directoarelor.
Figura de mai jos (ISO 14516) prezinta arhitectura unui serviciu de directoare.
Dupa logarea si autentificarea cu succes, fiecare interogare pentru obtinerea de date
din director este mediata de Sistemul de Autorizare. Daca drepturile de acces ale unei
entitati sunt n concordanta cu regulile de autorizare existente, se va obtine accesul.
Altfel, entitatea va primi un mesaj de eroare.
Incercarile de acces esuate (autorizari nereusite) vor fi jurnalizate.
Managerul de cereri gestioneaza interogarile autorizate. Scopul sau este de a procesa
interogarea, de a accesa baza de date si de a ntoarce raspunsul catre entitate.

44
- Login
Entitate
Profile
-
Auditor
6
6
?
?
-
Serviciu
- Fisiere de log
de autentificare
6
?
Administrator
baza de date
Sistem de
autorizare
Administrator
de securitate
6
?
Manager de cereri
6
?
Baza de date
Nu este obligatoriu ca toate informatiile sa fie localizate ntr-o singura baza de date
locala. Pentru administrarea securitatii serviciului de directoare pot fi definite urmatoarele
roluri (ISO 14516):
1. Administratorul de securitate este responsabil pentru definirea regulilor de autorizare conforme cu politica de securitate adoptata.
In acest sens, regulile de acces pot fi diferite, n functie de scopul serviciului de
directoare (de exemplu, serviciul poate fi de natura publica sau poate fi restrictionat
unei comunitati controlate de entitati care platesc pentru acest serviciu).
2. Administratorul bazei de date este responsabil de ntretinerea acestei componente
a serviciului de directoare. El are drepturi de acces la baza de date si poate scrie,
citi sau sterge informatie din baza de date.
3. Auditorul revede periodic jurnalele din fisierele de loguri pentru a detecta posibilele
intruziuni sau atacuri de securitate.
2.8
Servicii de Notariat Electronic
Serviciile publice de notariat electronic sunt servicii de nivel nalt care folosesc anumite
servicii de baza: servicii de marca temporala, de certificare, de directoare, de arhivare
digitala si non-repudiere etc.
Un document va fi trimis T T P -ului care-l va atesta (sau certifica) utilizand semnaturi
digitale sau alte mecanisme. Un serviciu de directoare poate fi o componenta a serviciului
de unde se pot obtine documentele certificate.
Un serviciu public de notariat poate atesta si certifica anumite clase de documente
(de exemplu faptul ca un document a existat la un anumit moment de timp sau ca este
autentic). Un astfel de serviciu poate fi folosit pentru medierea unei dispute ntre doua
entitati, fiind autorizat n acest sens de o anumita autoritate.
2.8. SERVICII DE NOTARIAT ELECTRONIC
45
Serviciile de notariat electronic lucreaza ca un notar public traditional. Ele pot stoca
documente semnate digital si marcate temporal. Aceste documente vor fi nregistrate
ntr-un registru electronic propriu serviciului notarial.
Exista nsa multe aspecte delicate legate de aceste tipuri de servicii cum ar fi cele
legate de autoritatea si responsabilitatea notarului electronic, de evidenta, jurisdictie si
mai ales legale.
Definitia 2.5. O Autoritate Notarial
a (N A) este un tert de ncredere care nregistreaza
date la un anumit moment de timp si poate verifica corectitudinea unei informatii nregistrate n raport cu politica sa de securitate.
Autoritatea Notariala actioneaza ca un serviciu de nregistrare; acest rol poate fi nsa
extins pentru a functiona si ca serviciu de validare. Atunci cand Autoritatea Notariala face
verificari asupra unui document ea poate adauga informatii noi la documentul respectiv.
In acest mod entitatile care se ncred n N A pot fi sigure ca documentul a fost verificat de
catre Autoritate la un moment dat de timp si este n concordanta cu o anumita politica
a Autoritatii Notariale.
Exemplul 2.5. O Autoritate Notarial
a poate notariza un certificat digital de chei publice
n raport cu o politica de validare.
acest caz N A verifica daca certificatul din cerere este sau nu valid si determina
In
starea de revocare la momentul respectiv. Autoritatea verific
a calea de certificare p
ana
la un punct de ncredere, folosind mecanisme de validare bazate pe CRL-uri, ARL-uri
sau pe servicii de validare on-line de tip OCSP (RF C 2560) sau SCV P (RF C 5055).
Informatiile privind starea certificatului se vor introduce mpreun
a cu o marc
a temporala
de ncredere ntr-un token notarial final.
Exemplul 2.6. Autoritatea Notarial
a poate notariza si date formatate. N A verifica
corectitudinea datelor si creaza tokenul notarial.
acest caz, corectitudinea datelor nu se refer
In
a neap
arat la valabilitatea unei semn
aturi
digitale. Particularitatea acestui aspect depinde de politica de verificare a Autorit
atii
Notariale si de tipul documentului.
De exemplu, documentul poate contine una sau mai multe semn
aturi (n acest caz,
corectitudinea documentului se bazeaz
a pe verificarea acestora), poate contine presupuneri
(corectitudinea se bazeaza pe valoarea lor de adev
ar) sau documentul poate fi de fapt un
contract (iar corectitudinea sa este legat
a de valabilitatea legal
a a documentului).
Autoritatea Notariala poate semna fiecare token notarial emis, folosind o cheie generat
a exclusiv n acest scop si care are mentionat
a aceast
a calitate n certificatul de chei
publice corespunzator.

46
2.9
Servicii de Gestiune a Cheilor
Un serviciu complet de gestiune a cheilor se bazeaza pe urmatoarele servicii primare

(ISO 17770 1): generarea, nregistrarea, certificarea, distribuirea, instalarea, stocarea,
derivarea, arhivarea, revocarea cheilor, precum si scoaterea din evidenta si distrugerea
cheilor.
In plus, se pot folosi si alte servicii de securitate nrudite cum ar fi: controlul accesului,
autentificarea, autorizarea sau marcarea temporala.
Un tert de ncredere on-line poate actiona ca un serviciu de gestiune a cheilor, ca
suport pentru serviciile care folosesc tehnici criptografice.
In functie de modul cum este generat materialul de cheie, serviciul poate actiona ca un
serviciu de distribuire de chei (cand cheia este generata de T T P ), sau un serviciu de
translatare a cheilor (cand cheia este generata de una dintre entitati si transmisa catre
celelaltor entitati prin intermediul T T P -ului).
2.9.1
Serviciul de generare a cheilor
Este folosit pentru generarea ntr-o forma sigura a cheilor necesare anumitor algoritmi criptografici. Generarea de informatie secreta si/sau nepredictibila, cu anumite proprietati,
este fundamentala pentru generarea cheilor.
Obtinerea aleatorismului reprezinta una din componentele cele mai dificile ale unui
sistem de generare de chei criptografice. Numerele aleatoare pot fi generate fie utilizand
un generator de numere pseudo-aleatoare securizat criptografic sau o sursa cu adevarat
aleatoare (T RN G - True Random Number Generator).
Gestiunea numerelor aleatoare presupune generarea lor, validarea gradului de aleatorism,
generarea si validarea parametrilor de domeniu, generarea perechilor de chei si validarea
cheilor publice. Recomandari utile privind numerele aleatoare si implicatiile acestora n
generarea de chei pot fi gasite n RF C 1750.
Atat pentru tehnicile simetrice cat si pentru cele asimetrice, trebuie avut n vedere
urmatoarele aspecte:
cheile posibil slabe pentru algoritmul tintit;
folosirea ntregului spatiu de chei.
2.9.2
Serviciul de nregistrare a cheilor
Aici T T P -ul este o autoritate de nregistrare acreditata, care realizeaza nregistrarea

cheilor pentru entitati. Fiecare cheie nregistrata este asociata cu o entitate.
Acest serviciu presupune mentinerea unui registru de chei si a informatiilor asociate,
ntr-o maniera securizata potrivita (de exemplu: un registru de chei publice pentru cheile
publice ale entitatilor).
2.9. SERVICII DE GESTIUNE A CHEILOR
47
Cheile publice trebuie sa fie certificate de una sau mai multe Autoritati de Certificare.
Pentru a creste disponibilitatea acestui serviciu, cheile certificate ar trebui distribuite pe
mai multe directoare accesibile si de ncredere caz n care directoarele ar trebui sa se
reactualizeze pentru a pastra consistenta.
Serviciile oferite de o autoritate de nregistrare sunt nregistrarea si de-nregistrarea
cheilor.
2.9.3
Serviciul de certificare a cheilor
In acest caz, T T P -ul este o Autoritate de Certificare acreditata care creeaza certificate
de chei. CA-ul marcheaza temporal si semneaza cheile publice sau atribute, pentru a le
valida si autentifica ntr-o infrastructura de chei de ncredere.
Entitatile care folosesc certificatele trebuie sa aiba ncredere ntr-o Autoritate de Certificare comuna.
Cheile certificate pot fi generate fie de un serviciu de generare al T T P - ului fie de
catre entitatea utilizatoare. Serviciul poate include de asemenea rennoirea certificatelor
expirate (re-certificarea).
Sunt importante:
obtinerea dovezii asupra posesiei cheii private din partea presupusului posesor;
obtinerea dovezii asupra validitatii valorii cheii publice candidate (si validitatea
parametrilor acolo unde este cazul).
2.9.4
Serviciul de distribuire a cheilor
Scopul este o distributie securizata a cheilor catre entitatile autorizate.

In functie de politica de securitate a T T P -urilor, cheile pot fi trimise catre alte servicii
T T P , furnizate eventual de acelasi tert de ncredere.
Distribuirea cheilor ntre T T P -uri si ntre T T P -uri si entitati mai ales daca se
folosesc canale nesecurizate trebuie sa foloseasca mecanisme si tehnici criptografice de
securizare.
Un tip mai special de serviciu de distribuire de chei l reprezinta serviciul de translatare
de chei. Rolul acestuia este acela de a translata cheile pentru ditributie ntre entitati, astfel
ca fiecare entitate sa mparta n comun o cheie unica cu Centrul de Translatare a Cheilor.
2.9.5
Serviciul de stocare a cheilor
Furnizeaza stocarea securizata a cheilor utilizate pentru folosirea lor curenta sau pe termen
scurt, sau pentru backup ntr-o locatie fizica separata, pentru a asigura confidentialitatea
si integritatea cheilor.
Este esential ca orice ncercare de compromitere sa fie detectata.
48
2.9.6

Serviciul de derivare a cheilor
Este utilizat pentru a crea un numar potential larg de chei (plecand de la o cheie initiala
secreta numita cheie de derivare), date variabile nesecrete si un proces de transformare.
Cheia de derivare necesita mijloace speciale de protectie, iar procesul de transformare
trebuie sa fie ireversibil si nepredictibil pentru ca n cazul compromiterii unei chei
derivate sa nu fie compromiee cheia de derivare sau alte chei derivate.
2.9.7
Serviciul de arhivare a cheilor
Acest serviciu este similar cu cel de stocare a cheilor, cu deosebirea ca stocarea cheilor se
face pe termen lung.
Serviciul este destinat pentru cheile care trebuie obtinute dupa o perioada mare de
timp pentru o anumita operatie.
2.9.8
Serviciul de revocare a cheilor
Scopul acestui tip de serviciu este de a asigura dezactivarea securizata a cheilor atunci
cand se stie (sau se suspecteaza) ca acele chei sunt compromise.
O lista de chei revocate ar trebui sa fie distribuita regulat. Revocarea unei chei poate
fi ceruta de proprietarul cheii, de o alta persoana autorizata sau de o entitate de ncredere
daca exista orice suspiciune ca acea cheie ar putea fi compromisa.
Conform ISO/IEC 11770 1, fiecare intrare ntr-o lista de revocare a cheilor trebuie
sa includa timpul revocarii, timpul cererii si timpul la care cheia era cunoscuta sau supecta
de a fi compromisa.
In anumite cazuri, revocarea poate fi datorata anumitor restrictii de timp. Trebuie sa
fie un interval mic de timp ntre momentul cererii de revocare si anuntarea listei de chei
revocate. Un T T P poate fi responsabil numai cu revocarea cheilor pentru clientii sai.
2.9.9
Serviciul de distrugere a cheilor
In acest caz, T T P -ul este o autoritate de nregistrare acreditata care furnizeaza servicii
de distrugere a cheilor care nu mai sunt utile.
Acest T T P trebuie sa furnizeze ntai un serviciu de scoatere din evidenta, pentru a
sterge asocierea dintre o cheie si entitatea sa.
Dupa acest pas, se trece la distrugerea efectiva a cheii.
Distrugerea cheii presupune distrugerea tuturor informatiilor care tin de ea, astfel
ncat sa nu existe nici un mijloc de a recupera cheia respectiva. Acest lucru presupune si
distrugerea tuturor copiilor arhivate ale cheii nu nainte de a verifica faptul ca nu mai
exista informatie arhivata protejata de aceasta cheie.
Bibliografie
[1] A. Ansper, A. Buldas, M. Saarepera, J. Willemson Improving the availability of
time-stamping services, The 6th Australasian Conference on Information Security
and Privacy ACISP, 2001.
[2] N. Asokan, M. Schunter, M. Waidner Optimistic protocols for fair exchange, T.
Matsumoto (Ed.), 4th ACM Conference on Computer and Communications Security,
ACM Press, Zurich, 1997.
[3] N. Asokan, V. Shoup, M. Waidner Optimistic fair exchange of digital signatures,
Advances in Cryptology: Proc. of Eurocrypt 99, Vol. 1403 of LNCS, Springer Verlag,
1998.
[4] D. Bayer, S. A. Haber, W. S. Stornetta Improving the efficiency and reliability of
digital time-stamping, In Sequences 91: Methods in Communication, Security, and
Computer Science, Springer-Verlag, 1992.
[5] J. Benaloh, M. De Mare Ecient Broadcast Time-Stamping, Technical Report TRMCS-91-1, Clarkson University, Department of Mathematics and Computer Science,
April 1991.
[6] I. Bica Protocoale si instrumente pentru confidentialitatea si autenticitatea documentelor n retele de calculatoare, Teza de doctorat, Academia Tehnica Militara,
Bucuresti, 2004.
[7] A. Bonnecaze, P. Liardet, A. Gabillon, K. Blibech A Distributed Time Stamping
Scheme, Proc. of the IEEE Conference on Signal and Image Technology and Internet
Based Systems, Cameroon, 2005.
[8] A. Buldas, P. Laud, H. Lipmaa, J. Villemson Time-stamping with binary linking
schemes, Advances in Cryptology CRYPTO 98, Springer-Verlag, August 1998.
[9] T. Coffey, P. Saidha Non-repudiation with mandatory proof of receipt, ACMCCR:
Computer Communication Review, 1996.
49
50
BIBLIOGRAFIE
[10] S. Chokhani, C. Wallace Trusted Archive Protocol, PKIX Internet Draft, February
2003.
[11] D. Lekkas, S. Katsikas, D. Spinellis, P. Gladychev, A. Patel User Requirements of
Trusted Third Parties in Europe. In Proc. of the Joint IFIP WG 8.5 and WG 9.6
Working Conference on User Identification & Privacy Protection, Stockholm, 1999
[12] S. A. Haber, W. S. Stornetta How to time-stamp a digital document, Journal of
Cryptology, Springer-Verlag, 1991.
[13] Y. Han Investigation of non-repudiation protocols, ACISP: Information Security and
Privacy: Australasian Conference, Vol 1172 of Lecture Notes in Computer Science,
Springer-Verlag, 1996.
[14] S. Kremer, O. Markowitch Optimistic non-repudiable information exchange, J.
Biemond (Ed.), 21st Symp. On Information Theory in the Benelux, 2000
[15] S. Kremer, O. Markowitch, J. Zhou An intensive survey of fair nonrepudiation
protocols. Computer Communications 25, 2002.
[16] R. Kotla, M. Dahlin, L. Alvisi SafeStore: A durable and practical storage system.
In Proceedings of the 2007 USENIX Annual Technical Conference, USENIX, June
2007
[17] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang, K. Fu Plutus: scalable secure
file sharing on untrusted storage. In Proc. of the Second USENIX Conference on File
and Storage Technologies (FAST), San Francisco, CA, 2003.
[18] O. Markowitch, Y. Roggeman Probabilistic non-repudiation without trusted third
party, Proc. of 2nd Workshop on Security in Communication Networks, 1999.
[19] C. Marinescu, N. T
apus A Survey of the Problems of Time-Stamping or Why It Is
Necessary to Have Another Time-Stamping Scheme, Proc. of the IASTED Conference
on Software Engineering 2007, SE2007, Austria.
[20] C. Marinescu Semnarea electronic
a a datelor. Schem
a hibrid de realizare a
stampilelor digitale de timp, Teza de doctorat, Universitatea Politehnica Bucuresti,
2008.
[21] S. Micali Certified E-mail with invisible post offices, Invited presentation at the
RSA 97 conference, 1997.
[22] J Mitsianis A new approach to enforcing non-repudiation of receipt, Manuscript,
2001.
BIBLIOGRAFIE
51
[23] E. L. Miller, D. D. E. Long, W. E. Freeman, B. C. Reed Strong security for networkattached storage. In Proc. of the 2002 Conference on File and Storage Technologies
(FAST), Monterey, CA, 2002.
[24] P. Maniatis, M. Roussopoulos, T. J. Giuli, D. S. H. Rosenthal, M. Baker The
LOCKSS peer-to-peer digital preservation system, ACM Trans. on Computer Systems
(TOCS), Vol. 23, 2005.
[25] J. Onieva, J. Zhou, J. Lopez Multi-Party Non-repudiation: A Survey, ACM Computing Surveys, 41(1), December 2008
[26] P. Syverson Weakly secret bit commitment: Applications to lotteries and fair
exchange, Proc. of the 1998 IEEE Computer Security Foundations Workshop
(CSFW11), 1998.
[27] M. Togan Contributii privind dezvoltarea unor servicii de tert de ncredere n retelele
de calculatoare, Teza de doctorat, Academia Tehnica Militara, Bucuresti, 2009.
[28] J. J. Wylie, M. W. Bigrigg, J. D. Strunk, G. R Ganger, H. Kiliccote, P. K. Khosla
Survivable storage systems, IEEE Computer, August 2000.
[29] K. Wouters, B. Preneel, A. I. Gonzlez-Tablas, A. Ribagorda Towards an XML
format for time-stamps, Proc. of the 2002 ACM Workshop on XML security, 2002.
[30] N. Zang, Q. Shi Achieving non-repudiation of receipt, The Computer Jurnal, 1996.
[31] J. Zhou, R. Deng, F. Bao Evolution of fair non-repudiation with TTP, ACISP:
Information Security and Privacy: Australasian Conference, Vol. 1587 of LNCS,
Springer-Verlag, 1999
[32] J. Zhou, D. Gollmann Observations on Non-repudiation, Proc. of the International
Conference on the Theory and Applications of Cryptology and Information Security:
Advances in Cryptology, Korea, 1996.
Capitolul 3
Securitatea postei electronice
In mediile electronice de transmitere a informatiei, posta electronica ocupa o pozitie
centrala. Ea permite utilizatorilor sa comunice prin mesaje, folosind facilitatile oferite
de retelele de calculatoare existente. In general serviciul de e-mail este cea mai utilizata
aplicatie, dar n acelasi timp este si cea mai putin sigura.
Astfel, pentru a trimite sau primi un mesaj, Alice trebuie sa fie conectata la un
server de e-mail. Serverul stocheaza mesajul, dupa care l trimite spre alt server care
face acelasi lucru. In acest fel, e-mailurile pot traversa mai multe servere pana ajung la
destinatie, fiecare din acestea pastrand cate o copie a mesajului. Alice (sau Bob) nu poate
sterge mesajul din aceste servere intermediare; ele raman aici pana cand administratorul
severului decide acest lucru1 .
Un mod de a proteja mesajele este criptarea lor folosind diverse produse, cum ar fi
Privacy Enhanced Mail (P EM ), MIME Object Security Services (M OSS), X.400, P GP
sau S/M IM E. Ultimele doua vor fi prezentate n acest capitol. P GP este o specificatie,
iar S/M IM E este un protocol; ambele sunt compatibile cu serviciile Internet actuale.
3.1
P GP (Pretty Good Privacy)
Este un protocol2 creat de Phil Zimmenmann ([8]) n 1991 pentru posta electronica si
pentru aplicatii legate de stocarea fisierelor. In acest moment este cel mai utilizat sistem
de securitate oferit de serviciile de posta electronica. O parte din cauzele care au condus
la aceasta suprematie sunt:
1. Este accesibil free n versiuni care functioneaza pe o gama larga de platforme (inclusiv WINDOWS, UNIX, MacIntosh).
1
Unele companii s-au orientat spre aceasta posibila piata si dezvolta softuri capabile sa stearga emailurile stocate n serverele intermediare. Aceste servicii necesita nsa costuri suplimentare.
2
Numele Pretty Good Privacy a fost inspirat de numele unui magazin, Ralphs Pretty Good Grocery, aflat ntr-un oras imaginar, Lake Wobegon, dintr-un foileton radiofonic scris de Garrison Keillor.
CAPITOLUL 3. SECURITATEA POSTEI ELECTRONICE
2. Este bazat pe algoritmi criptogafici considerati siguri. In particular sunt folositi

RSA, DSS si ElGamal (pentru criptarea cu cheie publica), CAST 128, IDEA,
3DES (pentru criptarea simetrica) si SHA 1 (ca functie de dispersie).
3. Are o arie larga de aplicabilitate, de la corporatii care doresc sa aleaga si sa ntareasca
o schema standard pentru criparea fisierelor si mesajelor, pana la persoane individuale (sau retele) care doresc sa comunice n siguranta pe Internet.
4. Nu a fost creat, dezvoltat sau controlat de nici un organism guvernamental sau
organizatie de standarde. Acest argument l face atractiv celor care se tem de un
posibil control institutional.
In prezent, protocoalele P GP asigura cinci servicii: autentificare, confidentialitate, compresie, compatibilitate e-mail si segmentare.
3.1.1
Autentificare
Este un serviciu de semnatura digitala cu appendix, oferit de P GP . Protocolul este

urmatorul:
Intrare: Mesajul m este trimis de Alice catre Bob.
Alice, n calitate de expeditor, efectueaza urmatorii pasi:
1. Genereaza o amprenta h(m) a mesajului, folosind o functie de dispersie
criptografica.
2. Cripteaza cu cheia secreta: dAlice (h(m)).
3. Aplica o functie de compresie Z perechii (m, dAlice (h(m))).
La receptia mesajului Z((m, dAlice (h(m))), Bob efectueaza urmatorii pasi:
1. Decomprima (cu Z 1 ) si afla mesajul m precum si dAlice (h(m)).
2. Folosind cheia publica a lui Alice, determina h(m) = eAlice (dAlice (h(m))).
3. Aplica functia de dispersie h lui m si compara rezultatul cu h(m). Daca
cele doua secvente coincid, mesajul m este acceptat ca autentic.
Pentru implementari se folosesc: SHA 1 drept functie de dispersie, RSA sau DSA
pentru sistemul de criptare/semnare folosit de Alice, si ZIP pentru functia de compresie.
De asemenea, un cuplu (, ) se utilizeaza sub forma concatenata k.
Securitatea protocolului se bazeaza pe securitatea sistemelor folosite (SHA/RSA sau
SHA/DSA).
3.1. P GP (PRETTY GOOD PRIVACY)
De obicei semnaturile sunt atasate mesajului (sau fisierului) pe care-l semneaza. Sunt
posibile totusi si semnaturi detasate. Acestea sunt pastrate de expeditor pentru a fi
folosite n diverse scopuri. De exemplu, daca mai multe parti semneaza un contract,
fiecare semnatura este independenta si se aplica doar documentului initial (altfel ntrun lant de semnaturi dependente fiecare semnatura ar conduce la aparitia unui nou
mesaj, diferit de cel anterior).
Sau ca un alt exemplu semnatura unui program executabil poate detecta o posibila
virusare ulterioara.
3.1.2
Confidentialitate
Alt serviciu de baza asigurat de P GP este confidentialitatea, oferita de criptarea mesajelor

transmise sau stocate local (ca fisiere). In ambele situatii sistemul de criptare preferat
este CAST 128 (ca alternative sunt folosite si IDEA sau 3DES), iar modul de criptare
este CF B pe 64 biti.
In implementari se foloseste RSA sau ElGamal pentru criptarea cu cheie publica.
Observatia 3.1. Timpul de criptare se optimizeaz
a combin
and un sistem de criptare cu
cheie publica si unul simetric (se stie c
a un sistem de criptare simetric de exemplu
CAST 128 este mult mai rapid dec
at unul cu cheie public
a: RSA sau ElGamal).
Intrare: Mesajul m este trimis de Alice catre Bob.
Expeditorul Alice efectueaza urmatorii pasi:
1. Arhiveaza m cu un protocol de arhivare Z; se obtine Z(m).
2. Genereaza aleator o cheie de sesiune K de 128 biti.
3. Efectueaza criptarea eK (Z(m)).
4. Cripteaza cheia de sesiune folosind cheia publica a lui Bob: eBob (K).
5. Trimite cuplul = (eBob (K), eK (Z(m))).
La primirea mesajului , Bob efectueaza urmatorii pasi:
1. Afla cheia de sesiune K = dBob (eBob (K)).
2. Decripteaza partea a doua a mesajului primit: dK (eK (Z(m))) = Z(m).
3. Dezarhiveaza cu Z 1 si afla mesajul m.
Observatia 3.2. Ideea de cheie de sesiune se refer
a de fapt la o cheie one-time. Protocolul
de distributie a cheii de sesiune nu este necesar, deoarece nu se solicit
a o confirmare a
cheii de c
atre Bob. Modul de functionare al postei electronice face ca protocolul prin care
ambele p
arti sa foloseasca o cheie de sesiune comun
a nu este util; fiecare mesaj este nsotit
de propria sa cheie, securizata printr-o criptare cu o cheie public
a.
Generarea unei chei de sesiune se realizeaz
a n modul urm
ator: Alice introduce o
parol
a, folosind tastatura sau mouse-ul. P GP foloseste parola si timpii de scriere la
tastatur
a (respectiv de miscare al mouse-ului) pentru a genera o cheie aleatoare care va fi
folosit
a de un sistem simetric de criptare.
Cele doua utilizari ale P GP (autenticitate si confidentialitate) pot fi asociate pentru
acelasi mesaj. In prima faza se genereaza o semnatura a textului clar, care se adauga
mesajului. Apoi perechea (text clar, semn
atur
a) este criptata folosind un sistem simetric
(CAST 128, IDEA sau 3DES), iar cheia de sesiune se cripteaza folosind un sistem cu
cheie publica (RSA sau ElGamal).
Principalele motive pentru care este preferata aceasta ordine (si nu invers: criptarea
mesajului, urmata de semnarea textului criptat) sunt:
1. In general este mai convenabil sa stocam semnatura unui text clar si nu a unui text
criptat (a carui cheie ar trebui retinuta de asemenea).
2. Daca se cere si verificarea de catre o terta parte, de obicei aceasta nu trebuie implicata n procesul de decriptare, ci doar n cel de verificare a semnaturii.
Deci, daca se cer ambele servicii P GP , Alice va semna ntai mesajul cu cheia sa secreta,
apoi l va cripta cu cheia de sesiune, iar pe aceasta o va cripta cu componenta publica a
cheii lui Bob.
3.1.3
Compresie
In general, P GP face o compresie a mesajului dupa semnarea lui, dar naintea criptarii.
Aceasta duce la o optimizare a spatiului folosit atat n mesajele e-mail cat si n stocarea
fisierelor.
Algoritmul de compresie folosit de P GP este ZIP , descris n Anexa 1.
Observatia 3.3. Semnatura este generat
a naintea compresiei deoarece:
1. Este preferabil sa semnam un mesaj necomprimat, deoarece pentru verific
ari va fi
caz contrar, sau se va p
oferit textul clar. In
astra n memorie doar o versiune
comprimata a mesajului, sau acesta va fi comprimat ori de c
ate ori se va solicita
verificarea semnaturii.
2. Chiar daca este usor de recomprimat mesajul ori de c
ate ori este necesar
a verificarea, apare o dificultate datorit
a faptului c
a ZIP este un algoritm nedeterminist:
diverse implementari duc la rate de compresie diferite si deci la forme diferite.
Aceste versiuni sunt totusi inter-operabile: orice versiune poate decompresa corect
iesirea din oricare alta versiune. Aplic

and functia de dispersie si semn
atura dupa
compresie, vom obliga ca toate implement
arile P GP s
a conduc
a la aceeasi compresie.
Observatia 3.4. Criptarea mesajului dup
a compresie asigur
a o securitate sporit
a, datorit
a redondantei mult mai reduse a textului compresat (comparativ cu textul clar).
Indiferent de serviciile solicitate (autentificare si/sau confidentialitate), n final transmisia va contine blocuri de octeti arbitrari. Multe sisteme de e-mail permit nsa transmiterea doar a blocurilor ASCII. Pentru a fi compatibil cu aceasta restrictie, P GP
efectueaza si o conversie a octetilor la secvente de caractere ASCII printabile. Conversia
folosita este radix 64 (Anexa 2): fiecare grup de 3 octeti binari este transformat n
patru caractere ASCII.
Folosirea sistemului radix 64 mareste mesajul cu 33%, extensie compensata de rata
de compresie (ZIP are de obicei o rata de compresie de 50%).
Astfel, daca un fisier are lungimea n, dupa compresie si conversie, lungimea lui va fi de
aproximativ 1, 33 0, 5 n = 0, 665 n.
Observatia 3.5. Algoritmul radix 64 converteste tot sirul de intrare, considerat ca o
secvent
a binara de octeti. Deci, daca un mesaj este doar semnat (nu si criptat), conversia
se aplic
a desi mare parte din text este deja ASCII. Aceasta l face necitibil unui intrus
ocazional deci ofera o anumita confidentialitate mesajului.
Exist
a optiunea ca P GP sa converteasc
a (cu radix64) numai componenta de semn
atura
a mesajului; n acest fel Bob l va putea citi direct, f
ar
a a folosi P GP . P GP va fi utilizat
numai pentru a verifica semnatura.
3.1.4
Segmentare si reasamblare
Exista adesea o restrictie referitoare la lungimea mesajelor transmise prin e-mail; de

exemplu, multe facilitati accesibile prin Internet impun o lungime maxima de 50.000 sau
65.000 octeti. Orice mesaj mai lung trebuie spart n blocuri mai mici si trimise prin
mesaje e-mail separate.
P GP segmenteaza automat un mesaj mai lung n mesaje care sunt trimise separat prin
e-mail. Blocurile sunt puse n ordine n fisiere cu extensia .as1, .as2 etc. Segmentarea este
realizata dupa ncheierea celorlaltor operatii (inclusiv conversia). Deci cheia de sesiune
si semnatura vor apare o singura data, la nceputul primului segment. Dupa receptia
tuturor segmentelor, P GP face reasamblarea lor n ordinea indicata de extensii, eliminand
headerele si alte detalii de e-mail.
3.1.5
Chei criptografice si servere de chei
P GP -ul foloseste patru tipuri de chei: chei de sesiune (simetrice, one-time), chei publice,
chei private si chei (simetrice) bazate pe parola.
Exista trei cerinte referitoare la modul de gestiune al acestor chei:

1. O procedura sigura de a genera chei de sesiune aleatoare.
2. Fiecare utilizator trebuie sa detina mai multe perechi de chei publice/private care
schimbate din cand n cand. Daca are loc o astfel de modificare, destinatarul Bob va
sti doar vechea cheie pana la o eventuala actualizare. In plus, utilizatorul ar putea
opta la un moment dat pentru mai multe perechi de chei fie pentru a interactiona
simultan cu mai multi destinatari, fie doar pentru a mbunatati securitatea, limitand
utilizarea unei anumite chei la doar o portiune din text. Dificultatea n aceste cazuri
este determinata de faptul ca nu exista o modalitate de relationare ntre utilizatori
si cheile lor publice.
Sunt necesare, asadar, anumite proceduri de identificare a unor chei particulare.
3. Fiecare utilizator P GP trebuie sa mentina un fisier cu propriile sale perechi de chei
publice/private, precum si un fisier cu cheile publice corespunzatoare.
Generarea cheilor de sesiune
Fiecare cheie de sesiune este asociata unui singur mesaj si este folosita exclusiv pentru
criptarea si decriptarea acestuia. Cele doua operatii se realizeaza asa cum s-a vazut
cu ajutorul unor algoritmi simetrici: CAST 128 si IDEA care folosesc chei de 128 biti
sau 3DES care foloseste chei de 168 biti.
Exemplul 3.1. Sa luam n considerare utilizarea algoritmului CAST 128.
Numerele aleatoare pe 128 de biti sunt generate folosind chiar algoritmul de criptare.
Intrarea generatorului de numere pseudo-aleatoare const
a dintr-o cheie de 128 de biti si
dou
a blocuri de 64 de biti tratate ca texte clare ce urmeaz
a s
a fie criptate. CAST 128
genereaz
a doua blocuri criptate de 64 biti fiecare, care sunt apoi concatenate pentru a
forma cheia de sesiune de 128 de biti.
Cele doua texte clare de cate 64 biti aflate la intrarea n generatorul de numere pseudoaleatoare provin la randul lor dintr-o secvent
a de 128 biti generati aleator. Aceste
numere folosesc ca sursa tastele apasate de utilizator sau misc
arile de mouse.
P GP -ul mentine un buffer de 256 octeti aleatori. De fiecare dat
a c
and P GP -ul
asteapt
a apasarea unei taste, nregistreaz
a timpul n format de 32 biti de la care
ncepe asteptarea. Cand o tasta este ap
asat
a, P GP -ul nregistreaz
a momentul la care a
avut loc acest eveniment, precum si valoarea pe 8 biti a caracterului tastat. Datele referitoare la timp si caracter sunt utilizate pentru a genera o cheie care la r
andul ei este
folosit
a pentru a cripta valoarea curent
a a buffer-ului de octeti aleatori.
Num
arul aleator astfel generat este combinat cu cheia de sesiune rezultat
a din algoritmul
CAST 128 pentru a forma noua intrare a generatorului de numere pseudo-aleatoare.
Datorit
a algoritmului CAST 128, rezultatul va fi un fisier de chei de sesiune c
at mai
apropiate de un model aleator.
Identificatori de chei
Cheia de sesiune este criptata cu cheia publica a lui Bob, astfel ncat numai acesta este
capabil sa recupereze cheia de sesiune si mai departe sa decripteze mesajul. Daca
fiecare parte implicata foloseste o singura pereche de chei publice/private, atunci Bob va
sti ce cheie sa foloseasca pentru a recupera cheia de sesiune: cheia sa privata (unica).
Daca nsa fiecare utilizator poate dispune de mai multe perechi de chei publice/private
problema nu mai este la fel de simpla.
O solutie ar fi transmiterea cheii publice odata cu mesajul. Bob ar putea verifica la
primire daca ntr-adevar cheia trimisa se regaseste printre cheile sale publice si n caz
afirmativ sa treaca la decriptarea mesajului.
Aceasta schema poate fi implementata usor, dar consuma foarte mult spatiu, deoarece o
cheie criptata cu RSA poate avea cateva sute de cifre.
A doua rezolvare consta n asocierea unui identificator fiecarei chei publice, care sa fie
unic pentru raporturile cu un anumit utilizator. In acest mod, o combinatie ntre ID-ul
utilizatorului si ID-ul cheii ar fi suficienta pentru a identifica n mod unic o cheie.
Aceasta solutie ridica, totusi o alta problema: ID-ul cheii trebuie alocat si stocat astfel
ncat atat Alice cat si Bob sa poata realiza transferul ntre ID-ul cheii si cheia publica.
Solutia adoptata de P GP consta n alocarea unui ID fiecarei chei publice care sa fie
cu o probabilitate mare unica n raport cu un anumit destinatar. ID-ul fiecarei chei
publice consta din cei mai putin semnificativi 64 biti ai acesteia. Astfel, ID-ul cheii publice
KPa este KPa (mod 264 ). Aceasta este o dimensiune suficienta pentru ca probabilitatea
existentei duplicatelor sa fie redusa.
Servere (Inele) de chei
Cheile trebuie sa fie stocate si organizate ntr-un mod care sa permita o utilizare efectiva
si sistematica de catre toate partile. P GP -ul furnizeaza o pereche de structuri de date
fiecarui utilizator: una pentru a stoca perechile de chei publice/private detinute de utilizatorul respectiv si una pentru a stoca perechile de chei publice corespunzatoare celorlaltor
utilizatori.
Aceste structuri de date sunt cunoscute sub numele de serverul de chei private si respectiv serverul de chei publice3 .
Timestamp
..
.
ID cheie
..
.
Cheie publica
..
.
Cheie privata
..
.
ID utilizator
..
.
Ti
..
.
P Ui (mod 264 )
..
.
P Ui
..
.
eh(Pi ) (P Ri )
..
.
Utilizator i
..
.
In tabelul de mai sus este prezentata structura serverului de chei private. Fiecare linie
reprezinta o pereche de chei publice/private detinute de un utilizator; ea este formata din:
3
Unele referinte folosesc termenul Inele de cheiprivate/publice).
Timestamp: data/ora la care a fost generata perechea de chei.

ID cheie: cei mai putin semnificativi 64 biti pentru aceasta linie (reprezentata n
binar).
Cheia public
a: componenta publica a perechii de chei.
Cheia privat
a: componenta privata a perechii de chei; acest camp este criptat.
ID utilizator: de obicei, acest camp este reprezentat de adresa e-mail a utilizatorului.
Serverul de chei private poate fi indexat fie dupa ID-ul utilizatorului, fie dupa ID-ul cheii.
Desi cheia privata va fi stocata si accesibila doar pe calculatorul utilizatorului care a creato si care detine perechile de chei, valoarea ei trebuie pastrata cat mai n siguranta.
Din acest motiv, cheia privata este criptata (cu CAST 128, IDEA sau 3DES) si abia
apoi nregistrata pe server. Procedura este urmatoarea:
1. Alice alege o parola ce va fi utilizata n criptarea cheilor private.
2. De fiecare data cand sistemul genereaza o noua pereche de chei publice/private
folosind RSA, Alice este solicitata sa introduca parola. Utilizand SHA 1,
este generata o amprenta pe 160 de biti, iar parola se sterge.
3. Sistemul cripteaza cheia privata folosind CAST 128 cu amprenta trunchiata
pe 128 biti drept cheie. Amprenta este apoi stearsa si cheia privata criptata
este stocata pe serverul de chei private.
Serverul de chei publice, folosit pentru stocarea cheilor publice ale celorlaltor utilizatori
conectati cu posesorul serverului de chei, are o structura similara. Astfel, el contine toate

campurile serverului de chei private: Timestamp,
ID cheie, Cheia publica, ID - utilizator
(cu mentiunea ca un utilizator poate avea mai multe ID-uri asociate unei singure chei).
In linii mari, cele doua servere sunt construite n conformitate cu o autoritate centrala care elibereaza certificate (detalii referitoare la P KI vor fi prezentate n capitolul
urmator).
Fiecare intrare n serverul cheilor publice reprezinta o cheie publica certificata. Fiercarei
linii din tabel i este asociat un camp de Legitimare Cheie; el indica n ce masura
P GP -ul va considera ca aceasta reprezinta o cheie publica valida pentru utilizator, si cat
de ridicat este nivelul ei de ncredere. Acest camp este calculat de P GP .
De asemenea, fiecarei linii i se asociaza una sau mai multe semnaturi (procurate de
posesorul serverului) care semneaza certificatul. La randul ei, fiecare semnatura are asociat un camp Signature Trust care indica n ce masura are ncredere utilizatorul ca
semnatura respectiva certifica o cheie publica. Un alt camp Legitimare Cheie

provine din colectia de campuri Signature Trust pentru intrarea respectiva.
In sfarsit, fiecare intrare defineste o cheie publica asociata cu un anumit proprietar si un
camp Owner trust este inclus pentru a indica n ce masura aceasta cheie publica este de
ncredere n semnarea altor certificate de chei publice; acest nivel de ncredere este stabilit
de utilizator. Deci campurile Signature Trust sunt de fapt copii ale campului Owner din
alta intrare din tabel. Modalitatea detaliata de calcul a valorilor acestor campuri precum
si lista valorilor pe care le poate lua fiecare intrare sunt discutate n [5] si [7].
Modul de transmitere a mesajelor si cheilor
Presupunem ca Alice doreste sa transmita un mesaj semnat si criptat. Ea va parcurge

urmatorii pasi:
1. Semnarea mesajului:
(a) P GP -ul alege cheia privata a lui Alice din serverul cheilor private,
folosind ID-ul ei de utilizator. Daca acest ID nu este dat ca parametru
al comenzii, se trimite prima cheie privata din server.
(b) P GP -ul cere lui Alice parola, pentru a recupera cheia privata necriptata.
(c) Este generata componenta mesajului care contine semnatura.
2. Criptarea mesajului:
(a) P GP -ul genereaza o cheie de sesiune si cripteaza mesajul.
(b) P GP -ul primeste cheia publica a lui Bob din serverul de chei publice,
folosind drept index ID-ul acestuia.
(c) Este generata componenta mesajului care contine cheia de sesiune.
La primirea mesajului, Bob va efectua urmatorii pasi:
10
1. Decriptarea mesajului:
(a) P GP -ul primeste cheia privata a lui Bob din serverul de chei private.
(b) P GP -ul cere lui Bob parola, pentru a recupera cheia privata necriptata.
(c) P GP -ul recupereaza cheia de sesiune si decripteaza mesajul.
2. Autentificarea mesajului:
(a) P GP -ul primeste cheia publica a lui Alice din serverl de chei publice,
folosind ca index ID-ul cheii din semnatura mesajului.
(b) P GP -ul recupereaza continutul necriptat al mesajului.
(c) P GP -ul cripteaza acest continut necriptat si-l compara cu mesajul primit.
Daca cele doua sunt identice, mesajul este autentic; n caz contrar,
mesajul initial a fost alterat de un posibil intrus.
3.1.6
Structura de pachete a mesajelor securizate cu P GP
Un fisier P GP este alcatuit din:

Un pachet mesaj. Contine datele care au importanta pentru utilizator si care vor
fi trimise sau stocate (componenta mesaj), precum si un antet (header) care contine
informatii generate de P GP : numele fisierului si un timestamp (care indica data
creerii mesajului sau fisierului).
Un pachet semn
atur
a. Contine o combinatie ntre informatii legate de cheia
publica a lui Alice si o amprenta a mesajului (obtinuta prin aplicarea unei functii
de dispersie criptografica asupra componentei mesaj).
Semnatura este formata din:
1. Timestamp: data la care a fost creata semnatura.
2. Amprenta mesajului: reprezentata de un cod de 160 biti generati cu SHA1 si
criptat cu cheia privata a lui Alice. Functia de dispersie este calculata pentru
timestamp-ul semnaturii, concatenat cu o portiune de date din componenta
mesaj.
Includerea n amprenta mesajului a timpului la care a fost generata semnatura
protejeaza mpotriva unui atac man-in-the-middle. Excluderea numelui fisierului
si a timestamp-ului pentru componenta mesaj asigura faptul ca semnaturile
detasate sunt identice cu semnaturile atasate, cu exceptia faptului ca nu prefixeaza mesajul.
3.2. OP EN P GP
11
Semnaturile detasate sunt calculate ntr-un fisier separat care nu contine nici
unul dintre campurile din antetul componentei mesaj.
3. Cei mai semnificativi octeti ai amprentei mesajului: acestia l ajuta pe Bob sa
determine daca s-a folosit cheia publica corecta pentru decriptarea amprentei.
4. ID-ul cheii publice a lui Alice: serveste la identificarea cheii publice care ar
trebui folosita pentru a decripta amprenta; identifica de asemenea si cheia
privata utilizata pentru criptarea amprentei.
Pachetelor mesaj si semnatura li se poate aplica o compresie folosind ZIP si pot fi
criptate cu ajutorul unei chei de sesiune.
Un pachet cheie de sesiune. Pachetele cheie de sesiune includ cheia de sesiune si
identificatorul cheii publice a lui Bob care a fost utilizata de Alice pentru a cripta
cheia de sesiune.
In interiorul pachetului principal se afla un pachet cu cheia publica de sesiune criptata. Pachetele de date (criptate identic) sunt precedate de un pachet ce contine
cheia publica de sesiune criptata pentru fiecare cheie utilizata n criptarea mesajului. Mesajul este criptat cu cheia de sesiune, care este la randul ei criptata si stocata
n pachetul cheii de sesiune.
Corpul pachetului cheii de sesiune este alcatuit din:
1. Un octet reprezentand cifra 3.
2. 8 octeti ai ID-ului cheii publice cu care este criptata cheia de sesiune.
3. 8 octeti care indica algoritmul folosit pentru cheia publica.
4. Un sir de octeti reprezentand cheia publica criptata. Continutul acestui sir
este dependent de algoritmul utilizat pentru cheia publica:
- pentru RSA: un M P I (ntreg n precizie multipla reprezentand valoarea
criptata a lui me (mod n);
- pentru ElGamal: doua M P I unul pentru valoarea g k (mod p) si altul
pentru m y k (mod p).
Daca se foloseste compresia, atunci criptarea se aplica dupa compresia pachetului
format din pachetul mesaj si pachetul semnatura.
3.2
OpenP GP
Una din problemele pe care P GP (prin compania PGP Inc.) a trebuit sa le rezolve a
fost aceea de a combina caracterul de produs free cu posibilitatea de a utiliza cele mai
bune sisteme de criptare, functii de dispersie si de compresie. Cum algoritmi ca RSA sau
12
ElGamal nu pot fi utilizati fara licenta, iar standardul intern al companiei mentioneaza
explicit: nu se va folosi nici un algoritm cu dificultati de licenta, au aparut mai multe
idei:
Deoarece criptarea este una din componentele de baza din P GP , ar fi bine sa se
scrie propriul soft de securitate, care sa fie inclus n produs.
Sa se construiasca o varianta sub forma unui standard de tip open.
In final, Zimmermann a font convins de avantajele celei de a doua variante si n iulie 1997,
PGP Inc. a propus IET F (Internet Engineering Task Force societatea care dezvolta
si promoveaza standardele Internet) un standard nou numit OpenP GP . IET F obtine
dreptul de a folosi numele OpenP GP pentru a descrie acest standard si protocoalelele
suportate de acesta.
OpenP GP este o varianta legalizata a P GP si se dezvolta permanent. Specificatia
actuala este RF C 4880 (aparuta n noiembrie 2007).
Exista si variante de OpenP GP dezvoltate de diverse societati. Cea mai cunoscuta
n acest moment este GNU Privacy Guard (GnuP G sau GP G) propusa de Free Software
Foundation.
GnuP G este free mpruna cu codul sursa, sub licenta GP L (GN U General Public License).
3.3
Comentarii finale
Luand n considerare informatiile facute publice, nu exista o metoda cunoscuta care sa

permita spargerea mesajelor P GP cu ajutorul atacului prin criptanaliza sau prin metode
computationale. Pentru primele versiuni ale P GP -ului ([6]) s-au descoperit unele falii
teoretice de securitate, care au fost rezolvate ulterior.
Securitatea P GP -ului se bazeaza pe ipoteza ca algoritmii utilizati nu pot fi atacati prin
criptanaliza directa cu echipamentele si tehnologiile actuale. De exemplu, n versiunea
originala, algoritmul RSA era utilizat pentru criptarea cheilor de sesiune; puterea criptografica a RSA-ului se bazeaza pe dificultatea problemei factorizarii numerelor ntregi.
Incepand nsa cu a doua versiune, pentru criptarea cheilor a nceput sa fie utilizat sistemul IDEA, pentru care nu sunt cunoscute vulnerabilitati. Cum versiunile ulterioare au
adagat noi si noi algoritmi, gradul de insecuritate al acestora variaza odata cu algoritmii
utilizati.
Periodic sunt lansate versiuni noi de P GP ; daca apar unele falii de securitate, acestea
sunt rezolvate pe parcurs.
Exemplul 3.2. Numeroase situatii arat
a c
a autorit
atile se g
asesc adesea n imposibilitate de a decripta prin atacuri traditionale mesajele interceptate. De exemplu, n 2006,
guvernul SUA gasind aproape imposibil
a accesarea fisierelor criptate cu P GP ale unui
3.4. M IM E
13
inculpat i-a cerut acestuia sa le furnizeze parola; acest lucru ns

a contravine amendamentului 5, care da dreptul unui acuzat s
a nu se incrimineze singur.
Avand n vedere utilizarea ndelungata a P GP -ului, mbunatatirile sistematice care
i-au fost aduse, precum si rezistenta confirmata la atacuri prin criptanaliza, sistemul si
dovedeste viabilitatea.
3.4
M IM E
M IM E (Multipurpose Internet Mail Extension) ([2]) este un standard care are ca scop
redefinirea formatelor mesajelor e-mail, permitand:
Folosirea n mesaje de caractere dinafara setului ASCII;
Un set extins de formate pentru mesaje (nafara modului text);
Mesaje compuse (Multipart message bodies);
Headere cu informatii care folosesc caractere dinafara setului ASCII.
S/M IM E (Secure MIME) este o suplimentare (bazata pe tehnologia RSA Data Security)
a securitatii formatului standard M IM E destinat cresterii securitatii mesajelor postei
electronice. In general specificattia4 S/M IM E este utilizata n standardul pentru uzul
comercial si institutional, pe cand P GP este folosit pentru utilizatorii obisnuiti ai emailului.
Standardul M IM E a aparut ca urmare a necesitatii transmiterii prin intermediul
postei electronice de imagini, nregistrari video sau mesaje text scrise n alte limbi
decat cea engleza. Inaintea acestuia, transferul informatiilor multimedia ntre parteneri
putea fi realizat doar n anumite circumstante, cu programe de translatare speciale, efort
si costuri, iar cea mai mare parte a traficului postei electronice era limitat la folosirea
caracterelor ASCII. Mai mult, fiecare client de mail avea posibilitatea de a trimite si de a
receptiona imagini, dar nu ntr-un format recognoscibil de catre celelalte sisteme. M IM E
extinde posta electronica la caractere U N ICODE ntr-o maniera simpla, compatibila cu
versiunile anterioare si totodata deschisa posibilitatii de extindere n continuare ([2]).
La scurt timp de la aparitie, formatul M IM E si-a gasit aplicatii si nafara domeniului
postei electronice. Cand fondatorii World Wide Web au creat functionalitatea hypertext,
s-a considerat usor de ntrebuintat framework-ul M IM E pentru definirea noului tip de
date hypertext si pentru specificarea scripturilor HT M L. In momentul n care s-a trecut
la definirea regulilor pentru HT M L, ncorporarea imaginilor n paginile web a devenit
o simpla formalitate, deoarece pentru M IM E se realizase deja definirea centralizata a
formatelor tipurilor de imagini.
4
S/M IM E este o specificatie, n timp ce P GP este un produs.
14
Formatul M IM E este derivat dintr-un alt format traditional: RF C 822 (folosit si

astazi).
3.4.1
Formatul RF C 822
Este formatul standard pentru mesajele text trimise prin posta electronica. In contextul
RF C 822 mesajele sunt privite similar scrisorilor obisnuite: un text pus ntr-un plic.
Plicul contine informatia necesara pentru realizarea unei transmisii si receptonari corecte.
Continutul este obiectul care va fi livrat destinatarului. Standardul RF C 822 se aplica
doar continutului.
Continutul include o multime de campuri de antet care vor fi utilizate de sistem pentru
crearea plicului, iar standardul este astfel creat ncat sa faciliteze accesarea automata a
acestor informatii de catre diverse programe. Standardul RF C a fost descris pentru prima
oara n 1982 de catre Davin Crocker n Standard for the Format of ARPA Internet Text
Messages.
Un mesaj n format RF C 822 are doua parti: un antet (header) utilizat de agentul
care asigura serviciul de e-mail, si un text ASCII (corp).
O linie de antet are forma:
< cuvant cheie >:< atribute >
Formatul permite ca o linie mai mare sa fie scrisa pe mai multe linii. Cele mai utilizate
cuvinte cheie sunt: From, To, Subject si Date.
In functie de mesaj, pot apare si alte linii de antet, cum ar fi CC, List Info etc.
Exemplul 3.3.
From: Cipher Editor < cipher editor@ieee security.org >
Subject: [Cipher Newsletter] Electronic CIPHER, Issue 60, May 18, 2004
Date: Tue, 18 May 2004 13:20:49 -0600
To: < cipher@mailman.xmission.com >
CC: < adrian@galaxyng.com >
List Info: subscriptions for the IEEE online newsletter, Cipher
Show details...
Alt camp care apare frecvent n antetele formatului RF C 822 este Message ID.
Aceasta linie contine un identificator unic asociat mesajului.
3.4.2
Structura formatului M IM E
SM T P
SM T P (Simple Mail Transfer Protocol) este unul din primele protocoale (apare la nceputul
anilor 80) folosite pentru transmiterea mesajelor n format electronic pe Internet. Avantajul sau comparativ cu alte protocoale contemporane (de exemplu U U CP ) era
3.4. M IM E
15
robustetea sa n cazul cand partenerii de dialog erau legati la retea tot timpul. Dupa
2001 existau cel putin 50 implementari SM T P (atat servere cat si clienti), cele mai cunoscute fiind Postfix, qmail, Novell GroupWise, Exim, Novell NetMail si Microsoft Exchange
Server.
In SM T P , comunicarea ntre client si server se realizeaza numai n format ASCII
pe 7 biti, numit N V T (Network Virtual Terminal). Cel mai raspandit format N V T este
N V T ASCII. Acesta opereaza cu un set de caractere pe 8 biti, n care cei mai putin
semnificativi 7 biti sunt identici cu cei din ASCII, iar bitul cel mai semnificativ este 0.
Protocolul de comunicare ntre Alice si server se desfasoara astfel:
1. Initial Alice lanseaza protocolul de conexiune cu serverul si asteapta ca acesta sa-i
raspunda cu mesajul 220 Service Ready.
2. Dupa primirea mesajului cu codul 220, Alice trimite comanda HELO prin care se
identifica.
3. Odata ce comunicarea a fost stabilita, Alice poate trimite unul sau mai multe
mesaje, poate ncheia conexiunea sau poate folosi diverse servicii (de exemplu verificarea adreselor de e-mail).
Serverul trebuie sa raspunda dupa fiecare comanda, indicand daca aceasta a fost
acceptata, daca se asteapta si alte comenzi sau daca exista erori de scriere.
4. Pentru a trimite un mesaj se foloseste ntai comanda M AIL prin care se specifica
adresa lui Alice. Daca aceasta comanda este corecta serverul va raspunde cu 250
OK.
5. Alice trimite apoi o serie de comenzi RCP T prin care specifica destinatarii mesajului. Serverul va raspunde cu 550 No such user here, sau 250 OK, n functie de
corectitudinea comenzii primite.
6. Dupa ce destinatarii sunt identificati, Alice trimite comanda DAT A, prin care
anunta serverul ca va ncepe sa scrie continutul mesajului.
Serverul poate raspunde cu mesajul 503 Command out of sequence sau 554 No
valid recipients daca nu a primit comenzile M AIL sau RCP T sau aceste comenzi
nu au fost acceptate.
Daca serverul raspunde cu 354 Start mail input, Alice poate introduce textul mesajului.
7. Sfarsitul comunicarii este marcat cu < CR >< LF > . < CR >< LF >.
Rezumand, un server SM T P trebuie sa cunoasca cel putin urmatoarele comenzi:
16

HELO
- specificare Alice ca expeditor;
EHLO
- specificare Alice cu cerere de mod extins;
MAIL FROM - date de identificare Alice;
RCPT TO
- specificare Bob ca destinatar;
DATA
- continutul mesajului;
RSET
Reset;
QUIT
- ncheierea sesiunii;
HELP
- ajutor pentru comenzi;
VRFY
- verificarea unei adrese;
EXPN
- expandarea unei adrese;
VERB
- informatii detaliate.
Trecerea de la SM T P la M IM E
M IM E este o extensie a formatului RF C 822, construit cu scopul de a elimina o serie
de restrictii ale protocolului SM T P . Astfel:
1. SM T P nu poate transmite fisiere executabile sau alte obiecte binare.
Desi exista diverse scheme de conversie a fisierelor binare n fisiere text care sunt
folosite de SM T P , niciunul din ele nu este standard (nici macar de facto).
2. SM T P nu poate transmite texte care contin caractere specifice diverselor limbi
(reprezentate prin coduri pe cel putin 8 biti) deoarece este limitat la ASCII pe 7
biti.
3. Serverele SM T P accepta doar mesaje limitate ca marime.
4. Unele implementari SM T P nu sunt pe deplin conforme chiar si cu standardele
SM T P definite n RF C 822. Cele mai frecvente probleme aparute se refera la:
Stergerea, adaugarea sau reordonarea comenzilor < CR > (Carriage Return)si
< LF > (Line Feed).
Trunchierea sau stergerea liniilor mai lungi de 76 caractere;
Eliminarea spatiilor albe (T ab-ul sau caracterul spatiu);
Aranjarea liniilor din mesaj la o lungime standard;
Conversia caracterului T ab ntr-un multiplu de caractere spatiu.
In figura de mai jos sunt reprezentate o serie de functii care permit transformarea caracterelor nonASCII n caractere ASCII si invers.
Specificatiile sunt cuprinse n standardele RF C 2045, . . . RF C 2049.
3.4. M IM E
17
#
-
7-bit
NVT ASCII
Date
non-ASCII
Server SM T P
M IM E
Bob
"!
6
7-bit
NVT ASCII
7-bit
NVT ASCII
Date
non-ASCII

Alice

M IM E
Client SM T P
O specificatie M IM E contine urmatoarele elemente:

1. Cinci linii noi n antet, care ofera informatii despre corpul mesajului.
2. Reprezentari standardizate care suporta elemente multimedia pentru posta electronica.
3. Codificari de transfer care permit conversia oricarui format ntr-un format standard,
protejat la modificari efectuate de sistemul de mail.
Cele cinci linii noi de antet definite n M IM E sunt:
M IM E V ersion: este nsotit de parametrul 1.0. El indica faptul ca mesajul este
codificat conform regulilor RF C 2045 si RF C 2046.
Content T ype: Descrie datele din mesaj, cu suficiente detalii pentru ca serverul de
la destinatie sa poata selecta un mecanism adecvat care sa reprezinte utilizatorului
datele respective ntr-o maniera adecvata.
Content T ransf er Encoding: Indica tipul de transformare folosit pentru reprezentarea mesajului ntr-o maniera acceptabila pentru transfer.
Content ID: Este folosit pentru a identifica n mod unic entitatile M IM E, indiferent de contextul n care se afla.
Content Description: Contine o descriere a obiectului care formeaza mesajul;
indicatia este utila atunci cand mesajul nu este de tip text (de exemplu date audio).
Ultimele doua cuvinte cheie sunt optionale si pot fi ignorate eventual n implementare.
Tipurile de date descrise prin specificatia Content T ype
Tipurile pe care le poate avea continutul unui mesaj (conform cu RF C 2046) sunt sumarizate n tabelul urmator:
18
Tip
Text
Multipart
Message
Image
Video
Audio
Application

Subtip
Plain
Enriched
Mixed
Descriere
Un text neformatat (de exemplu ASCII)
Ofera o flexibilitate sporita a formatului.
Diferitele componente ale mesajului sunt independente
dar sunt transmise mpreuna. Ele sunt prezentate
destinatarului n ordinea n care apar n mesaj.
Parallel
Difera de Mixed prin faptul ca ordinea componentelor
n mesaj este aleatoare.
Alternative
Componentele sunt versiuni alternative pentru aceeasi
informatie. Ele sunt ordonate crescator dupa similitudinea cu originalul, iar sistemul de mail al destinatarului va lista varianta cea mai buna.
Digest
Difera de Mixed prin faptul ca tipul principal al fiecarei
parti este message/rf c822.
rfc822
Corpul este un mesaj conform cu RF C 822.
Partial
Permite fragmentarea unui mesaj mare ntr-un mod
accesibil sistemului de mail al destinatarului
External-body Contine un pointer la un obiect care exista n alta
parte.
jpeg
Imaginea este n format JP EG, codificata JF IF .
gif
Imaginea este n format GIF .
mpeg
Format M P EG.
Basic
Se foloseste un canal ISDN pe 8 biti, codificat la o
rata standard de 8 kHz.
PostScript
Postscript Adobe
octet-stream
Date reprezentate n binar pe 8 biti.
Sunt sapte tipuri generale de date si 15 subtipuri (care specifica un anumit format pentru
tipul de date respectiv).
MIME: Content - Transfer - Encoding

Alta componenta majora a specificatiei M IM E este o definire a codificarii pentru corpurile mesajului. Atributele admise de aceasta specificatie sunt listate n tabelul urmator.
Trei din aceste atribute (7bit, 8bit, binary) indica faptul ca nu se aplica nici o codificare,
oferind doar anumite informatii despre natura datelor.
Pentru transferul SM T P forma 7bit este suficient de sigura.
3.4. M IM E
19
7bit
8bit
binary
Datele sunt reprezentate prin linii scurte de caractere ASCII.

Liniile sunt scurte, dar pot fi caractere non-ASCII.
Liniile nu sunt obligatoriu suficient de scurte pentru
transferul SM T P .
quoted printable Daca datele contin suficient de mult text ASCII, acesta ramane
accesibil unei citiri directe.
base64
Fiecare bloc de 6 biti se codifica ntr-un bloc de 8 biti caracter
ASCII printabil.
x token
Codificare nestandard.
M IM E utilizeaza doua metode de codificare a datelor: quoted printable si base645 .
Prima permite un transfer usor de citit, iar a doua ofera o securitate sporita tuturor
tipurilor de date.
3.4.3
Securitatea M IM E bazat
a pe OP EN P GP
Incercarea de a combina protocoalele P GP si M IM E este naturala, dar a ntampinat

mai multe dificultati, cea mai semnificativa fiind data de incapacitatea de a recupera
continutul mesajelor semnate fara parsarea structurilor de date specifice P GP -ului.
Standardul RF C 1847 defineste formate de securitate multipart pentru M IM E.
Acestea separa continutul mesajului semnat de semnatura. P GP -ul poate genera n
urma criptarii mesajelor fie caractere ASCII, fie siruri arbitrare de octeti, generand si
o semnatura sau extragand datele cheii publice. Protocolul de transmitere a datelor solicita ca acestea sa fie n format ASCII. Daca mesajul trebuie transmis n mai multe
parti, trebuie folosit mecanismul M IM E de transmitere partiala, n locul formatului
OpenP GP ASCII multipart.
Agentii de mail trateaza si interpreteaza mesajele multipart n mod opac, ceea ce
nseamna ca datele nu vor suferi nici o alterate. Totusi, unele servere pot detecta faptul
ca urmatorul gateway6 nu suporta formatul M IM E sau datele pe 8 biti si va realiza o
conversie la base64.
Aceasta reprezinta o problema serioasa pentru mesajele semnate, semnatura lor fiind
invalidata la efectuarea unei astfel de operatii. Din acest motiv, toate mesajele semnate
folosind acest protocol trebuie restranse la o reprezentare pe 7 biti.
Inainte de criptarea cu OpenP GP , datele trebuie trecute n forma canonica M IM E
(descrisa mai sus). Criptarea cu OpenP GP este anuntata prin antetul content type multipart/encrypted si trebuie sa aiba valoarea parametrului de protocol application/pgpencrypted.
Corpul mesajului criptat cu M IM E este compus din doua parti:
5
Codificarea base64 este identic

a cu radix 64 folosita de P GP . Singura diferenta consta n
adaugarea la base64 a unei sume de control pe 24 biti. Suma este calculata la intrarea datelor, nainte
de codificare, iar apoi este codificat
a cu algoritmul radix64, fiind separata (n transmisie) de restul datelor
prin simbolul =.
6
Un gateway este un computer/server care asigura transferul de informatie ntre diverse retele de
comunicatie.
20
Prima parte are antetul de continut application/pgp-encrypted si detine informatia

de control.
A doua parte trebuie sa contina mesajul criptat; ea este etichetata cu antetul
application/octet-stream.
Pentru generarea semnaturii digitale cu OpenP GP :
Mesajul care urmeaza sa fie semnat trebuie adus la forma canonica specifica antetului content type.
Se aplica o criptare de tipul Content Transfer Encoding. In particular, capetele de
linie ale mesajului trebuie sa foloseasca secvente < CR >< LF > (LF .
Se adauga antetele de continut M IM E.
Din mesajul semnat trebuie nlaturate spatiile.
Semnatura digitala se calculeaza atat pentru datele care urmeaza sa fie semnate cat
si pentru multimea antetelor de continut.
Semnatura trebuie sa fie detasata de mesajul pe care-l nsoteste, pentru a se evita
modificarea mesajului (cu o anumita procedura).
Se observa ca OpenP GP -ul respecta conventia ca mesajul semnat sa se termine cu o
secventa < CR >< LF >.
La primirea unui mesaj semnat, un client de mail trebuie:
Sa aduca capetele de linie < LC >< LF > la forma canonica, nainte de verificarea
semnaturii.
Sa trimita serviciului de verificare a semnaturii mesajul semnat si antetele de continut,
mpreuna cu semnatura OpenP GP .
Uneori se doreste atat semnarea digitala, cat si criptarea mesajului care urmeaza sa fie
trimis. Exista doua modalitati pentru realizarea acestui lucru:
Mesajul este ntai semnat conform antetului multipart/signature si apoi criptat conform antetului multipart/encrypted, pentru a forma corpul final al mesajului.
Acesta este cel mai folosit standard pentru trimiterea mesajelor.
Pachetul OpenP GP descrie o modalitate pentru semnarea si criptarea datelor ntrun singur mesaj OpenP GP .
Aceasta metoda favorizeaza reducerea supraprocesarii si creste compatibilitatea cu
implementarile non-M IM E ale OpenP GP -ului. Mesajele criptate si semnate n
3.5. S/M IM E
21
aceasta maniera combinata trebuie sa urmeze aceleasi reguli canonice ca un obiect

multipart/signed. Este permis n mod explicit unui agent de mail sa decripteze
un mesaj combinat si sa-l rescrie ca un obiect multipart/signed folosind semnatura
ncorporata n versiunea criptata.
3.4.4
Controverse legate de M IM E
Pe parcursul definirii standardului M IM E au aparut diverse controverse si dileme. Cateva

caracteristici discutate, dar care nu au fost incluse n standardul final, sunt:
Criptarea imbricat
a: Desi prezenta n primele versiuni ale formatului, n final s-a
renuntat la aceasta deoarece structura de ansamblu a mesajului nu putea fi vizibila
fara o decodificare prealabila. In al doilea rand, pot exista criptari imbricate n care
aceeasi informatie este codificata de mai multe ori. O consecinta a acestei decizii
consta n cresterea complexitatii pentru gateway.
Uuencode: A fost luat n considerare la nceput pentru a nlocui base64. A fost
respins deoarece:
nu exista o definire riguros formalizata;
rezultatul n urma aplicarii acestuia nu era robust pentru mai multe noduri
gateway.
uneori fisierele Uuencode ajung ntr-o forma care nu poate fi decodificata.
Compresia: Desi initial s-a considerat necesar un algoritm de compresie, acesta
nu a fost adoptat datorita situatiei legale incerte privind algoritmii de compresie si
lipsei unei experiente ndelungate a autorilor M IM E n acest domeniu.
Num
arul atributelor Content-type: S-au discutat propuneri legate de un numar
nelimitat de atribute, dar n acelasi timp s-a pus problema usurintei recunoasterii
acestora n cadrul antetului. In final, mecanismul sub-tipurilor a fost adoptat ca un
compromis.
3.5
3.5.1
S/M IM E
Comparatii cu P GP si OpenP GP
S/M IM E are o utilizare limitata doar la posta electronica, n timp ce P GP -ul are si alte
aplicatii cum ar fi n V P N (Virtual Private Network), criptarea volumelor hard-disk-ului,
arhivarea si criptarea fisierelor, batch processing etc.
Lungimea cheilor are o importanta deosebita pentru P GP si S/M IM E; din acest
punct de vedere securitatea oferita de S/M IM E este mult mai scazuta: chei de pana la
22
1024 biti n timp ce specificatia AN SI recomanda chei de minim 1024 biti pentru RSA
si Diffie-Hellman (DH).
Una din specificatiile S/M IM E ([3]), descrie o facilitate numita P oP (Proof of Possesion of Private Key) care permite transmiterea si stocarea cheilor private de catre autoritatea de certificare, n momentul n care utilizatorul solicita un certificat (a se vedea
capitolul dedicat P KI). P GP -ul nu are o astfel de problema de securitate legata de recuperarea cheilor, dar are un mecanism care a starnit multe controverse, numit Additional
Key Recovery (ADK). Aceasta facilitate nu este inclusa nsa n specificatia OpenP GP .
Se pot construi versiuni ale protocolului S/M IM E care sunt exemple clare ale notiunii
de cleptografie7 prin care se implementeaza rutine de generare a cheilor DH sau RSA
care produc chei aparent normale dar care contin o trapa secreta prin care un tert poate
recupera cheia privata. Acest proces reprezinta o extindere interesanta a conceptului de
canale subliminale. Astfel de canale nu pot exista nsa n cazul P GP -ului: orice inspectare
a codului sursa ar depista rapid orice problema de acest tip.
Utilizatorii S/M IM E dinafara SUA trebuie sa utilizeze chei simetrice RC2/40 cu o
lungime de 40 biti si chei publice mai mici de 582 biti.
Deci, din perspectiva securitatii P GP -ul poate fi considerat de departe mai sigur decat
S/M IM E, cel putin din doua motive:
S/M IM E este limitat la chei publice de 1024 biti; P GP -ul poate utiliza chei pana
la 4096 biti.
Specificatia P GP -ului este publica, fiind asadar supusa unei permanente revizuiri
de catre toti specialistii, n timp ce utilizatorii S/M IM E pot doar sa aiba ncredere
n eficienta implementarii.
3.5.2
Functionalitatea protocolului S/M IM E
Din acest punct de vedere, S/M IM E si P GP seamana foarte mult. Amandoua ofera
posibilitatea de a semna si/sau cripta mesaje.
Sa detaliem aceste functii pentru S/M IM E:
Poate cripta orice tip de continut si orice cheie de criptare, pentru unul sau mai
multi destinatari (enveloped data).
Poate semna date (signed data). O semnatura digitala este generata folosind amprenta corpului mesajului care va fi criptat cu cheia secreta a expeditorului. Perechea
formata din corpul mesajului si semnatura sunt apoi codificate cu base64.
Aceasta functie poate fi prelucrata numai daca destinatarul este dotat cu facilitati
S/M IM E.
7
Cleptografia reprezint
a studiul sustragerii de informatii n mod securizat si subliminal, constituind o
extensie natural
a a teoriei canalelor subliminale.
3.5. S/M IM E
23
Poate semna date n clar (clear-signed data). Ca si n cazul anterior, se genereaza o

semnatura a corpului mesajului, dupa care semnatura (si numai aceasta) se codifica
cu base64.
In acest caz orice destinatar (chiar si fara S/M IM E) poate citi mesajul, desi nu
poate verifica semnatura.
Poate semna si cripta date (signed and enveloped data). Corpul mesajului (criptat
sau nu) se semneaza, apoi semnatura (singura sau mpreuna cu corpul mesajului
criptat sau nu) se cripteaza din nou.
3.5.3
Algoritmii criptografici folositi de S/M IM E
Principalii algoritmi criptografici folositi de S/M IM E sunt:

Pentru crearea unei amprente: Functiile de dispersie folosite sunt SHA 1 si
M D5.
Pentru criptarea amprentei (si generarea semnaturii):
Ambele parti folosesc DSS.
Expeditorul foloseste RSA pentru criptare.
Destinatarul trebuie sa poata verifica semnaturi RSA cu chei pana la 1024 biti.
Pentru criptarea cheilor de sesiune:
Ambele parti folosesc ElGamal.
Expeditorul mai poate folosi pentru criptare RSA cu chei pana la 1024 biti.
Destinatarul trebuie sa poata efectua decriptari RSA.
Pentru criptarea mesajelor cu chei de sesiune one-time:
Expeditorul poate folosi criptarea cu 3DES sau RC2/40.
Expeditorul trebuie sa poata decripta 3DES (sau eventual RC2/40).
De remarcat similitudinea cu algoritmii de criptare folositi de P GP . Varianta utilizarii
RC2 pe 40 biti este recomandata doar pentru implementarile sistemelor americane care
mai mentin n unele servicii acest sistem de criptare (destul de slab).
Specificatiile S/M IM E includ o discutie asupra procedurii de selectie a algoritmului
de criptare.
De obicei, Alice trebuie sa faca doua alegeri. Intai, ea trebuie sa determine daca Bob
este capabil sa decripteze un mesaj criptat cu un sistem de criptare dat. Apoi, daca Bob
24
accepta numai texte criptate cu sisteme slabe, Alice trebuie sa decida daca poate trimite
mesajul folosind o criptare slaba. Pentru aceasta, toti partenerii trebuie sa anunte n
prealabil capacitatile solicitate pentru decriptarea mesajelor pe care le trimit, n ordinea
descrescatoare a preferintelor.
Fiecare destinatar poate stoca aceste informatii pentru a le folosi ulterior.
Pentru a trimite un mesaj, Alice trebuie sa verifice urmatoarele variante (n ordine):
1. Daca ea are o lista de capacitati de decriptare ale lui Bob, va alege primul sistem
de criptare pe care este capabila sa-l foloseasca.
2. Daca nu are lista lui Bob, dar detine cel putin un mesaj de la el, atunci mesajul
trimis de Alice va folosi acelasi algoritm de criptare folosit n mesajele respective.
3. Daca nu detine nici o informatie despre capacitatile de decriptare ale lui Bob, dar
este dispusa sa riste ca mesajul sa nu poata fi citit, va trimite un mesaj criptat cu
3DES.
4. Daca nu detine nici o informatie despre capacitatile de decriptare ale lui Bob, si nu
vrea sa riste ca mesajul sa nu poata fi citit de acesta, atunci Alice va trimite un
mesaj criptat cu RC2/40.
In plus, mesajele trimise prin posta electronica (n special pentru S/M IM E) beneficiaza si de o serie de protectii P KI (certificari, semnaturi ale unei autoritati centrale etc)
recomandate de laboratoarele RSA.
3.5.4
Servicii de securitate mbun

at
atite pentru S/M IM E
Definitia 3.1. Un mesaj triplu mpachetat reprezint

a un mesaj care a fost semnat, criptat
si apoi semnat din nou.
Expeditorii care semneaza mesajul interior si pe cel exterior pot fi una sau aceeasi persoana, sau entitati diferite. Specificatia S/M IM E nu limiteaza numarul de mpachetari
ncuibarite, deci se pot realiza mai mult de trei mpachetari ale aceluiasi mesaj.
Semnatura interioara este utilizata pentru verificarea integritatii continutului, a nonrepudierii originii acestuia, precum si adaugarea la mesaj a anumitor atribute. Aceste
atribute sunt transmise de la expeditorul initial pana la destinatarul final, indiferent de
numarul de entitati intermediare.
Atributele semnate pot fi folosite pentru controlarea accesului la corpul mesajului.
Conti-nutul criptat al mesajului asigura confidentialitatea acestuia, inclusiv confidentialitatea
atributelor incluse n semnatura interioara.
3.5. S/M IM E
25
Semnatura exterioara asigura autenticitatea si integritatea informatiei procesate saltcu-salt8 , fiecare salt reprezentand o entitate intermediara un agent de mail de exemplu.
Semnatura exterioara asociaza atribute corpului criptat. Aceste atribute pot fi folosite
pentru controlul accesului si luarea deciziilor de rutare.
Mesaje triplu mpachetate

Etapele urmate pentru crearea unui mesaj triplu mpachetat sunt:
1. Se porneste de la continutul original (corpul mesajului).
2. Mesajul original este ncapsulat cu antetele M IM E content-type corespunzatoare.
3. Se semneaza antetul M IM E si continutul original rezultate din pasul 2.
4. Se adauga o structura M IM E corespunzatoare mesajului rezultat la pasul 3. Mesajul
rezultat se numeste semnatura interioar
a.
5. Rezultatul se cripteaza ca un bloc unitar, ntr-o structura M IM E sau obiect pkcs7
- mime.
6. Se adauga antetele M IM E corespunzatoare: content-type-ul pentru structura
M IM E sau obiectul pkcs7 - mime cu parametri, precum si antete M IM E optionale,
cum ar fi Content-Transfer-Encoding sau Content-Disposition.
7. Rezultatul de la 6 (antetele M IM E si corpul criptat) se semneaza ca un bloc unitar.
8. Utilizand o logica asemanatoare cu cea de la pasul 4, se adauga o structura M IM E
corespunzatoare mesajului semnat de la pasul 7. Mesajul rezultat poarta numele de
semn
atura exterioara si reprezinta de fapt mesajul triplu mpachetat.
Un mesaj triplu mpachetat are mai multe nivele (layere) de ncapsulare. Structura difera
n functie de formatul ales pentru semnarea portiunilor mesajului. Datorita modului n
care M IM E structureaza datele, acestea nu apar ntr-o anumita ordine, ceea ce face ca
notiunea de layer sa devina oarecum ambigua.
8
Salt-cu-salt (hop-by-hop) reprezint

a un tip de rutare; operatia de rutare consta n determinarea
nodului intermediar urm
ator (adiacent), care la randul lui poate redirectiona mesajele catre destinatia
finala si, n general, nu permite determinarea ntregii secvente de noduri intermediare.
26
3.6
P EM
3.7
Anexa 1: Algoritmul de compresie ZIP
P GP foloseste algoritmul de compresie ZIP scris de Jean-Lup Gailly, Mark Adler si

Richard Wales si folosit ca utilitar pe UNIX. Functional, el este echivalent cu PKZIP,
sistemul creat de PKWARE si folosit de Windows.
Algoritmul de zipare este se pare cel mai utilizat algoritm de compresie; este free si a
fost implementat pentru toate sistemele actuale de calcul.
Bazele teoretice ale ZIP -ului (si a tuturor variantelor sale) au fost puse n 1977 de
Jacob Ziv si Abraham Lempel, care au construit algoritmul LZ77 de spargere a informatiei
continute intr-un buffer.
Motivatia este ca multe cuvinte dintr-un text (patternuri de imagini n cazul unui GIF
etc) se repeta. Aceasta secventa care se repeta poate fi nlocuita cu un cod scurt.
Exemplul 3.4. ([7], pag. 392) Sa consider
am urm
atorul text (f
ar
a semnificatie semantic
a):
the brown fox jumped over the brown foxy jumping frog
Lungimea lui este de 53 octeti = 424 biti. Algoritmul LZ77 parcurge texul de la st
anga
spre dreapta.
Initial, fiecare caracter este codificat ntr-o secvent
a de 9 biti, unde primul bit este 1, iar
urm
atorii opt biti contin codul ASCII al caracterului.
cazul nostru, aceasta
Algoritmul cauta secventele de lungime maxim
a care se repet
a. In
este the brown fox. Prima aparitie a secventei este p
astrat
a, iar celelalte sunt nlocuite
cazul
de un pointer la aceasta aparitie si de un num
ar care d
a lungimea secventei. In
nostru, a doua aparitie se nlocuieste cu perechea (26, 13) (secventa de aici repet
a pe cea
care a nceput 26 caractere mai devreme, pe o lungime de 13 caractere).
S
a presupunem ca sunt doua optiuni de codificare a perechii: un pointer pe 8 biti si un
num
ar pe 4 biti (optiunea 00) sau un pointer pe 12 biti si un num
ar pe 6 biti (optiunea
01). Optiunea este data la nceputul perechii.
Deci a doua aparitie a secventei the brown fox este codificat
a < 00b >< 26d ><
13d > (b - binar, d - zecimal), sau 00 00011010 1101.
continuare, din mesaj a ramas litera y, secventa < 00b >< 27d >< 5d > (care
In
nlocuieste un spatiu, plus textul jump) si secventa de caractere ing frog. A r
amas
the brown fox jumped over 0b 26d 13d y 0b 27d 5d ing frog
Textul compresat are 35 caractere de c
ate 9 biti si dou
a coduri; n total 359+214 = 343
biti; o rat
a de compresie de 1, 24.
Practic, algoritmul LZ77 foloseste doua buffere (n figura, B1 si B2 ).
3.8. ANEXA 2: CONVERSIA RADIX 64
Iesire
B1
27
Deplasare text sursa

?
B2
Surs
a
Iesire text compresat

B1 contine ultimele n caractere ale sursei care au fost prelucrate, iar B2 contine urmatoarele p caractere care urmeaza sa fie prelucrate.
Algoritmul cauta daca un prefix (|| = s 2) din B2 se afla ca subsir n B1 .
Daca nu, primul caracter din B2 iese codificat pe 9 biti n secventa compresata si
simultan este deplasat n B1 . Daca este n B1 , se continua cautarea pentru a gasi cel
mai lung subsir comun, de lungime k. Acesta este scos ca text compresat sub forma unui
triplet (indicator, pointer, k). Cele mai din stanga k caractere din B1 sunt eliminate, iar
cele k caractere din topul lui B2 trec n B1 .
3.8
Anexa 2: Conversia radix 64
Informatiile transferate prin comunicatiile digitale sunt secvente de biti, fara nici o formatare. Algoritmii de receptie formateaza bitii n blocuri de 64, 32 sau 8 biti.
Deoarece sistemele de e-mail permit transmiterea si receptia doar a codurilor ASCII
pe 8 biti, protocoalele de e-mail convertesc textul criptat alocand fiecarui grup de 6
biti, un caracter ASCII printabil. Algoritmul de codificare folosit de ambele protocoale
(P GP, S/M IM E) este numit radix 64 ([1]).
Principalele sale caracteristici sunt:
Domeniul de definitie este format din multimea caracterelor reprezentabile binar
(atentie ! nu o anumita codificare binara, ci orice caracter reprezentabil n binar).
Multimea valorilor este formata din 65 caractere printabile: unul este pentru legatura (pad), iar celelalte 26 = 64 sunt reprezentate pe 6 biti.
Nu exista caractere de control; deci un mesaj codificat n radix 64 va trece fara
probleme prin sisteme de posta care scaneaza secventele pentru depistarea caracterelor de control.
Caracterul (cu semnificatie n multe sisteme, inclusiv RF C 822) nu este folosit;
deci el trebuie eliminat anterior.
Codificarea celor 64 caractere din sistemul radix 64 este data de tabelul urmator. Sunt
folosite cele 52 litere (mari si mici), cele zece cifre si caracterele +, /.
28

Valoare
6-biti
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Cod
Caracter
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Valoare
6-biti
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Cod
Caracter
Q
R
S
T
U
V
W
X
Y
Z
a
b
c
d
e
f
Valoare
6-biti
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Cod
Caracter
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
Valoare
6-biti
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
pad
Cod
Caracter
w
x
y
z
0
1
2
3
4
5
6
7
8
9
+
/
=
Procedura de codificare este simpla: fiecare secventa de 3 octeti (24 cifre binare) este
mpartita n patru secvente de 6 biti fiecare. Apoi fiecare grup de 6 biti este codificat prin
caracterul din tabel.
Deci o intrare de 24 biti este expandata la iesire pe 32 biti.
Exemplul 3.5. Fie secventa de 24 biti
00100011 01011100 10010001
(235C91 n hexazecimal). Aranjata n grupuri de c
ate 6 biti, ea este
001000 110101 110010 010001.
Valorile zecimale ale acestor patru secvente binare sunt 8, 53, 50 si 17.
Folosind acum tabela radix 64 se obtine I1yR.
Trecut
a n format ASCII (8 biti, cu 0 pe bitul de paritate), avem
01001001 00110001 01111001 01010010
Sau n hexazecimal 49317952.
Altfel spus, codificarea radix 64 transform
a 235C91 n 49317952.
3.9
Exercitii
1. P GP foloseste pentru CAST 128 modul de criptare CF B, n timp ce majoritatea

sistemelor de criptare prefera modul CBC. Reamintim:
3.9. EXERCIT
II
In modul CBC :
In modul CF B :
29
Ci = eK (Ci1 Pi ),
Pi = Ci1 dK (Ci )
Ci = eK (Ci1 ) Pi ,
Pi = Ci eK (Ci1 )
Ambele moduri ofera acelasi grad de securitate. Sugerati un motiv pentru care
P GP prefera folosirea modului CF B.
2. Comprimati folosind codul LZ77 textul
A fost odata ca-n povesti, A fost ca niciodat
a.
3. Formalizati n pseudocod algoritmul LZ77. Scrieti un program pentru implementarea lui.
4. Scrieti programe pentru codificarea si decodificarea mesajelor folosind radix 64.
30
Bibliografie
[1] D. Atkins, W. Stallings, P. Zimmermann P GP mesage exchange formats (RFC
1001), http://www.ietf.org/rfc/rfc1991.txt?number=1991
[2] N. S. Borenstein MIME: A Portable and Robust Multimedia Format for Internet
Mail, Springer-Verlag, 1993.
[3] M. Myers, X. Liu, B. Fox, H. Prafullchandra, J. Weinstein Certificate Request Syntax,
(1997) http://tools.ietf.org/html/draft-ietf-smime-crs-00
[4] M. Mogollon Cryptography and Security Services: Mechanisms and Applications,
Cybertech Publishing, 2007.
[5] M. Y. Rhee Internet Security - Cryptographic Principles, Algorithms and Protocols,
Wiley Interscience, 2003.
[6] B. Schneier Applied Cryptography, ed. II-a, Wiley Interscience, 1996
[7] W. Stallings Cryptography and Network Security: Principles and Practice, Prentice
Hall, Second Editoon, 1999.
[8] P. Zimmermann An introduction to Cryptography, Network Associates, 2(2003)
http://www.pgpi.org/doc/guide/6.5/en/intro/
31
Capitolul 4
Smart Carduri
4.1
Prezentare general
a
Un smartcard este un sistem de calcul portabil (sau detasabil) utilizat n efectuarea

unor tranzactii, cu competente sporite pentru a prezenta sau autentifica o identitate;
el ncorporeaza o paleta larga de subansamble care asigura securitatea fizica si logica.
O serie de aplicatii utilizeaza smartcarduri n sisteme de securitate, pentru stocarea
de secrete sau utilizarea de algoritmi proprii (care nu influenteaza sistemul de securitate).
4.1.1
Istoric
Smartcardurile au fost inventate si patentate n anii 70. J

urgen Dethloff (Germania),
Arimura (Japonia) si Roland Moreno (Franta) si disputa paternitatea. In mod cert nsa,
prima utilizare pe scara larga a cardurilor a fost Telecarte cartela telefonica prepaid
folosita n Franta ncepand cu 1983.
Roland Moreno este cel care a patentat conceptul de card cu memorie n 1974. In
1977, Michel Ugon (Honeywell Bull) a inventat primul microprocesor de smartcard. Tot
Honeywell Bull patenteaza n 1978 SP OM (Self Programmable One-chip Microcomputer)
care defineste arhitectura unui cip de smartcard. Dupa 3 ani, Motorola produce primul
micro-cip CP8 bazat pe acest patent.
Utilizarea cardurilor explodeaza n anii 90, odata cu introducerea n telefonia mobila
GSM a smartcardurilor bazate pe SIM .
4.1.2
Clasific
ari
In general cardurile (cartelele) sunt de trei tipuri:

Carduri (cartele) magnetice:
Cardurile magnetice au nglobata o unitate de memorie relativ mica (maxim 100
1
CAPITOLUL 4. SMART CARDURI
octeti) sub forma unei benzi magnetice si sunt destinate unei singure aplicatii. Cele
mai cunoscute sunt cartelele telefonice.
Carduri cu procesor (smartcarduri):
Contin un mini-procesor, ceeea ce le da posibitatea de a rula mai multe aplicatii
prezente pe acelasi card. Avantajul unui smartcard fata de un card magnetic este
acela ca poate sa proceseze datele din memorie.
Ca o comparatie ntre aceste doua tipuri, cardurile cu banda magnetica nu au capacitati de procesare, sunt semnificativ mai nesigure decat smartcard-urile dar costa
mai putin. In schimb, cititoarele de cartele magnetice sunt mult mai scumpe decat
terminalele pentru smartcard-uri, fiind si mai putin sigure.
Carduri hibride:
Sunt o combinatie ntre celelalte doua tipuri.
Din 1982, bancile franceze au folosit carduri cu chip si banda magnetica pentru
operatii de credit, care permit bancilor sa migreze catre smartcard-uri. S-au obtinut
astfel avantajele unor cartele mai sigure, rezervand n acelasi timp o perioada rezonabila modernizarii infrastructurii bazate pe cartele magnetice.
n prezent exista carduri hibride care contin simultan micro-cip, banda magnetica,
cod de bare, memorie optica, poza si tabela de semnatura.
Din punct de vedere al modului de legatura cu exteriorul, smartcardurile se mpart n:
Cardurile cu contacte.
Transferul de date se face prin intermediul unui cititor de card, cu care se stabileste
un contact direct.
Cardurile fara contacte contin pe langa un cip cu micro-procesor un dispozitiv
de emisie-receptie radio cu antena. Pot functiona numai la distante foarte mici de
cititorul de carduri.
Aceste carduri sunt de obicei mai costisitoare si sunt dedicate unor aplicatii specifice
cum ar fi pentru transporturi sau pentru accesul n cladiri.
Cipul nglobat ntr-un smartcard este un microprocesor (M CU ). Deci un M CU este
un sistem de calcul miniatural integrat pe o singura piesa de silicon. Resursele sale sunt
separate complet de interfetele cu utilizatorul sau alt sistem de calcul; lipsesc componente
I/O cum ar fi tastatura, monitor, discuri, drivere etc.
Cipul de pe un smartcard este un M CU securizat: deoarece lucreaza doar sub controlul software-ul din ROM, programele sale nu sunt accesibile sub nici o forma unui
utilizator extern. Prin constructia sa, un M CU securizat este capabil sa previna accesul neautorizat la CP U (unitatea centrala de prelucrare), memorie, magistrale sau date
stocate/prelucrate n interior.
4.2. HARDWARE-UL UNUI SMARTCARD
4.2
4.2.1
Hardware-ul unui smartcard

Forma unui smartcard
Un card are o forma dreptunghiulara, ale carei dimensiuni sunt stabilite de standardul
ISO/IEC 7816: 85.60 53.98 mm, iar grosimea este 0.76 mm1 . De exemplu:
Pe una din fete este inserat un micro-cip, de o anumita forma. De exemplu:
Oricare ar fi cip-ul inserat, el este pozitionat conform standardului de mai sus, astfel:
Pentru cardurile f
ar
a contacte exist
a un alt standard: ISO 14443.
Detaliind, cele opt zone de contact ale unui cip sunt aranjate:
cu semnificatia si functionarea urmatoare:

Pozitie Abreviere Functie
C1
VCC
Asigura voltajul
C2
RST
Reset
C3
CLK
Frecventa de ceas
C4
RFU
Rezervata pentru utilizare ulterioara
C5
GND
Inpamantare
C6
VPP
Legatura pentru voltaj extern
C7
I/O
Legatura seriala input/output
C8
RFU
Rezervata pentru utilizare ulterioara
Contactul V P P este o reminiscenta; a fost utilizat pentru a suplimenta voltajul la
EEP ROM n operatiile de programare si stergere. Din ratiuni de securitate, n prezent
se face apel la el extrem de rar.
Contactul V CC asigura un voltaj standard de 5 volti 10%, dar se prevede construirea
unei tehnologii operationale la un standard de 3 volti. Motivul este asigurarea unei
compatibilitati ntre piata smartcardurilor si cea a telefoniei mobile. Un telefon mobil
lucreaza pe o configuratie de 3 volti, iar cardurile au ramas singura componenta care
solicita telefonului mobil sa aiba un convertor de ncarcare.
4.2.2
Sistemul de calcul al unui smartcard
Sistemul de calcul dintr-un smartcard este format dintr-un singur circuit integrat, care
include unitatea centrala de procesare (CP U ), memoria si liniile de Intrare/Iesire (I/O).
4.2. HARDWARE-UL UNUI SMARTCARD
5
ROM
RST
CLK
I/O
V CC
4.2.3
Control
I/O
CP U
NV M
Memorie non-volatila
RAM
Memorie volatila
Memoria
Exista trei tipuri de memorie ntr-un smart-card:

1. Memoria read-only (ROM ).
Aici este memorat sistemul de operare, precum si diferite rutine pentru comunicare,
pentru administrarea sistemului de fisiere de pe card mpreuna cu rutine pentru
criptare sau functii matematice speciale. Datele si codurile programelor sunt plasate
n memoria ROM n faza de fabricare a cardului.
2. Memoria non-volatila (N V M ).
Memoria nonvolatila (NonVolatile Memory N V M ) este o memorie de calculator
care poate retine informatie chiar daca sistemul de calcul este debransat. Exemple
de memorii nonvolatile: memorii read-only, memorii flash, tipuri de componente
de stocare magnetica (cum sunt hard-discurile, discurile floppy, banda magnetica),
discuri optice, cartele perforate. Memoria non-volatila aflata pe aproape cardurile
este EEP ROM (Electrically Erasable Programmable Read-Only Memory). Aici sunt
depuse diverse date variabile (numerele de cont, numarul de puncte de loialitate sau
sume de bani) care trebuie retinute de smartcard.
O memorie N V M poate fi scrisa si citita de aplicatii, dar nu poate fi folosita ca o
memorie RAM .
3. O cantitate relativ minuscula de memorie cu acces aleator (RAM ). Ea este
resursa cea mai pretioasa din punctul de vedere al dezvoltatorului de software. Mai
mult, RAM - ul este folosit nu numai de aplicatiile programatorului ci si de restul
rutinelor utilitare.
4.2.4
Unitatea central
a de procesare (CP U )
Pentru micro-controlerele pe 8 biti, CP U -ul unui smartcard foloseste de obicei instructiuni

din seturile Motorola 6805 sau Intel 8051.
Aceste seturi contin instructiunile uzuale de manipulare a memoriei si registrilor, de
adresare si de intrare/iesire. Unitatea centrala de prelucrare executa instructiunile la o
rata de 400.000 de instructiuni pe secunda (400 KIP), desi viteze de pana la 1 milion de
instructiuni pe secunda (1 MIP) devin disponibile la cipurile de ultima generatie.
Evolutia smartcard-urilor este extrem de rapida. Astfel, dimensiunea memoriei creste
iar arhitecturile procesoarelor se muta de pe configuratii pe 8 biti, pe unele de 16 sau
chiar 32 biti.
4.2.5
Iesirile/intr
arile unui smartcard
Canalul de intrare/iesire al unui smartcard este unul serial uni-directional. Hardwareul smartcardului poate suporta transfer de date de pana la 115.200 biti/secunda, dar
cititoarele de carduri comunica de obicei la viteze mult mai mici.
Comunicarea dintre terminal si card se bazeaza pe o relatie master (terminal) - slave
(smartcard): terminalul trimite comenzi catre card si asteapta raspunsul. Smartcard-ul
nu trimite niciodata date catre terminal decat sub forma unui raspuns la o comanda
data de terminal.
4.3
Software-ul pentru smartcard-uri
Exista doua tipuri fundamentale de software pentru smartcard-uri:

1. Software-ul pentru terminal (gazda); aplicatiile nglobate n el ruleaza pe un computer conectat la un smartcard.
2. Software-ul instalat pe card.
Este uneori util sa clasificam software-ul de smartcard n:
Software aplicatie:
Foloseste capacitatile computationale si de memorare ale smartcard-ului, ca si cum
ar fi cele ale unui computer oarecare; el face abstractie de integritatea si securitatea
datelor prezente pe smartcard.
Software sistem:
Foloseste explicit aceste cerinte si deci poate contribui la sporirea integritatii si
securitatii datelor.
4.3.1
Comparatie ntre software-ul gazd

a si software-ul de card
Cea mai mare parte a softului pentru smartcarduri consta n programele scrise pentru
terminale. Aceste programe acceseaza smartcard-urile existente integrandu-le n sisteme
mai mari. Software-ul gazda include de obicei:
aplicatii pentru utilizatori,
4.3. SOFTWARE-UL PENTRU SMARTCARD-URI
programe la nivel de sistem care accepta smartcard-uri specifice, folosite pentru a

ajuta aplicatiile pentru utilizatori.
aplicatii utilitare necesare administrarii infrastructurii smartcard-urilor.
Programele gazda sunt scrise de obicei n limbaje de programare de nivel nalt aflate
pe computere personale si statii de lucru: C, C++, Java, FORTRAN; ele sunt legate
de biblioteci de functii si drivere pentru a accesa cititoarele de smartcard-uri si cartele
introduse n ele.
Software-ul de card este scris de obicei n limbaje sigure precum Java sau limbaje
apropiate de cod - masina (exemplu: Forth sau limbaje de asamblare).
Aplicatiile gazda substituie uneori smartcard-ul cu o implementare alternativa avand
aceeasi functionalitate. Astfel, o cheie de criptare sau o informatie medicala este pastrata
pe un smartcard si nu ntr-un fisier pe hard disk sau ntr-o baza de date pe un server.
Software-ul gazda manipuleaza capacitatile unice de calcul si stocare ale cardului
trimitand comenzi acestuia si obtinand rezultatele generate.
Software-ul de card este clasificat n:
sisteme de operare,
utilitare,
aplicatii software.
Aplicatiile de card sunt de obicei folosite pentru a personaliza un smartcard existent
pentru o utilizare dedicata si pentru a realiza un transfer de functionalitate de la aplicatia
gazda la card. Acest lucru poate fi facut din considerente de eficienta sau de securitate
(pentru a proteja o anumita parte din sistem).
Software-ul de card este scris n general n limbaje de nivel inferior, avand ca tinta
un anumit tip de card si este folosit pentru a extinde sau nlocui functii de baza ale
smartcard-ului.
Aplicatiile gazda si cele de card difera n orientare si nfatisare. Software-ul de card
se concentreaza pe continutul unui anumit card. El ofera servicii computationale pentru
unele aplicatii care acceseaza acest continut si pe care l protejeaza de celelalte aplicatii
care ar putea ncerca sa l acceseze incorect.
Software-ul gazda se poate folosi nsa de diferite carduri. El este de obicei compatibil
cu multe terminale si posibil mai multi emitatori de carduri precum si diferite tipuri
de cartele.
Software-ul de card implementeaza particularitatile de procesare, precum si cerintele
de securitate ale unei cartele specifice. De exemplu, un program care ruleaza pe un card
poate sa nu dezvaluie numarul de cont memorat decat daca i se prezinta un PIN corect
sau poate aplica semnatura digitala folosind o cheie privata memorata pe card. Softwareul care ruleaza pe un smartcard ofera acces autorizat securizat la datele memorate pe
card. El este constient doar de continutul unui anume smartcard si de entitati (precum
oamenii, computerele, terminalele, consolele de jocuri etc.) care ncearca sa-l acceseze.
Software-ul gazda conecteaza smartcard-urile si posesorii lor la sisteme mai mari. De
exemplu, software-ul dintr-un bancomat foloseste smartcard-urile introduse de clientii
bancii pentru a-i identifica si a-i conecta la conturile bancare pe care le detin.
Software-ul gazda este compatibil cu multe smartcard-uri si si va adapta raspunsul n
functie de smartcard-ul prezent.
Spre deosebire de software-ul obisnuit, care depinde de suportul serviciilor din contextul care-l nconjoara, software-ul de card porneste de la premiza ca se afla ntr-un context
ostil, n care nu poate avea ncredere.
Pana cand nu li se prezinta o dovada convingatoare a contrariului, smartcard-urile nu
au ncredere n terminalele unde sunt introduse, si reciproc: terminalele nu au ncredere
n cardurile prezente. Un program de smartcard are ncredere numai n el nsusi. Orice se
afla nafara programului trebuie sa se autentifice nainte ca programul sa interactioneze
cu el.
4.4
Functiile unui smartcard
Conform celor prezentate anterior, un smartcard asigura cinci operatii de baza:

1. Introduce date;
2. Scoate date;
3. Citeste date din memoria nonvolatila (N V M );
4. Scrie sau sterge date din N V M ;
5. Calculeaza o functie criptografica.
Desi toate aceste operatii au legaturi cu componenta de securitate a cardului, gradul major
de risc apartine operatiilor (2) si (4). Operatia (2) ofera n exterior date si rezultate, iar
(4) modifica continutul N V M .
De exemplu:
Nici o informatie referitoare la cheile secrete folosite de microprocesor nu trebuie
oferita mediului exterior.
Unele date din memoria nonvolatila pot da drept de acces la anumite resurse; deci
trebuie luate masuri speciale de protectie nainte de stergerea sau scrierea datelor.
Rezultatul unui calcul criptografic poate fi un cuvant de control livrat exteriorului
(exemplu: pentru a decodifica un semnal TV); deci si aici trebuie asigurate masuri
de protectie nainte de efectuarea calculului si externarea rezultatului.
4.5. SISTEMUL DE OPERARE PENTRU SMARTCARD
Cardul trebuie sa fie sigur ca operatiile sunt efectuate de proprietarul de card, sau ca
anumite comenzi primite au fost formulate de emitatorul de card. O serie de mecanisme
si tehnici de la P IN sau M AC pana la scheme sofisticate de semnatura electronica
sunt utilizate de card pentru a controla aceste lucruri.
Aceste mecanisme sunt bazate atat pe tehnici criptografice cat folosind si tehnici empirice.
Cardul poate reactiona la unele tipuri de ncercari de frauda. De exemplu, trei P IN uri gresite vor duce la blocarea cardului
Cresterea dimensiunii memoriei si a vitezei de calcul asociate cu proceduri sofisticate de
securitate fac posibila elaborarea unui set sporit de mecanisme care sa asigure securitatea
logica2 a smartcardului.
Exemplul 4.1. Smartcardurile emise de unele unit
ati bancare au memoria nonvolatila
segmentat
a (fizic) n mai multe zone:
- O zon
a deschisa, accesibila fara restrictii;
- O zon
a protejata unde citirea este liber
a, dar pentru scriere este necesar
a cunoasterea
unei parole;
- O zon
a confidentiala, unde accesul la citire este permis doar cu parol
a;
- O zon
a secreta care contine P IN -uri, parole si chei criptografice.
Cardurile actuale au memoria nonvolatila organizata diferit la nivel logic fata de nivelul
fizic. In acest fel, zonele sunt mult mai putin vizibile: locatia fizica exacta a unui fisier n
N V M poate diferi pe diverse carduri si deci este mult mai greu de depistat.
4.5
Sistemul de operare pentru smartcard
Sistemul de operare al cipului de pe smartcard (numit frecvent COS sau uneori

M ask) este o secventa de instructiuni stocata n memoria ROM a smartcard-ului. Similar
sistemelor de operare aflate pe PC-uri (cum ar fi Unix sau Windows), instructiunile COS
nu depind de o aplicatie anume, dar sunt frecvent folosite de majoritatea aplicatiilor.
Sistemele de operare de pe un cip sunt mpartite n:
1. COS pentru scopuri generale; contin un set de instructiuni generale care acopera
majoritatea aplicatiilor.
2. COS-uri dedicate; contin comenzi speciale pentru unele aplicatii eventual nsasi
aplicatia. Este cazul cardurilor special concepute n acest scop (mai ales n zona de
comert electronic).
Functiile de baza ale unui COS (comune tuturor smartcard-urilor) cuprind:
2
Spre deosebire de securitatea fizic

a, securitatea logica a unui card are ca scop protejarea informatiei
aflate n microcomputerul de pe card.
10
Administrarea inter-schimbului de informatii dintre card si exterior, n primul rand

n termeni de protocol de comunicare.
Administrarea fisierelor si datelor aflate n memorie.
Controlul accesului la informatii si functii (de exemplu, selectie de fisiere, citirea,

scrierea si actualizarea datelor).
Administrarea securitatii cardului si a algoritmilor criptografici.
Mentinerea fiabilitatii, n special n cazul consistentei datelor, secventelor de ntrerupere si revenirea dupa o eroare.
Administrarea diverselor faze din ciclul de viata al cardului (fabricarea micro-cipului,

personalizarea, perioada activa, distrugerea).
Dupa cum s-a precizat, relatia de baza dintre terminal si smartcard este de tip master slave: terminalul trimite o comanda smartcard-ului, acesta o executa, ntoarce rezultatul
catre terminal si apoi asteapta alta comanda.
In plus, standardele referitoare la smartcarduri (ISO 7816 si CEN 726) descriu o gama
larga de comenzi pe care smartcardurile le pot implementa. Majoritatea fabricantilor de
smartcard-uri ofera produse cu sisteme de operare ce implementeaza aceste comenzi standard (sau o parte din ele) mpreuna cu extensii si mbunatatiri specifice producatorului.
4.5.1
Sistemul de fisiere al smartcardurilor
Majoritatea sistemelor de operare pentru smartcarduri suporta un sistem redus de fisiere,

bazat pe standardul ISO 7816. Deoarece smartcardurile nu au periferice, un sistem de
fisiere smartcard are o singura radacina si o ierarhie bazata pe directoare, n care fisierele
pot avea nume alfanumerice lungi, denumiri scurte numerice si nume relative.
4.5. SISTEMUL DE OPERARE PENTRU SMARTCARD
11
Fisier
radacina
Fisier
elementar
Fisier
dedicat
Fisier
elementar
Fisier
dedicat
Fisier
elementar
Fisier
dedicat
Fisier
elementar
Fisier
elementar
Sistemele de operare de pe smartcard suporta setul uzual de operatii cu fisiere: crearea,

stergerea, citirea, scrierea si actualizarea.
In plus, sunt suportate operatii pe tipuri particulare de fisiere.
Exemplul 4.2. Fisierele liniare sunt formate dintr-o serie de nregistr
ari de lungime fixa,
care pot fi accesate dupa numarul nregistr
arii, sau citite secvential folosind operatiile de
citit urm
atoarea sau precedenta nregistrare. Mai mult, unele sisteme de operare suporta
o form
a limitata de cautare n astfel de fisiere.
Fisierele ciclice sunt fisiere liniare care cicleaz
a napoi la prima nregistrare atunci
c
and dup
a ultima nregistrare este citit
a sau scris
a nc
a o inregistrare.
Fisierele portofel formeaza un tip de fisier specific (folosit n aplicatii de comert
electronic), suportat de sistemele de operare smartcard.
Aceste fisiere sunt ciclice, fiecare nregistrare contin
and informatie despre o tranzactie a
portofelului electronic.
fine, fisierele transparente sunt blocuri nediferentiate de memorie, care pot fi strucIn
turate de aplicatii n functie de necesit
ati.
Fiecarui fisier de pe card i este asociata o lista pentru controlul accesului. Aceasta
lista retine operatiile pe care le poate efectua fiecare din identitatile prezente pe card.
De exemplu, entitatea A poate avea dreptul de a citi un anumit fisier, dar nu si de
a-l actualiza, n timp ce B poate sa citeasca, scrie si chiar modifica drepturile de acces
pentru acel fisier.
4.5.2
Structurile de date ale protocolului de aplicatie (AP DU )
Protocolul de baza n stabilirea unei linii de comunicatie ntre smartcard si terminal este
pachetul Application Protocol Data Units (AP DU ).
Un AP DU poate fi considerat un pachet de date care contine o cerere completa sau
un raspuns complet dat de un smartcard.
ISO 7816 4 defineste doua tipuri de APDU - uri:
12
De comanda: trimise de aplicatia gazda.

Formatul unui astfel de fisier este:
CLA IN S
P 1 P 2 Lc
Date optionale
Le
unde:
1. CLA: Identifica clasa instructiunii; de exemplu, instructiunea poate fi standard
ori particulara.
2. IN S: Octet care determina comanda respectiva.
3. P 1, P 2: Doi octeti folositi pentru a transfera parametri specifici comenzii.
4. Lc: Octet care codifica lungimea datelor optionale transmise card-ului cu acest
AP DU .
5. Date optionale: sirul de octeti cu lungimea Lc care poate contine datele
propriu-zise ce vor fi procesate de card.
6. Le: Octet care specifica lungimea datelor ce se asteapta a fi returnate de catre
AP DU -ul de raspuns urmator.
Daca Le = 0x00, gazda se asteapta ca toate datele disponibile sa fie trimise n
raspunsul la comanda.
De r
aspuns: trimise napoi de smartcard, ca reactie la comenzi.
Formatul AP DU -urilor de raspuns este:
Date optionale
SW 1 SW 2
unde:
1. Date optionale: un sir de Le octeti daca acest AP DU este raspunsul unui
AP DU comanda ce avea octetul Le setat pe o valoare nenula.
Altfel numarul octetilor este variabil.
2. SW 1, SW 2: Doi octeti de stare, care contin informatii de stare definite conform ISO 7816-4.
Aplicatia software foloseste un protocol bazat pe AP DU -uri pentru schimbul de control si informatie ntre card si cititorul de carduri. Aceste AP DU -uri sunt schimbate
folosindu-se protocoalele la nivel de conexiune T = 0 si T = 1. Protocolul T = 0 este
orientat pe octeti, iar T = 1 este orientat pe blocuri de octeti. Mai exista si alte protocoale alternative pentru smartcardurile fara contacte (bazate pe tehnologia JavaCard)
cum ar fi T = U SB sau T = RF .
O componenta software de pe card interpreteaza aceste AP DU -uri si executa operatiile
specificate; aceasta arhitectura este ilustrata mai jos:
I IMPLICATE IN CONSTRUCT
4.6. ENTITAT
IA/UTILIZAREA UNUI SMARTCARD13
Aplicatie
Functii specifice
Raspuns
AP DU
Comanda
AP DU
Terminal
Raspuns

(Protocolul T = 0 sau T = 1)
4.6
Card

6
K
?
U
'$
/
Procesor
de
AP DU
Raspuns &%
Entit
ati implicate n constructia/utilizarea unui
smartcard
Exista mai multe entitati implicate potential ntr-un sistem bazat pe smartcard.
1. Proprietarul cardului este persoana care poseda cardul n mod uzual; acesta
decide daca si cand sa-l foloseasca.
Proprietarul poate controla datele de pe card oferite de sistem, dar extrem de rar
are si controlul protocoalelor, softului sau hardului ncorporate n card.
2. Proprietarul datelor este componenta care detine controlul datelor aflate pe card.
In anumite cazuri, el coincide cu proprietarul cardului.
Pentru cardurile de plati, proprietarul datelor este cel emite platile cash; aceasta
diferentiere ntre cele doua componente deschide anumite oportunitati de atac.
3. Terminalul este componenta care asigura interactiunea smartcardului cu exteriorul.
Terminalul controleaza toate intrarile si iesirile spre si dinspre smartcard: tastatura
prin care datele sunt ncorporate n smartcard si monitorul pe care este vizualizat
smartcardul.
La un card telefonic, aceasta componenta este chiar aparatul telefonic. Pentru un
card de plati, terminalul este ATM-ul la care este facuta conexiunea.
4. Emit
atorul de card este componenta care emite smartcardul.
El controleaza sistemul de operare al smartcardului, precum si datele stocate initial.
Exemple: pentru un card telefonic, aceasta componenta este compania de telefoane.
Pentru un card de serviciu, emitatorul este institutia la care este angajat proprietarul
cardului.
In anumite cazuri, emitatorul doar emite cardul, dupa care dispare din sistem;
alteori, el ramane implicat n functionarea cardului.
In unele carduri multifunctionale, emitatorul de card nu are nici o legatura cu
aplicatiile care ruleaza pe smartcard; n altele, el are controlul tuturor aplicatiilor.
14
Din punct de vedere al securitatii este mai simplu de considerat ca emitatorul de

card, fabricantul si programatorul de software formeaza o singura componenta. In
realitate, acest lucru se ntampla foarte rar.
5. Fabricantul de card: este componenta care realizeaza smartcardul.
Evident, aceasta este o imagine simplificata; n realitate, fabricantul de card poate
detine sau nu facilitatile de fabricare ale cipului ncorporat.
De exemplu, exista functii subcontractate care folosesc componente externe sistemului (cum ar fi compilatoare V HDL); desi nu sunt n proprietatea fabricantului de
card, ele sunt introduse pe card.
6. Programatorul de software este componenta care realizeaza programele rezidente pe smartcard.
Evident, si aici problemele sunt mult simplificate: n realitate sunt mai multi programatori care scriu codul pentru compilatoare, programe utilitare, componente de
securitate etc.
4.7
Exemple de partajare a securit

atii sistemelor de
carduri
Sa trecem n revista cateva din cele mai utilizate sisteme de smartcard, privite din punct
de vedere al controlului efectuat de componentele sale.
Cardul de pl
ati (Digital Stored Value Card): Este un card folosit pentru nlocuirea
modului de plata cash. Exemplu: Both Mondex, VisaCash.
Aici comerciantul este proprietarul terminalului, iar cumparatorul este proprietarul
de card. Atat propietarul datelor cat si emitatorul de card sunt institutia financiara
(de obicei o banca) care sprijina sistemul.
Cardul digital (Digital Check Card): Este similar cardului de plati, cu diferenta
ca proprietarul cardului este acelasi cu proprietarul datelor.
Cartel
a telefonic
a Prepaid: Este un card de plati cu utilizare specificata. Proprietarul cardului este utilizatorul. Terminalul, datele si emitatorul cardului sunt
asigurate de o singura entitate: compania de telefoane.
Cartel
a telefonic
a: In acest sistem, smartcardul stocheaza doar un numar de cont
un pointer la o baza de date. Proprietarul cardului si al datelor este utilizatorul,
iar cel care emite cardul, detinand si terminalul, este compania de telefoane.
4.8. COMPONENTE CRIPTOGRAFICE
15
Card de acces (Access Token): In aceasta aplicatie, smartcardul stocheaza o cheie

care este utilizata ntr-un login sau protocol de autentificare. Pentru o institutie,
proprietarul cardului este angajatul, iar proprietarul datelor, al terminalului si
emitatorul de card este compania.
In cazul unui card de acces multifunctional, proprietarul cardului si al datelor poate
fi eventual una si aceeasi persoana, n timp ce terminalul este detinut de un organism
comercial, iar emitatorul de card de o institutie financiara.
Card de navigare Web (Web Browsing Card): Utilizatorul poate folosi cardul pe
propriul PC pentru a cumpara diverse produse oferite prin Internet.
Este o varianta a cardului de plati, cu diferenta ca cel care face cumparaturi detine
atat cardul cat si terminalul.
Card de certificare (Digital Credential Device): Aici smartcardul stocheaza certificate digitale sau alte credentiale necesare autentificarii fata de parteneri. Proprietarul cardului este si proprietarul datelor. Terminalul este detinut de catre
partener (ntr-o aplicatie in-store de exemplu), sau tot de proprietarul cardului (care
efectueaza cautarea pe WWW). Emitatorul cardului este unitatea de certificare
(CA) care emite credentialele, sau o companie care gestioneaza aceste certificate.
Cartel
a de stocare a cheilor (Key Storage Card): In aceasta aplicatie, utilizatorul
stocheaza diverse chei publice (eventual verificate) pe un smartcard, pentru a le
pastra ntr-un mediu mai sigur decat propriul PC.
El este proprietarul cardului, al datelor precum si al terminalului.
4.8
Componente criptografice
4.8.1
Exemple de componente criptografice integrate pe un smartcard
Smartcard-urile contin suficient de multe componente criptografice pe care se dezvolta

aplicatii si protocoale de securitate cunoscute.
Semnatura electronica:
Cele mai folosite protocoale de semnatura sunt bazate pe RSA; pe ele sunt implementate chei de 512, 768 sau 1024 biti. Timpul necesar unei semnaturi este de
obicei sub o secunda.
De cele mai multe ori fisierul EEP ROM care contine cheia privata este conceput
astfel ncat informatiile sensibile despre cheie sa nu paraseasca niciodata cip-ul. Nici
cititorul de carduri nu poate accesa acest fisier. Folosirea cheii private este protejata
16
de P IN -ul utilizatorului, astfel ncat posesia cardului nu implica si posibilitatea

semnarii digitale.
Unele carduri au implementat padding-ul P KCS#1 corespunzator lui RSA.
Desi cardurile au abilitatea de a genera perechi de chei RSA, acest proces poate
dura foarte mult. Timpii uzuali necesari pentru generearea unei perechi de chei
RSA de 1024 biti poate ajunge pana la 3 minute, ceea ce depaseste specificatiile
ISO pentru timpul afectat unei comunicatii; din acest motiv este necesara uneori
existenta unui hardware specializat sau a unui co-procesor dedicat.
De asemenea, calitatea perechii de chei nu este foarte mare. Lipsa puterii de procesare implica implementarea de generatori relativ slabi de numere pseudo-aleatoare.
Algoritmul de Semnatura Digitala (DSA) este implementat mai putin frecvent decat
RSA. Atunci cand este disponibil, el foloseste chei de numai 512 biti.
Algoritmi de criptare:
DES si 3DES sunt ntalnite frecvent n smartcard-urile performante. De obicei
exista si optiunea de a fi folositi n calculul unui M AC. Totusi, datorita faptului
ca interfata seriala a smartcard-ului are o latime mica de banda, criptarea cu un
sistem simetric a unei cantitati mari de informatie este foarte lenta.
Alte aplicatii:
Functia de portofel electronic este prezenta n multe aplicatii; ea se bazeaza de
obicei pe criptari cu cheie simetrica, cum ar fi DES sau 3DES.
Algoritmii de dispersie cuprind de obicei SHA 1 si M D5; dar din nou
latimea scazuta a benzii seriale de comunicare mpiedica folosirea efectiva a
acestor functii pentru dispersia unui volum mare de informatii.
Generatoarele de numere pseudo-aleatoare (RN G) difera destul de mult de la
un tip de card la altul. Unii fabricanti implementeaza un pseudo-RN G n care
fiecare card are propria sa initializare.
In acest caz, numerele aleatoare cicleaza n functie de algoritm si initializare.
Alte carduri au un RN G bazat pe hardware, care foloseste unele aspecte fizice
ale cipului de siliciu.
Daca un card va fi folosit ntr-un context criptografic sensibil, este recomandat
sa se cunoasca cat mai multe detalii referitoare la RN G.
De asemenea ca si n cazul oricarei tehnologii exista aspecte legale care trebuie luate
n considerare n lucrul cu smartcard-urile. In mod normal, un smartcard are capacitatea
de a rula algoritmi cu licenta (de exemplu sistemul de criptare RSA). Taxele de licenta
se regasesc de cele mai multe ori n pretul smartcard-ului.
4.8. COMPONENTE CRIPTOGRAFICE
4.8.2
17
Aspecte legate de securitate
Unul din conceptele de baza pe care se bazeaza arhitectura securitatii smartcard-urilor

este acela ca extragerea de informatii despre sistemul de operare si cel de fisiere sunt
operatii extrem de dificile daca aceste procese nu sunt controlate de cip mpreuna cu
sistemul de operare al card-ului.
Pentru a realiza acest lucru, n smartcard-urile actuale sunt prezente diferite metode
de monitorizare a securitatii hardware.
O masura de siguranta (ireversibila) dezactiveaza orice cod de test din EEP ROM .
Ea se poate folosi o singura data n perioada de viata a unui smartcard.
Pentru a evita clonarea cardurilor, o secventa nealterabila specifica este parcursa
obligatoriu la orice utilizare a memoriei ROM .
Cand detecteaza fluctuatii de voltaj, temperatura sau frecventa de ceas, cardurile
sunt concepute sa se reseteze automat ntr-o stare initiala.
Operatia de citire din exterior a memoriei ROM este de obicei dezactivata.
Totusi, deoarece fiecare dezvoltator de carduri are propria sa schema de masuri, este bine
sa se cerceteze rezultatele unor teste provenite de la mai multe laboratoare independente.
Protocoalele de comunicare ale smartcard-urilor la nivel de comanda pot avea de
asemenea inclus un protocol de securitate. Acesta este bazat de obicei pe tehnologii
cu cheie simetrica si ofera smartcard-ului posibilitatea sa autentifice terminalul cu care
intra n contact direct.
Totusi, sistemele de criptare si algoritmii utilizati pentru aceste protocoale sunt n
marea lor majoritate specifice unor anumite aplicatii si unor anumite terminale.
Smartcard-urile au abilitatea de a configura mai multe P IN -uri cu scopuri diferite.
Aplicatiile pot configura un P IN pentru supervizor, care sa poata debloca P IN -ul unui
utilizator dupa un numar de ncercari esuate sau sa reinitializeze cardul.
Alte P IN -uri pot fi configurate pentru a controla accesul la fisiere sensibile sau functii
ale portofelului electronic.
4.8.3
Codul P IN
Cea mai simpla metoda de identificare a unui utilizator este de a-i atasa un numar secret,
numit Personal Identification Number3 (P IN ). Un P IN este un numar de 4 cifre zecimale4 El este introdus folosind un terminal sau o tastatura de calculator si directionat
3
Unele surse denumesc acest num

ar CHV - Cardholder Verification.
Conform standardului ISO 9546 1, codul P IN trebuie sa contina ntre 4 si 12 caractere alfanumerice (pentru a minimiza efectul unui atac prin forta bruta), lucru imposibil practic deoarece terminalele
de card au doar taste numerice, iar codul trebuie sa fie usor de memorat.
4
18
spre smartcard. Cardul compara valoarea primita cu cea stocata n interior si reporteaza
spre terminal rezultatul compararii.
Un P IN poate fi de doua feluri: static sau modificabil.
Un P IN static nu poate fi schimbat de utilizator; deci el trebuie memorat. Daca
devine public, utilizatorul trebuie sa distruga cardul si sa obtina un card nou, cu
alt P IN .
Un P IN modificabil poate fi modificat la solicitarea utilizatorului sau schimbat
de acesta cu un numar mai usor de memorat. Acest lucru comporta un anumit
risc, deoarece utilizatorul va prefera un P IN de forma 0 12340 , sau legat de date
personale (data nasterii, casatoriei etc). Smartcardul nu poate controla alegerea
numerelor triviale, deoarece nu are suficienta memorie pentru a construi o tabela
cu ele. In schimb un terminal poate interzice introducerea unor numere de forma
0
12340 , 0 99990 , 0 11110 , 0 00000 etc.
Exista si chei personale de deblocare (P U K), numite si super-P IN . Ele au mai mult
de 4 cifre (6 cifre de obicei) si sunt folosite pentru resetarea counterului unui smartcard
atunci numarul de ncercari a fost depasit. Odata cu utilizarea unui P U K se va defini un
nou P IN , deoarece un numar mare de ncercari cu P IN -uri gresite este un indiciu n
varianta optimista ca utilizatorul a uitat propriul P IN .
Alte aplicatii folosesc P IN -uri de transport. Smartcardul este personalizat cu un
P IN generat aleator, pe care proprietarul de card l primeste ntr-o scrisoare trimisa prin
posta. In momentul folosirii pentru prima oara a cardului, el nlocuieste acest P IN cu
unul propriu.
O metoda similara este P IN -zero: cardul este prencarcat cu un P IN banal, cum ar fi
0
00000 , valoare care este nlocuita obligatoriu la prima utilizare a cardului.
4.9
Criptanaliza smartcardurilor
Nu vom discuta aici metodele de atac legate de softul introdus pe smartcard (atacurile
asupra RSA, DES sau asupra SHA1 etc.). Acestea au fost studiate odata cu prezentarea sistemelor respective. Vom trece n revista o serie de atacuri specifice structurii smartcardului.
4.9.1
Tipuri de atac contra smartcardurilor
Definitia 4.1. Un atac este o ncercare a uneia sau mai multor p

arti implicate ntr-o
tranzactie bazata pe smartcard de a trisa.
Sunt doua tipuri de atac:
4.9. CRIPTANALIZA SMARTCARDURILOR
19
Atacuri venite din partea componentelor sistemului de smartcard. De exemplu:

ncercari ale proprietarului de card de a nsela terminalul; sau ale fabricantului de
card de a nsela proprietarul de card.
Atacuri venite dinafara sistemului. Sunt generate de obicei de persoane care fura
un card de la proprietar sau care nlocuiesc softul/hardul terminalului.
Datorita numarului mare de parti implicate ntr-un sistem de smartcard, apar mai multe
clase de atacuri; majoritatea lor sunt specifice smartcardurilor (nu apar n sistemele de
calcul obisnuite).
Atacuri ale terminalului contra proprietarului de card sau de date
Este un atac realizat de obicei cu ATM-uri contrafacute. Cand un card este introdus
ntr-un terminal, proprietarul sau are ncredere ca acesta va lucra corect.
Astfel, daca proprietarul cardului cere sa se scada (pentru o plata) 100 lei, mesajul trimis
mai departe de terminal consta n scoaterea din contul proprietarului a sumei de 100 lei,
si nu 1000 lei (de exemplu). Sau, daca un card trimite spre proprietar un mesaj de tipul
Contul contine 100 lei, terminalul trebuie sa transmita corect acest mesaj pe ecran.
In contextul unui singur terminal, proprietarul cardului nu poate detecta acest tip de
atac.
Mecanismele de eliminare a acestui atac se bazeaza general pe faptul ca pentru un
interval scurt de timp, doar terminalul are acces la card. De aceea, multe softuri de pe
card limiteaza suma ce poate fi retrasa la o cerere, sau ntr-o perioada de timp. Astfel,
n general nu se poate efectua retragerea de pe card a unei sume mai mari de 2.000 lei n
24 ore. De remarcat ca aceste mecanisme nu semnaleaza nici o anomalie a terminalului;
ncearca doar limitarea unor eventuale pagube.
Exista si mecanisme de prevenire mpotriva acestui tip de atac, care nu au nici o legatura
cu schimbul de informatii card - terminal; sunt sisteme centrale care monitorizeaza toate
cardurile si terminalele si semnaleaza orice comportament care provoaca suspiciuni.
Atacuri ale proprietarului de card contra terminalului
Aceste atacuri folosesc carduri false sau modificate, bazate pe softuri pirat, cu intentia de
a pacali protocolul de autentificare card - terminal.
De obicei un protocol bun reduce la minimum acest tip de atac. In plus, pot fi utilizate pentru autentificare anumite aspecte fizice ale cardului, greu de imitat (de exemplu
hologramele utilizate de sistemele Visa si Mastercard) si care sunt controlate separat de
terminal.
De remarcat ca o semnatura digitala controlata de software nu este sigura, deoarece un
card fals poate contraface (adesea) o semnatura, iar terminalul nu are nici o posibilitate
de a inspecta interiorul cardului.
20
Apararea contra acestui tip de atac consta n definirea unor functii care sa nu permita
accesul proprietarului de card la datele din interiorul cardului.
Atacuri ale proprietarului de card contra proprietarului de date
In multe smartcarduri (mai ales cele folosite n sisteme comerciale), datele stocate pe card
trebuie protejate fata de proprietarul de card. De obicei acestuia nu i este permis sa aiba
acces la datele respective.
De exemplu, o cartela de acces ntr-o cladire poate contine o valoare secreta; cunoasterea ei va permite proprietarului sa construiasca un acces multiplu (pe mai multe zone
ale cladirii). Sau cunoasterea unei chei secrete de pe un card de comert electronic poate
permite proprietarului sa efectueze tranzactii ilegale.
In alte cazuri, se permite cunoasterea valorii de catre proprietarul cardului, dar nu si
modificarea ei. Este cazul unui card de debit: daca proprietarul poate modifica valoarea,
el poate scoate bani pe care nu i are n cont.
Aceste atacuri au doua proprietati majore:
Cardul actioneaza ca un perimetru de securitate, limitand strict accesul proprietarului la datele aflate n interiorul cardului.
Atacatorul are acces la card n conditii stabilite de el: poate sa-l supuna oricaror
verificari si experimente doreste, pentru a avea acces la informatiile stocate. In
particular, poate distruge cardul, pentru a vedea cum este construit.
Exista multe tipuri reusite de atac contra datelor stocate pe card; cea mai mare parte a
lotr vor fi prezentate n sectiunile urmatoare.
Multe astfel de atacuri s-au materializat efectiv contra cardurilor de acces pay-TV si
a cartelelor de telefon. De asemenea, sunt unele ncercari reusite de sustrageri de date
din carduri folosite n comertul electronic.
Atacuri ale proprietarului de card contra emit
atorului de card
Sunt cunoscute mai multe atacuri de acest fel; toate sunt de fapt atacuri care au ca tinta integritatea si autenticitatea informatiilor stocate pe card. Multe din aceste informatii sunt
cunoscute de proprietarul de card; acesta doreste sa le modifice fara acordul emitatorului
de card (si implicit al fabricantului de card).
De exemplu, la o cartela de telefon prepaid, proprietarul (nu neaparat cel legal) poate
ncerca sa modifice contul, cu scopul de a putea vorbi mai mult cu aceeasi suma. In
acest caz, securitatea poate fi asigurata adaugand un mecanism de tip provocare/raspuns
(utilizat frecvent la protocoalele de comert electronic) sau un lant de functii de dispersie
inverse.
Daca emitatorul de card prefera sa puna pe card biti care sa permita utilizarea sistemului, evident ca principalul atac va fi construit pentru a-i afla. In general acesti biti
21
autentifica contul, sau formeaza un sistem bazat pe o cheie stocata pe card, cheie care nu
poate fi extrasa fara a distruge fizic cardul.
Evident, toate aceste precautii se bazeaza pe presupunerea (discutabila) ca perimetrul
de securitate al cardului este suficient de sigur.
Atacuri ale proprietarului de card contra programatorului de software
Precautiile ce se pot lua n aceasta situatie folosesc diverse protocoale preliminare de
recunoastere, bazate pe transformari neinversabile, pentru a avea siguranta ca nu este
posibil accesul la softul de pe card. Ele folosesc prezumtia ca nu exista nici o legatura
ntre proprietarul cardului si proprietarul softului.
Totusi, n acest caz, intrusii dovedesc o abilitate deosebita n constructia unor structuri
hard adecvate lansarii unor astfel de atacuri, structuri oferite adesea gratis pe Internet.
Atacuri ale proprietarului de terminale contra emit
atorului de carduri
Intr-un sistem nchis la exterior (cum este cel al cartelelor de telefon prepaid), proprietarul
de terminale este de asemenea si emitatorul de carduri (compania de telefoane ndeplineste
ambele functii).
La sistemele deschise (cand cele doua entitati sunt distincte), terminalul controleaza
toate comunicatiile ntre card si emitatorul de carduri (aflat n general la capatul sistemului). Deci el poate totdeauna sa falsifice mesajele care nu au legatura cu continutul
smartcardului; de exemplu sa refuze nregistrarea tranzactiei, sa lanseze comenzi false etc.
De asemenea, terminalul poate omite intentionat completarea unor pasi dintr-o tranzactie,
facilitand astfel o frauda sau creind dificultati de management emitatorului de card.
Astfel, daca nu modifica suma de pe card (scazand suma cheltuita), terminalul poate
genera o paguba; sau daca completeaza o tranzactie dar nu ofera serviciul respectiv (de
exemplu, scoate banii, dar nu ofera marfa) creaza prejudicii atat emitatorului cat si
proprietarului de card.
Aceste atacuri nu sunt legate de natura sistemului de utilizare a smartcardurilor; sunt
atacuri contra relatiei dintre proprietarul de terminale si emitatorul de carduri. De obicei
ele sunt prevenite printr-o monitorizare permanenta la ambele capete a protocoalelor de
comunicare.
Atacuri ale emit
atorului de carduri contra proprietarului de card
Cele mai multe sisteme de smartcard se bazeaza pe supozitia ca emitatorul de carduri
slujeste interesele proprietarilor de card. Acest lucru nu este totdeauna adevarat si un
emitator de carduri are posibilitatea de a lansa mai multe tipuri de atac mpotriva proprietarilor de carduri.
Majoritatea lor ncalca sub o forma oarecare conceptul de confidentialitate (privacy).
Astfel smartcardurile care efectueaza plati trebuie sa asigure mentinerea proprietatilor de
22
anonimitate si fara legaturi (unlinkability)5 a tranzactiilor. Acestea pot fi compromise de

emitatorul de carduri.
Este posibil ca un sistem sa fie oferit cu asigurarea ca asigura mai multa confidentialitate
decat are de fapt; proprietarul de card nu poate verifica daca datele pe care le are nu sunt
alterate n interiorul cardului. Aceste posibile atacuri (desi unele sunt doar slabiciuni
ale sistemului smartcard) se pot efectua fara ca proprietarul de card sa fie constient de
existenta lor, sau eventual fara sa fie avertizat asupra lor.
Astfel, schimbarea unui sistem efectuata de emitatorul de carduri este obligatorie pentru proprietarul de card si acesta nu este consultat sau constient de eventualele falii de
securitate pe care le deschide modificarea.
Majoritatea acestor atacuri pot fi realizate de emitatorul de carduri doar n colaborare
cu fabricantul de carduri si cu programatorul de software. De aceea este bine ca din
punct de vedere al proprietarului de carduri aceste entitati sa fie complet distincte.
Atacuri ale fabricantului de carduri contra proprietarului de date
Anumite designuri de fabricare pot avea efecte negative destul de importante privind
securitatea datelor de pe card.
Un sistem de operare care permite mai multor utilizatori sa ruleze programe pe acelasi
smartcard ridica numeroase probleme de securitate.
Prima problema este versiunea sistemului de operare si deci si a programelor care se
bazeaza pe el. Optiunea de a construi sisteme de operare noi, specifice smartcardurilor,
nu au convins din punct de vedere al securitatii.
Dar, chiar si cu un sistem de operare (teoretic) sigur, securitatea interfetei cu utilizatorul constituie permanent un risc de securitate.
1. Cum poate sti utilizatorul (sau designerul de card) ca programul ruleaza atunci cand
cardul este inserat ntr-un terminal ?
2. Cum poate fi el sigur ca programul interactioneaza cu acel terminal si nu cu un alt
program ?
3. Cum poate un program, care ajunge la concluzia ca este compromis, sa termine n
siguranta si sa semnaleze utilizatorului ca trebuie nlocuit ?
4. Ce atacuri devin posibile atunci cand un card anunta ca nu mai lucreaza deoarece
nu mai este sigur ? Poate sa asigure un astfel de card odata ce acest mesaj este
trimis ca memoria sa este ntr-adevar distrusa si nu este sub controlul unui intrus?
Mai putin evidente sunt implementari intentionate de generatori slabi de numere
pseudo-aleatoare, sau alte module criptografice de calitate inferioara privind securitatea.
5
A se vedea [1], capitolul dedicat sistemelor electronice de plata.
23
Fabricantul de carduri are numeroase posibilitati de a-si asigura baza unor atacuri
ulterioare asupra informatiilor de pe card. Nici un fabricant de carduri nu a asigurat pana
acum un sistem de operare sigur, fara vulnerabilitati (mai mult sau mai putin evidente).
In plus, prin implementarea diverselor protocoale, el poate aranja unele canale subliminale
care sa permita aflarea cheilor sau a altor date de pe card.
Mai mult, este posibil ca pentru o aplicatie pe smartcard sa existe o alta aplicatie care
sa ruleze simultan pe acelasi smartcard. S-a demonstrat ca daca avem un protocol sigur,
se poate crea alt protocol tot sigur care sa-l sparga pe primul, daca ambele ruleaza
pe acelasi echipament si folosesc aceleasi chei.
4.9.2
Tehnici invazive de atac
Definitia 4.2. Un atac asupra unui smartcard este invaziv dac

a implic
a o modificare
vizibil
a a dispozitivului.
De obicei tehnicile invazive presupun distrugerea totala a cipului smartcard-ului.
In plus, n timp ce atacurile non-invazive pot fi efectuate prin sustragerea pentru o
scurta perioada de timp a unui dispozitiv smartcard, atacurile invazive pot necesita ore de
munca specializata n laboratoare, fiind accesibile doar atacatorilor foarte experimentati si
cu suport financiar puternic. Exista, astfel, o probabilitate neglijabila ca un atac invaziv
sa se realizeze fara cunostinta utilizatorului (care va realiza mai devreme sau mai tarziu
ca nu mai poseda cardul), ceea ce face ca astfel de atacuri mpotriva dispozitivelor de
semnatura si autentificare sa nu fie viabile (certificatele pot fi revocate cand s-a descoperit
pierderea). Daca nsa smartcard-ul este proiectat sa stocheze informatii foarte valoroase,
aceste atacuri constituie o problema importanta.
Toate atacurile invazive ncep prin scoaterea cip-ului din suportul de plastic. Este
foarte simplu si nu necesita unelte speciale. Eventual se fac demersuri pentru ndepartarea
stratului de pasivizare (rasina epoxidica) care nfasoara cip-ul. Acest pas constituie principala diferenta ntre atacurile invazive si cele semi-invazive.
Daca cipul este proiectat sa efectueze functii speciale, exista o anumita sansa ca
cei ce l-au proiectat sa nu fi tinut cont de principiul lui Kerckhoff6 . Securitatea
prin obscuritate nu a functionat niciodata, inclusiv n cazul smartcard-urilor; astfel,
componentele cipului pot fi analizate iar proiectul initial poate fi descoperit (reverse
engineering).
Microsondarea reprezinta o metoda de atac strans legata de reverse engineeringul cip-ului, care presupune interactiunea directa cu componentele acestuia. Prin
aceasta tehnica se ncalca prezumtia conform careia smartcard-ul poate fi accesat
6
Reamintim, acest principiu spune c

a puterea unui sistem de criptare si prin extensie a unui
dispozitiv de criptare, trebuie s
a se bazeze numai pe cheie, nu pe structura si algoritmii sistemului. A se
vedea si [1], pag 11.
24
numai prin intermediul unui cititor de carduri. De exemplu, cu doua microsonde,

orice bit din EEP ROM poate fi setat sau resetat (aceasta face banala, de exemplu,
extragerea unei chei a carei paritate este o preconditie pentru algoritm); similar, cu
un microscop si un laser-cutter, orice bit din ROM poate fi modificat.
Un atac construit de Biham si Shamir mpotriva unei implementari hardware a DES

a fost prezentat n 1997; el a folosit un laser-cutter pentru a distruge o poarta din
implementarea hardware a unui bloc de criptare cunoscut, anume ultimul bit din
registrul ce duce iesirea unei runde n intrarea rundei urmatoare. Blocarea bit-ului
cel mai nesemnificativ are ca efect blocarea pe 0 a ultimului bit ntors de functia de
runda. Prin compararea celor mai nesemnificativi 6 biti din jumatatea stanga si cea
dreapta, pot fi descoperiti cativa biti din cheie. Folosind 10 texte criptate de un astfel
de cip si cu o tehnica bazata pe criptanaliza diferentiala, s-au obtinut informatii
despre cheia de runda a rundelor precedente. Se pot afla astfel destule informatii
despre cheie pentru a facilita cautarea. Acesta este de fapt primul atac eficient
mpotriva sistemelor de criptare bazate pe retele Feistel, n cazul cand nu exista
nici o informatie despre textul criptat. Este cazul multor aplicatii smartcard n care
cardul foloseste tranzactii succesive pentru a raporta starea interna emitentului.
Exista o masura simpla de protectie mpotriva unui astfel de atac: un cip modificat
n felul acesta are proprietatea ca functiile de criptare si decriptare nu mai sunt
inverse. Asa ca se poate atasa sistemului o auto-testare simpla, care foloseste o
intrare arbitrara, cripteaza si decripteaza folosind o cheie arbitrara, iar apoi compara
rezultatul cu blocul original.
Un alt atac tipic presupune deconectarea aproape n ntregime a Unitatii Centrale de

Procesare (CP U ) de magistrala de date, lasand conectate numai EEP ROM -ul si o
componenta a CP U care sa asigure accesul la citire. Pentru a citi toate celulele de
memorie fara ajutorul software-ului card-ului, trebuie folosita o componenta a CP U ului drept contor de adrese pentru a accesa toate celulele de memorie. Contorul de
program este implicit incrementat automat n timpul fiecarui ciclu de instructiuni
si folosit la citirea urmatoarei adrese, ceea ce l face foarte potrivit pentru rolul de
generator de secvente de adrese. Totusi, procesorul trebuie mpiedicat sa execute
instructiuni cum ar fi jump, call sau return, care ar deturna contorul de program
de la citirea secventiala. Mici modificari ale decodorului de instructiuni sau ale
circuitelor contorului de program (care se pot realiza prin deschiderea unui anumit
conector metalic) pot avea efectul dorit.
25

?
load
Semnal CLK
+1
Contor
program
Decodor
instructiuni
load
6 6
6
mpamantare
magistrala de date (8 biti)
magistrala de adresare (16 biti)
6
out
Microsonda

EEP ROM
Odata ce aceste masuri au fost luate, Oscar are nevoie de un singur ac pentru microsondare, sau o sonda electro-optica pentru a citi ntregul continut al EEP ROM ului. Aceasta abordare face programul mult mai usor de analizat decat n cazul
atacurilor pasive, care produc doar o urmarire a executiei; de asemenea nlatura
dificultatile mecanice de a avea simultan mai multe sonde inserate pe circuite (cu o
latime de un micron).
Pentru unele configuratii ale cipului, acest atac nu functioneaza. De exemplu, cardurile bancare citesc date critice din memorie doar dupa ce se asigura ca se afla
ntr-o tranzactie cu un cititor autorizat. Se pot adauga contoare auxiliare care sa
reseteze procesorul daca nu se executa instructiuni jump, call sau return ntr-un
anumit interval de timp.
Totusi astfel de dispozitive pot fi dezactivate prin modificari minore ale circuitelor,
asa ca de obicei protectia este incorporata n structura cip-ului; de exemplu prin
folosirea unui contor de program care sa nu poata acoperi ntregul spatiu de adrese.
Un contor de program pe 16 biti poate fi nlocuit usor cu o combinatie dintr-un
contor O de deplasare pe 7 biti si un registru de segment R pe 16 biti, astfel ncat
adresa accesata sa fie S +O. Contorul de deplasare reseteaza procesorul daca ajunge
la valoarea maxima. Procesorului i va fi astfel imposibil sa execute mai mult de
127 octeti de cod-masina fara jump, si acest lucru nu poate fi schimbat de catre
un atacator prin mijloace simple. Un post-procesor de cod - masina poate fi folosit
ulterior de programator pentru a insera jump-uri la urmatoarea adresa atunci cand
ramurile neconditionate depasesc lungimea de 127 octeti.
Daca nu mai poate folosi de contorul de program, Oscar poate ncerca sa creasca
numarul de iteratii din cicluri software care citesc siruri de octeti din memorie, pentru a avea acces la toti octetii. Acest deziderat se poate obtine folosind o microsonda
care sa produca o perturbatie direct pe magistrala de date. Programatorii care vor
sa utilizeze contoare pe 16 biti trebuie sa tina cont de acest lucru. Ca o prima linie
de aparare mpotriva acestui tip de atac, cele mai multe sisteme de operare pentru
smartcard-uri cripteaza datele importante de pe EEP ROM ; astfel este dificil pentru un intrus sa obtina text clar direct din EEP ROM .
26
Aceasta nu este de fapt o solutie, decat daca criptarea depinde de un secret (cum
ar fi P IN -ul introdus de utilizator).
Proiectantii de dispozitive bazate pe EEP ROM mai au de nfruntat urmatoarea
problema: stergerea unei celule de memorie necesita un voltaj relativ ridicat. Daca
Oscar poate preveni acest lucru, atunci informatia va fi imposibil de sters. Primele
smartcard-uri primeau voltajul necesar programarii printr-o conexiune dedicata cu
gazda, folosind contactul C6. Acest mod de alimentare extern a dus la atacuri
mpotriva sistemelor de televiziune cu plata, n care cardurile erau initial activate
pentru toate canalele, iar acele canale pe care abonatul nu le platea erau dezactivate
prin semnale difuzate. Acoperind contactul cardurilor cu banda izolanta abonatii
puteau preveni ca aceste semnale sa reprogrameze cardul. Ei puteau apoi sa-si
anuleze abonamentul fara ca prestatorul sa-i poata anula serviciul.
Cardurile folosite astazi sunt capabile sa genereze cei 12 volti necesari functionarii
din tensiunea de 5 volti obtinuta de la cititor. Aceasta ridica sensibil costul unui atac
dar nu-l face imposibil: condensatorii mari necesari transformarii pot fi identificati
usor la microscop si distrusi folosind laser, ultrasunete sau fascicule concentrate de
ioni.
Acest tip de atac nu este caracteristic cartelelor telefonice sau TV. Un cip modificat
n acest fel poate fi investigat fara riscul de a sterge din greseala EEP ROM -ul, sau
din cauza unei functii de protectie incorporate.
4.9.3
Tehnici non-invazive de atac
Un atac non-invaziv asupra unui dispozitiv smartcard este oarecum mai limitat, dar
prezinta un pericol major: din moment ce nu face nici o modificare asupra smartcardului, este foarte greu de descoperit. De exemplu, daca s-ar gasi cheia privata a unui
dispozitiv de semnatura fara ca Alice sa observe, se pot falsifica documente n numele ei
mult timp nainte de a se descoperi infractiunea.
Unele atacuri non-invazive pot decurge ntr-un timp scurt si folosind resurse hardware uzuale (eventual modificate putin). Dar aceste tehnici nfrunta limitari puternice:
deoarece ele trebuie sa aiba loc n timp ce cardul opereaza n conditii normale, orice manipulare va avea ca obiect conditiile de mediu sau octetii care intra si ies din smartcard.
In general, n cazul atacurilor non-invazive, este necesar ca Oscar sa cunoasca structura
software si hardware a smartcard-ului.
Atacul prin cronometrare:
In acest atac descris de Paul Kocher n [3] diferite secvente de octeti sunt trimise
card-ului pentru a fi semnate cu cheia privata. Informatii cum ar fi timpul necesar
efectuarii unei operatii si numarul de 0 si 1 din sirul de intrare sunt folosite ulterior
de Oscar pentru a obtine cheia privata.
27
Fiind un atac cu text clar ales, este necesar ca Oscar sa cunoasca P IN -ul cardului sau sa-l pacaleasca pe utilizator sa semneze sirurile de biti pe care acesta i le
furnizeaza.
Exista masuri de aparare la nivel hard mpotriva acestui tip de atac dar nu toti
producatorii de smartcard-uri le implementeaza.
Unele variante de atac prin cronometrare pot fi executate via software. De exemplu,
ar putea fi folosita o aplicatie cal troian, nfiltrata printr-un procedeu oarecare
pe o statie de lucru a lui Alice. Calul troian asteapta pana cand Alice introduce
un P IN valid dintr-o aplicatie de ncredere, activand astfel folosirea cheii private;
apoi cere smartcard-ului sa semneze digital niste date (de exemplu un contract).
Operatia se ncheie dupa acest schimb de mesaje, dar utilizatorul nu stie ca cheia
sa privata a fost folosita fara consimtamantul sau.
Masura de protectie mpotriva acestui tip de atac este folosirea arhitecturii single
- access device driver. Pe acest tip de arhitectura, sistemul de operare se asigura
ca, la orice moment, doar o singura aplicatie poate avea acces la un dispozitiv
(smartcardul n cazul nostru).
Acest lucru mpiedica atacul dar va afecta folosirea smartcard-ului, deoarece limiteaza accesul la serviciile smartcardului.
O alta cale de a preveni astfel de atacuri este folosirea unui smartcard care solicita
introducerea P IN -ului pentru fiecare utilizare a cheii private. In acest model, Alice
trebuie sa introduca P IN -ul de fiecare data cand cheia privata trebuie folosita, si
deci calul troian nu va avea acces automat la cheie. Acest lucru este nsa rareori
convenabil pentru utilizatorii comozi.
Atacuri prin analiza consumului de energie:
Se bazeaza pe masurarea fluctuatiilor n curentul consumat de dispozitiv. Diferite
instructiuni provoaca nivele diferite de activitate n decodorul de instructiuni si
unitatile de calcul aritmetic; ele pot fi adesea distinse clar, iar pe baza lor pot fi
reconstituite parti din algoritmi.
Aceste tehnici intra in categoria monitorizarii informatiei si constituie o amenintare
reala datorita faptului ca pe piata exista un numar mare de produse vulnerabile.
Atacurile sunt usor de implementat, pot fi automatizate, au un cost scazut si sunt
non-invazive.
Analiza simpla a consumului de curent (Supply Power Analysis SP A) presupune
observarea directa a consumului de energie al sistemului pentru obtinerea de informatii despre secventa de instructiuni executata. Daca Oscar are acces doar la o
singura tranzactie, poate fi decelat un numar limitat de indicii.
Atacatorii cu acces la tranzactii multiple si care poseda informatii despre mecanismele interne specifice arhitecturii cip-ului folosit, pot fi periculosi. Kocher arata
28
cum poate fi spart sistemul de criptare DES n cazul unei implementari hardware
slabe, dar si cum poate fi evitat acest atac daca sunt ndeplinite cateva conditii,
cum ar fi de exemplu nelasarea bitilor din cheie sa fie folositi n alegerea dintre doua
ramuri ale unui jump.
Analiza diferentiala a consumului (Differential Power Analysis - DP A) se bazeaza
pe faptul ca memorarea unui bit 1 ntr-un flip - flop necesita de obicei mai multa
energie decat memorarea unui bit 0. De asemenea, schimbarea de stare cauzeaza un
consum sporit de energie. In plus, fata de variatiile la scara mare datorate secventei
de instructiuni, exista efecte corelate cu valorile datelor manipulate. Aceste valori
tind sa fie mai mici si sunt uneori mascate de erori de masurare si alte interferente,
dar exista tehnici pentru rezolvarea acestor probleme.
Diferite instructiuni produc nivele variate de activitate n decodorul de instructiuni
si n unitatile aritmetice; adesea ele pot fi diferentiate clar, si pe baza lor pot fi
reconstruite parti din algoritm. Componentele procesorului si schimba valorile temporare stocate n momente diferite relativ la intervalul de oscilatie al ceasului si pot
fi separate prin masuratori de nalta frecventa.
Algoritmii cu cheie publica pot fi analizati folosind DP A prin corelarea valorilor
candidat pentru calculele intermediare cu masuratorile consumului de energie ([4]).
Astfel, pentru operatiile de exponentiere modulara, este posibil sa se testeze biti
ghiciti prin verificarea daca valorile intermediare prezise sunt corelate cu calculele
reale.
Prin aceasta metoda este posibil un atac reverse engineering pentru un protocol sau un algoritm necunoscut. In general, semnalele care se scurg n timpul unei
operatii asimetrice tind sa fie mult mai puternice decat acelea provenite de la algoritmii simetrici de exemplu, din cauza complexitatii computationale relativ ridicate
a operatiilor de multiplicare.
De aceea implementarea masurilor de aparare mpotriva SP A si DP A poate fi dificila.
DP A poate fi folosita pentru a sparge implementari ale aproximativ tuturor algoritmilor de criptare. De exemplu, o cheie secreta T wof ish de 128 biti (lungime
considerata sigura) a fost recuperata dintr-un smartcard dupa ce s-au monitorizat
100 criptari independente. In acest caz se poate observa ca DP A descopera 1 2
biti de informatie per criptare.
Singura solutie de ncredere presupune proiectarea de criptosisteme avand o imagine
clara a hardware-ului aflat la baza.
Exista tehnici de prevenire a DP A si a atacurilor nrudite. Ele se pot mparti n
trei categorii:
Se poate reduce dimensiunea semnalului folosind cai de executie constanta a
29
codului, alegand operatii care permit scurgerea a cat mai putina informatie
sau adaugand porti suplimentare care sa compenseze consumul.
Din nefericire semnalul nu se poate reduce la zero, iar un atacator cu un numar
(teoretic) infinit de mostre va fi capabil sa foloseasca cu succes un atac bazat
pe DP A.
Se pot introduce interferente n masurarea consumului de energie; ca si n cazul
precedent, un numar foarte mare de mostre va ajuta analiza statistica.
Folosirea procedurilor neliniare de actualizare a cheii. De exemplu, aplicarea
functiei SHA 1 unei chei de 160 biti ar trebui sa ascunda efectiv toate
informatiile partiale pe care un atacator le-a putut afla despre cheie. Similar,
pot fi folosite modificari ad-hoc n procesele de utilizare a exponentilor si de
modificare a modulelor n cadrul sistemelor cu cheie publica (pentru a mpiedica
atacatorii sa adune date n timpul unui numar mare de operatii). De asemenea
se pot utiliza contori ai folosirii cheilor, pentru a preveni obtinerea unui numar
mare de mostre criptate.
Un atac similar cu DP A este analiza electromagnetica (EM A ElectroMagnetic
Analysis). Atacul consta n masurarea campului radiat de procesor si corelarea
rezultatelor cu activitatea procesorului respectiv.
Un astfel de atac poate obtine cel putin acelasi rezultat ca cel prin analiza consumului de energie.
Atacuri prin generarea de erori:
Atacurile prin generare de erori se bazeaza pe exercitarea de presiuni asupra procesorului cardului, pentru a-l forta sa execute operatii ilegale sau sa dea rezultate
gresite.
Exista o mare varietate de forme pe care le pot lua astfel de atacuri.
O modalitate este aceea de a modifica tensiunea de alimentare si semnalul ceasului. Subtensionarea si supratensionarea pot fi folosite pentru a dezactiva circuitele
de protectie sau pentru a forta procesoarele sa efectueze operatii gresite. In alte
conditii, unii parametri fizici (cum ar fi temperatura) sunt modificati pentru a obtine
acces la informatii sensibile de pe smartcard.
Un alt atac fizic posibil presupune o fluctuatie intensa a unor parametri fizici, exact
n momentul n care se efectueaza verificarea P IN -ului. Astfel, functii sensibile ale
cardului pot fi folosite chiar daca P IN -ul este necunoscut.
Desi nu se poate descrie exact cum este posibil ca o perturbare sa cauzeze executarea
de catre procesor a unor instructiuni gresite, perturbarea se poate afla relativ usor
printr-o cautare sistematica.
Exemplul 4.3. O subrutina des nt
alnit
a n procesoarele de securitate este un ciclu
care scrie continutul unei zone limitate de memorie c
atre un port serial:
30
1
2
3
4
5
6
7
8
b = answer_address
a = answer_length
if (a == 0) goto 8
transmit(*b)
b = b + 1
a = a - 1
goto 3
Se poate cauta o perturbare care s

a incrementeze normal contorul de program, dar
care sa transforme n altceva saltul conditionat de la linia 3 ori decrementarea variabilei de la linia 6.
A g
asi acea perturbare nseamn
a a activa cardul ntr-un mod repetabil. Toate semnalele trimise catre card trebuie s
a ajung
a exact la acelasi interval de timp dupa
reset, pentru fiecare runda de testare.
Pentru fiecare ciclu de ceas pot fi testate mai multe perturb
ari, p
an
a c
and una din
ele are ca efect transmiterea catre portul serial a unui octet suplimentar. Repet
and
acea perturbare, se obtine o citire a memoriei r
amase, care cu ceva sans
a poate
contine cheile cautate.
Salturile conditionate creeaza ferestre de vulnerabilitate n stadiile de procesare a
multor aplicatii de securitate, care permit ocolirea barierelor criptografice sofisticate
prin simpla mpiedicare a executiei codului care verifica daca o autentificare are
succes sau nu.
Contramasurile hardware includ generatori interni independenti de ceas, sincronizati
doar cu frecventa externa de referinta. O alta abordare, mai radicala dar potential
mai benefica, este sa se elimine complet ceasul, transformand procesoarele de card
n circuite autocronometrate asincrone.
Ceasul extern ar fi folosit doar ca referinta pentru comunicare si prin urmare
perturbarile de ceas ar cauza doar o corupere a datelor.
4.9.4
Analiza diferential
a a erorilor
Analiza diferentiala a erorilor (Differential Fault Analysis DF A) este o tehnica de atac

detaliata de Biham si Shamir ([2]) mpotriva sistemelor de criptare nglobate n dispozitive
precum smartcard-urile.
Daca un dispozitiv aflat sub stress (caldura, vibratii, presiune, radiatii etc.) poate fi facut
sa returneze iesiri eronate, atunci un criptanalist care compara iesirile corecte cu cele
eronate, are un punct de pornire n atac.
31
DF A poate sparge DES folosindu-se de 200 texte criptate n care s-au introdus erori
de un bit, un numar infim comparativ cu numarul de texte solicitat de atacurile standard
(criptanaliza diferentiala sau liniara).
Modelul folosit a fost propus de Boneh si dezvoltat ulterior de Biham si Shamir. Se
presupune ca prin expunerea unui procesor la o sursa slaba de radiatie ionizanta, acele
erori de un bit pot fi induse n datele folosite si n special n corpul sub-cheii generate
n rundele succesive DES. Metoda poate fi extinsa pentru a realiza reverse engineering
pentru algoritmi a caror structura este necunoscuta.
1. Cu aceasta metoda a perturbatiilor se poate efectua un atac direct (propus de
Lenstra) asupra algoritmului RSA (sau DSA):
Presupunem ca un smartcard calculeaza o semnatura RSA, S pe un mesaj M ,
modulo n = pq, calculand ntai modulo p si q separat si apoi combinand rezultatele
cu Teorema Chineza a Resturilor. Daca poate fi indusa o eroare n oricare din aceste
calcule, atunci se poate factoriza n. Mai exact, daca e este exponentul public, iar
semnatura S = M d (mod pq) este corecta modulo p dar incorecta modulo q, atunci
p = cmmdc(n, S e M ).
2. Si atacurile asupra DES sunt destul de directe, daca Oscar poate alege ce instructiune va avea de suferit n urma unei perturbatii.
De exemplu el poate opta sa nlature una din operatiile XOR pe 8 biti folosite pentru
a combina cheia de runda cu intrarile n S boxurile provenite de la ultimele doua
runde ale textului, si repeta aceasta procedura pe rand pentru fiecare octet din
cheie. Fiecare din textele criptate alterate obtinute ca rezultat al acestui atac va
diferi de textul criptat autentic n iesirile a doua sau trei S boxuri.
Folosind tehnicile criptanalizei diferentiale, intrusul poate obtine ca rezultat al
erorii induse n jur de 5 biti de informatie despre cei 8 biti ai cheii care nu au fost
XOR-ati.
Astfel, de exemplu, 6 texte criptate folosind runde finale gresite pot demasca aproximativ 30 biti din cheie, permitand o cautare exhaustiva destul de usoara a cheii.
3. Un atac mai rapid se obtine daca se reduce numarul de runde din DES la maxim
2, prin coruperea unei anumite variabile sau a unui salt conditionat. Astfel, cheia
poate fi aflata printr-un atac simplu. Aplicabilitatea acestui atac consta n detaliile
de implementare.
4. DF A poate fi folosit chiar si pentru un sistem necunoscut de criptare. Biham si
Shamir arata ca n anumite conditii structura unui sistem de criptare similar
cu DES poate fi schitata folosind aproximativ 500 texte criptate; mai mult daca
numarul lor ajunge la 10.000, atunci se pot reconstitui toate detaliile legate de
S-boxuri.
32
O metoda de aparare mpotriva DF A consta n adaugarea unor rutine pentru detectarea erorilor.
Daca iesirile nu contin niciodata erori, DF A devine imposibil de aplicat, iar daca iesirile
eronate sunt destul de rare, DF A devine nepractic.
Exista numeroase propuneri pentru construirea rutinelor de detectie a erorilor.
1. O prima abordare este ca textul sa fie criptat de doua sau mai multe ori, iar rezultatele obtinute sa fie comparate si respinse daca nu coincid. Este o metoda destul
de ineficienta practic.
2. Verificarea paritatii:
Paritatea bitilor dintr-o secventa nu se schimba daca bitii sunt permutati. Verificarea paritatii poate proteja deci orice operatie criptografica care presupune permutare de biti. Se acopera astfel cateva operatii cum ar fi permutarile la nivel de
octeti sau blocuri, deplasari circulare, programarea cheilor pentru IDEA sau pentru
cateva versiuni de CAST . Sunt acoperite de asemenea toate operatiile echivalente
cu permutarea nula, cum ar fi stocare si recuperare sau transmisie si receptie a unei
valori.
Bitul de paritate al concatenarii a doua sau mai multe siruri de biti este XOR-ul
bitilor de paritate ai secventelor initiale. Verificarea paritatii poate proteja astfel
orice operatie criptografica bazata pe concatenare de biti sau invers pe spargere
n subblocuri.
Chiar si operatia XOR poate beneficia de pe urma verificarii paritatii, deoarece
bitul de paritate al unui XOR este egal cu XOR-ul bitilor de paritate ai intrarii.
3. Verificare prin aritmetica modular
a:
Orice operatie aritmetica pe Z ramane adevarata modulo orice baza (convenabila).
Folosirea unei baze mari, sau verificarea calculelor n mai multe baze duce la cresterea sanselor gasirii unei erori.
O tehnica buna de verificare a calculelor consta n adaugarea de grupuri de n cifre
binare, pentru a obtine valori modulo 2n 1.
Bibliografie
[1] Atanasiu, A. Securitatea Informatiei, vol 1 (Criptografie), Ed. InfoData, Cluj, 2007.
[2] Biham, E., Shamir. A. Differential Fault Analysis of Secret Key Cryptosystems. In
Burton S. Kaliski Jr. ed., Advances in Cryptology - CRYPTO 97, LNCS vol. 1294,
Springer - Verlag, 1997, pp. 513 - 525.
[3] Kocher, P. Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS and
Related Attacks, Proceedings of Advances in Cryptology - CRYPTO96, SpringerVerlag, 1996, pp. 104-130
[4] Kocher, P., Jaffe, J., Jun, B. Differential Power Analysis, Advances in Cryptology Crypto 99 Proceedings, LNCS vol. 1666, M. Wiener, ed., Springer-Verlag, 1999
[5] Schneier, B, Shostack, A - Breaking Up Is Hard to Do: Modeling Security Threats for
Smart Cards, USENIX Workshop on Smartcard Technology Chicago, Illinois, USA,
May 1011, 1999
[6] Shamir, A. Protecting Smart Cards from Passive Power Analysis with Detached
Power Supplies, LNCS, Springer - Verlag, 2000
[7] Simmons, G. J. Contemporary Cryptology, IEEE Press, 1992
33
Capitolul 5
Securitatea comunicatiilor GSM
5.1
Descrierea sistemului GSM
GSM (Global System for Mobile Communications) a fost dezvoltat de 3GP P (3rd Generation Partnership Project) ca standard pentru comunicatiile celulare digitale. Lucrarile de
proiectare au nceput n anul 1987, sistemul fiind realizat n forma finala prin cooperarea
a 17 tari europene; punerea n functiune a primelor retele GSM s-a realizat n 1991.
Desi initial GSM era destinat doar ca un standard european, el s-a raspandit rapid
n ntreaga lume; de remarcat ca la nivel mondial exista de asemenea si ADC (American
Digital Cellular) sistemul digital nord-american si JDC (Japonese Digital Cellular)
sistemul digital din Japonia. Se estimeaza ca n acest moment 82% din piata mobila la
nivel global foloseste standardul GSM . La sfarsitul anului 2005 sistemul dispunea de 1, 5
miliarde utilizatori, iar astazi numai cateva tari printre care Japonia si Coreea de Sud
nu se afla sub acoperirea sistemului GSM .
Printre motivele care au stat la baza acestei expansiuni putem aminti mbunatatirile
din domeniul tehnologiei telecomunicatiilor, precum si reducerile constante de preturi
atat pentru infrastructura cat si pentru telefoanele mobile. Sistemul GSM este bazat
pe o tehnologie celulara de a doua generatie 2G (ofera voce digitala, spre deosebire de
tehnica analogica folosita n sistemele anterioare). Multi operatori continua sa investeasca
n dezvoltarea retelelor GSM , acest lucru nempiedicand preocuparile de a introduce noi
functionalitati si de a micsora costul lor operational.
Standardul GSM s-a dezvoltat continuu, asa ncat versiunea 97 a fost mbogatita cu
GP RS serviciul de transfer pe pachete de date care permite ca informatia digitala
sa circule printr-o retea de telefonie mobila. Sistemele celulare 2G combinate cu GP RS
sunt de multe ori descrise ca 2.5G. Acesta completeaza transferul rapid de date (CDS) si
SM S-ul, ajungand pana la o viteza teoretica de 171.2 kbps (kilobiti pe secunda). O viteza
si mai mare pentru transmiterea de date n GSM a fost introdusa de EDGE (tehnologie
a retelei GSM /GP RS, destinata sa mbunatateasca calitatea serviciilor de date), care
asigura o viteza de pana la 236 kbps.
1
CAPITOLUL 5. SECURITATEA COMUNICAT

IILOR GSM
5.1.1
Cerinte pentru sistemul GSM
Trecerea la sistemele celulare digitale s-a datorat n principiu:

1. Capacitatii reduse a sistemelor analogice.
2. Necesitatii de a pune la dispozitia utilizatorilor un sistem compatibil cu alte sisteme
digitale cu servicii integrate.
Cresterea capacitatii sistemelor digitale, fata de sistemele analogice, se explica, pe
de o parte prin cresterea capacitatii de trafic a macrocelulelor si pe de alta parte
prin posibilitatea reducerii dimensiunilor celulelor, adica prin introducerea microcelulelor
(sistemul celular GSM are trei tipuri de celule: macrocelule, ce acopera o raza de 15 km,
microcelule raza de 500 m si picocelule pe distante mai mici de 100 m).
Initial, sistemul GSM a fost proiectat sa ndeplineasca urmatoarele cerinte:
1. Calitate buna a transmisiei,
2. Costuri mici pentru servicii si terminal,
3. Suport pentru deplasari internationale,
4. Capacitate de a suporta terminale portabile,
5. Suport pentru servicii si facilitati noi,
6. Eficienta spectrala si compatibilitate cu sistemul ISDN (retea digitala cu servicii
integrate, care permite interconectarea mai multor dispozitive: calculatoare, telefoane, aparate faximile etc).
5.1.2
Serviciile oferite de GSM
Serviciile de telecommunicatii se mpart n servicii de transfer de date, teleservicii, si

servicii suplimentare. Teleserviciul de baza suportat de GSM este telefonia. Semnalul
vocal este codificat digital si transmis prin reteaua GSM ca un flux de semnal digital.
Un serviciu specific oferit de GSM inexistent n sistemele analogice este Serviciul
de Mesaje Scurte (SM S). Alte servicii suplimentare sunt oferite n specificatiile curente,
care includ mai multe forme de transfer al apelului; ele includ identificarea apelantului,
apel n asteptare, conversatii multiple (conferinte) etc.
Reteaua pe care se construieste sistemul GSM se mparte n:
1. Statia mobila (M S - Mobile Station): este componenta aflata la abonat.
2. Subsistemul Statie de baza (BSS - Base Station Subsystem): controleaza legatura
radio cu statia mobila.
5.1. DESCRIEREA SISTEMULUI GSM
3. Subsistemul Retea (Network Subsystem): principala sa componenta este Centrul de

comutatie a serviciilor mobile (M SC - Mobile services Switching Center).
Vom detalia fiecare din aceste componente.
5.1.3
Statia mobil
a
Statia mobila consta dintr-un echipament mobil (cunoscut si sub denumirea de terminal)
si un smartcard SIM (Subscriber Identity Module).
Echipamentul mobil
Cel mai cunoscut echipament mobil este telefonul celular folosit initial numai pentru
apeluri vocale; astazi nsa, tendinta este de a-i asocia tot mai multe dispozitive mobile n
care telefonul este doar o componenta:
P DA cu telefon mobil pentru transmisii vocale si de date.
Console pentru jocuri cu telefon mobil integrat pentru voce si date.
Telefoane mobile pentru voce cu interfata Bluetooth integrata, care permite dispozitivelor de tip P DA sau notebook sa foloseasca telefonul pentru conexiune la
Internet.

IILOR GSM
Echipamentul mobil este identificat n mod unic de IM EI (International Mobile Equipment Identity) un cod care se gaseste de obicei tiparit pe telefon, sub bateria de alimentare si este folosit strict pentru identificare, neavand o relatie permanenta cu abonatul.
Componenta principala a unui telefon mobil este procesorul care contine o unitate
centrala RISC (cu set minimal de instructiuni) si un procesor cu semnal digital (DSP ).
Procesorul RISC este responsabil de urmatoarele actiuni:
1. Manevrarea informatiei primite prin diversele canale (BCCh, P Ch etc).
2. Stabilirea apelului si administrarea mobilitatii (cautarea retelei, reactualizarea locatiei, decalajul n timp etc).
3. Conexiunile prin interfetele externe ca Bluetooth, U SB etc.
Cum multe dintre aceste sarcini trebuie efectuate n paralel, procesorul RISC foloseste
un sistem de operare multitasking n timp real, capabil sa furnizeze informatii pentru
transmisiile prin interfata radio conform structurii si coordonarii n timp impusa de GSM .
Toate celelalte sarcini ca manevrarea tastaturii, actualizarea ecranului si interfata
grafica au o prioritate redusa.
Cartela SIM
Cartela SIM (Subscriber Identity Module) este un smartcard care stocheaza informatii
esentiale, cum ar fi IM SI (International Mobile Subscriber Identity), M SI un numar
unic asociat fiecarui abonat, Ki (cheia secreta folosita pentru autentificare) si alte informatii
despre utilizator. In general, informatiile sunt protejate printr-un numar personal de identificare (P IN ).
De fapt, un card SIM este mai mult decat o simpla memorie; el contine un microcontroller care poate fi folosit pentru scopuri aditionale, cum ar fi generarea valorii SRES
n procesul de autentificare (descris ulterior). Este obligatoriu ca SRES sa fie calculat
n interiorul SIM -ului si nu n telefonul mobil, pentru a proteja cheia secreta Ki , care
intervine de asemenea n procesul de autentificare.
Din punct de vedere logic, datele sunt stocate pe SIM n directoare si fisiere ntr-o
maniera similara stocarii pe hard-ul unui PC.
In specificatia tehnica 3GP P (3GP P T S), directorul root se numeste fisierul principal
(M F ). Urmatoarele directoare se numesc fisiere dedicate (DF ) iar fisierele normale se
numesc fisiere elementare (EF ). Datorita faptului ca memoria unui SIM este extrem
de limitata, fisierele nu pot fi identificate prin numele directorului si fisier. Sunt folosite
numere hexazecimale care ocupa numai 2 octeti de memorie fiecare. Standardul asigneaza
identificatori pentru aceste numere dar nu le stocheaza pe SIM .
Exemplul 5.1. Directorul root este identificat, de exemplu, prin 0x3F 00, directorul GSM
prin 0x7F 20, iar fisierul care contine IM SI, de pild
a, este identificat prin 0x6F 07.
Pentru a citi IM SI-ul de pe cartela SIM , statia mobil

a trebuie s
a deschid
a fisierul
av
and calea
0x3F 00 0x7F 20 0x6F 07.
Fisierele de pe SIM sunt protejate prin diferite drepturi de acces. Cu aceste atribute,
producatorul poate controla daca un fisier este citit sau scris numai daca este accesat de
telefonul mobil.
5.1.4
Subsistemul Statie de baz

a
Daca functionalitatea subsistemului retea pentru GSM este n cea mai mare parte definita
de soft-ul aditional, subsistemul Statie de baz
a este specific. Vechile generatii de sisteme
se bazau pe transmisii analogice prin interfata radio.
Subsistemul Statie de baza este responsabil pentru asigurarea traficului si a semnalului
ntre statia mobila si centrul de comutatie a serviciilor mobile. El este compus din:
Banda de frecvente
In sistemul GSM ea este formata din doua sub-benzi:
1. 890 915 MHz: comunicarea de la Statia Mobila la Statia de Baza (uplink);
2. 935 960 MHz: comunicarea de la Statia de Baza la Statia Mobila (downlink).
Aceste sub-benzi (fiecare de cate 25 MHz) sunt mpartite n 124 perechi de frecvente
purtatoare, fiecare pereche avand alocata o banda de 200 kHz.
Fiecare frecventa purtatoare este utilizata pentru transportul a 8 canale telefonice
distincte, multiplexate n timp (T DM A).
Deci numarul de cai telefonice este de 8 124 = 992.
Acest lucru este posibil deoarece datele si semnalele audio sunt codate si transmise digital.
Transmisia se face n pachete n interiorul intervalului de timp alocat, cu o rata de 271
kbps.
Datorita cererii tot mai mari din tarile europene, ulterior s-a adaugat un interval
suplimentar de frecvente pentru GSM , care foloseste pentru uplink banda de frecvente
1710 1785 MHz iar pentru downlink 1805 1880 Mhz. In locul latimii de banda de 25
MHz normala frecventei 900 MHz frecventa 1800 Mhz ofera o latime de banda de 75
Mh, care permite nca 375 canale aditionale1 .
GSM foloseste diverse canale pentru transmiterea datelor. Acestea sunt mpartite n
1
In America de Nord datorit

a existentei retelelor de telefonie mobila analogica la aparitia GSM ului, intervalele 900 MHz si 1800 MHz erau deja ocupate; de aceea s-au deschis frecvente noi de banda pe
1900 MHz si 850 MHz. Prin urmare, multe telefoane mobile GSM din SU A nu pot fi folosite n Europa
si vice versa.

IILOR GSM
Canale fizice (determinate de timesloturi),

Canale logice: folosite pentru transmiterea datelor utilizatorului si a datelor de
semnalizare.
Daca datele dintr-un canal logic sunt dedicate unui singur utilizator, atunci canalul
este numit canal dedicat. Daca avem n vedere transmiterea de date pentru mai
multi utilizatori, canalul este numit canal comun.
Canalele dedicate sunt clasificate n:
Canalul de trafic (T Ch): canal pentru datele utilizatorilor. Poate fi folosit pentru
transmisia de semnal vocal digital pana la 14.4 kbps.
Canale asociate rapide de control (F ACCh): ascund timeslot-uri din traficul alocat
si sunt folosite pentru cereri neprogramate de control, cereri transmise ocazional (de
exemplu handover-urile).
Canale asociate lente de control (SACCh): folosite n directia uplink pentru a
raporta masurile de calitate a semnalului din celula deservita si din cele vecine. In
sens invers, canalul este folosit pentru transmisia de comenzi de control de putere
catre statia mobila.
Canale de control dedicate (DCh): canale multiplexate ntr-un canal de trafic standard. Sunt folosite pentru nregistrare, reactualizarea locatiei, autentificare si apelare.
Canal comun descendent (AGCh): utilizat pentru a transmite mobilului mesaje de
alocare a unui canal dedicat.
Pe langa canalele dedicate asignate unui singur utilizator exista si canale comune,
dedicate tuturor utilizatorilor dintr-o celula:
Canal de sincronizare (SCh): folosit de statiile mobile n timpul cautarii retelei si
a celulei.
Canale de control emis (BCh): canale logice necesare transmisiei periodice a informatiilor generale.
Canal de paging (P Ch): canal logic care transporta mesajele de difuzare pe interfata
radio; este folosit n principal pentru anuntarea mobilului despre apelurile primite.
Canal de acces aleator (RACh): canal de accesare a retelei M S BT S. Este folosit
de M S pentru a cere alocarea unui canal dedicat.
Base Transceiver Station (BT S)

Statiile de baza sunt componentele cele mai vizibile din reteaua GSM . Ele nlocuiesc
conexiunile prin cablu din telefonia fixa prin conexiuni fara fir cu utilizatorul si reprezinta
componenta cea mai raspandita din reteaua de telefonie mobila.
Arhitectura celulara (celulele etichetate cu acelasi num

ar folosesc aceeasi frecvent
a)
BT S contine echipamentul necesar transmiterii si primirii semnalului, antene si echipament pentru criptarea si decriptarea comunicatiilor cu BSC (Base Station Controler). De
obicei, un BSC are sub control pana la 100 BT S. Retelele sunt structurate astfel ca sa
aiba mai multe BSC distribuite n regiuni apropiate de BT S-urile lor, conectate la grupuri
centralizate de M SC.
Teoretic, o statie de baza (BT S) poate acoperi o suprafata cu raza de pana la 35 km,
numita celula. Deoarece un BT S poate deservi simultan un numar limitat de utilizatori
celulele sunt de fapt mult mai mici, n special n mediile urbane foarte dense. Aici, celulele
acopera arii de raza 3 4 km n zonele rezidentiale si coboara pana la raze de numai 100
m n zonele comerciale foarte frecventate.
Chiar si n zonele rurale, aria de acoperire a unei celule este de obicei sub 15 km; puterea
redusa de transmisie a statiei mobile este n acest caz factorul limitator.
Avand n vedere ca emisiile statiilor de baza diferite dintr-o retea nu trebuie sa interfereze, toate celulele nvecinate trebuie sa emita pe frecvente diferite (vezi figura). Cum o
celula este nconjurata de multe altele, o statie de baza poate folosi doar un numar limitat
de frecvente diferite pentru a-si mari capacitatea.
Interfata radio
Legatura ntre BT S si terminalul mobil este denumita interfat
a radio sau interfat
a U m.
Exista doua metode care permit statiei de baza sa comunice simultan cu mai multi utilizatori.
1. Acces multiplu prin diviziune n frecventa (F DM A): utilizatorii pot comunica cu
statia de baza pe frecvente diferite, fara a interfera unii cu altii.
2. Acces multiplu prin diviziune n timp (T DM A Time Division Multiple Access).
GSM foloseste frecvente cu latimea de banda de 200 kHz prin care 8 utilizatori pot

IILOR GSM
comunica simultan cu statia de baza. Utilizatorii sunt multiplexati n timp prin

mpartirea n frame-uri cu durata de 4, 615 ms. Fiecare frame contine 8 timesloturi independente, fiecare timeslot fiind folosit pentru comunicarea cu alt utilizator.
Durata unui timeslot este de 0, 577 ms si cuprinde 148 biti, cu o perioada de garda2
de 8, 25 biti ntre slot-uri.
Frame TDMA
Prin combinarea procedeelor F DM A si T DM A se poate calcula capacitatea totala a
unei statii de baza.
Controllerul Statiei de baz
a (BSC)
In timp ce statia de baza este un element de interfata care conecteaza statia mobila cu
reteaua, controlerul statiei de baza (Base Station Controller - BSC) este responsabil de
stabilirea, ntreruperea si mentinerea conexiunilor celulelor care sunt conectate la el.
Functii ndeplinite de un BSC:
Daca un utilizator doreste sa efectueze un apel vocal, sa trimita un SM S etc, statia
mobila trimite un mesaj de cerere de canal catre BSC, care verifica daca exista
vreun canal SDCCh disponibil, si n caz afirmativ, l activeaza. Apoi BSC trimite
un mesaj de asignare statiei mobile prin AGCh, care include si numarul canalului
SDCCh asignat.
Stabileste canalele de semnalizare pentru apelurile primite sau mesajele scurte.
Mentine conexiunea. Cum utilizatorii se pot plimba liberi n retea n timpul unei
convorbiri, se poate ntampla ca ei sa depaseasca acoperirea celulei n care a fost
initiat apelul. In acest caz BSC intervine, directionand apelul catre cea mai
apropiata celula.
Pentru a reduce interferenta, raspunde de controlul puterii de transmisie pentru
fiecare conexiune prin interfata radio.
Pentru statia mobila, un control activ al puterii poate reduce puterea de transmisie
2
Perioada de gard
a este o perioad
a n care nu se transmite informatie; deoarece distanta unui utilizator
fata de statia de baz
a se poate schimba, se evita astfel suprapunerea ntre semnale.
n conditii de receptie favorabile. Daca puterea de transmisie a statiei mobile trebuie

sa creasca/scada, BSC trimite un mesaj de control catre BT S. In practica, controlul
puterii si adaptarea se fac la fiecare 12 secunde. In timpul stabilirii apelului, statia
mobila foloseste nivelul cel mai nalt admis de putere; acesta este apoi redus treptat
de catre retea.
Are n grija controlul decalajului n timp. T DM A solicita ca semnalele de la toate
mobilele care folosesc acelasi canal (de paging) sa atinga Statia de Baza la momente
corecte de timp, fara sa se suprapuna.
Exemplul 5.2. Daca Statia de Baz
a furnizeaz
a un semnal de referint
a, mobilele aflate
n apropierea sa vor raspunde mai devreme dec
at cele aflate la marginea ariei celulei.
GSM poate permite celulelor sa se extind
a p
an
a la 35 Km de Statia de Baz
a. Timpul
luat de semnalul radio pentru a strabate 70 Km (p
an
a la perimetru si napoi) este de 0, 23
ms; astfel, pentru fiecare timeslot va fi oferit
a o perioad
a de gard
a de aceast
a lungime.
Cum acest interval este clar ineficient, GSM va informa de fiecare dat
a mobilul cu cat
trebuie s
a-si avanseze transmisia astfel nc
at s
a se sincronizeze corect cu Statia de Baza.
Se ajunge n final la o perioada de 0, 03 ms adic
a 8, 25 biti.
5.1.5
Subsistemul retea
Are ca principale responsabilitati:

Stabilirea apelului;
Controlul apelului;
Rutarea apelurilor ntre diferite centre de comutatie fixe/mobile si alte retele.
Componentele sale sunt:
Centrul de comutare a serviciilor
Mobile Switching Center (M SC) este elementul central al retelei3 , deoarece el controleaza
toate conexiunile ntre utilizatori.
Activitatile de administratie pentru stabilirea si mentinerea unei conexiuni cuprind
urmatoarele sarcini:
Inregistrarea utilizatorilor: cand statia mobila este pornita, ea se nregistreaza n
retea, devenind accesibila tuturor utilizatorilor.
Stabilirea apelului si rutarea acestuia ntre doi utilizatori.
3
Este denumit si Retea de telefonie pe teritoriu public - P LM N (Public Land Mobile Network).
10

IILOR GSM
Transmiterea mesajelor scurte SM S.

Deoarece utilizatorii dispun de o mobilitate foarte mare n retea, M SC este responsabil
si de gestionarea urmatoarelor actiuni:
Autentificarea utilizatorilor n momentul stabilirii conexiunii.
Daca nu exista nici o conexiune activa ntre retea si statia mobila, M SC trebuie
sa raporteze retelei schimbarea locatiei mobilului, facandu-l astfel disponibil pentru
apeluri primite si mesaje scurte.
Daca utilizatorul si schimba locatia n timpul stabilirii unei conexiuni cu reteaua,
M SC asigura continuitatea conexiunii si rutarea ei catre urmatoarea celula procedura numita handover.
Asigura partea de facturare a apelurilor. M SC retine informatii cum ar fi numarul
apelatului si numarul apelantului, ID-ul celulei din care a fost initiat apelul, durata initierii apelului, durata apelului etc, pe care apoi le transmite serverului de
facturare.
Registru de localizare a vizitatorilor
Visitor Location Register (V LR) retine informatii despre fiecare utilizator care este servit
la momentul curent de M SC; aceste informatii sunt copii ale informatiilor originale stocate n HLR. Scopul principal al folosirii V LR este reducerea numarului de mesaje ntre
M SC si HLR.
Cand un utilizator ajunge n zona unui M SC, datele sunt copiate n V LR-ul aferent,
fiind disponibile local pentru orice conexiune. Cand acesta paraseste zona, informatiile
respective sunt copiate din HLR n V LR-ul noului M SC, fiind sterse din V LR-ul anterior.
Desi este posibila implementarea lui V LR ca o componenta hardware independenta,
n majoritatea cazurilor el este o componenta software din M SC.
Registrul de localizare (HLR)
Home Location Register (HLR) reprezinta baza de date cu utilizatori a retelei GSM . El
contine informatii despre serviciile disponibile pentru fiecare utilizator n parte.
Exemplul 5.3. IM SI-ul care identific
a un utilizator este stocat at
at pe SIM c
at si n
HLR; el reprezinta cheia catre orice informatie despre utilizator. Cum IM SI este unic la
nivel international, utilizatorul poate folosi telefonul nafara t
arii sale de origine (desigur,
dac
a exist
a un acord cu operatorul din tara sa). Atunci c
and telefonul este deschis, se
recupereaz
a IM SI de pe SIM si este transmis c
atre M SC care la r
andul s
au poate
cere informatii din HLR referitoare la utilizatorul respectiv.
5.2. RUTAREA APELURILOR IN GSM
11
Num
arul de telefon al utilizatorului numit si num
arul ISDN al utilizatorului n
standardul GSM are o lungime de maxim 15 cifre; el contine codul t
arii, codul national
destinatie (corespunzator operatorului respectiv) iar restul cifrelor reprezint
a num
arul utilizatorului.
Centrul de autentificare (AC)
AC detine o cheie secreta Ki pentru fiecare utilizator, care este o copie a cheii Ki de
pe cartela sa SIM . Pentru anumite operatii din retea (cum ar fi stabilirea unui apel),
utilizatorul este identificat prin Ki .
In AC se afla de asemenea cheile de autentificare si de criptare pentru toti utilizatorii
din HLR si din V LR-urile aflate n reteaua furnizorului. In particular, de aici sunt trimise
triplete de tipul (RAN D, SRES, Kc ) necesare pentru procesul de autentificare.
Registrul de identificare a echipamentului (EIR)
EIR este o baza de date care stocheaza o lista cu toate echipamentele mobile valide n
retea, fiecare telefon fiind identificat prin IM EI (International Mobile Equipment Identity). Un IM EI este marcat ca fiind invalid daca a fost declarat furat sau daca tipul sau
este unul neaprobat.
EIR mentine actualizate trei liste:
1. Lista alb
a: contine echipamentele mobile conforme cu cerintele impuse de operatorul de retea.
2. Lista neagr
a: contine echipamentele mobile care au fost raportate ca furate sau
cele care afecteaza bunul mers al retelei; acestea nu au voie sa acceseze reteaua.
3. Lista gri: contine echipamentele mobile care nu sunt conforme standardelor; ele
atent supravegheate, dar au voie sa acceseze reteaua.
5.2
Rutarea apelurilor n GSM
Utilizatorii telefoanelor mobile sunt prin definitie mereu n miscare; de aceea mecanismele pe care le foloseste reteaua GSM pentru a-i localiza sunt foarte importante. Sa
detaliem modul de rutare al apelurilor catre statia mobila.
5.2.1
Inregistrarea locatiei
Actualizarea locatiei este cel mai important instrument care permite gasirea telefoanelor
mobile n reteaua GSM . Locatia unei statii mobile este identificata n mod unic de codul
t
arii respective (mobile country code)(M CC), codul retelei mobile (M N C) si identitatea
12

IILOR GSM
locatiei (LAI). M CC-ul este o valoare de trei cifre ce identifica tara n care este situata
reteaua. M N C-ul este o valoare de doua cifre care identifica retele (concurente) din
aceeasi tara. LAI-ul identifica regiunea fizica n care este localizata statia mobila (o
regiune consta dintr-una sau mai multe celule fizice). Aceste trei valori formeaza mpreuna
IMSI-ul care identifica n mod unic un utilizator.
O retea poate avea mai multe centre de comutare a serviciilor mobile (M SC) dar numai
cele conectate la un ISDN sau PSTN sunt folosite ca gateway pentru centrele de comutare
(GM SC) dintr-o retea mpreuna cu un HLR. Apelurile sosite pentru telefoanele mobile
pot fi rutate corect numai dupa ce este verificata (n HLR) locatia mobilului tinta precum
si serviciile autorizate ale acestuia. GM SC si M SC au fiecare propriul V LR. Dupa ce
s-a efectuat actualizarea locatiei, mesajul de la statia mobila ce contine informatia despre
locatia sa este trimis prin M SC la V LR-ul atasat. Acesta verifica daca exista deja o
nregistrare cu acea statie mobila, si i actualizeaza locatia daca aceasta este diferita de
cea existenta. Daca statia mobila este necunoscuta pentru V LR, atunci acesta va avertiza
HLR despre locatia statiei mobile si despre informatiile de rutare, emitand anterior o
cerere despre datele de baza ale utilizatorului, pe care V LR le va folosi pentru a finaliza
initierea apelului.
Exista trei tipuri diferite de proceduri disponibile pentru actualizarea locatiei:
1. Inregistrarea: are loc atunci cand este deschisa o statie mobila. Dupa cateva
initializari interne, ea va cauta retele disponibile; cand va gasi o astfel de retea,
statia mobila va citi informatii despre locatie si va trimite IM SI-ul sau retelei
respective.
2. Actualizarea periodic
a a locatiei: este efectuata dupa o perioada de timp predefinita de retea si este trimisa constant tuturor statiilor mobile active care monitorizeaza canalul de control.
Daca statia mobila nu se nregistreaza n acest timp (de pilda, datorita faptului ca
utilizatorul a ajuns ntr-un spatiu cu semnal foarte slab), atunci reteaua va presupune ca statia mobila nu mai este disponibila si o va marca drept inaccesibila
n HLSR si V LR. Ca urmare, apelurile primite vor fi blocate n GM SC n loc sa
fie rutate spre regiunea n care se afla localizata. Apelul poate fi directionat catre
alt numar daca utilizatorul a setat n prealabil aceasta optiune.
3. Cand statia mobila detecteaza o schimbare a regiunii n care se afla, va anunta
reteaua despre aceasta schimbare.
5.2.2
Stabilirea apelului n GSM
Apelurile n GSM sunt clasificate astfel:
5.2. RUTAREA APELURILOR IN GSM
13
1. (In cazul n care apelul este initiat de retea) Reteaua notifica telefonul cu un PAGING REQUEST prin IM SI-ul corespunzator pe canalul de paging.
Daca apelul este initiat de telefonul mobil, se trece direct la pasul urmator.
2. Procedura de alocare directa:
(a) Telefonul trimite pe canalul RACh un mesaj RANDOM REQUEST de 8
biti. El este format dintr-o valoare aleatoare pe 5 biti, iar restul de 3 biti contine
establishment cause (tipul de apel care urmeaza a fi stabilit). Acest mesaj
solicita statiei de baza alocarea resurselor radio pentru realizarea conexiunii.
(b) Reteaua trimite un mesaj IMMEDIATE REQUEST pe canalul P AGCh.
Acesta contine valoarea aleatoare primita de la telefon, detalii despre canalul
alocat telefonului mobil, mpreuna cu alte informatii tehnice.
Mobilul se va racorda imediat la canalul de trafic alocat.
3. Cererea de servicii:
(a) Mobilul trimite un mesaj de cerere a serviciilor, incluzand T M SI-ul sau si
versiunile de A5 suportate
(b) Reteaua certifica acest mesaj si repeta T M SI-ul.
4. Autentificarea:
(a) Reteaua trimite o cerere de autentificare care include valoarea RAN D si un
numar care va stoca cheia Kc rezultata;
(b) Mobilul raspunde cu valoarea SRES calculata;
(c) Reteaua cere mobilului prin comanda CIP HM OD sa nceapa criptarea; ea
poate specifica algoritmul de criptare folosit si eventual cheia de criptare.
Reteua ncepe sa decripteze informatiile primite.
Mesajul poate fi folosit si pentru a cere mobilului sa trimita IM EI-ul si versiunea de software.
(d) Mobilul ncepe criptarea si decriptarea si raspunde cu mesajul
CIP HM ODCOM criptat. La cerere, el trimite si IM EI-ul.
5. Reteaua si mobilul comunica pe canal. Reteaua poate sa schimbe canalul n
functie de tipul apelului efectuat.
5.2.3
Rutarea apelului ntre dou

a statii mobile
Cand Alice initiaza un apel mobil catre Bob, apelul va fi rutat catre GM SC-ul retelei.
Daca reteaua are mai multe astfel de porti de intrare, apelul este rutat catre GM SC-ul
de care apartine Bob, adica spre acel GM SC al carui HLR atasat contine o nregistrare
14

IILOR GSM
cu datele lui Bob. GM SC-ul va afla locatia utilizatorului Bob prin lansarea unei cereri de
localizare, la care raspunde un HLR. Acesta va transmite catre GM SC zona sau M SCul corespunzator lui Bob. Cu aceasta informatie, GM SC-ul poate ruta apelul catre acel
M SC care poate finaliza initierea apelului. M SC-ul fiind acoperit de mai multe BSC
si BT S va trebui sa verifice locatia exacta a lui Bob din V LR si va primi un raspuns
continand datele exacte.
Mai departe, M SC este capabil sa trimita apelul spre Bob, folosind BT S-ul corect.
Rutarea apelului ntre dou

a statii mobile
Daca unul din utilizatori doreste ncheierea apelului, statia mobila va trimite spre
retea un mesaj de deconectare. Dupa eliberarea canalului de trafic si dupa trimiterea
unui mesaj de terminare catre celelalte parti implicate, toate resursele din retea sunt
eliberate si apelul este ncheiat.
5.3
Securitatea GSM
Conform cerintelor, un sistem GSM trebuie sa fie cel putin la fel de sigur ca P ST N
(Public Switched Telephone Network) reteaua de telefonie publica bazata pe circuite de
comutatie.
5.3.1
Cerinte de securitate
Securitatea GSM trebuie sa ia n considerare atat pe operatorul de retea cat si pe

client. Transmiterea informatiilor prin unde radio (wireless) implica existenta unor riscuri
potentiale care provin din interceptarea transmisiilor.
Operatorii sistemului vor sa se asigure ca ei sunt cei care emit facturile catre persoanele potrivite, sa evite fraudele si sa aiba siguranta serviciilor necompromise.
Clientii doresc sa li se asigure confidentialitatea convorbirilor.
5.3. SECURITATEA GSM
15
Pentru asigurarea acestor cerinte, sistemul este proiectat astfel ncat sa ofere retelei wiireless aceeasi siguranta pe care o are reteaua fixa, siguranta care nseamna autentificare
si confidentialitate mpotriva ascultarilor nedorite n retea.
Specificatiile GSM identifica urmatoarele trei aspecte ale securitatii pe care le acopera
sistemul:
Autentificarea utilizatorilor: telefonul mobil trebuie sa-si dovedeasca dreptul de
acces la un anumit cont din reteaua operatorului dorit.
Anonimitatea utilizatorilor: identificarea unui utilizator n retea devine o problema dificila pentru cineva din afara sistemului.
Confidentialitatea: informatiile comunicate wireless trebuie sa fie protejate, iar
accesarea lor sa fie posibila doar utilizatorilor destinati.
5.3.2
Anonimitatea
In momentul in care utilizatorul si deschide echipamentul mobil pentru a-l folosi n reteaua
operatorului contractat, el trebuie sa se identifice n retea.
Identificarea se face cu ajutorul numarului unic IM SI aflat pe SIM . Cum IM SI este
elementul cheie n rutarea apelurilor, reteaua trebuie sa stie la orice moment unde se afla
telefonul identificat. Aceasta functionalitate a retelei se numeste gestionarea locatiei
(location management.
Cum IM SI-ul identifica n mod unic un utilizator al retelei iar aceasta informatie
este publica este suficient ca cineva sa-l intercepteze n aer, pentru a identifica utilizatorul
corespunzator si a-i afla locatia.
Acest lucru este contracarat prin proprietatea de anonimitate, care protejeaza identitatea
utilizatorului fata de cineva care dispune de IM SI-ul sau. Identitatea protejata n cadrul
retelei implica si ascunderea locatiei, precum si a apelurilor efectuate.
GSM asigura anonimitatea folosind un identificator temporar pentru client T M SI
(Temporary Mobile Subscriber Identity) care, spre deosebire de IM SI (unic la nivel
global), este valid numai local si este asignat utilizatorului atunci cand cartela SIM
s-a autentificat n retea. Pentru comunicarea cu acel SIM , reteaua va folosi n continuare
numai T M SI-ul alocat.
Atunci cand este nregistrata o modificare a locatiei, reteaua asigneaza un nou T M SI
pentru statia mobila, care este stocat n retea mpreuna cu IM SI. Statia mobila si
reteaua vor folosi de acum pentru comunicare numai T M SI-ul. La nchidere, statia
mobila memoreaza T M SI-ul actual pe cartela SIM , pentru a fi accesibil atunci cand
este repornita.
Pe de alta parte, se poate vorbi ntr-un schimb de informatii ntre utilizatori despre
anonimitatea transmitatorului si a receptorului.
Anonimitatea transmitatorului se refera la ascunderea identitatii expeditorului unui mesaj,
16

IILOR GSM
iar anonimitatea receptorului ofera posibilitea de a-l contacta pe destinatar chiar daca
acesta ramane anonim.
[?] este prezentat un mecanism care s
Exemplul 5.4. In
a permit
a utilizatorului unei
statii GSM sa efectueze/primeasca apeluri astfel nc
at furnizorul s
au de telefonie mobila
s
a nu poata determina identitatea celeilalte p
arti implicate n convorbire.
Pentru aceasta, autorii folosesc un Trusted Third Party Privacy Proxy iar solutia propusa
implic
a folosirea de alias-uri (identificatori unici asociati abonatilor) astfel nc
at reteaua
s
a nu poat
a face legatura ntre acestea si transmit
atorul/receptorul real dec
at pentru scopuri de facturare.
In sistemul GSM exista o serie de probleme legate de stabilirea anonimitatii:
Un abonat trebuie sa poata fi accesat oricand: reteaua trebuie sa i stie mereu
locatia pentru a putea ruta apelurile sosite catre el. Chiar daca receptorul nu
cunoaste identitatea apelantului, reteaua trebuie sa cunoasca informatiile ambelor
parti, pentru a putea stabili si deschide canale de comunicare.
Numarul de telefon al unei persoane odata stiut poate fi considerat public: poate
fi divulgat si altor persoane, chiar fara consimtamantul proprietarului.
Apelurile GSM trebuie sa se desfasoare n timp real si sunt facturate n functie de
timp, de regulile stabilite n contract etc. Transmitatorul trebuie sa fie legat de o
anume entitate ce poate fi identificata, astfel ca dupa un anumit interval de timp
(de obicei lunar), operatiunile efectuate de el n retea sa poata fi facturate.
5.3.3
Atacuri asupra anonimit

atii utilizatorilor GSM
Atacurile asupra anonimitatii utilizatorilor GSM pot fi active sau pasive.

Atacatorul poate initia un atac pasiv cand doar asculta traficul, fara a efectua
actiuni; n schimb n monitorizarea activa, atacatorul se implica prin fabricarea si inserarea
unor mesaje, distrugerea altora etc.
Monitorizare pasiv
a
Stim ca la fiecare pornire a unei statii mobile se ataseaza un IM SI, pentru a informa
reteaua asupra faptului ca IM SI-ul respectiv este activ din acel moment. Protocolul
foloseste procedura de actualizare a locatiei din care statia mobila transmite un mesaj,
mpreuna cu IM SI-ul sau. Daca acesta nu este nregistrat n retea, atunci nu i este
asociata nici o cheie Ki , iar criptarea nu poate fi aplicata. Deci IM SI trebuie transmis
n clar, iar un atacator care asculta traficul, l poate extrage.
Aceasta nu este singura situatie cand poate fi capturat IM SI-ul. Exista cazuri (de
exemplu o disfunctionalitate a bazei de date) cand HLR-ul nu poate folosi T M SI pentru
a obtine anumiti parametri ai utilizatorului si prin urmare va cere n clar IM SI-ul.
17
Monitorizare activ
a
In acest caz Oscar poate comunica cu statia mobila, ceea ce presupune existenta unui
echipament mai sofisticat decat n cazul unei monitorizari pasive. El va folosi o procedura de identificare, n care reteaua va efectua un IDENTITY REQUEST, cerand statiei
mobile, IM SI, IM EI sau T M SI.
Deoarece GSM nu verifica autenticitatea unui mesaj, Oscar poate pretinde ca este
statie de baza, obtinand astfel prin intermediul unui astfel de mesaj informatia dorita.
Dupa ce detine IM SI-ul, atacatorul si poate identifica victima.
Urmatorul pas este gasirea T M SI-ului pe care reteaua l aloca statiei mobile, astfel
ca Oscar sa-l poata asocia IM SI-ului; aceasta i permite ulterior sa urmareasca miscarile
statiei mobile.
T M SI-ul este criptat nainte de a fi transmis, deci Oscar va trebui ntai sa-l decripteze.
El va genera o situatie n care cele doua entitati legitime care comunica sa creada ca
dispun de capabilitati diferite de criptare. Oscar poate face acest lucru deoarece poate
insera, distruge sau fabrica mesaje dupa bunul plac lucru posibil datorita faptului ca
GSM nu asigura integritatea mesajelor si nici autentificarea retea-utilizator.
5.3.4
Autentificarea
Prin autentificare se evita situatiile cand persoane neautorizate patrund n retea pretinzand ca sunt utilizatori acceptati ai retelei. Inainte de a avea acces la serviciile unei
retele GSM , un utilizator trebuie sa isi dovedeasca autenticitatea.
Vom descrie procedura de autentificare, reprezentata n figura urmatoare:
Procesul de autentificare n reteaua GSM

1. La pornire, echipamentul mobil ncepe cu cautarea unei retele wireless la care sa
se conecteze, scanand un anumit interval de frecvente. In momentul cand a gasit
18

IILOR GSM
frecventa dorita, SIM -ul ncearca sa se autentifice, trimitand un mesaj la BT S prin

care cere accesul la retea.
2. BT S-ul comunica cu centrul de comutare pentru a decide permiterea accesului,
care se face n urma unui protocol provocare - raspuns, bazat pe cheia secreta Ki
partajata ntre telefon si retea.
3. Centrul de comutare obtine de la registrul de locatii un triplet de forma
(RAN D, SRES, Kc )
unde:
(a) RAN D este un numar aleator pe 128 biti,
(b) SRES este un raspuns pe 32 biti de la RAN D, semnat si generat folosind
cheia partajata Ki ,
(c) Kc este cheia de sesiune pentru criptare, generata tot cu ajutorul lui Ki .
4. Dupa obtinerea acestui triplet, RAN D este trimis (via BSC si BT S) ca o provocare
catre statia mobila.
5. Ca raspuns la aceasta provocare, cartela SIM a statiei mobile va genera un SRES
folosind algoritmul A3 si acel Ki pastrat stocat (SRES = A3(Ki , RAN D)).
6. Apoi, cartela SIM trimite SRES-ul calculat catre M SC, care l compara cu SRESul continut n tripletul primit de la HLR. Daca cele doua coincid, M SC deduce ca
echipamentul mobil detine un SIM cu un Ki valid si i permite accesul n retea; n
caz contrar M SC va refuza accesul.
Exista cateva aspecte importante de remarcat n procesul de autentificare:
A3 si A8 nu sunt algoritmi n sine, ci mai degraba etichete pentru algoritmi.
Functional, ei sunt functii one-way, ceea ce asigura imposibilitatea descoperirii cheii
Ki . Furnizorii de telefonie mobila sunt liberi sa foloseasca orice algoritm doresc
pentru a genera SRES din Ki si RAND. Specificatia GSM foloseste numele A3
(A8) numai pentru a se referi la un astfel de algoritm.
Cele mai multe implementari GSM combina A3 cu A8 si folosesc un singur algoritm pentru a servi ambele scopuri. Algoritmul COM P 128 este de referinta, fiind
specificat de GSM si folosit de majoritatea operatorilor. Acesta are la intrare cheia
Ki si RAN D si genereaza SRES pe 32 biti si un alt numar pe 54 de biti, caruia i
se adauga la sfarsit nca 10 biti egali cu 0, pentru a forma cheia de sesiune Kc pe
64 biti folosita pentru asigurarea confidentialitatii.
19
O implementare frecvent
a a lui A3/A8 (COM P 128)
Cheia secreta Ki , identificatorul IM SI, functiile A3 si A8 sunt stocate si implementate n cartela SIM a telefonului; Ki nu paraseste niciodata cartela SIM .
Este remarcabila relatia de ncredere ntre componentele retelei ntre care se transmit informatiile confidentiale (centrul de comutare - registrul de locatii, BSC M SC). Aceasta ncredere evidentiaza o caracteristica a retelei GSM : ncercarea de
a securiza numai partea wireless. Motivul: GSM a evoluat din reteaua de telefonie
publica P ST N si si propune sa fie cel putin la fel de sigura. Partea centrala a
P ST N este securizata prin restrictionarea accesului fizic la retea. Ideea a fost aplicata si n GSM , unde componenta centrala din arhitectura sistemului se refera la
reteaua ce se gaseste dincolo de statia de baza (BSC), considerata sigura deoarece
este controlata numai de furnizorii de telefonie mobila, iar accesul la ea se afla sub
control foarte atent.
Totusi, exista o relatie ntre componente nafara retelei centrale: BT S - BSC. Ea
ramane o cale de atacuri posibile; de altfel, GSM nu specifica nici o metoda de
securizare a acesteia.
In GSM , entitatea autentificata este cartela SIM iar nu utilizatorul n sine. Ce
se ntampla daca echipamentul ce se doreste a fi utilizat n retea este unul furat ?
Atunci cand un client a pierdut echipamentul sau cartela SIM , el are responsabilitatea de a comunica aceasta catre furnizorul sau de telefonie mobila. Cum reteaua
mentine o baza de date cu echipamentele valide prin extrapolare furnizorul de
servicii ar putea avea si o baza cu SIM -urile valide.
Un detaliu mai ascuns al procesului de autentificare n GSM este folosirea a cinci
triplete de securitate pe care MSC le obtine de la HLR. Desi unul singur este necesar pentru autentificarea unui utilizator n retea, MSC cere mai multe triplete pentru
a evita repetarea acestei actiuni de fiecare data cand utilizatorul doreste autentificarea,
mbunatatind astfel performanta sistemului prin detinerea n stoc a nca patru triplete
de rezerva pentru o folosire ulterioara.
20
5.3.5

IILOR GSM
Atacuri asupra algoritmului de autentificare prin acces

fizic la cartela SIM
Stim ca fiecare operator de telefonie mobila beneficiaza de libertatea de a-si alege un

design precis pentru algoritmii A3 si A8. Cel mai folosit este COM P 128; desi nu a
fost niciodata publicat oficial, el s-a aflat prin inginerie inversa de catre M. Briceno, I.
Goldberg si D. Wagner ([?]). Acestia au efectuat si o criptanaliza asupra lui COM P 128,
gasind cheia Ki partajata ntre telefonul mobil si retea. Avand Ki , A3 si A8, clonarea
cartelei GSM este simplu de realizat.
Securitatea ntregului sistem GSM se bazeaza pe cheia secreta Ki . Odata ce intrusul
Oscar este capabil sa extraga cheia, el poate nu numai sa asculte apelurile abonatului
urmarit, dar se poate substitui acestuia n cadrul retelei, efectuand apeluri n contul lui.
Reteaua GSM are un sistem de securitate care poate determina si nchide contul a
doua telefoane cu acelasi ID folosite simultan n locatii diferite. Daca oscar este interesat
numai sa asculte convorbirile abonatului, el poate sta pasiv, fiind invizibil pentru reteaua
GSM .
Conform celor mentionate mai sus, COM P 128 este compromis. Oscar poate observa
intrarea si iesirea n cadrul algoritmului A8 si pe baza lor poate calcula Ki (intrarea
este o provocare aleatoare trimisa din reteaua abonatului iar iesirea este un raspuns de
la SRES-ul telefonului mobil). Un element care faciliteaza calcularea Ki este trimiterea
provocarii si a SRES n clar pe calea aerului.
Fisura n procesul de autentificare a fost descoperita n 1998 ([?]) de catre un grup de
cercetatori ISAAC (Internet Security, Applications, Authentication and Cryptography)
mpreuna cu Smartacrd Developer Association; s-a constatat ca un atacator cu acces fizic
la telefonul tinta poate face o clona (duplicat identic cu originalul) si poate efectua astfel
apeluri frauduloase n contul abonatului.
O conditie absolut necesara este accesul fizic la telefonul urmarit, ceea ce indica o fisura
partiala si nu una totala.
Atacul efectuat asupra COM P 128 este bazat pe provocari alese. Atacatorii au ales
un numar de provocari speciale si au interogat SIM -ul pentru fiecare din ele. Acesta
a aplicat algoritmul pentru fiecare provocare n parte, si a returnat un raspuns; analiza
raspunsurilor primite exploatand slaba difuzie (anumite parti ale functiei de dispersie
depind numai de anumite parti ale intrarii n algoritm) a putut determina valoarea
secreta a cheii.
Implementarea acestui atac foloseste un cititor de smartcard-uri si un computer. Atacul presupune interogarea cardului de 150.000 de ori; cu un cititor de carduri capabil sa
efectueze aproximativ 6 invocari pe secunda, atacul dureaza 8 ore. Cateva calcule suplimentare sunt necesare pentru analiza raspunsurilor.
Aceasta este cea mai comuna metoda de atac, si o masura imediata mpotriva ei ar fi
folosirea pentru autentificare a unei functii de dispersie criptografica mai puternice.
21
Versiunea COM P 128 a devenit COM P 1281 si doua versiuni noi COM P 1282 si
COM P 1283 au fost propuse pentru corectarea acestor probleme de securitate. Aceste
ultime versiuni sunt algoritmi care nu au fost supusi criptanalizei publice. COM P 128 3
rezolva problema celor 10 biti nuli din cheia de sesiune Kc . Operatorii de telefonie mobila
migreaza spre acesti algoritmi noi, dar deoarece A3 si A8 sunt stocati pe SIM se impune schimbarea cartelelor abonatilor. Interesant este faptul ca, dupa ce n 1998 Briceno,
Goldberg si Wagner au publicat atacul asupro COM P 128, majoritatea furnizorilor de
telefonie mobila nu au adoptat noua varianta COM P 128 2, ci au pastrat-o pe prima,
aplicand o restrictie asupra cartelei SIM : au fixat un numar maxim de invocari asupra
cartelei (sub 150.000), dupa care aceasta se bloca.
Datorita faptului ca algoritmul se afla pe cartela SIM care este un smartcard,
orice descoperire asupra vulnerabilitatilor acestuia are repercusiuni asupra securitatii
informatiilor stocate pe SIM : IM SI si Ki .
5.3.6
Atac prin partitionare
O metoda prin care cheia Ki poate fi extrasa fara a avea acces fizic la SIM este atacul
printr-o metoda foarte eficienta, numita atac side channel.
Atacurile side channel sunt atacuri criptanalitice care gasesc relatia ntre informatia
de intrare si cea de iesire transmisa n timpul calculelor din canalele anexe; de exemplu
sincronizarea operatiilor, consumul de energie, emanatii electromagnetice etc.
S-a constatat ca prin analiza acestor caracteristici se pot obtine informatii confidentiale.
Foarte multe atacuri bazate pe canalele anexe necesita cunostinte tehnice relativ la operatiile
interne ale sistemului care are integrata partea de criptografie.
Un algoritm puternic mpotriva acestui tip de atac trebuie sa aiba semnalul pe canalele
anexe independent statistic de intrare, iesire si alte informatii sensibile. O implementare
adecvata poate asigura rezistenta n fata unui astfel de atac, dar pot ramane unele relatii
statistice dependente care pot fi atacate usor. In general, eliminarea unor astfel de atacuri
consta n limitarea producerii de informatii de tipul emanatiilor electromagnetice sau sunet
si limitarea accesului la relatiile ntre acestea.
Partitioning attacks este o clasa descoperita de cercetatorii de la IBM si folosita
pentru a ataca implementari de algoritmi care altfel ar rezista la atacurile side channel.
Cu ajutorul lor, toata cheia de 128 biti din COM P 128 poate fi extrasa de pe un SIM
folosind mai putin de 1000 invocari cu intrari aleatoare, sau 255 intrari alese, sau doar 8
intrari special alese. Prin urmare, un adversar care se afla un posesia cartelei SIM poate
extrage cheia secreta Ki n maxim un minut.
Atacul prin partitionare poate fi folosit mai ales contra algoritmilor bazati pe cautari n
tabele foarte mari. COM P 128 este un astfel de exemplu; el utilizeaza cautari n 5 tabele
de cate 512, 256, 128, 64 si repectiv 32 biti.
22
5.3.7

IILOR GSM
Atacuri wireless asupra algoritmului de autentificare
Faptul ca nu ntotdeauna este posibil sa avem acces fizic la SIM a creat posibilitatea
unui atac wireless (pe calea undelor radio). Desi aceasta abordare pare mai atractiva, ea
introduce alt tip de obstacole. In primul rand, Oscar trebuie sa poata simula BT S-ul
ca unul legitim. Aceasta nseamna ca el are nevoie de o statie de baza falsa, capabila
sa genereze un semnal suficient de puternic asa ncat sa depaseasca semnalul BT S-ului
legitim. Numai n acest caz ar fi posibila comunicarea ntre BT S si statia mobila. O
posibila rezolvare a acestei probleme ar fi lansarea atacului atunci cand semnalul statiei
legitime este foarte slab (la metrou, n lift, n zone izolate etc).
Atac wireless asupra COM P 128

Pe langa aceasta, Oscar mai trebuie sa stie IM SI-ul sau T M SI-ul cartelei SIM pe
care vrea sa o cloneze. Cand aceste resurse sunt disponibile, el va ncerca sa capteze
statia mobila. Aceasta va efectua imediat o cerere de actualizare a locatiei. Daca pretinsa
retea a provocat telefonul mobil prin T M SI, IM SI-ul poate fi aflat usor prin comanda
IDENTITY REQUEST, la care telefonul trebuie sa raspunda imediat.
In demersul pentru actualizarea locatiei, intrusul va initia un proces de autentificare.
Imediat dupa ce obtine o pereche provocare - raspuns, el lanseaza o noua procedura de
autentificare. Statia mobila trebuie sa raspunda la fiecare provocare pe care o trimite
reteaua GSM . Procedeul continua pana cand Oscar va obtine numarul de perechi necesare pentru a efectua clonarea.
5.4. CONFIDENT
IALITATE IN GSM
23
Atacul functioneaza pe orice telefon mobil din GSM , fara nici un acces anterior la
acesta (si fara a cunoaste vreun IM SI). Prin monitorizarea traficului, poate fi ales un
T M SI la ntamplare. Fiind un atac wireless, el se poate desfasura de la distanta.
Daca Oscar obtine cheia Ki (prin clonarea cartelei) si intercepteaza valoarea RAN D
prin wireless n timpul stabilirii apelului, el poate calcula cheia Kc (daca este folosit
algoritmul COM P 128 sau un alt algoritm cunoscut) si poate asculta convorbirea n timp
real.
Dupa aparitia primelor atacuri, GSM a reactionat imediat si a creat alte doua noi versiuni pentru COMP128. Daca pana atunci furnizorii foloseau n continuare COM P 128
1 limitand doar numarul de provocari, n urma aparitiei atacului ce necesita doar 8
provocari, aceasta restrictie nu mai este posibila: o cartela SIM trebuie sa raspunda
la mai mult de 8 provocari pe parcursul unei zile.
Ultima versiune a lui COM P 128 a patra este complet noua si se bazeaza pe un
algoritm ce foloseste standardul AES. Ea este implementata n retelele U M T S, ceea ce
presupune emiterea de noi cartele pentru abonatii retelei, o reactualizare a soft-ului HLR
si securitate contra clonarii cartelei SIM .
Si noul algoritm este pasibil de atacuri; chiar si partitioning attacks. Cautarea n
tabele mari este folosita frecvent n algoritmi precum DES, AES si COM P 128, care
aplicate pe dispozitive limitate cum sunt smartcard-urile raman sensibile la atacuri side
channel. Cercetatorii IBM au propus o metodologie pentru a crea rezistenta n fata unor
astfel de atacuri. Ideea consta n nlocuirea unei cautari ntr-o tabela cu o serie de cautari
n locatii complet aleatoare folosind un tabel auxiliar, ceea ce nu permite nici o scurgere de
informatii. Metoda poate fi implementata cu succes n dispozitivele cu memorie limitata
cum sunt telefoanele mobile, pentru ca foloseste foarte putina memorie RAM .
5.4
Confidentialitate n GSM
Confidentialitatea n GSM nseamna protejarea informatiei schimbate n timpul conversatiei si a informatiilor de control asociate cu stabilirea unui apel.
Contextul de securitate este cheia de sesiune Kc pe 64 biti, rezultata n urma aplicarii
algoritmului A8 sau COM P 128 daca acesta este folosit pentru a combina ambii algoritmi
A3 si A8. Aceasta cheie ofera confidentialitate pe interfata wireless BT S - M E, deci
securizeaza comunicarea ntre echipamentul mobil si statia de baza.
Reamintim ca GSM foloseste tehnica de diviziune n timp pentru a face posibila
folosirea aceluiasi canal radio pentru 8 utilizatori simultan. Fiecare utilizator va transmite
si primi informatii numai pe durata unuia din cele 8 sloturi de timp disponibile n fiecare
frame. Fiecare frame dureaza 4.6 milisecunde si este indentificat printr-un numar asociat.
O conversatie GSM foloseste 2 frame-uri: unul mergand de la statia de baza spre statia
mobila si celalalt parcurgand aceeasi cale n sens invers. Fiecare din aceste frame-uri
contine 114 biti de informatie.
24

IILOR GSM
Deci la fiecare 4.6 milisecunde, statia mobila primeste 114 biti de informatie de la statia
de baza si trimite alti 114 biti de informatie catre aceasta. Acesti 228 biti au nevoie de
protectie mpotriva interceptarii.
Algoritmul folosit pentru criptarea pachetelor de informatii transmise wireless este A5.
Acesta este un algoritm de criptare specificat de standardul GSM (spre deosebire de A3
si A8 care sunt doar niste nume) pentru a ncuraja roaming-ul4 ntre retelele de telefonie
oferite de diversi operatori. Alegerea lui A3 si A8 este la libera alegere a operatorului,
datorita faptului ca procesul de autentificare se desfasoara ntre SIM si registrul de locatii
al utilizatorilor (HLR) aferent furnizorului de telefonie mobila. Pe de alta parte, procesul
de criptare trebuie sa se desfasoare ntre statia de baza (BT S) si statia mobila (M E)
(aceasta fiind prima ruta pe care circula pachetul de date ce contine informatiile trimise
de utilizator); deci informatia trimisa trebuie sa fie deja criptata.
Algoritmul A5 este un sistem de criptare fluid ([?]) care genereaza o cheie unica pentru fiecare pachet de date folosind la intrare cheia de sesiune Kc pe 64 biti si numarul
de secventa asociat frame-ului respectiv. Deoarece numarul de secventa al unui frame
este usor de aflat, confidentialitatea datelor transmise se bazeaza numai pe mentinerea
secretului cheii de sesiune Kc .
Cheia de sesiune poate fi schimbata la intervale regulate sau dupa cum considera furnizorul
de servicii de telefonie.
Dupa ce a fost obtinuta cheia de sesiune, criptarea va ncepe imediat ce reteaua GSM
trimite echipamentului mobil o cerere de criptare. Spre deosebire de A3 si A8 care sunt
implementati n SIM , algoritmul A5 se afla implementat hardware direct n echipamentul mobil.
In prezent exista trei versiuni dezvoltate pentru A5:
1. Prima, numita A5/1, este folosita n tarile membre ale CEP T (organizatie care
cuprinde 48 tari din Europa) si n Statele Unite. A fost lansata n 1987 si ofera cel
mai nalt nivel de criptare wireless. Desi oficial foloseste 64 biti, practic cheia nu
depaseste 54 biti, ultimii 10 biti fiind setati pe zero.
2. Al doilea algoritm, A5/2, dezvoltat n 1989, este mai slab decat A5/1 si este folosit
preponderent n Asia.
Schita celor doi algoritmi a fost tinuta secret, dar a fost descoperita prin inginerie
inversa de catre Briceno ([?]) n 1999 si este disponibila pe Internet.
3. In 2002 apare versiunea A5/3. Ca securitate, el este mai puternic decat primele
doua versiuni, dar este folosit numai n retelele U M T S pentru generatia a treia
(3G). Spre deosebire de versiunile precedente, schema lui A5/3 a fost facuta publica,
constructia lui fiind bazata pe sistemtul de criptare bloc KASUMI.
4
Prin roaming se ntelege extinderea conectivitatii serviciilor n locatii diferite de locatiile de baza n
care acestea au fost nregistrate.
5.4. CONFIDENT
IALITATE IN GSM
25
Inafara acestora mai exista o versiune ieftina si deci mai putin complexa numita A5/0,
care nu presupune nici o criptare.
5.4.1
Algoritmul A5/1
Algoritmul fluid A5/1 accepta la intrare o cheie de sesiune Kc pe 64 biti si numarul de

frame f pe 22 de biti care este public (fiecare frame are asociat un numar de frame,
frame-urile consecutive avand asociate numere consecutive).
Dupa cum am vazut, comunicarea n GSM se realizeaza prin frame-uri, unde un
frame este transmis la fiecare 4.6 milisecunde. In fiecare frame, A5/1 este initializat cu
cheia de sesiune si cu numarul de frame. Cheia fluida obtinuta la iesire ocupa 228 biti
si este mpartita n doua jumatati: prima parte (114 biti) este folosita pentru criptarea
datelor transmise de la retea catre telefonul mobil, iar a doua jumatate este folosita pentru
criptarea datelor de la telefonul mobil catre retea.
Criptarea este realizata prin aplicarea operatiei XOR asupra datelor transmise si a
jumatatii corespunzatoare din cheia fluida generata.
Trebuie mentionat ca statia de baza aplica acelasi algoritm A5/1; deci fiecare din cele
doua parti care comunica va folosi prima jumatate din cheia generata pentru a cripta
datele pe care le transmite, iar a doua jumatate pentru a decripta (decriptarea se face
similar cu criptarea, prin aplicarea operatiei XOR) datele primite.
A5/1 are o stare interna pe 64 biti si este construit din trei circuite LF SR ([?]) de
lungime 19, 22 si respectiv 23 biti fiecare, notate R1, R2 si R3. La fiecare tact (clocking)
fiecare registru calculeaza functia de ntoarcere, dupa care este deplasat la dreapta cu o
pozitie (cel mai din dreapta bit devine bit de iesire) iar feedback-ul calculat este stocat
n cea mai din stanga pozitie din registru.
A5/1 este initializat cu Kc si f n trei pasi (Kc [i] reprezinta al i-lea bit din Kc , iar f [i]
al i-lea bit din f ):
1. Seteaza R1 = R2 = R3 = 0.
2. For i = 0 to 63 do
(a) Aplica un tact pentru toti registrii
(b) R1[0] R1[0] Kc [i];
R2[0] R2[0] Kc [i];
R3[0] R3[0] Kc [i].
3. For i = 0 to 21 do
(a) Aplica un tact pentru toti registrii
(b) R1[0] R1[0] f [i];
R2[0] R2[0] f [i];
R3[0] R3[0] f [i].
26

IILOR GSM
Structura intern
a a algoritmului A5/1
Generarea cheii fluide se efectueaza n 328 tacti, la fiecare tact producandu-se un bit
de iesire. La fiecare tact, iesirea este un XOR ntre cei mai din dreapta biti ai celor trei
registri. Cheia fluida de 228 biti este generata astfel:
1. Executa initializarea cu cheia Kc si numarul de frame f .
2. Executa A5/1 pentru 100 tacti, fara a pastra iesirea.
3. Executa A5/1 pentru 228 tacti, bitii rezultati formand cheia fluida.
Mecanismul de calcul a bitului de iesire la fiecare tact foloseste regula majoritatii:
fiecare registru are o pozitie aproape de mijloc (locatiile R1[8], R2[10] si respectiv
R3[10]) marcata special. La fiecare tact se calculeaza valoarea majoritara din aceste
trei pozitii, iar apoi, fiecare registru avanseaza o pozitie daca si numai daca celula sa
marcata (un D flip-flop) este identica cu valoarea majoritara calculata.
Deci, la fiecare tact se vor deplasa cel putin doi registri; statistic, fiecare registru are
probabilitatea 1/4 de a ramane nemiscat si probabilitatea 3/4 de a se deplasa ([?]).
5.4.2
Algoritmul A5/2
A5/2 este construit pornind de la arhitectura lui A5/1: se folosesc patru registri (de
lungimi 19, 22, 23 si 17 biti), iar functiile de ntoarcere ale primilor trei sunt identice ca
pentru A5/1.
Algoritmul accepta la intrare aceeasi parametri ca si A5/1: o cheie Kc pe 64 biti si o
valoare publica f pe 22 biti, derivata din numarul de frame (cunoscut public). Valoarea
lui f este obtinuta din numarul asociat frame-ului T DM A:
5.4. CONFIDENT
IALITATE IN GSM
27
Obtinerea valorii f
unde T 1 este catul mpartirii numarului de frame la 51 26 = 1326, T 2 este restul
mpartirii numarului de frame la 26 si T 3 este restul mpartirii numarului de frame la 51.
A5/2 este initializat cu Kc si f n patru pasi dupa cum urmeaza:
1. Seteaza R1 = R2 = R3 = R4 = 0.
2. For i = 0 to 63 do
(a) Aplica un tact pentru cei patru registri.
(b) R1[0] R1[0] Kc [i];
R3[0] R3[0] Kc [i];
R2[0] R2[0] Kc [i];

R4[0] R4[0] Kc [i].
3. For i = 0 to 21 do
(a) Aplica un tact pentru primii trei registri.
(b) R1[0] R1[0] f [i];
R3[0] R3[0] f [i];
4. Seteaza bitii R1[15] 1,
R2[0] R2[0] f [i];

R4[0] R4[0] f [i].
R2[16] 1,
R3[18] 1,
R4[10] 1.
28

IILOR GSM
Si n acest algoritm, la fiecare tact avanseaza cel putin doi registri, n functie de valorile
a trei biti din R4. Apoi avanseaza R4 un tact.
La nceputul fiecarui tact se calculeaza valoarea
x = maj{R4[3], R4[7], R4[10]}
Apoi, R1 avanseaza daca x = R4[10], R2 avanseaza daca x = R4[3] si R3 avanseaza daca
x = R4[7].
Procesul de generare a cheii poate fi sumarizat astfel:
1. Executa initializarea cu cheia Kc si valoarea f .
2. Executa A5/2 pentru 99 tacti, ignorand iesirea.
3. Executa A5/2 pentru 228 tacti, iar bitii rezultati formeaza cheia fluida.
Procedura de criptare este identica cu cea a algoritmului A5/1.
5.4.3
Probleme legate de confidentialitatea GSM
De-a lungul timpului s-au descoperit o serie de slabiciuni ale arhitecturii de criptare a
sistemului GSM , slabiciuni care pot fi exploatate usor.
Partea de criptare a fost specificata ca o caracteristica optionala a retelei. Prin
urmare, operatorul de retea poate alege daca doreste folosirea criptarii sau nu. Unele
telefoane mobile cum sunt cele din seria Siemens S afiseaza pe ecran un simbol de
tipul *!* daca optiunea de criptare este dezactivata ([?]).
Criptarea este utilizata numai pentru securizarea interfetei dintre statia mobila si
BT S. Aceasta este singura legatura protejata criptografic, ceea ce expune restul
retelei la atacuri. Una dintre cele mai expuse interfete neprotejata prin criptare este
BT S - BSC. Cum aceasta legatura nu face parte din reteaua de baza si cum de
obicei este o legatura fara fir (bazata pe microunde, pe satelit s.a.m.d.), ea devine o
tinta atragatoare, interceptarea de apeluri fiind posibila cu un echipament adecvat.
Chiar si algoritmul folosit pentru criptarea legaturii statie mobila - BT S nu este
sigur, datorita puterii tot mai mare a hardware-lui. Folosind un simplu atac prin
forta bruta, securitatea algoritmului poate fi compromisa n cateva ore.
Principala problema este lungimea mica a cheii de sesiune Kc : doar 54 biti efectivi
(plus alti 10 biti setati pe zero). Puterea hardware permite n prezent nregistrea
pachetelor transmise ntre statia mobila si BT S si decriptarea lor la un moment
ulterior.
5.5. ATACURI ACTIVE ASUPRA RET

ELELOR GSM
29
GSM foloseste o procedura de autentificare ntr-un singur sens: numai reteaua are
dreptul sa verifice identitatea abonatului (mai exact, a statiei mobile). In schimb,
statia mobila nu poate verifica autenticitatea retelei. Aceasta permite punerea n
practica a unui atac n care BT S este falsificat.
Poate una dintre cele mai vizibile vulnerabilitati ale sistemului GSM este faptul ca
nu asigura protectia integritatii pentru informatiile transmise. Securitatea GSM
vorbeste despre autentificare si confidentialitate dar nu mentioneaza absolut nimic
despre integritate. Absenta unui mecanism care sa o asigure nseamna ca la receptie
nu se poate verifica daca mesajul primit a fost modificat sau nu. Se lasa astfel cale
libera pentru numeroase atacuri de tipul man-in-the-middle.
Algoritmii de criptare GSM nu sunt publicati n standardul GSM , ceea ce nseamna
ca nu sunt disponibili pentru analiza comunitatii de securitate. Acest lucru a fost criticat
pentru ca ncalca principiul lui Kerckhoffs (securitatea sistemului rezida numai n cheie).
Se considera indicat ca algoritmul de criptare sa fie analizat public, asa ncat eventualele
fisuri existente sa fie descoperite si publicate.
5.5
Atacuri active asupra retelelor GSM
Sa trecem n revista cateva atacuri bazate pe faliile de securitate existente n protocolul

de stabilire a apelului (prezentat n prima parte a capitolului); sunt atacuri active, deci
este necesar ca Oscar sa transmita (cu asumarea riscului de a fi detectat).
Faliile din protocol care pot fi exploatate sunt urmatoarele:
1. Autentificarea poate fi executata numai ntre mobil si retea, la nceputul apelului,
fiind numai la dispozitia retelei. Statia mobila nu poate solicita autentificarea. Daca
nu este efectuata nici o autentificare, Kc ramane cel din conversatia anterioara; n
acest caz, reteaua poate autentifica telefonul prin faptul ca foloseste acelasi Kc
pentru criptare.
2. Reteaua alege algoritmul de criptare (sau poate alege sa nu cripteze deloc). Telefonul
doar raporteaza lista de algoritmi de criptare pe care i suporta (printr-un mesaj
numit class-mark).
3. Mesajul class-mark nu este protejat si poate fi modificat de Oscar.
4. Faptul ca doar telefonul se autentifica la retea permite existenta statiilor de baza
false.
5. Nu exista o separare a cheilor: protocolul de stabilire a cheii este independent de
algoritmul folosit cheia Kc depinde numai de RAN D (ales de retea), indiferent
daca pentru criptare se foloseste A5/1, A5/2 sau A5/3.
30

IILOR GSM
6. Aceeasi valoare RAN D poate fi folosita ori de cate ori doreste reteaua.
5.5.1
Atacul de tip class-mark
In cel mai simplu atac asupra protocolului, Oscar schimba informatia din mesajul classmark pe care telefonul l trimite retelei la nceputul conversatiei; astfel, reteaua crede ca
telefonul suporta numai A5/2. Desi poae reteaua prefera sa lucreze cu A5/1, ea trebuie
sa foloseasca numai A5/2 sau A5/0 (fara criptare).
Intrusul are mai multe moduri de a modifica mesajul class-mark. El poate trimite
simultan cu utilizatorul un mesaj alternativ class-mark, folosind nsa un semnal radio
mult mai puternic; astfel, la BT S semnalul lui Oscar depaseste semnalul mesajului original.
Sau, Oscar poate efectua un atac de tipul man-in-the-middle (se interpune ntre statia
mobila si BT S folosind o statie mobila falsa si o statie de baza falsa), asa ncat toate
mesajele sa treaca pe la el. Apoi poate pur si simplu nlocui un mesaj class-mark cu un
alt mesaj.
5.5.2
Recuperarea cheii Kc dintr-o conversatie anterioar

a
Este un atac care recupereaza cheia de criptare a unei conversatii criptate nregistrata
n trecut. Ea ar putea fi valida pentru convorbiri ulterioare daca reteaua alege sa nu
efectueaze protocolul de stabilire a unei noi chei.
Calea cea mai simpla de a decripta conversatii nregistrate este cand Oscar are acces la
cardul SIM al utilizatorului. Atunci el l poate alimenta cu RAN D-ul folosit anterior n
conversatie. SIM -ul calculeaza si ntoarce spre intrus valoarea lui Kc (atacul este posibil
pentru ca GSM permite refolosirea valorii RAN D).
Singura problema este obtinerea accesului fizic la cardul SIM al utilizatorului. Exista
un atac man-in-the-middle care simuleaza un astfel de acces, prin folosirea unei statii de
baza false.
1. In faza de pregatire a atacului, Oscar nregistreaza conversatii criptate ale victimei.
2. La momentul atacului, el initiaza o sesiune wireless cu telefonul victimei, prin statia
de baza falsa, iar apoi o procedura de autentificare, folosind valoarea RAN D din
timpul conversatiei criptate. Telefonul va returna un SRES cu aceeasi valoare ca
SRES-ul conversatiei nregistrate.
3. Oscar cere telefonului sa nceapa criptarea cu A5/2.
Aparatul trimite o certificare (criptata cu A5/2) cu acelasi Kc din conversatia
nregistrata (Kc depinde de RAN D, care este identic cu cel din conversatia nregistrata).
5.5. ATACURI ACTIVE ASUPRA RET

ELELOR GSM
31
4. In final, intrusul poate folosi un atac cu text criptat pentru A5/2 (un astfel de
atac este prezentat mai tarziu), care poate fi repetat de mai multe ori pentru toate
valorile RAN D existente n nregistrare.
Atacul prezentat lasa urme, pentru ca telefonul retine ultimul Kc pentru a-l folosi n
urmatoarea conversatie.
Oscar poate aduce telefonul la starea anterioara atacului, prin efectuarea unei noi
proceduri de autentificare folosind ultima valoare (legitima) RAN D emisa telefonului.
Sau, Oscar poate recupera valoarea curenta Kc stocata pe telefon prin efectuarea atacului,
dar omitand procedura de autentificare.
El poate folosi cheia Kc pentru a patrunde n conversatii ulterioare, pana cand reteaua
initiaza o noua procedura de autentificare.
5.5.3
Atac de tipul man-in-the-middle
Oscar poate intercepta conversatiile n timp real prin lansarea unui atac man-in-themiddle.
Pentru aceasta, el foloseste o statie de baza falsa pentru a comunica cu telefonul tinta,
pretinzand retelei ca este statia mobila .
1. Cand reteaua initiaza protocolul de autentificare, ea trimite lui Oscar o cerere de
autentificare, pe care acesta sub chipul statiei de baza o trimite mai departe
utilizatorului.
2. Utilizatorul calculeaza SRES pe care l returneaza lui Oscar, care l va retine
temporar, fara a-l retrimite retelei.
3. Oscar cere telefonului sa nceapa criptarea folosind A5/2.
Aceasta cerere pare legitima telefonului, ntrucat intrusul joaca rolul retelei. Telefonul ncepe criptarea folosind A5/2 si trimite o certificare (acknowledgment numit
CIP HM ODCOM - Cipher Mode Complete, care confirma ca a nceput criptarea)
criptata.
4. Oscar foloseste atacul cu text criptat din sectiunea ?? pentru a gasi Kc (n mai
putin de o secunda).
5. Abia acum Oscar trimite valoarea SRES spre reteaua reala.
6. Acum Oscar este autentificat n retea, care i cere sa nceapa criptarea folosind
A5/1.
Intrusul cunoaste deja cheia Kc si poate trimite raspunsul criptat cu A5/1.
32

IILOR GSM
Atac man-in-the-middle pentru A5/2

Din acest moment, reteaua l vede pe Oscar ca statie mobila, iar Oscar poate continua
conversatia, sau o poate ncredinta telefonului.
5.6. CRIPTANALIZA ALGORITMULUI A5/2
5.6
33
Criptanaliza algoritmului A5/2
5.6.1
Primul atac cu text clar cunoscut
Prima criptanaliza a algoritmului A5/2 a fost realizata n august 1999 de cercetatorii

americani Goldberg, Wagner si Green, fiind un atac cu text clar cunoscut. Atacul necesita
doua frame-uri de text criptat, al caror text clar corespunzator are o diferenta XOR
cunoscuta.
Observatia 5.1. Datorita faptului ca R4[10] este setat pe valoarea 1 n timpul initializarii,
R4 va avea aceeasi valoare dupa initializare indiferent dac
a bitul f [10] este zero sau unu.
Initial, Oscar ncearca sa gaseasca doua frame-uri diferite care au aceeasi valoare f
pana la f [10]. Dupa etapa de initializare, cele doua frame-uri vor avea aceeasi valoare
pentru R4. Avand n vedere constructia lui f din numarul de frame, practic se cauta doua
frame-uri aflate la distanta 26 51 = 1326 frame-uri T DM A (aproximativ 6 secunde) de
primul frame cu f [10] = 0.
Altfel, intrusul trebuie sa mai astepte 6 secunde pentru un frame cu f [10] = 0.
Prin urmare, Oscar este obligat sa astepte ntre 6 si 12 secunde pentru a obtine datele
necesare pentru atac.
Atacul se desfasoara astfel:
1. Fie f1 si f2 valorile f pentru cele doua frame-uri iar k1 si k2 cheile fluide corespunzatoare. Notam valoarea registrilor R1 . . . R4 din primul frame, imediat dupa
initializare cu R11 . . . R41 si similar, n al doilea frame R12 . . . R42 .
Alegerea lui f1 si f2 conform observatiilor de mai sus asigura R41 = R42 . Ceilalti
registri nu sunt egali, dar datorita liniaritatii n bitii lui f1 si f2 a procesului de
initializare, diferenta dintre R11 , R21 , R31 si R12 , R22 , R32 este liniara n diferenta
dintre f1 si f2 .
Deci, se poate scrie R11 = R12 d1 , R21 = R22 d2 , R31 = R32 d3 cu d1 , d2 , d3
constante.
2. Fiind data valoarea lui R4, diferenta k1 k2 este liniara n R11 , R21 , R31 . Deci,
fiind dat R4, se cunoaste comportarea tuturor registrilor.
Fie l1 , l2 si l3 valori reprezentand cati tacti au avansat registrii R1, R2 si R3 pana
la sfarsitul ciclului i.
Valorile celor trei registri la ncheierea ciclului i din primul frame sunt L1l1 R11 ,
L2l2 R22 si L3l3 R33 cu L1, L2 si L3 matrici care reprezinta un tact pentru registrul
corespunzator.
Analog, pentru frame-ul al doilea, valorile celor trei registri la sfarsitul ciclului i
sunt L1l1 (R11 d1 ), L2l2 (R22 d2 ) si L3l3 (R33 d3 ).
34

IILOR GSM
Notand cu g1 (R1) g2 (R2) g3 (R3) bitul de iesire din A5/2, se observa ca functiile
g1 (), g2 () si g3 () sunt patratice (obtinute prin aplicarea functiei maj).
3. Goldberg, Wagner si Green au mai observat ca XOR-ul dintre bitii de iesire poate
fi exprimat ca functie liniara ntre bitii starii interne din primul frame.
XOR-ul dintre bitii de iesire (la ciclul i) ai celor doua frame - uri este:
g1 (L1l1 R11 ) g1 (L1l1 R11 d1 ) g2 (L2l2 R21 ) g2 (L2l2 R21 d2 )
g3 (L3l3 R31 ) g3 (L3l3 R31 d3 ) = gd1 (L1l1 R11 ) gd2 (L2l2 R21 ) gd3 (L3l3 R31 )
unde gd1 (), gd2 (), gd1 () se pot defini ca functii liniare.
Deci XOR-ul de iesire este liniar n R11 , R22 , R33 . Mai ramane de vazut daca
functiile gd1 (), gd2 (), gd1 () sunt liniare.
Mai general, ramane de aratat ca pentru o functie patratica g(x1 , ..., xn ) si
d = d1 , ..., dn cu xi , di {0, 1}, functia
gd = g(x1 , ..., xn ) g(x1 d1 , x2 d2 , ..., xn dn )
este liniara n x1 , ..., xn .
4. Deoarece g este patratica si xi xi = xi , g poate fi scris astfel:
g(x1 , ...xn ) =
ai,j xi xj a0,0
1i,jn
unde ai,j {0, 1} sunt fixate pentru un anumit g.

Deci,
gd =
ai,j (xi xj (xi di ) (xj dj )) =
1i,jn
X
1i,jn
ai,j (xi xj xi xj xi dj di xj di dj )) =
ai,j (xi dj di xj di dj ))
1i,jn
Fiind date d1 , ..., dn , ultima expresie este liniara n x1 , ..., xn .

Prin urmare, stiind R4 si k1 k2 , starile interne R11 , R21 si R31 pot fi aflate prin
rezolvarea unui sistem de ecuatii liniare.
Kc poate fi obtinut din starea interna initiala si f1 prin inversarea pasilor de initializare din A5/2.
Cat despre R4, acesta nu se da si deci Oscar trebuie sa testeze pe rand toate cele 216
valori posibile pentru R4 (lungimea lui este de 17 biti, dar R4[10] este setat pe 1)
si pentru fiecare valoare sa rezolve sistemul de ecuatii liniare rezultat, pana gaseste
o solutie consistenta.
35
O solutie mai rapida este posibila daca se filtreaza valorile corecte pentru R4.
Starea interna initiala a lui R1, R2 si R3 este pe 61 biti (trei biti din R1, R2, R3 sunt
setati pe 1).
Prin urmare, sunt necesari 61 biti din k1 k2 pentru a construi Kc , n timp ce k1 k2 are
o lungime de 114 biti.
Este deci posibila construirea unui sistem liniar unic determinat, a carui solutie este
starea interna. Cele 114 61 = 53 ecuatii dependente se reduc prin eliminare gaussiana.
Ele depind de valoarea lui R4; deci, pentru fiecare valoare a lui R4 se pot scrie 53 ecuatii
VR4 (k1 k2 ) = 0 unde VR4 este o matrice de 53 114 biti iar 0 este un vector cu 53
valori nule.
Redundanta se foloseste pentru filtrarea valorilor gresite pentru care VR4 (k1 k2 ) 6= 0.
O implementare directa a atacului pe un calculator de 2GHz pe 32 biti n care toate
matricile posibile VR4 sunt prencarcate, consuma aproximativ 15 MBs de memorie RAM
si necesita cateva milisecunde CP U pentru filtrarea valorilor corecte pentru R4.
Odata ce s-a aflat R4, se pot rezolva ecuatiile liniare pentru valoarea sa, obtinand
astfel valorile pentru R11 , R21 si R31 .
Stocarea acestor sisteme de ecuatii dupa eliminarea Gauss necesita cam 60 MBs de
memorie.
Timpul de preprocesare necesar (pentru calculul ecuatiilor si al matricilor VR4 ) pe un
P C este de cateva minute.
Ramane o problema a acestui atac obtinerea acelor frame-uri care se afla exact la
distanta ceruta, cunoscand si XOR-ul dintre cheile fluide calculate pentru criptarea lor.
Atacul Petrovici - Fuster - Sabater
Un alt atac cu text clar cunoscut este propus de Petrovic si Fuster-Sabater ([?]) n anul
2000.
El necesita patru frame-uri (nu neaparat separate de o anumita distanta) din secventa
de iesire pentru reconstructia urmatorilor biti de iesire. Desi atacul nu descopera starea
interna a lui A5/2, este totusi capabil sa recupereze restul conversatiei.
Atacul mizeaza pe reinitializarile dese care au loc n cadrul convorbirii (pentru fiecare
frame transmis) si distributia proasta a valorilor speciale marcate din LF SR pentru a
reconstrui relatiile liniare dintre bitii de iesire.
Dupa ce este realizata initializarea algoritmului si cele 100 de cicluri care se ignora, se
scrie sistemul de ecuatii neliniare avand ca necunoscute starile registrilor care au avansat
un tact. Pentru fiecare tact cu deplasare al algoritmului, sistemului i se adauga o noua
ecuatie. Probabilitatea ca rangul matricii sa fie apropiat de numarul de variabile este
destul de mica. Dar chiar si asa este posibila stabilirea relatiilor liniare ntre bitii
necunoscuti care urmeaza a fi aflati si multimea de biti cunoscuti.
36

IILOR GSM
Atacul propus se bazeaza pe analiza sistemului de ecuatii asociat fiecarei stari initiale
a registrului R4.
Dupa primul set de operatii din partea de initializare (cel n care se aplica XOR ntre
primii biti din registre si cheia secreta), se poate scrie un sistem de ecuatii neliniare avand
ca variabile starile interne ale primilor trei registri la acel moment. Aceste variabile
se noteaza x1 , .., x64 unde primele 19 variabile corespund starii din R1, urmatoarele 22
corespund starii din R2 iar ultimele 23 corespund starii din R3. Ecuatiile obtinute sunt
patratice. Numarul maxim de variabile din sistemul liniarizat asociat este:
n = 64 +
19
2
22
2
23
2
Sistemul de ecuatii obtinut este liniarizat prin nlocuirea termenilor neliniari cu noi
variabile compuse. Oscar poate folosi ecuatiile liniar dependente pentru a reconstrui bitii
necunoscuti de la iesire care apar la foarte scurt timp dupa bitii cunoscuti.
5.6.2
Atacurile Elad Barkan, Eli Biham si Nathan Keller
Atac neoptimizat cu text clar

Un atac cu text clar cunoscut care mbunatateste primul atac descris anterior a fost
realizat n 2003 de o echipa de cercetatori din Israel: Elad Barkan, Eli Biham si Nathan
Keller ([?]). Ca si atacul Petrovici - Fuster - Sabater, el necesita patru frame-uri; dar n
final recupereaza starea interna data de R1, R2, R3, R4 si gaseste si cheia de sesiune.
Atacul determina valoarea lui R4 si scrie fiecare bit de iesire ca un termen patratic
depinzand de R1, R2 si R3. Autorii descriu o metoda de reprezentare a fiecarui bit de
iesire ca un termen patratic n starile R1, R2, R3 din primul frame.
Avand astfel bitii de iesire din patru frame-uri, ei construiesc un sistem de ecuatii patratice
pe care l rezolva prin liniarizare, recuperand valorile initiale pentru R1, R2 si R3.
In continuare vom detalia modul de construire a sistemului, precum si rezolvarea lui.
Fie k1 , k2 , k3 , k4 cheile fluide din cele patru frame-uri f1 , f2 , f3 , f4 . Fiecare kj reprezinta
iesirea unui frame complet, deci are 114 biti lungime. Starea initiala interna din registrul
Ri din frame-ul fj (dupa liniarizare, dar nainte de cei 99 tacti) se noteaza cu Rij .
Fiecare bit de iesire poate fi scris ca o functie patratica depinzand de starea initiala
interna a registrilor R1, R2 si R3. Scopul urmarit este construirea unui sistem de ecuatii
patratice care exprima egalitatea ntre termenii patratici pentru fiecare bit de iesire, si
valoarea actuala a bitului din cheia fluida cunoscuta. Solutia unui astfel de sistem ar face
cunoscuta starea interna initiala.
Impedimentul principal este faptul ca rezolvarea unui sistem de ecuatii patratice este o
problema N P - completa. Totusi, exista facilitati cand sistemul este supradefinit (sunt
61 variabile si 114 ecuatii), iar complexitatea lui scade considerabil pe masura ce ecartul
dintre numarul de ecuatii si numarul de variabile creste. Prin urmare, vom adauga ecuatii
37
din alte frame-uri, cu conditia ca ele sa fie definite peste aceleasi variabile: valorile initiale
ale lui R1, R2, R3 din frame-ul f1 .
Odata combinate ecuatiile din patru frame-uri, sistemul se rezolva prin liniarizare. Se
construiesc astfel de sisteme pentru fiecare din cele 216 valori posibile pentru R41 si se
rezolva pana se gaseste o solutie consistenta.
Solutia este starea initiala interna a frame-ului f1 .
Din modul de calcul, functia majoritara opereaza pe bitii aceluiasi registru. Deci,
termenii patratici constau din perechi de variabile din acelasi registru. R1 contribuie cu 18
21 20
17 18
= 153 produse ale lor, R2 contribuie cu 21+
= 21+210
variabile si toate cele
2
2
22 21
variabile, iar R3 contribuie cu 22+
= 22+231 variabile; deci dupa liniarizare rezulta
2
655 variabile. La acestea se adauga constanta 1 care reprezinta partea afina a ecuatiilor.
Multimea acestor 656 variabile pentru frame-ul fi se noteaza cu Si .
Ramane de aratat cum se pot descrie bitii de iesire din frame-urile f2 , f3 , f4 drept
combinatii liniare de variabile din multimea S1 . Se presupune cunoscuta valoarea lui R41
si faptul ca initializarea este liniara n valoarea publica f .
Cum R11 , R21 , R31 sunt necunoscute, stim numai XOR-ul dintre R11 , R21 , R31 si
respectiv R12 , R22 , R32 .
Fiecare valoare din S2 va fi translatata n S1 astfel:
Fie 1 valoarea concatenata a variabilelor liniare din S1 si g o functie patratica astfel
ncat S = g(1 ). Stim ca valoarea concatenata a variabilelor liniare din S2 poate fi scrisa
ca 2 = 1 d1,2 si deci S2 = g(2 ).
La fel ca n primul atac, XOR-ul dintre S2 si S1 este liniar n bitii lui 1 , deci S2 poate
fi scris n termeni liniari n variabilele lui S1 .
Se poate construi deci un sistem de ecuatii patratice folosind cheile fluide din cele patru
frame-uri, cu variabile luate numai din S1 . Se va crea un sistem de ecuatii de forma
SR41 S1 = k unde SR41 este matricea sistemului de dimensiune 456 656, iar k =
k1 kk2 kk3 kk4 (de 456 biti).
Odata obtinute 656 ecuatii liniar independente, sistemul poate fi rezolvat prin eliminare gaussiana. Se observa nsa ca practic este dificil sa colectionam 656 ecuatii
liniar independente (datorita frecventelor initializari ale algoritmului A5/2 odata la
fiecare 228 biti). Nu trebuie aflate nsa toate variabilele, ci numai cele liniare. Autorii
au ajuns experimental la concluzia ca aproximativ 450 ecuatii liniar independente sunt
suficiente pentru a determina valorile variabilelor liniare originale din S1 .
De asemenea se mai pot obtine 13 ecuatii liniare aditionale, datorita cunoasterii lui
R41 si a numarului de frame. Fie R12341 = R11 kR21 kR31 kR41 un vector de 77 biti
(neluand n considerare cei patru biti setati pe 1 n cadrul procedurii de initializare).
Cum R12341 este liniar n bitii lui Kc si f1 , putem scrie:
R12341 = NK Kc Nf f1
(1)
unde NK este o matrice de 77 64 si Nf este o matrice de 77 22 care reprezinta
38

IILOR GSM
componenta de initializare din A5/2. Spatiul liniar generat de coloanele lui NK este de
dimensiune 64, dar cum fiecare vector are 77 de biti, raman 13 ecuatii liniare n NK Kc .
Fie HK matricea acestor ecuatii, de dimensiune 13 77:
H K Nk = 0
unde 0 este matricea nula de dimensiuni 13 64.
Prin multiplicarea relatiei (1) la stanga cu HK se obtine:
HK R12341 = HK NK Kc HK Nf f1 = HK Nf f1
R
L
astfel ncat:
si HK
HK se poate mparti n HK
L
R
HK R12341 = HK
R1231 HK
R41
R
L
R
L
de dimensiune 13 16 si R1231 =
de dimensiune 13 61, HK
, cu HK
kHK
unde HK = HK
R11 kR21 kR31 .
Rezulta:
L
R
HK Nf f1 = HK R12341 = HK
R1231 HK
R41
care poate fi scris:

L
R
HK
R1231 = HK Nf f1 HK
R41 .
Deci, pe baza lui R41 si a lui f1 se pot obtine 13 ecuatii liniare peste bitii din registrii
R1, R2, R3.
Recapituland, atacul consta n:
1. Se ncearca toate cele 216 valori;
2. Pentru fiecare valoare se rezolva sistemul liniarizat de ecuatii care descriu bitii de
iesire pentru patru frame-uri.
3. Solutia obtinuta plus valoarea lui R41 reprezinta o sugestie pentru starea interna.
Majoritatea valorilor lui R41 pot fi identificate usor datorita inconsistentelor aparute
la eliminarea gaussiana.
Complexitatea timp a atacului se poate calcula astfel: sunt 216 valori aleatoare pentru
bitii din R41 . Pentru fiecare valoare se rezolva un sistem liniar binar de 656 variabile,
care presupune 6563 228 operatii XOR.
Deci, complexitatea totala este de aproximativ 244 operatii XOR.
Autorii spun ca implementarea algoritmului pe un sistem Linux 800 MHz Pentium
III gaseste starea interna n aproximativ 40 de minute (estimare 2003) si necesita putina
memorie (sistemul liniarizat ocupa aproximativ 54 KB).
39
Un atac optimizat asupra lui A5/2

Dupa publicarea atacului anterior, aceeasi autori revin cu o versiune optimizata, care
gaseste Kc n cateva milisecunde, folosind tabele precalculate si stocate n memorie.
Ideea de baza este urmatoarea: ntr-o faza de precalcul, pentru fiecare valoare R41
se determina dependentele care apar n timpul eliminarii gaussiene pentru sistemul de
ecuatii. Apoi n faza de atac se filtreaza valorile corecte pentru R41 prin aplicarea
verificarilor de consistenta pe cheile fluide cunoscute.
Deci, ntr-o prima faza de precalcul, se stabilesc n avans sistemele de ecuatii pentru
toate valorile R41 . Tot n avans se rezolva fiecare astfel de sistem; n particular, fiind dat
un sistem de ecuatii SR41 S1 = k, se calculeaza o matrice TR41 pentru care TR41 SR41
este rezultatul eliminarii Gauss a lui SR41 . Cum SR41 nu depinde numai de R41 dar si de
XOR-ul dintre valorile f ale frame-urilor, trebuie efectuat un precalcul pentru mai multe
XOR-uri de valori f . Similar atacului anterior, XOR-ul ntre valorile f este folosit la
translatarea multimilor de variabile S1 , S2 , S3 n S1 .
Fiind necesara cunoasterea n avans a acestor diferente XOR, se efectueaza precalcule
pentru diverse valori posibile pentru diferente, iar rezultatele se pastreaza n tabele. Apoi,
n faza de atac, se folosesc tabelele asociate valorilor f din frame-uri.
Daca se dau valori pentru cheile fluide corespunzatoare unui frame avand valoarea f
neacoperita de precalculele facute, aceste chei se vor abandona, asteptandu-se altele, care
ndeplinesc cerinta mentionata.
Revenind la faza de atac, se calculeaza t = TR41 k pentru fiecare valoare a lui
R41 . Primele elemente ale vectorului t sunt variabilele din S1 partial rezolvate; dar
deoarece unele ecuatii sunt liniar dependente restul elementelor lui t ar trebui sa fie zero
(reprezentand ecuatiile dependente). Prin urmare, se verifica daca ultimele elemente din
t sunt ntr-adevar nule (cheia k este consistenta cu valoarea testata pentru R41 ). Odata
gasita o valoare consistenta pentru R41 , ea poate fi verificata prin calcularea cheii si efectuarea de teste prin criptare.
O implementare mai rapida nu retine n memorie matricea TR41 , ci doar ultimele linii
0
TR4
: cele care corespund elementelor nule din t. Apoi, pentru verificarea consistentei
1
0
valorii R41 , se poate testa numai daca t0 = TR4
k este un vector de zero-uri.
1
Analiza complexitatii timp si spatiu a atacului folosind un singur tabel precalculat
(pentru un singur XOR ntre valorile f ale frame-urilor): autorii spun ca timpul necesar
pentru precalcule este comparabil cu timpul necesar pentru efectuarea atacului n varianta
neoptimizata, adica aproximativ 40 minute. In faza de atac, trebuie pastrate n memorie
matricile (pentru operatii rapide). O singura matrice de sistem are cam 456 16 biti, deci
sunt necesari cam 60 MBs pentru retinerea tabelului corespunzator a 216 valori posibile
ale lui R41 . Alti 64 456 216 240MBs sunt necesari pentru pastrarea matricilor folosite
la aflarea starii interne avand R41 si cheia fluida respectiva.
Timpul atacului este de 250 cicluri CPU pentru nmultirea si verificarea unei matrici,
sau aproximativ cateva milisecunde n total pe un P C (date 2006). Dupa aflarea unui
40

IILOR GSM
candidat pentru R41 , ncarcarea matricei solutie relevante de pe disc dureaza cateva zeci
de milisecunde.
In implementarea autorilor, atacul dureaza mai putin de o secunda pe un P C.
Atac cu text criptat
In aceasta sectiune este prezentat un atac care transforma atacurile anterioare ntr-unul
cu text criptat cunoscut, si care verifica anumite combinatii liniare de biti dinainte de
criptare, bazandu-se pe teoria codurilor corectoare de erori.
GSM foloseste corectarea erorilor pentru a rezista la erorile de canal. In timpul
transmisiei, un mesaj este ntai transformat cu un cod corector de erori, ceea ce mareste
considerabil lungimea mesajului. In faza a doua, mesajul este criptat si ulterior transmis.
Aceasta procedura inversata contrazice practica obisnuita: de a cripta ntai un mesaj
si apoi de a-l codifica cu un cod corector de erori. Tocmai aceasta trecere a mesajului
prin codurile corectoare de erori nainte de criptare introduce o redondanta exploatata n
atacul curent.
Exista diverse scheme de corectare a erorilor n GSM , pentru diferite canale. Autorii
atacului s-au concentrat asupra codurilor corectoare de erori aplicate canalului SACCh,
folosite de asemenea si pentru canalul SDCCh. Ambele canale sunt utilizate la nceputul
apelului. Alte canale sunt accesate n alte etape ale conversatiei, iar atacul propus poate
fi adaptat si la acestea (desi este suficient sa gasim cheia pe canalul SDCCh la nceputul
apelului, pentru ca aceasta nu se schimba n timpul conversatiei).
In SACCh, mesajul sursa (care se codifica) are o lungime fixa de 184 biti; dupa
codificare, va avea 456 biti. Acestora li se aplica procedura de interleaving5 , dupa care
sunt mpartiti n patru frame-uri, ulterior criptate si transmise.
Operatiile de codificare si interleaving pot fi modelate mpreuna ca o multiplicare
a mesajului sursa (reprezentat ca un vector binar P de 184 biti) cu o matrice G de
dimensiune 456 184 peste GF (2) si apoi XOR-area rezultatului cu un vector constant
g:
M = (G P ) g
(2)
Vectorul M este mpartit apoi n patru frame-uri, iar fiecare este criptat conform
procedeului corespunzator algoritmului A5/2.
Cum G este o matrice binara, pentru orice vector M care verifica (2) exista 456184 =
272 ecuatii liniar independente.
Fie H o matrice definita prin relatia
H (M g) = 0
unde M este dat de (2) (n teoria codurilor, H se numeste matrice de control).
5
Pentru detalii privind tehnicile de codificare, a se vedea [?].
41
Sa aratam cum se foloseste redondanta mesajului pentru a lansa atacul.

Mesajul criptat este calculat dupa formula
C =M k
unde k = k1 kk2 kk3 kk4 este cheia fluida pentru cele patru frame-uri. Se folosesc aceleasi
ecuatii pentru C g adica
H (C g) = H (M k g) = H (M k) H k = 0 H k = H k
Cum valoarea textului criptat C este cunoscuta (g este fixat si cunoscut), ceea ce
ramane sunt ecuatii liniare peste bitii lui k.
Pentru fiecare ghicire a lui R41 se nlocuieste fiecare bit al lui k n acest sistem de ecuatii,
cu descrierea sa ca termen liniar peste S1 ; se ajunge la un sistem de ecuatii peste cele
656 variabile din S1 . Fiecare bloc de 456 biti care se codifica furnizeaza cele 272 ecuatii
mentionate anterior; deci, dupa doua astfel de blocuri se obtin peste 450 ecuatii.
Intr-o maniera asemanatoare atacului neoptimizat, se efectueaza apoi eliminari gaussiene,
cele 450 ecuatii fiind suficiente pentru a gasi valorile variabilelor liniare originale din S1 .
In final, Kc este determinat prin inversarea etapei de initializare din A5/2.
Restul atacului si complexitatea timp sunt similare cu cazul precedent. Principala
diferenta este aceea ca n atacurile precedente se cunosc bitii cheilor fluide, n timp ce n
acest atac se cunoasc valoarile combinatiilor liniare ale bitilor cheii fluide.
Prin urmare, ecuatiile rezultate aici sunt combinatii liniare ale ecuatiilor din atacurile
precedente.
Exemplul 5.5. Fie SR41 S1 = k un sistem de ecuatii din atacul optimizat, unde SR41
este matricea sistemului.
Inmult
im acest sistem la stanga cu H si obtinem
(H SR41 ) S1 = (H k).
H este matricea fixata prezentat
a anterior iar H k este calculat din textul criptat.
Prin urmare, acest sistem se poate rezolva si atacul continu
a ca n sectiunea anterioara.
atacul cu text clar cunoscut, se ncearc
In
a toate cele 216 sisteme de ecuatii posibile S.
atacul cu text criptat cunoscut, se ncearc
In
a toate cele 216 sisteme de ecuatii posibile
faza sa de precalcul, pentru fiecare astfel de sistem se g
H SR41 . In
asesc dependentele
liniare ale liniilor (prin eliminare gaussian
a). C
and se trece la faza de atac, se elimina
valorile gresite ale lui R41 verificand dac
a dependentele liniare g
asite n etapa de precalcul
se mentin pe bitii lui H k.
O diferenta tehnica ntre atacul cu text criptat si atacul cu text clar cunoscut este
aceea ca n timp ce pentru cel din urma atac, patru frame-uri de text clar furnizeaza
suficiente ecuatii, pentru primul atac sunt necesare opt frame-uri.
Motivul este ca n atacul cu text criptat, din 456 biti de text criptat se extrag numai 272
de ecuatii.
42

IILOR GSM
Complexitatea timp a atacului cu text criptat optimizat este aceeasi ca n cazul atacului cu text clar optimizat. Autorii au implementat o simulare a atacului si au certificat
experimental aceste rezultate.
5.6.3
Atac hardware asupra lui A5/2
Atacul prezentat n aceasta sectiune a fost publicat ntr-un articol din 2007 ([?]). Autorii
pornesc de la atacul cu text criptat cunoscut si arata ca atacul bazat pe hardware aduce
mbunatatiri n termeni de timp, memorie si flexibilitate.
Abordarea este similara cu cea descrisa n atacul anterior, dar fara a folosi precalcule
si fara a impune conditii asupra frame-urilor de text criptat. Mai mult, autorii au creat o
arhitectura care sa atace direct canalul de vorbire. In particular, pentru atac se folosesc
frame-uri de text criptat din canalele de trafic pentru vorbire (T Ch) n loc de canale
de control specifice (SDCCh). Avantajul este ca monitorizarea (pentru receptionarea de
frame-uri) poate ncepe oricand n timpul apelului, fara a fi nevoie sa se astepte trimiterea
pachetelor de date printr-un canal de control specific.
Atacul asupra canalului de vorbire necesita 16 frame-uri de text criptat la intrare, iar la
iesire va gasi starea initiala (secreta). Principalele parti ale arhitecturii hard constau n 3
generatori de ecuatii si un bloc care se ocupa de rezolvarea sistemelor liniare. Componenta
hardware propusa pentru cel din urma bloc se numeste SM IT H si poate rezolva orice
sistem supra-determinat de ecuatii liniare, efectuand extrem de rapid eliminari gaussiene.
Ea a fost construita pe un F P GA (retea de porti logice reconfigurabile) de cost redus
iar ideea matematica este urmatoarea: un sistem liniar de ecuatii de forma A x = b se
transforma (prin aplicarea operatiilor elementare asupra liniilor) n sistemul echivalent
U x = b0
(3)
unde U este o matrice superior triunghiulara.

Sistemul (3) poate fi rezolvat prin substitutie inversa. Folosindu-se de paralelizare hardware, complexitatea timp este cel mult patratica, iar cea medie este liniara.
La o iteratie, fiecare generator de ecuatii produce o ecuatie liniara avand ca variabile bitii
starii interne din A5/2. Dupa 185 iteratii (cand au fost ncarcate 555 ecuatii), blocul
SM IT H efectueaza eliminari Gauss - Jordan paralelizate. Iesirea sugereaza starea secreta candidata cea care trebuie verificata. Candidatul corect este astfel gasit dupa
aproximativ 228 tacti.
In aceasta forma, atacul se poate realiza ntr-o secunda, la o viteza de operare de
256 MHz pentru principala componenta chip si 512 MHz pentru celelalte, arhitectura
consumand numai 12, 8 wati.
Abordarea atacului este similara cu cea propusa n atacul cu text criptat; el necesita
l frame-uri criptate cu aceeasi cheie de sesiune K.
Parametrul l depinde de canalul ce va fi atacat. De pilda, sunt necesare 16 frame-uri
pentru atacul asupra canalului de vorbire si n jur de 8 frame-uri pentru atacul canalului
43
SDCCh.
Ideea generala este de a ghici starea interna a registrului R4 chiar dupa initializare, si
de a scrie fiecare bit al cheii generate folosita pentru criptarea celor l frame-uri de text
criptat n termeni de starile initiale ale registrilor R1, R2, R3.
Folosind anumite informatii despre bitii cheii, se construieste un sistem supradeterminat
patratic de ecuatii, care apoi este liniarizat si rezolvat prin eliminari gaussiene.
Procedura se repeta pentru diverse valori ale lui R4 pana este gasita solutia corecta.
Cu aceasta se poate construi usor starea interna a lui A5/2 dupa initializare, pentru
frame-uri arbirare care au fost criptate folosind cheia K.
Apoi se pot decripta toate celelalte frame-uri si gasi, n final, cheia de sesiune.
Arhitectura necesara pentru realizarea atacului este schitata n figura de mai jos; ea accepta la intrare 16 frame-uri de text criptat si cele 16 numere f de frame corespunzatoare;
iesirea contine starea initiala interna a celor 4 registri, formata din 77 biti 0 , ...77 (s-au
exclus cei 4 biti setati pe valoarea 1).
Arhitectura propus
a pentru atacul A5/2
Cele 16 frame-uri mpreuna cu numerele de frame corespunzatoare, notate IV
sunt stocate n Ciphertext Module (CM ). Fiecare din cei trei generatori de ecuatii (EG)
genereaza 185 ecuatii liniare avand bitii i (0 i 60) ca variabile.
EG primesc bitii de text criptat si numerele de frame IV de la CM . Fiecare ecuatie
generata este trecuta n bufferul din blocul care rezolva ecuatiile (LSE - Solver). Bufferul
este necesar pentru ca LSESolver-ul accepta o ecuatie la fiecare tact, iar cele trei EG-uri
produc simultan cate o ecuatie. Dupa ce cele 555 ecuatii se acumuleaza n LSE Solver,
acesta lanseaza etapa de rezolvare, producand un candidat pentru starea secreta.
44

IILOR GSM
Candidatul este trimis din LSE Solver catre Key Tester, care verifica daca a fost gasita
o stare corecta.
Procesul de verificare se desfasoara n paralel cu determinarea unui nou candidat. Mai
precis, n timp ce ecuatiile pentru al j-lea candidat sunt generate de EG, al (j 1)-lea
candidat este testat de catre KT . Toate procesele sunt controlate de Unitatea Logica
de Control, care efectueaza sincronizarea si clocking-ul pentru CM, EG, LSE Solver si
KT . Principala sa sarcina este de a verifica daca ecuatiile contin combinatii corecte de
biti de text criptat si cheie.
5.7
Concluzii
Modelul de securitate propus de standardul GSM este compromis pe mai multe nivele si
este deci vulnerabil la atacuri care tintesc anumite parti ale retelei operatorului. Algoritmii
de securitate (nepublicati) ncorporati n sistem s-au dovedit nesiguri. Algoritmul A5/2
folosit pentru criptare este vulnerabil la atacuri cu text clar si chiar cu text criptat, iar
dimensiunea redusa a spatiului cheii si a registrilor LF SR din arhitectura algoritmilor de
criptare permit chiar un atac prin forta bruta.
Exista mai multe atacuri publicate pentru ambii algoritmi A5/1 si A5/2.
Atacul pentru algoritmul A5/2 care necesita numai 4 frame-uri de text clar cunoscut
si se bazeaza pe o etapa masiva de precalculeori reuseste obtinerea cheii si decriptarea
ntr-un timp foarte scurt, de numai o secunda. Etapa de precalcul poate fi efectuata pe
majoritatea computerelor actuale.
Pe de alta parte, atacul bazat pe hardware aduce mbunatatiri n complexitatea timp; el
se bazeaza pe o arhitectura hardware masiv paralela, care elimina necesitatea unei etape
premergatoare de calcule.
Atacurile asupra algoritmului A5/1 sunt si mai numeroase, ridica probleme mai mari,
dar chiar si n acest caz progresele tehnice simplifica mult lucrurile. Cea mai recenta propunere de atac pentru A5/1 ([?]) este de asemenea bazata pe hardware si este remarcabila
pentru ca este complet pasiva, costul total pentru harware se situeaza n jurul sumei de
numai 1000 dolari, iar timpul total de spargere a cheii este de 30 de minute (putand
ajunge si la cateva secunde, daca se mareste puterea hardware).
Slabiciunile dovedite ale algoritmilor de criptare GSM nu sunt singurele existente n
sistem. Anonimitatea poate fi atacata activ, folosind echipamente care pot fi achizitionate
la preturi relativ modice (de pilda, daca se foloseste o statie de baza uzata).
Amenintarile legate de clonarea SIM par sa fie destul de reale. Este adevarat ca
metoda cea mai usoara este prin acces fizic la cartela tinta, astfel ncat nu poate fi o
amenintare foarte serioasa. Pe de alta parte, pentru a clona o cartela SIM fara a avea
acces fizic la ea devine mult mai costisitor. In principiu, atacatorul are nevoie de o statie
de baza cu semnal puternic, costul acesteia putand fi astazi n jurul a cateva zeci de mii
de dolari.
Bibliografie
[1] A. Atanasiu Securitatea informatiei, vol. 1 (Criptografie), Ed. Infodata, Cluj (2007)
[2] A. Atanasiu Teoria codurilor corectoare de erori, Ed. Universitatii Bucuresti (2001)
[3] P. Chandra BULLETPROOF WIRELESS SECURITY: GSM , UMTS, 802.11,
and Ad Hoc Security (Communications Engineering), Elsevier (2005).
[4] A. Mihaita Securitatea sistemelor GSM , Lucrare dizertatie, 2009.
[5] S. Martin Communication Systems for the Mobile Information Society, Wiley
(2006).
[6] S. Redl, M. Weber, K. Matthias, M. Oliphant GSM and Personal Communications
Handbook, Artech House, 1998.
[7] E. Barkan, E. Biham, N. Keller Instant Ciphertext-Only Cryptanalysis of GSM
Encrypted Communication , Journal of Cryptology, vol. 21, nr.3 (2008).
[8] E. P. Barkan Cryptanalysis of Ciphers and Protocols, PhD Thesis, Technion Israel
Institute of Technology (2006)
[9] P. Yousef GSM Security: a Survey and Evaluation of the Current Situation, Master
Thesis, Linkping, 2004
[10] A. Bogdanov, T. Eisenbarth, A. Rupp A Hardware-Assisted Realtime Attack on
A5/2 without Precomputations, Cryptographic Hardware and Embedded Systems CHES 2007, LNCS, Sprnger Verlag (2007).
[11] P.T. Ngarm, P. Poocharoen GSM Security Vulnerability, http://islab.
oregonstate.edu/koc/ece478/03Report/toparkngarm-poocharoen-project578.pdf
[12] M. Briceno, I. Goldberg, D. Wagner A pedagogical implementation of the GSM
A5/1 and A5/2 voice privacy encrypted algorithms, http://cryptome.org/GSM a512.htm, 1999
45
46
BIBLIOGRAFIE
[13] N. Courtois, W. Meier Algebraic Attacks on Stream Ciphers with Linear Feedback.
In: Biham, E. (ed.) EUROCRYPT 2003. LNCS, vol. 2656, pp. 346359, Springer,
Heidelberg (2003).
[14] J. Neil Croft, S. O. Martin The use of a Third Party Proxy in Achieving GSM
Anonymity, Southern African Telecommunication Networks and Applications Conference 2004 (SATNAC 2004), D Browne (ed), Stellenbosch, Africa de Sud (2004).
[15] S. Petrovic, A. Fuster-Sabater Cryptanalysis of the A5/2 Algorithm, IACR ePrint,
Report 200/52 (2000)
[16] B. Schneier http://www.schneier.com/blog/
Capitolul 6
Securitate pe Internet (IP Sec)
6.1
Introducere
In 1994, Internet Architecture Board (IAB) a emis un raport intitulat Securitatea n

arhitectura de Internet (RF C 1636). Raportul a declarat ca internetul are nevoie de
mai multa securitate si a identificat domenii - cheie pentru mecanismele de protectie.
Printre acestea, necesitatea de a securiza infrastructura de retea: de la monitorizarea
neautorizata si controlul traficului pana la necesitatea de a asigura comunicarea ntre
oricare doi utilizatori folosind mecanisme de autentificare si criptare.
Exemplul 6.1. Raportul din 1998 emis de Computer Emergency Response Team (CERT)
prezint
a 1.300 raportari de incidente de securitate care au afectat aproape 20.000 site-uri.
Cele mai grave tipuri de atac includ IP spoofing, n care diversi intrusi creeaz
a pachete
cu adrese IP false si exploateaza aplicatiile care utilizeaz
a autentific
ari bazate pe adresa
de IP , precum si diverse forme de interceptare a pachetelor sniffing, n care atacatorii
citesc informatiile trimise, inclusiv informatii de log on si continuturi ale bazelor de date.
Practic, IP Sec (Internet Protocol Security) este o secventa de protocoale avand ca
scop securizarea protocoalelor de comunicare prin Internet (Internet Protocol IP ),
autentificand si criptand fiecare pachet IP de sir de date.
IP Sec include de asemenea protocoale de autentificare reciproca ntre parteneri la
nceputul sesiunii si stabilirea cheilor criptografice care vor fi folosite pe durata sesiunii
de comunicare.
IP Sec poate fi utilizat de asemenea pentru protejarea fluxurilor de date dintre doua
entitati (de exemplu un calculator si un server), ntre doua gateway-uri (porti) de securitate1 (de exemplu routere sau firewalls), sau ntre un gateway de securitate si un
utilizator.
1
Un gateway de securitate este un sistem intermediar care implementeaza diverse protocoale IP Sec.
A se vedea Definitia 6.1.
CAPITOLUL 6. SECURITATE PE INTERNET (IP SEC)
De multe ori IP Sec este utilizat pentru protejarea traficului pe Internet.

Istoric, IP Sec este un succesor al standardului ISO N LSP (Network Layer Security
Protocol). N LSP era definit pe baza protocolului SP 3 publicat de N IST , care desemna
un proiect de securitate a datelor prin retea apartinand N SA (National Security Agency).
Oficial, standardele IP Sec sunt specificate de IET F (Internet Engineering Task
Force) printr-o serie de cereri de comentarii relative la diverse componente si extensii
(inclusiv definirea termenilor si a nivelurilor de securitate).
6.2
Arhitectura IP Sec
Asa cum s-a stablit, IP Sec este compus dintr-un set de protocoale interconectate, al caror
scop este asigurarea unor servicii de securitate.
In termeni generali, arhitectura unui IP Sec este descrisa de figura de mai jos:
Pachet IP
?
-
Motor ESP/AH
Baze de date
IP Sec
Nivel 1A
Protocoale de securitate
ncapsulate
Antet de Autentificare
Nivel 2
6
?
Criptare
Autentificare
si Integritate
Managementul cheilor
Nivel 3
Nivel 1B
Bazele de date IP Sec:

De obicei sunt trei baze de date standard la acest nivel:
1. SP D (Security Policy Database): Specifica controlul de trafic IP al ambelor
parti implicate (expeditor si destinatar).
6.2. ARHITECTURA IP SEC
2. SAD (Security Association Database): Contine parametrii fiecarei asocieri de

securitate stabilite (SA). Fiecare SA are un element n SAD.
In general, un SAD contine:
Indexul parametrului de securitate (SP I).
Serviciile de securitate ncapsulate (ESP Encapsulated Security Payload/Protocols), cu datele curente transmise: algoritmi de criptare si integritate, modul de generare al cheilor, valorile initiale (IV ) etc.
Antetul de autentificare (AH), cu algoritmul de autentificare, cheile M AC
etc.
Timpul de valabilitate al SA.
Tipul de protocol IP Sec (tunel sau transport) aplicat lui SA.
3. P AD (Peer Authorisation Database): asigura legatura ntre SP D si un protocol de gestiune a securitatii (de exemplu IKE).
Nivel 2: Cele doua protocoale de securitate de la acest nivel (care au sub control
si Nivelul 3) sunt:
1. AH (IP Authentication Header): folosit pentru autentificare, este bazat pe
standardul RF C 4302.
2. ESP (bazat pe standardul RF C 4303): este folosit pentru criptare si autentificare.
Nivel 3:
Fiecare algoritm criptografic pentru autentificare si criptare este definit de un standard RF C specific. In mod uzual, pentru criptare se folosesc AES si 3DES, iar
pentru autentificare si integritate functii de dispersie cu cheie.
Protocoale de gestiune a cheilor:
Sunt descrise n IKEv2 (Internet Key Exchange, version 2), bazate pe un standard
din 2005 (RF C 4306).
O relatie ntre aceste protocoale este redata de schema urmatoare:

Arhitectura
IP Sec
)
ESP
AH
z
Algoritmi
de
criptare
?+
- IKE v2
6
Algoritmi
de
autentificare
Gestiune chei
6.3
Negociere IP Sec
In momentul cand un pachet de date este transmis ntre doi utilizatori, are loc un protocol
de negociere lansat de expeditor (notat Alice), respectiv destinatar (Bob).
6.3.1
Pachetul de iesire
Serverul Alice vrea sa trimita pachetul de date spre serverul Bob. Pentru aceasta se deschide o aplicatie IP Sec, care functioneaza dupa urmatorul protocol (numit negociere):
1. Aplicatia apeleaza stiva T CP/IP pentru a prelua .
2. este preluat de un algoritm de negociere AN , care construieste un nvelis de
protectie.
3. AN cauta pachetul n baza de date a protocoalelor de securitate si decide daca
este necesara o protejare a sa sau doar un permis de trecere IP Sec. In final, poate
fi
(a) protejat folosind serviciile IP Sec;
(b) eliminat;
(c) asociat cu un permis de trecere IP Sec.
4. Daca trebuie protejat, AN trimite aplicatiei adresa lui Bob, care o cauta n SA
si SP I din bazele sale interne de date.
5. Daca nu a fost negociat nca un SA pentru adresa respectiva, atunci aplicatia
lanseaza o negociere IKE cu adresa respectiva, pentru crearea unui SA.
6. Dupa terminarea negocierii, aplicatia trimite SP I si SA spre AN ; acesta va construi
o protectie pentru folosind cheia negociata de aplicatie.
6.4. ASOCIERILE DE SECURITATE (SA)
6.3.2
Pachetul de intrare
Daca Bob primeste un pachet de date n portul rezervat negocierii IKE (de obicei acest
port este 500 sau 4500), atunci:
1. Daca pentru adresa primita nu a fost negociat nca nici un SA, atunci AN va
transmite pachetul aplicatiei de negociere.
2. Daca are un SP I asociat, atunci este cautat SA-ul corespunzator n baza de date
IP Sec. Daca SP I nu are corespondent n baza de date, pachetul este respins.
3. Daca nu contine nici un SP I, atunci AN poate deduce ca nu are asociat nici
un SA si l respinge.
6.4
Asocierile de securitate (SA)
O asociere de securitate ataseaza parametri de securitate pachetelor de date care sunt

trimise n trafic. Un SA descrie parametrii de securitate acceptati de Alice si Bob.
In aceasta faza se stabileste o conexiune ntre o sursa si o destinatie, n care cei doi
parteneri trebuie sa cada de acord printre altele asupra algoritmilor de criptare si
autentificare, asupra cheilor de criptare (marimea, durata, modul de trimitere), valorile
de initializare, precum si alti parametri de securitate.
Dupa ce s-a definit SA-ul unei conexiuni, lui i se atribuie un index (SP I Security
Parameter Index) si este stocat n baza de date SP D. In interiorul acestei baze de date,
la SA se adauga adresele IP ale sursei si destinatiei.
Deci, toata informatia dintr-un SA este grupata n:
Indexul parametrului de securitate (SP I). Scopul lui este de a asocia un SA
cu o conexiune particulara.
Adresa IP de destinatie: de obicei adresa unui user sau a unui gateway (router
sau firewall).
Protocolul pentru securitatea ID: Indica daca protocolul de securitate este
ESP sau AH.
Asocierea de securitate corespunzatoare unei conexiuni poate fi un ESP sau un AH,
dar nu amandoua. Daca o conexiune are asociate ambele protocoale, atunci sunt create cel
putin doua SA-uri pentru a-i asigura protectia. O comunicare securizata bidirectionala
tipica ntre doua entitati necesita doua asocieri de securitate (cate una pentru fiecare
directie).
Atat protocolul de securitate ESP cat si AH suporta doua moduri de operare: modul
transport si modul tunel.
6.4.1
Antetul de autentificare (AH)
Protocolul AH (RF C 4302) defineste formatul pachetelor IP Sec; el asigura integritatea

conexiunii, autentificarea originii datelor si optional un serviciu anti-replay. De remarcat ca el nu cripteaza portiunea de date din pachet.
AH poate fi folosit singur, combinat cu ESP , sau ntr-o forma interna a modului de
utilizare tunel.
Structura unui AH poate fi reprezentata astfel:
Autentificare
Antet IP
Next HA
AH
Date curente
8 biti
Lungimea campului
de date curente
Rezervat
Cuvant 1
Indexul parametrilor de securitate
Cuvant 2
Numarul de secventa
Cuvant 3
Date autentificate (marime variabla).

Contine si ICV (Integrity Check Value)

32 biti
Cuvant 4, . . .
-
unde:
Next HA: zona de 8 biti care identifica tipul antetului pe care l are urmatorul
camp de date curente (payload).
Lungimea c
ampului de date curente: Daca AH este format din s cuvinte,
contintul acestui camp este s 2. In cazul standard (ca n figura) al unui AH de
4 cuvinte, tot antetul de autentificare are 6 cuvinte, deci continutul acestui camp
este valoarea 4 (scrisa pe 8 biti).
Rezervat: Camp de 16 biti, rezervat pentru o utilizare ulterioara.
Indexul parametrilor de securitate (SP I): indica protocoalele de securitate,
algoritmii si cheile folosite. Impreuna cu adresa IP a destinatarului si protocolul de
securitate (AH), el identifica n mod unic asocierea de securitate pentru o comunicare. Valoarea SP I este selectata de (sistemul) destinatar n momentul stabilirii SA,
din intervalul [1, 255] (codificarea este asigurata de IAN A The Internet Assigned
Numbers Authority).
Num
arul de secvent
a: spune cate pachete au fost trimise si asigura protectie
non-reply. Campul contine un contor monoton crescator.
Prezenta lui este obligatorie, chiar daca destinatarul Bob nu alege o optiune
non-replay pentru un anumit SA.
La initierea unei asocieri de securitate, contoarele lui Alice si Bob sunt setate
pe 0. Primul pachet trimis folosind un SA fixat va avea numarul 1.
Daca este activat un non-replay (lucru realizat de obicei by default), numarul
de secventa nu se aloca niciodata ntr-un ciclu.
Numarul maxim de pachete transmise ntr-un SA este 232 . Cele doua contoare
trebuie resetate (stabilind un nou SA si deci o noua cheie) nainte ca ele sa
ajunga la aceasta valoare.
ICV: Este valoarea de control a integritatii pachetului de date transmis. Este o
variabila ntreaga scrisa ca un multiplu de 32 biti (pentru IP v4) sau 64 biti (IP v6),
variante selectate printr-un camp suplimentar, inclus explicit. Toate implementarile
trebuie sa asigure acest camp suplimentar.
Pentru a calcula ICV -ul unui AH se tine cont de:
Campurile antetelor IP , care sunt sau neschimbate n trafic, sau sunt predictibile ca valoare (pentru un AH) n momentul receptiei.
Toate datele din antetul AH.
Datele oferite de nivelul de protocol si setul de date curente despre care se
presupune ca sunt neschimbate n trafic.
Algoritmii folositi pentru implementarea antetului de autentificare sunt:
HM AC SHA1 96; obligatoriu.
AES XBCB M AC 96; recomandabil.
HM AC M D5 96; optional.
6.4.2
ESP
Protocolul ESP (RF C 4303) ofera pe langa serviciile asigurate de un AH confidentialitatea datelor, si ntr-o forma limitata a traficului pe canal (deci criptarea datelor).
Principala diferenta dintre autentificarea asigurata de ESP si cea oferita de AH
consta n extinderea ariei de acoperire: ESP nu protejeaza nici un antet IP care nu
este ncapsulat prin ESP (modul tunel).
Setul de servicii ESP depinde de optiunile selectate n momentul stabilirii asocierii de
securitate si de locul implementarii.
Autentificarea originii datelor si corectitudinea informatiilor de conectare sunt servicii
auxiliare numite integritate. Pentru protocol trebuie selectat cel putin unul din serviciile
de confidentialitate sau integritate.
Serviciul non-replay poate fi ales doar mpreuna cu cel de integritate, iar aceasta
alegere este n totalitate la dispozitia destinatarului.
Confidentialitatea fluxului din trafic necesita alegerea modului tunel si ea este realizata
efectiv daca se include n securitatea la nivel de gateway unde agregarea traficului poate
masca pachetele de informatie sursa - destinatie.
Autentificare
Criptare

Antet IP Original
Antet ESP
Rezumat ESP
Date curente
ICV ESP
Indexul parametrilor de securitate (SP I)

Numarul de secventa
Date curente (Payload Data)
Padding (0 255 octeti)

Lungime pad Next Antet
ICV

32 biti
ESP asigura criptarea unui IP la nivel de pachet, folosind algoritmi de criptare simetrici. Sunt admisi diversi algoritmi cel recomandat de standard fiind AES.
Sa dam o descriere a campurilor dintr-o ncapsulare ESP (conform figurii de mai sus):
SPI: Identic cu formatul AH.
Num
arul de secvent
a: Identic cu formatul AH.
Date curente (Payload data): Camp de lungime variabila care contine datele descrise de campul Next Antet.
ESP foloseste algoritmi de criptare simetrici si deoarece pachetele IP pot veni
ntr-o ordine arbitrara fiecare pachet va contine si informatii de sincronizare criptografica (de exemplu un vector de initializare).
Algoritmii de criptare utilizati n implementari sunt:
3DES CBC: obligatoriu.
AES CBC: recomandabil.

AES CT R: recomandabil.
Se pot folosi si alti algoritmi de criptare, cum ar fi RC5, IDEA, CAST, Blowf ish,
pentru care DOmeniul de Interpretare (DOI) are deja asignati identificatori.
Zona anex
a (Padding) de maxim 255 octeti este necesara pentru urmatoarele
motive:
Unii algoritmi de criptare folosesc blocuri de text clar de lungime fixata. Zona
anexa este folosita pentru a completa textul clar pana la lungimea solicitata.
Textul clar consta din datele curente, anexa, lungimea zonei anexe si campul
rezervat pentru Next Antet.
Anexa este adaugata la textul criptat, pentru ca n final numarul de biti al
textului criptat sa fie multiplu de 32.
Zone anexe aditionale se pot folosi si pentru a ascunde lungimea reala a anexei,
cu scopul de a creste confidentialitatea fluxului de date n trafic.
Lungime pad: Indica numarul de octeti din zona anexa. Valoarea este un numar
din intervalul [0, 255], unde 0 nseamna ca zona anexa nu este prezenta.
Next antet: Camp de un octet care identifica tipul de date din zona datelor curente.
Codificarea folosita este indicata pe pagina IAN A (http://www.iana.org/numbers/).
De exemplu, valoarea 4 indica IP v4, valoarea 41 indica IP v6 etc.
De asemenea, se poate identifica un protocol de nivel superior; de exemplu, valoarea
6 indica protocolul T CP .
ICV: Valoarea de control a integritatii este identica cu cea de la AH, cu singura
specificatie ca aici ea este calculata pentru 3 campuri: Antet ESP , Rezumat ESP
si Date curente. Daca s-a selectat serviciul de criptare, ultimele doua campuri sunt
sub forma criptata (criptarea fiind aplicata nainte de autentificare)
6.4.3
Modurile de operare AH si ESP
IP Sec poate fi implementat pe doua tipuri de echipament: pe server gazda sau pe poarta
(gateway) de securitate.
Definitia 6.1. Un gateway de securitate este un sistem intermediar ntre dou
a retele.
Canalul de intrare ntr-un gateway este nesigur, iar canalul de iesire este securizat.
Un gateway implementeaza IP Sec pe interfata nesigura, pentru a permite comunicatii
securizate ntre servere gazda de pe ambele laturi.
Astfel, serviciile de securitate pot fi asigurate:
10
1. ntre orice doua servere care comunica ntre ele;

2. ntre o pereche de gateway de securitate;
3. ntre un gateway si un server.
AH si ESP suporta doua moduri de operare: modul transport si modul tunel.
Un SA n mod transport este o asociere de securitate ntre doua servere.
Cand un gateway de securitate lucreaza n mod transport, el actioneaza ca un server:
traficul i este destinat lui.
Un SA n mod tunel este o asociere de securitate n care cel putin unul din parteneri
este un gateway.
Modul transport este folosit pentru protejarea protocoalelor de comunicare, pe cand modul
tunel are ca principal scop protejarea pachetelor IP (tot pachetul IP este ncapsulat n
alt pachet IP si este adaugat un nou antet IP ntre antetele interne si externe).
1. In modul transport, antetul protocolului de securitate apare imediat dupa antetul
IP originar si naintea datelor curente. Pentru ESP implementat n modul transport, SA asigura servicii de securitate numai pentru protocoale de nivel nalt, nu si
pentru antetul IP originar sau alte antete extinse care preced antetul ESP .
Pentru AH, protectia este extinsa la antetul IP originar.
2. Pentru SA n modul tunel, apar nca doua antete:
- unul extern care specifica destinatia finala IP Sec si detalii legate de aceasta
destinatie;
- un antet intern care specifica ultima destinatie (aparenta) a pachetului.
Antetul protocolului de securitate apare dupa antetul IP exterior si naintea celui
interior. Daca AH este utilizat n modul tunel, unele portiuni din antetul IP exterior
sunt asignate protectiei, mpreuna cu toate pachetele IP interne. Asta nseamna ca
toate antetele IP interioare sunt protejate, mpreuna cu toate protocoalele specificate n datele curente.
Daca se foloseste ESP , protectia este asigurata numai pentru pachetele interne, nu
si pentru antetul exterior.
6.5
Schimbul de chei Internet (IKE v2)
Deoarece serviciile de securitate IP folosesc sisteme simetrice de criptare, este necesar ca

ambele parti (Alice si Bob) sa cada de acord asupra unor mecanisme care sa le permita
sa stabileasca chei secrete pentru criptare, autentificare si integritate. IP Sec permite o
distributie a cheilor atat manual cat si automat.
6.5. SCHIMBUL DE CHEI INTERNET (IKE V 2)
11
Definitia 6.2. Protocolul IKE (Internet Key Exchange) stabileste proceduri si formate
de pachete de date care stau la baza definirii, negocierii, modific
arii si elimin
arii asocierilor de securitate (SA). El asigur
a cadrul de securitate pentru transferul de chei si
autentificarea datelor, independent de mecanismul de generare al cheilor, algoritmii de
criptare sau mecanismele de autentificare.
Protocolul IKE este utilizat free n doua versiuni: IKE v1 (definit de RF C 2409) si
IKE v2 (definit n prima varianta n decembrie 2005 cu RF C 4306, iar forma completa
n septembrie 2010, prin RF C 5996). Ambele au fost dezvoltate si cu drept de copyright
de ISOC (The Internet SOCiety).
Datele curente ale unui SA propun un set de algoritmi de criptare, mecanisme de
autentificare si algoritmi de stabilire a cheilor care sa fie utilizati n IKE, ESP si/sau
AH. Protocolul IKE nu se limiteaza la anumiti algoritmi; el permite constructii pentru
accesarea upgradarilor sau a altor mecanisme care pot fi preferate de utilizatori. Aceste
noi obiecte cu care va lucra IP Sec nu necesita dezvoltarea unui nou IKE sau nlocuirea
celui vechi.
Vom prezenta n aceasta sectiune elementele principale din IKE; v2, , urmaand ca
ulterior sa abordam si IKE v1.
In mod obisnuit, o asociere de securitate include obligatoriu urmatorii parametri (fara
a se limita doar la acestia):
1. Tipul de protectie folosit (ESP sau AH).
2. Algoritmul de autentificare folosit cu AH.
3. Cheile folosite cu algoritmul de autentificare din AH.
4. Algoritmul de criptare si modul, utilizate cu ESP .
5. Cheia utilizata de algoritmul de criptare n ESP .
6. Vectorul de initializare pentru algoritmul de criptare utilizat n ESP .
7. Algoritmul de autentificare si modul, utilizate cu ESP .
8. Cheia de autentificare utilizata cu algoritmul de autentificare n ESP .
9. Durata de valabilitate a cheii utilizate sau data cand ea trebuie schimbata.
10. Algoritmii de dispersie pentru crearea amprentei care va fi semnata.
11. Informatii despre grupul peste care se va defini schimbul de chei Diffie - Hellman.
12. Perioada de valabilitate a asocierii de securitate curente.
13. Adresa sursei care a construit asocierea de securitate.
12
6.5.1
Selectarea algoritmilor
IKE foloseste urmatoarele recomandari de implementare (care trebuie negociate de Alice

si Bob pentru construirea asocierii de securitate IP Sec):
Algoritmii de criptare care protejeaza datele:
3DES (obligatoriu)
AES CBC 128 (recomandat)
AES CT R 128 (recomandat)
Algoritmi de protectie a integritatii datelor, care produc amprente:
HM AC SHA1 96 (obligatoriu)
AES XCBC 96 (recomandat)
HM AC M D5 96 (optional)
Informatii despre grupul peste care opereaza protocolul Diffie - Hellman:
Grupul 2 unde se calculeaza logaritmi discreti pe 1024 biti (obligatoriu)
Grupul 14 unde se calculeaza logaritmi discreti pe 2048 biti (recomandat)
Curbe eliptice peste GF (2155 ) sau GF (2185 ) (optional)
Generatori de numere pseudoaleatoare:
P RF HM AC SHA1 (conform standardului RF C 2104) (obligatoriu)
P RF AES XCBC P RF 128 (conform standardului RF C 3664) (recomandat)
P RF HM AC M D5 (conform standardului RF C 2104) (optional)
6.5.2
Schimbul de mesaje IKE
Alice (care initiaza comunicarea) propune un set de algoritmi pe care poate sa i suporte
sistemul sau; Bob va selecta din ei algoritmii pe care i agreaza, crend astfel un IKE SA
(asocierea de securitate corespunzatoare IKE). Acesta este utilizat pentru protejarea
negocierii pentru formarea protocolului SA.
In general, doua entitati (de exemplu doua servere IP Sec) pot negocia mai multe
SA-uri.
Comunicarile IKE constau din perechi de mesaje: o cerere urmata de un raspuns.
Primul schimb de mesaje consta totdeauna din doua cereri/raspuns: IKE SA IN IT
si IKE AU T H.
13
IKE-SA-INIT
In acest prim schimb de mesaje, initiatorul Alice si destinatarul Bob negociaza utilizarea
algoritmilor de criptare (definind un IKE SA) si schimba informatiile necesare stabilirii
unui schimb de chei (trimitand nonce-uri si valorile Diffie - Hellman). Cheile alese sunt
utilizate pentru protejarea schimbului urmator IKE AU T H.
La primul pas (Pas 1), Alice trimite un mesaj de forma
HDRkSAA 1kKEA kNA
unde
HDR Zona care contine SP I, numarul versiunii IKE, si alti identificatori
(cum ar fi datele curente pentru KEA si SAA 1).
SAA 1 Informatia propusa de Alice pentru crearea IKE SA: generatorul
de numere pseudo-aleatoare si algoritmii criptografici agreati, precum si grupul
de baza pentru protocolul Diffie - Hellman.
KEA Cheia Diffie - Hellman g a a lui Alice.
NA un nonce generat de Alice (pentru protejarea contra unui atac reply).
Bob raspunde (Pas 2) cu mesajul
HDRkSAB 1kKEB kNB k[CERT REQ]
unde
Continutul HRD, SAB 1, KEB sunt similare cu informatiile analoge ale lui
Alice. Sirul algoritmilor propusi de Bob sunt o selectie din intersectia listei
trimise de Alice si proprii sai algoritmi agreati. Cheia Diffie - Hellman g b si
nonce-ul NB completeaza informatia curenta.
Optional, Bob poate solicita un anumit tip de certificat (de exemplu X.509),
trimitand aceasta cerere n CERT REQ.
Dupa acest prim schimb de mesaje, partenerii au stabilit un IKE SA continut n SAB 1,
neautentificat nca.
Similar, dupa schimbul de chei Diffie-Hellman, ei au generat o cheie de sesiune neautentificata SKEY SEED din care vor deriva ulterior toate cheile necesare pentru IKE SA:
SKe cheia de criptare (cate una pentru fiecare directie);
SKa cheia pentru autentificarea si verificarea integritatii mesajului (cate una pentru
fiecare directie);
SKd cheia pentru derivarea cheilor necesare asocierilor de securitate derivate;
SKp cheia pentru crearea datelor curente din schimbul de mesaje urmator.
De remarcat ca n acest moment Alice si Bob au stabilit algoritmii care vor fi utilizati
n comunicarile ulterioare, dar nca nu s-au autentificat reciproc.
14
IKE-SA-AUTH
In acest al doilea schimb de mesaje Alice si Bob se autentifica reciproc folosind diverse
mecanisme de autentificare (semnaturi digitale, certificate, EAP Extensible Authentication Protocol, chei partajate). Acum se creaza primul IKE SA si asocierea sa de
securitate IP Sec; ele se numesc generic child SA.
Alice trimite (Pas 3) lui Bob
HDRkSK{IDA , [CERT ], [CERT REQ], [IDB ], AU T H, SAA 2, T SA , T SB }
unde:
HDR antetul; include SP I-urile celor doi parteneri, numarul versiunii IKE,
identificatorii de mesaje folositi n IKE SA IN IT .
SK{. . .} se asigura criptarea si integritatea datelor folosind SKe si SKa .
CERT un certificat al lui Alice, eliberat de o entitate P KI.
CERT REQ O lista de autoritati de certificare de ncredere.
IDA , IDB identificatorii celor doi parteneri (Alice, Bob).
AU T H autentificarea (un mesaj semnat).
SAA 2 Informatia propusa de Alice pentru crearea primului childSA; poate
contine de exemplu antetul de autentificare (AH sau ESP ), protocoalele utilizate etc.
T SA , T SB selectori de trafic. Transmit celor doi parteneri adresele de contact,
porturile si protocolul IP folosit.
CERT, CERT REQ si IDB sunt optionale.
Exemplul 6.2. Daca Alice trimite T SA = {192.0.1.0 192.0.1.255},
T SB = {192.0.2.0 192.0.2.255}, nseamn
a c
a ea doreste ca toat
a informatia s
a i
fie trimisa la o adresa IP din domeniul {192.0.1.0 192.0.1.255} si solicit
a ca
tot ce transmite pe adresa lui Bob s
a fie la o adres
a IP din domeniul T SB =
{192.0.2.0 192.0.2.255}.
Bob raspunde (Pas 4) cu mesajul
HDRkSK{IDB , [CERT ], AU T H, SAB 2, T SA , T SB }
unde
HDR include SP I-ul lui Alice si Bob, versiunea IKE si identificatorul de
mesaj trimis de Alice.
15
CERT (optional) este certificatul lui Bob trimis doar la cerere.

AU T H camp utilizat de Bob pentru a se autentifica fata de Alice.
SAB 2 completeaza negocierea pentru crearea child SA, acceptand algoritmi
propusi de Alice si identificand protocolul negociat (AH sau ESP ).
T SA , T SB sunt selectorii de trafic. Daca Bob este de acord cu selectorii propusi
de Alice, aceste valori sunt identice cu cele din mesajul anterior.
De remarcat ca oricare din parti poate initia acest al doilea schimb de mesaje (deci
rolurile lui Alice si Bob pot fi inversate).
Chiar si n cele mai simple scenarii de comunicare, aceste prime patru schimburi de
mesaje (din IKE SA IN IT si IKE SA AU T H) sunt destul de costisitoare ca
resurse. In cele mai multe situatii ele sunt nsa preferabile, deoarece:
1. Desi entitati ca serverele IP Sec consuma timp pentru prelucrarea acestor mesaje,
din informatia obtinuta se pot crea child SA multiple care vor putea fi folosite n
contactele urmatoare, fara a mai trece prin acest start complet.
2. IKE IN IT stabileste un IKE SA care include informatia secreta (partajata)
utilizata n generarea asocierilor de securitate child SA.
3. In IKEv2, primul child SA este creat pe baza schimbului de mesaje IKE SA
AU T H. Celelalte asocieri de securitate child SA vor necesita un singur schimb
de mesaje extrem de simplu si rapid n CREAT E child SA,
CREATE-child-SA
Noul schimb de mesaje dintre parteneri are ca scop generarea unor child SA noi
si modificarea cheilor asocierilor de securitate active. Toate mesajele sunt protejate
criptografic folosind algoritmi de criptare si chei negociate n IKE SA IN IT si
IKE SA AU T H. Totusi, daca se solicita garantii suplimentare de securitate pentru
aceste primitive, CREAT E child SA poate folosi informatii Diffie-Hellman suplimentare pentru a genera chei noi.
Protocolul ncepe cu Alice care trimite mesajul
HDRkSK{[N + ], SA, NA , [KEA ], T SA , T SB }
unde
HDR antet care include SP I-urile celor doi parteneri, numarul de versiune
IKE si identificatorii de mesaj.
SK{. . .} criptarea datelor curente cu cheia SKe si asigurarea integritatii cu
cheia SKa .
16
[N + ] notificare (optionala) care contine detalii suplimentare pentru child

SA.
SA asocierea de securitate propusa de Alice.
NA un nonce.
KEA o valoare noua g a pentru cheia Diffie-Hellman (optional).
T SA , T SB selectori de trafic.
Tot mesajul este criptat si integritatea sa protejata folosind cheile calculate din SKd .
Bob raspunde cu
HDRkSK{[N + ], SA, NB , [KEB ], T SA , T SB }
unde
HDR similar antetului din mesajul primit.
[N + ] notificare (optionala) cu detalii suplimentare pentru child SA.
SA algoritmii pe care i agreaza din asocierea de securitate primita.
NB un nonce propriu.
[KEB ] o noua valoare Diffie-Hellman g b (optional).
TA , T SB selectorii de trafic agreati.
Si acest mesaj este criptat si integritatea sa protejata folosind cheile calculate din
SKd .
Intr-o asociere de securitate, IKE, ESP si AH folosesc cheile secrete doar o perioada
limitata de timp si numai pentru o cantitate limitata de date. Dupa expirarea unui
SA este stabilita o noua asociere de securitate, derivand alte chei din IKE SA sau
child SA.
1. Daca CREAT E child SA este folosit n obtinerea noilor chei pentru IKE SA,
atunci are loc schimbul de mesaje
(a) Alice Bob :
HDRkSK{SA, NA , [KeA ]}
(b) Bob Alice :
HDRkSK{SA, NB , [KeB ]}
2. Daca CREAT E child SA este folosit n obtinerea noilor chei pentru child SA,
atunci are loc schimbul de mesaje
(a) Alice Bob :
HDRkSK{N (REKEY SA), [N + ], SA, NA , [KeA ], T SA , T SB }
(b) Bob Alice :
HDRkSK{[N + ], SA, NB , [KeB ], T SA , T SB }
De remarcat ca Alice identifica child SA ale carui chei trebuie schimbate notificand
datele curente prin N (REKEY SA).
6.5.3
17
Schimbul de informatii n IKE
Dupa crearea unui IKESA, Alice si Bob si pot transmite mesaje de control privind erori
sau diverse notificari. Mesajele schimbate pot fi notificari (N ), stergeri (D) si configurari
de date (Configuration Payloads - CP ).
Schimbul de informatii poate sa nu contina mesaje sa fie doar o verificare daca partenerul
mai este prezent (ceva de tipul Mai esti acolo ?).
Un schimb de informatii este de forma:
Alice
Bob
HDRkSK{[N ], [D], [CP ], . . .}
HDRkSK{[N ], [D], [CP ], . . .}
6.5.4
Generarea componentelor cheii n IKE
Intr-un IKE SA sunt negociati patru algoritmi criptografici: algoritmi de criptare,

de protectia integritatii, grupul Diffie-Hellman si generatorul de numere pseudoaleatoare
(prf ). Componentele cheii pentru toti algoritmii criptografici folositi n IKE SA si
child SA sunt obtinute totdeauna ca iesiri ale unui algoritm prf .
IKEv2 foloseste pentru schimbul de chei numai algoritmul Diffie-Hellman.
Un protocol Diffie-Hellman se bazeaza pe un modul p, un generator g al lui GF (2p ) si
o cheie secreta a, respectiv b 2 . Alice si Bob schimba informatia necesara n IKE IN IT
prin KEA respectiv KEB . Aceasta informatie cuprinde g a , g b si nonce-urile NA , NB .
Cheia comuna de sesiune SKEY SEED este calculata apoi de parteneri dupa formula
SKEY SEED = prf (NA kNB , g ab )
Exemplul 6.3. Sa presupunem ca Alice si Bob au convenit prin schimbul de mesaje din
IKE IN IT la valorile comune p = 47, g = 12.
Alice alege drept cheie secreta a = 3 si nonce NA = 11.
Ea va calcula g a = 123 = 36 (mod 47) si trimite lui Bob KEA = (36, 11).
Bob alege drept cheie secreta b = 5 si nonce NB = 7.
Va calcula g b = 125 = 14 (mod 47) si trimite lui Alice KEB =(14, 7).
a
La primirea lui KEB , Alice calculeaz
a cheia comun
a g b = 143 = 18 (mod 47).
Similar, Bob primeste KEA si calculeaz
a (g a )b = 365 = 18 (mod 47).
Din aceste valori, ambii parteneri determin
a
SKEY SEED = prf (NA kNB , g ab ) = prf (117, 18)
Dupa ce Alice si Bob calculeaza valoarea comuna SKEY SEED, obtin din ea alte
sapte chei:
2
In terminologia IKEv2, a este nlocuit cu i (de la Initiator), iar b cu r (de la Responder).
18
SKd pentru derivarea cheilor noi folosite n child SA.

SKaA si SKaB pentru protejarea integritatii.
SKeA , SKeB pentru criptare si decriptare.
SKpA , SKpB pentru autentificare.
Derivatele lui SKEY SEED sunt calculate astfel:
{SKd kSKaA kSKaB kSKeA kSKpA kSKpB } = prf + (SKEY SEED, NA kNB kSP IA kSP IB )
unde
prf este o functie generatoare de numere pseudoaleatoare; de exemplu P RF
AES XCBC P RF 128 (descrisa de standardul RF C 3664).
SP IA , SP IB sunt parametri de securitate indexati de Alice respectiv Bob.
prf + (K, S) = T1 kT2 k . . . kTn , cu
T1 = prf (SKEY SEED, NA kNB kSP IA kSP IB k0x01),
Ti = prf (SKEY SEED, Ti1 kNA kNB kSP IA kSP IB k0x0i), i > 1
n este ales suficient de mare astfel ca sa se acopere toti bitii necesari definirii celor
7 chei noi.
Observatia 6.1.
1. Fiecare directie de trafic foloseste chei diferite; deci SKeA si SKaA vor proteja
mesajele trimise de Alice, iar SKeB si SKaB pe cele trimise de Bob.
2. Deoarece NA , NB sunt folosite drept chei n prf , aceste nonce-uri trebuie s
a constituie cel putin jumatate din m
arimea cheii din prf -ul negociat.
6.5.5
Generarea componentelor cheii pentru child SA
Daca n CREAT E child SA se genereaza un nou child SA, componentele cheii sunt
generate astfel:
KEY COM P = prf + (SKd , NA kNB )
sau
KEY COM P = prf + (SKd , g ab kNA kNB )
In primul caz, NA si NB sunt nonce-urile generate n comunicarea CREAT E childSA.
In al doilea caz, apare si cheia partajata g ab obtinuta din acelasi schimb de informatii,
componenta legata de Diffie-Hellman.
6.5.6
19
Integritatea si autentificarea n IKE
Pentru autentificare, IKEv2 foloseste algoritmi de semnatura digitala, partajare de secrete si metode EAP (definite n RF C 3748).
Pentru autentifcarea datelor curente, AU T H dispune de doua informatii: metoda de
autentificare folosita si datele de autentificat. IKEv2 foloseste drept metode de autentificare: semnatura digitala RSA, semnatura digitala DSS si codul de integritate a mesajelor
bazat pe partajare.
Pentru a detalia, sa revedem Pasii 1 4 din IKE IN IT si IKE AU T H.
1. La Pasul 3, datele de autentificat pe care Alice le semneaza n AU T H includ
mesajul trimis la Pasul 1, completat cu NB si cu valoarea prf (SKpB , IDBB ). Aceste
ultime doua valori nu au fost trimise explicit ci erau incluse n mesajul semnat
AU T H. IDBB este ID-ul datelor curente ale lui Bob, din care s-a eliminat antetul.
2. Similar, la Pasul 4, datele de autentificat pe care Bob le semneaza n AU T H
includ mesajul trimis la Pasul 2, completat cu NA si cu valoarea prf (SKpB , IDAA ).
Aceste ultime doua valori nu au fost trimise explicit ci erau incluse n mesajul
semnat. IDAA este ID-ul datelor curente ale lui Alice, din care s-a eliminat antetul.
Mesajele din IKEAU T H pot include un certificat sau o autoritate de certificare CA care
legalizeaza semnaturile digitale folosite de parteneri. IKEv2 permite lui Alice sa indice
autoritatile de certificare si tipurile de certificate pe care le foloseste (X.509, P KCS #7,
P GP, DN S SIG etc). Dupa selectarea unui CA, protocolul accepta autentificarile acestuia asupra metodelor folosite.
Daca Alice prefera o autentificare extinsa, ea nu va include la Pasul 3 datele AU T H.
Atunci Bob va include la Pasul 4 un camp EAP si trimite SAB 2, T SA , T SB pana
cand autentificarea este completa.
In aceasta varianta, IKE IN IT si IKE AU T H vor avea forma urmatoare:
1. Alice Bob :
HDRkSAA 1kKEA kNA .
2. Bob Alice :
HDRkSAB 1kKEB kNB k[CERT REQ]
3. Alice Bob :
HDRkSK{IDA , [CERT REQ], [IDB ], SAA 2, T SA , T SB }
4. Bob Alice :
HDRkSK{IDB , [CERT ], AU T H, EAP }
5. Alice Bob :
HDRkSK{EAP }
6. Bob Alice :
HDRkSK{EAP (succes)}
7. Alice Bob :
HDRkSK{AU T H}
8. Bob Alice :
HDRkSK{AU T H, SAB 2, T SA , T SB }
20
6.5.7
Grupul de descriptori Diffie-Hellman
Schimbul de chei Diffie-Hellman este folosit n IKE pentru a genera componentele cheilor.
Dupa nchiderea conexiunii, ambii parteneri uita nu numai cheile folosite, dar si secretele
care au stat la baza calculelor acestora.
IKE foloseste trei reprezentari de grupuri: de exponentiere modulara (numite M ODP ),
grupuri pe curbe eliptice peste GF (2n ) (numite EC2N ) si grupuri pe curbe eliptice peste
GP [P ] (numite ECP ). Pentru fiecare reprezentare sunt posibile diverse implementari, n
functie de parametrii selectati.
Standardele pentru IKEv1 si IKEv2 specifica urmatoarele grupuri:
Grup 2: Grup de exponentiere modulara cu un modul de 1024 biti.
Este definit de:
- generatorul g = 2,
- modulul p = 21536 21472 1 + 264 {[21406 ] + 741804} (primalitatea lui a fost
demonstrata riguros).
Valoarea n hexazecimal a acestui numar este:
FFFFFFFF
29024E08
EF 9519B3
E485B576
EE386BF B
C2007CB8
83655D23
670C354E
FFFFFFFF
8A67CC74
CD3A431B
625E7EC6
5A899F A5
A163BF 05
DCA3AD96
4ABC9804
C90F DAA2
020BBEA6
302B0A6D
F 44C42E9
AE9F 2411
98DA4836
1C62F 356
F 1746C08
2168C234
3B139B22
F 25F 1437
A637ED6B
7C4B1F E6
1C55D39A
208552BB
CA237327
C4C6628B
514A0879
4F E1356D
0BF F 5CB6
49286651
69163F A8
9ED52907
FFFFFFFF
80DC1CD1
8E3404DD
6D51C245
F 406B7ED
ECE45B3D
F D24CF 5F
7096966D
FFFFFFFF

Grup 3: Grup pe o curba eliptica peste GF [2155 ].
Curba eliptica este bazata pe extensia Galois GF [2155 ] generata de polinomul
p(X) = X 155 + X 62 + 1.
Ecuatia curbei este y 2 + xy = x3 + 471951, iar generatorul grupului este punctul
P = (x, y) = (123, 456).
Ordinul acestui grup este 45671926166590716193865565914344635196769237316
care se descompune n factorii primi
22 3 3805993847215893016155463826195386266397436443
Grup 4: Grup pe o curba eliptica peste GF [2185 ].
6.6. SCHIMBUL DE CHEI IKEV 1
21
Standardele ulterioare (RF C 3526) specifica grupuri Diffie-Hellman mai puternice,

echivalente ca nivel de securitate cu sistemul de criptare simetric AES.
Exemplul 6.4. O criptare AES pe 128 biti este echivalent
a cu un grup cu exponentiere
modular
a pe 3200 biti, iar AES pe 192 si 256 biti necesit
a pentru securitate echivalenta
grupuri de nmultire modulara pe 8000 respectiv 15400 biti.
Aceste standarde sunt:
6.6
Schimbul de chei IKEv1
Dupa cum s-a vazut, sistemul de gestiune al cheilor reprezinta o componenta fundamentala
a IP Sec-ului. Reamintim, pentru o sesiune de comunicari ntre Alice si Bob sunt necesare
patru chei.
In general exista doua tipuri de management al cheilor:
Manual: un administrator de sistem configureaza manual fiecare sistem cu fiecare
cheie personala si cu cheile altor sisteme de comunicare;
Automat: un sistem automat permite la cerere crearea de chei pentru SA si
faciliteaza folosirea cheilor ntr-un sistem larg distribuit, cu o configuratie evolutiva.
Managementul de distributie automata de chei folosit n IKEv1 (standard RF C 2408)
este ISAKM P/Oakley si se refera numai la protocolul Diffie-Hellman. El consta din:
1. Oakley Key Determination Protocol.
2. Internet Security Associations and Key Management Protocol (ISAKM P ):
ISAKM P furnizeaza un cadru pentru schimbul de chei prin intermediul retelei
Internet si furnizeaza protocolul de suport specific, incluzand formatele, negocierea
atributelor de securitate etc.
ISAKM P n sine nu aloca un anumit algoritm de generare a cheilor; mai degraba,
el consta dintr-un set de tipuri de mesaje care permite folosirea unui set de algoritmi
de schimb de chei. Oakley este algoritmul de schimb de chei folosit de versiunea
initiala a ISAKM P .
22
6.6.1
Protocolul Oakley de determinare a cheilor
Oakley este un protocol de schimb de chei bazat pe algoritmul Diffie-Hellman.

Algoritmul Diffie-Hellman are doua caracteristici atractive:
1. Cheile secrete sunt generate numai daca si cand este necesar. Nu este nevoie sa
se pastreze cheile secrete o perioada lunga de timp, expunandu-le la vulnerabilitati
ridicate;
2. Schimbul de chei nu necesita nici un fel de infrastructura pre-existenta, nafara unui
acord asupra parametrilor globali.
In general se admite ca exista unele slabiciuni ale protocolului Diffie-Hellman:
Nu furnizeaza nici un fel de informatie despre identitatile partilor.
Nu rezista unui atac man-in-the-middle (lansat de Oscar) de tipul3 :
1. Bob trimite cheia publica eB ntr-un mesaj adresat lui Alice;
2. Oscar intercepteaza acest mesaj, salveaza cheia publica si trimite lui Alice un
mesaj care contine ID-ul lui Bob si cheia publica eO a lui Oscar. Mesajul este
trimis n asa fel ncat apare ca si cum ar fi fost trimis de Bob. Alice primeste
acest mesaj si pastreaza cheia publica a lui Oscar cu ID-ul lui Bob.
Similar, Oscar retine cheia publica eA a lui Alice si trimite lui Bob un mesaj
cu cheia publica eO si ID-ul lui Alice.
3. Bob calculeaza cheia secreta K1 = g eB eO , Alice calculeaza cheia secreta K2 =
g eA eO . Oscar dispunand de cheile publice eA , eB calculeaza ambele chei de
sesiune K1 si K2 .
4. De acum Oscar este capabil sa transporte mesaje de la Alice la Bob si invers,
schimbandu-le modul de criptare pe traseu, n asa fel ncat nici Alice si nici
Bob nu vor sti ca informatiile lor sunt citite de altcineva.
Este un calcul intensiv. Prin urmare, este vulnerabil la un atac prin colmatare
(clogging), n care un oponent cere un numar foarte mare de chei. Victima consuma
resurse de calcul considerabile (facand exponentieri modulare) n locul unei activitati
reale.
Prin structura sa, Oakley este proiectat sa retina avantajele lui Diffie-Hellman si sa combata slabiciunile sale.
3
132.
Protocolul este o variant

a a atacului man-in-the middle pentru chei publice, prezentat n [1], pag.
23
Caracteristicile algoritmului Oakley

Algoritmul Oakley prezinta cinci proprietati importante:
1. Are un mecanism cunoscut sub numele de cookie pentru contracararea atacurilor
prin colmatare (valorile NA , NB din IKE SA IN IT ).
2. Permite celor doua parti sa negocieze o structura de grup, specificand parametrii
globali ai algoritmului de schimb de chei Diffie-Hellman.
3. Foloseste un nonce pentru a elimina atacurile prin replay.
4. Permite schimbul de valori de chei pentru Diffie-Hellman.
5. Autentifica schimbul de chei Diffie-Hellman pentru a elimina atacurile man-in-themiddle.
Exemplul 6.5. Intr-un

atac prin colmatare, Oscar afl
a adresa surs
a a unui user legitim
si i trimite cheia publica Diffie Hellman. Victima calculeaz
a o exponentiere modulara
pentru calcularea cheii secrete. Valorile NA , NB (cookie) din mesajele IKE SA IN IT
asigur
a ns
a un singur calcul pentru SKEY SEED.
Oakley foloseste pentru schimbul de chei Diffie-Hellman urmatoarele grupuri:
Exponentiere modulara pe 768 biti
p = 2768 2704 1 + 264 b2638 c + 149686
g = 2.
p = 21024 2960 1 + 264 b2894 c + 129093
g=2
Grup aditiv pe curbe eliptice peste GF (2155 ):
- Generator (hexadecimal): (X, Y ) = (7B, 1C8)
- Curba (hexadecimal): y 2 = x3 + 7338.
Grup aditiv pe curbe eliptice peste GF (2185 ):
- Generator (hexadecimal): (X, Y ) = (18, D)
- Curba (hexadecimal): y 2 = x3 + 1EE9.
24
Primele trei grupuri implementeaza algoritmul Diffie-Hellman folosind exponentiere modulara, iar ultimele doua grupuri aplica Diffie-Hellman pe curbe eliptice.
Oakley foloseste un numar prim mpotriva atacurilor prin replay. Fiecare numar este
un pseudoaleator generat local. Numerele apar n raspunsuri si sunt criptate de-a lungul
anumitor portiuni a schimbului de mesaje.
Pentru autentificare, Oakley foloseste trei metode distincte (pentru fiecare existand
diverse variante):
1. Semn
aturi digitale: Schimbul de chei este autentificat prin semnarea unei amprente; fiecare entitate cripteaza amprenta cu cheia sa privata. Amprenta este generata peste parametri importanti ai comunicarii, cum ar fi ID User si nonce-uri.
2. Criptare cu cheie public
a: Schimbul este autentificat prin criptarea parametrilor
(ID-uri, nonce-uri) cu cheia privata a lui Alice
3. Criptare cu cheie simetric
a: O cheie generata de un mecanism extern poate fi
folosita pentru autentificare schimbului de mesaje, prin criptarea simetrica a schimbului de parametri.
Exemplu de schimb de chei Oakley
Prezentam schimbul de chei n specificatii (varianta agresiva) numit astfel datorita
celor trei mesaje care sunt schimbate ntre parteneri.
1. Alice
Bob :
CKA , OK KEY, GRP, g a , EHAO, N IDP, IDA , IDB , NA ,

SKA (IDA kIDB kNA kGRP kg a kEHAO)
2. Alice
Bob :
CKB , CKYA , OKKEY, GRP, g b , EHAS, N IDP, IDB , IDA ,

NB , NA , SKB IDB kIDA kNB kNA kGRP kg b kg a kEHAS

3. Alice
Bob :
CKA , CKYB , OKKEY, GRP, g a , EHAS, N IDP, IDA , IDB ,

NA , NB , SKB IDA kIDB kNA kNB kGRP kg a kg b kEHAS
unde
CKA , CKB Cooky-urile celor doi parteneri (pachete de date care contin informatii
despre SA si schimbul curent de chei);
CKYA , CKYB Ecouri ale acestor cookie;
OK KEY Tipul mesajului de schimb de chei;
GRP Tipul grupului peste care este definit protocolul Diffie-Hellman;
25
g a , g b Cheile publice ale lui Alice respectiv Bob;

EHAO, EHAS Pachete cu functii de criptare, dispersie si autentificare propuse,
respectiv selectate;
N IDP Indica faptul ca restul mesajului nu este criptat;
IDA , IDB ID-urile lui Alice si Bob;
NA , NB nonce-uri generate aleator de Alice respectiv Bob;
SKA (), SKB () semnatura mesajului de catre Alice respectiv Bob, folosind
cheia privata KA (KB ).
Comentarii:
1. La primul pas Alice transmite un cookie, grupul care va fi folosit si cheia sa publica
Diffie-Hellman. Alice mai indica functia de dispersie si algoritmii de autentificare
folositi n acest schimb.
Totodata ea include n mesaj si identificatorii pentru Alice si Bob si nonce-ul ei
pentru acest schimb.
In final, Alice adauga o semnatura folosind cheia sa privata, prin care semneaza cei
doi identificatori, nonce-ul, grupul cheia publica Diffie-Hellman si algoritmii respectivi.
2. Cand Bob primeste mesajul, el verifica semnatura folosind cheia publica de semnatura
a lui Alice. Daca totul este n regula, Bob raspunde cu ecoul unui cookie, identificatorul lui Alice, un nonce si grupul agreat. Bob include de asemenea n mesaj propriul
cookie si identificator, cheia sa publica Diffie-Hellman, algoritmii selectati si propriul
nonce. In final, Bob adauga o semnatura folosind cheia sa privata, care semneaza
cei doi identificatori, cele doua nonce-uri, grupul, cheile publice Diffie-Hellman si
algoritmii selectati.
3. Cand Alice primeste al doilea mesaj, ea verifica semnatura folosind cheia publica a
lui Bob.
Valorile numerice din acest mesaj asigura ca nu este un replay al unui mesaj mai
vechi.
Pentru ca schimbul sa fie complet, Alice trebuie sa trimita un mesaj lui Bob, pentru
a certifica faptul ca a primit cheia publica.
26
6.6.2
ISAKM P
ISAKM P defineste proceduri si formate de pachete de date pentru a stabili, negocia,

modifica si sterge asocieri de securitate.
Fiind o componenta a stabilirii unui SA, ISAKM P defineste pachete de date curente
pentru schimbul de chei generate si de autentificare a datelor.
Formatul Antetului ISAKM P
Un mesaj ISAKM P este compus dintr-un antet ISAKM P urmat de unul sau mai multe
date curente, toate ncapsulate ntr-un protocol de transport.
Cookie de initiere
Cookie de raspuns
Next payload MjVer MnVer Tip de schimb
Flags
ID - mesaj
Lungime
Campurile acestui antet ISAKM P sunt:
Cookie de initiere (64 biti): reprezinta cookie-ul lui Alice (care initiaza, notifica sau
elimina un SA).
Cookie de raspuns (64 biti): cookie-ul lui Bob, care raspunde; n primul mesaj trimis
de Alice, el este null.
Next Payload (8 biti): indica tipul primului pachet de date curente din mesaj.
MjVer (4 biti): indica versiunea curenta de ISAKM P .
MnVer (4 biti): indica versiunea secundara de folosire ISAKM P .
Tip de schimb (8 biti): indica tipul de schimb.
Flags (8 biti): indica optiunile specifice acestui schimb de mesaje ISAKM P . Cel
putin doi biti sunt deja definiti: bitul de criptare este setat daca toate datele
curente de dupa antete sunt criptate folosind unul din algoritmii de criptare asociati
acestui SA, si bitul de asociere folosit pentru a asigura ca mesajul criptat nu este
primit naintea stabilirii unui SA.
ID - mesaj (32 biti): un ID unic pentru acest mesaj.
27
Lungime (32 biti): lungimea totala a mesajului (antet plus toate datele curente
asociate) n octeti.
Tipuri de date curente
Toate datele curente din ISAKM P ncep cu acelasi antet generic:
0
8
16
Next payload
REZERVAT
31
Lungime
Next Payload: are valoarea 0 daca acesta este ultimul set de date curente din mesaj;
altfel valoarea sa este tipul urmatorului set de date curente.
Lungime: indica lungimea n octeti a setului de date curente, inclusiv antetul
generic.
Sunt posibile urmatoarele tipuri de date curente:
1. Date SA (SA): folosit pentru nceperea negocierii unei asocieri de securitate. Drept
parametri se folosesc: Domeniu de interpretatare (DOI) sub care are loc negocierea, si Situatia n care are loc negocierea.
2. Date Propuse (P ): contine informatii folosite n timpul negocierii SA-ului. Setul
de date curente indica protocolul pentru acest SA (ESP sau AH) pentru care sunt
negociate serviciile si mecanismele. Aici mai sunt incluse SP I (identitatea lui Alice)
si numarul de transformari. Fiecare transformare este continuta ntr-un set de date
curente de transformare.
3. Date de transformare (T ): defineste o transformare de securitate folosita pentru
securizarea canalului de comunicatii. Parametrii folositi sunt: Transform Number care serveste pentru identificarea acestui set de date, astfel ca Bob sa l
poata folosi pentru a identifica acceptarea acestei transformari; Transform - ID
si SA - Attributes identifica o transformare specifica (de exemplu 3DES pentru
ESP, HM AC SHA 1 96 pentru AH) mpreuna cu atributele asociate (de
exemplu lungimea amprentei).
4. Date pentru schimb de chei (KE): este utilizat pentru o paleta larga de tehnici
de schimb de chei, inclusiv protocoalele Oakley, Diffie-Hellman si RSA. Are un singur parametru (Key Exchange data) care contine datele necesare pentru generarea
unei chei de sesiune si este dependent de cheia algoritmului de schimb utilizat.
5. Date de identificare (ID): este folosit pentru a determina identitatea comunicarii
si eventual pentru autentificarea informatiei. Are doi parametri: ID - Type
si ID - Data (de obicei aici este o adresa IP v4 sau IP v6).
28
6. Certificat (CERT ): specifica un certificat de cheie publica. Are doi parametri,

Certificate Data si Certificate Encoding. Ultimul indica tipul certificatului si
contine elemente din lista:
P KCS#7 mpachetat cu certificatul X.509;
Certificat P GP ;
Cheie de semnatura DN S;
Certificat de semnatura X.509;
Certificat de schimb de chei X.509;
Token-uri Kerberos;
CRL (Lista certificatelor revocate);
ARL (Lista autoritatilor revocate);
Certificatul SP KI
7. Cerere de certificare (CR): Intr-un schimb ISAKM P Alice poate include n
orice moment o solicitare a certificatului lui Bob sau al altei entitati de comunicare.
8. Date de dispersie (HASH): contine amprente generate de o functie de dispersie
peste unele parti ale mesajului si/sau stari ISAKM P . Acest tip de date curente
este folosit pentru verificarea integritatii datelor din mesaj si este util n special
pentru serviciile de non-repudiere.
9. Date de semn
atur
a (SIG): contine rezultatul unei functii de semnatura digitala.
10. Date de notificare (N ): contine mesaje de eroare sau informatii despre statusul
asociat SA-ului respectiv sau SA-ului de negociere. ISAKM P admite urmatoarele
mesaje status: Connected, Responder-Lifetime (durata de viata a SA-ului, decisa de
Bob), Replay-status (pentru confirmari pozitive din partea lui Bob), Initial-Contact
(pentru informarea partenerului ca acesta este primul SA stabilit cu sistemul).
11. Date de sters (D): indica SA-uri pe care Alice le-a sters din baza sa de date (si
deci nu mai sunt valabile).
Comunicatii ISAKM P
ISAKM P ofera un cadru pentru schimbul de mesaje, cu tipurile de date curente servind
ca blocuri de constructie. Conform specificatiilor sunt posibile cinci tipuri de schimburi:
1. Base Exchange: permite schimbul de chei si autentificarea datelor curente care vor
fi transmise mpreuna. Acest lucru minimizeaza numarul schimburilor de mesaje.
29
(1)
(2)
(3)
Alice Bob : SA; N once

Bob Alice : SA; N once
Alice Bob : KE; IDA ; AU T H
(4)
Bob
Alice : KE; IDB ; AU T H
Incepe negocierea ISAKM P SA.

Se cade de acord asupra bazei SA.
Se trimite cheia generata.
Bob verifica identitatea lui Alice.
Alice verifica identitatea lui Bob
Se ncheie stabilirea SA.
Primele doua mesaje furnizeaza cookie-uri si stabilesc tipul de protocol SA; ambele
parti folosesc un nonce pentru a se proteja mpotriva atacurilor prin replay. Ultimele
doua mesaje stabilesc cheia de criptare si verifica autenticitatea userilor, folosind un
protocol de autentificare bazat pe ID-uri si informatiile din primele doua mesaje.
2. Identity Protection Exchange: este o varianta extinsa a tipului anterior, pentru
a ntari protejarea identitatilor celor doi utilizatori 4 .
(1)
(2)
(3)
(4)
(5)
(6)
Alice Bob : SA
Bob Alice : SA
Alice Bob : KE; N once
Bob Alice : KE; N once
Alice Bob : IDA ; Auth
Bob Alice : IDB ; Auth

Se cade de acord asupra bazei SA.
Alice verifica identitatea lui Bob.
Primele doua mesaje stabilesc asocierea de secruitate. Urmatoarele doua mesaje

asigura schimbul de chei, folosind si nonce-uri, pentru protectie la atacul prin
raspuns. Dupa ce cheia de sesiune a fost calculata, cei doi parteneri schimba mesaje
criptate care contin informatii de autentificare (semnaturi digitale, certificate de
validare a cheilor publice etc).
3. Authentication Only Exchange: este utilizat pentru a realiza o autentificare
uniforma, fara schimburi de chei.
(1)
(2)
(3)

Alice Bob : SA; N once
Bob Alice : SA; N once; IDB ; Se cade de acord asupra bazei SA.
AU T H
Alice Bob : IDA ; AU T H
Primele doua mesaje stabilesc SA-ul. In plus, Bob foloseste al doilea mesaj pentru
a transmite ID-ul sau si un nonce poentru autentificare. Alice trimite un al treilea
mesaj pentru a transmite prin ID propria sa autentficare.
4. Aggressive exchange: minimizeaza numarul schimburilor de mesaje, cu pretul
nefurnizarii protectiei identitatii.
4
Notatia semnific
a faptul c
a datele curente sunt criptate dupa antetul ISAKM P .
30

(1)
(2)
(3)
Bob : SA; KE; N once; Incepe negocierea ISAKM P SA

IDA
si schimbul de chei.
Bob Alice : SA; KE; N once; Se cade de acord asupra bazei SA.
IDB ; AU T H
Alice Bob : AU T H
Alice
In primul mesaj, Alice propune un SA mpreuna cu protocolul asociat si optiunile

de transformare; n paralel ea lanseaza schimbul de chei si furnizeaza propriul ID.
In al doilea mesaj, Bob indica acceptul SA-ului cu un anumit protocol si transformare, completeaza schimbul de chei si autentifica informatia primita.
Cu al treilea mesaj, Alice transmite un rezultat autentificat care acopera informatiile
anterioare; acest mesaj este criptat folosind cheia secreta comuna de sesiune.
5. Information Exchange: contine o transmitere one-way a informatiei pentru managementul SA.
(1) Alice Bob N/D :
Anunta o eroare, o notificare de status
sau o stergere.
6.7
6.7.1
Analiza IP Sec
Performante IP Sec
Atunci cand se foloseste IP Sec, dimensiunea pachetului IP creste din cauza adaugarii
antetelor specifice (ESP, AH, noul antet IP n cazul modului tunel). Acest lucru duce la
cresterea raportului ntre dimensiunea antetelor si cea a datelor, reducand banda efectiva
de comunicare.
In plus, timpul necesar pentru constructia antetelor si aplicarea algoritmilor criptografici conduce la o ntarziere suplimentara n transmisia pachetelor.
Acest dezavantaj devine suparator mai ales cand capacitatile de procesare sunt mici.
6.7.2
Complexitate IP Sec
IP Sec prezinta dezavantajul unei complexitati extrem de mari; este pretul platit
pentru numarul mare de optiuni si de flexibilitatea sa mult crescuta.
Complexitatea reprezinta un dusman al securitatii, din mai multe puncte de vedere.
Algoritmii complecsi conduc la erori greu de remediat. In plus, un sistem complex
este mult mai dificil si mai costisitor de realizat si ntretinut.
De multe ori exista mai multe posibilitati de a implementa facilitati identice sau
similare.
6.7. ANALIZA IP SEC
31
Definirea standardului actual IP Sec de catre un comitet nu s-a dovedit a fi o alegere

prea fericita. De aceea, pentru alegerea urmatoarelor standarde de securitate s-a
ales varianta unui concurs, la care sa participe diverse colective.
In mod normal, un soft este realizat n urma unei metodologii de tip ncearca-sirepara. Detaliind, mici bucati de cod sunt implementate, testate si n cazul n
care apar erori fixate din nou. Aceste componente sunt apoi combinate n module
mai mari, carora la randul lor li se aplica acelasi tratament. Rezultatul constituie
de multe ori un produs mai putin functional decat cel asteptat initial.
Acest mod de constructie are un efect devastator asupra sistemelor de securitate.
Motivul principal este acela ca securitatea unui sistem nu poate fi testata prea usor,
iar daca partile sistemului sunt considerate ca fiind independente, analiza este si
mai dificila.
Singura modalitate de a testa securitatea unui sistem este aceea de a realiza analize care
necesita mult timp si efort. Daca se considera un sistem cu n optiuni diferite, fiecare cu
2 posibilitati de alegere, atunci sunt n(n 1)/2 = O(n2 ) perechi diferite de optiuni care
pot interactiona n moduri diferite si 2n configuratii posibile. Fiecare dintre acestea este
posibil sa conduca la o falie de securitate. Se asteapta deci ca numarul de puncte slabe
n securitate sa creasca foarte rapid odata cu complexitatea.
In concluzie, sistemele de securitate trebuie construite cat mai simplu cu putinta.
IP Sec este mult prea complex pentru a fi considerat cu adevarat sigur.
6.7.3
Documentatie IP Sec
Documentatia IP Sec este stufoasa si foarte dificil de nteles. Ca o parere generala,

ntelegerea IP Sec din documentatie este practic imposibila, parti ale acesteia fiind foarte
greu de citit.
O lipsa majora a documentatiei este nespecificarea clara a scopurilor IP Sec. Desi
unele dintre acestea sunt destul de evidente, de multe ori administratorii sunt lasati sa
le deduca singuri. Astfel, un designer care doreste sa utilizeze IP Sec si nu cunoaste
exact functionalitatile sale, poate realiza un sistem care sa nu atinga nivelul de securitate
considerat.
Afirmatia ca IP Sec ofera securitate la nivel IP poate conduce la o folosire neadecvata
a sa. Se poate considera n mod eronat ca el este util ca sistem de securitate la
nivel aplicatie (de exemplu la autentificarea unui user pentru citirea e-mail-ului). IP Sec
autentifica pachetele ca provenind de la cineva care cunoaste o anumita cheie, chiar daca
se poate crede ca autentifica o anumita adresa IP (cum poate fi de exemplu autentificarea
prin trecerea printr-un firewall). Astfel de interpretari gresite ale IP Sec pot conduce la
erori.
32
6.7.4
Eliminarea functionalit
atilor duplicate
IP Sec are doua moduri de operare (transport si tunel) si doua protocoale (AH si ESP ),
fapt ce conduce la o complexitate ridicata. Doua servere care doresc sa comunice pot
alege ntre 4 modalitati diferite. Diferenta dintre acestea este minora, atat din punct de
vedere al functionalitatii cat si din punct de vedere al performantei.
Exista propunerea a renunta la modul transport, fapt care ar conduce eliminarea
diferentelor dintre echipamentele de retea n host-uri si porti de securitate (security gateways). Principala diferenta dintre acestea este ca portile de securitate nu pot opera n
modul transport.
Multi dintre cei care au analizat IP Sec sunt de parere ca protocolul AH poate fi
eliminat. Functionalitatile oferite de AH si ESP sunt similare. In modul transport, AH
ofera o autentificare mai puternica ntrucat autentifica si campuri ale antetului IP . Dar
utilizat n mod tunel ESP ofera acelasi nivel de autentificare.
Protocolul AH autentifica indirect si antetele de la nivelele inferioare, fapt care atrage
dupa sine o multitudine de probleme, fiindca exista campuri care se pot modifica pe
parcursul drumului de la sursa la destinatie. Deci protocolul AH trebuie sa fie constient
de ce se ntampla la nivelele inferioare, pentru a evita utilizarea acestor campuri. Ca o
consecinta, constructia obtinuta este total neeleganta, cu probleme la extensiile viitoare
ale protocolului IP care pot adauga campuri pe care AH le ignora.
6.7.5
Utilizarea deficitar
a
Protocolul ESP permite ca atat autentificarea cat si criptarea sa fie optionale.

Astfel, un administrator de sistem poate sa configureze prost IP Sec: el este constient
ca are nevoie de criptare pentru asigurarea confidentialitatii datelor, deci activeaza criptarea,
nsa lasa dezactivata optiunea de autentificare.
Un alt exemplu de implementare deficitara este legata de alegerea gresita a algoritmilor
criptografici. O buna implementare pentru IP Sec impune ca toti algoritmii criptografici
utilizati sa permita un nivel adecvat de securitate n toate situatiile. Algoritmii criptografici buni sunt disponibili si nu este nici un motiv sa se utilizeze algoritmi slabi.
6.7.6
Ordinea operatiilor de securitate
Atunci cand sunt realizate atat autentificarea cat si criptarea, IP Sec realizeaza ntai
criptarea si apoi autentificarea textului criptat. Ordinea este exact inversa fata de cea
normala: mai ntai trebuie realizata autentificarea textului clar, si apoi se cripteaza textul
autentificat.
Autentificarea textului dupa criptare are totusi un avantaj: receptorul sterge pachetele
de date care nu se pot autentifica rapid, fara a fi nevoie de decriptarea lor. Acesta poate
constitui un avantaj n cazul atacurilor de tip DoS (Denial of Service), cand un numar
6.7. ANALIZA IP SEC
33
mare de pachete neautentificate ar putea ocupa resursele disponibile o perioada lunga de

timp.
6.7.7
Simetrizarea SA-urilor
Un SA (Security Association) poate fi folosit numai ntr-o directie; deci pentru o comunicare bidirectionala sunt necesare doua SA-uri. Fiecare din ele implementeaza un singur
mod de operare si un singur protocol. Daca se folosesc doua protocoale (AH si ESP )
pentru un acelasi pachet, atunci sunt necesare 2 SA-uri. Utilizarea a doua protocoale si
a doua moduri de operare conduce la cresterea complexitatii SA-urilor.
In practica exista foarte putine situatii n care traficul este necesar sa fie securizat
ntr-o singura directie. De aceea, SA-urile sunt negociate n pereche. Pare mult mai logic
ca SA-urile sa devina bidirectionale; astfel s-ar njumatatii numarul de SA-uri din sistem
si s-ar evita de asemenea configurari asimetrice, care pot fi uneori suparatoare.
6.7.8
SP D (Security Policy Database)
Politicile de securitate sunt stocate n SP D (Security Police Database). Pentru fiecare

pachet de date transmis, se verifica cum trebuie procesat. SP D-ul poate specifica 3
actiuni: poate arunca pachetul, poate lasa pachetul sa treaca fara sa i aplice IP Sec, sau
poate sa i aplice IP Sec.
In ultimul caz se specifica si ce SA se foloseste.
Acesta este un mecanism extrem de flexibil, care permite un control la nivelul fiecarui
pachet. Depinde de SP D daca ntreg traficul utilizeaza acelasi SA sau daca se genereaza
SA-uri diferite pentru aplicatii diferite sau pentru fiecare conexiune T CP diferita.
Exista un surplus de informatie, ceea ce ofera destul de multa informatie unui eventual
atacator.
De aceea, se considera ca rolul SP D-ului este strict acela de a determina daca un
pachet trebuie aruncat, daca trebuie transmis fara IP Sec, daca se autentifica sau daca
se autentifica si cripteaza. Nu este necesar sa se stie daca pentru mai multe pachete se
utilizeaza sau nu acelasi SA.
6.7.9
Incompatibilit
ati cu Internet Protocol
S. Kent si R. Atkinson sugereaza ([14]) ca exista anumite incompatibilitati ntre IP Sec

si IP . In acest sens se considera doua echipamente situate la o mare distanta unul de
celalalt, care doresc sa comunice n modul tunel. Intre acestea exista o multime de routere
care nu cunosc existenta SA-urilor si care trebuie sa transmita pachetele. Orice mesaj de
tip ICM P este neautentificat si necriptat; deci orice astfel de mesaj va fi aruncat, fapt
care conduce la pierderea functionalitatii IP .
34
Chiar daca pe routere se implementeaza IP Sec, tot nu se pot autentifica mesajele

ICM P decat daca acestea si seteaza SA cu capetele tunelului, cu scopul trimiterii pachetului ICM P . Dar acesta trebuie sa fie sigur ca primeste mesaje de la un router
veritabil, ceea ce nu poate verifica decat eventual cu P KI, lucru inexistent la acest nivel.
6.7.10
Atacuri
Duplicarea mesajelor
In mod ideal, daca se transmit mai multe copii ale aceluiasi mesaj, atunci raspunsurile
trebuie sa fie identice. Mai mult, sistemul ar trebui sa recunoasca faptul ca primeste copii
identice si sa replice primul raspuns transmis.
O implementare mai putin atenta poate crea falii de securitate. De exemplu, se transmit mai multe mesaje cu zona de date modificata. Se presupune ca implementarea Diffie
- Hellman modulo p se realizeaza peste un subgrup de dimensiune q, unde q|p 1 si p 1
are multi divizori mici. Oscar poate determina cheia secreta prin repetarea datelor KE
care contin elemente de ordin mic si verificand care din setul de chei posibile este utilizat
la criptare. Aceasta i releva ordinul elementului trimis ca date KE.
Combinand mai multe rezultate, se determina cheia secreta Diffie - Hellman.
Atacul de tip DoS
Utilizarea elementelor de tip cookie elimina o parte din atacurile de tip DoS.
Masura implica cresterea n dificultate a realizarii unui astfel de atac, dar nu-l elimina
n totalitate. Impactul introducerii acestor mijloace de aparare are ca revers cresterea
complexitatii.
6.8
Concluzii
Cu toate criticile care i se aduc, IP Sec constituie cel mai bun protocol de securitate
existent n momentul de fata.
Comparat cu alte protocoale de securitate, IP Sec ofera multe avantaje din punct de
vedere arhitectural si o foarte mare flexibilitate. Detaliile securitatii retelei sunt de obicei
ascunse aplicatiilor. In plus, IP Sec poate fi transparent si utilizatorilor finali, eliminand
necesitatea instruirii persoanelor n vederea utilizarii mecanismelor de securitate.
Un canal sigur poate fi configurat de la un cap la altul (protejand traficul dintre doua
entitati), route-to-route (protejand traficul care trece peste o multime particulara de
legaturi) etc.
Deci IP Sec poate realiza securizarea utilizatorilor individuali (daca acest lucru este
necesar).
Bibliografie
[1] Atanasiu, A. Securitatea Informatiei, vol. 1 (Criptografie), ed. InfoData, Cluj 2007
[2] Craig A. Shue, Minaxi G. IPSec: Performance Analysis and Enhancements,
http://www.csiir.ornl.gov/shue/research/icc07.pdf
[3] Stallings, W. Network Security Essentials, Applications and Standards, Third Edition,Pearson Prentice Hall, 2007
[4] Stallings, W. Cryptography and Network Security Principles and Practices, Fourth
Edition, Prentice Hall, 2005
[5] Ferguson, N., Schneier, B. A cryptographic Evaluation of IPSec,
http : //www.schneier.com/paper IP Sec.pdf
[6] Frankel, S., Herbert, H. (2003) The AES-XCBC-MAC-96 algorithm and its use
with IPSec (RFC 3566), http : //www.ietf.org/rf c/rf c3566.txt?number = 3566
[7] Gleeson, B., Lin A., Heinanen, J., Armitage, G., Malis, A. (2000) A framework for
IP based virtual private networks (RFC 2764),
http : //www.ietf.org/rf c/rf c2764.txt?number = 2764
[8] Hoffman, P. (2004) The AES-XCBC-PRF-128 algorithm fo the internet key exchange protocol (IKE) (RFC 3664),
[9] Hoffman, P. (2005) Cryptographic suites for IPSec (RFC 4308),
[10] Kaufman, C. (Ed.). (2005) Internet key exchange (IKEv2) (RFC 4306),
[11] Kent, S. (2005a) IP Authentication header (RFC 4302),
[12] Kent, S. (2005b) IP Encapsulating security payload (ESP) (RFC 4303),
35
36
BIBLIOGRAFIE
[13] Kent, S., Seo, K. (2005) Security architecture for the Internet protocol (RFC 4301),
[14] Kent, S., Atkinson, R. Security Architecture for Internet Protocol.
[15] Kivinen, T., Kojo, M. (2003) More modular exponential (MODP) Diffie-Hellman
Groups for IKE (RFC 3526), http://www.ietf.org/rfc/rfc3526.txt?number=3526
[16] Perlman, R., Kaufman, C. Analysis of the IPSec Key Exchange Standard,
http://warlord.nologin.org/papers/IPSec-analysis.pdf
[17] Orman, H. (1998) The OAKLEY key determination protocol (RFC 2412),
http://www.ietf.org/rfc/rfc2412.txt?number=2412
[18] Schiller, J. (2005) Cryptographic algorithms for use in the Internet key exchange
version 2 (IKEv2) (RFC 4307), http://www.ietf.org/rfc/rfc4307.txt?number=4307
[19] An Introduction to IP Security Encryption (IPSec Negotiation/IKE Protocols) Cisco
Systems, http://www.cisco.com/en/US/tech/tk583/tk372/technologies tech note
09186a0080094203.shtml
[20] Red ISAKMP and Oakley Information, http://www.cisco.com/en/US/tech/tk583/tk372/
technologies tech note09186a0080093c2b.shtml
[21] Group Domain of Interpretation (GDOI), http://en.wikipedia.org/wiki/GDOI
[22] ISAKM P , http://en.wikipedia.org/wiki/ISAKMP
[23] Securing Data in Transit with IPSec,
http://www.windowsecurity.com/articles/Securing Data in Transit with IPSec.html
[24] H3C ItoIP Solutions Expert, http://www.h3c.com/portal/Products Solutions/
Technology/Security and VPN/Technology Introduction/200701/195610 57 0.htm
[25] IPSec, http://cis.poly.edu/ ross/networksecurity/IPSec.ppt
[26] An Illustrated Guide To IPSec, http://unixwiz.net/techtips/iguide-IPSec.html
Capitolul 8
Alte protocoale de securitate
8.1
Introducere
Cresterea volumului de comert on-line solicita utilizarea de protocoale care trebuie sa

asigure o multitudine de operatii de securitate. Astfel, n desfasurarea unei tranzactii,
cumparatorul va trebui sa ofere datele cardului sau pentru a plati un produs. De asemenea, vanzatorul trebuie sa se asigure ca are de-a face cu un cumparator real caruia i
trimite produsul. Aceste informatii transmise printr-o retea nesigura cum este Internetul, genereaza multa reticenta si utilizatorii trebuie sa fie siguri ca sunt suficient de bine
protejati.
De aceea, pentru securizarea datelor necesare unei tranzactii (confidentialitate, autentificare si non-repudiere) s-au dezvoltat de-a lungul timpului o serie de protocoale.
Cele mai utilizate n perioada actuala sunt SSL (Secure Socket Layer) construit de
Netscape si standardul Internet al SSL, cunoscut sub numele T LS (Transport Layer
Security). Ambele sunt implementate pe toate browserele Web, desi sub forme diferite;
deci companiile trebuie sa dezvolte aplicatii SSL distincte pentru Netscape si Internet
Explorer.
In acest moment exista doua versiuni SSL: SSL 2.0 care suporta doar autentificarea
serverului si SSL 3.1 care autentifca atat serverul cat si clientul. Variantele T LS 1.0 si
1.1 realizeaza de asemenea ambele autentificari.
T SL si SSL permit utilizatorilor sa-si defineasca nivelul de securitate pe care-l doresc.
Ambele sunt standarde industriale si sunt folosite n milioane de tranzactii Internet. Utilizatorii pot selecta RC4, DES, 3DES sau AES pentru criptare, RADIU S (username
si password), RSA SecurID (username si token+pin) pentru autentificare, sau pot folosi
chiar certificate digitale X.509.
O comunicare sigura client-server solicita autentificarea ambelor parti, un schimb de
chei criptografice care conduc la o pre-cheie master agreata de ambii parteneri si o criptare
a datelor bazata pe chei generate din pre-cheia master. Cand un client si un server sunt
1
CAPITOLUL 8. ALTE PROTOCOALE DE SECURITATE
de acord sa comunice pe baza unui protocol SSL sau T SL, ei trebuie sa cada de acord
(prin protocoale de tip handshake1 ) si asupra altor puncte:
1. Protocolul si versiunea (T SL 1.0, T SL 1.1, SSL2, SSL3).
2. Sistemul de criptare.
3. Daca vor autentificare sau nu.
4. Sistemul de criptare cu cheie publica folosit pentru generarea pre-cheii master.
5. Cum se vor genera cheile de sesiune pentru criptarea mesajelor.
Anvantaje al protocoalelor SSL si T LS:
Asigura o confidentialitate si o integritate a datelor convenabila.
Au abilitatea de a negocia chei de criptare unice, ntre parteneri care nu au comunicat anterior.
Se pot aplica independent, toate deciziile privind detaliile de aplicare fiind luate in
mod amiabil (handshacking).
8.2
T SL
Un protocol T LS este format din doua etape, privite ca o stiva cu doua straturi (layers):
protocolul T LS de nregistrare si cel de handshaking.
Protocolul T LS de nregistrare ia mesajele care trebuie transmise, fragmente de date
din diverse blocuri interne, le arhiveaza (optional), aplica o functie M AC, le cripteaza si
transmite rezultatul.
Protocolul handshaking permite serverului si clientului sa se autentifice reciproc si sa
negocieze un algoritm de criptare si o cheie de criptare, nainte de a se transmite/primi
prinul bit de date.
In T LS este stabilita ntai o sesiune ntre client si server, iar apoi se realizeaza o
conexiune.
Definitia 8.1. O sesiune T LS este o asociere ntre un client si un server, cu scopul
de a defini un set de parametri de securitate pentru o perioad
a mai lung
a. Sesiunile sunt
create prin protocoale de tip handshaking, scopul lor fiind de a evita negocieri lungi pentru
stabilirea parametrilor de securitate la fiecare conexiune.
1
Un protocol handshake este un set de comenzi ntre doi parteneri, cu scopul de a controla fluxul de
informatii transmise. Este un protocol simplu de comunicare, care nu solicita autentificarea partenerilor.
8.2. T SL
Definitia 8.2. O conexiune este un transport care ofer

a anumite tipuri de servicii.
Fiecare conexiune este asociata unei sesiuni de comunic
ari ntre doi parteneri.
Parametrii de sesiune sunt:
Identificatorul de sesiune: Un octet arbitrar ales de server pentru a identifica o
stare de sesiune (activa sau resumabila).
Certificat: Un certificat X.509v3 asociat fiecarei parti. Eventual, acest camp poate
fi nul.
Metoda de compresie: Algoritmul care asigura compresia (nainte de criptare).
Detaliile de criptare: Specifica algoritmul de criptare, algoritmul M AC (M D5
sau SHA) si alte atribute criptografice legate de acestea.
Master secret: O secventa secreta de 48 octeti partajata de client si server.
Is resumable: Un bit care indica daca sesiunea poate fi utilizata pentru a initia
conexiuni noi.
Parametrii de conexiune sunt:
Nonce server si client: Secventa aleatoare de un octet generata de fiecare parte
la fiecare conexiune.
M AC secret server: Cheia secreta folosita n codul de autrentificare al datelor
scrise de server.
M AC secret client: Cheia secreta folosita n codul de autrentificare al datelor
scrise de client.
Cheie server: Cheia sistemului simetric folosita de server pentru criptarea datelor,
si de client pentru decriptare.
Cheie client: Cheia sistemului simetric folosita de client pentru criptarea datelor,
si de server pentru decriptare.
Vectorii de initializare: Daca pentru criptare se foloseste modul CBC, este necesar un vector de intlaizare (V I) pentru fiecare cheie. Acest camp este completat
prima oara de protocolul handshaking SSL; apoi ultimul bloc criptat din fiecare
nregistrare este pastrat drept V I pentru nregistrarea urmatoare.
Numere de secvent
a: Fiecare entitate mentine separat doua numere de secventa
pentru mesajele trimise si primite la fiecare conexiune. Cand este primit/trimis un
mesaj de schimbare a specificatiilor de criptare, aceste numere sunt resetate.
Cele doua numere de secventa ale fiecarei parti sunt de tipul unit64 si nu depasesc
264 1.
8.2.1
Protocolul de nregistrare T LS
Protocolul de nregistrare T LS ofera o conexiune securizata. Principalele sale proprietati

sunt:
1. Conexiunea este privata. Dupa un protocol initial handsake care stabileste o cheie
pre-master, se foloseste pentru criptare un sistem simetric (AES, DES, RC4 etc).
2. Negocierea secretului master este sigura. Nici un intrus nu poate modifica comunicarea n timpul negocierii fara a fi detectat.
3. Identitatea celor doua parti poate fi autentificata folosind sisteme de criptare cu
cheie publica (RSA, DSS etc).
4. Conexiunea este sigura. Transmiterea unui mesaj include un control al integritatii
folosind un HM AC cu M D5 sau SHA ca functii de dispersie (vom nota aceste
functii cu HM AC M D5(secret, date) respectiv HM AC M D5(secret, date)).
Se pot defini si alte functii de dispersie aditionale.
Structura unui protocol de nregistrare T LS este:
1. Mesajul clientului este mpartit n blocuri M1 , . . . Mn de lungimi egale, de cel
mult 214 octeti fiecare.
2. Optional, se aplica o functie de compresie.
3. Se calculeaza un cod de autentificare folosind HM AC M D5 sau HM AC
SHA; acesta este adaugat mesajului (arhivat).
4. Se cripteaza folosind un sistem simetric de criptare (bloc sau fluid).
Daca se foloseste un sistem bloc, mesajul (textul clar comprimat si codul de
autentificare) este completat astfel ca lungimea lui sa fie multiplu al lungimii
blocului de criptare.
5. Se adauga un antet SSL si rezultatul este trimis prin canal.
Pentru criptarea simetrica se foloseste unul din sistemele de criptare: RC4 cu cheie
pe 128 biti, DES cu cheie de 56 biti, 3DES cu cheie de 168 biti, sau AES cu cheie de
128/256 biti. Majoritatea implementarilor T LS negociaza sistemul si cheia, n functie de
nivelul suportat de dotarea celui mai slab dintre parteneri.
Marimea cheilor folosite de sistemul de criptare cu cheie publica depinde de autoritatea
de certificare.
8.2. T SL
Exemplul 8.1. V erySign utilizeaza chei de 512 sau 1024 biti, n functie de softwareul serverului. Cheia privata V erySign folosit
a la semnarea certificatelor este de 1024
biti, iar cheile de sesiune folosite n tranzactiile T LS sunt cele mai puternice permise de
legislatia SU A (n general 128 sau 256 biti).
Dupa protocolul de nregistrare, T LS cuprinde alte patru protocoale: handshake,
alerta, specificatii de schimbare a sistemului de criptare si de prelucrare a datelor.
8.2.2
Protocolul handshake
Parametrii criptografici ai starii de sesiune sunt generati prin protocolul handshake, care
constituie primul strat din T LS. Cand un client T LS vrea sanceapa o comunicare cu
serverul, ei cad de acord asupra unei versiuni a protocolului, selecteaza algoritmii criptografici, se autentifica reciproc (optional) si folosesc tehnici de criptare cu cheie publica
pentru a genera secretele partajate.
Protocolul este mpartit n patru faze:
1. Mesaje de salut.
2. Autentificare si schimb de chei client.
3. Autentificare si schimb de chei server
4. Sfarsit.
Sa detaliem fiecare din aceste faze.
Mesaje de salut
In specificatii aceste mesaje sunt numite Client hello, respectiv Server hello. Scopul lor
este de a stabili capacitati sigure de legatura ntre client si server; anume versiunea protocolului T LS, ID-ul sesiunii, sistemele de criptare si compresie. In plus, se mai genereaza
si se transmit ntre parteneri doua numere aleatoare: NC si NS .
Cand un client vrea sa se conecteze la un server, i se cere sa trimita un mesaj
Client hello. Acest mesaj contine:
Versiunea protocolului T LS sau SSL pe care doreste clientul sa l foloseasca n
timpul sesiunii. Aceasta trebuie sa fie cea mai recenta versiune suportata de softul
clientului.
N once Client (pentru evitarea atacurilor replay), format din:
Timpul curent si data n standard UNIX pe 32 biti conform cu ceasul intern
al clientului.
28 octeti generati de un generator de numere pseudoaleatoare.

O lista ordonata descrescator dupa preferinta a sistemelor de criptare agreate
de client. Fiecare propunere este formata din doua sectiuni: un tip de schimb de
chei si informatii despre un algoritm de criptare simetric (inclusiv lungimea cheii
secrete) mpreuna cu un cod de autentificare M AC.
Serverul va alege una din aceste propuneri, sau daca nici una nu este acceptabila
returneaza eroare handskhake si nchide conexiunea.
O lista de algoritmi de compresie suportati de softul clientului, ordonata descrescator
dupa preferinta.
Un ID de sesiune. Acest camp poate fi gol daca nu este accesibil nici un astfel de
ID sau daca clientul doreste sa genereze parametri de securitate noi.
Daca poate gasi un set acceptabil de algoritmi n Client hello, serverul trimite ca raspuns
un mesaj Server hello. Acesta contine:
Versiunea serverului: campul contine cea mai mica versiune T LS sau SSL propusa
n Client hello si cea mai mare versiune suportata de server.
N once Server: 28 octeti generati aleator de server, care trebuie sa fie diferiti de cei
generati de client.
O propunere (unica) de sistem de criptare, aleasa din lista propusa de client. Pentru
sesiunile rezumabile, acest camp este valoarea din campul de stare al sesiunii care
se ncheie.
Compresie: Un algoritm de compresie selectat de server din lista propusa de client.
ID de sesiune. Identitatea sesiunii care corespunde conexiunii.
Autentificare si schimb de chei
In faza a doua, imediat dupa mesajele de salut, serverul trimite:
1. Certificatul sau. Tipul acestuia trebuie sa fie apropiat de algoritmii de schimb de
chei propusi; de obicei este un certificat X.509v3 (sau o varianta a sa).
2. Cheia de server.
3. Un mesaj care solicita certificatul clientului (optional).
4. Un mesaj care confirma ca faza a doua este completa.
T LS suporta urmatorii algoritmi de schimb de chei:
8.2. T SL
RSA: Cheia secreta este criptata cu cheia privata a serverului.

Diffie-Hellman de perioad
a lung
a: Certificatul serverului contine parametrii
algoritmului Diffie-Hellman, semnati de o autoritate de certificare (CA).
Diffie-Hellman de perioad
a scurt
a: Parametrii Diffie-Hellman sunt semnati
folosind protocoalele RSA sau DSS ale serverului.
Diffie-Hellman anonim: Parametrii Diffie-Hellman nu sunt semnati.
Dupa cum se vede, parametrii cheii variaza, depinzand de protocolul de schimb de chei
propus de server. Ei sunt:
RSA: n (modulul) si a (exponentul public) pentru o cheie temporara.
Diffie-Hellman: p (modulul), g (generatorul grupului ciclic) si y (= g x ) (cheia
publica a serverului).
Acesti parametri propusi de server sunt semnati prin crearea unei amprente (cu M D5 sau
SHA) si apoi criptarea cu cheia privata a serverului. Amprenta include de asemenea si
nonce-urile din mesajele de salut.
Deci, daca h este functia de dispersie, acest mesaj are forma
h(N once ClientkN once ServerkP arametri server)
Dupa trimiterea certificatului de autentificare, schimbul de chei si (optional) cererea de
certificare, serverul trimite un mesaj de tip server hello indicand ca prima faza din protocolul handshake s-a terminat; n continuare, el asteapta raspunsul clientului.
In faza a treia, clientul:
1. Verifica validitatea certificatului trimis de server; n functie de aceasta depinde continuarea protocolului.
Daca serverul a trimis o cerere de certificare, clientul are doua optiuni: sa trimita
un mesaj de certificare, sau un mesaj de alerta prin care anunta ca nu are un astfel
de certificat; acesta este doar o atentionare, de care serverul poate sa tina cont (si
sa ncheie comunicarea) sau nu (si sa permita continuarea protocolului).
2. Trimite cheia pre-master. Aceasta se poate realiza
- prin trimiterea ei criptata cu sistenul RSA, sau
- transmiterea cheii publice Diffie-Hellman a clientului. Pe baza ei, cei doi vor cadea
de acord ulterior asupra cheii comune pre-master.
Daca metoda aceasta foloseste o semnatura RSA sau DSS, atunci este obligatorie
cererea de certificare a clientului, iar clientul trebuie sa prezinte un certificat ca
raspuns.
Patrametrii pentru cheia pre-master sunt:

RSA: O cheie pre-master de 48 octeti, criptata cu cheia publica din certificatul
serverului sau cu o cheie RSA temporara trimisa de server n faza a doua. Din cheia
pre-master, partenerii vor obtine cheia secreta master.
Diffie-Hellman: Valoarea publica (g x mod p) a cheii clientului. Daca si serverul
foloseste tot protocolul Diffie-Hellman, cei doi deduc imediat cheia comuna premaster.
Dupa ce s-a obtinut cheia pre-master, clientul si serverul calculeaza cheia secreta master dupa formula:
SKM = P RF (pre master, master secret, N once Client + N once Server)
Valoarea master secret foloseste o sursa de entropie pentru a genera valori aleatoare cu
diverse scopuri: M AC-uri, chei secrete, valori de initializare (IV ). Indiferent de varianta
folosita pentru cheia pre-master, master secret are 48 octeti.
P RF este un generator de numere pseudo-aleatoare (care va fi detaliat ulterior).
Dupa calculul SKM , cheia pre-master trebuie stearsa din memorie.
Sf
arsit
In aceasta faza, clientul si serverul actualizeaza specificatiile sistemulor de criptare cu
algoritmii de criptare, cheile si functiile de dispersie agreate de ambele parti.
Apoi, clientul trimite un mesaj de ncheiere pentru a verifica aceste date. Acesta este
primul mesaj protejat cu specificatiile negociate. Forma sa este:
M D5(master secretkpad2 kM D5(handshake mesajkExpeditorkmaster secretkpad1 ));
sau
SHA(master secretkpad2 kSHA(handshake mesajkExpeditorkmaster secretkpad1 ));
unde
pad1 si pad2 sunt valorile definite de M AC,
handshake mesaj se refera la toate mesajele handshake schimbate pana acum,
Expeditor se refera la un cod care identifica expeditorul: 0x434C4E54 daca este
clientul, 0x53525652 daca este serverul.
Dupa acest ultim mesaj, clientul si serverul pot ncepe sa comunice, transmitand date
confidentiale.
8.2. T SL
8.2.3
Calculul cheii
Protocolul de nregistrare T LS solicita un algoritm care sa genereze cheile si componentele

secrete din M AC ale parametrilor de securitate stabiliti prin protocolul handshake. Dupa
cum am vazut, cheia master generata n timpul autentificarii si a schimbului de chei este
folosita ca o sursa de entropie pentru generarea cheilor si a M AC-lui.
Materialul cheii este generat astfel:
Kbloc = P RF (M S.P S, cheie expandata, NS .P SkNC .P S)
unde:
M S.P S: Parametrii de securitate ai secretului master. Secretul master este o
secventa de 48 octeti, partajata de cei doi parteneri conectati.
cheie expandata: Reprezentarea ASCII pentru key expansion; este folosit ca
marca de identificare.
NS este un nonce de 32 octeti generati de server. Parametrii sai de securitate sunt
NS .P S.
Similar, NC este un nonce de 32 octeti generati de client. Parametrii sai de securitate
sunt NC .P S.
P RF este o functie pseudoaleatoare care expandeaza secretele n blocuri de date.
Ea ia la intrare trei parametri: un secret X, o samanta Y si o marca de identificare
label; ca rezultat, produce o secventa de lungime arbitrara.
Kbloc genereaza suficient de mult material pentru a construi n ordine patru date:
1. Componenta secreta din M AC client;
2. Componenta secreta din M AC server;
3. Cheie client;
4. Cheie server.
Din ele, clientul si serverul genereaza M AC-urile (necesare autentificarii) si cheile pe care
le folosesc mpreuna cu IV la criptarea mesajelor cu un sistem simetric.
10
Construirea functiei pseudoaleatoare P RF

P RF folosit n T LS construieste P RF din doi generatori de numere pseudoaleatoare, sub
o forma care garanteaza securitatea daca cel putin un generator este sigur.
Un P RF se genereaza n doi pasi:
1. Se construieste o functie de expansiune Phash (secret, data) pentru a expanda un
secret. Ea se bazeaza pe o functie de dispersie si se defineste astfel:
Phash (X, Y ) = HM AChash (X, A(1)kY )kHM AChash (X, A(2)kY )k . . .
unde A() este definit
A(0) = Y, A(i) = HM AChash (X, A(i 1))
Phash poate fi iterat cat este necesar pentru a genera o cantitate sufienta de date.
Exemplul 8.2. Daca se foloseste ca functie de dispersie SHA 1 pentru a genera
64 octeti de date, atunci vor fi necesare 4 iteratii (p
an
a la A(4)).
Ele vor genera 80 octeti, din care ultimii 16 se ignor
a.
2. Functia pseudoaleatoare P RF folosita de T LS se obtine astfel:
(a) Se divide un secret n doua parti egale;
(b) Una din jumatati este utilizata pentru a genera date cu PM D5 , iar cealalta
jumatate pentru a genera date cu PSHA1 .
(c) Cele doua iesiri sunt XOR-ate.
Deci
P RF (X, labelkY ) = PM D5 (X1 , labelkY )XORPSHA1 (X2 , labelkY )
unde
Secretul X este partajat n doua parti egale: X = X1 kX2 .
label este o secventaSCII, inclusa exact cum este scrisa (fara octet de lungime sau
caracterul null).
Exemplul 8.3. plano tx este procesat
a concaten
and octetii 70 6C 61 6E 6F 20 74 78
cu valoarea din Y .
8.2. T SL
11
Construirea M AC-ului
M AC-ul folosit de T LS este construit astfel:
HM AChash (secretM AC , num seqkT ipkV ersiunekLungimekF ragment))
unde
hash este algoritmul de dispersie specificat de parametrii de securitate,
num seq este numarul de secventa pentru nregistrarea corespunzatoare,
Tip, Versiune si Lungime se refera la caracteristicile respective ale algoritmului de
compresie specificat n T LS, iar Fragment este o portiune compresata din datele
asociate.
8.2.4
Protocolul de alert
a
Cand protocolul handshake detecteaza un mesaj de eroare, partea respectiva trimite

partenerului un mesaj de alerta. T LS permite doua tipuri de mesaje de alerta: totale si
avertizari.
Un mesaj de alerta totala indica o conexiune atat de rea ncat necesita ncheierea ei
imediata. O avertizare indica existenta anumitor probleme de conexiune.
Mesajele de alerta sunt criptate si arhivate conform specificatiilor date de starea
curenta a conexiunii.
Sa detaliem cateva mesaje de alerta totale:
Unexpected message: A aparut un mesaj avand un tip care nu corespunde protocolului. Un astfel de mesaj nu trebuie sa apara niciodata ntr-un protocol de
comunicatie implementat corect.
Bad record mac: Alerta trimisa daca s-a primit o nregistrare cu M AC incorect.
Decryption failed: Alerta trimisa daca un text criptat T LS este decriptat ntrun mod incorect: nu a fost multiplu par de lungimea blocului, valorile de control
adaugate sunt incorecte etc.
Decrypt error: A esuat o operatie criptografica din protocolul handshake (nu se
poate verifica corect o semnatura, decripta o cheie, valida terminarea unui mesaj
etc).
Decompresion failure: Functia de dezarhivare primeste o intrare incorecta (de
exemplu datele au o lungime prea mare).
Handshake failure: Expeditorul nu a putut negocia un set acceptabil de parametri
de securitate din lista optiunilor valabile.
Illegal parameter: Inconsistenta ntre campul atasat unui parametru si alte campuri.
12
8.2.5
Protocolul de schimbare a specificatiilor
In cadrul T LS, un protocol de schimbare a specificatiilor (Change Cipher Spec Protocol)

semnaleaza schimbarea strategiei de criptare. Protocolul consta dintr-un octet, criptat
si arhivat, n starea de conectare curenta. Cand unul din parteneri trimite un astfel de
anunt, el notifica colegului sau ca tot ce urmeaza este protejat cu noile chei si specificatii
de securitate negociate la nceput.
Un mesaj de schimbare a specificatiilor poate fi trimis n timpul protocolului handshake, dupa acceptarea parametrilor de securitate, dar nainte de procedura de verificare
a sfarsitului de mesaj.
8.2.6
Concluzii generale despre SSL/T SL
Cateva comparatii ntre cele doua aplicatii prezentate IP sec si SSL/T LS care asigura
securitatea comunicatiilor Internet:
IP sec instalat pe retele ofera un acces total la resurse, fiind indicate pentru conectarea
unei game extrem de variate de utilizatori (birouri, retele intranet, acces la cerere
client, extranet controlat de client etc). Pentru orice resursa si aplicatie de retea,
IP sec asigura un foarte buin acces securizat.
Principalul sau dezavantaj consta n complexitatea solicitarii vis-a-vis de clinet:
clientul trebuie sa posede un software adecvat si trebuie sa foloseasca cunostionte
avansate pentru a putea lucra cu acesta.
Pe de-alta parte SSL implementat prin standardul T LS nu solicita nici un
software pe partea client, asa ca aplicatia poate fi accesata de pe orice calculator
conectat la Internet. Dezavantajul consta ;intr-o securitate mai slaba. SSL este
recomandat pentru e-Comert, portaluri de aplicatii Web, retele extranet cu parteneri
multipli.
Retelele virtuale private IP sec ofera canale tip tunnel de la parteneri externi spre
retelele interne. SSL asigura o modalitate simpla de conectare a clientilor externi
la aplicatii ale serverelor interne.
O implementare SSL ofera mai multa flexibilitate decat IP sec. Pentru ca nu este
necesar nici un software client, orice angajat poate avea acces la retelele unei companii, folosind orice computer si orice browser Internet.
Deoarece SSL nu solicita retelelor dificultatea configuraii, instalarii si functionarii
IP sec pentru fiecare utilizator, n general, se considera ca o aplicatie SSL este mai
usoara si mai putin costisitoare pentru client, decat o aplicatie IP sec.
In general, o retea V P N dotata cu SSL implementat prin standardul T LS are
urmatoarele caracteristici:
8.2. T SL
13
O retea V P N utilizeaza SSL si tehnologie proxy pentru a oferi utilizatorilor acces

autorizat si sigur la HT T P , aplicatii server si diverse resurse partajate. Ele asigura
transportul datelor si sesiuni sigure ntre orice browser si orice server proxy dintr-un
gateway V P N cu SSL implementat.
SSL-ul unui V P N functioneaza ca un proxy pentru ambele parti; nu exista niciodata o conexiune directa spre o retea privata. Accesul este permis numai spre
aplicatiile oferite de SSL.
Intr-o retea V P N , SSL functioneaza ca un gateway: el stabileste doua conexiuni:
una ntre browserul Web al clientului dintr-o retea nesecurizata si SSL proxy din
V P N , si o a doua conexiune ntre SSL proxy din V P N si urilizatorul dintr-o retea
securizata; in acest mod este evitata orice legatura directa cu o retea securizata.
Deci SSL actioneaza ca un server pentru client si ca un client pentru server.
SSL asigura ca un utilizator autorizat are acces numai la anumite resurse, cele alocate de software-ul companiei prin aplicatia SSL si integrate de gestiunea traficului.
Serverele proxy sparg conexiunea T CP/IP dintre client si server, fara a mai forwarda si adresa IP a pachetelor. Astfel, ele ofera o secruitate la trecerea prin retele
nesigure, ascunzand adresele IP ale utilizatorilor din retelele securizate. Intr-o retea
nesecurizata este vizibila numai adresa IP publica a serverului proxy.
Dintre slabiciunile unei retele V P N dotate cu SSL, mentionam:
Computerele stocheaza n locatii nesecurizate diverse informatii importante.
Dupa nchiderea conexiunii, parolele clientilor raman n zone publice.
Parolele clientilor sunt stocate de browser.
Date importante (informatiile cache, U RL-urile, cookies, informatii din history) create n timpul sesiunii pot ramane pe calculatoare publice dupa nchiderea completa
a unei sesiuni.
Fisiere downloadate raman stocate n directoare temporare pe calculatoare publice.
Clientii uita adesea sa dea logout (sau nu considera necesar acest lucru).
Clientul urmator care foloseste calculatorul public are acces la aplicatii.
Virusi si viermi pot fi transferati de pe calculatoare publice pe retele interne.
14
8.3
Electronic Transaction Protocol (SET )
Protocolul SET a fost construit pentru tranzactii financiare pe Internet, cu scopul de a

oferi securitatea platilor cu card. El a rezultat prin unirea eforturilor de cercetare ale
firmelor Visa si MasterCard, ca o metoda de asigurare a tranzactiilor electronice. La dezvoltarea specificatiilor au cotnribuit de asemenea firme cunsocute ca IBM, M icrosof t,
N etscape, RSA, V eriSign.
La sfarsitul anilor 0 90 SET a fost aprobat drept un protocol de credit standard, dar nu
a putut fi impus din cauza costurilor si a problemelor ridicate de distributia certificatelor
utilizatorilor. Cu toate acestea el este considerat n acest moment ca fiind un protocol ideal
din punct de vedere al certificarii, al semnaturilor digitale si al algoritmilor de criptare
care securizeaza cardurile de credit n tranzactiile Internet.
SET utilizeaza criptografia pentru asigurarea urmatoarelor servicii de securitate:
1. Asigura autentificarea unui detinator de card ca utilizator legitim al unui cont din
care se pot efectua operatii financiare. Ea se realizeaza folosind sistemul de criptare
RSA si certificate X.509.
2. Asigura autentificarea unei isntitutii de plata (banca) de la care un vanzator primeste
valoarea bunurilor/serviciilor oferite unui client.
3. Asigura confidentialitatea operatiilor de plata, pe baza sistemului de criptare DES.
4. Asigura integritatea documentelor de plata, folosind functia de dispersie SHA 1.
8.3.1
Participantii la un protocol SET
Pentru orice tranzactie de plata cu card sunt implicate 5 entitati:

1. Detin
ator card: Intr-un context de comert electronic, consumatorii interactioneaza
cu comerciantii prin intermediul calculatoarelor personale. Un detinator de card
foloseste un card de plata emis de societate numita Emitent. Protocolul SET
asigura ca, n interactiunea dintre detinatorul de card si comerciant, informatia de
pe card ramane confidentiala.
2. Emitent: Este o institutie financiara care stabileste un cont pentru un utilizator si
i elibereaza acestuia un card de plati. Emitentul garanteaza onorarea cu ajutorul
cardului a tranzactiilor financiare autorizate.
3. Comerciant: Ofera spre vanzare bunuri sau servicii n schimbul unei plati. Un
comerciant care accepta plata pe card trebuie sa fie ntr-o relatie de parteneriat cu
un cumparator.
8.3. ELECTRONIC TRANSACTION PROTOCOL (SET )
15
4. Cump
ar
ator: Este institutia financiara care stabileste un cont cu un comerciant
si proceseaza platile autorizate de cardul asociat acestui cont.
5. Gateway de plat
a: Un sistem cu care opereaza cumparatorul sau o componenta
comuna stabilita de comun acord, al carui rol este de a procesa toate mesajele de
plata (inclusiv instructiuni de plata venite de la detinatorul cardului). El permite
cumparatorului sa accepte tranzactii SET prin Internet si sa le pregateasca pentru a
fi trimise la retele comerciale de plata (cum sunt retelele M asterCard ale bancilor).
Internet
Comerciant
Internet
Gateway de plata
Detinator card
Emitent
8.3.2
Retea
de plata
Cumparator
Tranzactii SET
Pasii unei tranzactii electronice SET sunt:

1. Cumparatorul (de fapt banca care gestioneaza contul clientului) solicita un portofel
digital dela o banca si obtine un certificat digital, un card sau alt document autentificat de banca emitenta.
2. Comerciantul obtine un certificat digital de la banca cumparator asociata. Daca
doreste sa faca vanzari on-line folosind SET , el va trebui sa detina doua certificate
valide: CERTCom emis de cumparatorul asociat si CERTGateway de la gateway-ul
de plata.
3. Clientul (posesorul cardului) cauta cu un browser printr-un catalog on-line din
pagina Web a comerciantului, selecteaza produsele pe care vrea sa le cumpere si
completeaza fisa electronica de comanda. Plata o face folosind din portofelul digital
primit de la banca.
4. Clientul trimite comerciantului fisa electronica completata (F E), nsotita de instructiunile
protocolul SET comerciantul nu poate accesa
de plata (OP ) ambele semnate. On
numarul cartii de credit a posesorului cardului informatie la care are acces numai
banca emitatoare. Posesorul cardului nu va trimite nici o informatie sensibila pana
ce nu l autentifica complet pe comerciant.
16
5. Comerciantul primeste F E si OP . Nu are acces nsa la OP deoarece aceasta este

criptata cu cheia publica a gateway-ului de plata.
6. El trimite F E, OP si datele sale de autentificare la banca asociata gateway-ului si
care va face platile. Gateway-ul de plata translateaza mesajul SET ntr-un protocol
recunoscut si folosit de reteaua care a emis cardul. Gateway-ul de plata primeste
certificatele de la SET -ul asociat Root CA (un CA aflat n varful ierarhiei de
ncredere).
7. Gateway-ul autentifica pe cei doi parteneri, decripteaza OP si transmite informatile
bancii care efectueaza plata. Banca trimite o cerere de autorizare pe care banca
emitenta a cardului.
8. Banca emitenta primeste cererea de autorizare ca pe orice solicitare de tranzactie
fizica. Cerceteaza contul posesorului de card si n functie de informatiile pe care
le detine aproba sau respinge plata. Acest mesaj este trimis napoi spre banca
care efectueaza plati.
9. Mesajul trece din nou prin gateway-ul de plata si este criptat nainte ca autorizatia
sa fie trimisa comerciantului. Daca acesta are confirmarea validitatii cardului de
plata (inclusiv daca suma este acoperita de creditul cardului), va livra solicitantului
produsele cumparate.
8.3.3
Autentificarea si confidentialitatea SET
Protocolul SET asigura servicii de confidentialitate si autentificare folosind primitive

criptografice si certificate digitale. La orice schimb de informatii ntre detinatorii de card,
autoritatile de certificare, comerciantii si bancile de emitere de card sau de plata pentru
obtinerea unui certificat, trimiterea unei instructiuni de plata sau o autorizare de plata
informatia vehiculata este securizata prin semnaturi si envelopari digitale, nsotite de
criptari (simetrice sau cu cheie publica).
Expeditor (Alice):
Cheie de sesiune
6
Criptare
RSA
Semnatura
digitala
Criptare
RSA
?
Envelopare digitala
?
- Mesaj text clar
SHA 1
6
-
-Criptare simetric
a
Mesaj criptat
si semnat
Certificat Alice
6
Mesaj
17
Destinatar (Bob):
?
Decriptare
Cheie publica
Decriptare Alice
DSS/RSA
Certificat AliceY

6

SHA 1
Semnatura
Mesaj
+
decriptat
Decriptare

(simetrica)
6

Cheie de sesiune
?
Mesaj criptat
si semnat
Dispersie
?-
Verificare
Da/Nu
Procesul de autentificare si confidentialitate SET cuprinde urmatoarele etape (descrise

si de figura de mai sus):
1. Expeditorul (Alice) genereaza o sesiune aleatoare. Cheia de sesiune este o cheie secreta one-time folosita pentru criptarea mesajului cu un sistem de criptare simetric.
2. Mesajul este arhivat cu functia de dispersie SHA 1 si semnat cu RSA bazat pe
cheia privata a lui Alice. Se formeaza astfel Semn
atura digital
a.
3. Mesajul text clar este concatenat cu semnatura digitala si cu certificatul lui
Alice.
4. Ceea ce s-a obtinut se cripteaza cu un algoritm simetric (DES) folosind cheia secreta
one-time de la Pasul 1.
5. Cheia de sesiune one-time este criptata cu RSA folosind cheia publica a lui Alice.
Rezultatul este numit envelopare digital
a.
6. Se face o concatenare a cheii de sesiune criptate cu mesajul criptat si semnat.
7. Pentru decriptarea si autentificarea mesajului, Bob va parcurge pasii n ordine inversa.
8.3.4
Ierarhia de ncredere SET
In mediul SET exista o ierarhie bine stabilita a autoritatilor de certificare. In varf se afla
SET Root CA detinuta si gestionata de Secure Electronic Transactions LLC. Toate
certificatele contin cheia sa publica.
Certificatul proprietarului de card:
Un certificat al proprietarului de card functioneaza ca o reprezentare electronica
a unui card de plati. El este aprobat de banca emitatoare, nu contine numarul
contului si nici data expirarii. Acest certificat este transmis comerciantilor nsotit
18
de instructiuni de plata criptate. Cand un comerciant primeste un certificat al

proprietarului de card, el este sigur chiar daca nu vede numarul de cont ca acest
card de plati este validat de banca.
Certificatul comerciantului:
Un comerciant primeste doua certificate de la institutia financiara:
Certificatul sau propriu. El i asigura dreptul de a exista ca brand (entitate
comerciala);
Certificatul gateway-ului de plat
a, prin care i sunt acceptate (si platite) de
catre cumparator contravaloarea marfurilor vandute.
Certificatul gateway-ului de plat
a:
Acest certificat est obtinut de cumparator de la Autoritatea de Certificare a Brandului pentru gateway-ul sau de plata. El include cheia publica si cheia de criptare
folosite de proprietarul de card pentru protejarea informatiei legate de cont.
Certificatul cump
ar
atorului:
Banca cu rol de cumparator trebuie certificata de emitatorul de carduri de plata.
Acesta i da astfel dreptul de a accepta sau respinge cererile de certificare venite
direct de la comercianti.
Certificatul emitentului:
Un emitent trebuie de asemenea certificat de emitatorul de carduri de plata. Astfel,
el poate opera ca o autoritate de certificare pentru cererile de certificare venite direct
de la posesorii de carduri.
Semnatura Root
?
Semnatura
Brand
?
Semnatura
CA Gateway
CA
Emitent
CA
Cumparator

Semnatura
posesor card

+

Semnatura
comerciant
Q
Q
CA
Gateway de plata

Q
s
Q
Schimb chei
comerciant

+

Semnatura
gateway de plata
Graful arata structura arborescenta a ierarhiei SET de ncredere.
Q
Q
Q
s
Q
Schimb chei
gateway de plata
8.3.5
19
Tranzactii SET
Atunci cand un client comanda un produs unui comerciant, protocolul SET desfasoara
trei tranzactii:
1. Cererea de cumparare;
2. Autorizarea de plata;
3. Efectuarea platii.
A. Cererea de cump
arare:
In aceasta faza protocolul este format din 4 mesaje schimbate ntre client si comerciant:
A1. Initierea cererii
Protocolul SET este invocat cand posesorul de card este gata sa lanseze un oridn de
cumparare: a selectat produsele pe care le doreste, a completat forma de vanzare a comerciantului si a fost de acord cu termenii si conditiile acestuia. In primul sau mesaj, clientul
initiaza cererea de cumparare solicitand comerciantului certificatul propriu si certificatul
emis de gateway-ul de plata afiliat.
A2. Initierea r
aspunsului
1. Software-ul comerciantului primeste initierea cererii de cumparare.
2. Genereaza un raspuns RI, i aplica o functie de dispersie h (standardul este SHA1)
si l cripteaza (standardul este RSA) cu cheia secreta K a comerciantului. In acest
fel produce o semnatura digitala dK (h(RI)) a mesajului de raspuns RI.
3. Trimite clientului (RI, dK (h(RI)), CERTCom , CERTGateway ).
Software-ul clientului verifica acest raspuns:
1. Decripteaza semnatura folosind cheia publica a comerciantului (aflata n CERTCom ):
eK (dK (h(RI))) = h(RI).
2. Aplica functia de dispersie lui RI si verifica daca rezultatul h(RI) este egal cu ce a
obtinut anterior.
20
A3. Cererea de cump

arare
Daca verificarea este pozitiva, clientul lanseaza un nou mesaj, continand instructiuni
de cumparare (CI) si de plata (P I). De remarcat ca CI contine portiuni din cererea de
cumparare, dar nu si descrieri ale produselor comandate. Mai exact, software-ul clientului:
1. Pune n CI si P I identificatorul de tranzactie asignat de comerciant; acesta va fi
folosit mai tarziu cand comerciantul primeste autorizatia de gateway-ul de plata
pentru a asocia CI de P I.
2. Genereaza o semnatura duala pentru CI si P I: C = dK 0 (h(h(P I)kh(CI))), folosind
cheia sa secreta K 0 .
3. Genereaza aleator o cheie de sesiune K1 pentru un sistem simetric de criptare (Standard DES) cu care cripteaza P I, h(CI) si semnatura duala. K1 si numarul de cont
al cardului clientului sunt criptate cu cheia publica a gateway-ului de plata, formand
un plic digital P D = eGateway (CON TClient , K1 ).
4. Trimite comerciantului
(P D, eK1 (P IkC ), C , h(P I), CI, CERTClient )
Primele doua componente nu sunt accesibile comerciantului, ele fiind destinate gatewayului de plata.
A4. R
aspuns la cererea de cump
arare
Comerciantul:
1. Verifica CERTClient si extrage din el cheia publica de criptare.
2. Calculeaza eK 0 (C ).
3. Calculeaza h(CI), apoi h(h(P I)kh(CI)) si compara rezultatul cu ceea ce a obtinut
la pasul anteior.
4. Daca cele doua valori sunt egale, deduce ca CI este autentic si proceseaza cererea
de cumparare (inclusiv trimiterea P I spre gateway pentru autorizare).
5. Genereaza un raspuns R la cererea de cumparare si l semneaza: dK (h(R)).
6. Trimite clientului perechea (dK (h(R)), CERTCom ).
B. Autorizarea de plat
a: Autorizatia de plata consta din doua mesaje:
Cererea de autorizare: trimisa de comerciant spre gateway-ul de plata,
21
Autorizare de raspuns.
Gateway-ul autentifica comerciantul, decripteaza si cripteaza informatia de plata si o
transmite bancii cumparatoare. Aceasta lanseaza si ea o cerere de autorizare pe baza
careia banca emitenta poate aproba sau respinge tranzactia posesorului de card. Banca
cumparatoare primeste decizia si o trimite gateway-ului de plata care emite comerciantului
o autorizare de raspuns.
B1. Cererea de autorizare
Software-ul comerciantului:
1. Genereaza o cerere de autorizare AR care include suma solicitata, identificatorul
tranzactiei (din CI), si alte informatii specifice.
2. Semneaza cererea: = dK (h(AR))
3. Genereaza aleator o cheie de sesiune K2 si calculeaza
P = eK2 (, AR), E = eKGateway (K2 ).
4. Trimite spre gateway-ul de plata mesajul
(P, E, P D, eK1 (P IkC ), CERTCom , CERTClient )
B2. Autorizare de r
aspuns
Gateway-ul de plata:
1. Verifica CERTCom , din care scoate cheia publica K a comerciantului.
2. Verifica cecerea de autorizare:
(a) Afla K2 , pe care o foloseste pentru a determina AR si .
(b) Calculeaza h(AR) si compara rezultatul cu eK ().
3. Verifica CERTClient , din care scoate cheia publica K 0 a clientului.
4. Obtine infoirmatia de plata data de client si verifica semnatura duala.
(a) Din P D obtine cheia K1 pe care o foloseste pentru a gasi P I si C .
(b) Calculeaza eK 0 (C ) = h(h(P I)kh(CI)).
(c) Calculeaza h(P I), apoi h(h(P I)kh(CI)), pe care l compara cu rezultatul anterior.
(d) Verifica consistenta dintre cererea de autorizare a comerciantului si P I trimis
de client.
22
5. Trimite cererea de autorizare folosind o retea financiara normala bancii care a

eliberat cardul clientului.
6. Trimite comerciantului autorizarea de raspuns:
(a) Genereaza o autorizare de raspuns AR, pe care o semneaza: G = dGateway (h(AR)).
(b) Genereaza aleator o cheie de sesiune K3 si calculeaza
Q = eK3 (AR, G ), F = eK (K3 ).
(c) Creaza un fisier CT numit Capture token si-l semneaza:
sign(CT ) = dGateway (h(CT )).
(d) Genereaza aleator o cheie de sesiuneK4 si calculeaza eK (K4 ), eK4 (CT ).
(e) Trimite comerciantului
(Q, F, eK (K4 ), eK4 (CT ), CERTGateway )
B3. Verificarea de c
atre comerciant a autoriz
arii de r
aspuns
La primirea mesajului, software-ul comerciantului stocheaza autorizarea de raspuns si
CT pentru a le folosi cand va solicita plata. Completeaza apoi comanda clientului,
trimitandu-i marfa si serviciile specificate n CI.
Detaliat, comerciantul efectueaza urmatorul protocol:
1. Verifica CERTGateway .
2. Gaseste cheia de sesiune K3 , cu ajurotul careia calculeaza autorizatia de raspuns
AR.
3. Verifica semnatura a gateway-ului: calculeaza eGateway (sign(h(AR)) pe care o compara cu rezultatul obtinut prin aplicarea functiei de dispersie h lui AR obtinut
anterior.
4. Stocheaza Sign(CT ) si eK4 (CT ). De observat ca numai gateway-ul de plata poate
afla tokenul de captura.
5. Finalizeaza procesarea cererii de cumparare.
C. Efectuarea pl
atii:
C1. Cererea de plat
a a comerciantului
Dupa finalizarea comenzii de livrare a produsului cumparat, comerciantul va solicita plata.
Pentru aceasta:
1. Scrie o cerere de plata SP .
23
2. O semneaza: Com = dCom (h(SP )).

3. Genereaza aleator o cheie de sesiune K5 .
4. Trimite spre gateway-ul de plata
(eGateway (K5 ), eK5 (SP ), Com , Sign(CT ), eK4 (CT ), CERTCom )
C2. R
aspunsul gateway-ului
Cand un gatewayu de plata primeste o solicitare de plata, el decripteaza informatia si
foloseste CT pentru a genera o solicitare de plata sub forma de text clar, pe care o trimite
bancii emitatoare via un sistem de plata pe card. Apoi el genereaza un raspuns pe care
l transmite comerciantului.
Detaliat, gateway-ul de plata:
1. Verifica CERTCom , din care scoate cheia publica a comerciantului.
2. Verifica cererea de plata a comerciantului.
(a) Afla K5 , cu ajutorul careia calculeaza SP .
(b) Verifica semnatura digitala a comerciantului, scotand din ea h(SP ) si comparand-o cu h(SP ) calculat din P R rezultat anterior.
(c) Afla K4 folosind cheia sa privata si calculeaza CT .
(d) Verifica consistenta dintre informatiile cuprinse n CT si SP .
3. Trimite SP printr-o retea financiara spre banca care detine contul clientului.
4. Genereaza un raspuns de plata RP si l semneaza: RP = dGateway (h(RP )).
5. Genereaza aleator o cheie de sesiune K6 .
6. Trimite comerciantului
(eCom (K6 ), eK6 (P R, P R ), CERTGateway )
C3. Verificarea r
aspunsului de plat
a
La primirea raspunsului la cererea sa de plata, software-ul comerciantului:
1. Verifica CERTGateway , din care scoate cheia publica de criptare.
2. Calculeaza cheia K6 , cu ajutorul careia afla raspunsul de plata RP .
3. Verifica semnatura digitala, decriptand RP si comparand rezultatul cu h(RP ) calculat pe baza informatiilor de la pasul anterior.
In final, comerciantul stocheaza RP ca o confirmare ca i se face plata.
24
Bibliografie
[1] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., Wright, T. (2006) Transport layer security (TLS) extensions (RFC 4366).
[2] Dierks, T., Rescorla, E. (2006) - The transport layer security (TLS) protocol version
1.1 (RFC 4346)
[3] Freier, A., Karlton, P., Kocher, P. (1996) The SSL protocol version 3.0
http://wp.netscape.com/eng/ssl3/3-SPEC.HTM#1
[4] Santesson, S. (2006) - TLS handshake message for supplemental data (RFC 4680)
[5] Santesson, S., Ball, J., Medvinsky, A. (2006) - TLS user mapping extension (RFC
4681).
[6] SET Secure Electronic Transaction Specification Book 1: Business Description (1997)
25
Capitolul 9
OpenID
9.1
Prezentare general
a
OpenID este un standard de comunicare pentru conexiunile individuale la Internet care

a castigat o mare popularitate n ultima vreme, mai ales datorita utilizarii sale free.
Primul protocol OpenID a fost dezvoltat n 2005 de Brad Fitzpatrick. Intentia era
de a minimiza efortul utilizatorilor de a trece prin procesele (uneori descurajante) de
nregistrare pe diverse site-uri, bloguri, retele de socializare. Datorita metodei unice de
accesare a unei palete largi de site-uri, protocolul a devenit popular foarte rapid. Cum
toate conturile Google, Yahoo, Facebook, AOL suporta OpenID, sunt mari sanse ca un
utilizator (mediu) ales arbitrar sa detina deja un OpenID enabled login;
Ultima versiune (2.0) de autentificare OpenID Authentication ([18]), cu facilitati
sporite, a aparut n decembrie 2007, derivata dintr-o versiune mbunatatita a variantei
intiale a lui Fitzpatrick.
Scopul principal al protocolului OpenID a fost simplificarea autentificarii pe site-uri
web, bloguri, retele de discutii etc. El nu a fost realizat pentru aplicatii de ncredere cum
ar fi protocoalele bancare sau notariale. Cerinta de a asigura doar ca un utilizator sa fie
cel care pretinde ca este, reprezinta un nivel de securitate scazut.
In general, OpenId este un protocol open care permite unui utilizator (Bob) sa foloseasca un U RL ca o identitate care l reprezinta pentru a accesa site-uri multiple (care suporta
acest protocol). Aplicatiile Web pot folosi identitatea U RL pentru autentificare, autorizare sau alte scopuri. Bob, ca proprietar al identitatii, are control complet si poate decide
asupra informatiei pe care trebuie sa o ofere n procesul de autentificare (pentru o aplicatie
sau un site web). Printre altele, OpenId permite lui Bob:
Conectarea la o aplicatie sau site web fara a introduce informatii de autentificare
de tip username si password.
Sa selecteze informatia care poate fi trimisa unui site web n procesul de autentificare/autorizare.
1
CAPITOLUL 9. OPENID
Sa aleaga seturile de informatie (numite profiluri sau carduri) care pot fi trimise
site-urilor web, n functie de nivelul de solicitare si risc.
Implementarea autorizarii graduate si bazate pe risc.
Implementarea unei semnaturi unice pentru aplicatii multiple.
Integrarea de aplicatii ntr-un sistem OpenId unitar, folosind mecanisme simple.
Un cost redus de implementare si maintenanta.
OpenID nu este unic prin scopul propus sau metodele folosite. Exista si alte specificatii
simple de autentificare a utilizatorilor, cu aproximativ aceleasi scopuri; cel mai utilizat
este probabil SAML Web Browser Single Sign On. Principala diferenta este aceea ca
SAM L solicita ca aplicatiile web pentru autentificare sa fie acceptate anterior de cele
doua parti, iar autentificarea este o componenta a unei constructii mai largi. Specificatia
SAM L a fost realizata de companii, n timp ce OpenID este un proiect coordonat public
de comunitatea Internet (oarecum similar cu P HP de la posta electronica).
Alte specificatii similare sunt OAuth ([17]), WS-Trust ([10]) si Information Card ([12]).
9.2
Schema general
a a unui protocol OpenID
In prezentarea modului de functionare al protocoalelor OpenID vor fi folositi o serie de

termeni specifici:
Identitificator de asociere: U RL-ul (Uniform Resource Locator) sau XRI-ul (Extensible Resource Identifier) ales de utilizatorul Bob pentru a-si defini identitatea.
Relying Party (RP ): o aplicatie Web care vrea sa verifice ca Bob are controlul asupra
Identificatorului de asociere.
OpenID Provider (OP ): un server de autentificare OpenID, pe care se bazeaza
Relying Party n operatia de verificare a utilizatorului.
User Agent (U A): un program client (browser Web) folosit de Bob pentru a comunica cu RP si OP .
Sa ncepem cu un exemplu:
Exemplul 9.1. Bob doreste sa se nregistreze pe aplicatia web cryptounibuc.com (ges loc de a completa un formular de nregistrare, el trimite lui RP un
tionat
a de RP ). In
URL care reprezinta identitatea sa s
a spunem www.bob.com. RP poate afla apartenenta
lui Bob la acest URL; n particular RP descoper
a c
a proprietarul acestui URL are capacitatea de a se conecta la openid.yahoo.com (providerul OpenID OP ) folosind ca
username 0 bobita0 .
A UNUI PROTOCOL OP EN ID
9.2. SCHEMA GENERALA
RP redirectioneaza pe Bob spre OP , unde i se cere s

a completeze parola pentru username-ul 0 bobita0 . Dupa aceasta autentificare local
a, Bob este ntrebat dac
a doreste ntradev
ar s
a foloseasca identitatea sa pentru *.cryptounibuc.com (realm) si n caz afirmativ
s
a confirme atributele cerute de RP (cum ar fi numele complet si adresa de e-mail).
Confirmarea este retrimisa de OP spre RP .
Folosind o conexiune directa, RP se asigur
a c
a identitatea local
a primit
a este autentificat
a de OP . Presupunand ca doar proprietarul poate modifica continutul site-ului
www.bob.com, cryptounibuc este asigurat c
a Bob este de fapt proprietarul acestui URL si
RP i va genera un cont local pe aplicatia sa web.
Ulterior, la orice solicitare a lui Bob, RP l va loga la cryptounibuc folosind identitatea lui.
Pe baza acestui exemplu, sa detaliem specificatiile unui protocol OpenId ([18]). O
privire schematica este data de Figura urmatoare:
(1)
U RL
OP
(5)
h
(8)
6 (7)
(3)
(2)
(4)
RP
(6)
- UA
1. U RL-ul identitatii mele;

2. Ce dovedeste posesia acestei identitati ?
3. Posibilitatea de logare la OP ca username;
4. Stabilirea asocierilor;
5. Redirectare;
6. Autentifica Utilizatorul cu username;
7. Redirectare;
8. Verificarea autentificarii (XOR cu (4)).
Protocolul contine o serie de operatii pe care sa le detaliem:
Descoperirea identit
atii Utilizatorului. RP se duce la componenta de identitate a U RL-ului specificat de utilizator, pentru a gasi OP -ul solicitat. In versiunea
CAPITOLUL 9. OPENID
2.0 acesta poate fi un link static continand OP -ul si identitatea locala sau un document XRDS care ofera lui Bob posibilitatea de specifica mai multe OP -uri (pentru
protocoale diferite). In acest caz se face apel la Y adis1 pentru a gasi OP si versiunea
protocolului care se va folosi.
Stabilirea unei asocieri. Asocierea este folosita pentru a garanta ca numai OP -ul
stabilit a autentificat identitatea locala a utilizatorului. Eventual, RP poate alege
sa omita acest pas si sa valideze identitatea la sfarsitul executiei protocolului.
Intre RP si OP O este stabilita asociere formata din doua componente: un Identificator de asociere (unic) si un cod M AC pentru semnarea mesajelor. Sunt doua
metode de stabilire a unei asocieri: printr-un schimb de chei Diffie-Hellman sau prin
solicitarea unui canal securizat (de exemplu SSL). Vom detalia aceasta construtie
ntr-o sectiune ulterioara.
Redirectare spre OP . Dupa aflarea OP -ului tinta si stabilirea (optional) unei
asocieri, RP forwardeaza cererea utilizatorului spre OP (via o redirectare Web).
Cererea contine o serie de parametri (detaliati n sectiunea 4), cei mai importanti
fiind identitatea, Identificatorul de asociere (daca a fost folosit), domeniul RP care
trebuie alocat (realm) si un U RL la RP -ul unde trebuie redirectat utilizatorul dupa
autentificare (return to).
Redirectare spre RP . Dupa ce OP a autentificat identitatea locala a lui Bob,
iar acesta a permis utilizarea identitatii sale n domeniul realm specificat, la pasul
urmator OP redirecteaza utilizatorul spre RP , mpreuna cu anumiti parametri.
Acestia includ Identificatorul de asociere (daca a fost folosit), un server-time bazat
pe un nonce (pentru prevenirea atacurilor replay) si o semnatura peste valorile unora
din parametri (cei mentionati sunt obligatoriu semnati).
Daca a fost stabilita o asociere, atunci semnatura foloseste codul M AC si algoritmul
de semnatura specificate de aceasta.
Verificarea r
aspunsului. Daca nu a fost stabilita nici o asociere, atunci RP
trebuie sa se asigure ca raspunsul a fost generat de OP , Pentru aceasta, RP trimite
parametrii primiti direct spre OP , iar acesta raspunde printre altele cu un
parametru valid care sa-i certifice semnatura.
9.3
Autentificarea
Deoarece notiunea de autentificare este esentiala n construirea unui protocol OpenId, sa

reluam o parte din pasii anteriori, detaliind acest aspect. pe forma generala.
1
Protocolul Y adis (Yet Another Distributed Identity System) a fost dezvoltat n aceeasi comunitate
ca si OpenID, dar f
ar
a a fi legate functional ntre ele. OpenID s-a numit intial Y adis.
9.3. AUTENTIFICAREA
Versiunea 2.0 protocolului de autentificare ([18]) foloseste pentru comunicatie protocolul HT T P (sau HT T P S), iar mesajele sunt codificate cu U T F 8.
1. U A RP : Prezentare Identificator de asociere.
2. RP OP : [Optional] Negocierea unei chei secrete.
3. RP U A: Redirectarea U A catre OP .
4. U A OP : Trimiterea credentialelor pentru autentificare.
5. OP U A: Redirectarea U A spre RP .
6. U A RP : Trimite decizia de autentificare semnata de OP .
7. RP OP : [Optional] Verificarea rezultatelor autentificarii (daca s-a trecut de
pasul 2)
8. RP U A: Permite sau respinge accesul la resursa protejata.
Descriere:
1. Primul pas n realizarea autentificarii este asa cum s-a vazut trimiterea Identificatorului utilizatorului (U RL) prin U A catre RP -ul care solicita autentificarea.
2. RP si OP stabilesc o cheie secreta ce va fi stocata de RP .
3. RP redirecteaza U A-ul utilizatorului catre OP , pentru ca bob sa se poata autentifica
direct. Metoda de autentificare poate varia, dar de obicei un furnizor OpenID (OP ) va
cere utilizatorului o parola (sau un InfoCard) si apoi l va ntreba daca are ncredere ca
RP -ul sa primeasca detaliile necesare privind identitatea sa.
4. 5. Daca utilizatorul nu are ncredere n RP, U A-ul sau va fi redirectat catre
RP cu un mesaj indicand respingerea autentificarii, iar RP va refuza la randul sau sa-l
autentifice pe Bob.
Daca utilizatorul decide sa aiba ncredere n RP atunci U A-ul va fi redirectat catre
RP mpreuna cu credentialele sale. RP trebuie sa confirme lui Bob daca credentialele au
venit de la OP .
Daca RP si OP au stabilit anterior o cheie secreta, atunci RP poate valida identitatea OP -ului comparand copia cheii secrete (pe care a stocat-o) cu cea primita mpreuna
cu credentialele utilizatorului. Compararea se face n varianta 2.0 printr-o operatie
XOR ().
Acest tip de RP se numeste stateful deoarece stocheaza cheia secreta ntre sesiuni,
spre deosebire de cel stateless care trebuie sa mai faca o cerere (check authentication)
pentru a se asigura ca datele au venit de la OP .
6. Dupa ce identitatea a fost verificata, autentificarea este terminata cu succes iar
utilizatorul este considerat a fi conectat la RP cu identitatea autentificata de OP . RP
va stoca identitatea utilizatorului mpreuna cu alte informatii de sesiune.
Pentru negocierea cheii secrete ntre RP si OP (de la pasul 2):
CAPITOLUL 9. OPENID
1. RP OP : In prima etapa se stabilesc tipurile de M AC, modurile de protejare a

sesiunii si alti parametri utilizati de protocol.
Tipurile posibile de M AC sunt HM AC SHA1 si HM AC SHA256.
Tipurile posibile de protectie a sesiunii sunt: fara criptare, DH SHA1 si
DH SHA256.
Criptarea nu trebuie eliminata decat daca se asigura securitatea transportului
(prin protocolul T LS de exemplu).
2. OP RP : In acest pas se primesc parametrii raspunsului:
(a) Parametri comuni (tipul sesiunii, durata);
(b) Parametri n clar (M AC(key));
(c) Parametrii Diffie-Hellman (cheia publica a OP , cheia MAC criptata cu DH);
(d) Parametri de insucces (mesaje si coduri de eroare indicand problema aparuta).
In cazul n care cheia M AC este protejata prin Diffie-Hellman ea va fi transformata
nainte de a fi trimisa n retea astfel:
base64(H(btwoc(g xA xB (mod p))) M AC(key))
unde g, p, xA si xB sunt parametrii Diffie-Hellman stabiliti anterior, btwoc este o functie
ce primeste ca parametru de intrare un ntreg (cu o anumita precizie) si ntoarce cea mai
scurta reprezentare complementara big-endian.
De asemenea trebuie respectata urmatoarea conditie: M AC(key) trebuie s
a aiba
aceeasi lungime ca rezultatul functiei de dispersie H: 160 biti pentru DH SHA1 sau
256 biti pentru DH SHA256.
9.4
Tipul mesajelor din procesul de autentificare OpenId
Toate partile implicate n procesul de autentificare comunica prin schimb de mesaje.

Formatul acestor mesaje este bine definit de protocolul OpenId 2.0, astfel ca succesul
comunicarii depinde de utilizarea lor corecta. Exista 4 tipuri principale de mesaje n
cadrul protocolului:
1. Mesajul de asociere (associate);
2. Mesajul checkid immediate;
3. Mesajul checkid setup;
4. Mesajul de verificare a autentificarii (check authentication).
9.4. TIPUL MESAJELOR DIN PROCESUL DE AUTENTIFICARE OP EN ID
Toate aceste tipuri de mesaje sunt protocoale de tip cerere/raspuns, fiecare dintre ele
putand avea diferiti parametri. De asemenea, n functie de tipul mesajului, utilizatorul
Bob si serverul OP pot apela la metode de comunicare directe sau indirecte.
In cazul celor directe, se foloseste protocolul HT T P de tip POST, iar pentru cele indirecte
protocolul HT T P de tip GET.
9.4.1
Cererea de asociere
Acest tip de mesaj este trimis de Identificatorul de asociere (U RL) spre serverul OP
(pasul 4). Scopul principal al acestor mesaje este de a stabili o cheie secreta comuna ntre
Utilizator si OP . Utilizatorul poate trimite acest mesaj ori de cate ori este cerut de OP .
Avand n vedere ca cei doi parteneri comunica direct, metoda folosita din cadrul
protocolului HT T P este POST. In timp ce se initiaza cererea de asociere, OP va trimite
odata cu ea si o serie de parametri. Lista cu parametrii care pot fi trimisi este: openid.ns,
openid.mode, openid.assoc type, openid.session type, openid.dh modulus, openid.dh gen si
openid.dh consumer public.
openid.ns.
Acest parametru (optional) defineste versiunea protocolului folosit. Utilizarea versiunii OpenId 2.0 se specifica prin valoarea http://specs.openid.net/auth/2.0.
Daca acest parametru lipseste sau are alta valoare, atunci se foloseste automat
versiunea 1.1 a protocolului din motive de compatibilitate cu implementari ce
utilizeaza versiuni mai vechi.
openid.mode.
Acest parametru permite destinatarului sa stie cu ce tip de mesaj are de a face. Din
acest motiv, Bob trebuie sa fie prezent n cadrul tuturor mesajelor; n caz contrar
mesajul nu face parte din procesul de autentificare OpenID.
Pentru mesajul de asociere, valoarea parametrului este associate.
openid.assoc type.
Prin acest parametru, cele doua parti care comunica se pun de acord asupra algoritmului folosit la semnarea mesajelor.
In momentul de fata sunt utilizate doua tipuri de algoritmi:
HM AC SHA1: lungimea cheii este de 160 biti, valoarea parametrului fiind
HM AC SHA1 (conform RF C2104/RF C3174);
HM AC SHA256: lungimea cheii este de 256 biti, valoarea parametrului
fiind HM AC SHA256 (RF C2104/F IP S180 2).
Recomandarea este folosirea algoritmului pe 256 biti daca acest lucru este posibil.
CAPITOLUL 9. OPENID
openid.session type.
Prin intermediul acestui parametru se stabileste tipul de sistem criptare folosit n
cadrul mesajului, pentru a cripta M AC-ul. Trei valori sunt valide pentru acest
parametru:
no-encription. Valoare folosita daca se doreste ca M AC-ul sa fie trimis necriptat. Acest lucru nu este recomandat, deoarece un atacator ar putea modifica
cu usurinta mesajul prin metode de tip eavesdropping.
Se poate nsa utiliza aceasta valoare daca pentru comunicare se folosesc canale
securizate prin SSL, care asigura deja criptarea continutului.
DH SHA1. In acest caz algoritmul folosit pentru schimbul de chei este
Difie-Hellman, mpreuna cu functia de dispersie de tip SHA 1.
DH SHA256. Si aici se foloseste algoritmul Difie-Hellman, combinat nsa cu
functia de dispersie SHA pe 256 biti.
Pentru valorile bazate pe algoritmul DH si functia de dispersie SHA, M AC-ul
trebuie sa aiba aceeasi lungime cu rezultatul functiei de dispersie (160 biti pentru
DH SHA1, respectiv 256 biti pentru DH SHA256), precum si cu rezultatul
algoritmului folosit pentru semnarea asocierii.
Detaliind, RP specifica un numar prim mare p si un generator q. De asemenea, tot
el genereaza aleator o cheie secreta xA , iar serverul OP alege tot aleator o cheie
secreta xB , ambele din intervalul [1, p 1].
Astfel, cheia secreta folosita pentru criptarea M AC-ului va fi
g xA xB (mod p) = (g xA )xB (mod p) = (g xB )xA (mod p)
Parametrii openid.dh modulus, openid.dh gen si openid.dh consumer public.
Daca pentru tipul asocierii s-a ales una din cele doua variante bazate pe algoritmul
Difie-Hillman si pe una din functiile de dispersie SHA, acesti trei parametri trebuie
sa fie prezenti.
Valoarea lui openid.dh modulus retine numarul prim p (modulul) si trebuie sa fie n
forma base64 (btwoc(p)). Valoarea default a acestuia n hexazecimal este:
DCF 93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7
623731866E61EF 75A2E27898B057F 9891C2E27A639C3F 29B608
14581CD3B2CA3986D2683705577D45C2E7E52DC81C7A171876E
5CEA74B1448BF DF AF 18828EF D2519F 14E45E3826634AF 1949E5
B535CC829A483B8A76223E5D490A257F 05BDF F 16F 2F B22C583AB
Valoarea lui openid.dh gen retine numarul ales g si trebuie sa fie tot n forma
base64 (btwoc(g)), iar valoarea sa default este g = 2.
openid.dh consumer public are ca valoare base64 (btwoc(g xA (mod p))).
9.4.2
R
aspunsul la cererea de asociere
Mesajul de raspuns la cererea de asociere este trimis de OP spre U A (site-ul care a initiat
cererea). Codul HT T P pentru raspuns este 200 si poate reprezenta succesul sau esecul
asocierii.
In cazul succesului, raspunsul va contine un token valid si intervalul (n secunde) de
validitate; altfel va fi returnat un mesaj de eroare.
Parametrii ce trebuie sa faca parte din raspuns (pentru ca asocierea sa reuseasca) sunt:
openid.ns, openid.assoc handle, openid.session type, openid.assoc type, openid.expires in,
openid.mac key, openid.dh server public, openid.enc mac key.
openid.assoc handle
Este folosit n mesajele ulterioare, pentru a identifica asocierea deja reusita. Valoarea este un sir de cel mult 255 caractere ASCII, avand coduri n intervalul
[33, 126].
De asemenea, acest parametru este folosit si pentru a identifica ce cheie va fi
(re)folosita pentru criptare/decriptare.
openid.session type.
Pentru ca asocierea sa fie acceptata, valoarea acestui parametru trebuie sa fie aceeasi
ca cea primita la trimiterea cererii. In cazul n care utilizatorul propune pentru
acesta folosirea unui algoritm pe care serverul nu-l are, valoarea lui va fi de tip
r
aspuns nereusit, iar asocierea va pica.
openid.assoc type.
Similar situatiei anterioare, si valoarea acestui parametru de raspuns trebuie sa fie
identica cu cea primita ca lerere. In caz contrar, asocierea va pica, iar valoarea
parametrului va fi de tip raspuns nereusit.
openid.expires in.
Reprezinta perioada de timp n secunde cat este valabila asocierea. Dupa expirarea ei, aplicatia nu va mai lua n considerare asocierea.
openid.mac key.
Acest parametru se foloseste doar daca n timpul cererii s-a optat pentru tipul
sesiunii fara criptare. Valoarea trebuie sa fie n format base64.
openid.dh server public.
Reprezinta cheia publica a serverului OP . Va fi folosita n cadrul algoritmului DifieHellman.
10
CAPITOLUL 9. OPENID
openid.enc mac key.

Contine codul MAC, criptat cu cheia secreta Difie-Hellman.
Functia de dispersie este fie SHA1, fie SHA256, n functie de cum s-a stabilit n
timpul sesiunii.
9.4.3
Cererile de tip checkid setup si checkid immediate
Aceste doua mesaje sunt folosite pentru a primi informatii de la OP . Trimiterea mesajelor
se face de catre U RL, comunicarea fiind de tip indirect deci se utilizeaza protocolul
HT T P de tip GET.
Exista totusi o diferenta ntre cele doua cereri. Mesajul checkid immediate este
folosit de utilizatorii care suporta comunicarea prin AJAX (Asynchronous JavaScript
and XML), n timp ce checkid setup este specific celorlalti utilizatori (care nu suporta
AJAX).
In ambele situatii sunt folositi parametrii openid.ns, openid.mode, openid.claimed id,
openid.identity, openid.assoc handle, openid.return to, openid.realm.
openid.mode.
Valorile posibile sunt checkid immediate si checkid setup. Daca Identificatorul
de asociere doreste ca utilizatorii sa poata interactiona cu OP , valoarea folosita este
checkid setup.
In general, interactiunea ntre Bob si OP nu este dorita n cazul comunicarii asincrone.
openid.claimed id si openid.identity.
Acesti parametri trebuie sa fie prezenti amandoi sau nici unul. Primul contine
valoarea identificatorului pe care utilizatorul pretinde ca-l detine si deci trebuie
verificat.
openid.assoc handle.
Este un parametru optional; prezenta lui semnifica faptul ca a fost realizata o
asociere ntre parti si ca aceasta trebuie folosita.
openid.return to.
Dupa procesarea cererii, serverul OP trebuie sa ntoarca un raspuns. Daca este
specificata o valoare pentru acest parametru (o adresa U RL), atunci browserul va
fi redirectat catre aceasta adresa, cu tot cu raspuns.
openid.realm.
11
Prin intermediul acestui parametru se specifica domeniul site-ului cu care comunica

OP . Aceasta valoare trebuie sa existe daca parametrul openid.return to nu a fost
specificat.
9.4.4
R
aspunsul la cererile checkid setup si checkid immediate
Dupa ce au fost trimise cererile spre OP , acesta le analizeaza si formuleaza un raspuns. In

functie de moment, serverul OP poate cere nainte de a oferi raspunsul autentificarea
utilizatorului, ca sa fie sigur ca totul este n regula.
Ca si n cazurile anterioare sunt definiti o serie de parametri: openid.ns, openid.mode,
openid.op endpoint, openid.claimed id, openid.identity, openid.return to, openid.response
nonce, openid.invalidate handle, openid.assoc handle, openid.signed, openid.sig.
openid.mode.
In cazul unei asocieri reusite, valoarea parametrului trebuie sa fie id res.
Daca dintr-un motiv sau altul asocierea a picat, valoarea parametrului trebuie
sa fie setup needed daca cererea a fost de tip checkid immediate, sau cancel
n cazul cererii de tip checkid setup.
openid.op endpoint.
Valoarea acestuia este adresa serverului OP .
openid.return to.
Copia exacta a parametrului similar primit n cazul cererii.
openid.response nonce.
Acest parametru unic pentru fiecare mesaj este foarte important deoarece ajuta
la blocarea atacurilor prin reluare (replay attacks). Valoarea sa este de maxim 255
caractere si trebuie sa nceapa cu data de pe serverul OP n format U T C 2 si
delimitat prin litera Z urmata de caractere ASCII din intervalul [32, 126], cate
sunt necesare pentru asigura unicitatea raspunsului.
openid.invalidate handle.
Acest parametru verifica validitatea asocierii. Daca este setat, nseamna ca ceva a
fost n neregula, iar utilizatorul trebuie sa respinga asocierea.
openid.assoc handle.
Contine legatura spre asocierea cu care a fost semnat mesajul. Pe baza lui se pot
face verificari privind autenticitatea mesajelor.
2
http://www.ietf.org/rfc/rfc3339.txt - Formatul datei conform standardului U T C.
12
CAPITOLUL 9. OPENID
openid.signed.
Contine o lista cu parametrii care au fost semnati, despartiti prin virgula.
openid.sig.
Acest parametru contine semnatura mesajului, n format base64.
9.4.5
Cererea pentru verificarea autentific

arii (check authentication)
Verificarea autentificarii este poate pasul cel mai important n tot acest proces, deoarece
el asigura ca toate mesajele sunt trimise ntr-adevar de OP si nu de altcineva (care
impersoneaza acest server). Exista cateva observatii privind acest mesaj:
1. Mesajul este trimis doar daca nu exista deja o asociere stabilita ntre utilizatorul
Bob si OP .
2. Daca se foloseste o asociere deja existenta, cererea lui Bob trebuie sa contina parametrul openid.assoc handle, iar OP va avea n raspuns aceeasi valoare de asociere.
3. Se poate ntampla si cazul n care serverul OP nu este de acord cu asocierea primita
de la utilizator; atunci raspunsul va contine parametrul openid.invalidate handle,
precum si un alt parametru (openid.assoc handle) pentru a fi folosit de Bob.
9.4.6
R
aspunsul la cererea de verificarea autentific
arii
Raspunsul serverului OP este foarte scurt, avand doar trei parametri: openid.ns, openid.is
valid, openid.invalidate handle.
openid.ns:
Identic cu cel din cererea de asociere.
openid.is valid.
Are o valoare de tip boolean, true sau false, specificand daca semnatura cererii
este valida sau nu.
openid.invalidate handle.
Daca parametrul openid.is valid are valoarea false, acest parametru trebuie trimis
n cadrul raspunsului pentru ca utilizatorul sa stie si sa elimine asocierea respectiva
din lista celor valide.
9.5. SECURITATEA OP EN ID
9.5
13
Securitatea OpenId
O analiza a securitatii oferite de protocolul OpenId poate fi clasificata n patru categorii,

reprezentand caracteristici ale scopurilor pe care si propune sa le rezolve, ale practicilor
de implementare, ale specificatiilor OpenID si ale infrastructurii oferite de Web3 .
1. Semn
atur
a unic
a. Scopul construirii unui protocol OpenID este accesarea de
site-uri Web diferite, folosind o singura semnatura (SSO Single Sign On). Ideea
este ca odata ce un utilizator (U A) s-a autentificat la un OP , nu va mai trebui
sa repete ulterior acest protocol. Intr-o implementare standard, odata ce exista o
aprobare de autentificare pentru un RP , ea nu mai trebuie repetata.
2. Acces liber. O caracteristica importanta a unui OpenId este aceea ca un utilizator
este capabil sa-si aleaga propria sa identitate (U RL), OP si RP -urile. In principiu,
oricine se poate alatura structurii deja existente, implementand un OP sau ncepand
sa accepte tranzactii OpenID (ca un RP ).
3. Specificatii OpenID proprii. Anumite cerinte dintr-o specificatie OpenID pot
fi adaugate sau eliminate. Aceasta faciliatte poate duce nsa la diferente n implementare si n consecinta la unele falii de securitate.
4. Utilizare de standarde W eb. Pentru transferul datelor lui Bob ntre RP si OP
pot fi folosite redirectari W eb deja existente. Acest lucru usureaza cerintele celor
trei parteneri (RP, OP si U A), dar OpenID va mosteni toate slabiciunile posibil
existente n aceste mecanisme de redirectare.
9.5.1
Semn
atura unic
a
Atacurile se directioneaz
a spre OP -uri. Bob foloseste acelasi OP pentru a se
conecta la multiple RP -uri. Daca Oscar poate afla aceste credentiale, el va obtine
acces la toate RP -urile, inclusiv la datele lui Bob (stocate acolo).
Credentialele stocate ntr-un OP devin cu atat mai valoroase cu cat popularitatea
standardului OpenID creste. Pe de-alta parte, deoarece OpenID devine de facto
un standard pentru SSO de pe Web, OP -urile trebuie sa se concentreze foarte
mult pe asigurarea protectiei datelor utilizatorilor sai, ceea ce ngreuneaza mult
implementarea.
Spionarea OP -urilor. Deoarece pentru conectare se foloseste totdeauna acelasi
OP , acesta are posibilitatea de a conecta orice tranzactie cu orice RP vizitat de
utilizator. El poate monitoriza frecventa aparitiei unei tranzactii, momentele de
3
In literatur
a se pot nt
alni si alte clasificari, dar toate sunt n final similare cu cea prezentata n acest
capitol.
14
CAPITOLUL 9. OPENID
solicitare etc. Singurul efort al OP -ului este de a se conecta la orice tranzactie.

Folosind apoi tehnici de data mining (a se vedea [15]) se pot completa si prelucra
datele obtinute, totul ducand la un posibil atac.
Intr-un mediu fara aceasta facilitate OpenID, acest drept l are numai browserul
Web folosit de Bob. De exemplu, browser-ul Google Chrome trimite server-elor
Google toate URL-urile vizitate de (orice) utilizator, scopul declarat fiind o mbunatatire a mecanismmelor de functionare, dar si pentru alte prelucrari posibile.
Atacuri Cross-Site Scripting. Prin facilitatea ca Bob sa se conecteze cu OP -ul
sau la orice RP fara nici o restrictie, el nu mai va avea contact cu pagina de conectare
sau cu solicitarea unui RP de a se autentifica. Acest lucru permite dezvoltarea unor
atacuri cross-site scripting. Oscar poate plasa un frame ascuns pe un site Web,
ncarcand datele de conectare OpenId ale lui Bob, aflate pe un RP tinta. Dupa
aceea l conecteaza pe Bob permanent la RP , fara permisiunea acestuia. In acest
fel, Oscar poate lansa un atac XSRF (cross-site request forgery), actionand n
numele lui Bob ([15]). Din acest motiv (asa cum specifica solicitarea de deconectare
dupa terminarea vizitarii unei pagini) nu se poate garanta protectie contra atacurilor
de acest gen.
Din aceasta categorie face parte si atacul clickjacking ([7]) unde folosind unele
proprietati de vizualizare a paginilor Bob crede ca se conecteaza la un link (cu un
click pe numele acestuia) controlat de Oscar, conectandu-se de fapt pe alta pagina
(de reclama n cel mai inofensiv caz).
Sesiuni false. Intr-un astfel de atac, Oscar l pacaleste pe Bob sa viziteze replica
unei pagini despre care Bob crede ca are un anume RP . El va conecta apoi automat
pe Bob la RP -ul real, dintr-un cont controlat de Oscar. Datorita ideii de semnatura
unica, se presupune ca Bob a semnat conectarea din contul sau ([9]).
Prin acest atac, Oscar va cauta diverse informatii cum ar fi de exemplu cele legate
de conturi sau carduri depuse de Bob pe RP n convingerea ca aceasta este contul
sau proprietarul real fiind de fapt Oscar.
9.5.2
Acces liber
RP ca scaner de port. La nceputul protocolului, RP extrage identificatorul U RL

specificat de U A. Deoarece utilizatorul are libertatea de a alege orice valoare pentru
U RL, un adversar poate introduce U RL-uri cum ar fi http://www.example.com:21,
(deci practic un scaner proxy de port pentru RP ). El poate (n functie de
configuratia RP -ului) sa scaneze chiar si locatii interne, cum ar fi 192.168.1.45 : 3654
([15]).
9.5. SECURITATEA OP EN ID
15
Scanerul de port nu este propriu zis o slabiciune, dar posibilitatea de a scana adrese
din zona interna a unei retele locale a RP -ului si faptul ca aceasta scanare poate fi
realizata automat ofera o facilitate n constructia unui atac.
RP pierdut n c
autare. Acest atac foloseste faptul ca RP trebuie sa se conecteze
la identificatorul U RL oferit de utilizator. Un cod malitios poate folosi fisiere mari
sau fara marcaj de sfarsit ca identificatori de U RL-uri, ca prim pas pentru un atac
DoS asupra RP -ului ([15]).
Apararea contra unei astfel de ncercari este foarte simpla: RP trebuie sa efectueze
cautarea unui U RL n anumite limite de timp si spatiu.
9.5.3
Specificatii OpenID proprii
Atac Man-in-the-Middle. Protocoalele folosite pentru stabilirea de asocieri de

securitate si trimiterea M AC-urilor corespunzatoare de la OP spre RP folosesc cu
predilectie schimbul de chei Diffie-Hellman. Dar acesta este vulnerabil la un atac de
tip Man-in-the-Middle, n care Oscar actioneaza drept OP pentru RP si drept RP
pentru OP . Deci el va putea modifica toate datele trimise de OP spre RP , fara ca
RP sa realizeze ca semnatura este incorecta. In functie de locatie, Oscar se poate
conecta ca utilizator U A la un RP sau, ca utilizator U A dintr-un OP la orice RP .
Association Poisoning. In acest atac Oscar cauta numele unei asocieri (the association handle) pentru o anumita comunicare RP OP . Apoi se conecteaza la
RP folosind propriul sau OP . Deoarece OP i permite sa aleaga numele asocierii,
Oscar va alege exact numele pe care l-a gasit, nlocuind cheia M AC originala cu
una aleasa de el. Din acest moment, pentru o anumita durata de timp (pana
cand adevaratul OP rescrie numele asocierii), el poate semna (si eventual modifica)
atributele trimise de OP spre RP , folosind propria semnatura. RP va considera ca
mesajele trimise de OP sunt incorect semnate si le va respinge ([3]).
Pentru a modifica datele trimise de OP spre RP , Oscar trebuie sa instaleze (ca n
atacul Man-in-the-middle) un nod ntre cei doi parteneri.
Reciclarea OpenID-lui. In timp, Bob poate renunta la OP , lasand lui Alice
identitatea sa locala. Daca acest OP a fost conceput sa suplineasca identitatea
U RL-lui sau (de exemplu, daca s-a folosit username.myid.net sau daca butoanele
Google/Yahoo! etc. au fost utilizate direct), aceasta nseamna ca nu numai identitatea locala dar si identitatea U RL a lui Bob este detinuta acum de Alice. Ea se
poate conecta ulterior la un RP si afla date ale lui Bob.
Specificatiile OpenID 2.0 recomanda o solutie pentru aceasta problema, dar OP urile nu sunt obligate sa o adopte.
16
CAPITOLUL 9. OPENID
9.5.4
Utilizarea standardelor W eb
Phishing. Intr-un astfel de atac, Bob este ispitit sa viziteze un site Web impersonand ecranul sau de conectare din OP . Daca el nu observa ca acesta nu este
site-ul oficial al OP -lui si-si introduce credentialele, acestea sunt la dispozitia lui
Oscar ([11], [14]).
Astfel de atacuri au loc numai daca Bob face click pe un link nesigur; dar faptul ca OpenID redirectioneaza automat legaturile face posibila existenta unui atac
phishing mai putin evident. Un RP controlat de Oscar poate pur si simplu sal directioneze pe Bob la un OP fals, fara a genera nici o suspiciune ca se face o
conectare nedorita.
Folosirea unui OpenId ridica deci riscul unui atac de tip phishing.
Realm Spoofing. Acest atac ([11]) presupune existenta unui RP avand un XSS
(sau alta vulnerabilitate) care sa permita forwardarea spre alte websituri (de exemplu http://www.example.com?goto=http://evil.com). Oscar creaza un website care
imita acest RP si daca Bob ncearca conectarea folosind OpenID, Oscar i spune ca
OP cu acest domeniu apartine unui RP oficial. Ca urmare n returul spre U RL (ultimul pas din schema de functionare) el poate abuza de posibilitatea de forwardare
(care-l returneaza pe Bob spre propriu site web).
In caz de succes, OP si Bob sunt convinsi ca atributele sunt trimise spre RP -ul
oficial, ele fiind de fapt redirectate de Oscar la un RP fals (desi OP a comparat
domeniul realm si a facut corect revenirea la U RL).
Categorie
Vulnerabilitate
Semnatura unica Totdeauna aceleasi OP -uri
Tip de atac
=1 >1
Atacuri spre OP
S
M
OP si urmareste userii M
M
Conectare ne-interactiva
Cross-Site Scripting
R
R
Sesiuni false
S
M
Acces liber
Specifica orice identitate U RL Scaner de port RP
M
M
RP pierdut n cautare
R
R
Specificatii
Folosire chei Diffie-Hellmann
Man-in-the-middle
S
R
OpenID proprii Specificatii usoare
Association Poisoning
M
R
Reciclare OpenId
Utilizare de
RP duce U A la OP
Phising
R
R
standarde W eb
U A este n browser
Clickjacking
M
R
Realm Spoofing
Tabelul prezentat sumarizeaza aceste slabiciuni posibile generate de OpenId.
Ultimele doua coloane dau o estimare a riscului (S- scazut, M - mediu, R - ridicat)
pentru doua scenarii: unul n care OpenID este utilizat n servicii cu nivel de securitate
egal cu 1 (standard dezvoltat n [16]), iar al doilea n care OpenID este utilizat pentru
POSIBILE
9.6. REZOLVARI
17
servicii cu nivel de securitate ridicat. Estimarile de risc sunt bazate pe o combinatie ntre
efortul necesar atacului respectiv si avantajul pe care l poate obtine Oscar n caz de
reusita. Principala diferenta dintre cele doua scenarii pleaca de la prezumtia ca serviciile
cu un nivel de securitate ridicat implica un castig potential mai mare pentru atacator,
deci o preferinta a atacurilor pe falia de securitate respectiva.
O analiza a tabelului duce la concluzia ca un risc mediu ntr-un nivel de securitate
egal cu 1 este relativ moderat, n timp ce riscul mediu pentru serviciile cu nivel ridicat de
securitate este ridicat atunci cand se foloseste OpenId.
9.6
Rezolv
ari posibile
In [4] sunt trecute n revista o serie de propuneri de rezolvare a majoritatii acestor vulnerabilitati din constructia OpenId 2.0 (propuneri care nu au fost nca implementate).
9.6.1
Configuratii de ncredere
Multe din probleme provin din modul liber de comunicare oferit de OpenId; deci ele se
pot rezolva prin crearea unor bariere de securitate (Trust Frameworks) ntre identitati,
OP -uri si RP -uri. Daca acestea sunt protejate, orice ncercare a lui Oscar de a controla
una din ele ar fi prevenita.
Ca o consecinta, nu va mai fi posibila conectarea unui potential OpenID la orice
potential RP , iar utilizatorii nu vor mai putea utiliza dupa plac orice identitate sau OP .
9.6.2
Tehnici anti-phishing
Sunt doua modalitati de prevenire a atacurilor phishing.

OP -ul poate adauga elemente de personalizare cum ar fi un icon personal la
paginile de conectare. Aceste iconuri sunt bazate pe cookie-uri si deci vor fi activate
numai atunci cand utilizatorul viziteaza un OP de la un singur browser.
Clientul poate instala un software aditional (ncarcat de browser) care va asista utilizatorul n marcarea unor atacuri phishing potentiale. Un astfel de software poate
include mecanisme de ajutor n verificarea certificatelor si adreselor de domeniu
(cum ar fi aparitia barei de adrese, efect initiat cu prioritate de multe browsere) si
specificatii OpenID suplimentare (de exemplu SeatBelt [5] de la VeriSign, Sxipper
[6] si selectori de identitate Microsoft [7]).
Unele articole propun ca solutie BeamAuth (utilizarea de bookmark-uri), sugerata
de Adida n [2], al carei principal avantaj este acela ca nu necesita instalarea de
software suplimentar.
18
9.6.3
CAPITOLUL 9. OPENID
Prevenirea atacurilor de tip Cross-Site Scripting
RP si OP pot lua diverse masuri pentru contorizarea atacurilor cross-site scripting. De

exemplu, se poate folosi JavaScript pentru a asigura RP sau OP ca nu este ncarcat
ntr-un frame ascuns. Alta optiune posibila pentru RP -uri si OP -uri este de a solicita
o semnatura redusa (sesiunea de informare nu este folosita, dar Bob trebuie sa se reautentifice spre OP pentru fiecare RP specific).
In plus, se pot folosi solutiile generale construite pentru evitarea atacurilor cross-site
scripting; de exemplu se poate recomanda adaugarea de nonce-uri la fiecare interactiune
dintre utilizator si aplicatia de pe RP , lucru care va preveni generarea de actiuni generate
automat cu identitatea altui utilizator.
9.6.4
Specificatii adaptate
Unele probleme pot fi evitate sau diminuate folosind specificatiile OpenID 2.0 ([18]).
Probleme cum ar fi abuzul de RP (ca un scaner de port) sau atacuri DoS prezentand
un Identificator U RL fals pot fi evitate solicitand anumite standardizari suplimentare
ale Identificatorului U RL (de exemplu refuzul U RL-lor care contin numere de port sau
adresari de IP -uri locale)
Alta solicitare ar fi ca RP avand un nonce n protocolul de initializare Utilizator
- Client, sa verifice daca acest nonce exista si la sfarsitul sesiunii (astfel se nlatura o
ncercare de Sesiune falsa).
9.7
Concluzii
Protocolul OpenID poate fi considerat sigur daca M AC-ul si canalul de comunicatie

sunt considerate sigure. Totusi securitatea depinde de metodele de autentificare folosite
de furnizorii serviciilor OpenId. Unii furnizori folosesc parole, n timp ce altii au solutii
mai sofisticate.
Un utilizator trebuie sa poata avea ncredere n securitatea generala si integritatea OP ului sau. Daca un furnizor este compromis, un intrus se poate da drept orice utilizator
al acelui furnizor, pentru orice serviciu bazat pe OpenID. Din acest motiv, este putin
probabil ca OpenID sau orice alt sistem similar sa fie adoptat pe scara larga n
domenii n care securitatea comunicarii este esentiala (de exemplu internet banking). O
solutie ar putea fi totusi existenta catorva furnizori de servicii OpenId recunoscuti oficial
(de exemplu modul n care sunt emise legitimatiile electronice suedeze).
Pana atunci, OpenID ramane un instrument folosit atunci cand comoditatea este mai
importanta decat siguranta.
Bibliografie
[1] Atanasiu, A Securitatea informatiei, vol. 2 (Protocoale de securitate), Ed. Infodata,
Cluj (2009)
[2] Adida, B. BeamAuth: Two-Factor Web Authentication with a Bookmark, In ACM
Conference on Computer and Communications Security, pp. 48-57 (2007)
[3] Arnott, A. OpenID Association Spoofing. blog.nerbank.net (March 2009),
http://blog.nerdbank.net/2009/03/openid-association-poisoning.html
[4] van Delft, B., Oostdijk, M. A Security Analysis of OpenID, de Leeuw, E, FischerHubner, Fritsch, L. (Eds.), IDMAN 2010, IFIP AICT 343, pp. 73-84 (2010), IFIP
International Federation for Information Processing 2010
[5] Diffie, W., Hellman, M.E. New directions in Cryptography, IEEE Transactions on
Information Theory IT-22, 644-654 (1976)
[6] Drebes, L. Relying Party Stats as of Jan 1st, 2009, JanRain Blog (January 2009),
http://blog.janrain.com/2009/01/relying-party-stats-as-of-jan-1st-2008.html
[7] Hansen,R., Grossman, J. Clickjacking (September 2008),
http://www.sectheory.com/clickjacking.htm
[8] Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., Maler, E.
Profiles for the OASIS Securit Assertion Markup Language (SAML) V2.0 (March
2005), http://docs.oasis-open.org/security/saml/v2.0/
[9] Jain, A., Nash, A., Hodges, J. OpenID Security Issues. Presentation PayPal Information Risk Management (November 2009).
[10] Lawrence, K., Kaer, C. WS-Trust 1.4 OASIS Editor Draft (February 2008),
http://docs.oasis-open.org/ws-sx/ws-trust/ 200802/ws-trust-1.4-ed-01.html
[11] Messina, C. OpenID Phising Brainstorm (December 2008),
http : //wiki.openid.net, http : //wiki.openid.net/OpenID P hishing Brainstorm
19
20
BIBLIOGRAFIE
[12] Nanda, A. Identity Selector Interoperability Profile V1.0 (2007)

[13] Sovis, P., Kohlar, F., Schwenk, J. Security Analysis of OpenID
[14] Tom, A., Arnott, A. OpenID Security Best Practices. openid.net (July 2009),
http://wiki.openid.net/OpenID-Security-Best-Practices
[15] Tsyrklevich, E., Tsyrklevich, V. Single Sign-On for the Internet: A Security Story,
n BlackHat USA (2007)
[16] Office of Management and Budget (OMB). E-Authentication Guidance for Federal
Agencies, Memorandum M-04-04 (December 2003),
http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf
[17] oauth.net. OAuth Core 1.0 Revision A (June 2009), http://oauth.net/core/1.0a/
[18] openid.net. OpenID Authentication 2.0 - Final (December 2007),
http://openid.net/specs/openid-authentication-2 0.html (2009)
[19] http://dev.aol.com/OpenidTokenExchange
Lessons Learned From Previous SSL/TLS Attacks

A Brief Chronology Of Attacks And Weaknesses
Christopher Meyer, Jorg Schwenk
Horst Gortz Institute for IT-Security
Chair for Network and Data Security
Ruhr-University Bochum
{christopher.meyer, joerg.schwenk}@rub.de
AbstractSince its introduction in 1994 the Secure Socket
Layer (SSL) protocol (later renamed to Transport Layer Security
(TLS)) evolved to the de facto standard for securing the
transport layer. SSL/TLS can be used for ensuring data
confidentiality, integrity and authenticity during transport. A
main feature of the protocol is its flexibility. Modes of operation
and security aims can easily be configured through different
cipher suites. During its evolutionary development process
several flaws were found. However, the flexible architecture of
SSL/TLS allowed efficient fixes in order to counter the issues.
This paper presents an overview on theoretical and practical
attacks of the last 15 years, in chronological order and four
categories: Attacks on the TLS Handshake protocol, on the
TLS Record and Application Data Protocols, on the PKI
infrastructure of TLS, and on various other attacks. We try to
give a short Lessons Learned at the end of each paragraph.
A complete communication example (SSL 3.0/TLS 1.x)

illustrating the handshake phase finally leading to the application data phase is given in Figure 1.
Keywords-SSL, TLS, Handshake Protocol, Record Layer,

Public Key Infrastructures, Bleichenbacher Attack, Padding
Oracles
I. I NTRODUCTION
In 1994, Netscape1 addressed the problem of securing
data which is sent over the (TCP) wire in the early days
of the World Wide Web, by introducing the Secure Sockets
Layer protocol version 2. Over the decades SSL gained
improvements, security fixes and from version 3.1 on a new
name - Transport Layer Security2 - , but the basic idea
behind the protocol suite remained the same. A key feature
of SSL/TLS is its layered design consisting of mainly two
blocks:
Handshake protocol. This is an Authenticated Key Exchange (AKE) protocol for negotiating cryptographic secrets
and algorithms.
Record and Application Data protocol. This is an
intermediate MAC-then-PAD-then-Encrypt layer positioned
between the application and the TCP network layer.
In addition, error messages are bundled in the Alert protocol, and the one-message ChangeCipherSpec protocol
which signalizes the switch from unencrypted to encrypted
mode.
1 http://www.netscape.com
2 http://datatracker.ietf.org/wg/tls/
Figure 1: SSL/TLS communication example

Due to space limitations a comprehensive introduction
to SSL/TLS is skipped. A detailed view on SSL/TLS is
provided by Eric Rescorla in [1].
Many attacks of theoretical and practical nature have
been found and partly exploited. Ongoing research improves
recent attacks and aims to prove security or finding further
security related flaws.
In the following attacks are discussed in four groups:
attacks on the TLS Handshake protocol, the TLS Record
and Application Data Protocols, attacks on the TLS Public
Key Infrastructure, and various other attacks. In each of the
four groups, they are presented in chronological order.We
tried to formulate a very short lessons learned sentence
after each attack.
II. ATTACKS ON THE H ANDSHAKE P ROTOCOL
1) Cipher suite rollback: The cipher-suite rollback attack, discussed by Wagner and Schneier in [2] aims at
limiting the offered cipher-suite list provided by the client

to weaker ones or NULL-ciphers. An Man-in-the-middle
(Mitm) attacker may alter the ClientHello message sent
by the initiator of the connection, strips of the undesirable
cipher-suites or completely replaces the cipher-suite list with
a weak one and passes the manipulated message to the
desired recipient. The server has no real choice - it can either
reject the connection or accept the weaker cipher-suite. An
example scenario is illustrated in Figure 2.
Figure 3: Example scenario for the ChangeCipherSpec message drop attack - based on Source: [2]
Figure 2: Example scenario for the cipher-suite rollback
attack - based on Source: [2]
This problem was fixed with the release of SSL 3.0, by
authenticating all messages of the Handshake protocol, by
including hash value of all messages sent and received by
the client (the server, resp.) into the computations of the
ClientFinished (ServerFinished, resp.) message. However,
this hash value explicitly excludes messages of the Alert
and ChangeCipherSpec protocols, leaving room for
future attacks.
Lesson learned: This attack illustrates that it is crucial
to authenticate what exactly reached the desired target and
what was sent. Theoretically, this idea was put forward in
[3] with the concept of matching conversations.
2) ChangeCipherSpec message drop: This simple but
effective attack described by Wagner and Schneier in [2]
was feasible in SSL 2.0 only. During the handshake phase
the cryptographic primitives and algorithms are determined.
For activation of the new state it is necessary for both
parties to send a ChangeCipherSpec message. This
messages informs the other party that the following communication will be secured by the previously agreed parameters. The pending state is activated immediately after the
ChangeCipherSpec message is received.
An attacker located as Mitm could simply drop the
ChangeCipherSpec messages and cause both parties to
never activate the pending states. An example is illustrated
in Figure 3.
According to Wagner and Schneier the flaw was independently discovered by Dan Simon and addressed by Paul
Kocher. The authors recommendation is to force both parties
to ensure that a ChangeCipherSpec message is received
before accepting the Finished message. According to

RFC 2246 [4] TLS 1.0 enforces this recommendation.
Lesson learned: See Section II-1.
3) Key exchange algorithm confusion: Another flaw
pointed out by Wagner, Schneier in [2] is related to a feature
concerning temporary key material. SSL 3.0 supports the use
of temporary key material during the handshake phase (RSA
public keys or DH public parameters) signed with a long
term key. A problem arises from a missing type definition of
the transfered material. Each party implicitly decides, based
on the context, which key material is expected and decodes
accordingly. More precise, there is no information on the
type of the encoded key material. This creates a surface for
a type confusion attack.
This attack is, to the best of our knowledge, strictly
theoretical until time of writing. Figure 4 gives an attack
sketch where a client is fooled into establishing a RSA based
key agreement while at the same time performing DHE
(ephemeral Diffie-Hellman key exchange) with the server.
According to the authors, SSL 3.0b1 hinders this attack.
Lesson learned: This attack highlights the need for
context-free message structures: Misinterpretation of a
received message should be avoided by providing explicit
information on the content.
4) Version rollback: Wagner and Schneier described
in [2] an attack where a ClientHello message of SSL
3.0 is modified to look like a ClientHello message of
SSL 2.0. This would force a server to switch back to the
more vulnerable SSL 2.0.
As a countermeasure (proposed by Paul Kocher), the
SSL/TLS version is also contained in the PKCS encoded
In the following C denotes the ciphertext, P the plaintext,

e RSAs public exponent, d the private exponent and n the
modulus. RSA encryption is defined as C P e mod n
and decryption as P C d mod n.
Blinding sketch
1) Choose invertible integer s
2) Blind known ciphertext C: C 0 se C mod n
3) Let the oracle decrypt C 0 : P 0 C 0d mod n
4) Separate s from P 0 :P P 0 s1 mod n
Depending on the validness of a received PKCS structure
the processing at server side differs. In particular, SSL
specified to send different error messages for different errors
during processing (invalid padding, invalid MAC, ...). With
this information one can build an oracle as given in Figure 5.

true, if x is PKCS conforming
OP KCS (x) =
false,
otherwise
Figure 5: PKCS oracle
Figure 4: Example scenario for the key exchange algorithm

confusion attack - based on Source: [2]
Block Type
00 02
Padding
...
Separation Byte
00
Encapsulated Data
PreMasterSecret
Table I: PKCS#1 v 1.5 encoded PreMasterSecret

PreMasterSecret of the ClientKeyExchange message (when RSA-based cipher suites are used). The countermeasure is sufficient, since SSL 2.0 only supports RSAbased key exchange.
Lesson learned: This attack shows that backward
compatibility is a serious security threat: The
countermeasure described in Section II-1 against
modification of single messages does not help, since
it was not present in Version 2.0!
5) Bleichenbacher Attack on PKCS#1: In 1998 Daniel
Bleichenbacher presented in [5] an attack on RSA based
SSL cipher suites. Bleichenbacher utilized the strict structure
of the PKCS#1 v1.5 format and showed that it is possible to decrypt the PreMasterSecret in an reasonable
amount of time. The PreMasterSecret in a RSA based
cipher suites is a random value generated by the client
and sent (encrypted and PKCS #1 formatted) within the
ClientKeyExchange. An attacker eavesdropping this
(encrypted) message can decrypt it later on by abusing the
server as a decryption oracle. The format of PKCS #1 v1.5
is given in Table I.
Bleichenbachers attack utilized a) the fixed structure and
b) a known weakness of RSA to Chosen Ciphertext Attacks
(cf., [6]). The idea is to blind the original ciphertext, pass
it to the decrypter and finally separate the blinding value.
By the use of this oracle it is possible to decrypt the

PreMasterSecret by continuous blinding the eavesdropped, encrypted message. Based on the oracles responses
the intervals in which possible values may lie can be
narrowed, until only a single value is left.
Lesson learned: Bleichenbachers attack was possible
because error messages sent by the server could be used as
an oracle revealing partial information about the plaintext.
Thus apparently negligible pieces of information such as
distinguishable errors, which inform the counterpart on the
exact error cause, can be leveraged by an attacker to break
security. As a consequence it is necessary to reveal as little
information as possible on the internal state of the protocol
processing. Especially error messages are a valuable source
of information for attackers.
6) The rise of timing based attacks: Brumley and Boneh
outlined in [7] a timing attack on RSA based SSL/TLS.
The attack extracts the private key from a target server
by observing the timing differences between sending a
specially crafted ClientKeyExchange message and receiving an Alert message inducing an invalid formatted
PreMasterSecret. Even a relatively small difference
in time allows to draw conclusions on the used RSA
parameters. Brumleys and Bonehs attack of Brumley and
Boneh is only applicable in case of RSA based ciphersuites. Additionally, the attack requires the presence of a
fine resolute clock on the attackers side. The authors were
able to successfully attack OpenSSL.
OpenSSLs implementation relies on application of the
Chinese Remainder Theorem (CRT) in order to enhance
computation. CRT is generally not vulnerable to Paul
Kochers timing attack (cf., [8]), but additionally to the
CRT optimization OpenSSL uses optimizations such as
sliding-window exponentiation which in turn heavily relies

on Montgomerys reduction algorithm for efficient modulo
reduction. Montgomerys algorithm and others require multiprecision multiplication routines. OpenSSL implements two
different algorithms to perform such multiplications: Karatsuba algorithm and an unoptimized algorithm. For these
algorithms the integer factors are represented as sequences
of words of a predefined size. Due to efficiency reasons
OpenSSL uses Karatsuba if words with equal number of
words are multiplied and the standard algorithm otherwise.
According to the authors the normal algorithm is generally
much slower than Karatsuba, resulting in a measurable
timing difference. But due to a peculiarity of Montogmerys
algorithm (an additional extra reduction in some cases) the
optimizations of Montgomery and Karatsuba counteract one
another. This prevents a direct timing attack.
Moreover, the authors attack determines the dominant effect
at a specific phase and leverages the differences. The authors
define their algorithm as a kind of binary search for the lower
prime of the RSA modulus n (n = pq).
As a countermeasure the authors suggest, as the most
promising solution, the use of RSA blinding during decryption. Blinding uses a a random value r and computes p = re c
mod n before decryption (p : plaintext, c : ciphertext, n :
RSA modulus, e : public exponent). The original plaintext can be recovered by decrypting and dividing by r:
e e d
e d
n
.
p (r c) r mod n (r p ) r mod n rp mod
r
The attack was significantly improved in 2005 by Aciicmez, Schindler and Koc in [9].
Lesson learned: Brumley and Boneh demonstrated
that designers have to take special care on building
implementations with nearly equal response times for each
conditional branch of message processing.
7) Improvements on Bleichenbachers attack: The researchers Klma, Pokorny and Rosa not only improved
Bleichenbachers attack (cf. II-5) in [10], but were able to
defeat a countermeasure against Bleichenbachers attack.
Breaking the countermeasure A countermeasure
against Bleichenbachers attack is to generate a random
PreMasterSecret in any kind of failure and continue
with the handshake until the verification and decryption of
the Finished message fails due to different key material (the PreMasterSecret differs at client and server
side). Additionally, the implementations are encouraged to
send no distinguishable error messages. This countermeasure is regarded as best-practice. Moreover, because of a
different countermeasure concerning version rollback attacks (cf., II-4) the encrypted data includes not only the
PreMasterSecret, but also the major and minor version
number of the negotiated SSL/TLS version. Implementations
should check for equality of the sent and negotiated protocol
versions. But in case of version mismatch some implementations again returned distinguishable error messages to the
sender (e.g. decode_error in case of OpenSSL). It is

obvious that an attacker can build a new (bad version) oracle
from this, as shown in Figure 6.

true, if version number is valid
OBadV ersion (c ) =
false,
otherwise
Figure 6: Bad Version Oracle
With a new decryption oracle OBadV ersion Klma, Pokorny and Rosa were able to mount Bleichenbachers attack,
in spite recommended countermeasures are present.
Improving Bleichenbachers attack on PKCS#1 Additionally to the resurrection of Bleichenbachers attack
the authors could improve the algorithm for better performance. These optimizations included redefinition of interval
boundaries for possible PKCS conforming plaintexts. These
improvements are based on advanced knowledge gained
from the SSL/TLS specification:
A PreMasterSecret is exactly 46 bytes longer
The PreMasterSecret is prefixed with two version
bytes
Padding bytes are unequal to 00
A PKCS conforming plaintext Mi contains a nullbyte separating the padding from the payload data.
The length of the padding is known in advance (2
type bytes, k 51 padding bytes, a single null byte
as a separator, 2 bytes for the version number and 46
PreMasterSecret bytes)
Even tighter adjustment is possible, since the used protocol
version is known in advance, revealing another 2 bytes.
Another optimization was made to the original algorithm
by introducing a a new method on how to find suitable
blinding values. The authors call this the Beta method.
As a last optimization Klma, Pokorny and Rosa suggested
to parallelize steps of Bleichenbachers algorithm, which
speeds up the attack.
Lesson learned: Countermeasures against one
vulnerability (cf. II-4) may lead to other vulnerabilities.
8) ECC based timing attacks: At ESORICS3 2011
Brumley and Tuveri [11] presented an attack on ECDSA
based TLS connections. As to their research only OpenSSL
seemed to be vulnerable.
The problem arose from the strict implementation of an
algorithm for improving scalar multiplications, which ECC
heavily relies on, such as e.g., point multiplication. The
implemented algorithm for performing such scalar multiplications, known as the Montgomery power ladder [12] (with
improvements by Lopez and Dahab [13]), is timing resistant
from a formal point of view, but from implementational point
of view contained a timing side-channel. The developers
optimized the performance of the algorithm by reducing the
repetitions of internal loops, leading to a timing side channel.
3 https://www.cosic.esat.kuleuven.be/esorics2011/
When arranging the integer of a scalar multiplication (k) in

a binary tree (leading zeros stripped) the trees height is
dlog(k)e 1 (1 since the first bit is expected to be 1, thus
ignoring the first level of the tree). This implies that the
runtime of the algorithm is t(dlog(k)e 1), where t denotes
some constant time of the algorithm. As a result, timing
measurements enabled drawbacks on the multiplier.
Brumley and Tuveri combined this side channel with
the lattice attack of Howgrave-Graham and Smart [14]
to recover secret keys. For this to work they identified
that creating ECDSA signatures relies on scalar multiplication. ECDSA signatures are generated in TLS/SSL when
ECDHE_ECDSA cipher-suites are used. The authors measured the time between the ClientHello message and
the arrival of the ServerKeyExchange message during
the handshake phase. The latter message contains an ECDSA
signature over a digest, consisting of relevant parts necessary
for further establishment of cryptographic material. As this
digital signature can only be created on-the-fly, and not in
advance, an adversary is able to measure runtime of the
vulnerable scalar multiplication function.
Lesson learned: Side channels may come from
unexpected sources.
9) Even more improvements on Bleichenbachers attack: In [15] Bardou, Focardi, Kawamoto, Simionato, Steel
and Tsay significantly improved Bleichenbachers attack
(cf., II-5) far beyond the previous improvements of Klma,
Pokorny and Rosa (cf., II-7). Bardou et al. fine-tuned the
algorithm to perform faster and with lesser oracle queries.
Additionally, the authors combined their results with the
previous improvements and were able to significantly speed
up Bleichenbachers algorithm.
Lesson learned: Attacks improve and adjust as time
goes by. It is necessary to observe research on attacks (even
if they are patched yet).
III. ATTACKS ON THE R ECORD AND A PPLICATION DATA

P ROTOCOLS
The attacks presented in this section are enabled by
weaknesses of the Record or Application Data Protocol
and/or the structure of record frames.
A. Attack discussion
1) MAC does not cover padding length: Wagner and
Schneier pointed out in [2] that SSL 2.0 contained a major weakness concerning the Message Authentication Code
(MAC). The MAC applied by SSL 2.0 only covered data
and padding, but left the padding length field unencrypted.
This may lead to message integrity compromise.
Lesson learned: Not only since the introduction of
padding oracles by Vaudenay (cf., III-A2) each single
bit of information should be considered useful for an
attacker. Thus, information should be integrity protected
and authenticated to keep the attack vector as small as
possible.
2) Weaknesses through CBC usage: Serge Vaudenay
introduced a new attack class, padding attacks, and forced
the security community to rethink on padding usage in
encryption schemes [17].
The attacks described by Vaudenay rely on the fact that
block encryption schemes operate on blocks of fixed length,
but in practice most plaintexts have to be padded to fit
the requested length (a multiple of the block length). After
padding, the input data is passed to the encryption function,
where each plaintext block (of length of the block size)
is processed and chained according to the Cipher Block
Chaining Mode (CBC) scheme. The CBC mode chains
consecutive blocks, so that a subsequent block is influenced
by the output of its predecessor. This allows an attacker
to directly influence the decryption process by altering the
successive blocks. For convenience, Figure 7 gives a short
recap of the CBC en-/decryption mode.
10) ECC-based key exchange algorithm confusion attack: In [16] Mavrogiannopoulos, Vercauteren, Velichkov
and Preneel showed that the key exchange algorithm confusion attack by Wagner and Schneier, discussed in II-3,
can also be applied to ECDH. According to the authors,
their attack is not feasible yet, due to computational limitations. But, as already discovered with other theoretical only
attacks, it may be a question of time when the attack is
enhanced to be practical or the resources for computation
increase. As discussed by Wagner and Schneier, the main
problem remains the lack for a content type field indicating
the algorithm type of the contained data - which implicitly
indicates how to decode the message.
Lesson learned: See II-3
Figure 7: Encryption/Decryption in CBC Mode
Vaudenay builds a decryption oracle out of the receivers reaction on a ciphertext in case of valid/invalid
padding. In the case of SSL/TLS the receiver may send
a decryption_failure alert, if invalid padding is encountered. The padding oracle is defined in Figure 8.

OP adding (C) =
true,
false,
if C is correctly padded
otherwise
Figure 8: Padding oracle

By the use of such an oracle and clever changes on the
ciphertext an attacker is able to decrypt a ciphertext without
knowledge of the key. The optional MAC ensuring message
integrity of SSL/TLS does not hinder this attack, since MAC
creation takes place before the message is padded. Thus, the
padding is not covered by the MAC.
Lesson learned: Although the attack is not directly
applicable to standard SSL/TLS (since Fatal errors immediately invalidate the session and accordingly the key material), it is applicable to DTLS (as discussed later in III-A11).
Thus, this theoretical attack should not be ignored. Again,
error messages can form the base for decryption oracles.
As a solution, SSL defines equal error messages for
padding and decryption errors. But there still remains some
room for timing attacks (due to conditional execution paths
in the SSL stack). The CBC mode leveraged the attack, so
the usage of weak schemes like CBC should be rethought
and replaced by more secure, authenticated encryption
schemes such as Galois/Counter Mode (GCM) [18].
3) Information leakage by the use of compression:
In [19] Kelsey described an information leak enabled by
a side-channel based on compression. This is in absolute
contrast to, what the author calls folk wisdom, that applying compression leads to a security enhanced system.
Kelsey showed that it adds little security or, in the worst
case, is exactly the other way around, due to the fact that
compression reveals information on the plaintext.
Cryptosystems aim at encrypting plaintexts in a way that
the resulting ciphertext reveals little to no information on the
plaintext. Kelsey observed that by the use of compression a
new side-channel arises which could be used to gain hints
on the plaintext. Therefor he correlates the output bytes of
the compression to the input bytes and makes use of the fact
that compression algorithms, when applied to the plaintext,
reduce the size of the input data.
Compression algorithms encode redundant patterns in input data to shorter representations and substitute each occurrence with the new representation. Different input strings of
the same length are likely to compress to strings of different
length. Kelsey used this observation to gain knowledge about
the plaintext. Kelsey advices that also timing issues have
to be taken into consideration, since compression as an
additional step requires additional processing time.
Although this attack was not exploited at that time it lead

to the development of Rizzo and Duongs C.R.I.M.E. tool
(cf. III-A12) in 2012.
Lesson learned: Kelseys observation is interesting
since it breaks with the folk wisdom that applying
compression leads to security enhanced systems.
Compression may lead to hidden side-channels (compression
rate, timing, etc.). It seems that optimizing for performance
in accordance with security is hazardous. Performance
optimizations should be proved against possible sidechannels and skipped or adjusted (which in turn may
counterbalance the performance gain).
4) Intercepting SSL/TLS protected traffic: In [20] Canvel, Hiltgen, Vaudenay and Vuagnoux extended the weaknesses presented by Vaudenay (cf., III-A2) to decrypt a
password from an SSL/TLS secured IMAP session.
Canvel et al. suggested three additional attack types based
on Vaudenays observations:
Timing Attacks The authors concluded that a successful
MAC verification needs significantly more time compared to
a premature abortion caused by an invalid padding. This observation relies on the fact that performing a padding check
is less complex than performing cryptographic operations as
they are necessary to verify a MAC.
Multi-session Attacks The basic idea of this attack type
requires a critical plaintext to be present in each TLS
session (such as e.g., a password) and that the corresponding
ciphertext is known to the attacker. Due to the nature of
security best-practice the corresponding ciphertexts look
different every session, since the key material for MAC and
encryption changes every session. Therefor, it is advantageous to check if a given ciphertext ends with a specific
byte sequence (which should be identical in all sessions)
instead of trying to guess the whole plaintext.
Dictionary attacks Leveraged by the previous attack type
which checks for a specific byte sequence of the plaintext
this attack aims at checking for byte sequences included in
a dictionary.
A successful attack against an IMAP server was performed and the password used by the LOGIN command
could be recovered. As a recommendation the authors propose to change the processing order when encrypting. The
MAC should also cover the padding, which implies the order
PAD-then-MAC-then-Encrypt.
Lesson learned: It may be advantageous to change
the order of processing to PAD-then-MAC-then-Encrypt,
but this in turn may leverage other attacks and has to
be carefully considered and accurately specified before
implementation. The order of processing makes a big
difference and should payed special attention.
5) Chosen-Plain-text Attacks on SSL: Gregory Bard
observed in [21] an interesting detail concerning Initializa-
tion Vectors (IVs) of SSL messages. As can be seen from

Figure 7 every en- and decryption in CBC mode depends on
an IV. Every new plaintext (consisting of multiple blocks)
should get its own, fresh and independent IV.
The problem with SSL is that, according to the SSL
specification, only the IV of the first plaintext is chosen
randomly. All subsequent IVs are simply the last block of the
previous encrypted plaintext. This is absolutely in contrast
to cryptographic best-practice.
Bard observed that an attacker willing to verify a guess
if a particular block has a special value and is in possession
of an eavesdropped ciphertext can easily check her guess.
An attacker could mount an attack if she knows exactly
which block is of interest. This knowledge is not as strong
as it seems to be, since the strict format of e.g., https://
requests contains fixed header fields which are known in
advance. Additionally, the previous block must be known
which is mostly no problem. If the second precondition is
fulfilled determining the IV used for this encryption remains
an easy task, since it is the last block of the preceding
message. Finally, an attacker has to find a way to inject
data to the first block of the subsequent message.
The vulnerability was at the same time discovered by
Bodo Moller who described the weakness in detail in a
series of emails on an IETF mailing-list4 . In this series
Moller described a fix which was later used by the OpenSSL
project: Prepending a single record with empty content,
padding and MAC, to each message.
As potential fixes for the IV vulnerability Bard recommended the use of pseudo random IVs or dropping CBC
and switching to a more secure encryption mode. TLS
1.1 follows the first recommendation by introducing an
IV field into the GenericBlockCipher structure which
encapsulates encrypted data.
The practicability of this attack was proven by Bard two
years later (cf. III-A6).
Lesson learned: The weakness outlined by Bard is a
good example for ignoring security best-practices for the
sake of simplicity.
6) Chosen-Plain-text Attacks on SSL reloaded: The
attack by Bard discussed in III-A5 was revisited by Bard in
a publication in 2006 [22]. Overall Bard addressed the same
topics as before, but provided an attack sketch how to exploit
this problem. Bard described a scenario in which an attacker
uses a Java applet, executed on the victims machine, to
mount the attack as described in III-A5. As a precondition
it is necessary to access a common used SSL tunnel. Bard
refers to HTTP-Proxy or SSL based tunneling scenarios.
It is outlined that this scenario does not work if compression is used. Many preconditions have to be fulfilled in
order to be able to successfully attack a SSL connection
4 http://www.openssl.org/bodo/tls-cbc.txt
(the author states that it is challenging but feasible).

However, Bard gives an example for block-wise-adaptive
chosen plaintext attacks targeting SSL. Rizzo and Duong
proved in III-A8 that Bards attack scenario is applicable,
in a slightly different implementation (by using JavaScript
instead of Java applets). The described attack was adopted
and adjusted in their B.E.A.S.T. tool (cf. III-A8).
The vulnerability is fixed with TLS 1.1, since it dictates
the use of explicit IVs.
Lesson learned: Not only the protocol has to be
considered when evaluating security - the interplay between
different layers and applications is relevant, too.
7) Traffic analysis of TLS: George Danezis highlighted
in an unpublished manuscript [23] ways how an attacker may
use the obvious fact that minimal information, despite the
connection is TLS protected, remains unencrypted to analyze
and track traffic. In particular, Danezis used unencrypted
fields, part of every TLS message, of the TLS Record Header
for analysis. Figure 9 shows an encrypted TLS Record
containing unencrypted header fields and encrypted payload.
struct {
ContentType type ;
ProtocolVersion version ;
uint16 length ;
s e l e c t ( CipherSpec . cipher type ) {
case stream : GenericStreamCipher ;
case block : GenericBlockCipher ;
} fragment ;
} TLSCiphertext ;
Figure 9: TLS Cipher-text Record - Source: RFC 2246 [4]

As can be seen the fields type, version and length
remain always unencrypted - even in an encrypted record.
The fields are necessary for correct record decoding. In [2]
the authors already criticized the presence of such unauthenticated and unencrypted fields. RFC 2246 is also aware of
this information leak and advices to take care of this:
Any protocol designed for use over TLS must
be carefully designed to deal with all possible
attacks against it. Note that because the type and
length of a record are not protected by encryption,
care should be take to minimize the value of traffic
analysis of these values.
- Source: RFC 2246 [4]
Danezis identified several information leaks introduced by
these unencrypted fields:
Requests to different URLs may differ in length which
results in different sized TLS records.
Responses to requests may also differ in size, which
again yields to different sized TLS records.
Different structured documents may lead to a predictable behavior of the clients application. For example a browser is normally gathers all images of
a website - causing different requests and different

responses.
Content on public sites is visible to everyone, an
attacker may link content (e.g., by size) to site content.
Moreover, an attacker could also actively influence the
victims behavior and gain information about what she is
doing (without knowledge of the encrypted content) by
providing specially crafted documents with particular and
distinguishable content lengths, structures, URLs or external
resources. The traffic analysis is not only limited to TLS, but
at least it reveals a weakness that can be exploited.
The author provides some hints on how the surface of
the attack can be limited, but the practicability of the
recommended measures remains questionable.
URL padding - all URLs are of equal length
Content padding - all content is of equal size
Contribution padding - all submitted data is of equal
size
Structure padding - all sites rely on an equal structure
(e.g., sites with equal number of external resources aso.)
This flaw was also discussed by Wagner and Schneier
in [2], but in a limited manner. Wagner and Schneier credited
Bennet Yee as the first one describing traffic analysis on
SSL. As a countermeasure Wagner and Schneier suggested
support for random length padding not only for block cipher
mode, but for all cipher modes. The use of random length
padding should be mandatory.
The feasibility of Danezis attack was proven by Chen,
Wang, Wang and Zhang in [24] who investigated multiple
real world web applications for these kind of side-channels.
Lesson learned: Clever and creative attackers may
find ways to use every obtainable part of information for
further attacks. More sophisticated attacks are possible
if fields are left unauthenticated. Protocol designers and
developers should be aware of this fact and sparely disclose
any information. This also applies to error messages. If
in doubt only use a single error message for all occurring
errors. One may question herself what the counterpart
could really do if she knows exactly what went wrong (bad
padding, invalid MAC, etc.) If she is a valid user she would
simply try again or give up, independent from a detailed
error message. On the other hand an attacker is grateful for
every peace of information, even a single bit.
8) Practical IV Chaining vulnerability: Rizzo and
Duong presented in [25] a tool called B.E.A.S.T. that is
able to decrypt HTTPS traffic (e.g., cookies). The authors implemented and extended ideas of Bard [21], [22],
Moller and Dai 5 . The combination of CBC mode applied
to block ciphers (cf., Figure 7) and predictable IVs (cf.,
Chapter III-A5) enabled guessing of plaintext blocks and
verify the validness. To verify a guess an oracle OGuess is
5 http://www.weidai.com/ssh2-attack.txt
required returning true in case of a successful guess and

false otherwise, Figure 10 illustrates such an oracle.

true, if guess P equals the plaintext
OGuess (P ) =
false,
otherwise
Figure 10: Guessing oracle
Rizzo and Duong created such an oracle based on the
precondition that the IVs used by CBC (the last encryption
block of the preceding encryption) are known to the attacker.
To adopt the technique to SSL/TLS and decrypt ciphertexts byte-wise the authors propose a new kind of attack
named block-wise chosen-boundary attack. It requires that
an attacker is able to move a message before encryption in
its block boundaries. This means an attacker may prepend
a message with arbitrary data in such a way that it is split
into multiple blocks of block-size of the cipher. Based on
this, it is possible to split a message of full block-size into
two blocks: the first one consisting of arbitrary data and the
first byte of the original block, the second block consisting
of the remaining bytes and a single free byte. So prefixing
a message with an attacker defined amount of data shifts
the message (if necessary into a new block). An attacker is
absolutely free to prepend any data of her choice and length.
An example is given in Figure 11.
Figure 11: Example boundary shifting

Full message decryption
To decrypt a full message the attacker adjusts the amount
of random prefix data so that the next unknown byte is
always the last byte in a block. This means in detail that
the message is shifted in such a way, that the scenario
illustrated in Figure 11 applies to the next unknown byte.
The unknown byte becomes the last and only byte of a single
block unknown to the attacker. Finally, this leads to a byte
by byte message decryption.
To apply the previously discussed algorithm Rizzo and
Duong chose HTTPS as SSL/TLS protected application
(protocol). The goal is to decrypt cookies sent by a browser
to a server for authentication. For a successful attack some
preconditions have to be met:
1) An attacker is able to sniff the traffic between victim
and server
2) An attacker can force a victim to perform HTTP(S)
POST requests to the server
3) An attacker can control the document path of the
POST request
4) An attacker forces the victim to visit a website under

control of the attacker to inject exploit code
Due to this massive vulnerability, migration to TLS Version
1.1 has been recommended since by IETF.
Lesson learned: This attack shows that vulnerabilities
considered to be theoretical only can turn in to practice
if skilled attackers put effort in the implementation and
fine-tune the algorithm.
9) Short message collisions and busting the length
hiding feature of SSL/TLS: In [26] Paterson, Ristenpart and
Shrimpton outlined an attack related to the MAC-then-PADthen-Encrypt scheme in combination with short messages. In
particular their attack is applicable if all parts of a message
(message, padding, MAC) fit into a single block of the
ciphers block-size. Under special preconditions the authors
described the creation of multiple ciphertexts leading to the
same plaintext message.
Lesson learned: The surface for this attack is limited,
since the precondition (message, padding and MAC have to
fit into a single block) is quite strong. But it revealed that
in some special cases the preconditions are met.
10) Message distinguishing: Paterson et al. extended
in [26] the attack described in III-A9 enabling an attacker
to distinguish between two messages. The authors sketch
how to distinguish whether the encrypted message contains
YES or NO. The attack is based on clever modification
of the eavesdropped ciphertext so that it either passes the
processing or leads to an error message. Based on the
outcome (error/no error) it is possible to determine which
content was send. The attack works only if the possible
contents are of different, short length. At least, the attack
remains unexploitable due to the fact that it is only possible
for 80 bit truncated MACs. While in versions prior to TLS
1.2 the use of truncated MACs was possible, 1.2 restricts it.
Anyway, truncated MACs are possible in TLS 1.2, too, by
the use of protocol extensions.
Lesson learned: See III-A9.
11) Breaking DTLS: In [27] AlFardan and Paterson
applied Vaudenays attack (cf., III-A2) to DTLS. DTLS
is a slightly different version of regular TLS adjusted to
unreliable transport protocols, such as UDP. There are two
major differences when compared to standard TLS:
1) Complete absence of Alert messages
2) Messages causing protocol errors (bad padding, invalid
MAC, ...) are simply dropped, instead of causing a
connection abort invalidating the session keys
These adjustments are advantageous, as well as disadvantageous at the same time. Vaudenays attack may work on
DTLS since bad messages do not cause session invalidation.
But with the lack of error messages the oracles introduced by
Vaudenay can not be used without adjustment. The attacker

gets no feedback whether the modified messages contained
a valid padding or not. The authors adjusted Vaudenays
algorithms by using a timing oracle arising from different
processing branches with unequal time consumption.
AlFardan and Paterson covered the OpenSSL and
GnuTLS implementations, both vulnerable to a timing oracle
enhanced version of Vaudenays attack. The timing oracle
of OpenSSL arises from a padding dependent MAC check.
In case of correctly padded data the MAC is checked,
where in case of an incorrect padding the verification is
skipped. This behavior leads to a measurable timing difference allowing drawbacks on the validity of the padding.
GnuTLS in contrast contains a timing side-channel during
the decryption process where sanity checks are performed
prior to decryption.
While the side-channel of OpenSSL is a consequence of
missing countermeasures, even GnuTLS - which implements
all recommended countermeasures - is vulnerable. When
timing differences are too little, reliable timing differences
are gained by sending multiple copies leading to an accumulation of timing differences. According to the authors, it
was necessary for the proof of concept attack to disable the
protocols anti-replay option, which is enabled by default.
Lesson learned: The authors recommend to
specification authors that defining standards by only
defining differences to previous standards should be
avoided (DTLS is a sub-specification of TLS).
12) Practical compression based attacks: In September 2012 Juliano Rizzo and Thai Duong presented the
C.R.I.M.E. attack tool. C.R.I.M.E. targets HTTPS and is able
to decrypt traffic, enabling cookie stealing and session takeover. It exploits a known vulnerability caused by the use of
message compression discovered by Kelsey in 2002 [19].
The attack relies on plaintext size reduction caused by
compression. Given that an attacker is able to obtain the
(real) size of an encrypted, compressed plaintext (without
padding) she might decrypt parts of the ciphertext by observing the differences in size. An attacker does neither know the
plaintext, nor the compressed plaintext, but is able to observe
the length of the ciphertext. So basically, she prefixes the
secret with guessed subsequences and observes if it leads to
compression (by observing the resulting ciphertext length).
A decreased ciphertext length implies redundancy, so it is
very likely that the guessed, prefixed subsequence caused
redundancy in the plaintext. It can be concluded that with
higher redundancy of input data the better the compression
ratio, resulting in length decreased output. This implies that
a guess, having something in common with the secret, will
have a higher compression rate leading to a shorter output.
When such an output is encountered the attacker knows that
the guess has something in common with the secret.
As preconditions an attacker must be able to sniff the
network and attract a user to visit a website under the

attackers control. Further on, both - client and server have to use compression enabled SSL/TLS. The website
controlled by the attacker delivers C.R.I.M.E. as JavaScript
to the victims browser. Once the script is running an attacker
starts guessing - e.g., the right cookie value - and forcing the
victim to transport the guess concatenated with the desired
cookie as an SSL/TLS message (at least encrypted).
Lesson learned: This attack is just another example for
mainly theoretical attacks that were found to be practical by
skilled attackers.
Normally, issuing subsequent certificates is only valid

if the CA:TRUE flag is present in the own certificate.
Otherwise, certificate inspectors should reject certificates
issued by (intermediate) CAs with insufficient rights.
The tool sslsniff7 provides a proof of concept implementation with the attacker acting as Mitm, issuing certificates for a requested domain on the fly. After a successful
attack the Mitm impersonates the requested server. The basic
functionality of the tool is illustrated in Figure 12.
IV. ATTACKS ON THE PKI

Checking the validity of X.509 certificates is an area full
of problems, which cannot be covered in an overview on
TLS attacks (especially usability aspects). However we want
to point to some specific problems that are technically very
closely related to TLS.
1) Weak cryptographic primitives lead to colliding certificates: Lenstra, Wang and de Weger described in 2005
how an attacker can create two valid certificates with equal
hash values by computing MD5 collisions [28]. With colliding hash values it is possible to impersonate clients or servers
- attacks of this kind render very hard to detect Mitm attacks
possible.
The practicality of the attack was demonstrated in 2008
by Sotirov et al. 6 who were able, through clever interaction
between certificate requests from a legal CA and a massively
parallel search for MD5 collisions, to create a valid CA
certificate for TLS. With the help of this certificate they
could have issued TLS server certificates for any domain
name, which would have been accepted by any user agent.
(To make sure that their results cannot be misused, they
however chose to create an expired CA certificate.)
Lesson learned: As long as user agents accept MD5
based certificates, the attack surface still exists, even if CAs
stop issuing such certificates. Thus MD5 must be disabled
for certificate checking in all user agents. Moreover, weak
algorithms may lead to complete breach of the security
when targeting the trust anchors.
2) Weaknesses in X.509 certificate constraint checking:
In 2008, US hacker Matthew Rosenfeld, better known as
Moxie Marlinspike, published a vulnerability report [29]
concerning the certificate basic constraint validation of Microsofts Internet Explorer. The Internet Explorer did not
check if certificates were allowed to sign sub-certificates (to
be more technical, if the certificate is in possession of a
CA:TRUE flag). Any valid certificate, signed by a valid CA,
was allowed to issue sub certificates for any domain.
6 http://www.win.tue.nl/hashclash/rogue-ca/
Figure 12: Basic mode of operation of sslSniff - Impersonating a server

Lesson learned: The attack relies on a specific
implementation bug and has been fixed. However, certificate
validation is a critical step.
3) Attacks on Certificate Issuer Application Logic: Attacks on the PKI by exploiting implementational bugs on CA
side were demonstrated by Moxie Marlinspike in [30], who
was able to trick the CAs issuance logic by using specially
crafted domain strings. Marlinspike gained valid certificates
for arbitrary domains, issued by trusted CAs. As a prerequisite for the attack it is necessary that the issuer only checks if
the requester is the legitimate owner of the TLD. An owner
of a TLD may request for certificates issued for arbitrary
sub-domains (e.g., the owner of example.com may also
request certificates for subdomain.example.com).
Marlinspike makes use of the encoding of X.509 ASN1. ASN1 supports multiple String formats, all leading
to slightly different PASCAL String representation conventions. PASCAL represents Strings length-prefixed (a leading
length byte followed by the according number of bytes, each
representing a single character). An example is given in
Figure 13.
Figure 13: String representation - PASCAL convention

In contrast C Strings are stored in NULL-terminated representation. Here, the character bytes are followed by a NULL
byte signalizing the end of the String. This implies that
NULL bytes are prohibited within regular Strings, since they
would lead to premature String termination. This scheme is
illustrated in Figure 14.
7 http://www.thoughtcrime.org/software/sslsniff/
Figure 14: String representation - C convention
This knowledge prepares the way for the NULL-Prefix

attack: A sample domain name which could be used
in a Certificate Signing Request (CSR) is the following
www.targetToAttack.com\0.example.com,
assuming that the attacker is the owner of example.com.
The attack works, because the CA logic only checks the
TLD (example.com). The leading NULL-byte (\0) is
valid because of ASN1s length-prefixed representation
(where NULL-bytes within the payload String are valid).
When the prepared domain String is presented to common
application logic (mostly written in languages representing
Strings NULL-terminated) the String is prematurely
terminated. As a result only the String afore the NULL byte
(www.targetToAttack.com) is being validated.
A specialization of the attack are wild-card certificates.
The asterisk (*) can be used to create certificates, valid - if
successfully signed by a trusted CA - for any domain (e.g.,
*\0.example.com).
Lesson learned: Certification authorities should be
prepared to deal with different encodings and security
issues related to this.
4) Attacking the PKI: Marlinspike described in [31] an
attack that aims at interfering the infrastructure to revoke
certificates. By the use of the Online Certificate Status
Protocol (OCSP) a client application can check the revocation status of a certificate. OCSP responds to query with
a responseStatus (cf. Figure 15).
OCSPResponse : : = SEQUENCE {
responseStatus
responseBytes ( optional )
}
O C S P R e s p o n s e S t a t u s : : = ENUMERATED {
successful
malformedRequest
internalError
tryLater
sigRequired
unauthorized
}
Figure 15: OCSP Response data type - based on

Source: [32]
The response structure contains a major design flaw:
The responseBytes field is optional, but it is the only
one containing a digital signature. This implies that the
responseStatus field is not protected by a digital signature. Not all of the OCSPResponseStatus types require
the presence of responseBytes (containing a digital
signature). Especially tryLater does not force signed

responseBytes to be present.
An attacker acting as Mitm could respond to every query
with tryLater. Due to lack for a signature the client has
no chance to detect the spoofed response. Thereby, a victim
is not able to query the revocation status of a certificate.
Lesson learned: If real-time checks on a PKI are
required, unsigned responses should lead to a halt in
protocol execution.
5) Conquest of a Certification Authority: At 15 March
2011 the Comodo CA Ltd. 8 Certification Authority (CA)
was successfully compromised [33]. An attacker used a
reseller account to issue 9 certificates for popular domains.
Except rumors, the purpose of the attack remains unclear.
Soon after attack discovery the concerned certificates have
been revoked. Due to previously discussed weaknesses affecting the revocation infrastructure (cf. IV-A4) it could be
possible that these certificates remain valid to parties with
out-of-date or missing certificate revocation lists.
It is crucial to note that the attacker did not compromise Comodos infrastructure directly (key material and servers were
not compromised at any time). Moreover, valid credentials
of a reseller were used to sign CSRs.
Lesson learned: Certification authorities have to
protect their critical infrastructure with strong security
mechanisms. Certificate issuing should not rely on weak
authentication mechanisms like username/password only.
6) Conquest of another Certification Authority: Soon
after the attack on Comodo, a Dutch Certification Authority - DigiNotar - was completely compromised by an
attacker [34]. In contrast to the Comodo impact, the attacker
was able to gain control over the DigiNotar infrastructure.
The attack discovery was eased by Googles Chrome web
browser who complained about mismatching certificates for
Google-owned domains. The browser stores hard coded
copies of the genuine certificates for Google and thus was
able to detect bogus certificates.
Lesson learned: Beside the lesson learned from IV-A5,
it can be seen that non-cryptographic security mechanisms
like malware and intrusion detection must be present in CA
systems.
7) Attacks on non-browser based certificate validation: At CCS 2012, Georgiev et al. [35] uncovered that
widespread, common used libraries for SSL/TLS suffer
from vulnerable certificate validation implementations. The
authors revealed weaknesses in the source code of OpenSSL,
GnuTLS, JSSE, ApacheHttpClient, Weberknecht, cURL,
PHP, Python and applications build upon or with these
products. The authors examined the root causes for the
8 http://www.comodo.com
bugs and were able to exploit most of the vulnerabilities.

As major causes for these problems bad and misleading
API specifications, lacking interest for security concerns
(even by banking applications!) and the absence of essential
validation routines were identified. Especially OpenSSL and
GnuTLS provide confusing APIs, leaving important tasks
influencing security to the API consumer. Even worse, the
API of cURL was attested to be almost perversely bad.
Especially, the following security tasks and robustness of
the libraries code responsible for these tasks are considered:
Certificate chaining and verification

Host name verification
Certificate revocation checks
X.509 Extension handling and processing
Exploiting these vulnerabilities may lead to successful Mitm

and impersonation attacks.
Lesson learned: The study of Georgiev et al. gives
an example on the importance of clean, simple and well
documented APIs.
V. VARIOUS ATTACKS
This section deals with various attacks not suitable for
any of the previous attack sections.
1) Random number prediction: In January 1996, Goldberg and Wagner published an article [36] on the quality of
random numbers used for SSL connections by the Netscape
Browser. The authors gained access to the applications
Source Code by decompiling it and identified striking weaknesses in the algorithm responsible for random number
generation. The entropy of the algorithm relied completely
on few, predictable values:
Current time
Current process id
Process id of the parent process
Moreover, the authors showed that due to export limitations

the entropy of key material is extremely limited - enabling
brute force attacks.
Lesson learned: The problem of weak random number
generators is not a specific problem of SSL or TLS but
reminds that a good (pseudo) random number generator
(PRNG) is crucial for cryptographic purposes (cf. V-A2).
2) Weakened security through bad random numbers:
In 2008 Luciano Bello [37] observed during code review
that the PRNG of Debian-specific OpenSSL was predictable
starting from version 0.9.8c-1, Sep 17 2006 until 0.9.8c-4,
May 13 2008, due to an implementation bug. A Debianspecific patch removed two very important lines in the
libssl source code responsible for providing adequate

entropy9 (cf. Figure 16).
MD Update(&m, buf , j ) ;
[ .. ]
MD Update(&m, buf , j ) ; / p u r i f y c o m p l a i n s /
Figure 16: Lines commented out leading to a serious bug Source: Debian optimized OpenSSL Source Code
This allowed a brute force attack, since the key space was
significantly limited without these code lines.
Lesson learned: Developers should comment
security critical parts of source code, explain exactly
the codes intention and highlight the consequences
when altered (e.g., in Java developers could decide to
introduce a Java Doc keyword SECURITY that marks
security related comments or additionally introduce a
@Security(critical=true) annotation). Beyond
this, test cases targeting the critical code lines and returning
errors if removed or altered should be provided.
3) Denial of Service enabled by Exceptions: In [38]
Zhao et al. provided an attack on the TLS handshake which
leads to an immediate connection shutdown and can thus
be used for a Denial of Service (DoS) attack. The authors
exploited two previously discussed weaknesses to mount
successful attacks.
The first attack targets the Alert protocol of TLS
and makes use of the fact that, due to yet missing
completed cryptographic primitives negotiation during
the handshake phase, all Alert messages remain
strictly unauthenticated and thus spoof-able. This enables an obvious, but effective attack: Spoofing Fatal
Alert messages which cause immediate connection
shutdowns
The second attack simply confuses a communication
partner by sending either misleading or replayed messages or responding with wrong messages according to
the expected handshake flow.
Lesson learned: Even obvious and self-evident
weaknesses (such as DoS vulnerabilities) have to be
discussed and focus of research.
4) Renegotiation flaw: Ray and Dispensa discovered
in [39] a serious flaw induced by the renegotiation feature
of TLS. The flaw enables an attacker to inject data into a
running connection without destroying the session. A server
would accept the data, believing its origin is the client. This
could lead to abuse of established sessions - e.g., an attacker
9 http://anonscm.debian.org/viewvc/pkg-openssl/openssl/trunk/rand/md
rand.c?p2=%2Fopenssl%2Ftrunk%2Frand%2Fmd rand.c&p1=openssl%
2Ftrunk%2Frand%2Fmd rand.c&r1=141&r2=140&view=diff&pathrev=
141
could impersonate a legitimate victim currently logged in to

a web application.
5) Disabling SSL/TLS at a higher layer: In February

2009, Moxie Marlinspike released the sslstrip12 tool
which disables SSL/TLS at a higher layer. As a precondition
it is necessary for an attacker to act as Mitm. To disable
the security layer the tool sends HTTP 301 - permanent redirection responses and replaces any occurrence of
https:// with http://. This causes the client to move
to the redirected page and communicate unencrypted and
unauthenticated (when the stripping succeeds and the client
does not notice that she is being fooled). Finally, the attacker
opens a fresh session to the (requested) server and passesthrough or alters any client and server data. The attack sketch
is outlined in Figure 18.
Figure 17: Example scenario for the renegotiation attack based on Source: [39]
Figure 17 shows how an attacker acting as Mitm may
abuse the renegotiation feature to inject arbitrary data into
a TLS connection. In the example scenario an attacker
concatenates 2 GET requests to send a gift to MitM Ave.
instead of Client Str.. This requires an authentication
based on cookies. The client attaches its authentication
cookie to the own request, but the attacker previously left
its own request unfinished by omitting a final CRLF and
adding a non-existent header field without value. At server
side the following happens: since the last request is not
finished yet, the following data (the original client request)
is concatenated with the pending data. The GET request of
the client becomes the value of the non-existent header field
and is therefor ignored by the server. The authentication
cookie in the next line remains valid (due to the \n after
the GET line). The result is a valid request with a valid
cookie. It is important to note, that the attacker does not
get the authentication cookie in plaintext, but her request is
constructed to be concatenated on server side in a way that
the first line of the clients request gets dropped (by using
the header trick) - the attacker is at no time able to decrypt
traffic.
Anil Kurmus proved the flaw to be practical by stealing
confidential data through a slightly different attack on Twitter10 (he used an unfinished POST request) enabled by the
renegotiation flaw11 .
There are multiple ways to fix the problem. E.g., Eric
Rescorla proposed a special TLS extension [40] that fixes
this flaw.
Lesson learned: When switching security contexts it
needs to be guaranteed that there is no pending data left.
Figure 18: Example scenario for a SSL stripping attack

Lesson learned: Usability is the keyword here: In
principle, a user should be able to detect the redirection
to http:// if it is properly visualized, e.g. by using red
colored address bars for all non-SSL/TLS connections.
6) Computational Denial of Service: In 2011, the German Hacker Group The Hackers Choice released a tool
called THC-SSL-DoS13 , which creates huge load on servers
by overwhelming the target with SSL/TLS handshake requests. Boosting system load is done by establishing new
connections or using renegotiation. Assuming that the majority of computation during a handshake is done by the
server the attack creates more system load on the server than
on the own device - leading to a DoS. The server is forced
to continuously recompute random numbers and keys.
Lesson learned: In DoS attacks, cryptography is part
of the problem, not a solution.
VI. C ONCLUSION
When summarizing the attacks and lessons learned some
guidelines for protocol designers and implementors emerge.
Since theoretical only weaknesses turned out to be adoptable in practice every outlined weakness should be taken
seriously. Unexploitability may not last forever.
From a developers point of view reliable cryptographic
primitives (e.g., good and strong random numbers) and sidechannel hardened algorithms turned out to be of importance.
10 http://www.twitter.com
11 http://www.securegoose.org/2009/11/tls-renegotiation-vulnerability-cve.
html
12 http://www.thoughtcrime.org/software/sslstrip/
13 http://www.thc.org/thc-ssl-dos/
Side-channel resistance evolved to a general, since sidechannels of any kind (information leaks, timing differences,
etc.) appear at different layers in different situations. Moreover, verbosity (e.g., error messages), normally a honorable
intention, provides attackers valuable information on internal
states and processing. Thus, as little information as possible
should be provided. Another critical aspect in matters of
honorable intersessions are own improvements on specifications for additional value (e.g., performance gains), because
they may lead to unintended vulnerabilities. Therefore, a
specification should be implemented exactly as is, without
modifications and tweaks. Marking critical parts of source
code with precise and clear comments highlighting potential risks could prevent disadvantageous modifications. This
should especially be best-practice when fixing vulnerabilities
to prevent bug reintroduction. Fixing software can be an
error prone task, since fixes have to patch not only the
current vulnerability occurrence, but all parts of the code that
may suffer from the same weakness. This often requires to
think about the interplay of different layers and applications.
As a final remark for developers, it can be concluded that
one should always be alarmed when working on security
critical components. Security is a necessity, not a necessary
evil.
Protocol designers, in turn, should be as precise as
possible when defining a specification. Specifications with
room for interpretation and implementational freedom can
lead to misunderstanding or unawareness of security related
concerns. Especially where processing order makes a huge
difference highlighting the risks of process reordering is
crucial. Risks related to divergence on the specification
need to be clarified and highlighted. Thus, the specification
of minimum requirements and mandatory preconditions is
required. This implies strong and context-free message structures with little to no room for misinterpretation. Sensitive
fields have to be authenticated and, if necessary, confidential
fields should be encrypted. The communication parties need
to authenticate what was sent and received at any time,
to obviate deliberate or non deliberate modifications during transport. Finally, adhere that flexibility mostly means
complexity which should be avoided.
DoS attacks remain a future problem that has to be focus
of research and discussion. New directions and means to
lower the surface emerged to be of increased relevance.
[2] D. Wagner and B. Schneier, Analysis of the SSL 3.0 protocol, The Second USENIX Workshop on Electronic Commerce
Proceedings, pp. 2940, 1996.
[3] M. Bellare and P. Rogaway, Entity authentication and key
distribution, 1994, pp. 232249.
[4] T. Dierks and C. Allen, The TLS Protocol Version 1.0,
RFC 2246 (Proposed Standard), Internet Engineering Task
Force, Jan. 1999. [Online]. Available: http://www.ietf.org/rfc/
rfc2246.txt
[5] D. Bleichenbacher, Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS #1, in
Advances in Cryptology CRYPTO 98, ser. Lecture Notes
in Computer Science, H. Krawczyk, Ed. Springer Berlin /
Heidelberg, 1998, vol. 1462, pp. 112.
[6] G. Davida, Chosen Signature Cryptanalysis of the RSA
(MIT)Public Key Cryptosystem, Tech. Rep., 1982.
[7] D. Brumley and D. Boneh, Remote timing attacks are
practical, in Proceedings of the 12th conference on USENIX
Security Symposium - Volume 12, ser. SSYM03. Berkeley,
CA, USA: USENIX Association, Jun. 2003, pp. 11.
[8] P. C. Kocher, Timing Attacks on Implementations of DiffieHellman, RSA, DSS, and Other Systems, in Proceedings
of the 16th Annual International Cryptology Conference on
Advances in Cryptology, ser. CRYPTO 96. London, UK,
UK: Springer-Verlag, Aug. 1996, pp. 104113.
[9] O. Aciicmez, W. Schindler, and C. Koc, Improving Brumley
and Boneh timing attack on unprotected SSL implementations, in Proceedings of the 12th ACM conference on
Computer and communications security. ACM, Nov. 2005,
pp. 139146.
[10] V. Klma, O. Pokorny, and T. Rosa, Attacking RSA-Based
Sessions in SSL/TLS, in Cryptographic Hardware and Embedded Systems - CHES 2003, ser. Lecture Notes in Computer
Science, C. Walter, C. Koc, and C. Paar, Eds. Springer Berlin
/ Heidelberg, Sep. 2003, vol. 2779, pp. 426440.
[11] B. Brumley and N. Tuveri, Remote Timing Attacks Are
Still Practical, in Computer Security - ESORICS 2011, ser.
Lecture Notes in Computer Science, V. Atluri and C. Diaz,
Eds. Springer Berlin / Heidelberg, Sep. 2011, vol. 6879, pp.
355371.
[12] P. L. Montgomery, Speeding the Pollard and elliptic curve
methods of factorization, MC, no. 48, 1987.
VII. ACKNOWLEDGMENTS
This work was partially funded by the Sec2 project of
the German Federal Ministry of Education and Research
(BMBF, FKZ: 01BY1030).
[13] J. Lopez and R. Dahab, Fast Multiplication on Elliptic

Curves Over GF(2m) without precomputation, in Cryptographic Hardware and Embedded Systems, ser. Lecture Notes
in Computer Science, C. Koc and C. Paar, Eds. Springer
Berlin / Heidelberg, 1999, vol. 1717, pp. 724724.
R EFERENCES
[1] E. Rescorla, SSL and TLS: Designing and Building Secure
Systems. Addison-Wesley, 2001.
[14] N. A. Howgrave-Graham and N. P. Smart, Lattice Attacks

on Digital Signature Schemes, Designs, Codes and Cryptography, vol. 23, pp. 283290, 2001.
[15] R. Bardou, R. Focardi, Y. Kawamoto, L. Simionato,

G. Steel, and J.-K. Tsay, Efficient Padding Oracle
Attacks on Cryptographic Hardware, INRIA, Rapport
de recherche RR-7944, Apr. 2012. [Online]. Available:
http://hal.inria.fr/hal-00691958
[16] N. Mavrogiannopoulos, F. Vercauteren, V. Velichkov, and
B. Preneel, A Cross-Protocol Attack on the TLS Protocol,
in Proceedings of the 2012 ACM conference on Computer and
communications security, ser. CCS 12. ACM, Oct. 2012,
pp. 6272.
[17] S. Vaudenay, Security Flaws Induced by CBC Padding
Applications to SSL, IPSEC, WTLS... in Advances in Cryptology EUROCRYPT 2002, ser. Lecture Notes in Computer
Science, L. Knudsen, Ed. Springer Berlin / Heidelberg, Apr.
2002, vol. 2332, pp. 534545.
[18] D. A. McGrew and J. Viega, The Galois/counter mode of
operation (GCM), 2005.
[19] J. Kelsey, Compression and information leakage of plaintext, in Fast Software Encryption, 9th International Workshop, FSE 2002, Leuven, Belgium, February 4-6, 2002, Revised Papers, ser. Lecture Notes in Computer Science, vol.
2365. Springer, Nov. 2002, pp. 263276.
[20] B. Canvel, A. Hiltgen, S. Vaudenay, and M. Vuagnoux, Password Interception in a SSL/TLS Channel, in Advances in
Cryptology - CRYPTO 2003, ser. Lecture Notes in Computer
Science, D. Boneh, Ed. Springer Berlin / Heidelberg, Aug.
2003, vol. 2729, pp. 583599.
[21] G. V. Bard, The vulnerability of ssl to chosen plaintext
attack. IACR Cryptology ePrint Archive, vol. 2004, p. 111,
May 2004.
[22] , A Challenging But Feasible Blockwise-Adaptive
Chosen-Plaintext Attack on SSL, in SECRYPT 2006, Proceedings of the International Conference on Security and
Cryptography. INSTICC Press, Aug. 2006, pp. 710.
[23] G. Danezis, Traffic Analysis of the HTTP Protocol over
TLS, unpublished manuscript.
[24] S. Chen, R. Wang, X. Wang, and K. Zhang, Side-Channel
Leaks in Web Applications: A Reality Today, a Challenge
Tomorrow, in Proceedings of the 2010 IEEE Symposium on
Security and Privacy, ser. SP 10. IEEE Computer Society,
May 2010, pp. 191206.
[25] J. Rizzo and T. Duong, Here Come The XOR Ninjas, May
2011.
[26] K. G. Paterson, T. Ristenpart, and T. Shrimpton, Tag size
does matter: attacks and proofs for the TLS record protocol, in Proceedings of the 17th international conference on
The Theory and Application of Cryptology and Information
Security, ser. ASIACRYPT11. Berlin, Heidelberg: SpringerVerlag, Dec. 2011, pp. 372389.
[27] N. AlFardan and K. Paterson, Plaintext-Recovery Attacks
Against Datagram TLS, in Network and Distributed System
Security Symposium (NDSS 2012), Feb. 2012.
[28] A. Lenstra, X. Wang, and B. de Weger, Colliding X.509

Certificates, Cryptology ePrint Archive, Report 2005/067,
Mar. 2005.
[29] M. Rosenfeld, Internet Explorer SSL Vulnerability,
May 2008. [Online]. Available: http://www.thoughtcrime.
org/ie-ssl-chain.txt
[30] , Null Prefix Attacks Against SSL/TLS Certificates,
Feb. 2009. [Online]. Available: http://www.thoughtcrime.org/
papers/null-prefix-attacks.pdf
[31] , Defeating OCSP With The Character 3, Jul.
2009. [Online]. Available: http://www.thoughtcrime.org/
papers/ocsp-attack.pdf
[32] M. Myers, R. Ankney, A. Malpani, S. Galperin, and
C. Adams, X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP, RFC 2560 (Proposed
Standard), Internet Engineering Task Force, Jun. 1999.
[Online]. Available: http://www.ietf.org/rfc/rfc2560.txt
[33] Comodo CA Ltd., Comodo Report of Incident - Comodo
detected and thwarted an intrusion on 26-MAR-2011, Tech.
Rep., Mar. 2011.
[34] Fox-IT, Black Tulip - Report of the investigation into the
DigiNotar Certificate Authority breach, Tech. Rep., Aug.
2012.
[35] M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh,
and V. Shmatikov, The Most Dangerous Code in the World:
Validating SSL Certificates in Non-Browser Software, in
ACM Conference on Computer and Communications Security,
2012.
[36] Goldberg and Wagner, Randomness and the Netscape
browser, Dr. Dobbs Journal, Jan. 1996.
[37] F. Weimer, DSA-1571-1 openssl predictable
random number generator, Network Working Group,
May 2008. [Online]. Available: http://lists.debian.org/
debian-security-announce/2008/msg00152.html
[38] Y. Zhao, S. Vemuri, J. Chen, Y. Chen, H. Zhou, and Z. Fu,
Exception triggered DoS attacks on wireless networks, in
Proceedings of the 2009 IEEE/IFIP International Conference
on Dependable Systems and Networks, DSN 2009, Jun. 2009,
pp. 1322.
[39] M. Ray and S. Dispensa, Renegotiating TLS, PhoneFactor,
Inc., Tech. Rep., Nov. 2009.
[40] E. Rescorla, M. Ray, S. Dispensa, and N. Oskov,
Transport Layer Security (TLS) Renegotiation Indication
Extension, RFC 2246 (Proposed Standard), Network
Working Group, Nov. 2009. [Online]. Available: http:
//tools.ietf.org/id/draft-rescorla-tls-renegotiation-01.txt

Sec Flux Informational PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Sec Flux Informational PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Capitolul 1

CU CHEI PUBLICE (P KI)

Sa nteleaga durata unui certificat si cum gestioneaza un P KI acest certificat pe

Formatul de certificat X.509

1.3. VARIANTE DE CERTIFICARE

Pentru o astfel de certificare, autoritatea CA genereaza proprii sai parametri RSA:

CU CHEI PUBLICE (P KI)

CA = (IDA , P ubA , (IDA kP ubA )P rivca (mod Nca ))

La primirea certificatului, Alice l verifica calculand

Certificare Cylink (SEEK)

Protocolul de certificare a fost prezentat n 1987 ([2]).

2. Genereaza aleator RA si calculeaza CcaA = aRA (mod p)

3. Daca SA = aMA , atunci certificatul CA este valid.

1.3. VARIANTE DE CERTIFICARE

Cand Alice doreste sa stabileasca o sesiune de comunicare cu Bob, i trimite quadruplul

Certificare CyLink bazat

Intr-o astfel de certificare, valorile a si p sunt comune tututor utilizatorilor si autoritatii

Recapituland: daca Alice si Bob doresc sa stabileasca un contact bazat pe un certificat

CU CHEI PUBLICE (P KI)

Amandoi schimba simultan ntre ei urmatoarele informatii:

Diferenta fata de varianta anterioara consta n modul de calcul al semnaturii S si n tipul

1.4. MANAGEMENTUL UNUI P KI

Alice : P rivA , P ubA , IDA , ScaA , VcaA , P ubca , h

g ScaX = g RcaX HX g VcaX P rivca = g RcaX

= (VcaX )HX (P ubca )VcaX .

In general, o infrastructura cu chei publice asigura urmatoarele servicii:

CU CHEI PUBLICE (P KI)

2. Autoritatea de certificare CA: entitatea nominalizata n campul Issuer name a

Un utilizator P KI (End-Entity) este un beneficiar al unui certificat P KI. El poate fi o

1. Alice se nregistreaza la autoritatea de certificare CA si aplica pentru obtinerea unui

1.4. MANAGEMENTUL UNUI P KI

5. Dupa primirea mesajului, Bob acceseaza RS si verifica autenticitatea certificatului

Contactele dintre utilizator si unitatea de certificare

Contactele dintre un utilizator si CA sunt legate exclusiv de operatia de certificare. Ele

CU CHEI PUBLICE (P KI)

(T T P ). Daca cheia generata este folosita la o actiune de non-repudiere, atunci ea

1.4. MANAGEMENTUL UNUI P KI

Cererea de revocare a unui certificat

Contacte ntre unitatea de certificare si cea de nregistrare

RA poate avea diferite functii; doua sunt nsa obligatorii:

Contacte ntre utilizator si RS

Intre cele doua entitati au loc doua tipuri de contacte:

CU CHEI PUBLICE (P KI)

Validarea certificatului: Dupa ce Alice a gasit certificatul lui Bob, ea trebuie sa

Contacte ntre dou

Formatul unei liste de revocare

1.6. MODELE DE INCREDERE

Autortatile de certificare actioneaza ca agenti de ncredere pentru validarea identitatii si

CU CHEI PUBLICE (P KI)

Model de ncredere ierarhic

Model de ncredere mesh

Este un model de ncredere bazat pe structura ierarhica, care faciliteaza certificarile

1.7. ALGORITMI DE CRIPTARE ACCEPTAT

Model de ncredere Web

Model de ncredere centrat pe utilizator

Protocolul de posta electronica P GP foloseste un model de ncredere centrat pe utilizator

Algoritmi de criptare acceptati n P KI

Standardul RF C 4210 stabileste algoritmii criptografici, functiile de dispersie si semnaturile

CU CHEI PUBLICE (P KI)

Amprenta este apoi formatata corespunzator algoritmului de semnatura care va fi

Cerinte ale serviciilor terte de ncredere

CAPITOLUL 2. SERVICII TERT

sa fie independent si impartial pe timpul functionarii;