sec_flux_informational.pdf

8/16/2019 sec_flux_informational.pdf

1/274

Capitolul 1

Infrastructură cu chei publice (P KI )

1.1 Prezentare generală

Într-un sistem de criptare cu cheie publică, cheia de criptare nu este secretă; deci estenecesară o autentificare a sa, pentru a-i garanta integritatea şi a elimina o serie de atacuri,cum ar fi man-in-the-middle .

Cheia publică a unui utilizator trebuie autentificată (semnată) de o autoritate decertificare (CA). Rolul acesteia este de a garanta autenticitatea şi integritatea unei cheipublice (unică) pentru fiecare utilizator. După certificare, utilizatorul poate trimite cheia

sa publică oricărui 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.

Definiţia 1.1. Un bloc de identificare este o structur˘ a asociat˘ a unui utilizator.Ea poate cont ̧ine num˘ arul serial al PC-ului, num˘ arul de telefon, num˘ arului ret ̧elei, num˘ arul de certificare, data de expirare a certificatului, diverse autorizat ̧ii.

Certificatul este creat prin legarea cheii publice cu blocul de identificare. Atunci cânddoi utilizatori stabilesc ı̂ntre ei o comunicare, ei ı̂şi trimit unul altuia certificatele, şi fiecare

validează identitatea partenerului.Ca mod de implementare. componentele cheii publice şi blocul de identificare al unui

utilizator pot fi scrise pe un smartcard. Cu ajutorul acestuia, componentele pot fi trans-portate fizic (electronic) la o autoritate de certificare. Aceasta generează un certificat careva fi ı̂ncărcat de asemenea pe smartcard.Ulterior toate aceste componente sunt ı̂ncărcate pe calculator.

Obiectivele pe care trebuie să le ı̂ndeplinească un sistem atunci când apelează la CAsunt ı̂n mare:

• Să fie capabil să estimeze scopul şi valoarea certificatelor şi a procesului de certificare;

1


2/274

2 CAPITOLUL 1. INFRASTRUCTUR ̆ A CU CHEI PUBLICE ( P KI )

• Să ı̂nţeleagă durata unui certificat şi cum gestionează un P KI acest certificat pedurata valabilităţii lui;

• Să fie capabil să aleagă un serviciu de ı̂ncredere adecvat pentru eliberarea certifica-tului.

1.2 Formatul de certificat X.509

X.509 este cel răspândit format de certificat utilizat pentru o structură P KI . Poate fiı̂ntâlnit ı̂n protocoale SSL, IP sec, S/MIM E, SET, P GP .Standardul RF C 4325 listează următoarele zone cuprinse ı̂ntr-un certificat X.509 (Santes-son & Housley, 2005):

• Version: Versiunea certificatului.

• Certificate serial number (maxim 20 octeţi): ı̂ntreg pozitiv (unic) asignat de C Afiecărui certificat.

• Signature algorithm identifier: Identificatorul algoritmului folosit de CA pentrusemnătura digitală a certificatului. Algoritmul folosit este RSA sau DSA.

• CA issuer name: Identifică autoritatea de certificare care a semnat şi a eliberat

certificatul.

• Validity period: Intervalul de timp ı̂n care CA asigură validitatea certificatului.Câmpul respectiv este o sevenţă de două date: data ı̂nceperii perioadei de validitateşi data expirării validităţii certificatului.

• Subject name: Identifică entitatea a cărei cheie publică este autentificată.

• Subject public-key information: Prezintă cheia publică ı̂mpreună cu parametriipublici asociaţi. Dacă este necesar, este depus şi identificatorul sistemului de criptareutilizat (de exemplu: RSA,DSA,Diffie − Hellman).

• Issuer unique ID: Zonă opţională alocată numelor CA apărute ı̂n “CA Issuer name ” (pentru o eventuală reutilizare).

• Subject unique ID: Zonă opţională care permite utilizarea ulterioară a numelordin “Subject name ”.

• Extensions: Acest câmp apare numai dacă versiunea certificatelor este 3.Extensiile pentru certificatele X.509 v3 oferă metode de asociere de atribute supli-mentare referitoare la utilizatori şi chei publice pentru gestionarea unei ierarhii decertificare, cum ar fi CA Key Identifier şi Subject Key Identifier .


3/274

1.3. VARIANTE DE CERTIFICARE 3

Informaţia scrisă pe aceste câmpuri este semnată folosind cheia secretă a lui CA. Acestedouă elemente (semnătura şi conţinutul zonelor) sunt apoi

1. concatenate;

2. scrise cu ajutorul unui sistem de notaţie sintactică numit Abstract Syntax One 1;

3. transformate ı̂n date binare folosind sistemul de codificare DER (Distinguish En-coding Rules );

4. convertite ı̂n caractere ASCII folosind codificarea base64.

Observaţia 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 internat ̧ional rezultat din codificarea BER (Basic Encoding Rules). De fapt, DER difer˘ a de BERdoar prin faptul c˘ a ignor˘ a opt i̧unile expeditorului (care ı̂n cazul unor certificate nu sunt necesare).

Scopul principal este oferirea unei codific˘ ari unice, asigurˆ and astfel C A c˘ a structura de date pe care o semneaz˘ a va produce o reprezentare serial˘ a unic˘ a. Multe lucr˘ ari consider˘ a DER ca o form˘ a canonic˘ a pentru BER (numit˘ a de aceea şi 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 logic˘ a Adev˘ ar.Pentru detalii privind ASN.1 şi DER se poate folosi [5].

1.3 Variante de certificare

1.3.1 Certificare RSA

Pentru o astfel de certificare, autoritatea CA generează proprii săi parametri RSA: pca, q ca, Privca (exponentul de criptare) şi P ubca (exponentul de decriptare).

CA face publice valorile P ubca şi N ca (unde N ca = pca · q ca) pentru toţi utilizatorii din

reţea.Dacă notăm l(α) lungimea secvenţei binare α, va trebui ca pentru orice utilizator X

din reţea,l(N ca) > l(IDX ) + l(P ubX )

CA autentifică cheia publică P ubA şi identificatorul IDA ale lui Alice, generând certifi-catul public

1Abstract Syntax Notation One (ASN.1) este un standard şi o notaţie definită prin reguli formale,utilizată ı̂n reţelele de calculatoare şi ı̂n telecomunicaţii. Descrie structuri de date utilizate pentrureprezentarea, codificarea, transmiterea şi – ı̂n final – decodificarea datelor.


4/274


C A = (IDA, Pu bA, (IDAP ubA)Privca (mod N ca)) (1)

La primirea certificatului, Alice ı̂l verifică calculând

IDAP ubA = (IDAP ubA)P ubca (mod N ca) (2)

Când Alice doreşte să stabilească o comunicare securizată cu alt utilizator din reţea,ea ı̂i va trimite acestuia certificatul C A; destinatarul B ob – având acces la P ubca şi N ca –va determina I DAP ubA calculând (2), după care va compara rezultatul cu primele douăvalori concatenate din C A.

Această variantă asigură autenticitatea şi integritatea cheii publice. Dacă vrem săavem şi confidenţialitate, se renunţă la primele două componente ale certificatului. În

acest caz ı̂nsă trebuie să existe o modalitate clară care să separe IDA de P ubA din secvenţabinară concatenată.

1.3.2 Certificare Cylink (SEEK)

Protocolul de certificare a fost prezentat ı̂n 1987 ([2]).Fie a un număr aleator şi p un număr prim tare ( p = 2q + 1 cu q prim).

Autoritatea de certificare C A generează propriile sale chei P ubca,Privca, ı̂n conformi-tate cu protocolul Diffie - Hellman:

P ubca = a

Privca

(mod p)

CA autentifică cheia publică şi ID lui Alice calculând certificatul după algoritmul:

1. Calculează M A = P ubIDAA (mod p)

2. Generează aleator RA şi calculează C caA = aRA (mod p)

3. Calculează V A din ecuaţia M A = [Privca · C caA + RA · V A] (mod ( p − 1))

4. Trimite lui Alice certificatul C A = (C caA, V A).

Alice verifică faptul că certificatul a fost eliberat de autoritatea CA folosind algoritmul:

1. Calculează M A = P ubIDAA (mod p)

2. Calculează S A =

P ubC caAca (mod p) ·

C V AcaA (mod p)

(mod p)

3. Dacă S A = aM A, atunci certificatul C A este valid.


5/274

1.3. VARIANTE DE CERTIFICARE 5

Când Alice doreşte să stabilească o sesiune de comunicare cu Bob, ı̂i trimite quadruplul

(C caA, PubA, V A, M A)

Cum ambele părţi dispun de a, p şi P ubca, Bob poate autentifica certificatul lui Alicecalculând

S B =

P ubC caAca mod p ·

C V AcaA mod p

(mod p)

şi verificând congruenţa aM A ≡ S B (mod p).De remarcat că prin acest protocol, B ob nu poate deduce identificatorul lui Alice.

1.3.3 Certificare CyLink bazată pe algoritmul ElGamalÎntr-o astfel de certificare, valorile a şi p sunt comune tututor utilizatorilor şi autorităţiide certificare. a este un număr generat aleator, iar p este un număr prim tare.

CA generează perechea de chei (P ubca,Privca) care verifică relaţia

P ubca = aPrivca (mod p)

La solicitarea lui Alice de a obţine un certificat pentru mesajul M A, unitatea de certificare:

1. Generează aleator un număr secret RcaA

2. Calculează valoarea publică V caA = aRcaA (mod p);

3. Aplică o funcţie de dispersie criptografică: H caA = h(M A, V caA);

4. Calculează semnătura sa digitală

S caA = (RcaA + H caA · Privca) (mod p)

5. Trimite lui Alice tripletul (S caA, H caA, V caA).

La primire, Alice verifică certificatul pe baza relaţiei

aS caA ≡ V caA · P ubH caAA (mod p)

Recapitulând: dacă Alice şi Bob doresc să stabilească un contact bazat pe un certificateliberat de C A:

• Informaţiile deţinute de

Alice : PrivA, Pu bA, M A, S caA, V caA, Pu bca, hBob : PrivB, Pu bB, M B, S caB, V caB, Pu bca, h


6/274


• Amândoi schimbă simultan ı̂ntre ei următoarele informaţii:

Alice −→ Bob : P ubA, M A, S caA, V caABob −→ Alice : P ubB, M B, S caB, V caB

• Fiecare stabileşte autenticitatea certificatului celuilalt calculând şi verificând:

Alice : H caB = h(M B, V caB), aS caB ≡ V caB · P ub

H caBB (mod p)

Bob : H caA = h(M A, V caA), aS caA ≡ V caA · P ub

H caAA (mod p)

Dacă congruenţele sunt verificate de ambele părţi, atunci Alice şi Bob ştiu că certificatelesunt eliberate de autoritatea de certificare CA, iar partenerii sunt autentificaţi.

1.3.4 Variantă a protocolului de certificare ElGamal

Diferenţa faţa de varianta anterioară constă ı̂n modul de calcul al semnăturii S şi ı̂n tipulde verificare al semnăturii.

Fie p un număr prim cu proprietatea că p − 1 are cel puţin un factor prim mare; fie gun generator al lui Z p.

Autoritatea de certificare C A generează perechea de chei (P ubca,Privca) care verificărelaţia

P ubca = gPrivca (mod p)

Pentru a instala certificatul generat de C A pentru computerul lui Alice, se genereazăı̂ntâi un identificator IDA (acesta poate consta din IP calculatorului, CNP lui Alice,numărul ei de telefon etc).La solicitarea lui Alice de a obţine un certificat, unitatea de certificare:

1. Generează aleator un număr secret RcaA;

2. Calculează valoarea publică V caA = gRcaA (mod p);

3. Aplică o funcţie de dispersie criptografică: H caA = h(IDA, Pu bA, V caA);

4. Calculează semnătura sa digitală

S caA = (RcaA · H caA + V caA · Privca) (mod ( p − 1))

5. Trimite lui Alice perechea (S caA, V caA).

Deci, dacă Alice şi Bob doresc să stabilească un contact bazat pe un certificat eliberatde CA:

• Informaţiile deţinute de


7/274

1.4. MANAGEMENTUL UNUI P KI 7

Alice : PrivA, Pu bA, IDA, S caA, V caA, Pu bca, h

Bob : PrivB, Pu bB, IDB, S caB, V caB, Pu bca, h

• Amândoi schimbă simultan ı̂ntre ei următoarele informaţii:

Alice −→ Bob : IDA, Pu bA, S caA, V caABob −→ Alice : IDB, Pu bB, S caB, V caB

• Fiecare stabileşte autenticitatea certificatului celuilalt calculând şi verificând:

Alice : H caB = h(IDB, Pu bB, V caB), gS caB ≡ (V caB)

H caB · (P ubca)V caB (mod p)

Bob : H caA = h(IDA, Pu bA, V caA), gS caA ≡ (V caA)

H caA · (P ubca)H caA (mod p)

Dacă congruenţele sunt verificate de ambele părţi, atunci Alice şi Bob ştiu că certificatele

sunt eliberate de autoritatea de certificare CA, iar partenerii sunt autentificaţi.

Observaţia 1.2. Consistent ̧a congruent ̧ei de verificare este bazat˘ a pe secvent ̧a de calcule (efectuate modulo p) pentru un utilizator X :

gS caX = g(RcaX·H X+V caX·Privca) (mod ( p−1)) (mod p)Deoarece gx mod ( p−1) ≡ gx (mod p), vom avea ı̂n continuare:

gS caX = gRcaX·H X · gV caX·Privca =

gRcaXH X

·

gPrivcaV caX

= (V caX )H X · (P ubca)

V caX .

Această variantă de certificare este mai robustă decât versiunea anterioară, deoarece:

• Factorul V caX este inclus atât la bază cât şi ca exponent;

• Cheia publică a autorităţii apare explicit ı̂n procedura de verificare.

1.4 Managementul unui P KI

În general, o infrastructură cu chei publice asigură următoarele servicii:

• Urmăreşte perioada de valabilitate a cheii şi certifică acest lucru;

• Pentru o cheie certificată, asigură servicii de back-up şi recovery ;

• Up-datează automat perechile de chei şi certificatele lor;

• Gestionează un istoric al cheilor certificate;

• Este capabilă să efectueze certificări ı̂ncrucişate.

Conform standardului RF C 4210, sunt 4 entităţi implicate ı̂n managementul unuiP KI :

1. Utilizatorul P KI , numit şi end-entity sau end-user : entitatea nominalizată ı̂n câmpul“Subject name” a unui certificat;


8/274


2. Autoritatea de certificare CA: entitatea nominalizată ı̂n câmpul “Issuer name” aunui certificat;

3. O autoritate de ı̂nregistrare RA (componentă opţională 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 opersoană, un computer, o aplicaţie (de exemplu pentru securitatea IP ).

Utilizatorul are nevoie de un acces local sigur la anumită informaţie (cel puţin la

propriul nume, la cheia sa privată, la numele unui CA ı̂n care are ı̂ncredere, precum şi lacheia publică a acestui CA).

Conform cu RF C 3647, un utilizator P KI are următoarele obligaţii:

• Să asigure o reprezentare corectă a datelor sale ı̂n cadrul certificatului;

• Să asigure protecţie cheii sale private;

• Să introducă restricţii de acces la cheia sa privată şi la utilizarea certificatului;

• Să notifice orice compromitere a cheii sale private.

Procesul de ı̂nregistrare şi autentificare are loc după schema următoare:

Alice Bob

CA/RA RS

Mesaj criptat

Semnătură digitală

1 2

3

4

5 6

7

1. Alice se ı̂nregistrează la autoritatea de certificare CA şi aplică pentru obţinerea unuicertificat;

2. CA verifică identitatea lui Alice şi eliberează un certificat;

3. CA publică certificatul pe un site dedicat RS (Repository Site );

4. Alice trimite lui Bob mesajul său criptat ı̂mpreună cu certificatul. Mesajul estesemnat cu cheia privată a lui Alice (se asigură astfel autenticitatea şi integritateamesajului, precum şi non-repudierea);


9/274


5. După primirea mesajului, Bob accesează RS şi verifică autenticitatea certificatuluilui 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

Într-un sistem cu cheie publică, secretul acestei chei nu este obligatoriu; este ı̂nsă necesarăo autentificare a cheii publice, pentru a garanta integritatea şi autenticitatea ei.

Identitatea şi cheia publică a unui utilizator P KI este autentificată (semnată) de oautoritate de certificare.

Termenul C A se referă la entitatea scrisă ı̂n zona “Issuer name ” a unui certificat. UnCA 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 trecândprin diverse domenii de securitate).

Un domeniu de securitate este un domeniu logic ı̂n care un CA emite şi gestioneazăcertificate.

În general, un utilizator P KI este certificat de un CA, iar un CA este certificat dealt CA. Se construieşte astfel o reţea arborescentă de certificare, care are ca rădăcină unroot - CA.

Nu este obligatoriu ca o unitate de certificare să fie ”a treia parte”; frecvent, CAaparţine aceleiaşi organizaţii ca şi utilizatorul pe care ı̂l certifică.

1.4.3 Contactele dintre utilizator şi unitatea de certificare

Contactele dintre un utilizator şi CA sunt legate exclusiv de operaţia de certificare. Eleapar ı̂n două situaţii: când este solicitat un certificat (iniţializare) şi la eliberarea unuicertificat.

Iniţializarea

Alice solicită un certificat de la CA sau RA. Rezultatul acţiunii este eliberarea unuicertificat pentru o cheie publică a lui Alice, care este trmis lui Alice şi/sau publicat peun repository site.Componentele unei faze de iniţializare sunt:

1. Înregistrare: CA (sau RA) stabileşte şi verifică identitatea lui Alice ca solicitatorde certificat.

2. Generarea cheilor: Este generată perechea (cheie public˘ a, cheie privat˘ a). Gener-area poate fi efectuată de Alice, CA, RA sau chiar o a treia parte de ı̂ncredere


10/274


(T T P ). Dacă cheia generată este folosită la o acţiune de non-repudiere, atunci eaeste generată obligatoriu de Alice.

3. Crearea certificatului: CA generează un certificat asociat cheii construite ante-rior. Numai C A poate construi un astfel de certificat.

4. Distribuţia certificatului şi cheii publice: CA trimite lui Alice certificatul şiperechea de chei (dacă acestea nu au fost generate de Alice).

5. Diseminarea certificatului: CA trimite certificatul lui Alice şi la un RS .

6. Păstrarea cheii: Opţional, CA poate trimite cheia (pentru backup) unui T T P .

Recuperarea şi 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 şi unitatea decertificare.

O cheie publică este folosită:

• pentru criptare (chei de criptare );

• pentru semnare de mesaje şi verificarea de certificate (chei de semn˘ atur˘ a ).

Procesul de recuperare a cheii este utilizat numai pentru cheile de criptare; aici, organis-mul abilitat va recalcula cheia privată.Acest proces nu poate fi similar pentru cheile de semnătură, deoarece va ı̂ncălca propri-etatea 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– când aceasta este ı̂nlocuită cu o nouă pereche de chei, ı̂nsoţită de un nou certificat.

Rêınnoirea şi actualizarea unui certificat

Un certificat este eliberat pentru o perioadă strict determinată de timp. După expirare,el trebuie rêınnoit sau actualizat.Reı̂nnoire ı̂nseamnă eliberarea unui nou certificat, pentru aceeaşi cheie şi aceleaşi datede identificare ale utilizatorului.Actualizare ı̂nseamnă eliberarea unui certificat pentru o nouă pereche de chei şi/sau omodificare de date de identificare ale lui Alice.


11/274


Cererea de revocare a unui certificat

Este un proces de invalidare a unui certificat ı̂nainte de expirarea sa. Această acţiune esteiniţiată de o persoană autorizată, care atenţionează CA asupra unei situaţii anormale,care impune revocarea certificatului.

Deoarece prezenţa unui certificat nu menţionează dacă acesta este revocat sau nu,apare necesitatea de a păstra ı̂ntr-o zonă – sigură, dar accesibilă oricui – o listă cu toatecertificatele revocate.

Contacte ı̂ntre unitatea de certificare şi RS (repository site)

Sunt două tipuri de contacte: cel legat de diseminarea certificatelor şi cel referitor lalista de revocare . Odată cu eliberarea sau revocarea unui certificat, CA este obligată sătrans,ită această informaţie spre RS , pentru publicarea sa.

La crearea unui certificat, RS ı̂l publică conform unui protocol special LDAP (LightWeight Directory Access Protocol) menţionat ı̂n standardul RF C 4510 − 19.

Cererea de revocare a unui certificat poate apare c ând cheia privată a lui Alice estecompromisă sau când Alice nu mai face parte din domeniul de securitate al CA (deexemplu când ea părăseşte organizaţia). Revocarea este inclusă de CA ı̂n CRL (CertificateRevocation List) şi diseminată cu ajutorul RS .

1.4.4 Contacte ı̂ntre unitatea de certificare şi cea de ı̂nregistrare

RA poate avea diferite funcţii; două sunt ı̂nsă obligatorii:

• În prima fază RA este un tampon ı̂ntre utilizator şi unitatea de certificare.Astfel, Alice trimite spre RA cererea de ı̂nregistrare. RA verifică datele de identi-ficare ale lui Alice, după care – dacă acestea sunt corecte – trimite această cererespre C A. CA răspunde cu rezultatele ı̂nregistrării, rezultate pe care RA le retrimitespre Alice. Pe baza acestor rezultate, Alice trimite ulterior spre CA o cerere decertificare.

• RA publică certificatele eliberate de CA (informaţie primită de la CA).

1.4.5 Contacte ı̂ntre utilizator şi RS

Între cele două entităţi au loc două tipuri de contacte:

• Găsirea certificatului: Alice contactează RA pentru aflarea certificatului lui Bob,care ı̂i este necesar pentru:

– Găsirea cheii publice a lui Bob – pentru a cripta un mesaj adresat acestuia.

– Verificarea unei semnături digitale primite de la Bob.


12/274


• Validarea certificatului: După ce Alice a găsit certificatul lui Bob, ea trebuie săı̂l valideze. Validarea unui certificat include următoarele verificări:

– 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 două autorităţi de certificare

Este posibil ca cei doi utilizaotri care doresc să intre ı̂n contact să aibă certificatele elibe-rate de autorităţi distincte. Astfel, Alice are certificatul eliberat de CA1, iar certificatullui Bob este eliberat de CA2. Fiecare din ei are ı̂ncredere numai ı̂n autoritatea care i-aeliberat certificatul. În plus, chiar dacă unul din ei doreşte să ı̂l certifice pe celălalt, acestlucru nu ar fi posibil deoarece domeniile de certificare sunt diferite.

Mecanismul folosit pentru a rezolva acest impediment este numit certificare ı̂ncruci-şat ̆a : CA1 ı̂l certifică pe C A2, extinzând ı̂ncrederea lui Alice şi asupra certificatelor emisede CA2 (ı̂n particular, al lui Bob).

Procesul poate fi rafinat, ı̂n sensul că domeniul lui CA1 se poate extinde asupra tuturorcertificatelor emise de C A2 sau doar pentru anumite certificate (care aparţin unei singureorganizaţii, 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 Revo-cation List (CRL) Profile”) descrie detaliat formatul şi semantica unei liste de revocarepentru P KI .

În formatul X.509, un CA emite periodic o structură semnată numită CRL (CertificateRevocation List). În esenţă, un CRL este o listă cu ştampilă de timp, emisă şi semnatăde un CA şi făcută publică printr-un site RS .Fiecare certificat revocat este identificat prin numărul său serial. Când se verifică uncertificat, ı̂nafară de semnătura şi perioada sa de valabilitate, se accesează şi CRL-ulcurent, verificând dacă aici este menţionat numărul serial al certificatului.

De menţionat că numai CA-ul care emite un certificat poate să ı̂l revoce. Din acestmotiv, datele cu care lucrează o unitate de certificare (algoritmul de semnătură, cheileetc) trebuie securizate prin protocoale suplimentare (deoarece compromiterea unui CAconduce 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̆ esterezervată locaţie numai dacă se lucrează cu versiunea 2.


13/274

1.6. MODELE DE ÎNCREDERE 13

• Semnătură: conţine ID-ul algoritmului folosit de CA pentru a semna CRL-ul.

• Nume emitent: Identifică CA-ul care emite şi semnează CRL-ul.

• Actualizare: Indică data emiterii. Informaţia se poate codifica ı̂n două moduri:UTCTime2 sau Timp generalizat 3.

• Următoarea actualizare: Indică data emiterii următorului CRL. Acesta poateapare ı̂nainte de data indicată, dar ı̂n nici un caz nu va apare ulterior datei.

• Certificatele revocate: Listează numerele seriale ale certificatelor revocate ı̂nintervalul dintre apariţia CRL-ului anterior şi cel actual. Pentru fiecare certificat

trebuie menţionată şi data revocării.Dacă nu există certificate revocate, această locaţie trebuie să lipsească.

În faza următoare, locaţiile care conţin aceste componente ale C RL-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 codificării base64.

1.6 Modele de ı̂ncredere

Autortăţile de certificare acţionează ca agenţi de ı̂ncredere pentru validarea identităţii şia 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 CAcât timp el are ı̂ncredere ı̂n C A-ul respectiv.Altfel spus, ”Alice are ı̂ncredere ı̂n Bob” ı̂nseamnă de fapt ”Alice are ı̂ncredere ı̂n CA-ul care semneaz˘ a certificatul lui Bob”.

Aici apar diverse dificultăţi, cum ar fi:• Alice şi Bob vor să intre ı̂n legătură, dar certificatele lor sunt emise de AC -uri cu

domenii de securitate distincte.

• Pentru a-şi legitima ı̂ncrederea, un CA trebuie să fie certificat la rândul său de altCA.

2Coordinated Universal Time : un compromis ı̂ntre timpul dat de meridianul 0 (numit Timp Universal)şi timpul fizic determinat cu cea mai mare precizie (Timpul Atomic Internaţional - TAI ); a se vedeahttp://ro.wikipedia.org/wiki/Ora universal˘ a coordonat˘ a .

3Reprezentare sub forma standard Y Y Y YMMDDHHMMSS .


14/274


Din aceste motive, apar diverse structuri formate din mai multe autorităţi de certificare;aceste structuri se numesc ”modele de ı̂ncredere ”. În prezent sunt utilizate mai multetipuri de modele de ı̂ncredere: ierarhice, mesh, Web, şi centrate pe utilizator.

1.6.1 Model de ı̂ncredere ierarhic

Într-un astfel de model există o autoritate de certificare (Root CA) considerată apriorisigură; celelalte CA-uri sunt organizate ı̂ntr-o structură arborescentă ale cărei noduriterminale sunt utilizatorii (entităţi care nu sunt abilitate să emită certificate).

Toate entităţile au ı̂ncredere ı̂n root CA. Înafară de el, fiecare entitate dispune de (cel

puţin) un certificat eliberat de un CA situat pe drumul (unic) de la el spre root CA.Avantajul acestui model este simplitatea sa şi uşurinţa de implementare. Dezavantajul

este acela că nu permite certificări ı̂ncruci̧sate ı̂ntre CA-uri diferite.

Un exemplu de model ierarhic este:

Utilizator A Utilizator B Utilizator C Utilizator D Utilizator E

CA2

Nivel 2

CA3

Nivel 2 Utilizator F

CA1

Nivel 1

CA4

Nivel 1

CA

Root

Certificatul lui A este emis de CA2, iar al lui F este emis de CA4. Dacă cei doi vorsă stabilească o legătură, iar A (de exemplu) nu are ı̂ncredere ı̂n CA4, el va trebui săgăsească alt C A ı̂n care să aibă ı̂ncredere. Singurul care poate fi folosit aici este Root CA.

Dacă contactul trebuie făcut ı̂ntre utilizatorii A şi 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̆ certificărileı̂ncrucişate.

Dacă sunt mai multe structuri ierarhice, toate autorităţile de certificare aflate pepoziţia de rădăcină se autorizează reciproc prin certificare ı̂ncrucişată. Această inter-autorizare are loc ı̂nainte de ı̂nceperea emiterii de certificate către alte entităţi.


15/274

1.7. ALGORITMI DE CRIPTARE ACCEPTAŢI ÎN P KI 15

1.6.3 Model de ı̂ncredere Web

Pentru un număr mare de utilizatori, modelul de ı̂ncredere cel mai utilizat este cel de tiplistă, numit şi Web model .

Fiecare browser Internet acţionează ca un Root CA virtual, deoarece utilizatorii auı̂ncredere ı̂n C A-ul instalat ı̂n softul browserului. Browserele sunt distribuite ı̂mpreună cuun set iniţial de certificate; la acestea utilizatorii pot adăuga certificate noi sau pot eliminacertificate. Browserele pot utiliza certificatele pre-instalate pentru a semna, verifica, criptasau decripta mesajele de e-mail scrise ı̂n S/MIME şi de a stabili sesiuni T LS sau SS L.De asemenea, ele sunt abilitate să verifice semnăturile ı̂n cazul codurilor semnate.

Pentru un utilizator obişnuit, gestionarea numeroaselor certificate instalate ı̂n browser-

constituie o problemă extrem de dificilă4

; mai mult, nu există nici o modalitate practicăde a preveni o modificare neautorizată (din partea utilizatorilor sau celor care au acces lastaţiile de lucru) a listei de certificate.

În acest tip de model de ı̂ncredere nu există o modalitate practică de a revoca cer-tificate. Astfel, dacă Firefox sau Microsoft (cei doi lideri actuali pe piaţa browserelorInternet) instalează din greşeală un C A care nu este de ı̂ncredere, nu există nici o modal-itate de a-i revoca certificatul din milioanele browsere aflate ı̂n uz.

1.6.4 Model de ı̂ncredere centrat pe utilizator

Protocolul de poştă electronică P GP foloseşte un model de ı̂ncredere centrat pe utilizator(User Centric Model). Orice utilizator P GP poate acţiona ca o autoritate de certificareşi să valideze certificatul cheii publice a altui utilizator P GP .

Totuşi, un certificat eliberat de Alice – care acţionează ca un CA – poate să nu fievalid pentru alt utilizator, pentru că acesta ştie că Alice nu este de ı̂ncredere ca autoritatede certificare. Fiecare utilizator este direct responsabil ı̂n a decide ce certificate acceptăşi ce certificate respinge.

1.7 Algoritmi de criptare acceptaţi ı̂n P KI

Standardul RF C 4210 stabileşte algoritmii criptografici, funcţiile de dispersie şi semnăturiledigitale care pot fi folosite pentru a semna certificatele şi listele de revocare.

1. Algoritmii de semnătură:

Certificatele şi listele de revocare pot fi semnate teoretic cu orice protocol de semnă-tură cu cheie publică. Algoritmul folosit este totdeauna ı̂nsoţit de o funcţie dedispersie criptografică. Aceasta produce o amprentă a datelor care trebuie semnate.

4De exemplu, browserele Firefox şi Microsoft Explorer sunt distribuite ı̂mpreună cu aproximativ 100chei publice pre-instalate, fiecare cheie fiind ı̂nsoţită de un certificat.


16/274


Amprenta este apoi formatată corespunzător algoritmului de semnătură care va fifolosit.După generarea semnăturii, valoarea obţinută este codificată cu ASN.1 sub formaunui şir de biţi şi inclusă ı̂n certificat.

Algoritmi recomandat ̧i : DSA/SHA1.

Alt ̧i algoritmi : HMAC/SHA1, RSA/MD5, ECDSA/ECDH

2. Algoritmi de criptare:

(a) Algoritmi cu cheie publică: Utilizaţi pentru criptarea cheilor privatre trans-portate de mesajele P KI .

Algoritm recomandat : Diffie - Hellman5.

Alt ̧i algoritmi : RSA, ECDH .

(b) Algoritmi simetrici:

Pot fi utilizaţi dacă cheia de criptare a fost transmisă prin canal securizat.

Algoritm recomandat : 3DES (̂ın mod CBC )

Alt ̧i algoritmi : RC 5, Cast 128.

5Aloritmul de criptare Diffie - Hellman acceptat de X.509 este definit ı̂n ANSI X.9.42, publicat ı̂n2003.


17/274


18/274

Capitolul 2

Servicii terţe de ı̂ncredere (T T P )

2.1 Cerinţe ale serviciilor terţe de ı̂ncredere

2.1.1 Noţiuni introductive

Schimbul de informaţie electronică ı̂ntre două entităţi implică prezenţa unui element deı̂ncredere care să asigure unele servicii, cum ar fi autenticitatea acelor entităţi. Mai mult,uneori nivelul de ı̂ncredere aşteptat de entităţi nu se poate obţine decât cu ajutorul uneipărţi terţe, care să faciliteze schimbul de informaţie.

Definiţia 2.1. (X509) O entitate are ı̂ncredere ı̂n alta cˆ and are sigurant ̧a c˘ a partenerul se va comporta exact conform aştept˘ arilor sale.

Un tert ̧ de ı̂ncredere ( T T P - Trusted Third Party) este o entitate specific˘ a care furni-zeaz˘ a unul sau mai multe servicii electronice şi este considerat˘ a de ı̂ncredere de c˘ atre celelalte entit˘ at ̧i.

Exemplul 2.1. Exemple de servicii furnizate prin intermediul tert ̧ilor de ı̂ncredere: ser-vicii de marcare temporal˘ a, servicii de arhivare electronic˘ a, servicii de administrare a cheilor şi certificatelor de chei, servicii suport pentru identificare, autentificare şi non-repudiere, servicii de acordare de privilegii, servicii de notariat public electronic, servicii de directoare etc.

Conform recomandărilor I SO 14516, un terţ de ı̂ncredere trebuie:

• să ofere servicii clar definite;

• să respecte politici bine definite de utilizare şi de securitate, care sunt făcute public;

• să opereze ı̂ntr-un cadru perfect legal ı̂n ceea ce priveşte serviciile pe care le oferă şientităţile cărora se adresează;

• să opereze ı̂n conformitate cu standardele naţionale şi internaţionale ı̂n vigoare;

1


19/274

2 CAPITOLUL 2. SERVICII TERŢE DE ÎNCREDERE ( T T P )

• să fie independent şi imparţ ial pe timpul funcţionării;

• să urmărească cel mai bun cod de practici şi proceduri acceptat, pe care ı̂l facepublic;

• să ı̂nregistreze şi să arhiveze toate elementele de evidenţă relevante pentru tipul deservicii oferite, astfel ı̂ncât ulterior să se poată face auditarea;

• să permită arbitrarea independentă, fără a compromite securitatea serviciilor oferitesau a entităţilor sale client;

• să-şi asume responsabilitatea şi răspunderea ı̂n nişte limite definite pentru disponi-bilitatea şi 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 concordanţă cu politicile definite şi publicate de acesta.În funcţie de arhitectura furnizorului de servicii de ı̂ncredere, pot exista cerinţe adiţionaleşi de securitate care trebuie avute ı̂n vedere la administrarea şi operarea sa.

2.1.2 Cerinţe asupra terţilor de ı̂ncredere

În general, cerinţele formulate asupra unui terţ de ı̂ncredere diferă ı̂n funcţie de serviciilefurnizate.

Pentru a câştiga ı̂ncrederea părţilor interesate, un T T P trebuie să demonstreze că(ISO 14516):

• există şi aplică o politică de securitate potrivită;

• problemele de securitate sunt rezolvate printr-o combinaţie de mecanisme şi proce-duri de securitate corect implementate;

• operaţiile sunt realizate corect şi ı̂n strânsă legătură cu un set de roluri şi respon-sabilităţi clar definite;

• procedurile şi interfeţele de comunicare cu entităţile sunt potrivite cu scopul lor şi

sunt aplicate corect;

• regulile şi regulamentele sunt corect aplicate şi sunt consistente cu nivelul de ı̂ncre-dere dorit;

• calităţile operaţiilor şi practicilor de lucru au fost corect acreditate;

• respectă obligaţiile contractuale ̂ın raport cu utilizatorii săi;

• există o ı̂nţelegere şi acceptare clară a responsabilităţilor;


20/274

2.1. CERINŢE ALE SERVICIILOR TERŢE DE ÎNCREDERE 3

• compatibilitatea cu legile şi regulamentele este menţinută şi auditată;

• ameninţările cunoscute şi măsurile de contracarare a acestora sunt clar identificate;

• sunt ı̂ndeplinite cerinţele organizaţionale şi de personal;

• credibilitatea sa poate fi verificată;

• este monitorizat permanent de o autoritate administrativă care ı̂i supervizează ac-tivitatea.

Cerinţe funcţionale

D. Lekkas ş.a. au realizat ([11]) un studiu privind o serie de proiecte de securitate derulatela nivel european, toate bazate pe utilizarea T T P -urilor. Aici s-au identificat o serie decerinţe funcţionale care pot fi definite la nivelul unui T T P :

1. Autentificarea: Identificarea corectă a entităţilor implicate ı̂n tranzacţ iile elec-tronice.Se obţine ı̂n general utilizând mecanisme de criptografie cu chei publice şi semnăturăelectronică. Stocarea cheilor private de autentificare se face de obicei: pentru uti-lizatori pe smartcarduri dedicate, iar pentru serviciile furnizate de T T P -uri pe dis-pozitive speciale de tip H SM (Hardware Secure Module ).

2. Integritatea datelor: Păstrarea lor nealterată pe timpul comunicării ı̂ntre entităţi.Alterarea datelor poate fi accidentală sau intenţionată. Integritatea se poate realizautilizând mecanisme de semnătură electronică sau funcţii de dispersie.

3. Confidenţialitatea: Criptarea mesa jelor schimbate ı̂ntre entităţi ı̂n cadrul tranzac-ţiilor electronice constituie o cerinţă de bază. Se obţine utilizând ı̂n general algoritmide criptare cu chei simetrice, iar ı̂n unele situaţii – mecanisme de criptare asimetrică.

4. Non-repudierea: O entitate nu poate nega o acţiune (cum ar fi expedierea saurecepţionarea unui mesaj) sau existenţa unor informaţii la un moment dat.Această cerinţă poate fi asigurată cu tehnici de semnătură digitală (non-repudierea

originii mesajelor) sau de marcare temporală (existenţa datelor la un anumit mo-ment).

5. Disponibilitatea: Este de asemenea una din cerinţele fundamentale ale unui T T P .Ea este corelată cu politica T T P -ului şi SLA-ului (Service Level Agreament ) accep-tat.Disponibilitatea poate fi asigurată prin mecanisme specifice de HA (High - Avail-ability ) având la bază redundanţa echipamentelor şi mecanisme de DR (Disaster -Recovery ).


21/274


6. Uşurinţa de utilizare: Interfaţa sistemului cu utilizatorii constituie o cerinţă

importantă ı̂n condiţiile ı̂n care interacţionează ı̂n mod direct cu aceştia. Uneleservicii oferite de T T P nu interacţionează ı̂n mod direct cu utilizatorii, ci prinintermediul unor aplicaţii care implementează protocoale specifice.

7. Mobilitatea: Necesară – ı̂n unele situaţii – pentru utilizatorii mobili. Aceştiatrebuie să poată contacta un anumit T T P indiferent de localizarea lor ı̂n raport cuacesta.

8. Anonimitatea: O entitate poate fi ı̂nregistrată la un T T P , ı̂ns̆a (̂ın funcţ ie deopţiunile sale) identitatea sa trebuie să nu fie dezvăluită celorlaltor utilizatori.

9. Marcarea temporală: Mărcile temporale sigure (de ı̂ncredere) ataşate docu-mentelor electronice sunt necesare ı̂n anumite tranzacţii desfăşurate ı̂ntre entităţi.În general serviciile de marcare temporală (T SP - Time Stamp Providers ) suntvăzute ca servicii auxiliare ale serviciilor de securitate. Implementarea lor necesităı̂nsă un nivel mare de atenţie, datorită complexităţii şi cerinţelor speciale privindechipamentele hardware de sincronizare a timpului.

10. Unicitatea: Unicitatea unor documente electronice/mesaje poate fi o cerinţă func-ţională care trebuie ı̂ndeplinită de un T T P .

11. Inter-operabilitatea: Schimbul mesajelor nu poate fi restricţionat la domeniul

deservit de un singur T T P . ˆIn unele situaţii, mesajele electronice trebuie procesateı̂nsă de utilizatori din domenii deservite de T T P -uri diferite.

Cerinţa poate fi asigurată prin acţiuni suplimentare executate ı̂ntre T T P -uri şi suntspecifice fiecărui tip de T T P . De exemplu, cross - certificarea a două CA - uri dindomenii P KI diferite poate fi o condiţie necesară şi suficientă pentru asigurareainter-operabilităţii utilizatorilor acelor domenii.Tot inter-operabilitatea presupune şi respectarea standardelor care guvernează do-meniul de aplicabilitate.

12. Acreditarea: Procedurile de auditare si acreditare pentru T T P -uri sunt esenţialeı̂n special pentru asigurarea unui nivel de ı̂ncredere cerut ı̂n relaţiile cu utilizatorii.

Acreditarea se poate face la nivel local, naţ ional sau internaţional iar nivelul eidepinde de legile şi standardele existente ı̂n domeniul respectiv.

13. Politica de securitate: Fiecare T T P trebuie să ofere utilizatorilor săi o politică desecuritate bine definită, ı̂n concordanţă cu legislaţia şi restricţiile naţionale precumşi cu cerinţele de securitate definite.Disputele dintre entităţi vor fi arbitrate ı̂n concordanţă şi cu politicile de securitatedefinite la nivelul T T P -urilor implicate (direct sau indirect) ı̂n tranzacţiile electron-ice.


22/274

2.1. CERINŢE ALE SERVICIILOR TERŢE DE ÎNCREDERE 5

14. Managementul cheilor: Utilizatorii pot cere unui T T P diverse servicii de gestiune

privind cheile lor de semnătură şi criptare. Generarea cheilor, distribuţia acestorchei, mecanisme de recuperare de chei (key - recovery), backup pentru chei, key- escrow, rêınnoirea automată sau la cerere a cheilor (la expirare sau ı̂n caz decompromitere) pot fi cerinţe funcţionale la nivelul unui T T P .

15. Publicarea datelor: Serviciile de publicare din T T P -uri sunt necesare pentrupu-blicarea unor informaţii folosite de utilizatorii sistemelor. Distribuirea cheilorpublice sau a certificatelor digitale pentru utilizatori, distribuirea listelor de certifi-cate revocate sunt informaţii esenţiale proceselor de certificare şi validare.Serviciile de publicare pot fi implementate prin intermediul unor protocoale cum arfi LDAP, HTTP, X.500, DNS etc.

16. Scalabilitatea şi modularitatea: Serviciile furnizate de T T P -uri trebuie să fiescalabile şi uşor gestionabile ı̂n implementări pe scară largă. Structura modularizatăpermite adăugarea sau scoaterea cu uşurinţă a unor componente de funcţionalitatela nivelul T T P -ului.

17. Compatibilitatea şi portabilitatea: Presupune compatibilitatea implementări-lor T T P -urilor cu standardele, tehnologiile şi platformele software/hardware cerute.

Cerinţe privind politica de securitate

Politica de securitate a unui T T P trebuie să acopere toate aspectele de securitate privindadministrarea T T P ului şi operarea serviciilor sale, fiind un instrument vital pentru genera-rea ı̂ncrederii către entităţile client.

O politică de securitate ı̂nglobează toate elementele principale de funcţionare aleterţului de ı̂ncredere. Orice politică de securitate ar trebui să conţină:

1. O componentă privind politica de securitate generală, ı̂n care care sunt stabilitetoate aspectele non-tehnice privind securitatea şi ı̂ncrederea ı̂n serviciile terţului;

2. O componentă privind politica de securitate tehnică, ı̂n care sunt stabilite aspecteletehnice privind securitatea şi funcţionalitatea terţului. Aici sunt descrise rutinele,procedurile şi aspectele tehnice ale sistemului.

Conţinutul efectiv al politicii depinde de serviciile oferite de T T P . În orice politică desecuritate sunt incluse următoarele elemente:

• conceptele generale privind serviciile furnizate;

• definirea entităţilor participante;

• cerinţele de securitate (confidenţialitatea, integritatea, disponibilitatea, autentici-tatea, responsabilitatea);


23/274


• infrastructura organizaţională si asignarea responsabilităţilor ı̂n cadrul T T P -ului;

• obligaţiile si răspunderile T T P -ului şi a celorlaltor entităţi implicate;

• ciclul de viaţă al cheilor criptografice necesare (mecanismul de generare a cheilor,protejarea cheilor, timpul lor de viaţă, rêınnoirea cheilor, distrugerea cheilor etc.);

• mecanismele de asigurare a securităţii ı̂n cadrul sistemului;

• procedurile de operare şi scenariile lor de aplicare;

• definirea rolurilor necesare ı̂n cadrul operării serviciilor furnizate;

• definirea claselor pentru clasificarea informaţiilor;

• aspectele legate de personal, ı̂n special pentru personalul din funcţii - cheie;

• strategiile de gestiune a riscurilor;

• tratarea incidentelor.

2.2 Configuraţii cu terţi de ı̂ncredere

Din punct de vedere al poziţionării terţului de ı̂ncredere ı̂n cadrul comunicaţiei dintre en-tităţile client, precum şi al implicării sale directe sau indirecte la protocolul de comunicaţie,se pot realiza trei configuraţii diferite:

1. Configurat ̧ie cu T T P in-line :

Un terţ de ı̂ncredere in-line poate exista atunci când două entităţi aparţinând ladouă domenii de securitate diferite doresc să schimbe ı̂ntre ele mesaje securizate.În această situaţie, terţul este poziţionat ı̂ntre cele două entităţi, acţionând ca unintermediar ı̂n toate interacţiunile dintre ele şi facilitând schimburile lor securizatede informaţii.

Entitate Alice T T P

in − line Entitate Bob

Configuraţiile cu T T P -uri in-line pot include servicii cum ar fi autentificarea saucontrolul privilegiilor (terţii de ı̂ncredere jucând un rol ı̂n furnizarea de servicii denon-repudiere), controlul accesului, recuperarea de chei, confidenţialitate şi integri-tate pentru datele transmise.


24/274

2.3. INTER-OPERAREA SERVICIILOR T T P 7

2. Configurat ̧ie cu T T P on-line : Un T T P on-line se poate utiliza ı̂n situaţia când

cel puţin una din entităţi cere terţului respectiv furnizarea sau ı̂nregistrarea unorinformaţii de securitate, iar terţul este implicat doar ı̂n câteva din schimburile se-curizate dintre ele (de obicei ı̂n prima fază a comunicaţiei).

Ulterior T T P nu mai participă la tranzacţiile dintre entităţi şi nu este poziţionatpe calea lor de comunicaţie.

Entitate Alice Entitate Bob

T T P on − line

Astfel de configuraţii pot include servicii de autentificare, certificare, controlul pri-vilegiilor etc.Terţul de ı̂ncredere poate juca de asemenea un rol ı̂n furnizarea de servicii de non-repudiere, controlul accesului, managementul cheilor, marcare temporală, confiden-ţialitate şi integritate pentru datele transmise.

3. Configurat ̧ie cu T T P off-line : Terţul de ı̂ncredere off-line nu interacţionează di-

rect cu entităţile ı̂n timpul schimburilor de mesaje securizate. ˆIn schimb, entităţilecomunică ı̂ntre ele folosind date generate anterior de către T T P .

Entitate Alice Entitate Bob

T T P on − line

T T P -urile off-line pot include servicii de autentificare, certificare, controlul privi-legiilor, 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 reţeacare să permită entităţilor sale să comunice securizat cu entităţile acestea. În situaţiileı̂n care T T P -ul nu poate oferi anumite servicii solicitate, se pot stabili protocoale de


25/274


ı̂ncredere care să permită altor T T P -uri să subcontracteze şi să asigure aceste servicii

suplimentare.La analizarea cerinţelor de interconectare trebuie avut ı̂n vedere dacă relaţia legală

dintre un T T P şi abonaţii săi este diferită de cea dintre acel T T P şi alte entităţi interesate(de exemplu utilizatori care verifică semnături digitale bazate pe certificatele digitale emisede o Autoritate de Certificare).Fiecare terţ de ı̂ncredere furnizează servicii către entităţile din domeniul său conform cupolitica de securitate proprie.

Există următoarele posibilităţi de interconectare:

1. Interconectare T T P - Utilizator : presupune mecanisme şi mijloace prin care un uti-lizator interacţionează cu un T T P pentru a cere/primi un serviciu. Fiecare utilizator

poate interacţiona cu un T T P ı̂n mod diferit, ı̂n funcţie de serviciul solicitat.

2. Interconectare Utilizator - Utilizator : după ce un T T P şi-a terminat joburile ı̂nrelaţia cu entităţile sale, toate comunicaţiile dintre entităţi se pot face fără a mai finevoie de asistenţa T T P -ului.

Relaţia ı̂ntre entităţi, precum şi formalizarea contractuală a acestei relaţii, se bazeazăpe ı̂ncrederea acestora ı̂n T T P şi 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 interfaţă (ISO 14516):

Domeniu Alice

Alice

T T P A T T P B

Bob

Domeniu Bob

(1) (3)

(2)

(3) (1)

(4)

(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̆ către Alice (3) şi către T T P -ul B (2).

(c) T T P -ul B transmite apoi cheia către Bob (3).

(d) Având stabilită o cheie comună, cele două entităţi pot comunica securizat (4).


26/274

2.4. SERVICII DE NON-REPUDIERE 9

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 către T T P -ul B emiterea unui certificat (1) şi-l obţine (3).

(d) De asemenea, cele două T T P -uri ı̂şi emit una către cealaltă câte un certificat(2).

(e) Acum, cele două entităţi pot comunica securizat având stabilită ı̂ntre ele in-frastructura de chei de ı̂ncredere publice (4).

2.4 Servicii de Non-Repudiere

Repudierea este una dintre problemele de securitate fundamentale existente ı̂n tranzacţiileefectuate prin documente. Necesitatea serviciilor de non-repudiere nu provine numai dinfaptul că părţile pot ı̂ncerca să se ı̂nşele una pe cealaltă. Este o realitate bine cunoscutăfaptul că diverse circumstanţe neaşteptate pot conduce la situaţia ı̂n care două entităţiimplicate ı̂ntr-o tranzacţ ie ajung – ı̂n timp – să aibă puncte diferite de vedere cu privire lace s-a ı̂ntâmplat ı̂n cadrul relaţiei dintre ele. O eroare de comunicaţie pe reţea ı̂n timpulderulării unui protocol este un exemplu reprezentativ.

Putem defini o tranzacţie de bază ca fiind transferarea unui mesaj M de la Alice

(Emitent) la Bob (Receptor):A −→ B : M

Chiar şi ı̂ntr-o astfel de tranzacţie simplă, ar putea apare următoarele cazuri de disput̆a:

• Alice susţine că a trimis mesajul M lui Bob, iar Bob acuză faptul că nu l-a primit;

• Bob susţine că a primit mesajul M de la Alice, iar Alice acuză faptul că nu l-atrimis;

• Alice susţine că a trimis mesajul M ı̂nainte de un moment de timp T , ı̂n timp ceBob declară că că nu a primit mesajul ı̂nainte de momentul T .

Serviciile de non-repudiere ajută entităţile implicate ı̂ntr-o astfel de tranzacţ ie să rezolveposibilele dispute care pot apare cu privire la anumite evenimente sau acţiuni care s-auı̂ntâmplat (sau nu s-au ı̂ntâmplat) ı̂n cadrul tranzacţiei.

Definiţia 2.2. Un protocol de non-repudiere este un flux de tranzact ̧ii ı̂n care entit˘ at ̧ile implicate schimb˘ a dovezi electronice, capabile s˘ a ofere apoi servicii de non-repudiere.

Principalele dovezi de non-repudiere – prezente ̂ın toate protocoalele propuse – sunt:


27/274


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

(NRO), dacă şi numai dacă poate genera o dovadă privind originea mesajului –destinată receptorului mesajului – şi care prezentat̆a unui judecător, acesta poatestabili fără dubiu că iniţiatorul a trimis acel mesaj.

• Non-Repudierea Recept ̧iei : un protocol de non-repudiere oferă non-repudierea recep-ţiei (NRR), dacă şi numai dacă poate genera o dovadă privind primirea mesajului– destinată iniţiatorului mesajului – şi care prezentată unui judecător, acesta poatestabili fără dubiu că destinatarul a primit acel mesaj.

Un protocol de non-repudiere este corect (fair) dacă la finalizarea sa:

• Alice deţine o dovadă de tip N RR, iar Bob deţine o dovadă de tip NRO; sau

• nici unul dintre ei nu deţ ine o informaţie de acest tip.

Protocoalele de non-repudiere corecte au constituit o temă importantă de cercetare ı̂nliteratura de specialitate. Studiul [15] ı̂mparte protocoalele de non-repudiere ı̂n:

1. protocoale cu corectitudine tare;

2. protocoale cu corectitudine adevărată;

3. protocoale cu corectitudine probabilistică.

Cele mai multe protocoale de non-repudiere propuse iau ı̂n considerare cazul ı̂n care suntimplicate doar două entităţi, care trebuie să obţină dovezile de non-repudiere a originii,respectiv a recepţiei unui mesaj. Există şi scheme de protocoale care asigur̆a dovezilenecesare de non-repudiere pentru scenarii cu mai mult de două entităţi care doresc săschimbe mesaje ı̂ntre ele. Un studiu asupra acestui tip de protocoale este realizat ı̂n [25].

Într-o tranzacţie electronică, un transfer de mesaj poate fi transferat de la un emitentE (Alice) către un receptor R (Bob) ı̂n două feluri:

1. E trimite mesajul direct către R (comunicare directă); sau

2. E trimite mesajul către un Agent de Expediere intermediar AE , care apoi trimitemesajul către R (comunicare indirectă).

E R

AE

Comunicare directă

Comunicare indirectă


28/274


În varianta de comunicare directă, dacă Emitentul şi Receptorul nu au ı̂ncredere unul

ı̂n cel̆alalt, pentru a se putea contoriza corect acţiunile lor, sunt necesare următoareleservicii de non-repudiere (ISO 13888 − 3):

• Non-Repudierea Originii (NRO): asigură protecţia ı̂mpotriva refuzului Emitentu-lui de a recunoaşte transmiterea mesajului. Dovada transmiterii mesajului va figenerată de Emitent sau un T T P şi va fi păstrată de Receptor .

• Non-repudierea Recept ̧iei (N RR): asigură protecţia ı̂mpotriva refuzului Receptorului de a recunoaşte primirea mesajului. Dovada primirii mesajului este generată deReceptor sau de un T T P şi va fi păstrată de Receptor .

ˆIn varianta de comunicare intermediată de un Agent de Expediere (AE ), pentru a seputea rezolva eventualele dispute ı̂ntre Emitent şi Agentul de Expediere , respectiv ı̂ntre

Agentul de Expediere şi Receptor , sunt necesare următoarele servicii de non-repudiereISO 13888 − 3):

• Non-repudierea depunerii (N RS ): asigură dovada că Emitentul a depus mesajulpentru expediere. Dovada depunerii mesajului este generată de Agentul de Expediere şi va fi păstrată de Receptor .

• Non-repudierea expedierii (NRD): asigură dovada că mesajul a fost expediat deReceptor . Dovada de expediere este generată de Agentul de Expediere şi va fi păstratăde Emitent .

În general, protocoalele care stau la baza unui serviciu de non-repudiere trebuie săı̂ndeplinească următoarele cerinţe:

• Corectitudine : Nici una din cele două entităţi implicate nu trebuie să poată deţinevreun avantaj faţă de cealaltă privind obţinerea dovezilor de non-repudiere.Repudierea poate fi prevenită numai dacă fiecare entitate obţine ı̂n egală măsurăinformaţia de care are nevoie: Bob trebuie să obţină mesajul util şi dovada denon-repudiere a originii acestui mesaj, iar Alice trebuie să obţină dovada de non-repudiere a recepţiei mesajului transmis.În caz contrar, cei doi utilizatori nu trebuie să aibă acces la nici una din aceste

informaţii.

• Eficient ̧̆ a : Non-repudierea se obţine ı̂n general prin folosirea unor servicii de tipT T P . Gradul de implicare al acestora este esenţial ı̂n determinarea eficienţei unuiprotocol de non-repudiere.

• Oportunitate : Din diverse motive, o tranzacţie din protocolul de non-repudiere poatefi ı̂ntârziată sau chiar stopată intenţionat de una dintre părţile implicate. Acest lucrunu trebuie să dezavantajeze cealaltă parte.


29/274


• Politic˘ a : Toate regulile şi toţi parametrii necesari ı̂n cadrul serviciului de non-

repudiere trebuie definite corect şi complet.

• Transparent ̧a T T P -ului : În anumite situaţii este de dorit ca implicarea T T P -uluiı̂n cadrul protocolului (sau a rezolvării disputelor) să fie invizibilă. Astfel, dovezileobţinute prin implicarea T T P -ului vor fi similare celor obţinute fără ajutorul aces-tuia.

• Verificabilitatea T T P -ului : Proprietate necesar̆a ı̂n situaţ ia când T T P -ul nu esteconsiderat de ı̂ncredere de ambele entităţi.

2.4.1 Protocoale de non-repudiere bazate pe T T P -uri

Există mai multe abordări şi propuneri privind protocoale care să asigure cerinţele definitemai sus pentru un serviciu de non-repudiere. Unele presupun obţinerea dovezilor de non-repudiere făra a implica terţe părţi ı̂n comunicarea dintre Alice şi Bob; cele mai multeprotocoale se bazează ı̂nsă pe conectarea la un T T P .

Rolul T T P -urilor ı̂n protocoalele de non-repudiere

În funcţie de mecanismele de non-repudiere folosite şi de politica aplicată, T T P -urile potparticipa sub diverse roluri la generarea, verificarea, validarea sau transferarea dovezilorde non-repudiere şi la arbitrarea disputelor.

Din punct de vedere al implicării T T P -ului ı̂n cadrul derulării unui protocol de non-repudiere, pot fi identificate trei situaţii (ISO 10181 − 4):

1. Protocoale de non-repudiere bazate pe T T P -uri in-line . Acest tip de terţi de ı̂ncre-dere acţionează ca intermediari ı̂n toate tranzacţiile efectuate ı̂ntre entităţi. Toatemesajele 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̆ activla generarea şi verificarea dovezilor de non-repudiere.

3. Protocoale de non-repudiere bazate pe T T P -uri off-line . În această situaţie, terţiide ı̂ncredere nu participă activ ı̂n cadrul serviciului de non-repudiere (vor fi invocaţidoar ı̂n anumite situaţ ii de excepţie).

Un T T P implicat ı̂n gestionarea dovezilor de non-repudiere se poate afla ı̂n una dinsituaţiile de mai jos ([30]):

• Ca Autoritate de Certificare . Un CA generează certificate digitale pentru cheileutilizatorilor, autentificându-le astfel pentru a fi folosite ı̂n protocoalele de non-repudiere. CA-ul furnizează de asemenea listele de certificate revocate, pentru aputea fi determinată validitatea cheilor folosite.


30/274


Autorităţile de Certificare sunt folosite ı̂ntotdeauna ı̂n situaţ iile când pentru gene-

rarea dovezilor de non-repudiere sunt utilizate semnăturile digitale. În general,T T P -urile cu rol de C A sunt utilizate off-line ı̂n protocoalele de non-repudiere. Elepot fi folosite şi ca T T P -uri on-line, dacă semnăturile electronice folosesc formateavansate de semnătură electronică şi conţin informaţii bazate pe servicii on-line devalidare a certificatelor.

• Ca Notar Electronic . Similar cazului non-electronic, un T T P cu rol de notar elec-tronic poate fi utilizat pentru asigurarea unor servicii de non-repudiere.

Dacă pentru generarea dovezilor de non-repudiere sunt folosite mecanisme bazate pecriptografia simetrică, T T P -ul implicat ı̂n protocol poate fi activat pentru a genera

dovezile de non-repudiere ı̂n numele participanţilor. Dacă dovezile de non-repudierese obţin pe bază de semnături digitale, notarul ar trebui să furnizeze mărci temporaleprivind momentul generării dovezilor.

În general T T P -urile cu rol de Notar Electronic sunt utilizate ı̂n protocoalele denon-repudiere ı̂ntr-o arhitectură on-line.

• Ca Autoritatea de Expediere . O astfel de Autoritate constituie un terţ de ı̂ncredereı̂n ceea ce priveşte expedierea mesajelor.

Acest tip de T T P -uri este utilizat ı̂n cadrul protocoalelor de non-repudiere ı̂ntr-oarhitectură in-line.

• Ca Autoritatea de Arbitrare . Un T T P cu acest rol nu va fi implicat ı̂n proto-coale decât ı̂n situaţiile ı̂n care apar dispute, principalul său scop fiind judecareaşi rezolvarea acestora. Judecarea disputelor presupune evaluarea dovezilor puse ladispoziţie de participanţi şi luarea ı̂n consideraţie a unei politici de non-repudiere.

Protocoale de non-repudiere fără T T P -uri

Protocoalele de acest tip pot asigura doar probabilistic cerinţele de non-repudiere.Chiar dacă ı̂n implementare se aleg corect parametrii protocolului, gradul de risc este

foarte mic iar probabilitatea de nesoluţ ionare a disputelor este neglijabilă, totuşi 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 init ̧ial pentru schimbul de secrete (de exemplu chei criptografice) ı̂ntre entit˘ at ̧i. Ideea de baz˘ a era ca fiecare entitate s˘ a transmit˘ a pe rˆ and bit ̧i succesivi din informat ̧ia secret˘ a care trebuia furnizat˘ a celeilalte entit˘ at ̧i, pˆ an˘ a la epuizarea informat ̧iei. Dac˘ a o entitate stopa procesul, cealalt˘ a proceda similar; ı̂n acest mod, efortul de calcul pentru aflarea restului de informat ̧ie era sensibil echivalent pentru ambele entit˘ at ̧i. ˆ In cadrul acestor protocoale de schimb de date pot fi identificate mecanisme clare de non-repudiere.


31/274


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

Abia mai târziu au apărut şi protocoale de non-repudiere care nu necesitau existenţa unuiT T P .

Pentru exemplificare prezentăm protocolul probabilist de non-repudiere propus deMarkowitch şi Roggeman ([18]). Protocoale similare care asigură non-repudierea şi nufolosesc T T P -uri au mai fost realizate ı̂n [13], [26], [22].

Scopul protocolului Markowitch - Roggeman este de a obţ ine dovezile de non-repudiereNRO şi N RR fără a utiliza un terţ de ı̂ncredere. Protocolul ı̂si propune să asiguretransmiterea unui mesaj M de la Alice către Bob şi să asigure dovezile de non-repudierea originii şi recepţiei mesajului.

Protocolul este descris de următoarele tranzacţii:

1. În prima rundă, Alice:

(a) Criptează mesajul M folosind cheia simetrică k şi obţine c = E k(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 răspunde cu dovada recepţiei mesajului criptat c:

EORC = SigBob(Alice,l,c)

3. În rundele i = 2, . . . , n− 1

(a) Alice trimite lui Bob cuplul (EOOri−1 , ri−1) unde ri−1 este o valoare aleatoarede rundă, iar

EOOri−1 = SigAlice(Bob,i,ri−1)

(b) Bob răspunde cu dovada recepţiei valorii ri−1:

EORri = SigBob(Alice,i,ri)

4. În ultima rundă, Alice trimite cheia simetrică k şi dovada E OOrn−1 a originii aces-teia:

EOOrn−1 = SigAlice(Bob,n,k)

5. Bob răspunde cu dovada recepţiei cheii k :

EORrn−1 = SigBob(Alice, n, k)


32/274


După epuizarea rundei n şi primirea lui E ORrn−1, Alice anunţă terminarea protocolului,

dezvăluind practic numărul de runde ales şi faptul că ı̂n această ultimă rundă a trimis cheiasimetrică k prin care Bob poate obţine mesajul M = Dk((c). Dovada de non-repudiere aoriginii va fi:

NRO = (EOOc,EOOrn−1),

iar dovada de non-repudiere a recepţiei va fi N RR = (EORc,EORrn−1).

În cazul unei dispute:

• Bob poate dovedi non-repudierea originii:

– EOOc: dovedeşte că Alice i-a trimis mesajul criptat cu o cheie simetrică;

– EOOrn−1: dovedeşte că Alice i-a trimis şi cheia simetrică de decriptare.

• Alice poate dovedi non-repudierea recepţiei:

– EORc: dovedeşte că Bob i-a confirmat primirea mesajului criptat cu o cheiesimetrică;

– EORrn−1: dovedeşte că Bob i-a confirmat şi primirea cheii simetrice de de-criptare, adică obţinerea mesajului M .

Protocolul se bazează pe păstrarea secretului privind numărul de runde şi cheia secretă k,

alese de Alice până la epuizarea ı̂ntregului set de runde. Bob, neştiind dinainte numărulde runde fixat de Alice, ı̂n ultima rundă nu va şti că a primit cheia simetrică decât dupăce va fi anunţat de Alice, furnizând la rândul lui informaţia necesară de non-repudiere.

Observaţia 2.1.

• La fiecare din ultimele n − 1 runde, ı̂nainte de a trimite dovada non-repudierii recept ̧iei corespunz˘ atoare, Bob ar putea ı̂ncerca decriptarea mesajului primit ı̂n prima rund˘ a; dac˘ a reuşeşte, poate alege s ̆a nu mai trimit˘ a aceast˘ a dovad˘ a, ceea ce l-ar pune ı̂n avantaj fat ̧̆ a de Alice. Aceast˘ a problem˘ a se poate rezolva printr-o implementare care s˘ a contorizeze timpii de r˘ aspuns ai lui Bob. Astfel, dac˘ a apare o ı̂nt ̂arziere mai

mare ı̂n cadrul unui r˘ aspuns de la Bob, protocolul eşueaz ̆a. Pentru asta, trebuie ales un algoritm de criptare ı̂n care operat ¸ia de decriptare s˘ a dureze un timp suficient ca s˘ a poat˘ a fi detectat de Alice. Solut ¸ia este ineficient˘ a practic din mai multe motive (stadiul actual face ca timpii de calcul s˘ a fie insezizabili; sau, dac˘ a entit˘ at ̧ile uti-lizeaz˘ a o ret ̧ea de comunicat ̧ie instabil˘ a unde pot apare ı̂ntˆ arzieri nepredictibile, f˘ ar˘ a ca ele s˘ a fie induse de Bob).

• Pentru ca protocolul s˘ a fie funct ¸ional, valorile aleatoare r1, . . . , rn−1 trebuie s˘ a fie independente, egal distribuite, de lungimi aproximativ echivalente cu lungimea lui k.


33/274


• Alice trebuie s˘ a aleag˘ a un algoritm de criptare simetric şi/sau un mod de utilizare

al acestui algoritm care s˘ a nu permit˘ a decriptarea doar a unei p˘ art ̧i a mesajului. ˆ In [18] sunt propuse astfel de moduri şi mecanisme de prevenire.

• Oricare dintre entit˘ at ̧i poate ı̂ntrerupe protocolul ı̂n rundele intermediare; ı̂n aceast˘ a situat ̧ie, nici Alice şi nici Bob nu det ¸ine un avantaj, deoarece nu va avea dovada privind trimiterea/recept ̧ia cheii simetrice de decriptare.

Exist˘ a ı̂ns ̆a o probabilitate ca Bob s˘ a intuiasc˘ a corect num˘ arul de ordine al rundei finale şi s˘ a ı̂ntrerup ̆a protocolul ı̂nainte de epuizarea corect˘ a a acestei runde finale,ceea ce ı̂i confer˘ a un avantaj. ˆ In aceast˘ a situat i̧e Bob va avea dovada complet˘ a a non-repudierii originii ı̂n timp ce lui Alice ı̂i lipseşte dovada recept ̧iei 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

În 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 (NRS - Non-Repudiation Server ).Acest terţ colectează dovezile de non-repudiere şi le transmite apoi entităţilor care ı̧̂sidispută tranzacţia. Practic terţul de ı̂ncredere funcţionează ca un Agent de Expediere (AE ) pentru mesajele schimbate ı̂ntre entităţile participante.

Protocolul utilizează semnăturile digitale (ca mecanism criptografic pentru generareadovezii de non-repudiabilitate) şi criptografia cu chei publice (pentru schimbul de mesaje).

Pentru ca protocolul să fie funcţional, Serverul de Non-Repudiere trebuie să aibăurmătoarele caracteristici:

• este independent de cele două entităţi, fiind ı̂nsă de ı̂ncredere pentru acestea;

• nu distribuie nici o informaţie legată de dovezi către vreo entitate participantă pânăcând nu deţine şi dovada corespunzătoare pentru a putea fi distribuită către cealaltăentitate;

• primeşte dovada de non-repudiere a originii direct de la Alice şi cooperează cu Bobpentru a genera dovada de non-repudiere a recepţiei;

• odată ce deţine toată informaţia necesară de non-repudiere pentru ambele entităţi,nu se va opune procesului de distribuţie a acestei informaţii către cele două entităţi.

Protocolul Coffrey - Saidha se desfăsoară ı̂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.


34/274


Emitent Alice Receptor Bob

T T P

Faza 1

Faza 2

După ce se consumă Faza 1 şi Serverul de Non-Repudiere este ı̂n posesia celor douădovezi, el va distribui ı̂n Faza 2 aceste dovezi către părţile comunicante.

Toată comunicarea dintre Alice şi Bob are avea loc prin intermediul Serverului de Non-Repudiere, iar mesajele schimbate sunt semnate digital şi ı̂nsoţite de o informaţie privind

momentul semnării. De aceea – pe lângă Serverul de Non-Repudiere – protocolul necesităşi prezenţa unei Autorit˘ at ̧i de Marcare Temporal˘ a care să marcheze momentul semnării şisă poată astfel demonstra că semnarea mesajelor s-a făcut ı̂n perioada de valabilitate acertificatelor digitale corespunzătoare cheilor de semnătură.

Protocolul Coffey-Saitha cu T T P in-line este descris formal de următoarele tranzacţii:

1. Alice −→ T SA : P K TSA(NROp)2. T SA −→ Alice : P K Alice(N RO)3. Alice −→ N RS : ”NR − req ”4. N RS −→ Alice : P K Alice(n1)

5. Alice −→ N RS : P K NRS (SigAlice(n1,NRO,NRRp))6. N RS −→ Bob : P K Bob(SigNRS (n2,NRRp))7. Bob −→ T SA : P K TSA(NRRps)8. T SA −→ Bob : P K Bob(NRR)9. Bob −→ N RS : P K NRS (SigBob(n2,NRR))

10. N RS −→ Bob : P K Bob((N RO))11. N RS −→ Alice : P K Alice(N RR)

Descrierea şi analiza protocolului:

• Toate mesajele intermediare M i sunt criptate cu cheia publică a entităţii destinaţie:P K Bob(M i). Astfel numai Bob – ı̂n calitate de destinatar – poate accesa mesajultransmis, utilizând pentru decriptare, cheia sa privată.

• În paşii 1 şi 2, Alice – ca entitate iniţiatoare – generează prin intermediul terţului deı̂ncredere dat de Autoritatea de Marcă Temporală (T SA – Timestamp Authority )dovada de non-repudiere a originii (NRO).

Alice trimite către T SA dovada parţială a originii:

NROp = SigAlice(Alice, Bob, M )


35/274


şi primeşte de la T SA marca temporală peste această semnatură:

N RO = SigTSA((NROp,TSA,ts1)

unde T SA şi ts1 reprezintă identificatorul T SA-ului şi respectiv timpul aplicat.

• La pasul 3 Alice iniţiază o sesiune de lucru cu Serverul de Non-Repudiere (NRS ),transmiţându-i o cerere de non-repudiere N R − req .

• În paşii 4 şi 5 Alice transmite către N RS dovada de non-repudiere a originii (N RO)obţinută la primii doi paşi, precum şi o dovadă parţială de non-repudiere a recepţiei:

NRRp = (Bob, Alice,h(N RO))

unde h este o funcţie de dispersie criptografică. Pentru a evita atacuri de tip replay,se foloseşte o secvenţă de tip provocare - răspuns bazată pe un nonce n1, generatde serverul N RS la pasul 4.

Fiind criptat de N RS cu cheia publică a lui Alice, nonce-ul transmis nu poate fiaccesat decât de Alice.

• În pasul 6, serverul NRS iniţiază generarea dovezii de non-repudiere a recepţieitransmiţându-i lui Bob un nonce n2 (necesar mai târziu) şi dovada parţială de non-repudiere NRRp primită de la Alice.

• În paşii 7 şi 8, Bob generează – prin intermediul terţului de ı̂ncredere dat de T SA– dovada de non-repudiere a recepţiei (N RR). Bob trimite spre T SA o dovadăparţială de non-repudiere a recepţiei, semnată de el:

NRRps = SigBob(NRRp) = SigBob(Bob, Alice, h(NRO))

şi primeşte de la T SA marca temporală peste această semnătură:

NRR = SigTSA(NRRps,TSA,ts2) = SigTSA(SigBob(Bob, Alice, h(NRO))).

• La pasul 9 Bob trimite către Serverul de Non-Repudiere (NRS ), dovada de non-repudiere a recepţiei NRR, ı̂nsoţită de nonce-ul n2 (pentru a evita atacurile de tipreplay).

• În acest moment, Faza 1 s-a ı̂ncheiat şi N RS – având ambele dovezi de non-repudiere– este ı̂n măsură să treacă la Faza 2 a protocolului: transmiterea acestor dovezi cătreAlice şi Bob.

Astfel, ı̂n paşii 10 şi 11, Bob va primi dovada de non-repudiere a originii mesajului(NRO) şi – ı̂mpreună cu acesta – şi mesajul propriu zis M ; similar, Alice primeştedovada de non-repudiere a recepţiei mesajului (NRR).


36/274


Observaţia 2.2.

1. Ideea principal˘ a a protocolului Coffey - Saidha este aceea c˘ a dovezile de non-repudie-re a originii şi respectiv a recept ̧iei nu sunt trimise celor dou˘ a entit˘ at ̧i pˆ an˘ a ce acestea nu depun aceste dovezi semnate la Serverul de Non-Repudiere.

2. Dovezile de non-repudiere det ¸inute de Alice şi Bob nu cont ̧in semn˘ atura N RS -ului.Acestea sunt:

• NRO = SigTSA(SigAlice(Alice,Bob, M ),TSA,ts1);

• NRR = SigTSA(SigBob(Bob, Alice, h(NRO)),TSA,ts2).

3. Cele dou˘ a entit˘ at ̧i nu comunic˘ a niciodat˘ a direct; schimbul de mesaje (mesajul M şi dovezile de non-repudiere) se face numai prin intermediul Serverului de Non-Repudiere.

4. Mesajul M ajunge la Bob odat˘ a cu dovada de non-repudiere a originii NRO şi nu ı̂nainte ca N RS s˘ a det ̧in˘ a dovada de non-repudiere a recept ̧iei NRR.

5. ˆ In cazul solut ̧ion˘ arii unei dispute ı̂n care Alice sust ̧ine c˘ a Bob a primit mesajul M , arbitrul cere NRS -ului dovada de non-repudiere a recept ̧iei ( NRR) precum şi dovada de non-repudiere a originii ( NRO).

Dac˘ a aceste dovezi nu pot fi oferite, afirmat ̧ia lui Alice este respins˘ a. Altfel, ar-bitrul verific˘ a semn˘ atura lui Alice şi marca temporal˘ a aplicat˘ a de T SA pe aceas-t˘ a semn˘ atur˘ a. De asemenea verific˘ a valoarea h(N RO) din cadrul dovezii NRR,semn˘ a-tura lui Bob şi marca temporal˘ a aplicat˘ a peste aceasta.ˆ In caz de succes, arbitrul aprob˘ a afirmat ̧ia lui Alice.

6. ˆ In cazul solut ̧ion˘ arii unei dispute ı̂n care Bob sust ̧ine c˘ a Alice a trimis mesajul M ,arbitrul cere N RS -ului sau lui Bob dovada N RO. Dac˘ a aceasta nu poate fi oferit˘ a,afirmat ̧ia lui Bob este respins˘ a.Altfel, arbitrul verific˘ a dac˘ a mesajul din NRO satisface informat ̧ia oferit˘ a de Bob.De asemenea, verific˘ a semn˘ atura lui Alice şi marca temporal˘ a aplicat˘ a de T SA pe

aceast˘ a semn˘ atur˘ a. ˆ In caz de success, arbitrul aprob˘ a afirmat ̧ia lui B.

7. T SA-ul particip˘ a activ la generarea dovezilor de non-repudiere; cei doi participant ̧i precum şi Serverul de Non-Repudiere, trebuie s˘ a aib˘ a ı̂ncredere ı̂n acesta şi s ̆a verifice semn˘ aturile digitale ale T SA-ului aplicate la marcarea temporal˘ a a mesajelor (pentru a se asigura c˘ a dovezile generate sunt valabile la solut ̧ionarea disputelor ulterioare).

8. Alice şi Bob nu trebuie s˘ a aib˘ a ı̂ncredere unul ı̂n cel˘ alalt, dar trebuie s˘ a aib˘ a ı̂ncredere ı̂n cele dou ̆a T T P -uri.


37/274


9. Atacurile de tip replay ı̂n relat ¸ia NRS - Entitate sunt ocolite prin utilizarea unor

secvent ̧e de tip provocare -r˘ aspuns, bazate pe informat ̧ii de tip nonce transmise de N RS .

Concluzie: Utilizarea de T T P -uri in-line (pentru asigurarea dovezilor necesare ı̂nserviciile de non-repudiere) poate fi o soluţie viabilă. Există ı̂ns̆a câteva dezavantajemajore 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 mesajelepe care le primeşte pentru a le retransmite.

2. La nivelul T T P -ului, ”gâtuirea” tranzacţiilor este maximă.

3. Gestiunea centralizată de informaţii sensibile ı̂n cantităţi mari poate constitui oproblemă, necesitând un nivel suplimentar de confidenţialitate la nivelul terţului.

Protocoale de non-repudiere bazate pe T T P -uri on-line

În cazul protocoalelor de non-repudiere bazate pe T T P -uri on-line, T T P -ul nu acţioneazăca Agent de Expediere (intermediar pentru fiecare tranzacţie ı̂ntre entităţi). El intervinetotuşi ı̂n cadrul fiecărei sesiuni a protocolului.

Dintre protocoalele de acest tip vom detalia pe cel propus de Zhou şi Gollmann ([32]) ı̂n1996. Aici T T P -ul funcţionează ca un director de publicare read-only, de unde entităţile

participante ı̧̂si obţin informaţii necesare pentru dovezile de non-repudiere.Protocolul este descris de următoarele tranzacţii:

1. Alice (ca entitate emitentă):

(a) criptează mesajul M folosind cheia simetrică k : c = E k(M );

(b) generează dovada originii lui c:

EOOc = SigAlice(Bob,l,t,c) unde l = Hash(M, k)

(c) trim

Documents

sec_flux_informational.pdf